Original Post Date: Monday, December 30, 2013

Unless you live under a rock, you are aware of the healthcare.gov rollout disaster.  While similar IT failures are regularly in the news, the high profile of healthcare.gov has really mainstreamed awareness of the fragility of many IT projects.  Check out this article entitled ‘The Worst IT project disasters of 2013’.  It details IT project failures such as:

  •  IBM’s failure to deliver on a payroll system project that could potentially cost taxpayers up to $1.1 Billion dollars US.  
  •  SAP’s failure to deliver satisfactorily on requirements for a massive payroll project on which the state of California has spent over $250 Million US since 2005
  •  Deloitte’s unemployment system creating problems with the successful managing of unemployment compensation in California, Maryland and Florida

And while the article points to the specific vendors as the root of the problem, it is safe to assume that the vendors may not completely agree and that the end customer may also have some culpability in the failure.  My mission here is not to judge either party but rather to take a minute to muse why in 2013 we continue to have these very public, very expensive failures to deliver software that meets requirements in a timely fashion.


In my quest to find an answer to this question I found myself reading the 2013 Chaos Manifesto  available at this link .  Each year the Standish Group takes a look at IT projects to identify what appear to be the success factors for project success and how important each of these success factors is in relation to the other factors identified.  Although this year’s report focused on smaller IT projects, the success factors identified should resonate across the software industry.  In general Standish has found that the changes of success for small projects are about 70% while large projects are 10 times more likely to fail than small projects.  Part of their recommendations are that large projects should be broken down into small projects rather than tackled all at once.


The factors identified in this report include (in order of importance):

  •  Executive management support  - the executive sponsor should be the most important person in the project with the target for success visibly on his or her forehead
  •  User involvement – projects where the user is not involved perform poorly
  •  Optimization – projects that are properly optimized and take advantage of technology and other methods to improve efficiency are more likely to succeed than those that don’t 
  •  Skilled Resources  - good people increase the chances for project success
  •  Project Management Expertise – good people in the project and process management seats increases changes of success.
  •  Agile processes  - application of agile processes enforces the notion of executive support and user involvement
  •  Less important but also mentioned….
    • Clear Business Objectives
    • Emotional Maturity of the project environment
    • Execution
    • Tools and Infrastructure

It is interesting to note that the same success factors were identified in the 2012 Chaos Manifesto  though the order of importance was slightly different. The first two items on the list (which were first two in 2012 as well) tend to lend credence to my earlier speculation that the end customers for the above mentioned project failures may have some culpability in the failures as well.


Maybe the Chaos Manifesto should be required reading for software contractors and their customers? 


What steps does your organization take to prevent IT Project failures?