How to write a change management plan
Geert Barandat · updated 26 September 2026
A change management plan sets out what has to change for which group, when, and how you will know it holds. It is not a project plan with a chapter on people. It follows the people, not the deliverables.
A project plan with a different subject
A project plan tracks what gets built. A change plan tracks who works differently afterwards. They share a timeline, and often the same go-live date. But for the project, go-live is the finish. For the change, it sits somewhere in the middle.
So you plan in groups, not in deliverables. The planning team starts with the new tool in March. The night shift follows in May, once the first problems are out. The team leads carry it from June. Each group has its own run-up, its own peak and its own moment when the new way should hold without you.
What goes in it
A change management plan holds a set of sub-plans, each a band on the same timeline: people and resources, sponsors, engagement, communication, learning, measuring and benefit, embedding. Not every change fills all of them. A small change in one team might fill two. What matters is that they sit together, so you see where they collide. Between the bands sit three kinds of marks. Milestones say what has to be true by a date. Measurement points say when you look whether it works, and how. Dependencies say what cannot start before something else is done: the sponsor's message before the training, the training before the new tool opens.
Click to enlarge
Plan the moment, not only the activity
Most change plans list the right activities at the wrong moment. Training given three months before go-live is forgotten by the time it counts. A message sent in the week of the year-end close goes unread. So the question is not only what you do. It is when a group can take it in.
That is why a group moves in waves. The innovators and early adopters go first. The early majority follows once it has seen them get through it, the late majority after that. The traditionalists come last, and usually for a reason. Each wave gets its own milestone in the plan, instead of one date for everyone.
It ends when the behaviour holds
A change plan that stops at go-live stops too early. The last part is anchoring: for each new behaviour, who owns it and how you can tell it sticks. The plan closes with a completion milestone. On that day the watch moves on. Each behaviour keeps its measurement point and its rhythm, so whoever looks next measures the same way.
A plan that moves with what you hear
The first version of your plan is an estimate. That is fine, as long as it can change. When the change agents come back with something different, the plan moves with it. A plan written once and filed is a photograph of what you believed in week one.
In Cohentis, the plan is built from your work
Click to enlarge
Your planning stands as a list. Each sub-plan holds its plan items, numbered and nested: 10, 10.1, 10.2. The milestones have a band of their own, and you choose which one is the go-live of the plan and which one the completion. The same work lies on a timeline, one band per sub-plan. Point at a bar and you see what it depends on.
Measurement points hang on the work they belong to. When a measurement deviates from what you expected, your dashboard says so and takes you straight to the plan item. The groups come from your stakeholder map, so every plan item carries names you already know.
The plan closes with embedding: per behaviour who carries it, and a measurement point that shows whether it holds. And if your change runs inside a portfolio, your working file goes to the portfolio, which takes a snapshot of it. So the portfolio sees what lands on whom, and when.
Common questions
What is a change management plan?
A change management plan sets out what has to change for which group, when, and how you will know it holds. It follows the people, not the deliverables.
What belongs in a change management plan?
Sub-plans for people and resources, sponsors, engagement, communication, learning, measuring and embedding, each as a band on one timeline. Between them sit milestones, measurement points and dependencies. And for each group the moment it moves, in waves rather than one date for everyone.
How is a change management plan different from a project plan?
A project plan tracks what gets built and ends at go-live. A change management plan tracks which groups work differently, and ends when the new behaviour holds on its own.