6 reasons your IT project was derailed

Michael Krigsman’s IT Failures Blog is a perennial favorite around the IT Knowledge Exchange office (who doesn’t love peering in on a good train wreck?), and so when he pointed  out Michiko Diby’s 6 Questions that Get at the Heart of Project Failure, I had a feeling it would be a worthwhile read.

Diby’s 6 points could prove quite handy when doing a perished project’s port-mortem, and Dilby even offers in depth looks at each of the categories:

• Intent Failure – Occurs when the project doesn’t bring enough addedvalue or capability to beat down the obstacles inherent throughout the process.  This suggests the original intent of the project was flawed from the beginning.
• Sponsor Failure – Occurs when the person heading up the project is not actively engaged and/or does not have the authority to make decisions critical to project success.
• Design and Definition/Scope Failure – Occurs when the scope is not clearly defined, so the project team is unclear on deliverables.
• Project Discipline Failure – Occurs when process/project methodology is allowed to lapse so that the mitigation factors inherent in the process are never used.
• Supplier/Vendor Failure – Occurs when the structure of supplier /vendor relationships doesn’t allow for communication and adjustments.

Communications Failure – Occurs when communications are infrequent or honest discussion of project problems and issues are avoided.

But while hindsight is a glorious 20/20, what would be really useful is a system for flagging these problems down before the latest initiative, with your name stamped boldly at the top, goes ingloriously awry.

More on IT project failures:

• Preventing Project Failures, Michiko Diby’s blog
• Michael Krigsman’s take on Diby’s six types of IT project failure
• 10 innovative ways to become a “lousy” project manager
• The Perils, Pitfalls, and Pluses of Project Management