The Standish Group report 83.9% of IT projects partially or completely fail
Last updated: August 29, 2024 Read in fullscreen view
- 02 Nov 2021 What is Terms of Reference (ToR)?
- 18 Oct 2021 Key Elements to Ramping Up a Large Team
- 03 Apr 2022 Microsoft Solutions Framework (MSF)
- 01 Oct 2020 Fail fast, learn faster with Agile methodology
- 14 Oct 2021 Advantages and Disadvantages of Time and Material Contract (T&M)
The original Standish report was published in 1994 and has been updated a number of times. Standish and other groups have published additional reports shedding more light on other factors with IT projects.
According to Standish only 16.2% of projects were deemed successful by being completed on time and budget, with all the promised functionality. A majority of projects, or 52.7%, were over cost, over time, and/or lacking promised functionality. That leaves 31.1% to be classified as failed, which means they were abandoned or cancelled.
It is useful to review the top factors found in each of the three project classifications.
The top five factors found in successful projects are:
- User involvement
- Executive management support
- Clear Statement of Requirements
- Proper planning
- Realistic expectations
These factors should be put on a checklist for anyone considering an IT project, whether large or small. While risk rises with size and complexity, even simple projects can fail if the participants do not have clarity on these five principles.
The top five indicators found in challenged projects are:
- Lack of user input
- Incomplete Requirements & Specifications
- Changing Requirements & Specifications
- Lack of executive support
- Technical incompetence
This list adds a few variables that didn’t show up in the first list, namely changing requirements and specifications, and technical incompetence – two more things to watch out for. If you see change orders coming out of a project, you can be assured the risk has risen substantially. Technical competence means you need to confirm the necessary skills and not just give elements of the projects to internal people because they are enthusiastic and seem bright.
All of the top factors found in failed projects include:
- Incomplete Requirements
- Lack of user involvement
- Lack of resources
- Unrealistic expectations
- Lack of executive support
- Changing Requirements & Specifications
- Lack of planning
- Didn’t need it any longer
- Lack of IT management
- Technical illiteracy
You could write a book with lots of interesting stories coming out of this list. For example, we worked with an organization where requirements were carefully reviewed in group sessions and documented. When the ERP implementation project began, ownership decided to include a second company with a totally different sales and manufacturing process. It went live but it was challenged by both time and cost. In another project one staff member boldly stated the new system was “going in over his dead body.” Executive sponsorship meant we just went up the ladder and the project proceeded without any more hostility.
Other projects start without complete requirements because the customer is too impatient to hit a certain date or won’t sit down long enough to confirm the details. Surprises don’t help anyone. If too many new requirements come up during the interviews or implementation phase, park them in the parking lot and come back to them in one or more future phases. You are better off getting the core system running well and then implementing incremental change.
About the Author | Armin Shahamati | Senior Software Engineer | Senior Software Engineer |