5 famous IT project failures – and how you can avoid their pitfalls

Ever had an IT project go over time or over budget?

Feature creep, insufficient training and overlooking stakeholders – the major culprits for why IT projects fail routinely crop up. The following five prominent examples are no exception. They have all failed publicly – some spectacularly – but serve as useful lessons to learn for anyone embarking on their own project, whatever the scale.

1. Sainsbury's warehouse automation

The UK supermarket giant embarked on a mammoth project to install an automated fulfilment system in their Waltham Point distribution centre. Serving most of London and the south east, the barcode-based system was supposed to streamline operations and improve efficiency.

From the initial installation in 2003, there were what were described as ‘horrendous’ errors in reading barcodes. Nevertheless, Sainsbury’s claimed that the system was working as intended in 2005. Two years later, they decided to scrap the entire project, writing off more than £150 million in IT costs.

What’s the lesson? Don’t ignore the initial phases. Problems left unaddressed at roll-out will only get worse over time – not better.

2. Apple's Copland operating system

Apple hasn’t always been phenomenally successful. When MS Windows 95 was released, the existing Mac System 7 simply couldn’t compete with its dynamic memory allocation and multitasking. Apple set out to develop a new OS in-house, with the aim of releasing a better System 8 by 1996.

It’s become known as a classic example of feature creep. As Apple refocused its resources on the new OS, project managers began to push for their products to be incorporated into System 8, derailing the project’s original scope.

Apple did eventually release System 8 to developers, but it was so unstable it did little to compete with MS Windows or boost Apple’s reputation. Before launching another developer release, Apple decided to bin System 8 and look elsewhere for their next OS – which led to the purchase of NeXT and the technology that became Mac OS X.

What’s the lesson? Project creep can take the whole thing down. Stay focused on your project’s original goals.

3. FozMeyer's ERP project

In the early 90’s, FoxMeyer was a major player in pharmaceuticals distribution in the US, worth around $5 billion. Aiming to improve efficiency, FoxMeyer bought an SAP system, together with warehouse automation technology, and brought in consultants to integrate the two. What was supposed to be a $35 million major IT project eventually became the business’ downfall. By 1996, the company was declared bankrupt.

There was a litany of reasons for failure. FoxMeyer set an unrealistic time frame: a total of 18 months to transform all their distribution systems. Warehouse employees whose jobs were under threat from the rise in automation were, unsurprisingly, unsupportive. After a series of redundancies, the first warehouse to be fully automated experienced widespread sabotage, with stock damaged and orders left incomplete. The new system also turned out to be less useful than the one it replaced. The SAP system was processing around 10,000 orders a night, compared to 420,000 under the old mainframe. FoxMeyer also accused their consultants and SAP of using the project as a training ground for new employees, rather than providing their best expertise.

What’s the lesson? No one plans failure. But you should plan for it – would your business be resilient enough to survive if the project was unsuccessful?

4. Nest's software refresh

In 2016, Nest (the Google-powered smart thermostat) released a catastrophic software update that literally left customers in the cold. A fault in the update forced the device’s batteries to run out, leaving it unable to control temperature and customers without heating or hot water in the middle of winter.

It was quick to roll out another update, solving the issue for most users. Understandably, though, the failure left some customers feeling frosty towards Nest.

What’s the lesson? Test, test and test again. Before releasing an update or implementing any kind of new system, never scrimp on the testing process.

5. US Census Bureau's remote devices

In a $600 million contract, the US Census Bureau bought half a million handheld devices to automate the 2010 census. Since then, project costs have more than doubled and a testing session found that the devices frequently froze or failed to retrieve mapping coordinates. Some devices even had the same ID number, overwriting one another’s data. A report found that ‘the final cost is unpredictable, and immediate, significant changes are required to rescue the programme’.

It’s hard to pinpoint what went wrong, but the US Census Bureau’s dogged persistence in seeing the project through even after initial testing showed major flaws meant that remedial costs spiralled.

What’s the lesson? Have a plan B. Be prepared for failure by creating a contingency strategy, and know when to use it.

Of course, we’re writing about these examples because they had sufficient scale and notoriety to be reported publicly. For most businesses, the size of transformation may be smaller, but the potential pitfalls are just as significant.

From network upgrades and new servers, to finding and implementing the right software and systems, it pays to bring in the experts. At Ratcliff IT, we have more than 15 years’ experience of delivering projects for London’s small businesses.