CA Community






Understanding Project Failure Rates

Published: May 04 2009, 08:39 AM
by Steve Romero

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

Share this post:  

 

By: Steve Romero
Steve Romero is the IT Governance Evangelist at CA Technologies, Inc. His mission is to help enterprises realize the full potential of their IT investments for strategic and competitive advantage. In this capacity, he acts as a strong advocate for the customer, speaking around the world to users, prospective...
Read More..

3 people have left comments:

Hi Steve:

I had recently written about the Standish CHAOS 2009 report (see: Failure is Not an Option" at douglevitt.blogspot.com/.../failure-is-not-option.html).

Without a doubt, the results are a blemish on our profession.  After all, we (as Project Managers) are accountable for project success.

With that being said, I wonder whether all "Challenged" projects should be classified as failing.  In my experience, the requirements for many software development projects are not known at the level of detail necessary for good estimation at the onset of a project (even when variance thresholds are taken into account).

Does the Standish Group take into account "approved Scope Changes" when determining whether a project is successful or challenged.  Remember, a Scope Change can occur at any time during the project (say, a new customer requirement is introduced that was not part of the original scope).  Oftentimes, such changes impact one or more of: scope, schedule, resources.

As an example, several years ago, I worked on a project where the originally approved scope was inherently flawed and we altered (that is, increased) the original requirements by more than 100%.  The project took longer and cost more than originally defined.  But we successfully delivered on time based upon the altered scope.  And, it led to the company's largest deal in its history.

By the way - I love your webinars.  Keep up the good work.

Best,

Doug Levitt, PMP

LinkedIn: www.linkedin.com/.../douglevitt

Posted by: Doug Levitt | June 16, 2009 8:15 PM

I am constantly asked about my definition of project failure, which I frankly applied to the Standish "challenged" category. I admit, my definition is sometimes thought of as being too harsh. I attempt to assuage this opinion by clarifying my "if it is late / if it costs more / if it does not deliver as necessary" comments:

- I allow for deviations in any of these categories when the thresholds for such deviations are specifically identified at the onset of the effort. This allows for just the evolution or maturation of requirements in those instances you note - when a project is accepted and initiated in spite of incomplete or yet-to-be-defined requirements. I actually suggest more lenient thresholds for less mature organizations with the expectation that said thresholds will be reduced as the organization's program and project methodology matures.

- I also allow for "reviewed and appropriately authorized/accepted changes in any of the 3 categories. I am assuming that these changes are only approved because the enterprise has taken the steps to ensure appropriate value will be delivered in spite of, or even due to, the change.

I can't speak for the Standish group. I think they are a "softer" than I in given they have the 3rd "challenged" category. I am much more black and white when it comes to what constitutes project success and project failure.

Thanks for the comments Doug and please stay in touch.

Steve

Posted by: Steve Romero | June 16, 2009 10:51 PM

Read this report on IS Project Failure by UK Professors Dr John McManus and Dr Trevor Wood-Harper

Research highlights that only one in eight information technology projects can be considered truly successful (failure being described as those projects that do not meet the original time, cost and (quality) requirements criteria).

www.bcs.org/server.php

Posted by: Kerry Gladwell | April 4, 2010 7:27 AM

Leave a Comment

* An asterisk indicates a required field

* :  

:

* :  

 Submit