Software Development Failure

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.

3 thoughts on “Software Development Failure

  1. As an employee of an organization undergoing a huge business transformation prompted by the implementation of a new software package that the business will be entirely base upon, this hits very close to home. I’m not sure of the entire budget, but saying it’s over $25 million is probably safe. We are currently in the “requirements” phase. With a final implementation date of Q2 2009. Which I suspect will end up as Q4 2009.

    The interesting part is that this can’t be a failure. Or a failure in the sense that they will continue with their current processes. Since that might be to the detriment of the entire business itself. Therefore, this will continue on with an end result being…??? That’s anyones guess.

    But, I’m happy to say that next week is my last week here. I’m moving on to an organization with 2-6 week delivery cycles. Which, from what I hear, the business is very happy with. Results that can still be measured against the original requirements while the ideas are still relatively fresh in the minds of the people that originated them. What a concept huh?

    After 25 years in this industry, I’m still amazed that there are those that can’t learn from the mistakes of the thousands that have come before them. 0% of large projects succeed?? What does it take to understand that? I bet if I pose that question to my two sons, ages 7 & 9, they’ll have an answer. Change what you are doing, Dad.

  2. It is strange to look at the answer of organizations struggling with run away projects. Instead of taking a strong look in the mirror, typically either:

    1. Blame some/all of the team, or
    2. Write it off

    Never looking at the very methodology/approach for delivery. The second angle is worse as it drives the focus on cost for the org (i.e. they aren’t getting anything for the spend so the Cx0’s have to ponder why spend at all).

    Even large scale system swap outs can be achieved in a more ‘chunking’ fashion .. if they think about it hard enough.

Leave a Reply

Your email address will not be published.