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.

Project Disasters and Career Management

“My project’s going down the tubes. How do I keep them from making me the scapegoat?”

- RN, Washington, DC

There’s an old joke about the stages in a project life cycle. First comes enthusiasm, then disillusionment, followed quickly by panic. Then comes the search for the guilty, resulting in punishment for the innocent, praise for non-participants, and when everyone sees what a disaster it’s been comes the final stage: figuring out what we should have been doing in the first place.

By the time the project’s in trouble, it’s usually too late to do much about it. That’s why project managers know the real secret is to keep your project out of trouble in the first place. It doesn’t matter whether the problems are actually your fault; it matters whether you could possibly have prevented it, fixed it, or managed it. That’s called risk management, a forward-looking approach to project uncertainties. What could go wrong? Why could it go wrong? And what can you do to prevent the problem or deal with it if it occurs?

A risk management plan can be a huge, formal document or it can be comparatively casual, but either way, you need one. Start with risk identification, a list of potential issues. You can brainstorm with your team, you can ask people who’ve done similar projects, and you can review the documentation (requirements, contracts, statements of work). Prioritize the risks by how serious they are, and take some time to dig into the bigger ones.

There are basically five things you can do about a risk, and your job is to pick the best choice. For example, if you’re the owner or captain of RMS Titanic, and you know there are icebergs in the North Atlantic, you can do the following:

1. Avoid the risk. Change the course far enough to the south, and there are no icebergs. Of course, the trip will take longer.
2. Transfer the risk. Buy insurance so that someone else will pick up the bill in the event of sinking.
3. Mitigate the risk. Mitigation reduces a risk without getting rid of it altogether. For example, the British inquiry into the sinking concluded that the Titanic was going too fast. It might have hit an iceberg anyway, but a slower collision might have reduced the damage. 
4. Have a contingency plan. More lifeboats (the Titanic only had enough for about a third of its passengers and crew) wouldn’t have prevented the sinking, but would have reduced loss of life.
5. Accept the risk. Some risks you just have to deal with. If you’ve done everything that seems practical and appropriate, risk isn’t exactly zero. The remaining risk is something you simply accept. Save the rich and leave the poor in steerage.

Risk management is something you do in advance. Once the Titanic hits the iceberg, the game changes from risk management to problem solving. There, unfortunately, the options tend to be dramatically reduced.

What if the project appears to be impossible? People say “nothing’s impossible,” but that’s if you have unlimited time, unlimited resources, and really flexible standards. Are the constraints on the project (time, cost, expected performance) too tight? Is that because of a management decision, or are the constraints imposed by external circumstances? Management decisions may change, but if the money isn’t there or the deadline is unstoppable, management may have no more power than you do.

If a project is impossible as contemplated, that doesn’t mean it’s impossible period. Maybe you can do something different, or do it in a different way. Look for flexibility and opportunity wherever it may be found. If you can’t do everything they’re asking for, perhaps there’s a “good enough” level that meets the objective.

In the aftermath of a big project disaster, there may be some kind of investigation, and if you’re in charge, it’s perfectly reasonable that people will look at you. That doesn’t automatically mean that scapegoating is taking place. Yes, there’s usually blame to go around, and it may be appropriate and fair for you to own a piece of it. Sometimes it’s good strategy to accept your share of any blame early. And, to be perfectly fair, if you’re in charge of the project, you normally deserve at least some share of both credit and blame.

When scapegoating actually occurs, it’s normally an attempt to deflect responsibility from someone higher in the management food chain onto a more vulnerable target: you, for example. And again, you normally have ample warning if you’re paying attention. That person’s goal, remember, isn’t to scapegoat you, it’s to avoid getting himself or herself in hot water. If you can keep that person out of trouble without getting yourself hurt, that may be a win/win. (Don’t yield to the temptation to deflect the trouble onto someone still lower on the food chain, unless that’s the person who’s actually responsible. It’s not only immoral, but other people will notice and your reputation will suffer.)

If everything else fails, advance notice gives you one more opportunity. There’s an old management joke about an outgoing project manager who had some words of wisdom for the incoming one. “I’ve left you three envelopes in my desk drawer, and they have the answers to the first three crises you hit,” the outgoing PM said.

The answer to the first problem was “Blame your predecessor.” To the second, it was “Reorganize the team.” And to the third, it was “Prepare three envelopes.”

Sometimes you have to know how to get while the getting is still good.

Failure *Is* An Option!

You probably won’t see the American Movie Classics channel run a festival of ‘‘Great Project Management Movies’’ any time soon, but if they did, Ron Howard’s motion picture Apollo 13, based on the real-life story, would be a natural candidate. Faced with a potentially disastrous accident, project teams overcome one potentially fatal barrier after another to bring the crew safely back to Earth, guided by mission director Gene Krantz’s mantra: ‘‘Failure is not an option.’’

But of course, failure is an option. Sometimes, it looks like the most likely option of all.

The odds in the actual Apollo 13 disaster were stacked against a happy outcome, and everyone—including Gene Krantz—had to be well aware of that fact. One of the key scenes in the movie involves a team of engineers trying to figure out how to rig a CO2 filter out of miscellaneous junk.

• The time constraint: before the CO2 levels overwhelm the astronauts. 
• The performance goal: to work well enough to let the astronauts breathe during the long trip home. 
• The budget: the junk on the table. 

And no one knows whether it’s even possible.

