Why Do Systems & Software Projects Fail?

By: Warren S. Reid, Managing Director of WSR Consulting Group, LLC specializing in consulting and expert witness assistance in computer system turnaround, software projects, software failure, Internet and e-business failure, high-tech, and IT intellectual property matters. You can reach him by email wsreid@wsrcg.com and by phone (818) 986-8842.

In this new millennium, it is still true that approximately 29% of all large-scale systems projects are successful, 53% are challenged  (with average overruns of 84% in time, 56% in dollars and only providing 67% of the required functionality), and 18% are scrapped and written off altogether. Although these stats show a small improvement over the statistics from a decade ago, and even with all the reported advances in technology, methodology, and software development and implementation, this is a poor showing for the Information Technology Industry [Source: Standish Group “Chaos Reports”].

For the past 36 years I have been a computer systems consultant and computer crisis consultant, including 20 years as a large-scale systems project turnaround specialist and an expert witness in large-scale software and systems implementation failures in the United States, Canada, the Caribbean, Europe and Asia.  If I have learned one thing, it is the following:

  1. Virtually all systems failures stem from the same handful of root causes and lack of “-abilities” (e.g., cap-ability, respons-ibility, suit-ability, etc.). And this is true everywhere in the world!
  2. All parties in a large scale systems or software project failure or dispute typically share some of the blame, but with some bearing much more blame than others  for causing the failure(s) to happen, allowing them to happen, or being unaware that they are happening – with each party contributing anywhere from 0%-100% in each failure category.
  3. Many, if not most, of the problems (sand their causes) could have been avoided, mitigated, or managed if the parties followed a few simple, but not easy, rules. 
  4. Putting in proper project policies, procedures, resources, monitoring metrics, tools, and project team communications to address these root cause areas could have either: (1) allowed the project to be successful in the first place if they were implemented and used from the outset of the project, (2) been used to turn around a runaway project midway if not originally implemented.

    Alternatively, determining how and how much each party contributed to these root causes is extremely powerful in helping judges, juries, and arbitrators assess the comparative guilt of the parties in litigation or dispute resolution for failed systems.

I developed the chart below to summarize my findings regarding why systems and software projects fail. This chart has been published in several peer-reviewed scholarly journals with relatively few changes over the years because of the persistent applicability and relevance of these root cause failings through today.



#

Category:
the “-abilities”

He Said (Customer)…

She Said (Vendor, Integrator, Consultants, Outsourcers)…

1

Feasibility

System doesn’t work; Not what we wanted

You changed your minds; You don’t know what you want or need

2

Capability

You delivered limited functionality

You continually changed project scope

3

Compatibility

The system failed in the field & in production

You didn’t perform the required “business process reengineering” to make it work

4

Credibility

Your software, services & expertise were  oversold

You conducted your reference checks & due diligence; What didn’t you know?

5

Usability

No one can use system! Poor training

“Required staff” never came to primary  training or refresher training

6

Stability

The system is “fundamentally flawed”

We only need 2 more months to test/fix issues

7

Culpability

You never told us that! You gave poor advice!

You didn’t follow our recommendations; You changed/delayed making key decisions

8

Reliability

The system is full of bugs!

Bad data conversion/poor interfaces caused the problems. Systems always have bugs!

9

Responsibility

You failed as Systems Integration Project Manager (SIPM).

No! You failed as the SIPM. That role was not my job!

10

Availability

You baited, then switched! You provided unqualified, unstable, uncommitted staff, project manager(s), Steering Committee

No, you baited, then switched! You provided unqualified, unstable, uncommitted staff, project manager(s), Steering Committee

11

Suitability

You abandoned good Project Management & System Development Life Cycle (SDLC) methodologies

You were unwilling to comply with  agreed to, promised & necessary methodologies (to mistakenly save costs w. no associated risks)

More on Why Do Systems & Software Projects Fail?  2007 and Computer & Systems Failure Litigation

Disclaimer: The information contained in this article is for education purposes and to stimulate thought, discussion, and improvement. Each real life situation is different. Accordingly, every solution must be tailored (and in some cases heavily modified) to the specific situation at hand. Please seek appropriate professional advise before proceeding to use any of the ideas and materials contained in this article.

© Copyright 2006-2007 by Warren S. Reid.  All rights reserved.

For a detailed look at just how failures in these root cause areas and the lack of certain “-abilities” derailed large, real, mission critical projects, please link to:
http://www.wsrcg.com/Articles/itj0511_reid.pdf, and
http://www.wsrcg.com/Articles/ComputerandSystemsFailureLitigationQAI.pdf .

To review a PowerPoint slide show to help you learn more about implementing policies, methodologies, management philosophies, and tools to turnaround projects failing for these same reasons, please link to  
http://www.wsrcg.com/PDFs/CPRPRO.PDF .