Projects: Succeeded, "Challenged," Failed

The Standish Group have done numerous studies of software project success and failure rates over the last 10 years. They've observed some trends in project management suggesting things are marginally improving out there.

In 1995, their report identifies these key factors and associated weights contributing to project success:

SUCCESS CRITERIA	POINTS
1. User Involvement	19
2. Executive Management Support	16
3. Clear Statement of Requirements	15
4. Proper Planning	11
5. Realistic Expectations	10
6. Smaller Project Milestones	9
7. Competent Staff	8
8. Ownership	6
9. Clear Vision & Objectives	3
10. Hard-Working, Focused Staff	3
TOTAL	100

As you can see in the graphic below, in 1994 the the success rate for projects was only 16%, while "challenged" projects (over time and cost) accounted for 53%, and failed (canceled before completion) accounted for 31% of all projects. In 1998, 26% were successful. Then in 2004, we reached a 29% success rate. Project costs are higher and the success rates are lower for larger companies.

The 1995 piece has a scorecard to apply to your project to help you assess your potential for success. They're good questions (but a little intimidating even in 2006).

The 1999 report is quite sobering; they suggest that project size, team size, and project duration are the major factors correlated with success. They identify project management and standard infrastructure as crucial factors for team success. (Their comments on project management are well worth looking at, too, including the role of mentoring project managers.) I am quite sure that Scott Berkun would agree with them.

In 2001's report, they state that executive sponsorship replaced user involvement as the number one critical factor, because the IT world had caught on to the user involvement philosophy. Staunch business and management support now trump requirements analysis and user review of product design.

Finally, here is a telling quote about written communication on projects, from their original article:

Achieving the answers to solving project failure often lies in developing written communication such as problem statements, project plans, and detail specifications. However, one of the problems with any written communication is the participant's (reader's) level of understanding. As technologists, we think, write, and talk in a manner that is not readily grasped by many people outside our industry. Aside from sounding intimidating, you run the danger of the reader actually thinking they understand what you are saying, while your meaning may in fact be entirely different. To paraphrase the words of the English poet, Samuel Taylor Coleridge "Until you understand a reader's ignorance, presume yourself ignorant of his understanding". In other words, write the document devoid of all technical terms and pseudo technical terms. This includes words used by our industry, but rarely used outside our industry. Words like paradigm, metric, abstraction, and orthogonal, should not be used in any document if you want the normal reader to understand. Remember it is your job make the reader understand the plan. It is not your job to show how smart you are or to demonstrate that you can use big words.

Sadly, "phenomenological" is probably not a good word to put in a spec either.