← Catalog
skill Business

Change Management Plan

change-management-plan

Creates change management plans with stakeholder analysis, communication strategy, and transition timelines for smooth business changes.

Add this skill
  1. This skill, packaged and ready to upload. change-management-plan.zip
  2. In claude.ai or Claude desktop: Customize → Skills (+) → Create skill → Upload a skill, select the zip and toggle it on. Greyed out? Enable code execution under Settings → Capabilities.
  3. It’s live in your chats — no code, no setup. Want every Business skill at once? Add the whole plugin from the Business page (Customize → Personal plugins → Create plugin → Upload plugin).

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.

View source on GitHub →