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

Work from what is given. If any of these is missing, still produce the complete output: fill each gap with a reasonable assumption marked (assumed, confirm) and list those assumptions at the end. Ask a question first only when the core subject itself is missing (there is nothing to write about).

• 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]?"