Framework library · Change management
Organisational transformation roadmap
A transformation roadmap puts every workstream of a large change on one timeline: how it is governed, what happens to people and roles, which processes and systems change, and what customers and partners see. Its value is in the dependencies between lanes, which show the order the change has to happen in and which single item, if it slips, moves everything after it.
Use it when
- A change touches strategy, structure, people, processes, systems and customers at once, and each has its own plan.
- A board needs one view of the sequence, the critical dependencies and who owns each part.
- Workstreams are planning in isolation and keep discovering late that they depend on each other.
Avoid it when
- The direction is not yet decided. A roadmap shows a chosen path. Settle the strategy first with scenario planning or an options appraisal.
- You need a detailed delivery schedule with tasks and resources. Use a project plan under each lane; the roadmap is the level above.
- The change is a single technology programme. Use a technology roadmap, which layers market, product, technology and resources.
How to run it
Set the end state and the horizon
Describe what will be true when the transformation is done, in a few sentences, and pick periods that fit: quarters over two years is common.
Agree the lanes
Governance, people, processes, technology and customers is a good default. Add a lane for anything with its own owner and budget, such as a site closure or a regulatory approval.
Place the items and the milestones
Each item is a piece of work with an owner and a start and end. Milestones are dated events: a board decision, a contract signature, a go-live, a closure.
Write what each item depends on
Most of the insight comes from links across lanes: a process cannot change before the system that supports it, and people need to be consulted before roles change.
Write how you will know each item is done
An observable result, not an activity: "two providers taking orders through the interface", not "interface built".
Find the critical chain and protect it
Trace the dependencies back from the end state. The item that everything else waits on gets the sponsor's attention and a fallback.
Work through it
Answer the questions below, or load the worked example to see a finished one. The drawing updates as you type. Export the result as a PowerPoint deck, a Word document, an Excel workbook, a PDF or plain text.
What you type stays in this browser, so you can close the page and come back to it. It is not sent to Blue Prysm or anyone else, and the exports are made here, on your device. Privacy policy.
Mistakes to avoid
- Putting only technology on the roadmap, so people and process changes are discovered late and squeezed.
- Leaving the old world out. Decommissioning systems, closing contracts and ending roles take time and need their own items.
- Precise dates in the second year. Show the far end coarsely and firm it up at each review.
- A roadmap that nobody reviews. Bring it to the transformation board every month and change it when the facts change.
Where it comes from
No single originator. The roadmap rests on the idea, set out by Richard Beckhard and Reuben T. Harris in Organizational Transitions: Managing Complex Change (Addison-Wesley, 1977; second edition 1987), that a large change is managed as a transition state between the present and a defined future, with its own management arrangements. The lanes across time follow technology roadmapping practice. Source.
Use it with
Further reading
Work through it with us
The frameworks here are free to use as they stand. If you would rather work through the question behind this one with us, these are the ways an engagement starts.