Do you know the project failure rate in your organization? To have any chance of answering this critical question, you first need to define and characterize project failure. How you define project failure?
You may recall a post I wrote a year ago titled "Straight Talk About Project Failures." http://community.ca.com/blogs/theitgovernanceevangelist/archive/2008/04/28/straight-talk-about-project-failures.aspx. I had just completed a podcast with Tim Jennings of the Butler Group. They had just published a study of project success rates and found that 50% of all projects were indeed failing.
I am revisiting the topic of project failure after reviewing the recently released Standish CHAOS 2009 Report Summary http://www.standishgroup.com/. In my last post, I provided the results noting the highest project failure rate in over a decade (according to Standish measurement methods). Once again, here is the summary:
- 32% Succeeded - delivered on time, on budget, with required features and functions
- 44% Challenged - late, over budget, and/or with less than the required features and functions
- 24% Failed - cancelled prior to completion or delivered and never used
Please note the 3 categories Standish uses to characterize project results: - Succeeded - Challenged - Failed. I'll get back to these categories in a bit.
The 2000 Standish CHAOS Report found 23% of projects failed. Each subsequent study (conducted every two years) had lower project failure rates, until this year's figure of 24%.
The Standish Group appropriately notes the cause for alarm, but some folks might actually be encouraged by this report. Why? Well, if they have been to any of my presentations they have heard me say that study after study conducted in the past 5 years found over 50% of IT projects are failing. In fact I tell folks I think the 50% figure is generous and I would put the failure rate at 60%.
Yes, the Standish Group looks at all projects, but the 24% figure should cause everyone to question the claims of all of these other IT project failure reports. If indeed the failure rate for all projects is 24%, then don't you think the IT project failure must be lower than 50%? Given these figures I find it hard to believe the IT project failure rate is SO much higher than non-IT projects.
But let's take another look at the Standish Report. Remember those 3 categories? They were Succeeded, Challenged and Failed. I think it is the Challenged category that provides the appropriate insight into true project failure rates.
Let's now revisit the podcast I did with Tim Jennings of the Butler Group last summer. That study found that 50% of IT projects were failing. The first question I asked Tim was how the Butler Group defined project failure. There were two reasons I started with this question. First, I would need to understand their definition to have any appreciation of their study's findings. Second, I wanted to compare their definition of project failure to my definition. Frankly, many folks with whom I have worked in the past thought I was being too hard on projects. Here is why:
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 was delighted to hear that the Butler Group applied the same criteria.
Now let's apply this definition of project failure to the Standish Report. If we do, we need to include the "Challenged" project in the failed category - which was 44% of all projects. The Butler Group definition of project failure would also include the Standish "Failed" category - which was 24% of all projects. Given this interpretation, the newest Standish CHAOS Report shows that 68% of all projects are failing.
2 out of 3 projects are failing! If ever there was a call-to-arms, this is it!
So I am curious about the project failure rates in your organization, though you may be quite hesitant to share the data. How about if you just let me if you are tracking project failure, and if so, how do you define it? Even better, if you are experiencing lower failure rates, please share your recipe for success. I am sure readers of this blog would greatly appreciate your insights.
In the meantime, this latest CHAOS report gives me even more incentive to continue my quest to help organizations reverse this intolerable if not inexcusable trend.
Steve Romero