Study: 68 percent of IT projects fail
Summary: 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.
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.
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.
- 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.
- Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.
- 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.
- 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:
- 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.
[Via PR goddess, Joan "have you seen this study" Levy, from Blanc and Otus.]
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
I used to work for the federal government...
Hmmm
This is OK since IT in US is not a business but humanitarian aid to India.
Ignorance is Bliss
Please read this
This is OK since IT in US is not a business but humanitarian aid to India.
RE: Study: 68% of IT projects fail
The answer to that question is in the article.
RE: Study: 68 IT projects fail
What would be more important to see is out of the 68%, how many had a project manager with a PMI certification? Do the certifications actually make a difference? PMI has been selling itself as a solution to these sort of failures. That would be the more interesting analyst. But then again I'm not as smart as a ZDnet writer.
What has PMI got to do with it?
If you want to see studies regarding the benefits of hiring PMPs, I suggest you contact PMI.
Wow, a bit defensive are we?
Maybe You Want to Issue a Throw Down to IAG?
Now, you may have issues with their survey questions, or the types of people whom they chose as participants, but the blogger of this post is not a representative of IAG.
Sounds like you want to challenge their premise.
The failures described in the article
The results are entirely consistent with the longtime research into quality by Capers Jones, who once observed that the best engineering companies keep getting better while the majority are bad and getting worse.
The consequence is that we have a gulf of quality between the best and worst systems / software engineering companies that is only widening.
RE: Study: 68% of IT projects fail
So they audited the process. Were all the requirements captured as intended? Check. Were all the requirements met by the solution? Check. Result: Fail!
And this is where my life changed...they brought anthropologists into the environment in which the system was being used -- an emergency room. They added more requirements based on their observations...the system was a success.
Now let's talk about having the wrong skills...
I'm not sure ...
It seems obvious to me that IT managers should be one part anthropologist - understanding the culture of their company, especially how it relates to how the people are using the technology.
Rotkapchen *is* an anthropologist
IS
The best sources for how users use a system
The failure Rotkapchen describes is a business analysis failure - failing to understand how the system will be used by the operational staff in the system's operational configuration and environment.
You're right - business analysis is a major part of requirements analysis. Failing to connect the system's business need with the system's definition is a very good way to ensure program failure.
Knowing You're on the Side of Reality is the Trick
EXACTLY!
That?s why so many organizations are so surprised when their IT initiative run counter to their operations. You think you got it all right. You can verify that your system does what you defined it to. But it doesn?t help in the field.
And that?s when your dealing with the nitty-gritty details within a business process.
What kinds of assumptions and expectations go wrong upstream from that?
That?s why is so helpful to have a third-party who can question assumptions during the "we need a miracle stage" or the capture or re-evaluation of business process stage.
A few root causes
[/i]?"
1) Systems architecture failing to provide a clear, complete, and correct concept of operations that follows from the business mission statement and the system business case.
2) Systems engineering failing to perform adequate business analysis and requirements analysis.
Project management or customers can be a root cause in not allowing enough time for thorough requirements analysis.
Excellent requirements analysis is the top strength of Praxis High Integrity Systems, but they admit this requires a lot of customer management. Customers who start clamoring for "when can I see something" need to be persuaded that rushing into something less than half-baked is not in the customers' best interests.
You can see this impatience in video game developer forums with kids who start screaming for the next mission pack just 1 day after the last one.