Article
Service DesignStakeholder Map: Guide, Practical Example & Template for Service Design
The Stakeholder Map step by step: identify, prioritize, and manage stakeholders with a practical example and template.
The Stakeholder Map (also called stakeholder mapping or stakeholder analysis) is a visual tool for systematically identifying, classifying, and prioritizing all individuals and groups that influence or are affected by a project, service, or organization. The theoretical foundation was laid by R. Edward Freeman in 1984 with Strategic Management: A Stakeholder Approach, in which he defined stakeholders as “any group or individual who can affect or is affected by the achievement of the organization’s objectives” [1].
What distinguishes the Stakeholder Map from a simple contact list: it makes power dynamics, interest levels, and relationship networks visible. A contact list shows who is involved. A Stakeholder Map shows who can block, who can drive, who needs to be informed, and who can be ignored. This distinction is the difference between a project that stalls in consensus and one that advances with purpose.
Search for “Stakeholder Map” and you will find dozens of results with the same 2x2 matrix. None explains why Mendelow’s Power-Interest Grid from 1991 is too simplistic for service design projects. None shows how backstage actors — IT departments, compliance teams, external service providers — are systematically captured, despite the fact that they fundamentally determine a service design’s feasibility. And none systematically compares the three prevalent stakeholder models: Power-Interest Grid, Salience Model, and Influence-Interest Matrix.
This guide closes those gaps.
From Freeman to modern service design: Where the method comes from
R. Edward Freeman (born 1951), professor at the Darden School of Business at the University of Virginia, published Strategic Management: A Stakeholder Approach in 1984 — the foundational work of modern stakeholder theory [1]. Freeman’s central thesis: companies that only consider shareholder interests fail in the long run. Sustainable success requires the systematic consideration of all stakeholders — customers, employees, suppliers, communities, regulators.
What began as a strategic management concept in 1984 was developed into a practical tool through several subsequent contributions:
Aubrey Mendelow (1991) developed the Power-Interest Grid — still the most widely used stakeholder visualization [2]. The 2x2 matrix positions stakeholders according to their power (influence on the project) and interest (engagement with the topic) into four quadrants: Manage Closely, Keep Satisfied, Keep Informed, Monitor.
Mitchell, Agle, and Wood (1997) expanded the model into the Salience Model, which distinguishes three attributes: Power, Legitimacy, and Urgency [3]. Stakeholders with all three attributes are “Definitive Stakeholders” — they demand immediate attention. Stakeholders with only one attribute are “Latent Stakeholders” — they can be ignored as long as they don’t gain a second attribute. The Salience Model explains why certain stakeholders suddenly become relevant: a data protection officer (high legitimacy, low power) becomes a Definitive Stakeholder as soon as a GDPR violation looms (urgency rises).
Ackermann and Eden (2011) combined power and interest with the concept of stakeholder dynamics: stakeholders move between quadrants. A satisfied major client (Keep Satisfied) becomes an active project opponent (Manage Closely) if their feedback channel is eliminated [4].
Three stakeholder models compared
| Dimension | Power-Interest Grid (Mendelow) | Salience Model (Mitchell et al.) | Influence-Interest Matrix |
|---|---|---|---|
| Axes/Attributes | Power x Interest (2 dimensions) | Power x Legitimacy x Urgency (3 dimensions) | Influence x Interest (2 dimensions) |
| Complexity | Low — quick to create | High — 7 stakeholder types | Medium — similar to Power-Interest |
| Best for | Quick stakeholder prioritization in workshops | Complex projects with regulatory and political stakeholders | Projects where influence and formal power diverge |
| Weakness | Doesn’t distinguish between formal power and informal influence | Demanding — requires evaluating three attributes per stakeholder | Similar to Power-Interest without the established academic framework |
| Origin | Mendelow (1991) [2] | Mitchell, Agle & Wood (1997) [3] | Bourne & Walker (2005) [5] |
Recommendation: Start with the Power-Interest Grid — it is fast, intuitive, and sufficient for 80% of projects. Switch to the Salience Model when regulatory or political stakeholders play a role and you need to understand the dynamics between power, legitimacy, and urgency. The Influence-Interest Matrix is a variant of the Power-Interest Grid that is useful when informal influence (e.g., opinion leaders, internal champions) matters more than formal hierarchical position.
When is the Stakeholder Map the right tool?
Use the Stakeholder Map when:
- You are launching a service design project and want to understand who influences, blocks, or supports the outcomes
- You are assembling a cross-functional team and want to ensure all relevant perspectives are represented
- You expect or are experiencing resistance and want to understand where it comes from and how to address it
- You need to set communication priorities: Who do you inform, how often, in what depth, through which channel?
- You want to identify the backstage actors of a service — IT, compliance, external providers — who don’t appear in a customer journey map but determine implementation feasibility
Use a different tool when:
| Situation | Better alternative | Why |
|---|---|---|
| You want to assign responsibilities for specific tasks | RACI matrix | RACI defines roles (Responsible, Accountable, Consulted, Informed) per task; the Stakeholder Map doesn’t define task allocation |
| You want to understand the hierarchy of an organization | Org chart | Org charts show formal reporting lines; the Stakeholder Map shows influence and interest, which often run across hierarchies |
| You want to understand how the customer experiences a service | Customer Journey Map | Journey Maps are chronological and customer-centric; the Stakeholder Map is relational and project-focused |
| You want to resolve conflicts between stakeholders | Multi-Stakeholder Design | Multi-Stakeholder Design offers conflict resolution protocols; the Stakeholder Map only identifies the actors |
| You want to classify user types of your service | Empathy Map / Persona | The Stakeholder Map shows power dynamics, not user needs |
Comparison: Stakeholder Map vs. RACI vs. Org Chart
Three tools that are often confused — but answer different questions:
| Dimension | Stakeholder Map | RACI Matrix | Org Chart |
|---|---|---|---|
| Core question | Who has influence and interest? | Who is responsible for which task? | Who reports to whom? |
| Focus | Power dynamics and relationships | Task allocation and decision rights | Formal hierarchy and reporting lines |
| Timing | Project start and regular updates | After task definition | Permanent (organization-wide) |
| Captures | Also informal influencers, external actors | Only internally assigned roles | Only formal positions |
| Weakness | No task assignment | No power dynamics | No informal influences |
Ideal combination: Stakeholder Map (project start: who is relevant?) → RACI (project planning: who does what?) → Stakeholder Map update (mid-project: has the dynamic changed?).
Step by step: Create a Stakeholder Map in 90 minutes
Preparation (before the workshop)
- Participants: 4–8 people from different areas — project management, subject matter experts, someone with customer contact, someone with IT/operations background. The more perspectives, the more complete the map.
- Materials: Large whiteboard or flipchart, Post-its in at least 3 colors (one per stakeholder category: frontstage, backstage, strategic/external), markers, pre-drawn Power-Interest Grid (2x2 matrix on the whiteboard)
- Define context: Stakeholder mapping is context-dependent. “Stakeholders of the company” is too broad. “Stakeholders of the redesign of the onboarding process for individual customers” is focused enough.
Phase 1: Identify stakeholders (25 minutes)
Collect all individuals and groups who influence the project or are affected by it. Work through three categories systematically:
Category 1: Frontstage actors (directly visible to the end customer)
- End customers (differentiated by segment)
- Customer advisors / field service
- Call center staff
- Partners who co-deliver the service
Category 2: Backstage actors (invisible to the end customer but essential)
- IT department / system administration
- Compliance / data protection / regulation
- Controlling / finance department
- Product management
- External service providers (logistics, payment, cloud providers)
Category 3: Strategic actors (not operationally involved but decision-powerful)
- Executive management / board
- Division head / sponsor
- Works council
- External regulators (financial supervisory authority, data protection authority)
- Industry associations
Facilitation tip: The most common gap is Category 2 — backstage actors. Teams think first of customers and executives but forget the IT department that must implement the new system, or the data protection officer who must grant approval. Ask specifically: “Who must deliver technically for this service to work? Who must approve from a regulatory perspective?”
Write each stakeholder on a Post-it (color by category). Target: 15–30 stakeholders. Fewer than 10 means you likely have gaps. More than 40 makes prioritization in Phase 2 difficult.
Phase 2: Classify stakeholders (25 minutes)
Position each stakeholder in the Power-Interest Grid:
| Low Interest | High Interest | |
|---|---|---|
| High Power | Keep Satisfied — Keep them content but don’t flood them with details. Regular status reports, strategic updates. Example: Board member who approves the budget but isn’t interested in operational details. | Manage Closely — Close collaboration, regular exchange, involve early. Example: Division head who sponsors the project and represents results to the board. |
| Low Power | Monitor — Observe, but minimal effort. Only respond when power or interest changes. Example: Industry association that monitors the topic but has no direct influence. | Keep Informed — Regular updates, solicit feedback, but no active steering needed. Example: Call center team that will implement the new process and needs to understand early what changes. |
Assessment criteria for power:
- Can this person/group stop or delay the project? (Veto rights, budget withdrawal, regulatory blockade)
- Can they allocate or withdraw resources? (Staff, budget, systems)
- Do they have formal decision authority over relevant aspects?
Assessment criteria for interest:
- Is this person/group directly affected by the outcomes?
- Do they have a professional or personal interest in the topic?
- Have they proactively expressed themselves (positively or negatively)?
Facilitation tip: Rate power and interest on a 1–5 scale, not binary (high/low). This makes positioning in the grid easier and reveals borderline cases. When the team disagrees, the discussion is more valuable than the result — it uncovers different perceptions of power dynamics.
Phase 3: Analyze relationships and dynamics (20 minutes)
This step is missing from most stakeholder mapping guides — yet it is decisive:
- Identify alliances: Draw connecting lines between stakeholders who collaborate or share interests. Green lines for alliances, red for conflicts.
- Identify gatekeepers: Who controls access to other stakeholders? The executive assistant has low formal power but a high gatekeeping function.
- Anticipate dynamics: Where might power or interest shift? An IT director (currently: Keep Satisfied) becomes a Manage Closely stakeholder as soon as system integration begins.
Example of a critical dynamic: In a hospital service redesign, nursing staff (high interest, low formal power) depend on the medical director’s support (high power, variable interest). If the medical director loses interest, nursing loses its leverage — even though they would benefit most from the new service. The Stakeholder Map makes this dependency visible.
Phase 4: Derive engagement strategy (20 minutes)
For each quadrant, define a concrete communication and engagement strategy:
| Quadrant | Strategy | Frequency | Format | Example |
|---|---|---|---|---|
| Manage Closely | Active involvement, co-design, regular alignment | Weekly | 1:1 meetings, workshop participation, steering committee | Project sponsorship with division head |
| Keep Satisfied | Strategic updates, risk escalation | Every 2–4 weeks | Executive summary, dashboard, status report | Quarterly report to the board |
| Keep Informed | Regular information, feedback channels | Every 2 weeks | Newsletter, town hall, feedback sessions | Monthly update to call center team |
| Monitor | Passive observation, reactive communication | As needed | Only when power or interest changes | Inform industry association when new regulation emerges |
Result: A documented Stakeholder Map with (1) all identified stakeholders, (2) their position in the Power-Interest Grid, (3) key relationships and dynamics, (4) an engagement strategy per quadrant.
Example: Stakeholder Map for a hospital service redesign
Context: A large DACH-region university hospital is redesigning its admissions process for elective (planned) surgeries. The goal: reduce the time from admission to surgery from an average of 4.5 hours to 2 hours while maintaining patient safety. The service design team creates a Stakeholder Map to identify all relevant actors and plan the engagement strategy.
Identified stakeholders (excerpt):
| Stakeholder | Category | Power | Interest | Quadrant |
|---|---|---|---|---|
| Patients (elective) | Frontstage | Low | High | Keep Informed |
| Admissions team (nursing) | Frontstage | Low | High | Keep Informed |
| Anesthesiologists | Frontstage | High | High | Manage Closely |
| Surgeons | Frontstage | High | Medium | Keep Satisfied |
| OR scheduling | Backstage | High | High | Manage Closely |
| IT department (HIS system) | Backstage | High | Low | Keep Satisfied |
| Health insurers | External | Medium | Low | Monitor |
| Data protection officer | Backstage | Medium | Low → High | Monitor → Manage Closely |
| Hospital director | Strategic | High | Medium | Keep Satisfied |
| Quality management | Backstage | Medium | High | Keep Informed |
| Patient representative | External | Low | High | Keep Informed |
| Referring physicians (external) | External | Medium | Medium | Keep Informed |
Critical insights:
-
OR scheduling is the central bottleneck stakeholder: They have high power (determine surgery sequence) and high interest (suffer from current inefficiencies). They must be involved as a co-design partner — not just as information recipients.
-
The IT department is a sleeping giant: Currently low interest (the admissions process is “not their problem”), but high power (any process change requires hospital information system adjustments). If IT is not involved early, implementation fails on technical dependencies. Engagement strategy: invite an IT liaison to the steering group early and evaluate technical feasibility in parallel with the service design.
-
The data protection officer shifts quadrants: Currently in the Monitor quadrant (low relevance). As soon as the team wants to transmit patient data through new digital channels (e.g., mobile admissions, pre-check-in app), urgency spikes — the data protection officer becomes a Manage Closely stakeholder. This shift must be anticipated, not addressed reactively.
-
Patients have high interest but low power: They experience the admissions process as frustrating (waiting times, repetitive questions, disorientation) but cannot directly influence the process. The service design team must actively introduce their voice — through patient advisory boards or co-design workshops. Without this deliberate inclusion, patient needs are overruled by more powerful stakeholders (surgeons, OR scheduling).
Relationship dynamics: Anesthesiologists and surgeons have a latent conflict: anesthesiologists want sufficient lead time for risk assessment; surgeons want minimal waiting times between operations. The new admissions process must address this conflict — not ignore it. Multi-Stakeholder Design offers facilitation protocols for this purpose.
Note: This example is illustratively constructed to demonstrate the method in a service context. The stakeholder positions are based on typical dynamics in university hospitals.
The Stakeholder Map in the service design process
The Stakeholder Map is not a one-time workshop artifact — it is a living document that accompanies the entire service design process:
Phase 1: Discovery
- Create the Stakeholder Map (this guide)
- Decide which stakeholders to include in user research
- Create Empathy Maps for the most important stakeholder groups
Phase 2: Definition
- Update the Stakeholder Map: have power and interest changed?
- Create Customer Journey Maps for end customers
- Create Service Blueprint: backstage actors from the Stakeholder Map become swimlanes in the blueprint
Phase 3: Design & Delivery
- Execute engagement strategy: involve Manage Closely stakeholders in co-design workshops
- Inform Keep Satisfied stakeholders about progress
- Update the Stakeholder Map again: the IT department (previously Keep Satisfied) is now Manage Closely because implementation has begun
Connection to the Service Blueprint: Every backstage actor in the Service Blueprint should appear in the Stakeholder Map. If a blueprint shows an “IT system interaction” but the IT department isn’t in the Stakeholder Map, you have a blind spot.
Stakeholder Map: Template for immediate use
Use this template directly for your next workshop:
Preparation
- Project context clearly defined (not “stakeholders of the company” but “stakeholders of project X”)
- 4–8 participants from different areas invited
- Power-Interest Grid prepared on whiteboard or flipchart
- Post-its in 3 colors provided (Frontstage / Backstage / Strategic-External)
Phase 1: Identification (25 min.)
- Frontstage actors collected (end customers, advisors, partners)
- Backstage actors collected (IT, compliance, controlling, service providers)
- Strategic actors collected (executive management, works council, regulators)
- 15–30 stakeholders identified
Phase 2: Classification (25 min.)
- Each stakeholder rated for power (1–5) and interest (1–5)
- Stakeholders positioned in the Power-Interest Grid
- Four quadrants populated with stakeholders
Phase 3: Relationship analysis (20 min.)
- Alliances and conflicts between stakeholders identified
- Gatekeepers marked
- Dynamics anticipated (who might change quadrants?)
Phase 4: Engagement strategy (20 min.)
- Communication strategy defined for each quadrant
- Frequency and format of communication established
- Responsible persons for stakeholder management named
- Next review date for the Stakeholder Map scheduled
5 common mistakes with the Stakeholder Map
1. Only considering external stakeholders
Symptom: The Stakeholder Map shows customers, partners, and regulators — but no internal actors. IT department, controlling, works council are missing.
Why it hurts: Most service design projects fail not because of customer acceptance, but because of internal blockades: IT can’t deliver, compliance doesn’t approve, the budget gets cut. Ignoring internal stakeholders means discovering these blockades too late.
Solution: Work through the three categories (frontstage, backstage, strategic) systematically. Ask the check question: “Who must deliver technically, approve from a regulatory standpoint, or agree financially?“
2. Forgetting backstage actors
Symptom: The Stakeholder Map contains end customers, advisors, and executives — but not the IT department that must adapt the system, the data protection officer who must grant approval, or the external cloud provider whose API limitation constrains the entire service.
Why it hurts: Backstage actors determine the feasibility of a service design. A perfect journey design fails when IT needs 18 months of development time or data protection prohibits the planned data processing.
Solution: For every frontstage touchpoint in the Service Blueprint, ask: “Which backstage systems and people stand behind this?” Those belong in the Stakeholder Map.
3. Treating the Stakeholder Map as a one-time exercise
Symptom: The Stakeholder Map is created at project start and never updated. In project month 6, the power dynamic has changed — the map still shows month 1 reality.
Why it hurts: Power and interest are not static. An IT director who shows little interest at the start (Keep Satisfied) becomes highly relevant once implementation begins (Manage Closely). A project opponent is neutralized when a new sponsor comes in. Working with an outdated map means communicating with the wrong people at the wrong intensity.
Solution: Update the Stakeholder Map at every phase transition in the project — at least every 6–8 weeks. Ask: “Who is new? Who has changed quadrants?“
4. Equating power with hierarchy
Symptom: The CEO sits at the top of the grid, the processor at the bottom — regardless of the specific project context.
Why it hurts: Power in the context of a service design project is not identical to position in the org chart. The call center processor has low hierarchical power but high operational power: if they don’t implement or actively resist the new process, the project fails. A CEO has high formal power but may have zero interest in an operational process topic — and delegates the decision entirely.
Solution: Evaluate power context-specifically: “Can this person stop, delay, or accelerate this project?” — not “How high is this person in the hierarchy?“
5. Not deriving an engagement strategy
Symptom: The Stakeholder Map is created and hung on the wall. There are no defined communication measures, no responsible persons, no frequencies.
Why it hurts: A Stakeholder Map without an engagement strategy is an analysis without consequence. Knowing that the IT department is “Keep Satisfied” accomplishes nothing if nobody writes the regular status reports.
Solution: For each quadrant, define at minimum: (1) Who communicates? (2) How often? (3) In what format? (4) What is communicated? The engagement strategy is the output of the Stakeholder Map, not the map itself.
When the Stakeholder Map does NOT work
1. For deep empathy with individual users: The Stakeholder Map shows power dynamics and relationships — not what an individual user thinks, feels, and needs. For deep user empathy, you need an Empathy Map or persona.
2. For task allocation: The Stakeholder Map says “The IT department has high power and low interest” — but not who in the IT department takes on which task. For that, you need a RACI matrix.
3. In politically highly sensitive environments: If the mapping itself triggers conflicts — e.g., if the project sponsor sees they are in the “Keep Satisfied” quadrant, not “Manage Closely” — the transparency can be counterproductive. In such contexts, create the detailed map within the core team and communicate only the engagement strategy externally.
4. For chronological customer experience analysis: The Stakeholder Map is relational (who influences whom), not chronological (what happens when). For chronological analysis, you need a Customer Journey Map.
Frequently asked questions
What is a Stakeholder Map?
A Stakeholder Map is a visual tool for systematically identifying, classifying, and prioritizing all individuals and groups that influence or are affected by a project. It typically positions stakeholders by power and interest in a 2x2 matrix (Power-Interest Grid) and derives a communication and engagement strategy from this positioning. The theoretical foundation comes from R. Edward Freeman (1984).
How do you create a Stakeholder Map?
In four phases: (1) Identify stakeholders — systematically across frontstage, backstage, and strategic actors. (2) Classify stakeholders — position them in the Power-Interest Grid by power and interest. (3) Analyze relationships and dynamics — alliances, conflicts, gatekeepers. (4) Derive an engagement strategy — communication measures per quadrant. Plan for 90 minutes for a complete workshop.
What is the difference between a Stakeholder Map and a RACI matrix?
The Stakeholder Map answers “Who has influence and interest?” — it shows power dynamics and relationships. The RACI matrix answers “Who is responsible for which task?” — it defines roles (Responsible, Accountable, Consulted, Informed) per task. Both are complementary: first the Stakeholder Map (who is relevant?), then RACI (who does what?).
What is the difference between a Stakeholder Map and an org chart?
The org chart shows formal hierarchy and reporting lines — who reports to whom. The Stakeholder Map shows influence and interest in the context of a specific project — cutting across hierarchies. A processor may sit low in the org chart but in the “Manage Closely” quadrant of the stakeholder grid because they must operationally implement the project.
Which stakeholder model should I use?
Start with the Power-Interest Grid (Mendelow) — it is fast, intuitive, and sufficient for 80% of projects. Switch to the Salience Model (Mitchell et al.) when regulatory or political stakeholders play a role and you need to understand the dynamics between power, legitimacy, and urgency.
How often should I update the Stakeholder Map?
At every phase transition in the project — at least every 6–8 weeks. Power and interest are not static: an IT director who initially shows little interest becomes highly relevant once implementation begins. At every update, check: Who is new? Who has changed quadrants? Which dynamics have shifted?
Related methods
A typical sequence in service design: With the Stakeholder Map you identify all relevant actors and their power dynamics. With Multi-Stakeholder Design you address the conflicts between them. With the Customer Journey Map you map the frontstage stakeholders’ experience. With the Service Blueprint you connect frontstage and backstage.
- Multi-Stakeholder Design: When you want not just to identify stakeholders but actively resolve their conflicts — the Stakeholder Map identifies, Multi-Stakeholder Design resolves
- Service Blueprint: When you want to embed the backstage actors from the Stakeholder Map in their operational context
- Customer Journey Mapping: When you want to map the chronological experience of frontstage stakeholders (end customers)
- Service Design Methods: Overview: When you want to understand how the Stakeholder Map fits into the overall picture of service design tools
- Empathy Map: When you want to develop deeper empathy for a single stakeholder — the Stakeholder Map shows the relationship network, the Empathy Map shows the individual perspective
Research methodology
This article synthesizes findings from Freeman’s stakeholder theory (1984), Mendelow’s Power-Interest Grid (1991), the Salience Model by Mitchell, Agle, and Wood (1997), Ackermann and Eden’s work on stakeholder dynamics (2011), Bourne and Walker’s Influence-Interest Matrix (2005), and the analysis of 10 German-language expert contributions on stakeholder analysis.
Limitations: Academic literature on stakeholder analysis originates predominantly from strategic management and project management. Empirical studies on application in service design are limited. The practical example (hospital admissions process) is illustratively constructed, not a documented case study.
Disclosure
SI Labs offers consulting services in the area of service innovation. In the discovery phase of the Integrated Service Development Process (iSEP), we use the Stakeholder Map to structure the actor landscape of a service design project before the actual design work begins. This practical experience informs the framing of the method in this article. Readers should be aware of potential perspective bias.
References
[1] Freeman, R. Edward. Strategic Management: A Stakeholder Approach. Boston: Pitman, 1984. [Book | Foundational Work | Citations: 70,000+ | Quality: 95/100]
[2] Mendelow, Aubrey. “Environmental Scanning — The Impact of the Stakeholder Concept.” Proceedings of the International Conference on Information Systems (ICIS), 1991. [Conference Paper | Power-Interest Grid Origin | Citations: 3,000+ | Quality: 80/100]
[3] Mitchell, Ronald K., Bradley R. Agle, and Donna J. Wood. “Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What Really Counts.” Academy of Management Review 22, no. 4 (1997): 853-886. DOI: 10.5465/amr.1997.9711022105 [Journal Article | Salience Model | Citations: 15,000+ | Quality: 92/100]
[4] Ackermann, Fran, and Colin Eden. “Strategic Management of Stakeholders: Theory and Practice.” Long Range Planning 44, no. 3 (2011): 179-196. DOI: 10.1016/j.lrp.2010.08.001 [Journal Article | Stakeholder Dynamics | Citations: 1,500+ | Quality: 85/100]
[5] Bourne, Lynda, and Derek H.T. Walker. “Visualising and Mapping Stakeholder Influence.” Management Decision 43, no. 5 (2005): 649-660. DOI: 10.1108/00251740510597680 [Journal Article | Influence-Interest Matrix | Citations: 800+ | Quality: 78/100]
[6] Stickdorn, Marc, Markus Edgar Hormess, Adam Lawrence, and Jakob Schneider. This Is Service Design Doing. Sebastopol, CA: O’Reilly Media, 2018. [Book | Service Design Practice | Citations: 1,000+ | Quality: 85/100]
[7] Bryson, John M. “What to Do When Stakeholders Matter: Stakeholder Identification and Analysis Techniques.” Public Management Review 6, no. 1 (2004): 21-53. DOI: 10.1080/14719030410001675722 [Journal Article | Stakeholder Analysis Techniques | Citations: 3,000+ | Quality: 88/100]