The six categories of failed IT projects
December 16, 2009, 12:34pm PST | Length: 00:03:35
There are lots of reasons why two-thirds of all IT projects fail, but most of the time it doesn't have much to do with the technologies involved.
Jason Hiner: There are lots of reasons why about two-thirds of all IT projects fail, but most of the time it doesn't have much to do with the technologies involved.
I'm Jason Hiner, and this week on CIO Sanity Savers, we'll look at the six categories of project failure, based on some great insights from project management experts Michael Krigsman and Michiko Diby. Stay tuned.
A lot of what causes IT projects to fail are errors in executing those projects. In order to help pinpoint the root issues involved so that they can be discussed and dealt with, project management guru Michiko Diby has suggested six categories of failures that bring down most projects. So here they are:
1. Intent failure - This is when a project just doesn't have enough value to overcome the hurdles that are a natural part of the project management process. This suggests that the intent of the project was flawed from the very beginning.
2. Sponsor failure - You see this when the person leading the project loses interest, gets distracted, and is not actively engaged. Another scenario is that the project leader doesn't have the authority to make decisions that are critical to the project's success.
3. Definition or scope failure - When the scope of a project is not clearly defined, the project team eventually becomes unclear on the deliverables that they need to produce and so they waste their time or dissipate their efforts.
4. Communications failure - This happens when communications are infrequent or an HONEST discussion of the project's problems and issues are either delayed or avoided altogether.
5. Project discipline failure - When standard processes and project methodologies are allowed to lapse, it's easy for even the best projects to go off the rails.
6. Supplier or vendor failure - You'll typically see this when the structure of supplier or vendor relationships are too rigid and do not allow for adjustments or plan for regular communication.
To go deeper on this topic, see Michael Krigsman's article that this episode is based on as well as Diby's article that goes further in-depth to offer some questions you can ask up front to help overcome these failures. Both are linked in the blog post for this week's show.
I'm Jason Hiner, and this has been an episode of CIO Sanity Savers. For more, you can find my blog at hiner.techrepublic.com and you find me on Twitter at twitter.com/jasonhiner. Thanks for watching. See you next week.