If an IT project is going to fail--and let's face it, a lot of them are--it's cheaper and easier if it fails quickly. Companies can save millions of dollars by failing fast, and the trick is to know how fast an initiative can be allowed to fail, writes Jonathan Feldman at InformationWeek.

There are a lot of forces in place conspiring to let IT projects drag on, including bureaucracy and the aura of credibility that a project gains the longer it's been around. "Projects start to attach themselves to the careers of certain managers, and there's a reciprocating effect: The projects take on a heightened importance among line-level staff," Feldman laments. "The project's sponsors damn the torpedoes and plow ahead, because the project simply must work. 'My name's on it!'"

Project managers are trained to plow ahead rather than acknowledge that an initiative was perhaps poorly conceived, under-supported or just plain wrong in light of new information. "The wheels of bureaucracy will eventually grind to the realization that the project is indeed a bad one--but not until the big investments have been made," Feldman writes.

There are five steps you can take to help put a doomed project out of its misery sooner rather than later. The first is to keep the focus on the business so that project managers have the necessary access to the organization's leadership when they need the go-ahead to kill a project.

Make sure you've defined the criteria for project failure, and make sure the executive sponsoring the project is involved in setting the criteria. Project managers need to know that their initiatives may reach a point at which they will be terminated.

Avoid letting managers get overly wrapped up in a project by making their assignments about programs rather than projects. While a project may be doomed, it doesn't have to mean an entire program is failing.

Come up with processes that are well-suited to rapid execution.

Finally, create a fail-fast atmosphere by continuing the conversation about a project after it has failed. "A frequent problem is to declare a failed project 'done,' stop the meetings, yank the funding, and move on," Feldman writes. "Declaring 'done means that everyone can go back to doing things the way they used to. And that means continuing to let misguided projects linger and run up costs. Learn from your mistakes and continuously share that knowledge."

For more:
- see Jonathan Feldman's post at InformationWeek

Related Articles:
IT projects 20 times more likely to fail than other business initiatives
Four signs that an IT project should be axed
Tech projects that have blown the budget (slideshow)