In my recent blog post on Rethinking ‘Transformation’: From projects to long-term capability, I asserted that how we define transformation shapes how it’s funded and delivered. In my opinion, treating transformation as separate from business as usual creates costly distortions, and results in a project‑led, cost‑cutting mindset that often undermines the very change organisations are trying to achieve.

In this post, I’m going to set out what ‘good’ looks like, and the lessons we can all learn to make good transformations the norm rather than the exception. I’ll begin by looking at one of the successful programmes that was referenced at a recent roundtable I attended, hosted by the Institute for Government in partnership with Scott Logic.

Lessons from the sharp end

The Bank of England’s core ledger replacement is often cited as an example of long-term, disciplined programme delivery. It is worth being precise about what it was, and what it was not.

It was not, strictly speaking, a transformation programme in the sense of my working definition. The Bank did not fundamentally change the way it operated as a result of it. What it did instead was replace a decades-old system that had become a critical risk, with one that was fit for purpose. We consider that a replatforming: a vital, complex, high-stakes, and technically demanding piece of work, but one aimed at maintaining existing capabilities on better foundations, rather than creating new ones.

The distinction matters because it is easy to look at a nine-year programme and conclude that transformation just takes a long time. The more accurate conclusion is that foundational systems replacement takes a long time – and that conflating it with transformation creates unrealistic expectations in both directions.

That said, the way the programme was run contains lessons that apply directly to genuine transformation. A few stand out.

Confront the biggest risks early

The first is the decision to confront the biggest risk early. Rather than following a pure agile approach and building an MVP, the BoE recognised that the key risk in the initiative was platform selection and so entered into a ‘competitive dialogue’ with the suppliers bidding on the project. This involved each bidder designing and building a simplified payment system to test their technical approach and responsiveness to customer needs – effectively forcing a resolution of any questions that, if left unresolved, could have derailed everything.

This is the opposite of the business case logic that encourages programmes to demonstrate early wins and push difficult decisions towards the back end. A programme where all the hard stuff sits in year four is a programme where the hard stuff never quite gets done.

It is important to note that while Accenture was chosen as the winning bidder, both of the unsuccessful bidders were compensated for their time and effort, recognising that their efforts, along with the successful bidder’s, contributed to a refined final design.

Ensure sponsors truly understand the terrain

The second lesson is the role of the executive sponsor. Programmes that work well tend to have a senior sponsor who genuinely understands the risk landscape; to borrow an analogy I used last time, they understand that nine women cannot make a baby in a month. A sponsor who understands the technical and organisational complexity involved enables teams to make difficult calls, take short‑term pain for long‑term gain, and resist the pressure to do the easy things first.

Don’t mistake slow progress for failure

The third is that not everything that looks slow from the outside is going wrong. Long periods of groundwork – platform design, architecture decisions, vendor selection, integration planning – do not produce the kind of visible progress that stakeholders and ministers tend to want to see. Programmes that are forced to manufacture visible milestones to satisfy governance requirements often end up making commitments that constrain their later choices.

Fund capability, not projects

The structural answer to most of what we have described is a shift in how organisations think about funding technology, and about what transformation is.

The programme model funds outcomes: a specific system, a defined set of capabilities, delivered by a certain date. Once the outcome is delivered, the funding ends. This makes reasonable sense for infrastructure projects, where the thing you build stays broadly as you built it. It does not make sense for software, which is never finished and which degrades in value without continuous investment.

The alternative is to fund products and services. Not “build a new case management system” but “fund the ongoing development and operation of our case management capability.” The difference sounds subtle, but it changes how teams are structured, how priorities are set, how progress is measured, and crucially, how the organisation’s capability continues to improve after the initial build is complete.

This means treating digital systems as operational investments with ongoing running costs; accepting that the opex component is not a sign that something has gone wrong, but a feature of how modern software works. It means maintaining (and working on) a backlog of improvements rather than declaring the work done. It means having the KPIs and data infrastructure to understand what is working, what is not, and where to invest next.

It also means being honest about what success looks like for an external partner. At Scott Logic, our goal is always to leave an organisation with capability that outlasts our involvement. We bring specialist expertise to navigate the change from A to B, but the transformation should not depend on us being there indefinitely. Building that internal capability – the people, the processes, the data fluency – is as much a part of the work as the technology itself.

Enable and sustain

The theme of these two blog posts is that transformation is something that needs to be rethought. The rethink I am proposing is not complicated, but it does require a shift in how organisations frame the question.

Stop asking: when does the transformation programme end?

Start asking: how do we build the capability to keep improving?

That means orienting around a vision; a ‘north star’ for where the organisation is trying to get to, rather than a fixed endpoint. It means accepting that the path will not be linear, that the environment will change, and that some of what you planned will turn out to be the wrong thing. It also means investing in the foundations – the data, the people, the governance – that make continuous improvement possible rather than episodic.

Finally, it means resisting the language that treats transformation as a time-bounded event with a beginning, a middle, and a triumphant end. Real transformation is not something you finish. It is something you sustain.