Admitting project failure is never easy, but sometimes the kill decision turns out to be the best decision. Here's how to know when to scrap and when to save a failing project.

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."

Most projects that get into trouble are plagued by problems and oversights that existed at the very start of planning, says Todd Williams, a project failure consultant and the author of "Rescue the Problem Project, A Complete Guide to Managing, Preventing, and Recovering from Project Failure" (2010, AMACOM). Planners often overlook key issues, he notes. "It could be that there is one person who has done the project before who sees it as simple, yet he or she does not consider that the team doing the current project is different, and may not have the same experience as the team in the past."

Recognizing high risk projects

Organizations embarking on a new project should realize that some types of ventures are more failure prone than others. "There is empirical research that indicates the types of projects that are likely to be successful — or fail," Zucker says.

Zucker says planners should be aware of thee basic project truths:

• Small projects are significantly more successful than large ones
• Projects with engaged executives and stakeholders are more likely to succeed than ones with low engagement
• Agile projects are more likely to succeed than traditional waterfall projects

"The larger the project the more likely it will fail," Williams states. "Ten million dollar projects fail much more frequently than $100,000 projects — there are more moving parts." Williams notes that incremental deployment is generally a safer approach than undertaking a sweeping multifaceted project.

Michael Coakley, CIO of the City of White Plains, New York, and an adjunct computer science professor at Pace University, says that personal experience has shown him that customer relationship management (CRM) implementations tend to be the most risky projects. "Those systems are only as good as the data that goes into them and sales people and sales managers may not be so forthcoming with that information, fearing it takes away their competitive advantage," he observes.

Coakley observes that enterprise resource planning (ERP) initiatives are another potential minefield since, in most cases, both old and new systems will have concurrently during what might become a lengthy transition period. "That can put a lot of strain on all the players involved," he says.

Why IT projects fail

A project's overall trajectory — and its likelihood of success or failure — is typically set on the day it starts. "Projects with clear objectives and strong executive engagement tend to be successful," Zucker says. "Projects with broad objectives, where the finish line is fuzzy, will struggle or fail." He points to the 2017 PMI Pulse of the Profession global management survey, which shows that strong executive involvement increases the likelihood of project success by 43 percent. "Yet only 60 percent of projects get that support," Zucker notes.

The warning signs that indicate a project is in trouble are classic and well known. "The problem is, we tend to discount or ignore these early warning signs—like we do the onset of a cold," Zucker says. A project that's falling behind schedule and continually failing to reach planned milestones is almost certainly in deep distress. "Digging in, you will often find that requirements have not been clearly defined or the technology is experiencing high defect rates," he explains.

Coakley notes that falling behind schedule frequently derails traditional waterfall projects. "One of the reasons the Agile approach is so popular now is that organizations feel they can avoid those types of problems via the daily scrum, where issues are brought up to the project team on a daily basis and plans to mitigate those issues are implemented swiftly," he says.

In many cases, a compromised schedule launches the project into an unrecoverable death spiral. "I've never seen a project that was significantly behind [schedule] ever get back on track, but partial success can be met by scaling back the original scope or moving in a different direction than was originally planned," Gfesser says. "Both avenues of which are enabled by Agile methodologies."

Is project recovery possible? 5 key questions

1. Have there been any internal or external changes that could be hurting the project?

Recent business, market or technology developments may be adversely affecting the project's framework and goals. The plan may need to be redesigned to accommodate these changes.

2. Should we reduce our goals to a more realistic level?

Initial overly optimistic projections may have to be scaled back to reflect real world conditions.

3. Is our current project team working together as effectively as possible?

Team dissention may be pulling the project down. Now is the time to either resolve these problems or to shake up the team by adding and/or losing members.

4. Why are we falling behind schedule and is there anything we can do about it?

A period of introspection and revised planning can help get a lagging project back on track.

5. Who can we call in to help us?

A project outsider might be able to detect problems that team members are too involved to see.

When and how to kill a failed project

Projects can occasionally be rescued by seeking an outside perspective provided by a knowledgeable individual with no personal stake in the project's success or failure. "Some failing projects create massive amounts of acrimony between departments," Coakley says. "Somebody who can be deemed as relatively impartial may be able to offer some fresh perspectives that might be able to identify some issues the in-house players are blind to."

Yet, there eventually comes a time when all the effort an organization can muster can't save what has become a doomed project. That's the day when management and project team members finally agree that pulling the plug is the only logical way of ending the mess.

"The kill decision ... needs to be done by the executive sponsor," Williams says. Some organizations hand the task over to a steering committee, an auditor or even the CIO, but Williams believes that these parties generally lack the accountability and authority necessary to make such an important decision. "The executive sponsor is the only person who can fit those requirements," he says.

Actually shutting down a project is like ripping off an adhesive bandage. "Slowly pulling off the Band-Aid does not make it better, it just prolongs the pain," Zucker says. "It is better to get people to new assignments rather than letting them languish."

Learning from IT project failures

The school of hard knocks is renowned for its punishing coursework, yet CIOs and other IT leaders can take heart in the fact that failed projects often generate hard-earned lessons that can be used to help prevent future fiascos. "Failure is not necessarily a bad thing, because it can lead to a more successful project by understanding what doesn't work," Gfesser explains.

"The key is to identify the weak areas, vet why they were problematic, and work on ways to avoid them the next time," Coakley says.

"Small, quick failures should be acceptable," Zucker concludes. "But, when we have huge catastrophic failures it is because we have organizational and cultural issues that prevent us from recognizing, or hearing, what is actually happening on our projects."
Source: mavenlink