Stakeholder Analysis
Identify, analyze, and plan engagement strategies for project and initiative stakeholders. Based on BABOK v3 Elicitation & Collaboration knowledge area.
What is Stakeholder Analysis?
Stakeholder analysis systematically identifies all parties affected by or able to affect an initiative, assesses their interests and influence, and develops engagement strategies.
Core Deliverables
| Deliverable | Purpose | When to Create | |-------------|---------|----------------| | Stakeholder Register | Comprehensive list of all stakeholders | Project initiation | | Power/Interest Matrix | Prioritize engagement approach | Analysis phase | | RACI Matrix | Clarify roles and responsibilities | Planning phase | | Communication Plan | Structured engagement strategy | Planning phase |
Workflow
Phase 1: Stakeholder Identification
Step 1: Brainstorm Categories
Systematically identify stakeholders by category:
| Category | Examples | Questions to Ask | |----------|----------|------------------| | Sponsors | Executive sponsor, budget owner | Who funds this? Who can cancel it? | | Users | End users, power users, administrators | Who uses the solution daily? | | Operators | IT ops, support teams, maintenance | Who keeps it running? | | Regulators | Compliance, legal, audit | Who ensures we follow rules? | | Affected Parties | Other departments, displaced roles | Who is impacted by changes? | | Subject Matter Experts | Domain experts, technical leads | Who has critical knowledge? | | Decision Makers | Steering committee, architects | Who approves decisions? | | Influencers | Opinion leaders, union reps | Who shapes perceptions? |
Step 2: Create Stakeholder Register
## Stakeholder Register
| ID | Name/Role | Category | Organization | Contact | Notes |
|----|-----------|----------|--------------|---------|-------|
| S01 | Jane Smith | Sponsor | Executive | jane@... | Budget authority |
| S02 | IT Operations | Operator | IT | ... | 24/7 support team |
| S03 | Customer Service Reps | User | Customer Care | ... | 50+ daily users |
| S04 | Compliance Officer | Regulator | Legal | ... | GDPR requirements |
Phase 2: Stakeholder Analysis
Step 1: Assess Each Stakeholder
For each stakeholder, evaluate:
| Dimension | Question | Scale | |-----------|----------|-------| | Power | Can they stop or significantly impact the initiative? | Low/Medium/High | | Interest | How much do they care about the outcome? | Low/Medium/High | | Attitude | Are they supportive, neutral, or resistant? | Supporter/Neutral/Resistor | | Influence | Can they sway other stakeholders? | Low/Medium/High |
Step 2: Create Power/Interest Matrix
HIGH INTEREST
│
┌────────────────────┼────────────────────┐
│ KEEP SATISFIED │ MANAGE CLOSELY │
│ │ │
│ • Regular updates│ • Active partner │
│ • Address issues │ • Key decisions │
│ • Prevent blocks │ • Regular 1:1s │
HIGH├────────────────────┼────────────────────┤
POWER │ │
│ MONITOR │ KEEP INFORMED │
│ │ │
│ • Minimal effort │ • Regular comms │
│ • Watch for │ • Address needs │
│ changes │ • Build support │
└────────────────────┼────────────────────┘
LOW INTEREST
Step 3: Plot Stakeholders
## Power/Interest Analysis
### Manage Closely (High Power, High Interest)
| Stakeholder | Power | Interest | Strategy |
|-------------|-------|----------|----------|
| Executive Sponsor | High | High | Weekly 1:1, all major decisions |
| Product Owner | High | High | Daily stand-ups, backlog collaboration |
### Keep Satisfied (High Power, Low Interest)
| Stakeholder | Power | Interest | Strategy |
|-------------|-------|----------|----------|
| CTO | High | Low | Monthly summary, escalation path |
| Legal | High | Low | Involve on compliance matters only |
### Keep Informed (Low Power, High Interest)
| Stakeholder | Power | Interest | Strategy |
|-------------|-------|----------|----------|
| End Users | Low | High | User group updates, beta programs |
| Help Desk | Low | High | Training, knowledge base updates |
### Monitor (Low Power, Low Interest)
| Stakeholder | Power | Interest | Strategy |
|-------------|-------|----------|----------|
| Other Departments | Low | Low | General announcements only |
Phase 3: Responsibility Assignment (RACI)
Create RACI matrix for key decisions and deliverables:
| Legend | Meaning | Rule | |--------|---------|------| | R - Responsible | Does the work | Can have multiple | | A - Accountable | Final authority | Must be exactly one | | C - Consulted | Provides input | Before decision | | I - Informed | Notified of outcome | After decision |
## RACI Matrix
| Decision/Deliverable | Sponsor | PO | Dev Lead | Users | Ops |
|---------------------|---------|-----|----------|-------|-----|
| Solution Requirements | I | A | R | C | C |
| Technical Architecture | I | C | A | - | C |
| User Acceptance | A | R | C | R | I |
| Go-Live Decision | A | R | C | I | R |
| Production Support | I | I | C | - | A |
Phase 4: Communication Planning
Step 1: Define Communication Needs
For each stakeholder group:
| Question | Purpose | |----------|---------| | What do they need to know? | Content | | When do they need it? | Timing | | How should we communicate? | Channel | | Who should communicate? | Sender | | What response do we expect? | Feedback mechanism |
Step 2: Create Communication Plan
## Communication Plan
| Stakeholder | Message | Frequency | Channel | Owner | Feedback |
|-------------|---------|-----------|---------|-------|----------|
| Executive Sponsor | Status, risks, decisions | Weekly | 1:1 meeting | PM | Discussion |
| Product Owner | Progress, blockers | Daily | Stand-up | Team Lead | Same day |
| End Users | Training, updates | Bi-weekly | Newsletter | Change Lead | Survey |
| IT Operations | Release plans | Sprint end | Email + meeting | Tech Lead | Sign-off |
| All Stakeholders | Major milestones | As needed | Email blast | PM | None |
Phase 5: Engagement Strategy
For challenging stakeholders (resistors, skeptics), develop targeted strategies:
Resistance Analysis
## Resistance Analysis
| Stakeholder | Current Attitude | Desired Attitude | Resistance Reason | Strategy |
|-------------|-----------------|------------------|-------------------|----------|
| Dept Manager | Resistor | Supporter | Fears job impact | Show how role evolves, not disappears |
| IT Architect | Skeptic | Neutral | Technical concerns | Deep-dive sessions, address concerns |
| Union Rep | Neutral | Supporter | Needs assurance | Early engagement, transparency |
Output Formats
Narrative Summary
## Stakeholder Analysis Summary
**Initiative:** [Name]
**Analyst:** [Name]
**Date:** [ISO date]
### Key Stakeholders
**Primary Sponsors:**
- [Name] - [Role] - [Key interest/concern]
**Critical Partners (Manage Closely):**
- [List with brief description]
### Risk Areas
1. **[Stakeholder]** - [Risk] - Mitigation: [Strategy]
### Recommendations
1. [Specific engagement recommendation]
2. [...]
Structured Data (YAML)
stakeholder_analysis:
version: "1.0"
initiative: "Customer Portal Redesign"
date: "{ISO-8601-date}"
analyst: "stakeholder-facilitator"
stakeholders:
- id: S01
name: "Jane Smith"
role: "VP Customer Experience"
category: sponsor
organization: "Customer Care"
power: high
interest: high
attitude: supporter
influence: high
strategy: manage_closely
communication:
frequency: weekly
channel: meeting
owner: "Project Manager"
concerns:
- "Timeline for Q2 launch"
- "Budget constraints"
- id: S02
name: "IT Operations Team"
role: "Platform Support"
category: operator
organization: "IT"
power: medium
interest: high
attitude: neutral
influence: medium
strategy: keep_informed
communication:
frequency: bi-weekly
channel: email
owner: "Tech Lead"
concerns:
- "Support load increase"
- "Training requirements"
raci:
- deliverable: "Requirements Sign-off"
responsible: ["Product Owner"]
accountable: "VP Customer Experience"
consulted: ["IT Architect", "Users"]
informed: ["IT Operations"]
communication_plan:
- audience: "Executive Sponsor"
content: "Status, risks, decisions needed"
frequency: weekly
channel: "1:1 Meeting"
owner: "Project Manager"
Mermaid Diagrams
Power/Interest Quadrant:
quadrantChart
title Stakeholder Power/Interest Matrix
x-axis Low Interest --> High Interest
y-axis Low Power --> High Power
quadrant-1 Manage Closely
quadrant-2 Keep Satisfied
quadrant-3 Monitor
quadrant-4 Keep Informed
Executive Sponsor: [0.9, 0.95]
Product Owner: [0.85, 0.8]
CTO: [0.3, 0.85]
End Users: [0.8, 0.3]
IT Operations: [0.7, 0.5]
Other Depts: [0.2, 0.2]
Multi-Persona Workshop Mode
For comprehensive stakeholder analysis, run a multi-persona workshop (similar to event storming):
Personas to Invoke:
| Persona | Perspective | Contribution |
|---------|-------------|--------------|
| executive-sponsor-persona | Strategic | Budget, timeline, success criteria |
| end-user-persona | Operational | Daily usage, pain points, adoption |
| operations-persona | Support | Maintenance, reliability, training |
| compliance-persona | Regulatory | Rules, audit, risk |
| devils-advocate | Critical | Risks, overlooked stakeholders, conflicts |
Orchestration:
- Launch all personas in parallel
- Each persona identifies stakeholders from their perspective
- Synthesize findings with provenance tracking
- Resolve conflicts and gaps
When to Use
| Scenario | Use Stakeholder Analysis? | |----------|--------------------------| | New project initiation | Yes - identify all affected parties | | Change management | Yes - plan adoption strategy | | Requirements gathering | Yes - ensure right people involved | | Conflict resolution | Yes - understand interests | | Routine operations | No - not needed for BAU |
Common Mistakes
| Mistake | Impact | Prevention | |---------|--------|------------| | Missing hidden stakeholders | Late surprises, resistance | Use systematic categories | | Ignoring resistors | Project failure | Develop engagement strategy | | Static analysis | Outdated understanding | Revisit quarterly | | Over-communicating to all | Information overload | Tailor by quadrant |
References
- Load
references/power-interest-matrix.mdfor matrix variations - Load
references/raci-matrix.mdfor RACI guidance - See BABOK v3 Chapter 3 (Elicitation & Collaboration)
Related Skills
capability-mapping- Identify capability owners as stakeholdersjourney-mapping- Understand user stakeholder needsrisk-analysis- Assess stakeholder-related risksprioritization- Prioritize stakeholder engagementdecision-analysis- Stakeholder decision matricesprocess-modeling- Identify domain stakeholders through process analysis
User-Facing Interface
When invoked directly by the user, this skill operates as follows.
Arguments
<initiative-description>: Description of the initiative, project, or change to analyze stakeholders for--mode: Analysis mode (default:guided)full: Multi-persona simulation with diverse perspectives (~10K tokens)quick: Rapid stakeholder identification (~3K tokens)guided: Interactive stakeholder discovery (variable)
--output: Output artifacts (default:all)register: Stakeholder register onlymatrix: Power/Interest matrix onlyraci: RACI matrix onlyall: All artifacts
--dir: Output directory (default:docs/analysis/)
Execution Workflow
- Parse Arguments - Extract initiative description, mode, and output format. If no description provided, ask the user what initiative to analyze.
- Execute Based on Mode:
- Full: Spawn the
stakeholder-facilitatoragent with persona agents (executive-sponsor, end-user, operations, compliance, devils-advocate) for comprehensive multi-perspective analysis. - Quick: Rapid identification using standard RACI-style groups with default engagement strategies.
- Guided: Interactive discovery using AskUserQuestion for stakeholder group selection and analysis depth, then walk through category sweep, assessment, matrix placement, and additional artifacts.
- Full: Spawn the
- Generate Output - Produce stakeholder register, Power/Interest matrix (Mermaid quadrantChart), RACI matrix, communication plan, and resistance analysis.
- Save Results - Save to
docs/analysis/stakeholder-analysis.md(or custom--dir). - Suggest Follow-Ups - Recommend capability-mapping for ownership links, journey-mapping for stakeholder experiences, and change management planning for resistors.
Version History
- v1.0.0 (2025-12-26): Initial release