Multi-technique business analysis orchestration using BABOK. Coordinates 14 techniques across strategic analysis, problem solving, planning, and design into comprehensive analysis packages.

2026-01-13301

benchmarking

Prorise-cool/Claude-Code-Multi-Agent

Benchmarking and competitive analysis techniques. Compares performance, processes, and practices against industry standards, competitors, and best-in-class organizations.

2026-01-13301

business-model-canvas

Prorise-cool/Claude-Code-Multi-Agent

Business model design using Osterwalder's Business Model Canvas and Lean Canvas. Creates 9-block canvases with structured analysis for business model innovation and startup validation.

2026-01-13301

capability-mapping

Prorise-cool/Claude-Code-Multi-Agent

Business capability modeling using BABOK Business Capability Analysis. Creates hierarchical capability maps (L1-L3) linking strategy to architecture with Mermaid visualization.

2026-01-13301

data-modeling

Prorise-cool/Claude-Code-Multi-Agent

Data modeling with Entity-Relationship Diagrams (ERDs), data dictionaries, and conceptual/logical/physical models. Documents data structures, relationships, and attributes.

2026-01-13301

name	stakeholder-analysis
description	Stakeholder identification, analysis, and management using BABOK techniques. Creates Power/Interest matrices, RACI charts, and communication plans.
allowed-tools	Read, Glob, Grep, Task, Skill

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.md for matrix variations
Load references/raci-matrix.md for RACI guidance
See BABOK v3 Chapter 3 (Elicitation & Collaboration)

Related Skills

capability-mapping - Identify capability owners as stakeholders
journey-mapping - Understand user stakeholder needs
risk-analysis - Assess stakeholder-related risks
prioritization - Prioritize stakeholder engagement
decision-analysis - Stakeholder decision matrices
process-modeling - Identify domain stakeholders through process analysis

Version History

v1.0.0 (2025-12-26): Initial release