The Standish Report is the basis and many discussions how why software projects fail and of course the proposed new methods needed to prevent these failures. Robert Glass' IEEE Computer column in the May/June 2005 issues asks many of the questions I've asked in the past about the approach and data of the Standish Report:
- What's the definition of failure or success? - There are very vague definitions in both categories. Failure to meet a budget target by how much? 10%, 100%? What if the original budget target was rebaslined (something that happens all the time in aerospace)? Is the project a budget failure or is the rebudgeting a recognition of the importance of the project and the additional funds.
- How is the sample of failed projects chosen? The GAO study of failed selected projects that were already on the road to failure.
Simula Research Center papers report significantly different numbers than the Standish Report.
I'm currently involved in an ERP system roll out as the basis of an Enterprise Services initiative. Enterprise Services is a project type that consolidates the core business processes across several divisions of a company. Finance, Human Resources, Procurement, Facilities and IT become "common" across all business units. The schedule and budget for this effort was planned before the detailed scope of work was well understood. This is not only common, it is likely the only way to execute on the project. The myth that we can forward plan a complex and evolving project actually requires precognition by the project team.
Robert Austin's approach to ERP is the treat the project as a venture capital project, where funds are allocated against specific returns in benefit on an incremental basis. So what numbers can we believe regarding the percent of project failures: 70%, 30%? It's not really possible to tell given the current approach of asking scalar type questions. Here are some questions I'd ask:
- How far Over Target Baseline for the budget (OTB is the DoD EVMS term) did the project go before re-baseline authorization was required?
- Was the re-baseline authorization approved? If so was the benefits stream re-baselined as well?
- How far Over Target Schedule did the project go before a re-baseline authorization was required?
Those two questions could be used to select projects as failure candidates. Once that population was collected assessment of the reasons for failure could be examined. Otherwise the population of failed projects includes those whose schedule and budget over ran for a correct and authorized reason.
