Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

When to kill (and when to recover) a failed project

John Edwards | Sept. 15, 2017
Admitting project failure is never easy, but sometimes the kill decision turns out to be the best decision.

threatening dangerous rough ocean concept with sharks and life preserver

The project is behind schedule. The pilot has failed to meet expectations. Several key team members have already said good-bye. An important vendor has just discontinued an essential component.

The decisive moment has arrived. Is it time to kill the project or press forward in a new direction?

That's a simple question. An equally simple answer, however, can be elusive. As economist Paul Samuelson once remarked, "Good questions outrank easy answers."

Alan Zucker, founding principal of Project Management Essentials, a project management consulting firm based in Arlington, Va., notes that a troubled project's fate can be resolved most easily and successfully when all of its participants work cooperatively. The problem is, of course, that failing projects tend to generate the same amount of team harmony as a street riot. 


The path to project failure

Zucker notes that internal conflicts often keep once-promising projects firmly directed toward failure despite multiple warning signs that the venture requires a major course correction. "It is very difficult for the project leaders and senior executives to review and analyze the state of a failing project without their own biases clouding the decision making process," he explains. Marketing or product development leaders may, for instance, claim that the project is still a great idea, but that engineering or IT has messed up the execution. Engineering and IT staff, meanwhile, may blame the vendors, the concept or various constraints placed on the project. "These discussions usually do not end in a successful outcome," Zucker observes.

Stubborn prejudices and misconceptions can also steer a once promising project into the express lane to disaster. "There is the ostrich bias, where we tend to ignore negative information, or the confirmation bias where we look for information that supports our point of view," Zucker says. "Then there is overconfidence bias, where we are too confident about our abilities."

Unrecoverable costs are yet another reason why many organizations become reluctant to reach a decision on a failing project's future. "The idea is that a significant cost has already been paid and one might as well make further attempts to succeed so that this initial cost is not all for naught," says Erik Gfesser, principal architect at technology consulting firm SPR Consulting. "The problem with this reasoning is that if the direction of the project is unchanged it will continue to fail, leading to even greater incurred costs."

All too often, hubris plays a major role in postponing a go/no-go decision. "Organizations are so reluctant to kill doomed projects because the internal team — product owners and their bosses — will have a permanent scar associated with their name," observes Umair Aziz, chief Innovation and technology officer for Creative Chaos, a technology development consulting firm. "They were the champions behind the idea, and probably spent a decent amount of political capital to get the necessary budget and autonomy approvals."


1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.