Identify Stakeholders in PMBOK 8 — Complete Guide

Article updated in March 2026 for the PMBOK® Guide — Eighth Edition.

Identify Stakeholders in PMBOK 8 — Complete Guide

Formerly known as: Identify Stakeholders (PMBOK 6)

A large software implementation project was six months into execution when the legal department sent a two-paragraph email that effectively paused the entire project for three weeks. The project manager had never spoken to anyone in legal. The implementation involved storing employee health data — a fact that triggered HIPAA reporting obligations that no one on the project team was aware of. Legal was a stakeholder from day one. They had never been identified, analyzed, or engaged. The compliance requirement they surfaced in month six could have been known and planned for in week one, at a fraction of the cost in time and schedule disruption.

This pattern — missing a critical stakeholder early and paying the price in execution — is one of the most preventable project failures, and Identify Stakeholders in PMBOK 8 is the process specifically designed to prevent it. Identify Stakeholders is the process of identifying project stakeholders regularly and analyzing and documenting relevant information regarding their interests, involvement, interdependencies, influence, and potential impact on project success. The key word is “regularly” — stakeholder identification is not a one-time initiation activity in PMBOK 8. It is a continuous process that must be revisited as the project evolves and its environment changes.

For PMP candidates, this is Stakeholders Process 1 of 7. For practitioners, it is the foundation on which every subsequent stakeholder management activity depends. You cannot engage stakeholders you have not identified. You cannot plan communications for audiences you do not know exist. You cannot manage resistance from parties whose opposition you were not aware of.

• 1. What Is the Identify Stakeholders Process
• 2. Why Use the Identify Stakeholders Process
• 3. Inputs, Tools & Techniques, and Outputs (ITTO)
• 4. Step-by-Step Application Guide
• 5. When to Apply This Process
• 6. Real-World Examples
• 7. Templates and Downloads
• 8. Five Common Errors
• 9. Tailoring This Process
• 10. Process Interactions
• 11. Quick-Application Checklist

1. What Is the Identify Stakeholders Process

According to the PMBOK® Guide — Eighth Edition, Identify Stakeholders is the process of identifying project stakeholders regularly and analyzing and documenting relevant information regarding their interests, involvement, interdependencies, influence, and potential impact on project success. The key benefit of this process is that it enables the project team to identify the appropriate focus for the engagement of each stakeholder or group of stakeholders. Continuous stakeholder identification can work as a risk management strategy as the project environment evolves. This process is performed periodically throughout the project as needed.

The Stakeholders performance domain in PMBOK 8 includes seven processes: Identify Stakeholders, Plan Stakeholder Engagement, Plan Communications Management, Manage Stakeholder Engagement, Manage Communications, Monitor Stakeholder Engagement, and Monitor Communications. Identify Stakeholders is the first and most foundational: it produces the stakeholder register that every subsequent stakeholder management process depends on.

PMBOK 8 places a strong emphasis on the breadth of stakeholder identification. Stakeholders include not only the obvious project participants (sponsor, project manager, project team) but also the full spectrum of people, groups, and organizations that have a stake in the project — internal and external, supportive and resistant, powerful and marginalized. The PMBOK 8 stakeholder universe explicitly includes: the project manager, the project management team, the project team, the sponsor, governing bodies, project management offices, steering committees, suppliers and vendors, customers, end users, regulatory bodies, local communities, and family members of project team members affected by project demands. Missing any significant category risks the consequences illustrated in the opening example.

2. Why Use the Identify Stakeholders Process

The identify stakeholders process PMBOK 8 defines is not bureaucratic list-making — it is a structured intelligence-gathering activity that produces the insight the project team needs to navigate the human landscape of the project.

Direct benefits

• Risk management through stakeholder visibility: Many of the most damaging project risks are stakeholder-driven — resistance from an influential department, compliance requirements from a regulatory body, contractual constraints from a vendor. Identifying these stakeholders early converts unknown risks into known risks that can be analyzed and responded to proactively.
• Engagement targeting: Not all stakeholders require the same level of engagement. By identifying and analyzing stakeholders (power, interest, influence, attitude), the project team can allocate limited engagement time and resources to the stakeholders where focused attention will have the most impact on project outcomes.
• Communication planning foundation: The stakeholder register produced by Identify Stakeholders is the primary input to Plan Communications Management. You cannot design an effective communication strategy for audiences you have not defined.
• Conflict prevention: Stakeholder conflicts that are discovered during execution — when two powerful stakeholders have opposing expectations, or when a group that should have been consulted discovers they were excluded — are far more expensive to resolve than conflicts surfaced and addressed during the identification and analysis phase.
• Requirements completeness: Many project requirements come from stakeholders. Missing a stakeholder category at identification means missing the requirements that category would have provided. Late-discovered requirements (discovered because their source stakeholder was not identified) produce scope changes that disrupt schedule, budget, and team productivity.

