The IT Governance Evangelist

I recently recorded a podcast with Tim Jennings, Research Director with the Butler Group. The Butler group completed a study finding that 50% of IT projects fail. My brief discussion with Tim focuses on this issue and highlights best practices for guidance on implementing successful project management initiatives in IT organizations.

I find the topic of IT project failure rates interesting and compelling. I speak frequently on the topic, citing numerous studies with varying conclusions. The most optimistic figure I have encountered is 40% and the most pessimistic came from a major analyst study in 2006 that put the IT Project failure rate at 78%!

I thought the 78% number was a bit sensationalistic. I think the number is closer to 60%, which is still quite alarming. Regardless of the number, whenever I talk about the rate of project failures, I think it is necessary to define what I mean by project failure. I do so in the Podcast and was surprised to find that Tim Jennings and the Butler Group agreed with my characterization because, frankly, I thought I was being militant about the subject.

I contend if a project takes longer than we scheduled, it is a failure. If a project costs more than we said it was going to cost, it is a failure. If a project does not deliver the value we said it was going to deliver, then it is a failure. Keep in mind, I am allowing for the variance thresholds agreed upon at the onset of the project. If a project is not completed within those thresholds, it is a failure.

I have shared this view with countless people in my travels. I have found the majority of them find my definition of project failure to be too harsh and uncompromising. I am not surprised by their reaction. In fact, it is their reaction that provides some insight as to why so many IT projects fail in the first place.

We take for granted that IT projects take longer than we think they will. We expect them to cost more than we thought they would cost. It is not realistic to believe we can deliver everything we said the project would deliver. In fact, we have the reasons for this at the ready. Do any of these statements sound familiar?

• It is too hard to estimate the time and cost
• We didn't have enough time to plan
• IT projects are very complex and inherently unpredictable
• The customer didn't know what they wanted
• Our requirements process is terrible
• We don't have enough resources to get the work done
• Production emergencies adversely affected project progress
• We didn't have the information we needed
• Scope creep!!!

I am sure you have heard all of these and more. We have grown accustomed, if not complacent to IT projects taking too long, costing too much, and not delivering as expected. Couple that with the human tendency to wince at the word "failure" and it is easy to understand why people judge my interpretation of project failure to be too harsh if not outright unreasonable.

So how do we change the project failure rate? Anyone who has met me or read my blog knows my answer is good IT Governance and more specifically, good Project and Portfolio Management. Tim Jennings of the Butler Group offers some great insights and ideas so I urge you to listen to our podcast. But first, let's get everyone to agree on our definition of project failure. Let's call the slipped schedules, cost overruns, and missed deliverables what they are - failures. Only then will we aggressively and relentlessly pursue the solutions that will ultimately ensure project success.