Study: 68 percent of IT projects fail

Michael Krigsman examines key findings from a new report, which notes that success in 68% of technology projects is “improbable.” He says the solution lies in recognizing that requirements definition is critical.

—————————————————————————————————————

This is a guest post from Michael Krigsman of TechRepublic’s sister site ZDNet. You can follow Michael on his ZDNet blog IT Project Failures, or subscribe to the RSS feed.

According to new research, success in 68% 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.

• Related: Requirements and failure: Interview with CA’s SVP of IT

Key findings from the report, The Impact of Business Requirements on the Success of Technology Projects from IAG Consulting, include (emphasis added): 

• 1. Companies with poor business analysis capability will have three times as many project failures as successes.
• 2. 68% 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% of this group’s projects were “runaways” which had any 2 of: taking over 180% of target time to deliver; consuming in excess of 160% of estimated budget; or delivering under 70% of the target required functionality.
• 3. Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.
• 4. Over 41% 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.
• 5. 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% 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:

1. Write it down
2. Expand the requirement into a set of features
3. Share the planned features with the business to get their feedback
4. 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.

[Via PR goddess, Joan "have you seen this study" Levy, from Blanc and Otus.]