| 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:
- What is changing (clear, specific, no jargon)
- Why it is changing (the business reason + benefit to them)
- How it affects them (specific changes to their experience)
- What support is available (training, resources, contacts)
- 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:
- Are people actually using the new process/tool?
- Have the expected benefits materialized?
- What unexpected issues have surfaced?
- 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.