The cost of incomplete stakeholder identification

• Compliance surprises: Regulatory stakeholders (compliance teams, legal departments, government agencies) discovered after requirements are defined and architecture is established produce redesign costs that can dwarf the cost of early consultation.
• Change resistance: Stakeholders who were not engaged because they were not identified become resistant stakeholders who feel excluded and disrespected. Converting a resistant stakeholder to a neutral or supportive position in execution is far more difficult than engaging them constructively during identification.
• Scope gaps: Stakeholder groups that represent legitimate requirements (end users in a different department, operational staff who will maintain the project’s outputs, customers in a specific geography) whose requirements are missing produce scope gaps that become post-implementation problems.

3. Inputs, Tools & Techniques, and Outputs (ITTO)

Inputs explained

Project charter: The project charter names the sponsor, defines the project’s objectives and scope, and describes the context in which the project will be executed. Each of these elements is a lens for stakeholder identification: who benefits from the project’s objectives? Who is impacted by the scope? Who has authority over the context in which the project will operate? The charter is always the starting point for stakeholder identification.

Business documents — Business case and benefits management plan: The business case identifies the problem being solved and the stakeholders who experience that problem or benefit from its resolution. The benefits management plan identifies the stakeholders who will measure, track, and realize the project’s benefits — a distinct group from those involved in producing the project’s deliverables. Both documents expand the stakeholder universe beyond the project team to include the business stakeholders who are the ultimate reason the project exists.

Project management plan — Communications management plan and stakeholder engagement plan: These plans (updated versions from previous identification cycles) provide context for the current identification pass. In iterative stakeholder identification (the PMBOK 8 emphasis on “regularly”), reviewing the current plans helps identify gaps — stakeholder categories that were engaged in previous phases but are not adequately represented in the current engagement approach, or new stakeholder groups that have emerged as the project evolved.

Agreements: Contracts define the parties involved in the project from a legal perspective — the contracting organization, the client, specific individuals with signature authority or contractual roles. These parties are always stakeholders. More importantly, contracts often reference regulatory requirements, third-party standards bodies, or compliance authorities that are implied stakeholders not named explicitly in the project charter.

Enterprise Environmental Factors (EEFs): Organizational culture (determines which internal groups have informal influence beyond their organizational position), existing stakeholder relationships, industry regulatory environment (which government agencies and standards bodies have authority over the project’s domain), and market conditions (which external parties could be affected by or affect the project’s outcomes) all shape the stakeholder landscape.

Tools & Techniques explained

Data gathering — Brainstorming: A facilitated session with knowledgeable project participants to generate a comprehensive initial list of potential stakeholders. Effective stakeholder brainstorming works from categories (internal vs. external; by organizational function; by project phase; by geographic impact; by regulatory domain) to ensure systematic coverage. The goal is breadth — generating a list that can be analyzed and prioritized, not pre-filtered to only the “important” stakeholders.

Data analysis — Stakeholder analysis: Once identified, each stakeholder or stakeholder group is analyzed across multiple dimensions to inform engagement strategy. Common analytical frameworks include: the Power/Interest grid (placing stakeholders by their authority level and degree of interest in the project); the Power/Influence grid (authority vs. ability to affect project outcomes); the Salience model (analyzing power, legitimacy of interest, and urgency of demands). The choice of framework is less important than the consistency of its application — the goal is a structured basis for prioritizing engagement attention.

Data representation — Stakeholder mapping/representation: Visual representations of the stakeholder landscape that make complex stakeholder relationships comprehensible. A stakeholder map shows not only who the stakeholders are but how they relate to each other — who influences whom, which stakeholders are potential allies, which are potential blockers, and which stakeholder groups have overlapping interests that could be leveraged for coalition building. Stakeholder maps are particularly valuable for communicating the stakeholder landscape to new team members or for briefing executives on the project’s engagement context.

Expert judgment: People who know the organizational and industry landscape provide insight that no document can fully capture: informal influence networks, historical project contexts, interpersonal dynamics between key stakeholders, unwritten cultural rules about who must be consulted on what decisions. Expert judgment for stakeholder identification often comes from experienced project managers who have worked in the same organization or industry, from the project sponsor, and from functional managers whose departments are affected by the project.

Outputs explained

