« Budgeting, Fund Management and Allocation, Expenditure Approval and Tracking of Funds Committed and Expended - Lessons Learned from Major Programs
What is Executing Process Group? »

Why It’s So Hard to Pull the Plug on a Failing Project

July 31, 2008 | Author: PM Hut | Filed under: Project Management Musings

Why It’s So Hard to Pull the Plug on a Failing Project
By Barry Shore, Ph.D.

Why is it that even when the evidence suggests that the plug should be pulled, projects go on and on?

Merck, for example, continued to market Vioxx in the face of evidence that the drug had harmful, sometimes fatal, side effects. The Denver baggage handling project continued for a decade after evidence mounted that the “line balancing” problem was unlikely to be resolved.

Why did General Motors, as reported by Business Week, continue to fund gas guzzling projects in the face of persistent evidence that gas prices were unlikely to return to $25 or even $50 a barrel? And why did Microsoft continue to push Windows Vista when over 33% of users where dissatisfied with the product?

What about the fatal attempt to climb Everest in 1996, when five people died on the mountain unwilling to heed the mandatory turnaround time and pull the plug on an expedition that faced deteriorating conditions.

How do these projects continue in the face of evidence that the plug should have been pulled? How can we make sense of this compulsion to continue?

Unfortunately there is not one root cause that can explain this behavior. Instead there are many possible explanations. Let’s explore a few reasons why it is so tough to quit.

Organizational Reward Culture. Most organizations reward success. If you complete a project within budget, on time, and meet quality objectives, you may enjoy the spoils of success and even earn a promotion. Bring in a project over budget, late, or deliver mediocre results, and it may take years to recover. Fail to deliver altogether and you may find yourself looking for a new job. Under those conditions who would want to pull the plug on a project?

Indeed, the Columbia Accident Investigation Board concluded that it was NASA’s “Faster, Better, Cheaper” culture that was as much to blame for the disaster as were the technical problems that lead to the disintegration of the spacecraft as it returned to earth’s atmosphere.

Executive Pressure. When executive management signs on to a project, they often visualize a very simplified AON diagram. It is a diagram with only two nodes; Start and Finish. What happens in the middle is often of little concern to them as long as you get to “Finish.” Under pressure of this kind, pulling the plug in the middle is tantamount to organizational suicide.

Sunk Cost Trap. When I worked at Hewlett Packard, one of my projects was to develop a process for winding toroidal transformers. These were doughnut shaped components, about the size of a quarter through which wire would be wound. The completed unit would then be mounted on a printed circuit board. I quickly discovered that the machines we had available were obsolete and if we replaced them with automated winders we could produce them in-house at a fraction of the cost that our current vendors would charge. With great confidence I wrote a proposal to the manager of manufacturing. Given our current volume, I explained, payback for the new machines would be less than nine months. Later that same day he stopped by my desk. Investing in these machines, he insisted, would make no sense because we had several machines, purchased six years ago, that were still not fully depreciated and could be used to wind these toroids. Under no condition would he be willing to authorize their replacement.

Most decision makers would say that the manager of manufacturing failed to recognize the principle of sunk costs. Once money has been spent, and the cost of the machine can no longer be recovered, the cost is “sunk” and can be essentially ignored when making future decisions.

The sunk cost principle implies that it makes no sense for a pharmaceutical company that has already spent $150 million in a drug development to continue with the project when new data strongly suggests that it performs no better than other drugs already on the market and has some troubling side effects. The $150 thousand in this case is a sunk cost.

We are not Quitters. I live near Boston and in addition to boasting about our championship sports teams we enjoy complaining about the cost of the Big Dig. When first conceived, this new system of bridges and tunnels promised to relieve traffic congestion in the Boston downtown area. The initial price tag was about $2 billion. But shortly after the project was approved we began suffering from price creep. Digging under a centuries old city with a maze of underground wires, cables, pipes, and tunnels, was much more complicated than expected. Even the soil under South Station refused to cooperate and had to be frozen to prevent the excavation from collapsing. Yet we persevered. Meanwhile, the price crept higher and higher. But we didn’t quit and construction continued. In the end the project cost about $16 billion.

