Projects can fail for a number of reasons, but at the root of most failures is a failure to gather correct and consistent requirements. We've all laughed at some variant of the above diagram, but these issues are all because:
- We fail to capture correct and consistent requirements
- We play "broken telephone" when we are communicating requirements
As long as the written requirements don't diverge too much from the actual requirements, you will have time to adjust the requirements during project execution and still get to the finish point.
Now suppose one of the following happen:
- You don't have all the core requirements because insufficient people were consulted
- You have conflicting requirements from different sources
The last situation occurs where you only have vague requirements before you start a project. This situation happens where the executives need a project done quickly and over-estimate the teams familiarity with the subject domain.
It is human nature to assume that the sooner you start a project that the sooner you will finish. That assumption is only correct if you have good requirements to point you in the correct direction. Good requirements are consistent and correct and include at a minimum the core requirements for the primary users.
Starting a project with mediocre or poor requirements is simply a recipe for project failure. Mediocre or poor requirements are incomplete and inconsistent.
If you have been part of a project failure then you will discover that despite the other factors that went wrong, requirements failure was at the root of it.