Stakeholder register: The primary output of the Identify Stakeholders process. A well-structured stakeholder register includes for each stakeholder: identification information (name, role, organization, contact details); assessment information (interests and requirements in the project; potential impact on project success; involvement level; attitude toward the project: unaware, resistant, neutral, supportive, or leading); and classification (internal/external; upward/downward/outward/sideward influencer). The stakeholder register is a living document that is updated continuously throughout the project — new stakeholders are added, existing assessments are revised as engagement reveals new information, and engagement strategies are refined as the project evolves.

Project document updates — Risk register: Stakeholder identification frequently surfaces project risks. A powerful stakeholder with a negative attitude toward the project is a risk that must be analyzed and responded to. A regulatory body whose requirements are not yet fully understood is a risk. A key sponsor whose organizational position is unstable is a risk. The risk register should be updated whenever stakeholder identification reveals stakeholder-driven risks.

4. Step-by-Step Application Guide

Step 1 — Gather and review all relevant inputs

Before conducting stakeholder identification activities, review: the project charter (objectives, scope, context); business documents (who benefits, who is impacted); existing agreements and contracts (parties, references to third-party authorities); any previous versions of the stakeholder register (for iterative identification runs); and lessons learned from similar previous projects (which stakeholder categories were consistently overlooked or underestimated). This review provides the foundational context that makes the identification session productive rather than starting from scratch.

Step 2 — Conduct a structured brainstorming session

Facilitate a 60-90 minute session with the project sponsor, key team members, and any subject matter experts who know the relevant organizational and industry landscape. Work systematically through stakeholder categories: internal project participants (sponsor, team, PMO, governance bodies); internal organizational stakeholders (impacted departments, resource providers, support functions, compliance, legal, finance); external stakeholders (clients, end users, vendors, regulatory bodies, community groups); and any project-specific categories (user communities, industry associations, media in high-visibility projects). Document every candidate — filter after the session, not during.

Step 3 — Conduct individual interviews for high-priority stakeholder insights

For the sponsor, the primary client representative, and any stakeholders identified as high-power or high-influence, conduct focused individual interviews to understand their specific interests, concerns, and expectations before finalizing the stakeholder register. Group brainstorming surfaces stakeholder names; individual interviews reveal the nuanced information needed to develop effective engagement strategies. A powerful stakeholder with a strong opinion about a key project decision is a completely different engagement challenge than the same stakeholder with a neutral attitude — and only an interview reveals the difference.

Step 4 — Analyze stakeholders using a structured framework

Apply a consistent analytical framework (Power/Interest grid, Salience model, or organization-specific classification) to every identified stakeholder. Document the analysis in the stakeholder register. The analysis should answer: How much power does this stakeholder have to affect project outcomes? How interested are they in the project? What is their current attitude? What do they want from the project? What would cause them to resist or support the project? This analysis is the bridge between stakeholder identification and engagement strategy development.

Step 5 — Update the stakeholder register and related project documents

Compile the complete stakeholder register, including identification information, analysis data, and initial engagement notes for each stakeholder. Update the risk register with any stakeholder-driven risks surfaced during identification. Update the assumption log with assumptions about stakeholder attitudes or requirements that have not yet been validated. Flag any stakeholders whose requirements may not be reflected in the current requirements documentation — these are inputs to the requirements management process.

Step 6 — Validate and review with sponsor

Review the initial stakeholder register with the sponsor before distributing it more widely. Sponsors often have contextual knowledge that identifies additional stakeholders, corrects analytical assessments of existing ones, or flags politically sensitive information about certain stakeholders that requires careful handling. The sponsor’s validation also ensures that the engagement approach that will flow from the register is aligned with the sponsor’s understanding of the project’s stakeholder landscape.

5. When to Apply This Process

Mandatory scenarios

• Project initiation: The first complete stakeholder identification must occur during or immediately after project initiation — before planning activities that require stakeholder input (requirements elicitation, risk identification, communication planning) begin.
• Phase transitions: Each phase brings new stakeholders to prominence and may reduce the relevance of others. A phase gate review should include a stakeholder register review to ensure the identification reflects the new phase’s context.
• After significant scope or context changes: Any change that alters who is impacted by the project, who has authority over a project domain, or who has a stake in the project’s outcomes requires a stakeholder identification update.

Recommended scenarios

• Regularly throughout execution: PMBOK 8’s emphasis on continuous identification reflects the reality that stakeholder landscapes change. New regulatory requirements emerge, organizational structures change, vendor relationships evolve, and community responses to project impacts may surface new stakeholder groups.
• When issue or change logs surface new parties: The issue log and change log are excellent secondary sources for new stakeholder identification — parties who raise issues or request changes are stakeholders whose register entry should be reviewed for completeness.

