---
title: "Stakeholder Summary"
description: "Documents stakeholder needs, concerns, and influence for a project or initiative. Use when starting projects, managing complex stakeholder relationships, or ensuring alignment across organizational boundaries."
generated: true
source: scripts/generate-skill-pages.py
tags:
  - Discover
  - research
---

:::note[Quick facts]
**Phase:** Discover | **Version:** 2.0.0 | **Category:** research | **License:** Apache-2.0
:::

**Try it:** `/stakeholder-summary "Your context here"`

A stakeholder summary documents the people and groups who have interest in or influence over a project, capturing their needs, concerns, and relationships. Effective stakeholder management often determines project success more than technical execution, making this document essential for navigating organizational complexity.

## When to Use

- At the start of a new project or initiative to map the landscape
- When taking over an existing project from another PM
- Before major decision points that require cross-functional buy-in
- When experiencing resistance or misalignment mid-project
- During organizational changes that shift stakeholder dynamics
- When preparing communication strategies for launches or changes

## How to Use

Use the `/stakeholder-summary` slash command:

```
/stakeholder-summary "Your context here"
```

Or reference the skill file directly: `skills/discover-stakeholder-summary/SKILL.md`

## Instructions

When asked to create a stakeholder summary, follow these steps:

1. **Identify All Stakeholders**
   List everyone with a stake in the project: sponsors, approvers, contributors, consumers of the output, and those affected by changes. Cast a wide net initially.you can prioritize later. Include both individuals and groups.

2. **Assess Influence and Interest**
   For each stakeholder, evaluate their influence (power to affect the project) and interest (how much they care about outcomes). This determines how much attention each requires.

3. **Understand Their Perspective**
   Document what each stakeholder needs from the project, what concerns or risks they perceive, and what a successful outcome looks like to them. When possible, validate these directly through conversation.

4. **Map Relationships**
   Identify key dependencies, alliances, and potential conflicts between stakeholders. Understanding who influences whom helps you navigate organizational dynamics.

5. **Categorize by Engagement Level**
   Based on influence and interest, determine the appropriate engagement approach: actively manage, keep satisfied, keep informed, or monitor. Different stakeholders need different levels of attention.

6. **Plan Communication**
   For high-priority stakeholders, define communication cadence, preferred channels, and key messages. Good stakeholder management is proactive, not reactive.

7. **Identify Risks and Mitigations**
   Note where stakeholder concerns could derail the project and plan how to address them. Early attention to resistant stakeholders prevents surprises.

## Output Template

# Stakeholder Summary: [Project/Initiative Name]

## Overview

**Project:** [Project or initiative name]
**Purpose:** [One-line description of what this stakeholder analysis supports]
**Date:** [When analysis was conducted]
**Owner:** [Who maintains this document]

## Stakeholder Map

<!-- Visual representation of influence vs. interest -->

```
                    [High Interest]
                          |
        KEEP SATISFIED    |    MANAGE CLOSELY
                          |
                          |
[Low Influence] ----------+---------- [High Influence]
                          |
                          |
        MONITOR           |    KEEP INFORMED
                          |
                    [Low Interest]
```

### Quadrant Placement

**Manage Closely (High Influence, High Interest):**
- [Stakeholder name]
- [Stakeholder name]

**Keep Satisfied (High Influence, Low Interest):**
- [Stakeholder name]
- [Stakeholder name]

**Keep Informed (Low Influence, High Interest):**
- [Stakeholder name]
- [Stakeholder name]

**Monitor (Low Influence, Low Interest):**
- [Stakeholder name]
- [Stakeholder name]

## Stakeholder Profiles

| Stakeholder | Role | Influence | Interest | Alignment | Key Need |
|-------------|------|-----------|----------|-----------|----------|
| [Name] | [Title/Function] | High/Med/Low | High/Med/Low | Supportive/Neutral/Resistant | [Primary need] |
| [Name] | [Title/Function] | High/Med/Low | High/Med/Low | Supportive/Neutral/Resistant | [Primary need] |
| [Name] | [Title/Function] | High/Med/Low | High/Med/Low | Supportive/Neutral/Resistant | [Primary need] |
| [Name] | [Title/Function] | High/Med/Low | High/Med/Low | Supportive/Neutral/Resistant | [Primary need] |
| [Name] | [Title/Function] | High/Med/Low | High/Med/Low | Supportive/Neutral/Resistant | [Primary need] |

## Detailed Stakeholder Analysis

### [Stakeholder Name 1]

**Role:** [Title and function]
**Influence Level:** [High/Medium/Low] . [Why]
**Interest Level:** [High/Medium/Low] . [Why]
**Current Alignment:** [Supportive/Neutral/Resistant]

