Why UK IT projects keep going over budget (and what good governance actually looks like)

This is an organisational problem, not a technology problem

The 35% figure is striking enough. But the research behind it is more instructive than the number: around 80% of IT project failures are attributed to poor communication and stakeholder management, not technical failure. The software works. The implementation doesn't.

That distinction matters because it changes where you look for the fix. If IT projects failed because of bad code or unreliable infrastructure, the answer would be better engineers and better tools. But when the failure mode is organisational – unclear ownership, unmanaged scope, misaligned stakeholders – the answer is governance. And governance is something you can design in from the start.

The five most common causes of IT project overruns

Scope creep. The "while you're at it" problem accounts for more project overruns than any other single factor. Requirements get added after sign-off without a corresponding budget adjustment. Each addition seems small in isolation. Cumulatively, they extend the timeline by months and push costs well beyond the original estimate. The fix isn't to refuse all changes – requirements do evolve legitimately – but to document every change, cost it and make it a conscious decision rather than a quiet addition.

Under-budgeted data migration. Moving from one system to another always takes longer than estimated, because data is messier than anyone admits before the project starts. Duplicate records, inconsistent formats, missing fields, legacy data that nobody's touched in a decade but somebody still needs – data migration surfaces all of it. Projects that budget two weeks for data migration and end up spending two months are not unusual. They're the norm. If your project includes a system change, the data migration estimate should be treated sceptically and padded accordingly.

Underestimated change management. Technology changes how people work. If that's not planned and budgeted – training, process redesign, communication, a period of parallel running – the project delivers the system but not the outcome. You've paid for new software that half the team uses inconsistently and the other half has found workarounds to avoid. The business case doesn't materialise because the behaviour change didn't happen. Change management isn't a soft extra. It's where the value is realised or lost.

Missing a key stakeholder. The person who approved the budget and the person who will use the system daily often have different requirements, different tolerances for disruption and different definitions of success. Discovering that gap at go-live is expensive. The user who's been left out of the requirements process will find problems immediately – problems that were entirely predictable had they been asked. Map your stakeholders before requirements are finalised, not after.

Unrealistic timelines. Procurement timelines are often compressed to fit a budget cycle or a board commitment rather than to reflect how long delivery actually takes. Vendors agree to the timeline to win the work and quietly replan once the contract is signed. The project starts slipping from day one, everyone knows it and nobody says so until month four when it becomes impossible to ignore. An honest timeline agreed upfront – even if it's uncomfortable – is cheaper than a dishonest one that collapses under its own optimism.

What good project governance looks like

Governance isn't bureaucracy. Done properly, it's the structure that keeps decisions clean, problems visible and accountability clear.

Four things distinguish projects with good governance from those without. First, a named project sponsor with genuine decision-making authority – not just a champion who can escalate, but someone who can actually say yes or no when a decision needs making. Second, a change control process that requires scope changes to be documented and costed before they're approved. Verbal agreements don't count. Third, steering group meetings with honest status reporting – not just traffic-light dashboards that are permanently amber without explanation, but actual discussion of what's at risk and what's being done about it. Fourth, a defined go/no-go process before go-live, with explicit criteria that have to be met before the system is switched on.

None of these are complicated. All of them require discipline to maintain when a project is under pressure to move faster.

The discovery phase: why skipping it costs more

A discovery phase – a structured period of requirements gathering, stakeholder interviews and solution design before the main project contract is signed – is often the first thing cut when budgets are tight. It feels like overhead. It delays the "real" work. In practice, projects that skip discovery typically spend the discovery budget on rework instead, at a much worse exchange rate.

A discovery phase surfaces the disagreements, the missing requirements and the technical constraints before they become expensive problems. It produces a requirements document that vendors can actually price against, which means fewer surprises later. And it gives you the opportunity to discover that the original brief was wrong – which is far better to learn in week two than in week twenty.

Contract structure: fixed price, T&M or milestone-based

Fixed-price contracts feel safe for buyers but incentivise vendors to interpret requirements narrowly and push ambiguities back as change requests. Time-and-materials contracts give vendors no reason to be efficient. Milestone-based contracts – with defined deliverables, acceptance criteria and payment tied to each milestone – align vendor incentives with project outcomes most effectively. For any complex IT project, milestone-based is the structure worth insisting on. It forces clarity about what "done" means at each stage, which is exactly the discipline that prevents scope arguments at go-live.

The case for independent project management

Most IT projects are managed either by the vendor or by the internal champion who approved the budget. Both have conflicts of interest. The vendor wants to deliver as cheaply as possible within the letter of the contract. The internal champion is invested in the project succeeding and may be reluctant to escalate problems that reflect on their original decision to proceed.

An independent project manager – someone who isn't the vendor and isn't the internal sponsor – provides the objectivity that catches problems early. They have no stake in the original decision and every incentive to surface risks honestly. This is one of the strongest arguments for fractional CTO or IT project management as a service: you get experienced, independent oversight without the cost of a permanent hire. On a project where a few weeks of slippage costs more than the oversight engagement, the ROI is straightforward.

Early warning signs and what to do about them

Projects rarely fail suddenly. They fail gradually, with warning signs that are easy to rationalise away in the moment. Status updates that avoid specifics. Scope changes approved verbally rather than through the change control process. "We'll sort that in phase 2" as a frequent answer to unresolved problems. A vendor that's always about to catch up but never quite does.

When these patterns emerge, the instinct is often to push harder – more meetings, more pressure, tighter deadlines. That rarely works. The better response is to pause, reassess honestly and restructure if necessary. A two-week pause to get a clear picture of where the project actually stands is cheaper than driving blindly forward for another three months before the inevitable reckoning.

The lessons-learned gap

Most organisations that run a troubled project go straight into the next one without stopping to understand what went wrong. The same decisions get made. The same mistakes follow. Thirty minutes of honest retrospective – what did we get right, what did we get wrong, what would we do differently – produces insights that compound across every subsequent project. It's one of the highest-return conversations a leadership team can have, and one of the least frequently held.