---
name: change-management-plan
description: "Creates change management plans with stakeholder analysis, communication strategy, and transition timelines for smooth business changes."
allowed-tools: Read Write Glob
metadata:
  author: matthewhitcham
  version: "1.0"
---

# Change Management Plan

## When to Use This Skill

Use this skill when you need to:
- Plan a major business change (new tool, process, pricing, team restructure)
- Create a stakeholder communication strategy for an upcoming transition
- Build a timeline for rolling out changes with minimal disruption
- Manage resistance and get buy-in from affected parties

**DO NOT** use this skill for personal habit changes, product launches, or project management. This is for managing internal business transitions.

---

## Core Principle

PEOPLE DO NOT RESIST CHANGE — THEY RESIST BEING CHANGED WITHOUT INPUT, CONTEXT, OR PREPARATION. A CHANGE MANAGEMENT PLAN ADDRESSES ALL THREE.

---

## Phase 1: Define the Change

Clarify what is changing and why before planning the rollout.

### Required Inputs

| Input | What to Ask | Default |
|-------|------------|---------|
| **Change description** | "What is changing? Be specific." | No default |
| **Reason for change** | "Why is this change happening now?" | No default |
| **Scope** | "Who is affected? (team, clients, vendors, all)" | Team members |
| **Timeline** | "When does this need to be fully implemented?" | 30 days |
| **Risk of not changing** | "What happens if you do NOT make this change?" | No default |
| **Previous change attempts** | "Has this been tried before? What happened?" | First attempt |

### Change Impact Assessment

```
## Change Impact Assessment

**Change:** [Description]
**Type:** [Process / Tool / Structure / Policy / Pricing]
**Urgency:** [Immediate / Planned / Strategic]

| Impact Area | Current State | Future State | Impact Level |
|-------------|-------------|-------------|-------------|
| Daily workflow | [How it works now] | [How it will work] | High/Medium/Low |
| Tools/systems | [Current tools] | [New tools] | High/Medium/Low |
| Team roles | [Current structure] | [New structure] | High/Medium/Low |
| Client experience | [Current experience] | [New experience] | High/Medium/Low |
```

**GATE: Confirm the change definition before stakeholder analysis.**

---

## Phase 2: Stakeholder Plan

Identify who is affected and how to bring them along.

### Stakeholder Map

```
## Stakeholder Analysis

| Stakeholder | Impact Level | Current Attitude | Desired Attitude | Key Concern | Action |
|-------------|-------------|-----------------|-----------------|-------------|--------|
| [Name/Group] | High/Med/Low | Supportive/Neutral/Resistant | Supportive | [Concern] | [Approach] |
```

### Communication Plan

```
## Change Communication Plan

| Audience | Message | Channel | Timing | Owner |
|----------|---------|---------|--------|-------|
| Core team | Full context + rationale + timeline | Meeting | Week 1 | [Name] |
| Clients | What changes for them + benefits | Email | Week 2 | [Name] |
| Vendors | Operational adjustments | Email | Week 2 | [Name] |
```

### Message Framework

For each audience, structure the message as:

1. **What is changing** (clear, specific, no jargon)
2. **Why it is changing** (the business reason + benefit to them)
3. **How it affects them** (specific changes to their experience)
4. **What support is available** (training, resources, contacts)
5. **Timeline** (when it starts, key dates, when it is complete)

**GATE: Present stakeholder plan for review.**

---

## Phase 3: Transition Timeline

Build the phased rollout plan.

### Transition Phases

```
## Change Rollout Timeline

### Phase 1: Prepare (Week 1-2)
- [ ] Announce the change to all stakeholders
- [ ] Distribute FAQ document
- [ ] Set up new tools/processes in parallel (not replacing old ones yet)
- [ ] Identify change champions who can support others
- [ ] Schedule training sessions

### Phase 2: Pilot (Week 2-3)
- [ ] Small group tests the new process/tool
- [ ] Collect feedback and fix issues
- [ ] Document common questions and solutions
- [ ] Update training materials based on pilot feedback

### Phase 3: Rollout (Week 3-4)
- [ ] Full team transitions to the new way
- [ ] Old process/tool remains available as fallback (sunset date set)
- [ ] Daily check-ins during first week of rollout
- [ ] Dedicated support channel for questions

### Phase 4: Stabilize (Week 4+)
- [ ] Sunset old process/tool
- [ ] Address remaining issues
- [ ] Document the new process as the standard
- [ ] Celebrate wins and acknowledge the effort
```

### FAQ Template

```
## Change FAQ: [Change Name]

**Q: Why are we making this change?**
A: [Answer]

**Q: When does this take effect?**
A: [Answer]

**Q: What do I need to do differently?**
A: [Answer]

**Q: What if I have problems with the new [tool/process]?**
A: [Answer]

**Q: Can we go back to the old way?**
A: [Answer]
```

---

## Phase 4: Sustain

Ensure the change sticks and deliver the intended benefits.

### Success Metrics

Define 2-3 metrics that prove the change is working:

```
## Change Success Metrics

| Metric | Before Change | Target (30 days) | Target (90 days) |
|--------|-------------|-----------------|-----------------|
| [Metric] | [Baseline] | [Target] | [Target] |
```

### Post-Change Review

At 30 and 90 days:
1. Are people actually using the new process/tool?
2. Have the expected benefits materialized?
3. What unexpected issues have surfaced?
4. What additional support is needed?

---

## Anti-Patterns

- **Announcing without context** — "Starting Monday, we use [new tool]" creates instant resistance. Lead with why.
- **Big bang rollout** — switching everything overnight maximizes disruption. Phase the transition.
- **Ignoring resistance** — resistance is feedback. Listen to it, address it, do not dismiss it.
- **No training** — expecting people to figure it out themselves guarantees frustration and workarounds.
- **Changing too many things at once** — one major change per quarter. Stacking changes causes burnout.

---

## Recovery

- **Team is actively resisting:** One-on-one conversations, not group announcements. Understand individual concerns.
- **Change was rolled out too fast:** Pause, acknowledge the disruption, and reintroduce with a proper timeline.
- **Change is not delivering expected results:** Check if it is an adoption problem (people not using it) or a strategy problem (the change itself was wrong).
- **User is making the change alone (solopreneur):** Focus on client communication and personal habit change. Use the pilot phase to test before fully committing.
- **Stakeholders were not consulted:** It is not too late. Hold a feedback session, incorporate input, and adjust the plan.
