CIO analysis: Why 37 percent of projects fail

CIO analysis: Why 37 percent of projects fail

Summary: New research identifies five important reasons that projects fail.

TOPICS: CXO, IT Employment

A study by project management consulting company, PM Solutions, identifies top causes of IT failure.

The report, called Strategies for Project Recovery (PDF), covers 163 companies roughly split between small, medium, and large organizations. On average, respondents manage $200 million in projects each year, of which approximately 37 percent are "at risk." The average company in the study therefore faces $74 million of "at risk" projects each year.

The study identifies five top causes of troubled projects:

  1. Requirements: Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise.
  2. Resources: Lack of resources, resource conflicts, turnover of key resources, poor planning.
  3. Schedules: Too tight, unrealistic, overly optimistic.
  4. Planning: Based on insufficient data, missing items, insufficient details, poor estimates.
  5. Risks: Unidentified or assumed, not managed.

According to the survey, the most common obstacles that interfere with recovering failed projects are:

  • Getting stakeholders to accept the changes needed to bring the projects back on track-whether they are changes in scope, budget, resources, etc.
  • Poor communication and stakeholder engagement; lack of clarity and trust.
  • Conflicting priorities and politics.
  • Finding enough qualified resources needed to complete the projects.
  • Lack of a process or methodology to help bring the project back on track.


This study is useful but not groundbreaking; it sheds light on a common problem, reaffirms existing beliefs on causes of failure, and brings attention to important issues.

The 37 percent failure rate is notable because it falls within the broad range of statistics (thirty to seventy percent) that most studies report, even though it is somewhat surprising the number is so low. This report did not focus on failure rates, but instead emphasized project recovery, which could have affected these specific results.

Failure rates are notoriously difficult to measure and virtually impossible to compare across multiple studies by different researchers. Therefore, consider specific failure rates as suggesting problems and relative magnitude of seriousness; failure statistics are not absolute indicators.

Related: CIO analysis: Defining IT project 'success' and 'failure'

Nonetheless, it's incredible to consider that over a third of projects in this study are likely to have serious problems. The financial impact of these failures is significant and meaningful, to say the least.

It's easy to brush aside the five causes of failure listed above, thinking they offer nothing new. However, such superficial views do not help solve the problem. It's far better to acknowledge the challenge and difficulty of aligning expectations and perceptions across a diverse set of stakeholders, which is a fundamental obstacle to project success. That's why this blog discusses change management so frequently.

CIO perspective: Acknowledge the reality of project risk -- vulnerabilities from so-called "obvious" sources represent a clear and present danger to your organization. To address these inherent risks, develop improved methods for communication, collaboration, and information sharing across silos and departments, both inside your organization and with external partners.

In addition, consider methods for making your projects more adaptive. On many projects, decision-making is a step function where information gathered over a relatively lengthy period culminates in periodic review and analysis. Reduce these decision cycle times to keep your projects responsive to changing conditions and requirements.

Solving the IT failures problem is difficult precisely because there is neither a silver bullet nor a clear target at which to aim. Forward thinking CIOs will recognize these realities and innovate by constructing a broad-based, long-term campaign to ensure that project outcomes align with organizational interests.

Update: Argentinean IT consultant, Carlos Francavilla, translated this post into Spanish, which you can read here.

