Change Management Planner

Change Management Plan Skill

Produces a structured change management plan — because most change initiatives fail not because the change is wrong, but because people aren't brought along with it.

Required Inputs

Ask the user for these if not provided:

• The change (what is changing, and what is the current state?)
• Scale (how many people affected, in how many teams/locations?)
• Timeline (when does the change go live? How long is the transition?)
• Sponsor (who is accountable at senior level?)
• Key concern (what is the biggest risk to adoption?)
• What happens if change fails (consequences of low adoption)

Output Structure

---

Change Management Plan: [Change Name]

Change sponsor: [Executive owner] Change manager: [Who is running this] Go-live date: [Date] Affected population: [N people, N teams/locations]

---

1. Change Summary

From (current state): [Specific description of today's situation] To (future state): [Specific description of what changes] Why this change is happening: [Honest explanation — people adopt change faster when they understand the real reason] What stays the same: [Explicitly naming what is NOT changing reduces anxiety]

---

2. Stakeholder Analysis

Stakeholder group	Size	Impact level	Current sentiment	What they need
[Group]	[N]	High/Med/Low	Supportive / Neutral / Resistant	[Specific concern or need]

Key influencers to engage early: [Name the informal leaders, respected voices, and early adopters who can help. And the resistors who need direct attention.]

---

3. Impact Assessment

Area	Impact	Severity	Action needed
Daily workflow	[What changes day-to-day]	High/Med/Low	[Training / support / redesign]
Systems or tools	[What tools are affected]
Roles and responsibilities	[Any role changes]
Processes	[Process changes]
Metrics and targets	[Any KPI changes]

---

4. Communication Plan

Core message: [The 1-sentence summary everyone should understand and remember]

Audience	Message focus	Channel	Timing	Owner
All staff	[Why this is happening + what to expect]	All-hands / Email	[T-6 weeks]	Sponsor
Managers	[How to support their teams]	Manager briefing	[T-5 weeks]	Change manager
Directly affected teams	[What changes for them specifically]	Team meeting	[T-4 weeks]	Line manager
[Other group]	[Tailored message]

Communication principles:

• Over-communicate — people need to hear a message 7 times to internalise it
• Use managers to cascade, not just top-down announcements
• Create a feedback channel — questions left unanswered become rumours

---

5. Training and Support Plan

Audience	Training type	Timing	Duration	Delivery	Owner
[Group]	[e.g. Hands-on system training]	[T-2 weeks]	[2 hours]	[In-person / online]	[Owner]

Go-live support:

• [What support is available on day 1 — helpdesk, floor walkers, champions]
• [Escalation path for issues in first 30 days]

---

6. Resistance Management

Anticipated resistance sources:

Concern	Who holds it	Root cause	Response
[e.g. "This will increase my workload"]	[Middle managers]	[Loss of autonomy]	[Specific action to address]

Resistance management principles:

• Acknowledge concerns genuinely — dismissing resistance amplifies it
• Involve resistors in design where possible — converts them into advocates
• Distinguish between genuine concerns (worth addressing) and preference for the status quo (to be managed, not solved)

---

7. Adoption Metrics

Metric	Baseline	Target	Measurement point	Owner
[System usage rate]	[0%]	[80%]	[30 days post go-live]	[Owner]
[Process compliance]	[X%]	[Y%]	[60 days]	[Owner]
[Staff confidence score]	[Survey score]	[Target]	[90 days]	[Owner]

Adoption milestones:

• D+7: [First check — early issues identified]
• D+30: [First adoption review]
• D+90: [Sustained adoption confirmed or remediation plan activated]

---

Quality Checks

• "What stays the same" is explicitly addressed
• Stakeholder analysis includes resistors, not just supporters
• Communication plan uses managers to cascade (not just top-down)
• Training is timed before go-live (not after)
• Adoption metrics have a measurement date and owner
• Resistance management has specific responses (not just "communicate more")

Anti-Patterns

• Do not treat communication as a one-time announcement — people need to hear a message multiple times before they internalise it; plan for repeated touchpoints
• Do not assign change management to a single owner without involving line managers — managers are the most effective cascade channel and must be briefed before their teams
• Do not schedule training after go-live — people who learn a new system on the day they need to use it will revert to the old process
• Do not ignore resistors in the stakeholder analysis — resistors who are not explicitly engaged will undermine adoption, especially informal leaders
• Do not measure adoption only at go-live — the real test is sustained adoption at 90 days, when novelty has worn off

Example Trigger Phrases

• "Write a change management plan for [initiative]"
• "Help me plan the rollout of [system change] for [team/org]"
• "Create a communication and training plan for [change]"
• "How do I manage resistance to [change]?"