How do you balance the value of realism against the value of optimism in solving problems?

One way is to reject the false dilemma the question poses. Failure is not only an option, it’s a gateway to success ... if you fail in the right dimension.

If there is a trade-off to be made between the time constraint and the performance criteria, we know that ultimate failure—the death of the Apollo 13 astronauts—comes most rapidly from failure to meet the time constraint. That is, if we build a perfect CO2 filter, but we finish it too late, we’ve still failed. Perfect performance does not compensate for a failed deadline.

But wait! Why isn’t the reverse equally true? If you fail to meet the performance criteria, isn’t it irrelevant how quickly you fail to do so? Actually, it depends on the extent of the failure.

To illustrate, let’s look at this scenario: You’ve managed to come up with an inefficient partial solution that will last only half as long as it’s going to take to get the astronauts back home, but you’ve done so within the original time constraint. Do you take this solution? Absolutely!

Although you have failed to make the performance goal for the project within the original time constraint, you’ve reset the game clock. With a day or more to work instead of mere hours, your chance of finding a solution that solves the remainder of the problem has become that much more possible.

The right kind of failure is not only an option, but sometimes a desirable one. In this project, we can’t accept a failure to meet the time constraint, but we can live with a partial performance failure and stay in this game.

This piece was written for Federal PM Focus, a newsletter published by Management Concepts. Click the title above to register for a free 30-day trial.

Adapted with permission from The Six Dimensions of Project Management: Turning Constraints into Resources, by Michael Dobson and Heidi Feickert, © 2007 by Management Concepts, Inc.  All rights reserved. www.managementconcepts.com/pubs

Unknown Unknowns

“There are known knowns, known unknowns, and unknown unknowns,” Donald Rumsfeld famously observed. He was talking about an issue close to the heart of every serious project manager: managing risks and making decisions when you don’t always have data to back them up.

Classical risk management is based on the law of large numbers. A creation of famous mathematicians of the 18th century, classical risk is based on statistics. We don’t know if your house will burn down, but in a pool of 100,000 houses, we can make a pretty good prediction about how many houses will. In many ways, classical risk management is at the heart of modern economic civilization. From insurance to interest rates, the ability to analyze and measure risk is essential. At the root of our current economic crisis is the unfortunate fact that risk analysts sometimes get it wrong.

The classic risk formula R=PxI (risk equals probability times impact) measures the severity of risk and provides a guideline for determining how much you should spend in dealing with the risk. If there is a 10% chance, for example, of an event that will cost you $10,000 if it happens, the risk score is $1000. That means if you can get rid of the risk for under $1000, you are better off.

But in project management, you often have no idea what the probability is. “We’ve never done this before! What’s the chance of Event A happening?” Clearly, we have no idea. What do we do now?

Rumsfeld’s answer, basically, was to do nothing. Known knowns and known unknowns fall into the universe of planning, but the set of unknown unknowns was too far outside the box. Unfortunately, that doesn’t work out in practice. If you go to your boss and say, “Sorry that project failed, but it was because of an unknown unknown,” that doesn’t work very well as an excuse. Someone else, after the fact, with the benefit of 20/20 hindsight, gets to decide whether it was reasonable for you to have missed it. You are a hostage to fate.

Fortunately, there are a great many things project managers and planners can do even in the face of unknown unknowns.

1. Establish a reserve. Military planners know this well. As the elder von Moltke famously observed, no battle plan survives first contact with the enemy. No project plan survives first contact with reality. The total reserve should be proportional to the estimated risk, but the real secret is that reserve can be created in three dimensions: extra resources, extra time, and optional scope.
2. Think backwards. The triple constraints – the interplay of time, cost, and performance – form a powerful tool for insight. Any negative event can only do three things to your project: it can make you late, it can drive up your cost, or it can degrade your performance. If it does none of those things, it’s not an issue. If you have generic strategies for recovering lost time, recouping lost resources, or patching up problems in scope, you don’t need to know every possible direction from which trouble can appear. You already know what to do.
3. Define the range of outcomes. There are six possible outcomes for any given project. The baseline outcome is “fully satisfactory.” That’s the level of meaningful good enough. Another outcome is “barely adequate.” That’s the worst you can do and not have to call the outcome of failure. Above “fully satisfactory” is “exceeds expectations,” a traditional operational definition of quality. At the top is “outstanding,” and below “barely adequate” are the levels of “failure” and “catastrophe.” (Failure just takes down your project; catastrophe takes other stuff down along with it.) The reason you want to define failure and catastrophe is for risk management. The reason to define the higher grades is to improve quality. While it’s easy to provide quality as long as you don’t care how much you spend, that’s not so good for business. Find the elements of outstanding that cost very little, and you’ll deliver high quality performance even on a shoestring budget.
4. Work harder and dig deeper. At the beginning of the project just about everything is an unknown unknown, but it doesn’t have to stay that way. Have you really analyzed your project risk environment? In a number of organizations, thinking about failure causes people to be branded as “not a team player.” Unfortunately, the failure to think about failure increases the likelihood of failure. The more you obsess about the reasons for failure, the more powerful you’ll be at preventing it.

SideWise thinkers don't fall to pieces in the face of uncertainty. Uncertainty and the unknown is quite real, and denying its reality doesn't make your life better. Unknown unknowns are part of projects and of life in general. You can prepare even if you can't know.

Next week, Unknown Knowns — What you don't know that you really do know.