September 6th, 2006
Ten Steps from Doom
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.
—–
Michael Krigsman is CEO of Asuret, Inc., a software and consulting company dedicated to reducing software implementation failures. Click here to discuss this post with him on Twitter. See his full profile and disclosure of his industry affiliations.
Subscribe to IT Project Failures via Email alerts or RSS.
