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.