6. Real-World Examples

Example 1: Project Phoenix — Website Launch

Context: PM Alex Morgan, PMP. 90-day website redesign and e-commerce integration for TechCorp (CEO Sarah Chen). Budget: $72,250.

How Identify Stakeholders was applied: Alex conducted a systematic stakeholder identification session during project initiation, reviewing the signed contract, the client’s organizational chart shared during the sales process, and the business case documentation. The initial brainstorming identified 14 stakeholder parties across three categories: agency-side (agency owner/sponsor, PM, developers, designer, QA, digital strategist), client-side (CEO Sarah Chen, marketing director, sales director, IT manager, legal/compliance representative), and external (HubSpot support, e-commerce platform vendor, web hosting provider, Google Analytics as a data source for baseline measurement).

The Power/Interest grid analysis immediately surfaced two engagement priorities: the CEO (high power, initially low interest — she had delegated day-to-day oversight to the marketing director) and the IT manager (medium power, initially resistant — he had concerns about a new integration’s security impact on the company’s existing CRM system). The IT manager’s resistance had not surfaced in the sales process. Alex scheduled a focused 30-minute call with the IT manager before the kickoff meeting to understand his security requirements — and discovered that the CRM integration required IT department approval for any new API connections to the company’s data infrastructure. This was a gate that would have caused a 2-3 week delay if discovered during sprint 4.

Result: By identifying and engaging the IT manager during initiation, Alex obtained IT approval for the HubSpot API integration during week 2 — before development began. The stakeholder identification also revealed that the legal/compliance representative needed to review any new forms collecting personal data, which Alex incorporated into the sprint 3 review plan. Neither of these requirements appeared in the contract or the project charter.

Example 2: Project ProjectAdm — SaaS PM Platform

Context: PM Eduardo. 18-month SaaS platform development. 8 developers, 2 designers, 1 QA. Cloud-based PM tool for mid-market companies.

How Identify Stakeholders was applied: For a product development project launching in multiple markets, stakeholder identification was considerably more complex than a client service project. Eduardo’s initial identification session categorized stakeholders into five tiers: Tier 1 (product decision authority): co-sponsors Eduardo and Henry Douglas, steering committee (board of advisors); Tier 2 (primary users): early access program participants, beta testers, initial paying customers, PMP-certified PM community; Tier 3 (compliance authorities): GDPR supervisory authorities (specifically the ICO in the UK and CNIL in France given the planned European market entry), California Attorney General (CCPA), and any PMI relationship implications for PMBOK 8 content use; Tier 4 (infrastructure stakeholders): AWS technical account manager, Stripe merchant agreement compliance team, third-party security assessment firm for SOC 2; Tier 5 (competitive environment): indirect stakeholders in the sense that competitor product announcements could shift user expectations and affect the product roadmap.

The stakeholder analysis produced a critical insight: the PMI (Project Management Institute) warranted formal relationship management. The product’s name and content directly referenced PMBOK 8 terminology. Eduardo’s legal counsel confirmed that while PMBOK content itself is protected, the PMI brand and certification names require care in marketing language. This stakeholder relationship — with PMI as an influential quasi-regulatory party — had not been considered in the initial product concept. A review of marketing copy and product feature naming conventions was added to the compliance checklist as a result.

The stakeholder register was updated six times over the 18-month project, with three significant additions: a data privacy advocacy organization that commented publicly on a beta feature, two enterprise client representatives who joined as strategic advisors during month 12, and a regional PM association that became a distribution partner.

7. Templates and Downloads

• Stakeholder Register — Software Development — Complete stakeholder register template with identification fields, Power/Interest analysis grid, attitude classification, and engagement notes sections.
• Stakeholder Engagement Plan Template — Template for the engagement strategy document that flows from the stakeholder register.

8. Five Common Errors

Error 1: Treating stakeholder identification as a one-time initiation activity

The single most common error in stakeholder management is treating identification as a checkbox to be completed once at project start and never revisited. PMBOK 8 is explicit: stakeholder identification should be performed “periodically throughout the project as needed.” Projects that do not continuously update their stakeholder register will consistently be surprised by stakeholder-driven issues that were entirely predictable from the evolving project context.

Error 2: Identifying only supportive or neutral stakeholders

There is a natural psychological tendency to focus stakeholder identification on parties who are aligned with the project. Resistant, hostile, or skeptical stakeholders are uncomfortable to identify and analyze, so they are often omitted or minimized. This is precisely backwards: resistant stakeholders represent the highest risk and therefore require the most proactive identification, analysis, and engagement. The stakeholder identification process must explicitly include parties who may oppose the project.

