The enormous cost of IT project failure

1 Nov 2016

10 min read time

At a glance

By Beverley Head & David Walker

In the late 1980s, Australian banking giant Westpac launched a project to build its own core banking system, CS90. A core banking system is the software machinery that runs modern banks, and so the CS90 project was both huge and mission-critical. Westpac brought in IBM to help, but their joint efforts could not make CS90 work. In 1992, the bank closed the project down, axed 500 jobs and took a A$150 million loss.

That same year, a young US software engineer named Steve McConnell was pondering why some software projects succeeded and others failed. These failures seemed startlingly common, especially in big programs for large organisations (“enterprise IT”), and he wanted to know why.

By the late 1990s, he had compiled a long list of project failures, with CS90 as one of the prize exhibits. “Even Vegas prize fights don’t get this bloody,” he wrote in 1998.

When failure is an industry standard

McConnell has spent many years analysing success and failure in IT projects and is now one of the world’s acknowledged experts on the subject. He estimates that a typical business systems project overruns its planned budget by about 100 per cent.

What’s more, he calculates only a quarter of such projects are delivered within 25 per cent of their original target.

Enterprise IT brings special challenges – elaborate work flows, unique needs and complex interdependencies. Completing such programs is a very different activity from building an app for a smartphone.

"We know why projects fail; we know how to prevent their failure – so why do they still fail?"

— Martin Cobb

What’s most remarkable about the past few decades is that despite enterprise IT’s long and storied history of project failure, the problem persists. Its persistence even has a name, “Cobb’s Paradox”, after Martin Cobb, a Canadian Government IT specialist who in 1995 ruminated, “We know why projects fail; we know how to prevent their failure – so why do they still fail?”

In 2005, the Institute of Electrical and Electronics Engineers (IEEE) – the closest thing the technology world has to a peak body – published a study, Why Software Fails, which argued that the project failure problem was actually getting worse as IT systems became more common.

Ten years later, in 2015, the IEEE went back to re-examine the issue and concluded that “while it’s impossible to say whether IT failures are more frequent now than in the past, it does seem that the aggregate consequences are worse”.

Dr Cecily Macdougall CPA, founder and CEO of Building4Business, explored software project failure in her PhD thesis. She estimated a project success rate of around 64 per cent and calculated that in Australia alone, A$5.4 billion was being wasted each year on projects that don’t deliver a benefit or are abandoned.

The dismal IT failure record

Their sheer scale means public sector IT project failures have hogged the limelight. The gold medal for recent enterprise IT project failure goes to the UK government’s attempt to create a national electronic health record system, cancelled in 2012 after an investment of more than UK£11 billion. Further examples include:

Queensland Health’s payroll replacement project failed in 2010, leading to a long legal stoush with IBM. IBM bid A$98 million to win the project; by the time it was finished the government had thrown A$1.2 billion at it.

The official inquiry into the project described underestimation of its complexity, poor governance and bad decision-making. Inquiry head Richard Chesterman QC said it could be the worst failure of public administration in Australian history.

Victoria’s Myki public transport project blew out by A$550 million.

The Australian Bureau of Statistics’ August 2016 Census, conducted predominantly via the web, was disrupted by site failures that meant the majority of Australians could not complete the census online on the designated day.

The US Air Force’s Defense Enterprise Accounting and Management System (DEAMS) has seen its projected life cycle costs double to US$2.2 billion – and its expected completion date slip from 2014 to 2017.

The private sector is less likely to be the subject of public post-mortems, but it has also had spectacular problems. Among the examples:

Australia’s Woolworths took six years and A$200 million to replace a 30-year-old legacy IT system with a SAP (systems, applications and products) solution. When it was first introduced, Big W operations couldn’t even place orders with suppliers, and it continued causing trouble until it finally began to stabilise earlier this year.

Retailer Target US decided to have its Canadian business implement a SAP solution. The project came so badly unstuck that it contributed to Target’s decision to close all 133 Canadian stores, with 17,600 employees losing their jobs. (Seeking to learn from that experience, Woolworths has appointed to its board former Target merchandising chief Kathee Tesija.)

"Even Vegas prize fights don’t get this bloody."

— Steve McConnell

