Get in touch today: 0800 133 7948 or Email us

Why Software Projects Fail – Part 1

Posted on: September 13th, 2017 by Simon Swords

Why Software Projects Fail PDF Cover

Far too many software projects either fail or go sideways by not meeting their original objectives, timescales or budgets.

The statistics for software project delivery show that one in three software projects are truly successful. According to Standish Group’s 2015 Annual CHAOS report, 66% of technology projects (based on the analysis of 50,000 projects globally) end in partial or total failure.

Just one in three software projects are considered truly successful with large projects most at risk of failure

  SUCCESSFUL CHALLENGED FAILED
Large 8% 26% 41%
Medium 9% 26% 31%
Moderate 21% 32% 17%
Small 62% 16% 11%

Despite larger projects being more prone to encountering challenges or failing altogether, even the smallest of software projects fail one in ten times. Some of the reasons for project failure are tales as old as time – a lack of proper requirements, political imperatives, weak project sponsorship, and severe over optimism.

You don’t have to look very far for incidents of software project failures, especially those driven by central government, as the media are quick to speak out about the waste of taxpayer’s money. More recent examples include:

  • The failed e-borders system, which has landed the taxpayer with a £220m bill for costs and damages to Raytheon, the company contracted to deliver the scheme before it was unceremoniously axed by Theresa May in the early years of the coalition.
  • £100m squandered by the BBC on a video archives system that never materialised.
  • £56m Ministry of Justice back-office project cancelled after the department realised the Cabinet Office had a system doing the same thing.
  • Last but by no means least, £10bn sunk into the NHS’s national programme for IT before it too was shelved.

All of this begs the question, if the UK government with its extraordinary spending power and 3 million employees in central government alone (2017 source) is unable to successfully launch bespoke software, what chance do smaller businesses have?

IT projects are of course inherently complex and risky – but that’s okay, we have ways to mitigate risk and avoid failure

Despite the inherent risk in software projects now more than ever businesses understand the need to use software to leverage an advantage over their competitors.

We help our customers launch successful projects every day, and have done so since 2007. We understand the steps that must be taken to avoid risks inherent in software development, and this guide outlines our six most important strategies to keep your project on time, on budget and headed for success.

Case study: Sainsbury’s supply chain management fiasco

Sainsbury's Logo

Prior to the year 2000, a price war between Sainsbury’s and Tesco was in full flow. Both sides had done everything within their power to lower prices including squeezing their suppliers, streamlining logistics and in some cases even making a loss on certain items in the hope that margins elsewhere would make it up.

Having eliminated all commercial options Sainsbury’s turned their attention to their mainframe-based warehouse management system. The system was, in fact, more than one system, it was nearly 400 unique yet interconnected supply chain software applications. Peter Davis, Sainsbury’s new CEO authorised the outsourcing of all IT to Accenture, aiming to create an “agile infrastructure built on an open, adaptive and scalable architecture with hardware and software systems that would generate very high performance, strong data security and a low total cost of ownership”.

By May 2004 Peter Davis confirmed that “the £1.8 billion overhaul was well underway, and would be successfully completed in 2005”. Mr. Davis was in fact so confident about the success of their new supply chain management system that he went on to confirm that “The relationship with Accenture has worked so well that Sainsbury’s has chosen to extend its IT outsourcing contract for another three years, until 2010 — a move that should allow the retailer to net additional cost reductions of more than £230 million by 2007.”

In July 2004 Peter Davis resigned, the official reason cited was poor financial performance.

By October 2004 the new supply chain system was struggling. It was unable to track stock correctly and the shops that relied on it were starting to run out of stock. In a bid to overcome these issues Sainsbury’s hired an additional 3,000 shelf stackers. The cost for these temporary workers ran into the millions. Additionally, the £260m IT spend was written off and Sainsbury’s had to renegotiate the contract extension previously agreed with Accenture. Accenture was very quick to blame Sainsbury’s for the failure – specifically, they believed that the four fully automated depots outside of their control (and not covered by the agreement) were the cause of the problems. The new CEO Justin King blamed Accenture for the failings of the new system.

A year later in October 2005 Sainsbury’s cancelled all IT outsourcing, bringing everything back in house.

A thorough review of the failures cited the following causes:

  • The project was simply too large – the “big bang” approach and waterfall project methodology limited and in most cases punished change
  • Due to the prolonged nature of the project, staff turnover caused disruption and a loss of key legacy system understanding
  • Lack of sponsor buy in
  • Weak outsourcing governance
  • Poor project planning and “political in-fighting”

Accenture and Sainsbury’s, two mega corporations, failed to get some of the most basic software project strategies right, and their project was doomed to failure from the outset as a consequence.

Next week we’ll look at Strategy 1 – Define a Software Project Vision.



Simon Swords

Simon Swords

Director

Managing Director

Want to stay up to date with the latest software news, advice and technical tips?

;