Recipe for Project Success: The CHAOS Top Ten
In the Standish Group’s 2011 CHAOS report, 37% of projects were described as successful – on target, on time, on budget. Here are ten reasons why more than half of software projects failed.
1. Executive support. Traditionally, executive support occupied the No. 2 spot; however, it is now the No. 1 factor in project failure. Executive support influences a project’s process and progress. Lack of executive input can jeopardize a project.
2. User involvement. Lack of user involvement traditionally has been the No. 1 reason for project failure. Conversely, it has been the leading contributor to project success. Even when delivered on time and on budget, a project can fail if it doesn’t meet user needs or expectations. However, this year user involvement has moved to the No. 2 position. Despite how that may sound, user involvement hasn’t decreased in importance; it’s just that IT professionals have, in effect, solved this major problem.
3. Experienced project manager. Ninety-seven percent of successful projects have an experienced project manager at the helm.
4. Clear business objectives. This factor has moved down one spot because evidence shows that experienced project managers increase success rates.
5. Minimized scope. Wrapping up the top five is minimized scope. Time is the enemy of all projects, and since scope affects time, or project duration, they are linked. Clearly then, minimizing scope increases a project’s chances of success. Minimized scope has replaced small milestones. While these two factors are similar, the act of minimizing scope leads to greater success than does creating small milestones. Concentrating on the top five will result in 70 success points.
6. Standard software infrastructure. Requirements are in a state of constant flux, but infrastructure needs stability. The Standish Group’s research shows that 70% of application code is infrastructure. Some of this code is unique to the application; nonetheless, much of this code could be purchased from an infrastructure vendor.
By using standard infrastructure, the application development team can concentrate on business rules rather than on technology. Many application development projects fail not in stand-alone application development, but in existing application integration. Standard infrastructures can shortcut application integration.
7. Firm basic requirements. The word “basic” refers to base-level requirements. Creating minimal, obtainable base requirements and then developing those features will reduce the effect of change. Delivering minimal features allows users and executive sponsors to see quick results. As a result, project managers are better prepared to articulate the needs and priorities of the next project phase.
8. Formal methodology. This provides a realistic picture of the project and resources committed to it. And it results in steps and procedures the team can reproduce and reuse. It also enables the team to maximize consistency. And it incorporates lessons learned into active projects. The process encourages a go or no-go decision checkpoint. It also helps the project team proceed with a higher level of confidence, or halt or alter steps to fit changing requirements. CHAOS research shows that 46% of successful projects use a formal project management methodology, compared with 30% of challenged and failed projects. So, this factor should increase success rates by about 16%.
9. Reliable estimates. Systematic project estimating must be approached realistically, because estimating is just plain hard. Then add to that the difficulty of developing, purchasing, and integrating components into existing and packaged applications, and outside services. IT managers must use all their collective knowledge and experience to come up with estimates that reflect the true effort required.
10. Other criteria. In last place is a collection of other factors. These factors include small milestones, proper planning, competent staff, and ownership. In the past, each of these factors was given its own category.
Source: CHAOS, (1994, 2001) – http://www.standishgroup.com/
Are these still true in your projects? How would you rearrange the order?
James L. Haner