What’s the lesson? We’re not quitters!

No Contingency Planning. No one likes to consider the possibility that things can go wrong. For this reason, and perhaps other reasons, we are reluctant to engage in contingency planning. When the Denver Airport baggage handling system was designed, for example, no one asked what would happen if the fully automated system failed. How would baggage be handed? No one thought about it and there we no accommodations made in the airport plan. So when the system did fail there were no other alternatives to move baggage around the airport. There were no underground roadways on which to manually move luggage using tugs.

It just might be that it is human nature to avoid contingency planning. None of us likes to write a living will, and if you look at the trend in personal savings rates over the last ten years they have fallen from a positive ten percent to a negative two percent. Few people, it seems are willing to plan for the possibility that they will need more than social security during their retirement years.

But here is the problem. If you don’t have a contingency plan for a project, then you might be inclined to cling to a failing project. There is nowhere else to go! It happened at Denver and it happened when General Motors had few plans to produce fuel efficient cars when the price of crude skyrocketed.

Continuous Improvement. When I was a kid, my uncle Al would take me to see the Red Sox every Saturday at Fenway Park in Boston. I remember sitting in the Bleaches near the left field wall and never taking my eyes off Ted Williams. He was my childhood hero. But the Sox never won the World Series. Yet every spring we were convinced that the team had improved and this year would be it. Well, I had to wait over 40 years for the chance to see it happen and by that time Uncle Al had died.

How many times have I heard the mantra of “continuous improvement” not only to keep hope alive for the Red Sox but to keep projects alive? How many times have project managers wanted more time to turn things around? How many times have they asked for more time to give their improvements a chance to show results!

Sometimes “continuous improvement” is too little and too late, yet it is a phrase that is often used to buy more time and avoid pulling the plug.

I am sure you can add to this list of “reasons.” But the main point here is to become aware of what is happening, understand the reluctance that most of have in pulling the plug, yet be courageous enough to put an end to a project that has little chance of meeting its objectives.

Dr. Barry Shore received his Ph.D. from The University of Wisconsin. He is the author of many scholarly and trade articles which focus on management issues ranging from human relations to decision support systems. Dr. Shore worked for Hewlett Packard, General Electric, and Boeing. His consulting and workshop clients include Liberty Mutual, Westinghouse, GTE, Chase Manhattan Bank, and US Navy. Dr. Shore runs Global Project Strategy, a project management consultancy website.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Thursday, July 31st, 2008 and is filed under Project Management Musings. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

3 people have left comments

Barry,

great post with wonderful examples. I would expect nothing less from a Wisconsin graduate.

You actually provided me with something I’ve been looking for. Justification for having gates or thresholds on projects. To me, a threshold is a point where the project has to be evaluated against predetermined measurements in order to determine if the project is continued or ended. I believe any major project (greater than 6 months or over say $10M) should have at least two and probably not more than 4 threshold review meetings.

What you provided was an additional justification. Contingency planning. Prior to beginning a project or a phase on a project, the threshold and at least one viable contingency plan should be known. The decision in the threshold review should not be an evaluation of the project, it should be an evaluation of whether to continue the project or switch to the contingency plan.

Andy

Andrew Meyer wrote on July 31, 2008 - 10:37 am | Visit Link

Great article. I like the AON example. Most of the major projects I’ve worked in the last 24 months have been “Recovery” of ERP systems. These projects had no contingency, and no pre-determined measurement at each milestone (as Andy has stated in his response). In most cases the cost of pushing a project to completion and then having to “recover” can be 10 times the initial cost, take longer then the first project, and quality, well quality quickly turns to a massive effort to just meet the basis legal requirements.

Great subject!

Doug

Doug Cazel wrote on July 31, 2008 - 10:55 am | Visit Link

Great article, great comments… Measurement thresholds and portfolio reviews are a great way for leadership to understand the health of a project compared to its individual milestones and its peer initiatives.

On the flip side, I’ve found that project teams I’ve been on also do not want to disband after successfully implementing a project. It seems that there is a certain comfort level associated with being part of a project team, whether the project is succeeding or failing.

Chris wrote on July 31, 2008 - 4:09 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories