The problem doesn?t get solved in part because it is still not accurately understood; and so the solutions continue to come up short. The five key causes are not independent. Rather, poor requirements lead to poor planning that cannot help misjudge resources, schedules, and risks.
More importantly, what people call requirements generally are actually high-level design of the products, systems, software they expect to create. What they are missing are the REAL, business requirements deliverable _whats_ that provide value when met, satisfied, or delivered by the products/systems/software _hows_.
REAL business requirements are not merely objectives but instead are the _whats_ that will achieve the objectives and thereby provide value.
Products, and thus their projects, turn out wrong when they don?t meet the REAL business requirements, usually because the REAL business requirements have not been defined adequately, usually because people think (and their gurus tell them) mistakenly that product/system/software requirements are _the_ requirements.
See my Artech House book, Discovering REAL Business Requirements for Software Project Success, for further explanation and ways to reduce failures.
Discussion on:
Message 5 of 1
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
