2 Stakeholder Identification
Learn how to identify project stakeholders systematically, document their relationships, interests, and influence, validate findings, and keep the stakeholder list current.
Define the scope of identification
A stakeholder is a person, group, or organization that can affect a project, is affected by it, or has a relevant in its outcomes. Identifying systematically helps a team understand whose needs and may shape the work.
Begin by defining the project’s scope and deciding what counts as a stakeholder for the analysis. Clarify whether the identification will include internal and external parties, individuals and organizations, and current as well as potential .
Search broadly for
Agree on useful categories before searching so the team can identify broadly rather than relying on memory. Consider people and organizations across the project’s relationships and effects:
Governance and funding: sponsors, decision-makers, funders, and regulators.
Delivery: the project team, operational staff, suppliers, and delivery partners.
Use and impact: customers, users, affected communities, and other teams that rely on the outcome.
Wider context: professional bodies, advocacy groups, media, and other organizations that may or be affected by the work.
Use a workshop or structured brainstorming session with people who understand the project, its delivery, and the organization. Review project documents and processes, and ask each identified stakeholder to suggest others who may be affected or influential. Where useful, record named individuals as well as the stakeholder groups they represent.
Document relationships, interests, and
Use a to record findings. Include the stakeholder’s name, group, or organization and, where known, a contact or representative. Record how each stakeholder contributes, makes decisions, uses results, or may be affected.
Document interests and concerns: what need, value, expect, or may be concerned about. Consider their perspective rather than relying only on the team’s assumptions. Record each stakeholder’s and the basis for the assessment, such as formal authority, expertise, or access to key resources. Include how the assessment was formed and what still needs to be checked.
and are different. A person may care deeply about an outcome but have little formal decision-making power, while another may have considerable authority but limited day-to-day . Record the reasoning behind judgments instead of treating scores as objective facts. A can summarize the analysis, but it does not replace the register or direct validation.
Apply the analysis to an example
For a new online appointment system, may include patients, reception staff, clinicians, the system sponsor, IT support, and the supplier. Patients may have high because they use the system; the sponsor may have high through funding and decisions; and reception staff may have practical knowledge of workflow impacts. Check their specific interests with them rather than assuming what they are.
Validate and maintain the list
Ask people from relevant functions—such as operations, customer support, IT, procurement, legal, communications, and governance—to review the list. They may identify overlooked groups, clarify who represents a stakeholder group, or point out dependencies and impacts. Include project partners or subject-matter experts when their knowledge is needed. Colleagues who already engage with can also help identify additional .
Use these questions to check the list:
Have we considered who decides, delivers, funds, uses, or is affected by the work?
Have we included relevant external groups as well as internal teams?
Are group representatives and assumptions clear?
Have we distinguished evidence from estimates about interests and ?
Who can confirm uncertain entries, and when will the register be reviewed?
Keep the register current at project milestones and when scope, people, or circumstances change. Identification is ongoing: conversations and new information can reveal who were not apparent at the outset.