A project plan tells you what you’re building.
A change management plan tells you how to make people actually use it.

That’s where most teams go wrong.

They deliver the system. Launch the process. Check the box.
And then nothing changes.

Because they forgot the people.

This is how you build a real change management plan from scratch—one that works in the real world, not just in theory.

1. First: Know What Change You’re Managing

Don’t just say, “We’re rolling out a new tool.”

Be precise:

• What are people doing now?
• What will they do differently after the change?
• What’s going to be uncomfortable or unfamiliar for them?

If you can’t explain the change in a sentence that makes sense to someone on the ground, you’re not ready to build the plan.

2. Map the People (Not Just the Process)

Change doesn’t affect org charts. It affects real people.

So:

• List out who is impacted. Not just teams—individual roles.
• Identify how they’re impacted (directly, indirectly, emotionally, politically).
• Flag influencers, resistors, and quiet champions.

If you skip this, your messaging will miss the mark. Guaranteed.

3. Assess the Change Impact

This is where change planning gets sharp.

Ask:

• What’s changing for each group?
• What are they losing, gaining, or needing to unlearn?
• What’s the risk if they ignore the change?

Build a simple matrix:
Low/Medium/High Impact vs Low/Medium/High Risk.
That becomes your guide for prioritising attention, comms, and support.

4. Plan Your Communication (Don’t Just Spam)

This is not “send a launch email” and move on.

Real comms planning includes:

• What people need to know (not what you want to say).
• When they need to hear it.
• Who they need to hear it from (hint: not always the project team).
• How they’ll hear it—email, face-to-face, video, Slack, stand-ups, etc.

The golden rule: Don’t broadcast. Engage.

5. Build Support Structures Early

Don’t wait until go-live to figure out support.

Set this up early:

• Identify champions inside teams.
• Create Q&A hubs or drop-in clinics.
• Run “train the trainer” sessions.
• Make sure people know who they can go to when they’re stuck.

If people feel alone, they’ll go back to what’s familiar—fast.

6. Create a Training & Enablement Plan

This part fails when training is generic, boring, or theoretical.

Your goal:

• Train for the job, not just the system.
• Keep it short, relevant, and hands-on.
• Use a mix of live sessions, self-serve guides, and quick how-to clips.

And always, always include feedback loops.
What people tell you in training is often more valuable than what’s in the deck.

7. Lock In Go-Live & Post-Go-Live Support

Most change plans fizzle right after launch. Avoid that by planning ahead.

I always include:

• A readiness checklist: is everyone prepped, tested, and briefed?
• A comms countdown: reminders that build clarity and momentum.
• Live support: named contacts, help channels, drop-ins, and actual humans who can solve problems.

Post-go-live support matters just as much as the pre-work. If not more.

8. Track Adoption (Not Just Completion)

Change isn’t finished when the project goes live. It’s finished when the change is embedded.

So measure:

• % of people using the new process or tool
• Drop in errors or time spent
• Uptake rates and usage logs
• Feedback and sentiment from users

If you’re not tracking adoption, you’re just guessing—and probably missing the mark.

Final Word: A Real Change Plan = Clarity + Momentum

Change doesn’t fail because people hate change. It fails because the change is unclear, unsupported, or dumped on them last-minute.

A proper change management plan:

• Makes the change understandable
• Makes adoption feel supported
• Builds trust, not friction

And most importantly: it helps the transformation actually stick.

Want the Template I Use?

👉 leadingbusinessimprovement.com – Step-by-step templates and real-world training to build change plans that stick.
👉 robertchapman.info/contact/ – Need help building a change plan that works? Let’s talk.