Some phrases are used so often they lose all meaning. “Digital transformation” is one of them. Spend any time in technology or public sector circles, and you will encounter it everywhere – in business cases, strategy documents, ministerial announcements, supplier pitches, and more. But if you ask a room of senior leaders what transformation actually means, you will get very different answers, as we discovered at a recent roundtable I attended, hosted by the Institute for Government in partnership with Scott Logic.

That ambiguity is not just a semantic inconvenience. The way an organisation defines transformation shapes how it funds it, how it governs it, and how it measures success. In this article, I’m discussing how to reframe thinking and definitions of transformation to ensure success.

The word is doing too much work

At our roundtable, the question of what transformation actually is came up quickly and sparked a debate. Is a nine-year programme a transformation programme, for instance? Is incremental improvement transformation, or just evolution? Does replacing legacy infrastructure count, or does transformation require fundamentally changing the way an organisation operates?

It matters because the way an organisation defines these activities influences how those activities are funded, staffed, and governed.

My working definition, arrived at through a lot of experience on both sides of these programmes, is that transformation means doing something fundamentally different. Not faster, not cheaper, not on newer infrastructure – but differently. Changing the model, not just the machinery.

And that change isn’t always a discrete activity. As one member of the roundtable quipped: “transformation programmes aren’t just for Christmas.” There is a tendency in the public sector to see transformation as something with a start and a finish; this can be limiting. Genuine transformation is a sustained, ongoing shift in the way an organisation operates – something you enable and maintain, not something you complete.

The false binary between transformation and BAU

Part of what makes this shift in thinking so difficult is the way organisations have come to think about transformation as something separate to business as usual.

Transformation sits in one box: exciting, funded, visible. BAU sits in the other: operational, steady-state, perpetually underfunded, and administratively unglamorous. The people working on transformation are changing the world. The people keeping the lights on are, well, keeping the lights on.

This binary is artificial, and it is costly. It creates a structural incentive to badge work as “transformation” to access funding, visibility, and resource – regardless of whether the work is genuinely transformational. And it leaves the operational estate, the systems and services that organisations actually depend on day to day, chronically starved of investment.

The more useful frame is a continuous one: build, run, optimise. The distinction that matters is not transformation versus BAU, but whether you are funding enduring capability or chasing a one-off outcome. By funding capabilities and products instead of projects, this frame can be enshrined in an organisation’s operational DNA.

The programme trap

The reason why it’s problematic to plan transformation as a project is that, despite being the dominant model for organising and funding large-scale change, the project model is a poor fit for digital systems. And yet it continues to govern how most organisations invest in them.

Programmes assume a fixed set of stages leading to a defined outcome. They have start dates and end dates. They are funded through multi-year budgets that split between capital (investment) and resource (operational) spending. Indeed, in the public sector, large transformation projects are often framed to secure capital funding, with business cases aligned to HM Treasury’s Green Book. This can incentivise planners to treat transformation as a finite project rather than an ongoing activity.

The result is that business cases are built on assumptions about users and their behaviours, and an overarching assumption that those things will not change between project kick-off and delivery.

Digital systems do not work like that. Requirements evolve. User behaviour changes. The organisation itself changes. The environment changes. A programme that sets out to achieve a fixed outcome in a fixed timeframe will often arrive at that endpoint to find the goalposts have moved.

I have seen this pattern repeatedly in the public sector, where the pace of policy change means that a programme working towards a fixed goal over three or five or seven years can find itself solving the wrong problem by the time it finishes. One example from my own experience: a business case for introducing a system to charge users a transaction fee for a formerly free service was dependent on processing a certain volume of transactions. But the business case failed to account for the fact that introducing fees for those transactions would change the volume itself. The model was internally consistent, but it didn’t account for the real-world response to the thing it was building.

The HMCTS reform programme illustrates another version of this trap. The programme’s digital transformation ambitions were real and substantive – but they were funded, in significant part, by the savings expected from closing court buildings. The digital work and the estates rationalisation were coupled in the business case in ways that created dependencies and constraints that had nothing to do with the quality of the technology. When you tie programme funding to outcomes that are only partially within your control, you are managing risk by hoping.

There is also the matter of what happens when the programme ends. We’ve already discussed how most large-scale programmes are funded as capital expenditure; this suits the accounting conventions of government, but poorly reflects the economics of digital systems. Software is not a building. You do not construct it once, hand it over, and walk away. It requires continuous investment: security patches, performance improvements, new features, integration work as the surrounding landscape changes. Programmes that secure capital funding to build a thing but leave no budget to run and improve it are setting up their successors for a slow, invisible decay.

Optimism bias

Optimism bias compounds the problem. Transformation programmes are typically wildly optimistic about what they can achieve and in what timeframe. There are established practices in government appraisal for adjusting cost estimates to account for this bias – but those adjustments are not always applied with equal rigour to the projected outcomes. The result is programmes that cost more than expected and deliver less than promised, not because anyone was dishonest, but because the planning model was structurally overconfident.

The way that optimism bias is accounted for is also sometimes problematic, because of project-based thinking. On paper, it can seem like you can pull different levers to manage risk in projects – but the business case often misses nuances about which levers it is possible to pull. Adding more people to a development team just because you have more funding in-year can actually increase risk and slow down development rather than improving the probability of delivering a fixed outcome faster. I’m always reminded of the phrase “nine women can’t make a baby in a month”. When transformation is freed from the fixed goals and timescales of projects, it’s easier to spot which levers can be pulled to manage risk effectively.

The cost-cutting trap

There is a specific version of the programme problem worth naming separately, because it is so common and so damaging.

When transformation is framed primarily as a cost-reduction exercise (and it frequently is, because cost reduction is the language that unlocks funding approval), it can undermine the very change it is trying to drive.

The logic is understandable. Transformation is expensive. Business cases need to stack up. Savings from headcount reduction or process consolidation are quantifiable in ways that “better user outcomes” or “increased organisational agility” are not. So, the business case leans on the efficiency gains, and the programme gets positioned internally as a route to doing more with less.

The problem is what this does to the people who are supposed to make the change happen. Staff who understand that a transformation programme is, in practice, a mechanism for reducing headcount are not going to be enthusiastic champions of it. The change management challenge – already significant – becomes nearly impossible when the message received by the workforce is that transformation means their jobs. Engagement collapses. Resistance hardens. And the programme that was supposed to change the organisation ends up being resisted by it.

Transformation sold as cost-cutting tends to produce exactly the kind of short-term, box-ticking behaviour that real transformation requires you to move away from.

OK, so what does good look like? That will be the subject of my next blog post.