In 2014, Australian superannuation fund administrator Superpartners cancelled the building of an administration platform that was four years overdue and A$180 million over budget. Later that year, Superpartners’ disillusioned owners, some of Australia’s largest industry superannuation funds, sold the whole business to the Link Group.

The IT meltdown at the Royal Bank of Scotland took nearly two months to resolve and locked 6.5 million customers out of their accounts for several days. It has cost the bank UK£56 million in fines and much more since in efforts to shore up its systems.

Steering to IT success

Steve McConnell says organisations have to overcome three persistent challenges before things can improve: they have to lift the technical management of a project; enhance staff capability; and boost organisational understanding of, and commitment to, a project of work.

McConnell and other specialists list a series of concrete steps those organisations can take to meet these challenges, according to specialists in the field.

Get sponsorship

Business IT projects need champions at the top. It’s one of the most common themes of reports into IT project failure. Says Richard Marrison, partner in charge of KPMG Technology Advisory, “When it works well, someone very senior with a lot of authority to make change is in charge. You need a broad business mandate and a clear view of the technology solution.”

That may require a business to change its practices in order to use packaged or cloud-based solutions, rather than requiring whole new software systems to be written to map the way an enterprise operates, says Marrison.

Liaise with the business

CPA Australia’s chief information officer (CIO) Cathy Bibby says IT leaders who want project success must engage in “honest conversations” with the business that clearly explain the challenges, costs and risks of major software projects. She says it’s also beholden on the CIO, project delivery manager and project manager to put up the flag early if a project can’t be done within the budget or timeframe that the company is pushing.

That, she says, relies on the project team having a deep understanding of the program of work required to achieve a desired outcome.

For Bibby, several situations flag that a project is facing issues:

when requirements and objectives are not clearly spelt out but development starts;
when there are inadequate and potentially wrong resources to tackle either the development or the change management that must come with it;
when a vendor serially fails to deliver and is not appropriately managed; and
when project governance doesn’t provide for honest conversations.

Get excellent technical leadership

Industry analysts say there has been a tendency in some organisations to draw CIOs from the business ranks rather than from computer engineering, and for generalists instead of specialists to be left in charge of complex programs of work.

Building4Business’s Macdougall is concerned also that in large, sophisticated programs of work, competencies are often focused too low, and there is a lack of overarching control that such a program requires.

Require certification of software professionals

McConnell laments the lack of rigorous certification among software engineers. While the IEEE and other bodies have advocated certification of software professionals, he says that their efforts have thus far failed to establish a critical mass of certified software engineers.

Investigate failure

Given the amount of waste in the public service, Australian Computer Society vice-president Professor Paul Bailes is keen for government to step up, with more forensic analysis of its project failures. Mandated reflection, he says, could prompt much greater transparency between purchasers and suppliers and also help lift competencies across the industry.

“We just can’t keep repeating this,” he maintains.

Solving Cobb’s Paradox

History seems to argue that IT project failure could keep repeating itself. The problem was already old when Westpac’s CS90 hit the rocks in 1992. Almost a quarter century later, Westpac is in the nervous early stages of renewing its core banking system. It is using someone else’s software, not its own. Even so, the banking industry is holding its collective breath.

If many billions of dollars are not to be wasted, jobs lost and hopes dashed each and every year on IT projects, then boards, senior executives and government all need to take note of Cobb’s Paradox.

We know how and why projects fail. Now we need to enforce the practices that will minimise the risk of yet more failure.

Can Agile help?

An Agile approach to software development is fundamentally different from the classic Waterfall approach, where everything is mapped out in advance. In Agile, software development goes through repeated cycles, and projects are split into more manageable chunks, which are often quite small.

Agile practices such as Scrum allow programmers to alter the program as customers think through what they really want and need.

Steve McConnell notes, however, that not every organisation is rigorous in the way they leverage Scrum. That can leave unsolved problems hanging around.

Yet he believes that overall, the use of Agile techniques has improved software creation in the past decade.

"You need a broad business mandate and a clear view of the technology solution."

— Richard Marrison, KPMG Technology Advisory

Cecily Macdougall generally agrees, although she warns that teams shouldn’t cherrypick which bits of Agile they use – they have to embrace the entire approach, including quality assurance and ongoing testing. While Agile is getting runs on the board, it still needs careful management.