ComputerWorld offers a ten-point prescription for rescuing a failed project. From the article:
Denial can also come into play. “You don’t want to admit it, so you don’t go into the stage of reassessing the project,” says Dan Demeter, CIO at Los Angeles-based Korn/Ferry International.
It’s often up to the project sponsor to decide whether a project is stumbling enough to warrant a reassessment.
“Most projects go bad because they’ve been overcomplicated,” says Jim Lester, senior vice president of global technology strategy at Aflac Inc. in Columbus, Ga. “You get caught up in ‘requirement rush.’ You continue to add requirements, and it gets so complicated, it’s like a duck-billed platypus. The project team can’t figure out what they’re building. They can’t see it in their mind’s eye.”
If the project is still alive, the evaluator should consider the new requirements against the team’s performance, skills and interpersonal dynamics. He should spend time with every team member to get a feel for what goes on behind the scenes.
There’s some pretty good advice in the article. Here in project failure-land, that’s pretty unusual.