# THE STANDISH GROUP - CHAOS

[https://iclass.tku.edu.tw/course/146893/learning-activity/full-screen#/584383](https://)
For purposes of the study, projects were classified into three resolution types: -

- Resolution Type 1, or project success: The project is completed on-time and on-budget,
with all features and functions as initially specified.

- Resolution Type 2, or project challenged: The project is completed and operational but
over-budget, over the time estimate, and offers fewer features and functions than
originally specified.

- Resolution Type 3, or project impaired: The project is cancelled at some point during the
development cycle.

Overall, the success rate was only 16.2%, while challenged projects accounted for 52.7%, and impaired (cancelled) for 31.1%.
## Restarts
One of the major causes of both cost and time overruns is restarts. For every 100 projects that
start, there are 94 restarts. This does not mean that 94 of 100 will have one restart, some
projects can have several restarts.

## Cost Overruns
For combined Type 2 and Type 3 projects, almost a third
experienced cost overruns of 150 to 200%. The average across all companies is 189% of the
original cost estimate. The average cost overrun is 178% for large companies, 182% for
medium companies, and 214% for small companies.

| Cost Overruns | % of Responses |
| -------- | -------- |
| Under 20% | 15.5% |
|21 - 51% | 31.5% |
| 51 - 100% | 29.6% |
|101 - 200% | 10.2% |
|201% - 400% | 8.8% |
| Over 400% | 4.4% |

## Time Overruns
For the same combined challenged and impaired projects, over one-third also experienced time
overruns of 200 to 300%. The average overrun is 222% of the original time estimate. For large
companies, the average is 230%; for medium companies, the average is 202%; and for small
companies, the average is 239%

| Time Overruns | % of Responses |
| --- | -------------- |
| Under 20% | 13.9% |
| 21 - 51% | 18.3% |
| 51 - 100% | 20.0% |
| 101 - 200% | 35.5% |
| 201% - 400% | 11.2% |
| Over 400% | 1.1% |

## Content Deficiencies
For challenged projects, more than a quarter were completed with only 25% to 49% of
originally-specified features and functions. On average, only 61% of originally specified features
and functions were available on these projects. Large companies have the worst record with
only 42% of the features and functions in the end product. For medium companies, the
percentage is 65%. And for small companies, the percentage is 74%

| % of Features/Functions | % of Responses |
| -------- | -------- |
| Less Tan 25% | 4.6% |
|25 - 49% | 27.2% |
| 50 - 74% | 21.8% |
|75 - 99% | 39.1% |
|100% | 7.3% |

## Focus Groups Comments

- "Being that it's a mindset, it's very difficult to get all of the management -- it's even on the local level, not even on a worldwide level -- to get all of the management to agree on a set of rules.... That's a challenge in itself because you have to, in some cases, convince them that this is best for the company, not necessarily best for them, but best for the company. And you have to have that buy-in. If you don't have that buy-in, you're going to fail. I don't care how big or how small the project is.

*Jim, the Director of IT at a major medical equipment manufacturer*

- Probably 90% of application projectfailure is due to politics!"

*John,Director of MIS at a government agency*

- "Sometimes you have to make a decision you don't like. Even against your own nature. You say well, it's wrong, but you make that decision anyway. It's like taking a hammer to your toe. It hurts."

*Kathy, a programmer at a telecommunication company*

- "Changes, changes, changes; they're the real killers."

*Bill, the Director of MIS at a securities firm*

- "Brain-dead users, just plain brain-dead users,"

*Peter, an analyst at bank*

- "We just had a reorganizationtoday. So now that's going to sap all the resources. And explaining to senior management that,'Well, it's really taking us the time we said it was going to take. But because you've reorganized the company, I'm going to take another six months on this other project, because I'm doing something else for you.' That's the biggest issue I have."

*Bob, the Director of MIs at a hospital*

- "When the projected started to fail,the management got behind it -- way behind."
*Paul, a programmer at a personal products manufacturer*

- "The project was two years late and three years indevelopment,We had thirty people on the project. We delivered an application the user didn't need. They had stopped selling the product over a year before."
*Sid, a project manager at an insurance company*

## The Bridge To Success
Research at The Standish Group also indicates that smaller time frames, with delivery of
software components early and often, will increase the success rate. Shorter time frames result
in an iterative process of design, prototype, develop, test, and deploy small elements. This
process is known as "growing" software, as opposed to the old concept of "developing"
software. Growing software engages the user earlier, each component has an owner or a small
set of owners, and expectations are realistically set. In addition, each software component has a
clear and precise statement and set of objectives. Software components and small projects tend
to be less complex. Making the projects simpler is a worthwhile
endeavor because complexity
causes only confusion and increased cost.

There is one final aspect to be considered in any degree of project failure. All success is rooted
in either luck or failure. If you begin with luck, you learn nothing but arrogance. However, if you
begin with failure and learn to evaluate it, you also learn to succeed. Failure begets knowledge.
Out of knowledge you gain wisdom, and it is with wisdom that you can become truly successful.