Topics: CXO, IT Employment

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
  • Incompetent management

    These are all symptoms, the cause is incompetent management every time.

    Bad requirements capture usually means management has assigned too much weight an analyst who has no talent.

    Then the smart people leave, its clear from early on if a project will fail, they want to leave with a CV full of success.

    Schedules slip, but that's not because developing software is hard, it's not, it's easy. They slip because nobody wants to rush ahead to hit the dead ends. There is no win in that situation, when you hit the dead end, *you* will take the blame for rushing ahead, as if the dead end isn't there if you don't reach it!

    Planning, is meaningless if the project will fail, why rush... milk it.

    Risks, well I've even had one manager who had such poor control of a project, any meeting in late beta cycles could send the spec wildly off at a tangent.... this is a guy who really knows how to snatch failure out of the jaws of success.

    There's a sort of gap, one the one hand the code says one thing, the computer works a certain way and it needs to be correct because you can't fool a computer. On the other, the management *believes* the code works in a *different* way. They convince themselves their requirements capture was correct. They convince themselves the code so far is fine, and that the process will lead to success, even if every step fails.
    • RE: CIO analysis: Why 37 percent of projects fail

      @guihombre Sorry, can't agree with your assessment that software is easy. It's only easy if you don't care. Anyone can deliver crap. Doing it right is hard.
      • RE: CIO analysis: Why 37 percent of projects fail

        have to agree with Sundowner. Why'd you think software gets released slower than hardware?
  • Message has been deleted.

  • Misunderstanding what requirements are is unrecognized culprit

    The problem doesn?t get solved in part because it is still not accurately understood; and so the solutions continue to come up short. The five key causes are not independent. Rather, poor requirements lead to poor planning that cannot help misjudge resources, schedules, and risks.

    More importantly, what people call requirements generally are actually high-level design of the products, systems, software they expect to create. What they are missing are the REAL, business requirements deliverable _whats_ that provide value when met, satisfied, or delivered by the products/systems/software _hows_.

    REAL business requirements are not merely objectives but instead are the _whats_ that will achieve the objectives and thereby provide value.

    Products, and thus their projects, turn out wrong when they don?t meet the REAL business requirements, usually because the REAL business requirements have not been defined adequately, usually because people think (and their gurus tell them) mistakenly that product/system/software requirements are _the_ requirements.

    See my Artech House book, Discovering REAL Business Requirements for Software Project Success, for further explanation and ways to reduce failures.
  • RE: CIO analysis: Why 37 percent of projects fail

    Michael, we're thrilled that you found our research worth quoting and delving into. Probably the key "failure" is the failure to admit from the get-go that many projects will face challenges and risks. If we "begin with the end in mind" as Stephen Covey urges, that fact that the end could involve risk and failure ought to loom large, according to the statistics. Yet we always act as if risk did not exist. Still, the major point we hoped to make with the study was that, despite the large number of projects at risk of failing, when companies take action to recover, they recover and go on to succeed. That, more than the failure statistic, is the key finding of our study.
  • RE: CIO analysis: Why 37 percent of projects fail

    How much was spent on this research? It's not that I disagree with the findings: I agree 100%. But fifteen minutes with any frustrated IT worker could have given you the same information.
  • RE: CIO analysis: Why 37 percent of projects fail

    I think at the top of the causes listed should be poor Executive Sponsorship / Leadership, Metrics, and Governance. Due to poor Executive Sponsorship / Leadership there is a lack of clear direction, strategy. Without proper governance, there is a lack of clear process for timely issue escalation, decisions, strategies. Without clear metrics to track progress, it is difficult to manage and control...another major cause of failure. If these were in place....the project would be a priority, there will be less politics, scope will get firmed up quickly, timelines will be in place, the collective project team will move forward and not fail.
  • From a consultant's perspective

    Thag came to me the other day and asked me to solve his problem; basically he is hunting Mammoths in the tundra around Milton Keynes and finds it difficult, dangerous and inefficient using just a pointy stick to track and kill his prey. He is near starvation.

    He has already spoken to 3 other consultants who gave him 3 different solutions.
    Firstly the technology solution - Use these new devices called 'bow-and-arrow', where you don't need to get close to the beast to fell it
    Secondly the process solution - Retain the pointy stick, yet work with colleagues such that they spook/corrale the beasts and push them into a swamp where they get stuck and are easy targets
    Finally the people solution - Capture some baby mammoths and 'domesticate' them, therefore making hunting redundant and farming the norm

    Clearly all solutions are viable; however some are better than others, yet some are only able to be assimilated by some people. Thag, alas, is not a farmer, and can only operate in very small family units. The bow-and-arrow is the only workable solution - yet clearly he and his clan lacks the technical expertise the build and maintain a good stock of items.

    Moral of the story - let's see greater alignment between the project solution and the capability of the client!
  • RE: CIO analysis: Why 37 percent of projects fail

    If ever there was a 'back to the future' this artice says it all..Nothing has changed in the last 20 years to effect the success rate of IT projects seems to me that all that happens is a new group of supposed consultants dish up these well known lessons as 'new'...
  • RE: CIO analysis: Why 37 percent of projects fail

    Requirements don't define a problem, let alone a solution.

    Understanding the business problem and identifying an optimal solution will lead to requirements that a project can deal with.

    Starting with requirements and expecting a project to deliver a solution is crazy - but it's business as usual - so are projects that don't "meet expectations"
  • unless we start designing things like pros in other fields ...

    Suppose I were to ask people why there were so many failures in the early days of rocketry? Would anyone say requirements, resources, schedules, planning or risks? I doubt it. I think almost anyone with any common sense would say that the failures were due to bad DESIGN. An engineer might add that if the design were OK then the failure was due to a bad IMPLEMENTATION (i.e. one that didn't follow the design). Rockets used to blow up on the launch pad regularly because the designers didn't know what they were doing. But at least the rocketry industry eventually figured it out, and I doubt that rocket scientists were ever dim enough to imagine that you could build a rocket without designing it first.

    Now suppose I propose to you that we build a custom house in the same manner that most software projects today build custom apps. We'll hire a project manager with an MBA but zero construction experience. The manager will hire a bunch of contractors and hand them a list of requirements and maybe an artist's conception of the house. But there will be no designer and consequently no blueprint. How would this project fare? Most reasonable people, I think, would give the project a zero percent chance of success.

    I've been in this business thirty five years and every project that I've seen fail was due to a failed design (which includes the ever-popular "no design"). More recently I find projects staffed with people who simply have no conception that software has an underlying design (whether you design it or not), and that most "designs" are simply intractable. Show me a project that's going down the tubes, and I'll show you a design that could never be implemented, no matter how many contractors and managers you throw at it.

    Your five top causes here seem to imply that there's nothing between requirements and a finished product. Until our industry adopts the same commonsense measures that other industries have practiced for decades or even centuries, we will see a landscape littered with failed software projects, gasping for air like the fish out of water that they are.
    Dave Ziffer