Our transformation programme worked. It worked because we stopped trying to do all of it. The version that succeeded looked nothing like the plan I approved two years earlier, and the difference was sequencing rather than ambition.

I want to be specific about that, because most advice on digital transformation services stays at the level of vision. Vision was never our problem. Order was.

Our first attempt collapsed under its own scope. Eighteen months, every system, one date.

By month nine we had spent a great deal and shipped nothing anyone could use. The team was demoralised. The board had stopped asking how it was going, which is worse than being asked.

Nothing exotic caused that. We had committed to a plan written before we understood the systems. Then we defended the plan instead of the outcome.

The restart was smaller and it delivered. Same people. Same budget envelope. Different order.

The thing customers complained about

We picked the single process customers mentioned most. In our case it was a form that took nine days to produce an answer.

Fixing it took eleven weeks. It cut the wait to under a day. It also bought us something we badly needed, which was proof that the programme could deliver anything at all.

The process that ran on one person

Every company has one. A spreadsheet only one person understands. A monthly close that fails if she is on holiday.

We automated three of those. None was strategic. All of them removed a risk we had been quietly carrying for years.

The system nobody could change safely

Then we went after the hard one. The old platform where every change felt dangerous.

That took longer and was worth it. Once changes stopped being frightening, everything downstream got faster.

Here is the pattern that worked. Start where the pain is visible. Bank a win. Use the credibility to fund the harder work.

That is also how I would judge any legacy modernization roadmap put in front of me. A good one is ordered by risk and value, not by system age. It says what happens in the first quarter, not just the third year.

Be suspicious of any roadmap where nothing lands for twelve months. Long silences are how programmes lose their sponsors. A plan that produces something usable every quarter survives a change of budget mood. One that does not, will not.

There is a boring dependency underneath all of this, and we learned it the hard way.

Our first big release went out onto an estate we could not observe properly. When something broke, we spent hours arguing about whether it was the new system or the old one. Twice we rolled back changes that turned out to be fine.

Incident and problem management sounds like a topic for the operations team. It is not. It is what lets you tell whether a change worked. Without it, every release becomes a guess and confidence drains out of the programme.

We fixed that before phase two. Response times improved, and more importantly, arguments stopped.

If you are planning a large change programme, put incident and problem management in the first phase rather than the last. It is not glamorous and it will not excite a board. It is what makes everything after it measurable.

Our first procurement round asked vendors for a strategy. We got three impressive documents and no way to compare them.

The second round asked something narrower. Show us what you would deliver in the first ninety days, and tell us what we would own at the end of it.

That question sorted the field quickly. Two partners answered with something concrete. The others returned to talking about vision.

We also changed how we pay. A short first phase with a clear deliverable, then a decision point. Digital transformation services bought in one long block remove your ability to change your mind, and you will want to change your mind.

●      What will be usable at the end of this quarter, by whom?

●      Which of our current risks does this remove?

●      What are we choosing not to do, and are we comfortable saying that out loud?

●      How will we know in ninety days whether this is working?

●      If funding stopped after this phase, would we still be better off?

That final question is the one I would give any chief executive. Programmes that only pay off at the end are fragile. Ours had to leave the company better after every stage, and that constraint improved the plan more than any consultant did.

How long should a first phase be?

One quarter. Long enough to matter, short enough that a wrong assumption is cheap.

Should we modernise or rebuild?

Usually modernise. Rebuilds promise a clean result and deliver a long period with two systems running. Choose that only when the old system genuinely cannot do the job.

Do we need outside help?

Often, for capacity and for patterns you have not seen. Good digital transformation services should make your team stronger rather than create a permanent dependency. Ask what your people will know at the end.

Two years on, the visible results are modest. Some processes are faster. A few systems retired. Nothing that would make a magazine cover.

The real change is harder to photograph. We ship changes weekly now instead of quarterly. When something breaks, we know within minutes. People propose ideas without first checking whether the system will allow it.

That is what digital transformation services bought us. Not a new platform. The ability to keep changing without it hurting.

If your programme has been running for a year and nobody outside the project team has felt anything yet, the problem is probably not the technology. It is the order you chose. That is fixable, and it is cheaper to fix now than after another year.