**Needs:**
- [What they need from this project]
- [What success looks like to them]

**Concerns:**
- [What worries them about this project]
- [What risks they perceive]

**What Motivates Them:**
- [Underlying drivers and priorities]

**Preferred Communication:**
- Channel: [Email/Slack/meetings/etc.]
- Frequency: [Daily/weekly/milestone-based]
- Style: [Data-driven/narrative/executive summary]

---

### [Stakeholder Name 2]

**Role:** [Title and function]
**Influence Level:** [High/Medium/Low] . [Why]
**Interest Level:** [High/Medium/Low] . [Why]
**Current Alignment:** [Supportive/Neutral/Resistant]

**Needs:**
- [What they need from this project]
- [What success looks like to them]

**Concerns:**
- [What worries them about this project]
- [What risks they perceive]

**What Motivates Them:**
- [Underlying drivers and priorities]

**Preferred Communication:**
- Channel: [Email/Slack/meetings/etc.]
- Frequency: [Daily/weekly/milestone-based]
- Style: [Data-driven/narrative/executive summary]

---

### [Stakeholder Name 3]

**Role:** [Title and function]
**Influence Level:** [High/Medium/Low] . [Why]
**Interest Level:** [High/Medium/Low] . [Why]
**Current Alignment:** [Supportive/Neutral/Resistant]

**Needs:**
- [What they need from this project]
- [What success looks like to them]

**Concerns:**
- [What worries them about this project]
- [What risks they perceive]

**What Motivates Them:**
- [Underlying drivers and priorities]

**Preferred Communication:**
- Channel: [Email/Slack/meetings/etc.]
- Frequency: [Daily/weekly/milestone-based]
- Style: [Data-driven/narrative/executive summary]

## Key Relationships

<!-- Map important dependencies and dynamics -->

### Dependencies
| From | To | Dependency Type |
|------|-----|-----------------|
| [Stakeholder] | [Stakeholder] | [Approval/Resources/Information] |
| [Stakeholder] | [Stakeholder] | [Approval/Resources/Information] |

### Alliances
<!-- Stakeholders who tend to align with each other -->
- [Group description]: [Names]
- [Group description]: [Names]

### Potential Conflicts
<!-- Stakeholders with competing interests -->
| Parties | Conflict Area | Risk Level |
|---------|---------------|------------|
| [Names] | [Issue] | High/Med/Low |
| [Names] | [Issue] | High/Med/Low |

## Communication Plan

| Stakeholder | Frequency | Channel | Content | Owner |
|-------------|-----------|---------|---------|-------|
| [Name] | [Weekly/bi-weekly/monthly] | [Meeting/email/Slack] | [What to communicate] | [Who sends] |
| [Name] | [Weekly/bi-weekly/monthly] | [Meeting/email/Slack] | [What to communicate] | [Who sends] |
| [Name] | [Weekly/bi-weekly/monthly] | [Meeting/email/Slack] | [What to communicate] | [Who sends] |

## Risk Mitigation

### Resistant Stakeholders

| Stakeholder | Concern | Mitigation Strategy | Owner |
|-------------|---------|---------------------|-------|
| [Name] | [Core concern] | [How to address] | [Who owns] |
| [Name] | [Core concern] | [How to address] | [Who owns] |

### Political Risks

| Risk | Impact | Mitigation |
|------|--------|------------|
| [Risk description] | [What could happen] | [Prevention strategy] |
| [Risk description] | [What could happen] | [Prevention strategy] |

## Action Items

- [ ] [Action to improve stakeholder relationship]
- [ ] [Meeting to schedule]
- [ ] [Communication to send]
- [ ] [Concern to address]

## Document History

| Date | Change | Author |
|------|--------|--------|
| [Date] | Initial creation | [Name] |
| [Date] | [Update description] | [Name] |

---

*Review and update this document when stakeholder dynamics change or at major project milestones.*

## Example Output

<details>
<summary>Stakeholder Summary: Cloud Infrastructure Migration</summary>

# Stakeholder Summary: Cloud Infrastructure Migration

## Overview

**Project:** Migrate core business applications from on-premise data center to AWS
**Purpose:** Identify and manage stakeholders to ensure smooth migration with organizational buy-in
**Date:** January 2026
**Owner:** Sarah Chen, Technical Program Manager

## Stakeholder Map

