Digital transformation programmes rarely fail because organisations lack meetings, reports, or control gates. They fail because decision-making is unclear, accountability is diluted, escalation is slow, and governance becomes disconnected from the real needs of delivery.
Every large-scale IT transformation I've been involved in has had governance. Steering committees. Status reports. RAID logs. Tollgates. The artefacts are always there. But having governance artefacts and having effective governance are two very different things — and confusing the two is one of the most common and most costly mistakes organisations make.
The organisations that succeed in transformation are not the ones with the most governance. They're the ones with the clearest decision rights, the strongest accountability, and the best visibility into whether the programme is actually delivering value. This article explores why governance so often fails in IT transformation, what that failure looks like in practice, and what the organisations that get it right do differently.
What governance actually is
Before diagnosing what goes wrong, it's worth being precise about what we mean.
Project governance is the framework through which a programme is directed and controlled. It defines who has authority, who is accountable, how decisions are made, and how the programme stays aligned to the strategic objectives it was set up to deliver.
That sounds straightforward, but the critical word is "framework." Governance isn't a single meeting or a single document. It's the entire system of decision-making, accountability, assurance, and escalation that sits around a programme. It includes the structures — the boards, the forums, the reporting lines — but it also includes the people, the behaviours, and the culture that determine whether those structures actually work.
In IT transformation, governance has a specific and demanding job. These programmes are cross-functional, politically visible, high-cost, and often deeply uncertain. They touch every part of the business. They create dependencies between workstreams that didn't previously exist. They force trade-offs between scope, budget, timeline, and risk that no single team can resolve alone. Governance is the mechanism through which those trade-offs are surfaced, debated, and decided — and through which someone is held accountable for the outcome.
When governance works, it provides clarity. Everyone knows who decides what, how issues escalate, and what the programme is optimising for. When it doesn't, you get the opposite: confusion, delay, misalignment, and a false sense of control that persists until the moment the programme hits a wall.
What governance is not
Given how often governance fails, it's equally important to be clear about what governance isn't — because many of the problems I see stem from organisations treating it as something it was never meant to be.
Governance is not bureaucracy for its own sake. It is not endless forums, approval theatre, or large reporting packs that generate activity without improving decision quality. A programme that produces a 60-slide status pack every week but can't get a scope decision made in under a month doesn't have strong governance — it has expensive administration.
Governance is not a generic template copied from another programme. This is a pattern I see constantly. An organisation runs a successful programme, distils its governance model into a template, and then applies that template wholesale to the next programme — regardless of the fact that the delivery model is different, the stakeholder landscape is different, and the risk profile is different. The governance model needs to be designed for the programme it serves, not inherited from the programme that came before it.
Governance is not the same as project management. Project teams manage day-to-day delivery — the plans, the tasks, the dependencies. Governance defines who has authority, what gets escalated, and how decisions are made and owned. Conflating the two leads to one of two problems: either governance forums get dragged into operational detail they shouldn't be dealing with, or strategic decisions get made at the wrong level because there's no clear distinction between management and governance.
The simplest test I apply: governance is not the paperwork around a transformation. It is the mechanism through which the organisation makes and owns its most important transformation decisions.
Why governance matters more in IT transformation
Governance matters in any programme. But in IT transformation, the consequences of weak governance are amplified by factors that don't exist in simpler delivery contexts.
First, IT transformation programmes are inherently cross-functional. They don't sit neatly within a single department or business unit. An ERP implementation touches finance, operations, supply chain, HR, and IT simultaneously. A platform migration affects every team that depends on the system being replaced. This means decisions made in one workstream routinely create consequences in another — and without governance that connects those workstreams, those consequences go undetected until they become problems.
Second, these programmes carry significant organisational and political weight. They're expensive, visible, and often personally associated with senior sponsors. This creates pressure to report progress optimistically, to defer difficult conversations, and to avoid escalating issues that might reflect badly on the people responsible. Weak governance allows that pressure to go unchecked. Strong governance creates the conditions for honest reporting and early escalation — even when the news is uncomfortable.
Third, the level of uncertainty is high. At the start of an IT transformation, no one fully understands the complexity they're dealing with. Requirements evolve. Technical challenges emerge. Dependencies multiply. The programme that was signed off in the business case is never the programme that gets delivered — and the governance model needs to accommodate that reality, not pretend it doesn't exist.
When governance fails to account for these factors, the result is predictable: decisions slow down, accountability fragments, risks escalate undetected, and the programme drifts away from the strategic intent it was set up to serve. By the time the symptoms become visible, the damage is usually significant.
What poor governance looks like in practice
Poor governance rarely announces itself. It doesn't show up as a single dramatic failure. Instead, it manifests as a set of patterns that individually seem manageable but collectively erode a programme's ability to deliver.
Decision rights are unclear
This is the most common pattern I encounter. Governance forums exist — sometimes several of them — but nobody is clear who is supposed to make which decisions, or on what basis they are involved. A change request bounces between the steering committee, the design authority, and the programme board. Each forum assumes the other will decide. The change request sits in limbo for weeks while the delivery team waits.
In the worst cases, forums actively avoid making decisions. They request more analysis, defer to the next meeting, or escalate upward to a body that's even further removed from the detail. The result is a programme that has all the apparatus of governance but none of the decisiveness.
Reporting is disconnected from reality
Status reports exist, but they don't tell the truth. RAG statuses stay green long after the delivery team knows a workstream is in trouble. Reporting packs are comprehensive but not decision-useful — they describe activity rather than surfacing the exceptions, risks, and decisions that governance forums actually need to act on.
This pattern is self-reinforcing. When reporting doesn't reflect reality, governance forums can't identify problems early. When governance forums can't identify problems, they can't escalate or intervene. When they can't intervene, problems compound — and by the time reality forces its way into the reporting, the programme has lost months of potential recovery time.
Forums overlap and compete
Multiple forums exist with similar or overlapping responsibilities. A design decision that should sit with the design authority ends up being relitigated at the steering committee. An operational issue that the programme board should resolve gets escalated to the sponsor because no one is confident the programme board has the authority to decide.
This creates two problems simultaneously. First, decisions take longer because they're debated multiple times. Second, accountability is diluted — because when everyone is responsible for a decision, nobody is.
The governance model doesn't match the programme
This happens when a governance model is designed at the start and then never revisited, even as the programme evolves. A governance structure that worked during the design phase — when decisions were primarily about scope and requirements — may be completely wrong for the build and test phases, when decisions are about technical trade-offs, defect prioritisation, and cutover planning. But if nobody adapts the model, the programme is left with governance forums that can't process the decisions being put in front of them.
Sponsors are present but passive
The sponsor attends the steering committee. Their name is on the programme charter. But they don't actively own the outcomes. They don't challenge the reporting. They don't make the difficult trade-off decisions that only a sponsor can make. They treat governance as a meeting they attend rather than a function they lead.
This pattern is particularly damaging because it's often invisible to the wider organisation. From the outside, the programme appears to have strong sponsorship. From the inside, the delivery team knows that escalations go unanswered, decisions are deferred, and the programme lacks the executive air cover it needs to move forward.
When governance failures make headlines
The patterns I've described aren't theoretical. They play out at scale, with consequences that extend far beyond the programme team. Two UK examples illustrate what happens when governance fails on transformational programmes.
NHS National Programme for IT
The NHS National Programme for IT — NPfIT — remains one of the most significant governance failures in UK public sector history. Launched in 2002 with an initial budget of £6.2 billion, it aimed to create an integrated electronic patient record system across the entire English NHS. By the time it was dismantled in 2011, costs had exceeded £10 billion, with only a fraction of the intended clinical benefits delivered.
The governance failures were present from the outset. The programme was initiated through a top-down political decision with minimal consultation — not with the clinicians who would use the system, not with the NHS trusts that would implement it, and not with Parliament, which had little opportunity to scrutinise the plans before procurement began. Decision-making authority was centralised in a way that was fundamentally misaligned with how the NHS actually operated — a network of semi-autonomous trusts, each with different systems, workflows, and priorities.
The programme lacked meaningful stakeholder engagement at every level. Clinicians raised concerns early on about accessibility and fitness for purpose, but the governance structure provided no effective mechanism for those concerns to influence decisions. Accountability was equally fragmented. Contracts were awarded to major IT firms under terms so aggressive that multiple providers withdrew or were terminated over the programme's lifetime.
The lesson from NPfIT isn't simply that big programmes are hard. It's that governance which centralises decision-making authority without connecting it to the people who understand the delivery reality will eventually collapse — no matter how much money or political will sits behind it.
Crossrail
Crossrail — now the Elizabeth Line — was originally budgeted at around £14.8 billion and scheduled to open in December 2018. It eventually opened in stages between 2022 and 2023, with total costs approaching £19 billion.
What makes Crossrail instructive for IT transformation is that the governance failures weren't about the absence of governance. The programme had governance structures. It had a sponsor board. It had assurance reviews. It had external schedule reviews. And yet none of these mechanisms surfaced the scale of the problems until it was too late.
The core issue was an extreme version of autonomy. The sponsor devolved accountability to Crossrail Ltd to such a degree that when risks escalated, the sponsor lacked the visibility and contractual mechanisms to intervene effectively. As late as June 2018 — just months before the delay was publicly announced — Crossrail's own reports rated the December opening date as green, despite flagging 25 individual amber and red warnings on specific elements. The governance forums had the data in front of them, but the reporting structure aggregated it in a way that obscured the cumulative risk.
There were no planned review points of the governance arrangements during the life of the project. The model that worked during the tunnelling phase was never formally reassessed for the integration and commissioning phase — a fundamentally different type of work.
The lesson: governance that works in one phase of a programme is not guaranteed to work in the next. If nobody is asking whether the governance model is still fit for purpose, the answer is almost certainly that it isn't.
The common threads
Across these high-profile failures — and the hundreds of less visible ones that happen every year in the private sector — the same patterns emerge.
Structures are not effectiveness
Both NPfIT and Crossrail had governance. What they lacked was governance that actually functioned — surfacing problems early, assigning accountability clearly, and adapting as the programme evolved.
Centralised decisions without local connection
NPfIT proved that governance which concentrates authority at the top, without mechanisms for delivery teams to influence decisions, will eventually lose touch with reality.
Optimism bias thrives in weak governance
Crossrail demonstrated how governance that doesn't actively challenge reporting can allow an increasingly optimistic narrative to persist until reality forces a correction.
Static models break under changing conditions
Both programmes suffered from governance designed for one phase and never adapted. Each transition creates different decision-making demands that the model must evolve to serve.
The practical ingredients of effective governance
Knowing what fails is useful. Knowing what to do instead is more useful. The following principles aren't abstract — they're the practices I've seen consistently in programmes that govern themselves well.
Design governance for the programme, not from a template
Every programme is different. The delivery model, the stakeholder landscape, the risk profile, the organisational culture — all of these should shape the governance design. That doesn't mean starting from scratch every time. Good governance principles are well established. But the application of those principles must be tailored to the specific context.
A programme using an agile delivery model needs governance that can make decisions at sprint cadence, not monthly board cadence. A programme with multiple legacy systems and a complex data migration needs governance that connects the data workstream to design and testing — not one that treats data as a sub-task of the technical team.
Make sure every stakeholder understands their role
One of the most effective governance tools I've used is a simple RACI matrix for major deliverables, approvals, and decisions. It sounds basic, but the exercise of building it — of forcing the programme to define who is responsible, who is accountable, who is consulted, and who is informed for each significant decision — routinely surfaces ambiguities that would otherwise persist for months.
The value isn't in the document itself. It's in the conversation it forces. When you sit down with a sponsor, a programme director, a design authority chair, and a workstream lead and ask them to agree on who approves a scope change, you quickly discover whether the governance model is clear or whether everyone has a different assumption about how the programme actually works.
Establish clear decision and escalation paths
The damage caused by unclear escalation is underestimated. When nobody is clear who should make a decision, or when decisions take too long because the escalation path is ambiguous, delivery teams do one of two things: they wait, losing time; or they make the decision themselves, creating risk.
Effective governance documents escalation triggers, decision thresholds, and forum ownership explicitly. If a risk exceeds a defined threshold, it escalates to the programme board. If a scope change has budget implications above a certain value, it goes to the steering committee. None of this needs to be complex. It needs to be written down and understood.
Maintain RAID management as an active tool
Every programme has a RAID log. Very few programmes use it well. In most programmes I've inherited, the RAID log is a static document — a spreadsheet that gets updated before a board meeting and then ignored until the next one. Risks are logged but not actively mitigated. Actions are assigned but not chased. Issues are recorded but not escalated.
Effective RAID management is a live governance discipline. The log is reviewed regularly — not just before board meetings, but as part of the programme's operating rhythm. Risks are assessed for cumulative impact, not just individually. Actions have owners and deadlines, and those deadlines are enforced. The RAID log drives the agenda of governance forums, not the other way around.
Use technology for live visibility, not retrospective reporting
Too many programmes still rely on a patchwork of Excel trackers, manually compiled PowerPoint packs, and email chains to report programme status. The result is reporting that is always out of date, always subjective, and always open to interpretation.
The shift that makes the biggest difference is moving from retrospective reporting to near real-time visibility. Tools that provide a single view of programme status — dependencies, risks, decisions, milestones — reduce the opportunity for optimism bias and give governance forums information they can actually act on.
Strip out reporting for reporting's sake
If your programme produces a 40-page status pack every fortnight and the steering committee spends 90 minutes reviewing it, you have a reporting problem. The purpose of governance reporting is to surface exceptions, identify decisions that need to be made, highlight risks that require action, and track progress against outcomes — not to provide an exhaustive account of everything that happened since the last meeting.
The most effective governance reporting I've seen follows a simple discipline: report by exception. What's changed? What's at risk? What needs a decision? What's blocked? If a workstream is on track and there's nothing to escalate, a single line confirming that is sufficient. The time recovered can be spent on the issues that actually need the attention of senior stakeholders.
What strong organisations do differently
They invest in sponsorship as a capability
The sponsor isn't simply the most senior person willing to lend their name. They actively own outcomes, challenge reporting, and make the trade-off decisions that only a sponsor can make.
They make governance visible and understood
Decision rights are documented and communicated. Every person in the programme understands how decisions are made, where their authority begins and ends, and what happens when an issue exceeds their remit.
They use governance to enable delivery
The strongest models help teams resolve issues quickly, not trap them in process. Forums have clear mandates and the authority to decide. The model flexes as the programme evolves.
They separate governance from administration
Governance forums spend time on decisions, trade-offs, and risks — not reviewing information that could have been distributed in advance. Pre-reading, exception-based agendas, and time-boxed discussions.
They review the governance model itself
They build in formal review points at phase transitions and major milestones. The willingness to adapt governance to the programme's evolving needs separates those who govern well from those who go through the motions.
The bottom line
Governance is not a set of meetings and reports. It's the decision-making and accountability system that determines whether a transformation programme stays aligned, controlled, and focused on outcomes.
When governance fails in IT transformation, it doesn't fail loudly. It fails quietly — through unclear decision rights, slow escalation, disconnected reporting, passive sponsorship, and models that were designed for one context and never adapted for another. The programme continues to produce status packs and hold board meetings. The artefacts of governance persist even as the substance evaporates. And by the time the symptoms become impossible to ignore, the cost of recovery has multiplied.
The answer is not more governance. It is better governance: proportionate, clear, adaptive, and relentlessly focused on enabling the decisions that keep a programme on track. The organisations that succeed in transformation are not the ones with the most governance artefacts. They are the ones where decision rights are clear, accountability is real, escalation is fast, and the governance model serves the programme — not the other way around.