According to new research, success in 68 percent of technology projects is "improbable". Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start.
These are staggering numbers, hitting the high end of the Standish Chaos Report and presenting a far worse picture than Sauer, Gemino, and Reich.
Key findings from the report, The Impact of Business Requirements on the Success of Technology Projects from IAG Consulting, include (emphasis added):
- Companies with poor business analysis capability will have three times as many project failures as successes.
- Sixty-eight percent of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50 percent of this group's projects were "runaways" which had any 2 of: taking over 180 percent of target time to deliver; consuming in excess of 160 percent of estimated budget; or delivering under 70 percent of the target required functionality.
- Companies pay a premium of as much as 60 percent on time and budget when they use poor requirements practices on their projects.
- Over 41 percent of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization.
- The vast majority of projects surveyed did not utilize sufficient business analysis skill to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70 percent of the companies surveyed.
This chart illustrates the requirements skills gap most companies face:
The impact of this skills gap is substantial, directly increasing project time, cost, and risk of failure. The "skills gap premium" is reflected in this graph:
My take. This research seems credible and insightful, intuitively corresponding to observations one sees in the field. I should mention the study talks about "companies", rather than projects, and it's unclear whether that distinction has numerical significance. Either way, the number is both high and disturbing.
It's important to quantify issues such as requirements failure, because many organizations over-estimate their capabilities in this area. As the study makes clear, few organizations perform these activities well. Let me be clearer: your organization probably does a lousy job setting up projects, which is why they fail.>
The solution lies in recognizing that requirements definition is critical. Learn to make assumptions explicit; for example, if the business requests a specific requirement, do the following:
- Write it down
- Expand the requirement into a set of features
- Share the planned features with the business to get their feedback
- Rinse, lather, repeat until the technical team and the business are on the same page.
I asked Helge Scheil, CA's senior vice president and general manager of the company's governance group, for comment:
Solid requirements planning establishes a clear connection between the business case, project goals, and the project outcome.
Yes, it may seem obvious, but still many projects fail. Follow this perhaps-not-so-obvious advice and more of your projects will succeed than fail.
Michael Krigsman is CEO of Asuret, a software and consulting company dedicated to reducing software implementation failures. He is also CEO of Cambridge Publications, which specializes in developing tools and processes for software implementations and related business practice automation propjects. This article was first published as a blog post on ZDNet.com.