```
                    [High Interest]
                          |
        KEEP SATISFIED    |    MANAGE CLOSELY
         - CFO            |     - CTO (Marcus)
         - Legal          |     - VP Engineering (Diana)
                          |     - IT Director (James)
                          |     - Security Lead (Priya)
[Low Influence] ----------+---------- [High Influence]
                          |
        MONITOR           |    KEEP INFORMED
         - HR             |     - Engineering Leads
         - Marketing      |     - Customer Success
                          |     - Sales
                    [Low Interest]
```

### Quadrant Placement

**Manage Closely (High Influence, High Interest):**
- Marcus Wong, CTO . Executive sponsor, budget authority
- Diana Reyes, VP Engineering . Technical decision maker, team impact
- James Liu, IT Director . Infrastructure owner, operations impact
- Priya Sharma, Security Lead . Compliance gatekeeper

**Keep Satisfied (High Influence, Low Interest):**
- Michael Torres, CFO . Budget approval, cost concerns
- Jennifer Adams, Legal Counsel . Contract and compliance review

**Keep Informed (Low Influence, High Interest):**
- Engineering Team Leads . Affected by changes, need to plan
- Customer Success Team . Potential customer-facing impact
- Sales Team . Need confidence to reassure customers

**Monitor (Low Influence, Low Interest):**
- HR Department . Minor process updates needed
- Marketing Team . Minimal direct impact

## Stakeholder Profiles

| Stakeholder | Role | Influence | Interest | Alignment | Key Need |
|-------------|------|-----------|----------|-----------|----------|
| Marcus Wong | CTO | High | High | Supportive | Successful migration, modernization |
| Diana Reyes | VP Engineering | High | High | Supportive | Minimal team disruption, improved DX |
| James Liu | IT Director | High | High | Neutral | Clear transition plan, job security |
| Priya Sharma | Security Lead | High | High | Resistant | Zero security incidents, compliance |
| Michael Torres | CFO | High | Medium | Neutral | Cost predictability, ROI clarity |
| Jennifer Adams | Legal Counsel | Medium | Low | Neutral | Contract compliance, vendor terms |

## Detailed Stakeholder Analysis

### Marcus Wong, CTO

**Role:** Chief Technology Officer, Executive Sponsor
**Influence Level:** High . Budget authority, final technical decisions
**Interest Level:** High . Strategic initiative tied to his objectives
**Current Alignment:** Supportive

**Needs:**
- Successful migration that positions company for scale
- Clear progress visibility without micromanaging
- Minimal production incidents during transition

**Concerns:**
- Timeline slippage affecting other initiatives
- Hidden costs emerging mid-project
- Team burnout from concurrent projects

**What Motivates Them:**
- Technology leadership reputation in industry
- Enabling business growth through infrastructure
- Building a modern, attractive engineering organization

**Preferred Communication:**
- Channel: Weekly 1:1, Slack for urgent items
- Frequency: Weekly status, immediate escalation for blockers
- Style: Executive summary with key decisions needed

---

### Diana Reyes, VP Engineering

**Role:** VP Engineering, 60 engineers across 8 teams
**Influence Level:** High . Controls engineering resources and priorities
**Interest Level:** High . Her teams are directly affected
**Current Alignment:** Supportive

**Needs:**
- Minimal disruption to sprint commitments
- Clear ownership boundaries during transition
- Improved developer experience post-migration

**Concerns:**
- Engineers pulled from product work for migration tasks
- On-call burden increasing during transition
- Knowledge gaps on new cloud infrastructure

**What Motivates Them:**
- Team morale and retention
- Engineering velocity and productivity
- Technical excellence and best practices

**Preferred Communication:**
- Channel: Engineering leads meeting, Slack channel
- Frequency: Bi-weekly detailed review, weekly async update
- Style: Technical depth with impact on team metrics

---

### James Liu, IT Director

**Role:** IT Director, manages infrastructure and operations team of 12
**Influence Level:** High . Owns current infrastructure, critical for transition
**Interest Level:** High . Directly affects his team's role and processes
**Current Alignment:** Neutral (previously resistant)

**Needs:**
- Clear role for his team post-migration
- Training on AWS operations
- Recognition of his team's institutional knowledge

**Concerns:**
- Job security for himself and team members
- Being blamed if migration causes outages
- Loss of control and expertise relevance

**What Motivates Them:**
- Team stability and career growth paths
- Operational excellence and uptime metrics
- Being seen as enabler, not blocker

**Preferred Communication:**
- Channel: Direct 1:1 meetings, private Slack
- Frequency: Weekly check-in, daily during critical phases
- Style: Collaborative, acknowledging his expertise

---

### Priya Sharma, Security Lead

**Role:** Head of Information Security, compliance owner
**Influence Level:** High . Can block migration with security concerns
**Interest Level:** High . Major changes to security perimeter
**Current Alignment:** Resistant

