I’ve written about a number of failed projects (see the Project Failure link at the top of this blog). There is a common thread across all of them. Lack of clear requirements. It is the lack of clarity that is the key point.
The US Census devices had “thousands” of “unreconciled” requirements, the Sydney Opera House had an attractive picture, but no hard factual underpinnings for how the design could ever work, the FBI’s virtual case file project were “ill defined and evolved as the project progressed” and during the H1N1 vaccine project the scope of work changed materially. All of the projects I’ve just described failed.
Now this is a short post, so I won’t detail strategies for project success, but it does seem that a sure fire way to fail is to have vague, changing or conflicting requirements. Interestingly, bad estimates don’t lead to massive delays, vague requirements do. Equally, poor budgeting may not cause massive cost overruns, vague requirements do.
Of course, to run a successful project you need to succeed in a host of areas. It’s not just about the triple constraint of cost, schedules and resources. You need to get the people and communications aspects right too, but to fail you only need to keep the requirements vague.