“Keeping you up to date with everything software engineering!”

Software Project Failure Rates, Are We Improving?

Project Management | October 05, 2004 | 1 comments

We always hear that the software industry has a very high failure rate but the question I ask myself is: “are we at least getting better?” The CHAOS Report has been published yearly since 1994 by the Standish group and its purpose is to research the reasons for IT project failure in the United States. In 1994 the Standish Group found that a dismal 16% of projects where considered a success… in 2004 34% of projects were considered a success. By just looking at those numbers I would say as an industry we deserve a tap on the back.

The report is only available if you purchase it from the Standish which we haven’t done. What have done though, with the help of google, is find articles that report and quote the official reports from different years. I am going to try to put it together for you here.

Summary of Results:

	1994	2000	2004
Success	16%	28%	34%
Challenged	53%	49%	51%
Failure	31%	23%	15%

The definition of a projects success and failure is defined differently by different people. The standish defines them as follows:

Success

The project is completed on time and on budget, with all features and functions originally specified.

Challenged

The project is completed and operational, but overbudget, late, and with fewer features and functions than initially specified.

Failure

The project is canceled before completion, or never implemented.

My major issue with the study is that I don’t see mentioned acceptance tests being part of the success criteria. A project can be under budget, delivered on time with all of it’s requirements but it does not mean that it will ever be accepted by the users. In this case I still consider the project a failure.

Let’s for argument sake conservatively assume that the results from acceptance tests have been steady over the past decade. That still means we have increased the success rate of projects by over a very impressive 100%.

So we at least now know that we are proceeding in the right direction. Now we have to learn from the successful projects. According to the 2000 Report the following, in order of importance, are the top 10 factors that lead to a successful project:

1. Executive Support
2. User Involvement
3. Experienced Project Manager
4. Clear Business Objectives
5. Minimized Scope
6. Standard Software Infrastructure
7. Firm Basic Requirements
8. Formal Methodology
9. Reliable Estimates
10. Other Criteria: small milestones, proper planning, competent staff and ownership

I know that this is not the list from the latest report but from what I gather the list has not changed much over the past decade expect for one or two of the criteria’s moving up or down a notch or two.

But to quote Standish Chairman Jim Johnson from the 2004 study:

“The primary reason [for project success] is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.”

No where on the list does it say that a choice of a specific programming language or the use of design patterns would increase the likelihood of a project being successful, not to say that it wouldn’t make a difference, it is just not on the top 10. The majority of the problems lie with project management and the link between the business heads and software developers.

So next time you have a long drown out argument with someone at work over which programming language you should use maybe you should consider putting it on the back-burner and focus on things that are up high on the list of things that contribute to a successful project.

As a strong believer of using good frameworks as a basis for development I am happy that “Standard Software Infrastructure” is sixth on the list.

Are you surprised with the results? Is the order of the factors that lead to the success of a project what you would of thought them to be? Would you add or remove something from the list?

Related Links:

• Article: Standish: Project Success Rates Improved Over 10 Years (2004 Results)
• Collaborating on Project Success (2000 Results)
• 1994 Report (PDF)
• Other Studies: Failure Rate: Statistics over IT projects failure rate

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

October 9, 2004 04:55 PM | David Di Giacomo commented:

I’ve just read “Peopleware : Productive Projects and Teams, 2nd Ed.” by Tom Demarco and Timothy Lister, and I would highly recommend it to any software engineer or project manager to perhaps have new perspectives (on things we probably knew all along), on why projects fail and what are the factors that make them succeed… but a review would be another topic…

The authors contend, though all the projects they analyzed, not one failure has ever been linked to the technology used. So I guess I’m not surprised by the statements made here, and it is refreshing to see that less projects seem to be failing as the years go by…

But the list hugely neglects what the authors of the book is trying to tell us: The social aspect of the project is paramount to its success…

• Having teams that work well together, teams the “gel” according to book terminology.
• Having a good work environment: no paging systems, phones that can switch instantly to voice mail if you don’t wish to lose your train of thought, adequate space and silence to allow work to flow uninterrupted, allowing workers to personalize their space, etc.
• Not having to deal with “micro-management”, the manager having some degree of trust in their staff..
• Building a community in the workplace so that employees form a solidarity among themselves, enjoy their work, give them pride in what they do… This will reduce turnover, and the enormous investment lost when a company is forced to train new people…

..and other various examples…

I would also modify the point about methodology into having “a formal, yet flexible methodology”. I find as I continue in engineering that most attempts to formalize something tend to introduce an unecessary amount of paperwork for the task at hand, and does not account for the fact that people work and think differently. I’m not against methodology, just wished some of it wouldn’t be so rigid.

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)