Why transformation programmes produce reports and nobody changes how they work

Transformation programmes stall because they treat the report as the change. A diagnosis is written, a target operating model is approved, a communication plan goes out, and Monday morning looks exactly like last Monday. People change how they work when their own routines are redesigned, by them, in the time they actually have, with the old way switched off. Until that happens, a transformation is a document.

The belief, stated fairly

The belief runs: if we diagnose the organisation properly, design the right future state and communicate it clearly, people will move towards it. Resistance is a communication problem. More clarity, more engagement sessions, more senior sponsorship, and the change will land.

There is truth in it. A shared diagnosis matters. People do need to understand why things are changing, and visible senior backing makes a real difference. John Kotter's well-known eight-step model puts urgency, a guiding coalition and a communicated vision at the front for good reason. Without those, nothing moves.

The mistake is assuming that once people understand the destination, they will find their own way there.

Why it fails in practice

Work lives in routines, not documents

What an organisation actually does is a set of routines: how a case is opened, who approves what, what the weekly meeting looks at, which spreadsheet people trust. A target operating model describes the future at the level of boxes and lines. It rarely goes down to the routine: what does this team do differently at 9am on Sunday? If nobody designs that level, people keep doing what they did, because that is what their week is built around.

The thinking was done by someone else

Many programmes are diagnosed and designed by a central team or outside advisers, then "rolled out". The people who will live with the change see the answer without having seen the reasoning. They spot the parts that won't work on their floor, and nobody asked them. A design you did not help make is easy to agree with in a workshop and easy to ignore afterwards. (On keeping ownership when outside help is involved, see Bringing in outside experts without losing ownership.)

Nothing was taken away

New ways of working are almost always added on top of the old ones. The new dashboard arrives, and the old monthly report is still due. The new agile ceremonies start, and the old approval committee still meets. People do both for a while, then quietly drop the new one, because the old one is what they are still judged on.

The forces holding things in place were never named

Kurt Lewin's force-field analysis is a simple reminder that any situation is held steady by forces pushing for and against change. Programmes spend almost all their energy adding pushing forces: messages, sponsors, training. They rarely work on the restraining forces: the appraisal that rewards the old behaviour, the policy that requires the old step, the manager whose authority depends on the old process.

Progress is reported as activity

Workstreams report "assessment complete", "design approved", "training delivered to 400 staff". All true, all activity. None of it says whether the work changed. Because the programme's reporting looks healthy, nobody notices that the floor hasn't moved. (The alternative is set out in Measuring transformation by outcomes, not activity.)

What works instead

1. Change one routine at a time, with the team that runs it. Pick a real routine, such as how a complaint is handled or how the weekly priorities are set. Have the team map how it works today with a process flowchart, then redesign it themselves. The central team facilitates; it does not deliver the answer.
2. Name what holds the old way in place. Run a force-field analysis with the team and their manager. Then work on the two or three strongest restraining forces before adding any more communication.
3. Switch something off. Every new routine needs a stop-doing list: the old report, meeting, approval or form it replaces. Agree the date the old one ends, and have the senior sponsor announce it.
4. Rehearse before rolling out. Walk through the new routine with the people who will run it, using role-play with real cases. You find the gaps in an afternoon instead of in the first month.
5. Make roles explicit. When a routine changes, decisions move. A RACI for the new routine stops the old owners pulling decisions back.
6. Review the routine, not the programme. After two and four weeks, hold a short retrospective with the team: what are we actually doing now, what slipped back, what needs adjusting. Then move to the next routine.

The report still exists, but it becomes a by-product: a record of routines that have changed, written after the fact.

An example

Illustrative. A national health insurer in Europe ran an 18-month programme to become "customer-led". The diagnosis was thorough, the target operating model was approved by the board, and every manager attended a two-day workshop. A year later, claims handlers were working exactly as before.

The programme lead changed approach. Instead of rolling out the model, she asked one claims team to pick the routine that annoyed customers most. They chose the handling of incomplete claims, which were returned by letter and joined the back of the queue. The team mapped it, named the restraining forces (a productivity target that counted letters sent, and a rule that only supervisors could phone customers), and redesigned it: the handler phones the customer the same day and keeps the claim. The old letter template was withdrawn, the target was changed for that team, and the rule was lifted.

After a month's retrospective, the team adjusted the call script and the next team asked to do the same. The programme's progress report now listed routines changed, not workshops held.

Do's and don'ts

Do

• Go down to the level of the routine: who does what, when, with which tool.
• Let the team that runs the work redesign it, with facilitation.
• Remove the old way on a named date.
• Work on the forces holding the old way in place, not only on enthusiasm for the new.
• Report changes in how work is done, not tasks completed.

Don't

• Treat an approved target operating model as the finish line.
• Confuse attendance at training with adoption.
• Run the new process alongside the old one with no end date.
• Answer every sign of resistance with more communication.
• Try to change every routine at once. Sequence them.

Questions people ask

Isn't this just change management? It overlaps with it. Classic change management often focuses on preparing people for a change that has been designed elsewhere. The approach here puts the design of the change into the hands of the people doing the work, routine by routine. Communication and sponsorship still matter; they just aren't enough.

What do we do with the transformation report we already have? Use it as the map, not the vehicle. Pull out the routines it implies will change, sequence them, and start with one team and one routine. Plan that sequence as a transformation roadmap teams own.

How fast can this go? One routine with one team can be redesigned, rehearsed and running within a few weeks. It feels slower than a big rollout at the start and is much faster at the end, because what changes actually stays changed.

Where to go next

This piece belongs to the hub's main article, Transformation fails at the customer's door. To work on your own routines, start with a process flowchart of how the work runs today, a force-field analysis of what keeps it that way, and a stop-doing list for what the new routine replaces.