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?
1. Buy Versus Build Why Companies Should Never Build Software
2. Introduction <ul><li>Corporate America spends more than $275 billion covering about 250,000 in-house application software development projects </li></ul><ul><li>Unfortunately, this is an area of business where success is rare and failure is the norm </li></ul>
3. Project Definitions <ul><li>Successful Projects – The project is completed on time and on budget, with all features and functions as originally specified. </li></ul><ul><li>Challenged Projects – The project is completed and operational, but over-budget, over the time estimate and with fewer features and functions than initially specified. </li></ul><ul><li>Failed Projects – The project is cancelled before completion. </li></ul>
4. Project Resolution History Source: The Standish Group. Used by permission.
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
6. Success by Project Size Source: The Standish Group. Used by permission.
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
8. Buy or Build? Never build. Always buy.
9. Recommendations When Buying Software <ul><li>Buy a mature application that has been on the market for at least three years and adapt it to your purpose, running it on equipment you already own </li></ul><ul><li>Never buy a 1.0 or even 2.0 version if at all possible </li></ul><ul><li>The name of the vendor doesn’t matter as long as its been on the market 3 years and has significant market share </li></ul><ul><li>If off-the-shelf applications still won’t work, consider outsourcing, especially Web-based applications suites </li></ul>
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. Sources <ul><li>Inc Magazine – What’s Next: Software for Non-Dummies by Robert X. Cringely </li></ul><ul><ul><li>www.inc.com/magazine/20030201/25103-print.html </li></ul></ul><ul><li>The Standish Group – The CHAOS Report (1994) </li></ul><ul><ul><li>www.standishgroup.com/sample_research/chaos_1994_2.php </li></ul></ul><ul><li>The Standish Group – The CHAOS Report (1998) </li></ul><ul><ul><li>www.standishgroup.com </li></ul></ul>