Running a transformation roadmap that teams own

A transformation roadmap that teams own is one where leadership sets the outcomes and the limits, and the teams who will do the work write the steps, the order and the tests themselves. It is built in a few joint sessions rather than by a consultant alone, shows near-term work in detail and later work only as direction, and is revisited every month by the teams and re-planned every quarter with leaders. The test of ownership is simple: when a team leader is asked "why is this on the roadmap?", they can answer without opening a slide.

Why most roadmaps are owned by nobody

The usual transformation roadmap is a Gantt chart produced by a central office or an outside firm, approved by the executive committee and then handed to units to deliver. It fails in a predictable way. Units treat it as somebody else's plan. They report progress against it, because reporting is required, while carrying on with their real work. Dates slip, the central office re-baselines, and within a year the roadmap describes a programme that exists mainly in status reports. Why transformation programmes produce reports and nobody changes how they work explores that pattern in depth.

The cause is not poor discipline. It is that the people who know how the work actually runs had no say in the plan, so the plan is wrong in ways only they can see, and they have no reason to fix it.

Step 1: Start from the outcomes and the map, not a project list

A roadmap built from a list of initiatives ("new CRM", "process automation", "training programme") is a list of activities. Start instead from two or three outcomes the change is meant to produce for customers or citizens, written so that a customer would recognise them. The pillar article Transformation fails at the customer's door explains why this framing matters.

If you have mapped the system, bring the map. The places where change is likely to hold, identified in Mapping the system before you change it, become the first candidates for the roadmap. If you have not mapped the system, do that first. A roadmap without a diagnosis is a guess with dates on it.

Step 2: Leadership sets the frame, and only the frame

Leaders own four things and should write them down on one page:

1. The outcomes and how each will be recognised.
2. The choices: where the organisation will and will not play. A strategic choice cascade (from Lafley and Martin's Playing to Win) is a good way to force these.
3. The limits: budget envelope, regulatory constraints, things that cannot change this year.
4. The rhythm: when the roadmap will be reviewed and by whom.

An OGSM page (objective, goals, strategies, measures) does the same job in a format many leadership teams already know. What leaders should not write is the list of projects. That is the teams' work.

Step 3: Pass the frame down and let it come back changed

Japanese hoshin kanri practice uses the word catchball for the exchange that follows: leadership throws the frame to the next level, which works out what it would take and throws back what it can commit to, what it needs and what it disagrees with. Several rounds are normal. The hoshin-style annual alignment guide sets out how to run it.

In practice, give each team or cross-unit group the one-page frame and two weeks. Ask them to return with:

• The three to five pieces of work they believe will move the outcome most.
• The assumption behind each one.
• What they need from other units, and what they will stop doing to make room.

Expect pushback. A team that says "this outcome is unrealistic with the current approval rules" has just given you more value than a team that agrees to everything.

Step 4: Build the roadmap together, in lanes, not dates

Bring the teams together for a one-day roadmapping session. Lay out the returns on one wall, grouped by outcome. Then:

1. Sort by horizon. Use three horizons lanes: improving what runs today, extending it, and building what will replace it. Most transformations overload horizon one and leave horizon three empty, or the reverse.
2. Use now, next, later instead of a full calendar. The now-next-later format, popularised by Janna Bastow of ProdPad, commits firmly to the next quarter, loosely to the one after, and only to direction beyond that. It tells the truth about uncertainty.
3. Find dependencies and collisions. Where two teams need the same people or the same system in the same quarter, decide now.
4. Name one owning team per item. Not a person in the central office, the team that does the work. A RACI for the items that cross units prevents the "everybody is responsible" problem.

Step 5: Turn each item into a bet with a test

For every item in the "now" column, the owning team writes one line: "We believe that doing this will change that outcome, and we will know within this many weeks because we will see this signal." This is a hypothesis test in roadmap form.

The line does two jobs. It makes the reason for the work visible to anyone, and it gives the team permission to change course when the signal does not appear. A roadmap item that cannot be written this way is usually an activity looking for a purpose. How to choose signals that reflect real outcomes rather than activity is covered in Measuring transformation by outcomes, not activity.

Step 6: Run it on a rhythm the teams control

Ownership is kept or lost in the reviews.

• Monthly, team level. Each owning team reviews its own items: what moved, what was learned, what it will change. Use a short retrospective. The central office attends to listen and to remove blockers, not to grade.
• Quarterly, joint. Teams and leaders meet for half a day. Items move from "next" to "now", some are stopped, new ones arrive. Leaders may change the frame; teams may change the plan within it.
• Communication. A stakeholder communication plan decides who hears what after each quarterly review. People outside the programme should hear about changes from the teams that made them.

Keep the roadmap itself on one page per outcome. If it needs a forty-slide deck to explain, nobody will own it.

Illustrative example

Illustrative. A mid-sized insurer in Canada set out to cut the time to settle simple home-insurance claims. Its first roadmap, written by a consultancy, had 46 initiatives on a two-year Gantt chart. Eight months in, claims teams were reporting green on most items, and settlement times had not moved.

The insurer restarted. Leadership wrote a one-page frame: one outcome (a customer with a simple claim is paid within ten working days), two choices (focus on claims under a set value; no change to underwriting this year) and a quarterly rhythm. The claims, finance and IT teams had two weeks to respond. The claims team came back with a finding the original plan had missed: most delays came from waiting for a loss adjuster's visit on claims that did not need one. Their top roadmap item was a rule change, not a system.

The new roadmap had nine items across three lanes, each with an owning team and a signal. Two were stopped at the first quarterly review because the signal never appeared. Team leaders presented the roadmap to the board themselves.

Do's and don'ts

Do

• Write outcomes before initiatives.
• Keep leadership's contribution to one page: outcomes, choices, limits, rhythm.
• Let teams push back, and change the frame when they are right.
• Commit firmly only to the next quarter.
• Give every item an owning team and a signal.
• Stop items openly at quarterly reviews.

Don't

• Commission the roadmap from an outside firm and hand it down.
• Measure the roadmap by the percentage of items marked green.
• Fill the later columns with dates you do not believe.
• Assign items to the central transformation office. It supports, it does not own.
• Add items without removing anything. Ask every team what it will stop.

Questions people ask

What should a transformation roadmap include? The outcomes it serves, the items of work grouped by outcome and horizon, the owning team for each item, the signal that will show whether it is working, and the dates of the next reviews. Detailed dates belong only to the next quarter.

Who should own the transformation roadmap? Leadership owns the frame: outcomes, choices, limits and rhythm. The teams doing the work own the items, their order and their tests. The central transformation office keeps the roadmap visible and removes blockers, but owning it centrally is the most common reason teams disown it.

How often should a transformation roadmap be updated? Teams should review their own items monthly and the whole roadmap should be re-planned quarterly. An annual refresh is too slow; by the time it happens, the roadmap has stopped describing the real work.

Where to go next

The roadmapping, hoshin-style annual alignment, three horizons and RACI guides cover the four sessions described here. Before you start, read Mapping the system before you change it, so the roadmap begins from a diagnosis rather than a wish list.