Dr. Andrew Makar is an IT program manager and is the author of the Microsoft Project Made Easy series. For more project management advice, visit the website TacticalProjectManagement.com.
The Chaos Report is a frequently referenced study that provides statistics on IT implementation failures and successes. You likely don’t need another industry statistic to understand poorly defined requirements result in poor project outcomes. While developing a lecture on requirements management, I found a few examples of project failure. The following categories are not a definitive list, but represent a high-level categorization of sources for requirement management failures.
Poorly Defined Requirements
We’ve all heard the phrase “Garbage in, garbage out.” A few years ago, a system implementation project suffered from poorly defined requirements and resulted in a failed project. The business customers thought they were providing good requirements for system development but ended up with garbage and fodder for this story.
The original scope of the project was to develop a simulation tool for a Microsoft Access database application. The business customers wanted to train people using the Web instead of relying on local copies of the Access application. The vendor followed the high-level requirements and developed a Web-based application that resembled the 30+ Access screens. The business customer quickly noticed none of the behind-the-scenes calculations worked and the data didn’t flow between different modules.