2 Identifying Stakeholders
Learn how to identify, map, validate, and maintain a broad, evidence-based list of people and groups connected to a project.
Define the boundary
A is a person, group, or organization that may affect a project, be affected by it or its outcomes, or believe it is affected. Identifying stakeholders means building a broad, evidence-based list; it does not yet mean deciding whose opinions matter most. Include people with direct roles and people who may experience effects indirectly.
The distinction between and depends on the organization or project boundary chosen. State that boundary clearly: a supplier can be external to the organization while closely involved in the project.
may include the sponsor, project team, executives, affected departments, frontline employees, finance, information technology, legal, human resources, operations, and staff who will maintain the result. may include customers, end users, suppliers, contractors, funders, regulators, business partners, unions, community members, and people living or working near a project site.
may not use or deliver the result themselves, but could experience changes to workflows, services, costs, access, safety, privacy, or the environment. Examples include a customer’s caregiver, a neighboring business affected by construction, or a support team that inherits a new system.
Do not assume that a department, organization, or demographic group speaks with one voice. Where appropriate, identify specific roles, locations, or people within a group, and consider who may be underrepresented or less able to participate.
Build the candidate list
Begin with a short description of the project, intended outcomes, affected processes, and boundary being considered. Brainstorm with people who bring different perspectives, such as the sponsor, project team, subject-matter experts, and representatives of affected groups.
Use these prompts to identify possible stakeholders:
Authority and resources: Who approves, funds, governs, or can stop the work? Who provides staff, facilities, data, technology, or other resources?
Delivery and operation: Who designs, builds, tests, delivers, supports, maintains, or eventually replaces the result?
Use and access: Who will use the product or service? Who needs it but might not use it? Who may face access barriers or need accommodations?
Changes and consequences: Whose tasks, workload, costs, risks, service, safety, privacy, or environment may change? Who may benefit, lose out, or bear unintended effects?
Connections and dependencies: Which suppliers, partners, customers, teams, or public services rely on the affected process? Who is affected upstream or downstream?
Rules and public interest: Which regulators, auditors, professional bodies, advocacy groups, community representatives, or emergency services may have relevant concerns?
Missing voices: Who is absent from the planning conversation, indirectly affected, less visible, harder to reach, or likely to have a different experience from the majority?
For each candidate, ask, “What might change for them, and how?” A plausible effect is a reason to include someone for further consideration, not proof that they will be significantly affected.
Map relationships and record candidates
Use more than one mapping technique when the project has many connections. A process or service map traces work from beginning to end and identifies people and groups who perform, receive, support, or depend on each step. An influence or relationship map places the project at the center and connects it to decision-makers, delivery partners, users, affected groups, and people who influence them; follow indirect links rather than stopping at the immediate team.
A category checklist can sort candidates into groups such as sponsor, delivery team, operations, users, suppliers, regulators, community, and affected non-users. Comparing the candidates with these categories can make blank areas easier to notice.
After compiling the broad list, a can map stakeholders by their potential influence and interest to help plan analysis and engagement. Use it to prioritize attention, not to decide who counts as a .
Record candidates in a . Useful fields include the person or group, internal or external status, connection to the project, possible effects or interests, information source, and questions to verify. Group names can be used initially and made more specific as more is learned.
Check coverage with the clinic example
For a clinic introducing an online appointment system, possible stakeholders include clinic leaders, receptionists, clinicians, information technology and support staff, patients, caregivers who help patients book, the software supplier, and relevant privacy or accessibility representatives. Looking only at project decision-makers and direct users could miss caregivers, staff who handle exceptions, or people who cannot readily use the online option.
This example illustrates why considering indirect effects, access, and different roles can reveal candidates that an initial focus on the project team and direct users might overlook.
Validate and maintain the list
Treat the first list as a set of hypotheses. Review it with project and operational staff, consult relevant records such as process maps, contracts, service plans, and impact assessments, and speak with representatives of affected groups.
Ask interviewees, “Who else could be affected, depend on this work, or help us understand its effects?” Compare the resulting names with the category checklist and maps. Record gaps, assumptions, and uncertain impacts rather than silently treating them as settled.
Revisit the list when the project scope, design, suppliers, operating process, or affected population changes. A thorough list does not mean that every receives the same level of attention; it provides a sound basis for later analysis and engagement.