Conrad Weisert, September 27, 2007
©Information Disciplines, Inc.
NOTE: This document may be circulated or quoted from freely,
as long as the copyright credit is included.
Trade journal articles and conference presentations claim that 31% (or some other figure) of all system development projects are cancelled before they're completed. They present that as a scandalous indictment of the state of our ability to plan and carry out a project, and often go on to present some new methodology that's expected to prevent such failures.
That's naïve. A project that's cancelled in an early phase should usually be thought of as a success.
Suppose you've approved a system development project that's estimated to cost $600,000 and be finished in 18 months. For 16½ months you'veļapproved been getting weekly status reports showing that satisfactory progress is being made and confirming the budget and target date. But now you're told that, due to unexpected obstacles, the project team needs another three months to finish the project and will consume additional funding of $50,000. The project manager is confident of the team's ability to meet the revised schedule and budget. You've already spent $560,000.
Do you authorize the additional funds?
Workshop exercise from course PM-01
What choice do you have? Can you kill the project, admitting that you've just wasted over a half million dollars? Should you demand a re-analysis of costs and benefits? Hardly. What would you do with the results? You're helpless, forced to go along with the overrun, and you hope it's the last one.
Tough-minded managers sometimes call that situation "The Vietnam War Syndrome". The fact that we've invested all that effort forces us to keep going even if a rational analysis tells us that we should stop. When the slippages and overruns are repeated several times, we say that the project is "out of control".
That's the situation the phased life-cycle was designed to avoid. Instead of optimistic weekly status reports you get concrete deliverables at the end of each phase. And the phases, especially the early ones, are short, requiring a modest commitment of resources.
If the project in the above problem had followed a life-cycle with a phase-limited commitment you would have faced rational decision points long before wasting a half million dollars. If the deliverables had been disappointing or if the schedule had badly slipped in the early phases, you could have killed (or drastically restructured) the project without risking career-ending embarrassment.
When you propose to abort a project, especially in the later phases, you'll encounter opposition from almost everyone: from the sponsoring user community, from management, and from the developers. "We must stay the course"1 they advise.
When you hear that phrase, you can be sure that things have gone horribly wrong. The project may be out of control or the justification may have evaporated, but stubbornness and ego can get in the way of rational decision making. Whenever I've heard that phrase, it has always indicated that the effort is way beyond salvaging. If you hear it, assume that you're in big trouble.
Painful though it may be, we may sometimes be faced with canceling a project in the later phases. No matter how much money has already been spent, management must confront project justification unemotionally. I once inherited a business application project well into the programming phase, only to discover that the cost of processing each transaction would exceed the average profit resulting from that transaction. Abandoning the project was unthinkable to the user organization's management; that system was installed and operated for many years.2
When we have to decide whether to cancel or continue a project, we should ignore the past. The decision affects the future starting now. It may be embarrassing to admit that things haven't gone well, but to conceal such facts is never in the best interest of an organization.
2 — Falling hardware prices may have eventually cushioned the fiasco.
Last modified September 28, 2007
Return to IDI home page
Project management material.