Software failure statistics are abundant and serve as clear evidence that we must reform software development. While industry claims an IT labor shortage is the motivating force behind outsourcing, the greatest factor is directly related to our inability to deliver value-add software. As organizations continue to lose faith in IT as a trusted partner, the services we offer are little more than an ample commodity, and the search for cheaper labor will persist. But, there is no IT labor shortage.
We fail for many reasons. But mostly, it’s of our own accord. The original CHAOS report, published by The Standish Group in 1994, supports the claim that the primary impediment to successful software delivery surrounds requirements. Since the publication of that report, more evidence has emerged to support its findings:
- 35 percent of requirements change throughout the software lifecycle (Jones, C. 1997. Applied Software Measurement. McGraw Hill.)
- 45 percent of delivered features are never used. (Johnson, J. 2002. Keynote speech, XP 2002, Sardinia, Italy.)
- 82 percent of projects cited incomplete and unstable requirements as the number one reason for failure. (Thomas, M. 2001. “IT Projects Sink or Swim.” British Computer Society Review.)
- Large projects, those costing more than $10 million, are successful exactly zero (0) percent of the time. (Johnson, J. 1999. “CHAOS Into Success.” Software magazine.)
Unfortunately, many organizations attempt to rectify this situation by applying traditional software development techniques that emphasize early requirements elicitation and stabilization, followed by the other phases of the SDLC excecuted serially. While a noble goal, it is not possible to stabilize that which is inherently unstable. Experience has also shown me that many process improvement efforts result in little more than a varied manifestation of the same flawed processes that have plagued the software industry for decades. Yes, I put that in bold type for a reason – in many cases, we attempt to solve the problem using solutions that directly contribute to the problem.
Clearly, to improve software delivery, a more nimble and adaptive approach is required. Returning value to IT requires shedding the flawed processes of yesterday, and introducing methods that create greater alignment between IT and business by promising incremental delivery of functional software. Obviously, you see where I’m going with this, but the details will have to wait for another day. Instead, I want to point out some alarming failure statistics.
- After five years and $26 million dollars, the University of Wisconsin System discontinued implementation of a system-wide payroll and benefit initiative.
- The Department of Workforce Development recently canceled the EnABLES project. Overall, $23.6 million was spent on the project, including approximately $10 million on the phase II appeals system that was never completed.
- Wisconsin is attempting to recover $2.1 million after a failed Oracle-based e-mail installation.
- In 2005, after spending more than $170 million, the FBI canceled development of it’s Virtual Case File (VCF) without deploying it.
- The Software Hall of Shame shows other startling statistics.
I can promise there are many other examples of failure with equally staggering numbers. Why do we fail? In the case of the VCF, failure was the direct result of poorly defined and evolving requirements and overly ambitious schedules.
Obviously, our current approach is not working. In an era where IT services are viewed as an easily obtainable commodity, the onus is on IT to earn back the trust of our business partners. To do so requires a more adaptable and nimble approach to software delivery that results in more innovative use of technology. I’m a firm believer that increased development agility is the fundamental element in software development reform.