Stakeholder Impact Map

Stakeholder Impact Map

When to use

Segment stakeholders by influence and impact; name specific behavior, process, and system changes per group before readiness or comms work.

What this skill does not do

• Does not assess readiness — route to /change-management:change-readiness-assessment.
• Does not draft comms — route to /change-management:communications-plan.
• Does not design org structure — route to /operating-model:diagnose-structure-fit when installed.

Preconditions

| Input | If missing | |---|---| | Initiative scope or change description | Ask what is changing and for whom | | Practice profile | Proceed with default segments; [PROVISIONAL] | | TOM or roadmap output | Build from user input; note SOURCE |

Provisional mode

Without named groups: infer from scope; flag [review] on incomplete coverage.

Trust spine

Structured-aggregation bands; every segment tied to a concrete change; no generic "all employees affected."

Workflow

1. Read the practice profile — segmentation model and change methodology from config paths.

1. If transformation is installed, read /transformation:target-operating-model or /transformation:roadmap-builder output as seed — reuse stated capability, process, and org impacts rather than reinventing.

1. List stakeholder segments — not just names but roles/groups with similar change exposure (e.g. frontline ops, regional managers, finance close team).

1. For each segment, document:

• Influence — can accelerate or block adoption (high/medium/low with rationale).
• Impact — degree of behavior, process, system, or reporting change (high/medium/low).
• What changes for them — specific old → new behaviors; not "improved ways of working."
• What they lose — status, autonomy, familiar tools, relationships — resistance often starts here.
• Primary channel to reach them — from practice profile or inferred; flag if unknown.

1. Place segments on influence/impact grid — identify manage-closely (high/high), keep-informed, keep-satisfied, monitor.

1. Coverage check — flag segments with high impact but no identified owner or channel; flag "everyone" buckets that hide real differences.

Output format

SOURCE: [TOM / roadmap / user input]

SEGMENT: [name]
  Influence: [H/M/L] — [why]
  Impact: [H/M/L] — [why]
  What changes: [specific behaviors/processes/systems]
  What they lose: [named losses, or "none identified"]
  Grid quadrant: [manage closely | keep informed | keep satisfied | monitor]
  Reach channel: [channel or UNKNOWN — flag]

[repeat per segment]

COVERAGE GAPS: [high-impact segments with no owner/channel, or "none"]
GENERIC-BUCKET FLAGS: [segments too broad to action, or "none"]

Worked example

Input: CRM rollout, "sales team affected."

Expected output: Split by role (AE vs sales ops vs sales manager); each with different process change; flag generic bucket.

Quality checks before delivering

• [ ] Every segment has influence, impact, and specific changes
• [ ] Losses named where plausible
• [ ] Coverage gaps listed

Propose profile update

When a stable convention surfaces during this run (thresholds, naming, tone, output format, or recurring corrections), propose a profile update: show the exact diff against ~/.claude/plugins/config/claude-for-strategy/change-management/CLAUDE.md (org-wide facts go to org-profile.md), ask for confirmation, and write only on yes. Only /change-management:practice-setup auto-applies a full profile write.

Outputs

Follows plugin CLAUDE.md § Outputs. Next: change-readiness-assessment or communications-plan.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: daddia
• Source: daddia/claude-for-strategy
• License: MIT

Install and usage instructions live in the source repository linked above.