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.

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


Previous Page  1  2  3  4 

Sign up for CIO Asia eNewsletters.