Error 3: Confusing stakeholders with project team members

The project team is a stakeholder group, but it is rarely the only significant one. Project managers who conduct “stakeholder identification” by listing team members have not performed stakeholder identification — they have produced a resource plan. True stakeholder identification expands the field of view to include the entire ecosystem of parties with a stake in the project’s outcomes.

Error 4: Failing to identify compliance and regulatory stakeholders

Regulatory bodies, compliance departments, legal teams, and standards authorities are among the most consequential stakeholders in any project operating in a regulated domain. They are also among the most commonly overlooked at identification, often because they are not directly involved in project execution. The opening example of this article illustrates exactly what happens when compliance stakeholders are not identified: late-stage compliance requirements disrupt execution at maximum cost.

Error 5: Producing a stakeholder register that no one reads or updates

A stakeholder register that is produced as a compliance artifact at project initiation and then filed away is not a project management tool. The stakeholder register should be a living document that is actively referenced during every stakeholder engagement planning discussion, updated when new information is obtained through stakeholder interactions, and revised when project conditions change. Its value is proportional to its currency and the team’s active engagement with it.

9. Tailoring This Process

• Project size: Small, internal projects with a limited and well-known stakeholder universe (a departmental process improvement, a team tool implementation) can execute a simplified stakeholder identification: a 30-minute team session, a one-page stakeholder list with basic analysis, and a commitment to review quarterly. Large, complex, multi-stakeholder projects require the full process with structured brainstorming, individual interviews, formal analytical frameworks, and regular periodic reviews.
• Adaptive approaches: Agile projects address stakeholder identification in the product owner role (who represents user and business stakeholder interests) and in sprint review stakeholder engagement. The stakeholder register may be less formal, but the underlying need — knowing who all the relevant parties are — is unchanged.
• Politically sensitive environments: Projects where stakeholder relationships are politically complex require more careful handling of the stakeholder register itself — the document’s distribution should be controlled to avoid exposing sensitive assessments of powerful stakeholders. The analytical work should still be done; the documentation may need to be sanitized or restricted in distribution.
• Community and public stakeholders: Projects with significant community impact (infrastructure, environmental, social) may require formal community consultation processes, public comment periods, and engagement with advocacy groups. These stakeholder categories require specialized engagement methods beyond standard project management practice.

10. Process Interactions

• Initiate Project or Phase: The project charter is the primary input to Identify Stakeholders. The chartering process itself may surface initial stakeholder information.
• Plan Stakeholder Engagement (Stakeholders Process 2): The stakeholder register is the primary input to engagement planning. Identify Stakeholders defines who needs to be engaged; Plan Stakeholder Engagement defines how.
• Plan Communications Management (Stakeholders Process 5): The stakeholder register defines the audience for all project communications, which is the foundational input to communication planning.
• Risk Domain: Stakeholder identification and risk identification are mutually reinforcing — each surfaces information relevant to the other. Stakeholder-driven risks should flow directly to the risk register from the identification process.
• Integrate and Align Project Plans: Stakeholder information from the register must be integrated into the requirements management plan, communications management plan, risk management plan, and stakeholder engagement plan.
• PMBOK 8 Process Index: Complete process map.

11. Quick-Application Checklist

• ☐ All project inputs reviewed before identification session (charter, business case, contracts)
• ☐ Structured brainstorming conducted with sponsor and key team members
• ☐ All stakeholder categories covered: internal, external, regulatory, compliance, vendors
• ☐ Individual interviews conducted with high-power/high-influence stakeholders
• ☐ Stakeholder analysis applied using consistent framework (Power/Interest or equivalent)
• ☐ Attitude toward project documented for each stakeholder
• ☐ Stakeholder register completed with all required fields
• ☐ Risk register updated with stakeholder-driven risks
• ☐ Assumption log updated with stakeholder-related assumptions
• ☐ Stakeholder register reviewed and validated with sponsor
• ☐ Periodic review schedule established for stakeholder register updates

Call to Action:

References

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

PMBOK Guide 8: The New Era of Value-Based Project Management. Available at: https://projectmanagement.com.br/pmbok-guide-8/

Disclaimer

This article is an independent educational interpretation of the PMBOK® Guide – Eighth Edition, developed for informational purposes by ProjectManagement.com.br. It does not reproduce or redistribute proprietary PMI content. All trademarks, including PMI, PMBOK, and Project Management Institute, are the property of the Project Management Institute, Inc. For access to the complete and official content, purchase the guide from Amazon or download it for free at https://www.pmi.org/standards/pmbok if you are a PMI member.