Josie Sephton, originally published on The Register
According to the grassroots campaigning group the Taxpayers’ Alliance, overruns in UK government IT projects have run into several billion pounds. If a similar tally were made of private sector overruns, they would most likely be of a similar order of magnitude. It is just that public sector overspends are much better publicised because taxpayers foot the bill when something goes wrong and expect to be told.
Some IT managers might be tempted to breathe a sigh of relief, knowing that overspends are par for the course. However, with current economic conditions squeezing budgets and spending under closer scrutiny, there is much to lose when IT projects go over budget, not least one’s job.
Many IT projects overrun because they are not properly specified, which can happen in a number of ways. To begin with, numerous technical dependencies need to be taken into account. A unified communications implementation, for example, will be reliant on an IP telephony infrastructure, which will in turn be dependent on the underlying network infrastructure. Or a hosted services rollout may be dependent on the right front ends with appropriate connectivity and integration with other applications within the business. It may only run with certain versions of given applications. Failure to miss these key points early on means additional work further down the line – which of course translates to higher costs and a longer rollout.
In focusing mainly on a new IT system’s functionality, people sometimes neglect service-level issues such as resilience or disaster recovery. In one example we know, a company implemented an IP telephony system without first carrying out a thorough assessment of its own communications infrastructure. As soon as the system went live it promptly fell over, having overloaded the local area network. This might not have been so serious had the old analogue system not been switched off the same day to conserve cash. The network had to go through an unplanned, expensive and hasty upgrade, during which staff had to use mobile phones to make business calls.
The fallout from this failure went beyond the financial hit – although that was significant enough. Business was lost as a result of customers not being able to call in. And the rushed upgrade meant that system glitches were never properly dealt with, as there was no time for proper testing.
Such extreme cases of poor planning appear almost farcical, but less dramatic oversights occur on a regular basis. Whether it’s failing to appreciate that a server virtualisation project will need a storage infrastructure upgrade, or that kitting out the sales guys with iPads will require some application changes because their front ends won’t render properly in mobile Safari, unplanned costs soon add up.
Business dependencies can also be missed. For example, a system being implemented as an internal departmental solution may actually need to be accessed more broadly – for example by key suppliers or customers or by staff from other departments. Retrofitting the system to deal with the security and access implications may just turn out to be impossible without a fundamental revisiting of its architecture.
A more subtle reason for overruns, and one that is harder to control, is scope creep, where interim decisions are taken along the way to build in more features or functionality. Departing from the original specification may cause more than incremental costs if new dependencies emerge as a result of the extended scope.
Because IT project costs are not the easiest thing to keep control of, the capability of the project manager (PM) is crucial. Good PMs will be able scope a project based on the various dependencies, weeding out any duplication of effort, identifying gaps and building in sufficient contingency. Importantly, this will be done in collaboration with the various stakeholders across the business as well as with technical specialists. Good PMs will also manage resources to keep things on track, taking a firm line whenever scope creep threatens.
The unforeseen can always still happen but good project management practices, underpinned by regular checkpoints, should spot the early warning signs that spend is going higher than it should. The overrun can then be addressed by trimming down the scope of the project, or dropping the quality of some of the deliverables, or even calling on the contingency. An increase in the budget is also an option, although often a politically less attractive one.
Adept project management has little value if it is not underpinned by authority and accountability. This requires clear definition of all key roles and responsibilities, with the understanding that if things go off the rails for no good reason, then heads will roll – not just the project manager’s but those of key stakeholders and even beyond. Everyone needs to be working off the same page.
There are no guarantees that IT projects will be delivered within budget, but if you treat an overrun as inevitable, then it probably will be.