Why Projects Fail

The following piece is from my book with Ted Leemann, Creative Project Management, published in 2010.

 * * *

If project management is so good, why do 70% of all projects, including those led by experienced and capable project managers, fail to get done within the Triple Constraints of time, cost, and performance — or in layman’s language, on time, on budget, and to spec?

Here are a few instructive examples.

• In 2006, a $400 million purchasing system for Ford Motor Company was simply abandoned.

• Software errors in a UK Inland Revenue system resulted in a $3.45 billion tax-credit overpayment.

• The infamous automated baggage system at Denver International Airport burned through $250 million before being abandoned as unworkable.

• The Department of Defense’s $6 billion Kinetic Energy Interceptor program was terminated in 2009 after it was determined that it would not achieve its goals.

That’s not all. Let’s look at some numbers on project performance.

The Standish Group has tracked project performance since 1994. Every two years, it issues the CHAOS Report. In the 2009 CHAOS Report, they reported these abysmal numbers:

• 32% of projects were delivered on time, on budget, and with the required features and functions.

• 44% were finished either late, overbudget, or only partially completed

• 24% failed altogether, and were cancelled or abandoned.

There’s good news and bad news here. The good news is that in 1994, when the Standish Group began tracking, only 16% of projects succeeded in meeting the trifecta of the Triple Constraints (on time, on budget, to spec). On the other hand, the 2009 report shows that there’s been a downtick in success (34% to 32%) and a significant uptick in failure (from a low of 15% to today’s 24%).

For challenged projects, those that succeed in some elements and fail in others, the good news is that average budget overrun has dropped from 180% to only 43%. On the less positive side, time overruns have gone up 30%, and the percentage of features that made it into the final product has dropped from 67% to 52%.

During this time, nearly 260,000 project managers earned the prestigious Project Management Professional (PMP®) designation from the Project Management Institute (PMI). But the track record of improved project performance is lackluster at best.

What’s going on?

A significant amount of study and reporting has attempted to discover the reasons for these failures.

• The 1998 Bull Survey, conducted by the French computer company of the same name, identified the major causes of IT project failure as a breakdown of communications, a lack of planning, and poor quality control. 

• KPMG Canada, in 1997, identified the core issues as poor planning, weak business case, and a lack of top management involvement and support. 

• The Standish 1995’s Chaos Report named incomplete requirements and lack of user involvement. 

• The OASIG Study, also published in 1995, cited lack of attention to the human and organizational aspects, poor project management, and poor articulation of user requirements.

But poor planning, weak business case, and inattention to human and organizational aspects aren’t causes, but rather symptoms of a much large systemic shortcoming.

Treating the symptoms isn’t the same as treating the underlying medical conditions. We know some of the root causes. People with poor interpersonal or team leadership skills and stakeholder conflict create friction in the project environment, and friction increases inefficiency and waste. The mass and complexity of the organization increases its moment of inertia, and getting anything to move takes enormous effort. People come and go, missions mutate, information goes missing, and that increases entropy, the tendency to move from order toward chaos.

Things fall apart.

It’s been said that there are only two reasons for project failure:

1. Things that happened that nobody thought of and that they accordingly didn’t prepare for.
2. Things that happened that everybody knew was going to happen, but nobody did anything about.

How often have you experienced project problems because something came along halfway through your project and they had to pull two people off the team ? How about someone wanting a major change in one or more of the triple constraints when the project is  three-quarters completed? Somewhere in your project environment, there’s probably some recurrent problem that happens every single time. Things take longer than you expected. Not everybody is really on board. There’s always a layer of technical complexity no one expected. Important people don’t really know what they want, or expect you to figure it out magically.

But do you account for these situations in your project planning? For a few outstanding project managers, the answer is at least a partial “yes.” For most of us, the answer rests somewhere between seldom and never.

Maybe it’s something you can’t afford to recognize officially because the organization’s in denial. But maybe it’s something in your project management blind spot.

If you take the list of reasons from the studies above, you can boil them down into the following four (seven, if you count clauses) often unasked and unanswered questions:

• Why are we doing this? (Business case)

• Who has an interest in what we’re doing, and what do they each want and need? (Human and organizational aspects)

• What do we have to do, and how are we going to do it? (Project management, including planning and quality control)

• Who needs to be involved, and in what way? (Top management and user involvement and support)

The official standards of professional project management are designed to make sure these issues get appropriate consideration. But let’s face it — these are pretty obvious. It shouldn’t take a PMP to grasp these concepts.

And all too often, having a PMP doesn’t mean someone does.

The CHAOS Report (Managing Impossible Projects, Part 3)

Photo: Baggage system, Denver International Airport


