Three Questions Before the First Workshop: What a Troubled Programme Taught Me

Most post-mortems are written after the invoices are settled and the language has been smoothed. This one is not. In late 2026 I closed out a transformation programme for a mid-sized UK services business that came far closer to failure than the board ever knew. We delivered the new operating model, but only after a six-week recovery period that cost the client money, goodwill and management attention. The lessons were not technical. They were about the questions I failed to ask at the start.

The warning signs were there in week one

The programme had a capable sponsor, a sensible business case and a steering group that met fortnightly. On paper, it looked well governed. In practice, the sponsor was accountable in name but not in behaviour. When the first trade-off arrived — a decision about which team would lose headcount under the new model — the steering group asked for more analysis rather than making a choice. That was the first signal.

The second signal was the plan itself. It assumed that operational managers would find roughly two days a week to support design workshops, data cleansing and testing. No one had checked whether those managers had two days a week to give. They did not. The plan was precise about activities and silent about capacity.

The third signal was language. Different workstreams used the same words — 'go-live', 'sign-off', 'ready' — to mean different things. One team meant that the system worked. Another meant that the process had been documented. A third meant that people had been trained. We did not discover this until the first integrated test, when three definitions of 'ready' collided in the same room.

The moment the plan stopped matching reality

The turning point came about ten weeks in. The programme was still reporting amber, largely because the reporting was measuring activity rather than outcomes. We had completed workshops, produced process maps and cleared actions. What we had not done was test whether the new operating model could survive a normal Monday morning.

When we ran a live simulation, the answer was clear. Handoffs between sales and operations were slower than the current process. A key approval had no named owner. The finance team could not close the month under the new structure without two temporary staff who had not been budgeted for. None of this was catastrophic on its own. Together, it meant the plan had become a fiction.

We stopped. We spent a week re-baselining with the sponsor, the operations director and the finance director in the same room. We cut two workstreams, delayed a third and reallocated decision rights. The recovery worked, but it was expensive. The client paid for a programme that had to be re-planned, and I paid in credibility.

Question one: Who owns the outcome when it becomes inconvenient?

A programme sponsor who attends meetings is not the same as a sponsor who makes decisions. I now ask a blunt question before accepting any transformation engagement: who will own the outcome when the choice becomes unpopular?

If the answer is a committee, I keep asking. Committees can govern; they rarely own. The person who owns the outcome must have the authority to move budget, change priorities and, if necessary, disappoint a senior colleague. They must also have the time to do it. A sponsor who is accountable but unavailable is a risk disguised as governance.

Question two: What must be true for the first ninety days to work?

This question forces the conversation away from the plan and towards the conditions. What must be true about data quality, management capacity, decision rights and frontline stability for the first ninety days to deliver anything useful?

On the troubled programme, the honest answer would have been that the first ninety days could not work as designed. The data was not clean enough, the managers did not have the time and the decision rights were unclear. We would have known that in week one if I had asked the question properly, rather than accepting the business case as evidence.

I now ask for evidence, not assurance. Show me the last three data extracts. Show me the managers' diaries. Show me who signs off the exception. If the evidence is not available, that is the finding.

Question three: How will we know early that we are wrong — and what will we stop?

Every programme needs tripwires. Not a risk log that is updated monthly, but specific evidence that would cause the sponsor to pause, re-plan or stop. On the troubled programme, we had risks. We did not have kill criteria.

I now agree three tripwires before mobilisation. They might be a test failure rate, a decision backlog, a capacity shortfall or a customer complaint threshold. The point is not to predict failure. The point is to make failure visible early enough to do something about it. The second half of the question matters just as much: what will we stop? A programme that cannot name what it will deprioritise is not a programme; it is an addition to the day job.

What I do differently now

I still believe in transformation. UK businesses need to change their operating models, adopt better systems and remove friction from their processes. But I am less impressed by plans and more interested in conditions. I spend longer in the diagnostic phase, ask more awkward questions and accept fewer assurances.

The result is not slower delivery. It is fewer recoveries. A programme that starts with honest answers to difficult questions is more likely to finish on time than one that starts with a polished plan and a hopeful steering group.

If you are about to commission a change programme, ask the three questions before the first workshop. If the answers are uncomfortable, that is useful. Discomfort before mobilisation is cheaper than recovery after go-live.