Too many IT projects fail. Here’s four reasons why

For all the focus we put on corporate strategy, it’s not strategy that determines why most organisations fail or otherwise.

In a moderately competitive marketplace, it’s the implementation of the strategy that separates the market leaders from the followers.

Implementing strategy isn’t just about inspiration and leadership. It’s a technical skill-set. And one that too many managers don’t have, if the deficiencies in project management are anything to go on.

According to figures released by the Caravel Group, a large-scale infrastructure consultancy, up to half of all projects undertaken by companies go over budget and fail to achieve the aims the company set for the development.

This isn’t just a problem for large mining companies. Project management is a concern for every business, though for many businesses, the projects revolve around IT rather than construction.

Failed IT projects set big organisations back billions of dollars. For example, Queensland Health went more than $1 billion over budget when it contracted IBM to upgrade its payroll systems.

Stephen Coates, a technology risk partner at BDO, advises large businesses about how to avoid their IT projects going off track and over budget.

“The thing with IT is that it’s a support function across your entire organisation,” he says.

“If the IT project goes poorly, your organisation pays for a very long time.”

He talked LeadingCompany through the biggest mistakes he sees companies make when developing and implementing their IT projects.

1. Reinventing the wheel

The first mistake is one of pride.

“Quite often, businesses like to think they’re trailblazers, the first to do things a particular way,” Coates says.

This might help sell an idea of a certain project. But it’s bad news for project management.

“In almost every project you can find four or five other situations where companies have done something very similar.

“I always like to look at where something has been done before, so I can learn from that project. There’s always a reluctance to send people overseas on study tours. But generally, it’s very beneficial to spend time going out to other organisations and learning from that. That’s crucial education they can bring back.”

2. Letting the limits define the goal

Coates says he recently caught up with a businessman who was describing a project he was working on.

“He said he had $100 million for a project, which had to be done by the end of the year. Already, that’s two things that trigger project failure right there.”

It’s human nature to view budgets and deadlines as guides to what it should take to do something, Coates says. This is despite the fact that in IT projects, the budget and the deadline is defined by people who typically have no idea of what’s required to complete a certain project.

This means budgets and deadlines are often arbitrary, and likely to lead project management astray.

“If the budget is insufficient, then corners are cut to come in within that budget,” Coates says. “And if the budget is overly generous, then things are scoped in that aren’t actually required, and not supported or needed by those in the business.”

This doesn’t seem to make sense. Should businesses place no limits at all on what projects should need to get done?

Coates says it’s about the order things are done in. Too often, decision-makers within a business allocate money and time for a project without having a proper understanding of what’s required for it to get done.

“You need to go into the marketplace in the first place to understand those things, and not set your budget before,” he says. “And after that, you should have a range, and budget for the upper limit. A range is more sensible than a hard deadline.”

3. Project governance

Because IT projects often go on for a long time, the people governing said projects often move onto other things before a project is completed.

“What’s delivered at the end often isn’t what was wanted at the start,” Coates says. While the original project governance team might understand clearly why a particular project is required, the next one might not see the business imperative as clearly, which leaves them more likely to deliver what’s easiest technically rather than what’s needed.

Even when the project governance team stays the same, they’re often not good at the type of follow-through you need to manage a project.

“I often see businesses assess the risks of a project at the start,” Coates says. “It’s noted, and written down.

“Sometime down the track, the risk occurs and someone says, ‘Why didn’t we raise this five months ago?’ That’s the problem. Things are noted but not followed up. It needs to be the next step from that.

“A lot of it comes down to the experience of the people on the project. Experienced people recognise issues and address them adequately when they arise. Less experienced people will wait for someone else to deal with them.”

In Coates’ view, the disconnect arises from many experienced technical experts not being as experienced around making a business case for a project and failing to understand its broader business significance.

As a result of this, they end up being overseen by business managers who may not understand the technology side of the project well. When the two sides do not communicate well, mistakes get made and things get left behind.

5. Finishing too early

“Project teams finish their work on the day of implementation,” Coates says.

“Really, they should finish a couple of months later, after you’ve seen how the project works in practice and done a review of the whole thing.”

The way people use technology is often different from the way you think they’ll use it. If the project team doesn’t stick around to make tweaks in the months following the implementation, problems fester and don’t get addressed until the next time your systems are overhauled, which costs a whole lot more than making a few tweaks along the way.