**Needs:**
- Zero security incidents during and after migration
- Compliance documentation for auditors
- Security controls equal or better than current state

**Concerns:**
- Expanded attack surface with cloud exposure
- Team lacks cloud security expertise
- Rushed timeline compromising security reviews

**What Motivates Them:**
- Zero breach track record
- Regulatory compliance (SOC 2, GDPR)
- Security team recognition and resources

**Preferred Communication:**
- Channel: Security review meetings, documented decisions
- Frequency: Bi-weekly security review, ad-hoc for findings
- Style: Risk-focused, evidence-based, documented

---

### Michael Torres, CFO

**Role:** Chief Financial Officer, budget authority
**Influence Level:** High . Controls funding approval
**Interest Level:** Medium . Cares about cost, not technical details
**Current Alignment:** Neutral

**Needs:**
- Predictable costs with clear ROI
- No budget surprises or overruns
- Business continuity during transition

**Concerns:**
- Cloud costs spiraling out of control
- Hidden costs not in original estimate
- Productivity loss during migration

**What Motivates Them:**
- Financial predictability and control
- Operational efficiency
- Risk management

**Preferred Communication:**
- Channel: Monthly finance review, email for budget items
- Frequency: Monthly, plus any budget change requests
- Style: Numbers-focused, ROI-driven, concise

## Key Relationships

### Dependencies
| From | To | Dependency Type |
|------|-----|-----------------|
| Project Team | Marcus Wong | Budget approval, executive air cover |
| Project Team | Priya Sharma | Security sign-off for each phase |
| James Liu | Diana Reyes | Knowledge transfer on current systems |
| Diana Reyes | Engineering Leads | Resource allocation for migration work |

### Alliances
- **Executive alignment:** Marcus and Michael are aligned on cloud strategy; Marcus can influence Michael on budget concerns
- **Technical block:** Diana and James share operational concerns; addressing James's concerns helps with Diana
- **Security partnership:** Priya has CFO's ear on risk; getting her support removes a major blocker

### Potential Conflicts
| Parties | Conflict Area | Risk Level |
|---------|---------------|------------|
| James Liu vs. Diana Reyes | Ownership of cloud operations post-migration | Medium |
| Priya Sharma vs. Project Team | Security review timeline vs. project schedule | High |
| Engineering Leads vs. Project Team | Resource allocation between product and migration | Medium |

## Communication Plan

| Stakeholder | Frequency | Channel | Content | Owner |
|-------------|-----------|---------|---------|-------|
| Marcus Wong | Weekly | 1:1 meeting | Status, risks, decisions needed | Sarah (PM) |
| Diana Reyes | Bi-weekly | Eng leads sync | Team impact, timeline, asks | Sarah (PM) |
| James Liu | Weekly | Private 1:1 | Transition planning, concerns | Sarah (PM) |
| Priya Sharma | Bi-weekly | Security review | Security status, findings, mitigations | Sarah + Tech Lead |
| Michael Torres | Monthly | Finance review | Budget status, forecast, variances | Sarah + Marcus |
| Engineering Leads | Bi-weekly | Slack + meeting | Technical updates, timeline | Tech Lead |
| Broader org | Monthly | All-hands update | High-level progress, what's changing | Marcus |

## Risk Mitigation

### Resistant Stakeholders

| Stakeholder | Concern | Mitigation Strategy | Owner |
|-------------|---------|---------------------|-------|
| Priya Sharma | Security controls inadequate | Engage her team early in architecture; hire cloud security consultant; extra review time | Sarah + CTO |
| James Liu | Team relevance post-migration | Create explicit "Cloud Operations" role; AWS training budget; acknowledge expertise | Sarah + Diana |

### Political Risks

| Risk | Impact | Mitigation |
|------|--------|------------|
| James blocks knowledge transfer | Migration delayed, critical gaps | Private relationship building; involve in architecture decisions; protect his team |
| Priya escalates to board | Project paused for extended security review | Proactive security partnership; over-communicate; no surprises |
| CFO cuts budget mid-project | Scope reduced, value compromised | Regular cost updates; contingency in budget; ROI documentation |

## Action Items

- [ ] Schedule private lunch with James Liu to discuss team transition plan (Sarah, this week)
- [ ] Invite Priya to architecture review as co-owner, not reviewer (Tech Lead, next sprint)
- [ ] Prepare "IT Team Cloud Evolution" proposal for Diana's approval (Sarah, next week)
- [ ] Create CFO dashboard showing migration costs vs. budget (Sarah, before next finance review)
- [ ] Draft security partnership proposal for Priya with dedicated review slots (Sarah + Tech Lead)

