IT projects

Project Failures: Black Swans and the Crack Spread Phenomenon

 

Why Your IT Project May Be Riskier Than You Think

I have recently stumbled across a very interesting article titled "Why Your IT Project May Be Riskier Than You Think" published by Bent Flyvbjerg and Alexander Budzier.

I am a big fan of professor Flyvbjerg and his work and as a result needless to say I read this article with great interest. The article describes the phenomenon called the "black swan projects" or as he puts it "high-impact events that are rare and unpredictable but in retrospect seem not so improbable". In other words, these are the endeavours that are vastly over budget and sometimes so bad, that they kill the companies that conceived them. Some of the examples are:

  • Levi Strauss' migration to the SAP system (original budget - $5 million, actual cost - $192 million)
  • Hong Kong’s airport's IT system upgrade (losses of $600 million)
  • Hershey’s a new order-taking and fulfillment system (losses of $100 million causing an 18.6% drop in quarterly earnings)
  • Kmart's IT modernization project (original budget - $1.4 billion, actual cost - $2 billion; led to company's bankruptcy)

Professor Flyvbjerg further states:

"The average overrun was 27%—but that figure  masks a far more alarming one. Graphing the projects’ budget overruns reveals a “fat tail”—a large number of gigantic overages. Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%. This highlights the true pitfall of IT change initiatives: It’s not that they’re particularly prone to high cost overruns on average, as management consultants and academic studies have previously suggested. It’s that an unusually large proportion of them incur massive overages - that is, there are a disproportionate number of black swans."

The article proposes the following steps to be taken in order to address this challenge:

Found On The Web - Why IT Projects Really Fail

CIO New Zealand

By Hemant Kogekar

05 December, 2013 11:46

 

You have probably read about the Queensland Department of Health payroll project, which ended in debacle with costs estimated at $1.2 billion. In the US, the Expeditionary Combat Support System project was cancelled after the US Air Force spent $1bn on its development.

The sad fact is these failures are not isolated instances; they’re just the most visible. Based on industry norms, less than 50 per cent of IT projects finish on time and on budget.

Discussions with experienced CIOs, consultants and project managers indicate there are many reasons for the failure of IT projects. If you step back from the individual causes, common themes emerge. A few are obvious; others are not well recognised.

Fuzzy goals: Many large projects fail because what they are trying to achieve isn’t made clear enough. There is no clear problem definition or clarity about the requirements, and the full scope of the project is not understood. One executive has an objective, but as the project moves forward new people, such as other executives, risk managers, and architects are introduced, adding their ideas of what would be best. The net result is unclear goals, expanding project scope and poor project design, all of which lead to unending debates and sliding timelines.

Over-optimism: Salespeople and internal project champions both want their proposal to succeed. However, in their desire to make the ‘sell’, they often underestimate the costs and over-emphasise the benef its. While preparing business cases, there is a tendency to maximise benefits and reduce costs to achieve the right return on investment (ROI). At times, this under-estimation is not intentional, but a result of the CIO having a poor understanding of the current situation and requirements. The CIO does not consider, or budget for, the effort to move from installing a system to actually achieving the benefits (new products, customers, capability).

Over-optimism results in unrealistic schedules. There is often an unjustified faith in technology (product, vendor or internal capability). Solution complexity is not evaluated either.