---
description: "Create a structured change management plan for any organisational change. Use when asked to write a change management plan, manage a change initiative, plan a system rollout, or lead an organisational transformation. Produces a plan covering stakeholder analysis, impact assessment, communication strategy, and resistance management."
globs:
alwaysApply: false
---

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