Introduction
Hot take: most digital transformation programmes don’t fail because of the technology.
They fail because of the decisions made long before anyone opens a laptop — and often long before the programme board meets for the first time.
I’ve spent 30 years delivering complex programmes. The NHS National Programme for IT, then the world’s largest civilian change programme at £12bn+. Digital transformation across NHS Trusts, central and local government. A clinical research platform at the University of Oxford that now holds 6 million patient records. A full enterprise transformation as COO of a healthcare technology company that had just merged three separate businesses into one.
In that time, I’ve seen programmes succeed against the odds. And I’ve seen well-funded, well-intentioned programmes collapse from the inside — not because the technology failed, but because of failures that were visible months before go-live, if anyone had been paying attention to the right things.
The pattern is remarkably consistent. Here are the six failure modes I see most often, what they look like in practice, and what you can do to avoid them.
1. Strategy without delivery thinking
Boards sign off beautiful transformation strategies. Consultants produce impressive slide decks. And then the programme hits reality — budget constraints, legacy systems, resistant middle management, suppliers who overpromised — and there’s no one in the room who knows how to navigate that gap between vision and execution.
I’ve sat in programme kick-off meetings where the strategic ambition was genuinely compelling. Twenty slides of future-state architecture, market opportunity analysis, a compelling “why now” narrative. Not a single slide on how you get from A to B. No sequencing. No dependency map. No honest assessment of what the organisation’s actual delivery capacity looks like.
Strategy is not a delivery plan. Confusing the two is one of the most expensive mistakes an organisation can make — because you don’t discover the gap until you’re already committed, the budget is spent, and the board is asking why nothing has shipped.
Practical takeaway: Before the programme starts, ask one question. “Who in this room has delivered something of comparable complexity before — not advised on it, delivered it?” If the honest answer is nobody, that’s your first risk to address.
2. Sponsorship that disappears after the launch event
I’ve seen more programmes fail due to sponsor disengagement than almost any other single cause. The executive who championed the business case moves on, or gets distracted by the next priority, or assumes that signing off the budget was their job done.
It wasn’t.
On the NHS National Programme for IT, the governance structures that worked were the ones with active, visible executive sponsorship at every level — national, regional, and local. Where that sponsorship was genuine, programmes moved. Where it was nominal — where the SRO turned up for the quarterly review and little else — the programme drifted. The suppliers could feel it. The delivery team could feel it. Stakeholders who were already sceptical had their scepticism confirmed.
Active, visible, sustained sponsorship is not optional. It is the single most powerful thing an executive can provide to a transformation programme — and the most frequently withheld. Without it, the programme loses air cover the moment the first serious obstacle appears. And there are always serious obstacles.
Practical takeaway: Define what executive sponsorship actually means before the programme starts. Not a job title. Specific behaviours: weekly touchpoints with the SRO, visible presence at key milestones, personal engagement with the top five external stakeholders. Make it a governance requirement, not an aspiration.
3. Treating people as an afterthought
Technology changes fast. People change slowly. Organisations that invest heavily in the platform and lightly in adoption, training, and change management consistently get the same result: a system that works and a workforce that doesn’t use it.
When I led the deployment of digital patient record systems across 29 NHS Trusts — 130,000 users, hundreds of sites — the biggest variable in whether a deployment succeeded or struggled wasn’t the technology. It was whether the clinical leads felt heard, whether the training was clinically relevant rather than technically generic, and whether the local IT teams felt like partners rather than afterthoughts.
Sites where we invested time in clinical engagement before go-live adopted faster, escalated fewer issues, and had demonstrably better outcomes. Sites on sister programmes under the national programme where clinical change management was treated as a tick-box exercise — a two-hour briefing the week before go-live — struggled. Some of them are still struggling.
Digital transformation is not an IT project. It’s a people project that happens to involve IT. The ratio of investment between technology and people — in budget, in leadership attention, in programme resources — should reflect that.
Practical takeaway: Map your stakeholder landscape before you design your change management plan, not after. Who needs to change their behaviour for this programme to succeed? What do they currently believe? What would need to be true for them to believe something different? That’s your change management brief.
4. Governance that exists on paper only
I’ve walked into programmes with beautifully documented governance frameworks that nobody actually followed. Risk registers updated for the board meeting and literally forgotten when exiting the meeting room door. Issues escalated to committees that never met. RAID logs that bore no relationship to the actual state of the programme.
On the NPfIT, one of my core responsibilities was implementation assurance — essentially, a final quality gate before any supplier received an Authority to Proceed with go-live. The suppliers who consistently passed that gate were the ones whose governance was real. They had programme boards that made decisions, not just received reports. They had risk owners who actively managed their risks, not just reported them amber. They had escalation paths that were actually used.
Real governance is not a document. It’s a discipline — a set of habits that a programme team either has or doesn’t. It’s what protects the programme when things go wrong. And things always go wrong.
Practical takeaway: The test of whether your governance is real is simple: in the last month, has any issue been escalated through the formal governance structure and resolved as a direct result? If not, your governance is decorative. Find out why — usually it’s because the escalation path leads to a meeting that nobody is incentivised to attend with bad news.
5. Mistaking activity for progress
Busy teams. Full diaries. Lots of workshops. Status reports showing green. And underneath it all, the programme is drifting.
This is one of the most insidious failure modes because it’s the hardest to see from the outside — and the hardest to call out from the inside. Nobody is doing anything wrong. Everyone is working hard. And yet the programme is going nowhere.
I learned to spot this early in my career: a programme in trouble often looks busier than a programme that’s delivering. The meetings multiply. The working groups proliferate. The status decks get longer. Because activity is measurable and visible, and progress — real progress, material change in the state of the programme — is harder to demonstrate.
One of the most important skills in programme leadership is the ability to cut through the noise and ask the awkward question: what has actually changed this week? Not what has been discussed, or planned, or agreed in principle. What has materially moved? If your programme can’t answer that question clearly and quickly, you have a problem.
Practical takeaway: Introduce a weekly “what moved?” discipline. One slide, no more. What was the planned state of the programme this week? What is the actual state? What is the delta, and why? Done consistently, this is the single most effective early-warning mechanism I know — and the most frequently absent.
6. Starting without knowing what done looks like
This one sounds obvious. It isn’t.
I have worked on programmes where the definition of success was never properly agreed — where different stakeholders had fundamentally different views of what the end state should look like, and nobody surfaced that disagreement until the programme was already well underway. The technology team thought done meant a working system in production. The clinical team thought done meant full adoption across all sites. The board thought done meant the cost savings in the business case. The IT team thought done meant the legacy system switched off.
None of those definitions are wrong. But they’re not the same definition. And a programme that doesn’t agree on which one it’s working towards (and when) will satisfy none of them.
At Oxford, one of the things we got right on the CRIS platform was spending significant time at the outset aligning the University, the NHS Trusts, the governance leads, and the research community on what success looked like — not just technically, but for data-subjects, for researchers, and for the organisations taking the governance risk. That alignment took time. It also meant that when difficult decisions arose mid-programme, we had a shared foundation to return to.
Practical takeaway: Before mobilisation, convene your senior stakeholders and ask each one independently: “What does success look like for you in two years’ time?” Write down the answers. Compare them. Where they diverge is your second programme risk — and the most important one to resolve before anything else starts.
None of this is secret knowledge
Most of what I’ve described above is common sense. The frameworks exist. The playbooks have been written. The post-implementation reviews have captured the lessons.
The problem is that common sense is remarkably uncommon under pressure. When a programme is behind schedule and the board is asking questions, the instinct is to add more governance, more reporting, more oversight. When the right response is often simpler: go back to basics, agree on what done looks like, reestablish the habits that were quietly dropped when things got busy, and find the sponsor who disappeared after the launch event.
The programmes I’ve seen succeed share common characteristics. They had delivery leadership with real experience of complexity, not just strategy. They had sponsors who stayed engaged through the difficult moments. They invested as much in people as in technology. They had governance that was practised, not just documented. And they were honest about progress — even when the honest answer was uncomfortable.
That combination is rarer than it should be. When you find it, it’s worth protecting.
If your organisation is about to embark on a significant digital transformation — or is already in one that isn’t going the way it should — get in touch. We would be glad to have an honest conversation about it.