The following series is adapted from a keynote I delivered at the Washington, DC, chapter of the Project Management Institute back in August. Parts also come from my book Creative Project Management (with Ted Leemann), published by McGraw-Hill. 



The annual Standish Group’s CHAOS Report, which tracks software project performance reported these abysmal numbers for 2009:

• 32% on time, on budget, to spec
• 44% finished late, over budget, or partially completed
• 24% failed, cancelled, or abandoned

Why do so many projects fail, either in part or in whole?

Certainly, there are badly managed projects — even some headed by PMPs. But it’s hard to blame a 68% defect rate on poor practitioners alone.

Sometimes the problem is the definition of success. By the logic of project management, the Leaning Tower of Pisa was an abysmal failure: late, over budget, and…well, aren’t buildings supposed to be straight? The Standish Group would clearly label the tower as a failed project, yet if the tower didn’t lean, who today would bother to visit?

The third reason, of course, is that the project was problematic to begin with — arguably or actually impossible. This can happen for a variety of reasons. In the case of Apollo 13, the constraints of time, resources, and performance were established by the situation, not by the will or desire of the project managers or owners. They were what they were — whether they were achievable was a separate issue.

In the Battle of the Bulge, the German Ardennes offensive had already begun. We would be able to get troops to the front to relieve the pressure on beleaguered First Army units, or we wouldn’t. Neither project managers nor project owners necessarily control the constraints that drive their projects.

Sometimes we’re just making a guess when we establish a project’s constraints. The original budget for Denver International Airport was $1.2 billion, and the original deadline was October 1993. The final price came in at $4.8 billion and the actual opening date was February 1995. (The infamous automated baggage system, budgeted at $186 million, wasn’t cancelled until 2005, by which time its construction costs were increasing at a staggering $1 million a day!)

Denver wasn’t an example of engineering or technical failure — no, not even the baggage system. The failure was driven by political considerations, including a nonstop war among several key stakeholders. When customer conflict generates mutually exclusive requirements, “impossible” becomes just another word for nothing left to lose.

In any event, we project managers are hired hands. Sometimes we may do double duty as customers or sponsors of our own projects, but when we put on our PMP hats, we’re here not to decide, but to execute. We are bound by the decisions and choices of others, and sometimes we start the project on the precipice of failure. After all, how many of you get to decide your own timelines, set your own budgets, and establish your own performance requirement?

I didn’t think so.

Still, you don’t want to be too quick to pull the trigger. Let’s imagine that you have a project and your experience tells you it can’t be done. Isn’t delaying the inevitable bad news just going to make the problem worse?

That depends on what you do in between receiving the assignment and giving the answer. Even if your project’s impossible, or at least compromised, there’s still a customer problem needing to be solved. Telling people what they can do and what they can have tends to get a better reception than telling people what they can’t do and what they can’t have.

That’s why the first step in managing a potentially impossible project is analysis. When you analyze an apparently impossible or potentially impossible project, you may learn different things.

1. You confirm that the project is in fact impossible, and can provide evidence to the customer. You and the customer can begin to figure out what alternatives may exist or how to deal with the consequences of an unsuccessful project.
2. You confirm that the project as originally proposed is in fact impossible, but are able to find potential changes that will make the project possible, which you can present to the customer.
3. You confirm that the project as stated is in fact impossible, but are able to offer alternatives and compromises that might satisfy at least some of the customer’s requirements and needs, or close part of the gap.
4. You can’t confirm that the project is in fact impossible, but you can identify at least some of the risks and challenges you face, which you and the customer can then assess.
5. You find a creative way around the barrier that made the project impossible, and achieve the original goal.

Even if your analysis leads to the first outcome (it’s just flat impossible), however, your situation is still improved by your ability to give a thoughtful reply with supporting evidence, and your attitude in making a good-faith attempt to solve the problem.

Partial successes (outcomes two, three, and four) are a marked improvement. Even if the project is impossible — or highly risky — as stated, the customer may be able to get a significant portion of what he or she wants. Plus, it’s well known that the first approximation of available constraints may not be the final word. There may be more to draw on. And again, people tend to react better to hearing what they can have, and less well to hearing what they can’t have.

We renovated our house last summer, and the project was on time, exceeded our expectations — and cost about twice as much as we’d planned. We still call it a rousing success, because we never really expected to meet the budget anyway. It was a hope, not a realistic assessment. The Standish Group would call it a failure, but we don’t — and the customer is always right.

The fifth outcome (solve the problem with creativity) is ideal, but often challenging and not always successful.  The best direction to find the creative answer is, paradoxically, to focus on the barriers in the first place.

Next Week: The Power of Negative Thinking!