Study: 68 percent of IT projects fail

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.

TOPICS: Software

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):

  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:

Study: 68% of IT projects fail

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:

Skills gap premium

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.]

Topic: Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • I used to work for the federal government...

    ...we never got anywhere near a 32% success rate. More like 10%.
    • Hmmm

      How is that even possible? Where in the government? What was your role?
  • This is OK since IT in US is not a business but humanitarian aid to India.

    • Ignorance is Bliss

      Looks like sour grapes to me. Please do some research before stating your opinion.
    • Please read this
    • This is OK since IT in US is not a business but humanitarian aid to India.

      IT in US is able to sustain the salary levels because of outsourcing to India!! Have a thought!!
  • RE: Study: 68% of IT projects fail

    Is this problem down to the 'get-ahead' office politics that pervade so much of Gov't and business life?
    • The answer to that question is in the article.

  • RE: Study: 68 IT projects fail

    I think your recommendations to prevent failure are rather simplistic, if not pedantic. Not all project management teams are as smart as ZDnet writers, but I'm sure some are close.

    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?

      Your comments suggest the post hit a nerve with you -- why is that?

      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?

      The statistics and data in this post have been summarized from the IAG?s actual report (31 page-report---- ack too long!).

      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

      are systems engineering and systems architecture failures. The article is right on target in looking at the relationships between business analysis, requirements analysis, company capabilities, and how these impact the cost for quality.

      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

    Here's my rinse and repeat. Back in 1990 or so I found a one-page 'editorial' that reshaped my career focus. It effectively reported a study to 'debunk' the "we didn't get the requirements right" theory.

    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 ...

      ... how that would 'debunk' the "we didn't get the requirements right" theory. Seems to reinforce it, actually. Only after the right requirements were determined, could the system be made to work.

      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

        And I suspect would therefore agree strongly with you :)
      • IS

        There is actually a field of study specific to this process: information systems. Learning organizational psychology is part of the discipline. Experienced developers know that they need to look at the functioning of the entire system, and that the people, processes, culture, politics, etc. are all part of that system, along with the network hardware, computers, applications, etc.
      • The best sources for how users use a system

        are the users.

        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

      Most insightful!


      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

        Re: "[i]What kinds of assumptions and expectations go wrong upstream from that

        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.