Change Management Roadmap: 6-Phase Template With Owners
8 min read ยท 2026-10-25
A change management roadmap is the plan for the people side of a change. It shows when you will build sponsorship, assess who is affected, communicate, train, support go-live and make the new way of working stick. The project plan covers the system or the reorganization. The change roadmap covers whether people actually adopt it.
The template below covers six months in six phases, which suits a mid-size change like a new CRM, a new finance process or a team restructure. Each phase has a goal, concrete steps and a milestone you can check. The guide also covers who owns what, a filled-in example, the metrics to report and how to present the roadmap to a steering committee. Stretch the middle phases for a company-wide change, and compress them for a single team.
The roadmap at a glance
Goal: The affected teams use the new process or system as their normal way of working, adoption is measured against a target, and ownership has moved from the project to the business. Duration: 6 months
Define the change and secure sponsorship (Weeks 1-3)
Agree on what is changing, why, and who will lead it visibly.
- Write a one-page change brief: what changes, why now, what happens if nothing changes, and what success looks like.
- Name an executive sponsor and agree on what they will do: messages, town halls, steering decisions.
- Set two or three adoption targets, such as active use of the new system or share of work done in the new process.
- Align the change timeline with the project plan so training and communications match the real go-live date.
Milestone: Change brief signed by the sponsor, with adoption targets and a sponsor calendar for the next three months.
Assess impact and readiness (Weeks 3-6)
Know which groups are affected, how much, and how ready they are.
- List every affected group and describe what changes for each: tasks, tools, reports, roles and decision rights.
- Rate the impact on each group as high, medium or low.
- Run a short readiness survey and a few focus groups to find concerns early.
- Map key stakeholders by influence and attitude, and decide how to engage each one.
- Check for other changes hitting the same teams at the same time.
Milestone: A change impact assessment and stakeholder map, reviewed with the sponsor and the people managers of the high-impact groups.
Plan communications, training and champions (Weeks 6-10)
Build the plans that will carry each group from awareness to ability.
- Write a communication plan: message, audience, channel, sender and date for each touchpoint.
- Design role-based training, with short sessions tied to the tasks each group will do.
- Recruit a change champion in each team and give them early access and a briefing pack.
- Prepare people managers with talking points and an FAQ so they can answer questions in their own teams.
Milestone: Communication plan, training plan and a named champion for every affected team, approved by the sponsor.
Prepare people before go-live (Weeks 10-16)
Make sure every affected person knows what changes and can do their new tasks.
- Run the sponsor kickoff message and manager-led team briefings.
- Deliver training close to go-live so skills are fresh, and track attendance by team.
- Hold demo sessions and open Q&A run by champions.
- Run a second readiness check and close the gaps it finds.
- Agree on the go-live support model: floor walkers, help channel and escalation path.
Milestone: Training completion at target for every team, and a go or no-go readiness review held with the sponsor.
Go-live and early support (Weeks 16-20)
Help people through the first weeks when the change feels hardest.
- Staff hypercare: champions and project team members available in each team during the first weeks.
- Hold short daily check-ins with champions to collect issues and fix the top ones fast.
- Share quick wins and fixes in a weekly update so people see that feedback leads to action.
- Track usage data and support tickets by team to find groups that are falling behind.
Milestone: Hypercare closed, the top reported issues fixed or scheduled, and adoption data reported by team.
Reinforce and hand over (Weeks 20-26)
Make the new way of working the default and hand ownership to the business.
- Retire the old tools, reports or workarounds on a set date.
- Add the new process to onboarding for new hires and to team routines and metrics.
- Coach teams with low adoption, and recognize teams that hit their targets.
- Run a lessons-learned session and hand over ownership to the business process owner.
Milestone: Adoption targets met or a recovery plan agreed, old tools retired, and a named business owner in place.
Change management roadmap vs project plan
A project plan answers "when will the system, process or structure be ready". It tracks build, testing and go-live. A change management roadmap answers "when will people be ready, and will they use it". It tracks sponsorship, impact, communication, training, support and reinforcement.
The two must share the same dates. If go-live moves, training and communications move with it. Many teams put the change roadmap as its own swimlane under the project timeline, so the steering committee sees both on one page. The project can finish on time while adoption fails, which is why the change roadmap keeps going after go-live.
Example: a change roadmap for a CRM rollout
Picture a sales organization of about 150 reps across three regions moving from spreadsheets and an old contact database to a new CRM. Reps worry about extra admin. Sales managers worry about forecast accuracy during the switch.
Notice that the old spreadsheets are retired on a fixed date. As long as the old tool works, many people will keep using it.
- Weeks 1-3 (owner: VP of Sales as sponsor, change lead): change brief, target that all reps log opportunities in the CRM, sponsor video planned. Milestone: brief signed.
- Weeks 3-6 (owner: change lead): impact rated high for reps and managers, medium for sales ops, low for finance; survey shows fear of double entry. Milestone: impact assessment reviewed.
- Weeks 6-10 (owners: change lead, sales enablement): one champion per sales team, role-based training for reps and managers, manager FAQ on forecasting. Milestone: plans approved.
- Weeks 10-16 (owners: sales managers, champions): team briefings, training in the two weeks before go-live, double entry removed by a data import. Milestone: training at target, go decision.
- Weeks 16-20 (owner: project manager with champions): floor support, daily champion stand-up, weekly fix list. Milestone: usage reported by team.
- Weeks 20-26 (owner: sales operations manager): spreadsheets retired, CRM data used in the weekly forecast call, onboarding updated. Milestone: handover to sales operations.
Who owns what
Change management works through people who already have influence over the affected teams. The change lead plans and coordinates, but managers and the sponsor do most of the persuading.
Write these roles into your RACI and confirm the time each person can give. A sponsor who cannot attend the kickoff or a champion with no time freed up is a risk to log, not a detail.
- Executive sponsor: explains why the change matters, makes trade-off decisions, removes blockers and shows up at key moments.
- Change lead or change manager: owns this roadmap, the impact assessment, the communication and training plans, and adoption reporting.
- People managers: brief their teams, answer questions, coach individuals and hold the team to the new way of working.
- Change champions: test early, give feedback, help peers and report issues during go-live.
- Project manager: keeps the project and change timelines aligned and manages the dependencies between them.
- HR, training and communications partners: role changes, training delivery and internal channels.
Metrics to track
Measure both activity and outcome. Activity metrics, like training attendance, tell you if the plan is running. Outcome metrics, like usage, tell you if the change is working. Report them by team, not only as one company number, because adoption problems are usually local.
Set the baseline before go-live and the targets in the change brief. Report the same table at every steering committee.
- Readiness: survey scores on awareness and confidence, run before training and again before go-live.
- Training completion: share of each team trained before go-live, from the learning system or attendance lists.
- Usage: active users and key actions in the new system or process, from system logs or reports.
- Proficiency: errors, rework or help desk tickets per team in the first weeks.
- Old way still in use: logins to old tools, shadow spreadsheets or manual workarounds.
- Business outcome: the result the change was meant to improve, such as forecast accuracy or processing time.
How to present it to the steering committee
Put the roadmap on one slide: six phases as columns across the top, the milestone under each, and today's position marked. Add a small box with the adoption targets and the current status for each high-impact group, using green, amber and red.
On the second slide, show the top risks and the decisions you need. Typical asks are sponsor time for a town hall, managers released for training, or a firm date to retire the old tool. Leave out the full communication calendar and training schedule. Bring them as backup if someone asks.
How ADKAR and Kotter fit into the roadmap
Many change teams use a model to check that the plan covers each stage people go through. Prosci's ADKAR model names five outcomes for each person: Awareness, Desire, Knowledge, Ability and Reinforcement. Kotter's eight-step model looks at the organization level, starting with a sense of urgency and a guiding coalition, and ending with making the change part of the culture.
You do not need to pick one to use this roadmap. Phases 1 and 2 build awareness and sponsorship. Phases 3 and 4 build knowledge and ability. Phases 5 and 6 cover reinforcement. If your company already uses a model, label the phases with its terms so the roadmap matches how leaders already talk about change.
Common mistakes to avoid
- Starting change work two weeks before go-live leaves no time to build support, so start the change roadmap at the same time as the project.
- Relying on emails from the project team gets little attention, so have the sponsor explain why and managers explain what it means for each team.
- Training everyone the same way wastes time and misses real tasks, so build short role-based sessions based on the impact assessment.
- Training too early means people forget before go-live, so schedule training in the last weeks before launch and offer refreshers after.
- Leaving the old tool running gives people an easy way back, so set and announce a firm date to retire it.
- Stopping at go-live leaves adoption unmeasured, so track usage by team for several weeks and coach the teams that fall behind.
Frequently asked questions
What should a change management roadmap include?
It should include a change brief, sponsorship plan, impact assessment, stakeholder map, communication plan, training plan, go-live support and reinforcement. Each phase needs an owner, dates aligned with the project plan, and a milestone you can check.
How long does a change management roadmap cover?
It usually runs from the start of the project until well after go-live, so adoption can be measured. A team-level change may need a few months, while a company-wide transformation can span a year or more. Plan reinforcement time after go-live in every case.
Who is responsible for change management?
A change lead usually owns the plan, but the executive sponsor and people managers do much of the work with employees. Champions in each team help peers and pass feedback back. HR, training and communications support the delivery.
How do you measure the success of a change?
Track readiness before go-live, then usage, proficiency and the business result the change was meant to improve. Compare each team against the targets in the change brief. Watch for signs that people are still using the old way.
What is the difference between change management and project management?
Project management delivers the solution on time and within scope. Change management makes sure people accept and use it. Both need to run together with shared dates and shared reporting.