5 Jan 2015 11:46am

Why do IT projects fail?

High-profile failures have cast doubt on the ability of both the public and private sector to incorporate cutting-edge IT. But, argues Nick Martindale, it’s often the business plan, not the technology, that needs turning off and on again

Recent history is littered with examples of expensive IT failures. From national computer systems that have seen costs spiral only to eventually be dismantled (NHS), to high-profile digital projects that have had to be abandoned (2013’s £98.4m write-off by the BBC of its failed Digital Media Initiative), it is a long and sorry tale.

Unfortunately, it does little to enhance the UK’s ability as a nation to effectively grasp, manage and oversee the adoption of new ways of working, which is a shame because theoretically, successful projects can improve productivity, efficiency, competitiveness and investability.

For organisations specifically, the consequences can be significant, even fatal. “Project failures, delays and delivery of the wrong outcomes continue to hit the headlines on a regular basis,” says Peter Osborne, managing director of advisory firm LOC Consulting. “In addition to the waste of time and money, the long-term impact of a failing project puts an organisation’s brand, reputation and even its future viability at risk.”

David Mitchell, EY executive director, advisory, has been involved in many large-scale IT projects. A common reason for things going wrong, he says, is that organisations tend to start by picking the solution they like the look of, rather than fully evaluating the business case. “Once you’ve got a clear benefits case, then you can start talking to people about what the system contains and what you’re going to do from an IT perspective that’s going to get you to where you want to be,” he says.

People who have been through big transformation programmes don't want to get involved with them again


“But, frankly, no one really wants to do that. They like buying shiny stuff like iPhones and they like Amazon, and they think they’re going to get an Amazon experience when they part with their money to one of the big systems integrators. That rarely turns out to be true.” He believes finance directors and finance functions have an important role to play as a link between the wider business – those who would end up using the systems – and IT, and ensure there are clear objectives around what the business is looking to achieve.

The Danish government has recently deployed a business case modeller package to help it make objective decisions around whether or not to sign off new programmes. The package from business analysis firm Visual Reporting uses a number of methods to test proposed costs and benefits including the Monte Carlo simulation, a computerized mathematical technique that allows people to account for risk. “The main reason large IT projects fail is that they grow in complexity, and humans are very poor at handling complex tasks,” says Laurits Søgaard Nielsen, CEO of Virtual Reporting. “But often the creation of a business case does not follow best practice and can be severely affected by managers wanting to influence the process of project approval. ‘I want this project to happen’ often outweighs the poor business case.”

Other mistakes tend to happen once the project is underway. Sally Waterston, director of IT business consultancy Waterstons, points to a lack of communication. There are two common scenarios she sees, both of which can prove catastrophic. “One is that IT feel that someone else has chosen a system they haven’t been involved with and then they are expected to make it work,” she says. “The other is when it is regarded as an ‘IT project’ and IT have to find and justify the budget, so they make decisions which they are often ill-equipped to do, and then roll out the system without any ownership from anyone else.”

Richard Anning, head of the IT Faculty at ICAEW, agrees that part of the issue is the tendency for any initiative involving technology to be pigeonholed as an IT project.

“That immediately puts it into a corner which has ‘too difficult’ marked on it,” he says. “The CEO and the board need to be able to communicate with IT, and vice versa. This lack of accepted ownership is one of the reasons projects fail.” He suggests having one person to take on the role of “temporary CEO”, devoted to managing such programmes, rather than relying on IT project managers.

Mitchell even goes so far as to suggest that the difficult nature of such projects is, at least in part, one of the reasons why lessons do not appear to be learned from one failure to the next. “One of my personal observations is that the people who have been through big transformation programmes typically don’t want to get involved with them again,” he says. “So you end up with a bunch of relatively inexperienced people, sitting on top of something they don’t really know what to do with, or how to manage. They can’t look at the systems integrator because, frankly, they don’t trust them, and they know they haven’t got the skills in-house. It’s very difficult for them to navigate through that.”

Large IT projects are not, of course, the only ones to experience issues, although they are the ones most likely to hit the headlines. Smaller projects tend to be more contained, and have fewer individuals and business units involved, making them less likely to fall apart. “Big IT projects generally are more complex, go across a number of departmental boundaries, and have tasks of unknown difficulties before you start,” says Anning. “It’s fair to assume they are going to be more likely to fail.”

Dan Onions has worked as a strategic advisor on a range of public and private sector IT transformation projects and recently founded the DASH project management app. He highlights what he terms a “conspiracy of optimism” which tends to infiltrate projects early on. “Sometimes this is from pressure to fit within a budget in order to secure funding, since on a large-scale project the problem of filling the funding gap does not impact until much later, so it is easier to defer the problem than to tackle it,” he says. “It is important that project risks are addressed early, which means de-risking technology with end-users in a real situation. On smaller projects this often happens quite naturally, but on larger projects the organisation structure often creates layers that prevent this intimacy between end-users and designers.”

