Published: April 28 2008, 09:46 AM | 3 Comment(s)
by Steve Romero

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.

Share this post:  Email

Share

Published: April 16 2008, 12:45 PM | no comments
by Steve Romero

I just finished studying an analyst report entitled "The State of IT Governance In North American and European Enterprises." You already know that almost anything about IT Governance excites me, with an analyst report about my favorite topic high on the list. But, while there was certainly a lot of compelling data in the report, I was left wanting more.

The study focused on 8 areas: Strategic Positioning, The Perception of IT In The Enterprise, Standardization, How IT Is Structured, IT Planning, Architecture and The Role Of R&D In IT, Managing Vendors, and Managing Projects.

While these areas do fall within IT Governance, what I was looking for was information on enterprise efforts to establish IT Governance, or enterprise progress in regards to IT Governance initiatives. I was interested in the 8 areas, but more interested in how they were managed as part of a larger IT Governance initiative. Were the enterprises surveyed even aware that these were the major areas of IT Governance? 

I continue to believe very few organizations adequately understand the nature and discipline of IT Governance. Until enterprises recognize the areas of the Forrester report as subsets of IT Governance, they have little chance of fully achieving the very specific goals, and realizing the very specific benefits, of IT Governance.

But I am hopeful that the day will come. And I am anxiously awaiting the next IT Governance analyst report in my inbox.

Steve Romero, IT Governance Evangelist

Share this post:  Email

Share