5. Overruns and Deficiencies Note: All figures are for projects that are either challenged or out-right failures except for ‘Content Deficiencies’, which only include figures from projects that are considered challenged. 26% 239% 214% Small 35% 202% 182% Medium 58% 230% 178% Large Content Deficiencies Time Overruns Cost Overruns Company Size
7. Project Duration, Team Size Affect Project Success Source: The Standish Group. Used by permission. 0% +36 +500 Over $10M 8% +24 +250 $6M to $10M 15% 18 40 $3M to $6M 25% 12 25 $1.5M to $3M 33% 9 12 $750K to $1.5M 55% 6 6 Less than $750K Success Rate Time (months) People Project Size
10. Why? “ Unless you are operating a software company, software should not be central to the way you view your business. It’s just a means to an end. And to be classed as truly successful, the means should be quietly efficient and as close to invisible as you can get.” -Robert X. Cringely in Inc Magazine, February 2003
11.
Hinweis der Redaktion
Underestimating project complexity and ignoring changing requirements are basic reasons why project fail.
The Standish Group classifies application development projects into one of three groups.
If 28% of software projects were complete successes in 2000, then 72% were at least partial failures. In 2003, if recent success and failure percentages apply, $63 billion in development costs will go down the toilet. For every 100 projects that start, there are 94 project-restarts. Does not mean that 94 out of 100 projects will have one restart, some projects can have several restarts.
A large company is defined as one that has greater then $500 million in revenue. A medium company is defined as having between $200 and $500 million in revenues. A small company is defined as having between $100 and $200 million in revenues. 30% of all challenged or failed projects experienced a cost overrun of between 150 and 200%. 30% of all challenged or failed projects experienced a time overrun of between 200 and 300%. More then 25% of challenged projects were completed with only 25 to 49% of originally-specified features and functions. Even though success rates increased and project costs decreased, challenged and failed projects are still the norm.
It is also interesting to note that, the larger the project, the lower the success rate. The more expensive the project becomes, the less likely its chance of success.
The smaller the team and the shorter the duration of the project, the greater the likelihood of success. Does not mean that companies should compress time schedules or reduce the number of resources of a large project.
Considering the fact that in-house projects have such a track record of failure, the questions of if companies should buy or build becomes clearer.
Why should companies buy software and customize it to their needs rather than building the entire building everything from scratch?