Why do so many projects fail? – take 2
This month’s other article considers why projects fail from the perspective of a project manager. This month, I am looking at an even more critical reason for failure – getting it wrong (or not getting it right) from the very start. According to the Standish Group (1995), the single most common cause of project failure is incomplete requirements, more than any of poor planning, inadequate resources or lack of managerial support.
I am regularly asked to help companies who have commissioned or bought a system that did not deliver the expected benefits or, in some cases, delivered nothing at all. When I ask for the original specification that told the supplier what was required, it often turns out that there was no such document. A plausible sales team has persuaded the company that their system was all that was needed and no formal selection process was ever undertaken.
If you don’t know, or cannot write down, what your project must achieve and what part IT systems play in that, then it should come as no great surprise if the project fails to deliver. Enough people have discoursed on this in the past, from Lucius Annæus Seneca who said “There is no fair wind for one who knows not whither he is bound.” in the first century AD, to Forrest Gump: “If you don't know where you're going, you're unlikely to end up there.”
But gathering requirements is omitted or skimped in projects because it takes time and effort. It has to take account of the views and needs of the various people who have a stake in the project’s outcome, be that management, users, customers, suppliers, shareholders, regulatory bodies or any other of the many possible stakeholders. Investing this time and effort lays the foundations for a successful project, since good requirements provide:
- a description of the agreed outcomes for the project, based on all the relevant views
- a baseline for the project, against which a project manager can measure progress
- a basis for testing the systems in the project, and for accepting them into service when complete
On a practical note, it’s important to remember two critical aspects of good requirements:
- they are found by consistently asking “why?”, not taking statements at face value, but probing to uncover the underlying need
- they concentrate on what is required, not on how it can be achieved
With good requirements in place, the architects and designers of the solution have a much better chance of delivering what is needed.
In short, if you want to have any chance of delivering a successful project: before starting out, make sure you have agreement on what people want from it and write it down.
|
