When to kill (and when to recover) a failed project, on CIO, September 15, 2017. Also, available on: CIO NL, CIO DE, and Tech Mundo
..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.”
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
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.
When and how to kill a failed project
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
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.”