## Document History

| Date | Change | Author |
|------|--------|--------|
| 2026-01-14 | Initial creation | Sarah Chen |
| 2026-01-14 | Added communication plan | Sarah Chen |

---

*Review and update this document when stakeholder dynamics change or at major project milestones.*

</details>

## Real-World Examples

See this skill applied to three different product contexts:

<details>
<summary>Storevine (B2B): Storevine B2B ecommerce platform . Campaigns launch stakeholder map</summary>

**Prompt:**

```
/stakeholder-summary

Project: Campaigns . native email marketing for Storevine merchants
Stage: PRD complete, moving to engineering kickoff

Stakeholders I've identified:

Internal:
- Growth PM (me) . owner
- Eng Lead (Platform) . aligned, participated in PRD review
- Design . in progress on Figma specs
- Legal . needs to review CAN-SPAM + GDPR section; not started yet
- Merchant Success . launch comms owners; engaged in discovery
- Storevine Marketing . dog-food use case; interested in using
  Campaigns for our own merchant communications

External:
- Power-user merchants (fashion/home segment) . 5-6 who joined
  discovery interviews; have expectations about the feature
- Klaviyo integration partner team . active Storevine integration;
  not sure how they'll react to a native competing feature

Need: influence/interest map, stakeholder profiles, communication
plan, and risk mitigation for Klaviyo and resistant stakeholders.
```

---

**Output:**

# Stakeholder Summary: Campaigns . Native Email Marketing

</details>

<details>
<summary>Brainshelf (Consumer): Brainshelf consumer PKM app . internal stakeholder map for the Resurface feature</summary>

**Prompt:**

```
/stakeholder-summary

need to map the internal stakeholders for the resurface feature before
we kick off the build. brainshelf is a ~20 person startup so this is
small-team politics, not enterprise governance.

key people:
- marco (ceo/cofounder) . big advocate, sees this as the retention bet
- alex (eng lead) . supportive but worried about A/B test infrastructure
- jordan (growth) . wants resurface as the retention lever
- dan (designer) . concerned about the digest feeling spammy
- chloe (data) . needs instrumentation for the experiment

want a proper stakeholder map with communication plan.
```

---

**Output:**

# Stakeholder Summary: Resurface Feature

</details>

<details>
<summary>Workbench (Enterprise): "Workbench enterprise collaboration platform: Blueprints launch stakeholder map"</summary>

**Prompt:**

```
/stakeholder-summary

Project: Workbench Blueprints -- reusable document templates with required sections and role-based approval gates
Product: Workbench (enterprise collaboration platform, Series B, ~200 employees, ~500 enterprise customers [fictional])
Stage: Pre-development. Discovery interviews complete. About to enter Define phase.
PM: Rachel V. (Technical PM, Blueprints)

Stakeholders to map:

Internal:
1. Sandra C. -- Head of Product. Blueprints sponsor. Approves scope and timeline. Wants Blueprints to drive enterprise expansion and reduce churn in the compliance segment.
2. James W. -- VP Engineering. Owns engineering allocation. Concerned about CRDT complexity and timeline risk. Supportive but cautious.
3. Karen L. -- Engineering Lead, Blueprints squad. Day-to-day engineering owner. Excited about the technical challenge. Needs clear requirements early.
4. Derek H. -- Head of Marketing. Owns GA positioning and messaging. Needs competitive differentiation story for enterprise sales enablement.
5. Mei-Lin T. -- Enterprise Sales Lead. Manages the top 50 enterprise accounts. Wants Blueprints to close pipeline deals stalled on governance gaps. Resistant to phased rollout -- wants everything at once.

External:
6. IT Security leads at enterprise customer accounts. Gate SSO and data residency requirements. Will block deployment if security posture is insufficient.
7. Confluence-migrant accounts (estimated 15 of 80 closed-beta customers [fictional]). High-value, high-risk -- switching cost makes them sticky if onboarding goes well, churnable if it doesn't.

Format: Full stakeholder summary with influence/interest map, detailed profiles, communication plan, and risk mitigation.
```

---

**Output:**

# Stakeholder Summary: Workbench Blueprints

</details>

## Quality Checklist

Before finalizing, verify:

- [ ] All significant stakeholders are identified (not just obvious ones)
- [ ] Influence and interest assessments are realistic, not wishful
- [ ] Concerns are documented from stakeholder's perspective, not dismissed
- [ ] Relationships and dependencies are mapped
- [ ] Communication plan is specific and actionable
- [ ] Resistant stakeholders have mitigation strategies

## Output Format

Use the template in `references/TEMPLATE.md` to structure the output.
