Stakeholder analysis is not about producing the longest possible list of names. It is about understanding the human and organizational system surrounding a project. A useful stakeholder analysis answers four practical questions: Who can influence the project? Who will be affected by its outcome? What does each person or group expect? How should the project involve them? When these questions are answered early—and reviewed as the project changes—the project manager is less likely to encounter late objections, unclear decisions, avoidable resistance or requirements that should have been discovered earlier.

A stakeholder is a person, group or organization that can influence a project, may be affected by it, or believes that the project could affect its interests. Internal stakeholders include project sponsors, team members, product owners, functional managers, operations personnel and assurance functions. External stakeholders include customers, suppliers, regulators, authorities, investors and affected communities. The obvious stakeholders are rarely the only important ones. A senior executive may have substantial decision authority but limited involvement in daily delivery. An operational employee may have little formal power but possess knowledge that determines whether the solution works. A regulator may never attend a project meeting but can prevent the outcome from being approved. Effective analysis therefore looks beyond job titles. Many project problems first appear technical or procedural but are actually stakeholder problems. A delayed decision may be caused by an unidentified approver. Resistance may indicate that affected users were consulted too late. Rework may result from a compliance requirement that was never discussed with the appropriate specialist. Good analysis helps the project manager involve the right people, improve requirements, discover assumptions, identify support and resistance, clarify decisions, adapt communication and anticipate adoption or compliance risks. A stakeholder register is therefore a working decision-support tool—not an administrative formality. A practical rule worth remembering is: If a stakeholder is discovered only when they object, the project has discovered them too late.

1. Begin with the project context Start by understanding why the project exists and how it will operate. Review the business case, charter, expected benefits, scope, contracts, governance, organizational structure, regulatory obligations, assumptions and lessons from similar projects. Do not read these documents only for technical information. Ask who approves the investment, provides resources, operates the result, can prevent release and measures benefits. Each answer points towards a potential stakeholder. 2. Scan beyond the immediate team The first stakeholder list is often too narrow because it reflects the project manager’s existing network rather than the project’s complete environment. Look across governance, delivery, users, operations, assurance and the external environment. Ask participants: “Who else can influence this work, make a decision about it or be affected by its outcome?” 3. Analyse what actually matters A name and job title are not enough. Consider interest, influence, degree of impact, current attitude, expectations, information needs, decision authority, required contribution, urgency and relationships with other stakeholders. Base conclusions on evidence. A person described as resistant may actually be concerned about workload, timing, operational risk or loss of control. Understanding the concern is more useful than applying a label. 4. Prioritise engagement—not people Use a power–interest or influence–impact grid to decide where engagement effort is most valuable. These categories are starting points rather than permanent labels. People with limited formal authority may still determine whether a process is adopted or whether requirements are practical. Prioritisation determines the engagement approach; it does not determine whose concerns deserve respect. 5. Maintain a useful stakeholder register Record information that improves decisions: role, relationship, interests, expectations, influence, impact, decision responsibilities, engagement needs, relationship owner and next action. Avoid unnecessary personal opinions or sensitive descriptions. If an entry would be inappropriate to show the stakeholder concerned, reconsider whether it should be recorded in that form. 6. Revisit the analysis Review the analysis when scope, phase, leadership, governance, suppliers, risks, regulation or stakeholder attitudes change. A stakeholder with little influence during planning may become essential during deployment. The analysis should change as the project changes.

A regional wholesaler is preparing to open a new distribution warehouse while introducing a warehouse-management system and revised order-fulfilment process. The initial stakeholder list contains the business owner, project manager, warehouse manager, software vendor and building contractor. It appears reasonable, but it reflects only the parties already attending meetings. The project manager reviews the business case, operating model, lease obligations, implementation plan and statutory requirements. A workshop identifies warehouse employees, procurement and inventory teams, finance, e-commerce and customer service, major retail customers, suppliers, delivery partners, IT security, local authorities, the landlord and the ongoing support team. The warehouse manager has operational authority. Warehouse employees have less formal power but understand the receiving, picking and dispatch work, making their involvement essential. The software vendor controls a technical dependency but does not own adoption. The local authority can delay opening if evidence is incomplete, while major customers need notice of temporary delivery changes. The project manager adapts the approach. Employees join process walkthroughs and prototype testing. The authority receives evidence through scheduled compliance reviews. Customers receive targeted transition updates. Finance validates inventory-control requirements. The sponsor resolves cross-functional decisions, and the support team joins before deployment rather than after launch. Two months later, the company adds temperature-controlled products. The project manager revisits the analysis. The change introduces quality specialists, equipment suppliers and additional regulatory contacts, while increasing the influence of facilities and compliance. Discovering these consequences before construction and configuration are finalized avoids expensive rework.

When a PMP question presents an unidentified, resistant or dissatisfied stakeholder, the strongest response will usually begin with understanding and analysis. Look for actions such as identifying the affected stakeholder, investigating expectations, assessing influence and impact, facilitating discussion, reviewing the engagement approach, updating the register or involving the appropriate decision maker. Be cautious about answers that immediately escalate the stakeholder, remove them from participation, reject the concern, change the project without analysis or send more communication without understanding the underlying need. The project manager should normally understand the situation before selecting a response.

Stakeholder analysis is not about completing a matrix. It is about seeing the project through the perspectives of the people who authorize it, deliver it, use it, govern it and live with its consequences. Identify broadly, analyse using evidence, prioritise the engagement approach and review the analysis whenever the environment changes. The goal is to involve the right people early enough for their knowledge, authority and concerns to improve the outcome.