Rather than simply handing over projects to IT, finance directors have an important role to play in helping to shape the framework through which a project can work. “Financial directors are in a position to influence and guide an organisation,” says Adrian Buckman, group head of quality and programme management services at software firm SQS. “Important factors include identifying where a large project can be broken down, and ensuring the right people within the organisation are on board.” He adds that IT vendors would welcome more involvement from the business side of the client.

Performing a review or a project health check in a structured manner and taking the right actions at the right time can ensure all elements of a project are kept on track

Dan Osborne

At a practical level, simply checking that the business case being presented at the outset stands up to scrutiny is a good starting point, suggests Anning. “When you’re getting estimates for a project, don’t just rely on those from project advocates, because they might not necessarily be the most accurate you can get,” he says. “Get the best skilled team you have internally, but don’t be afraid to have estimates checked by independent specialists, who can compare those with best practice from other organisations. They can also tell you if a project is going out of control, and whether that particular project now falls below an acceptable level where you want to continue with it.”

Keeping track of where projects are at is another important task, particularly as those working on the project delivery become more absorbed with detail. Babuji Abraham, chief technology officer at IT services provider ITC Infotech, says the key here is to work backwards from the desired result at the beginning of a project, providing clear benchmarks against which progress can be measured further down the line. “Teams should work together to identify their objectives and associated risks on a granular level, and define them for each stage of the project, creating regular intermediate milestones to check progress,” he says. “This means that if something goes wrong, the issue can be contained and addressed quickly without causing the entire project to collapse.”

Where projects do require attention, finance directors can help to take action at an early stage to ensure costs and schedules do not slip further. But it’s important here that business cases and projected outcomes are flexible, says Osborne. “Performing a review or project health check in a structured manner and taking the right corrective actions at the right time can help ensure all the elements of a project are kept on track,” he says.

“Yet in the same way that most people only go to the doctor when they feel ill, the majority of organisations only perform a review if they believe that something is fundamentally wrong. The tendency for stakeholders to halt a failing project mid-flow for review and restructure or to take drastic corrective actions is exactly the wrong approach,” he adds. “All momentum and focus is lost because stakeholders find there’s been little progress and the delivery team quickly become disillusioned.” In some cases it could be necessary to focus on priority areas and short-term objectives, and revisit other issues further down the line, he suggests.

Whether a project is ultimately viewed as a success or failure will depend in part on what criteria it is assessed against, and this isn’t always time, budget or even whether a project is completed. Mitchell says he’s aware of at least a couple of large and expensive projects that will be completed shortly, but where the end result is not something the business actually requires. “The classic failure mode for me would be product but no business outcome, where you have a solution, but it doesn’t do what the business wanted,” he says. “You often hear that 30% of programmes get canned. My experience is 30% of the big ones probably don’t, but neither do they deliver anything the business wants or uses.”

Onions, too, believes more focus needs to be placed on the end result, even if this is different from what was initially envisaged at the outset. “The traditional way to judge the success or failure of a project is to look at the ‘iron triangle’ of scope, time and cost,” he explains. “But it is often better to look at a project based on the outcomes it achieves. It might not meet the plan, but it may deliver a huge business benefit. For these projects, it is more a case of managing expectations about outcomes.”



Acorn Care and Education is one of the largest providers of specialist childcare in the UK, running schools, foster care and residential care homes across the country.

Over recent years the business has expanded through a mixture of organic growth and acquisition to more than 40 different entities, and recently decided to bring the production of statutory accounts and corporation tax back in-house, deploying and rolling out software across the group.

As this was a finance project, the finance function had a particular interest in ensuring a successful outcome. “We started work on the project about nine months before our financial year-end, so 12 to 13 months before we actually had to deliver our first set of signed accounts,” says Will Napier-Fenning, group finance controller.

After conducting a “beauty parade” of potential providers, Acorn decided to go for Thomson Reuters’s ONESOURCE accounts production and corporate tax packages, with the finance team closely involved in ensuring the systems were able to cope with its requirements.

“We got them to live demo and test pieces of work which we knew would be complicated to make sure we were buying something that was capable of doing what we wanted it to,” says Napier-Fenning. He also made sure he met the technical team early on, he says, as well as just the salespeople.

The finance team has been involved in overseeing more operational projects in the past, he says, but he believes the experience of going through its own implementation means it would be better equipped to contribute to future rollouts.

“One thing I have learned is that when you’ve got projects that cross between finance and operations, you need to spend time engaging operations in the process early on, especially if it’s something you’re building from scratch or having customised,” he says. “If you can do that, the uptake is higher, the buy-in is higher, and you will end up with something that actually works for them.”

Nick Martindale

Related articles


RBS fined £56m for IT failure

FCA launches RBS glitch enquiry

In a digital age the network is king

Intelligent machines and displaced workers