The Long, Dismal History of Software Project Failure

May 15, 2006

From the IEEE article Why Software Fails:

Last October, for instance, the giant British food retailer J Sainsbury had to write off its US $526 million investment in an automated supply-chain management system. Merchandise was stuck in the company's depots and warehouses and was not getting through to many of its stores. Sainsbury was forced to hire about 3000 additional clerks to stock its shelves manually.

This is only one of the latest in a long, dismal history of [software] projects gone awry. Most IT experts agree that such failures occur far more often than they should. What's more, the failures are universally unprejudiced: they happen in every country; to large companies and small; in commercial, nonprofit, and governmental organizations; and without regard to status or reputation. The business and societal costs of these failures -- in terms of wasted taxpayer and shareholder dollars as well as investments that can't be made -- are now well into the billions of dollars a year.

The problem only gets worse as IT grows ubiquitous. This year, organizations and governments will spend an estimated $1 trillion on IT hardware, software, and services worldwide. Of the IT projects that are initiated, from 5 to 15 percent will be abandoned before or shortly after delivery as hopelessly inadequate. Many others will arrive late and over budget or require massive reworking. Few IT projects, in other words, truly succeed.

From Rapid Development:

If Las Vegas sounds too tame for you, software might just be the right gamble. Software projects include a glut of risks that would give Vegas oddsmakers nightmares. The odds of a large project finishing on time are close to zero. The odds of a large project being canceled are an even-money bet (Jones 1991).

In 1998, Peat Marwick found that about 35 percent of 600 firms surveyed had at least one runaway software project (Rothfeder 1988). The damage done by runaway software projects makes the Las Vegas prize fights look as tame as having high tea with the queen. Allstate set out in 1982 to automate all of its office operations. They set a 5-year timetable and an $8 million budget. Six years and $15 million later, Allstate set a new deadline and readjusted its sights on a new budget of $100 million. In 1988, Westpac Banking Corporation decided to redefine its information systems. It set out on a 5-year, $85 million project. Three years later, after spending $150 million with little to show for it, Westpac cut its losses, canceled the project, and eliminated 500 development jobs (Glass 1992). Even Vegas prize fights don't get this bloody.

The history of software development is a tremendous success. Just look around you for evidence of that. But that success has a long, dark shadow that we don't talk about very much: it's littered with colossal failures. What's particularly disturbing is that the colossal failures keep recurring year after year. The names and dollar amounts may change, but the story is otherwise the same. Two recent examples are the Canadian gun registry and the FBI's Virtual Case File system.

If you're looking for more examples of colossal software project failure, you don't have to look very far:

• Software Hall of Shame (from IEEE article Why Software Fails)
• History's Worst Software Bugs (Wired)
• Software Horror Stories (Nachum Deshowitz, Tel Aviv University)
• Forum on Computer Risks (ACM moderated mailing list)
• Failure Rate (collection of failure rate statistics from IT surveys)

You'd think that the software development industry would have matured over the last ten years. And it has:

The 10th edition of the annual CHAOS report from The Standish Group, which researches the reasons for IT project failure in the United States, indicates that project success rates have increased to 34 percent of all projects. That's more than a 100-percent improvement from the success rate found in the first study in 1994.

Asked for the chief reasons project success rates have improved, Standish Chairman Jim Johnson says, "The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward."

The Standish Group has studied over 40,000 projects in 10 years to reach the findings.

Project failures have declined to 15 percent of all projects, a vast improvement over the 31-percent failure rate reported in 1994. Projects meeting the "challenged" description -- meaning that they are over time, over budget and/or lacking critical features and requirements -- total 51 percent of all projects in the current survey.

Failing is OK. Failing can even be desirable. But you must learn from your failures, and that requires concerted postmortem introspection and analysis. I'd like to think that a large part of the statistical improvement cited above is attributable to sharp project managers and savvy developers who studied the first CHAOS report. Once you know what the common pitfalls are, it's easier to avoid them.