Stakeholder Analysis: criteria and prioritization in projects

Learn how to perform stakeholder analysis in projects using influence, impact, legitimacy, urgency, attitude, and dependencies to prioritize decisions and engagement.

Check it out!

Stakeholder analysis is the structured process of assessing who can influence a project, who will be affected by it, which interests are at stake, what capacity each party has to enable or block decisions, and how these conditions change throughout the life cycle. It turns a list of interested parties into management intelligence: it makes it possible to prioritize attention, anticipate conflicts, calibrate communication, define engagement strategies, and support governance decisions with explicit criteria.

In engineering projects, the analysis should not be limited to job titles, organization charts, or a generic power-interest matrix. The client, operations, maintenance, engineering, supervision, suppliers, integrators, utilities, regulatory authorities, users, communities, and other parties may have formal or informal influence, different levels of impact, legitimacy, urgency, and critical knowledge. A robust analysis combines these factors and records the evidence that supports each classification.

What is stakeholder analysis

Stakeholder analysis is an interpretation and prioritization stage that follows the identification of interested parties. While identification answers who participates, influences, or is impacted, analysis seeks to understand how much, how, when, and over which decisions that influence or impact is manifested.

In stakeholder management, analysis serves as a bridge between understanding the project environment and managerial action. It provides the basis for defining relationship strategy, governance, escalation, communication, and the treatment of stakeholder-related risks.

The objective is not to label people. The objective is to produce an operational reading of the context to guide decisions. A stakeholder classified as highly influential, for example, is not “more important” as a person; it only means that the stakeholder has greater capacity to affect a specific decision, deliverable, authorization, or project result at that moment.

Stakeholder analysis, mapping and matrix: what is the difference?

The three concepts are related, but they are not equivalent.

Stakeholder mapping organizes actors and relationships: who relates to whom, where interfaces exist, dependencies, flows of influence, and decision points. The stakeholder matrix, in turn, is a classification tool, normally used to position interested parties according to two or more criteria.

Analysis is broader. It can use maps, matrices, interviews, registers, document analysis, workshops, governance data, decision history, risks, and contractual evidence to form a consolidated view.

Element	Main question	Result
Identification	Who are the stakeholders?	Initial list
Mapping	How do they relate?	Relationship and interface map
Analysis	What do we need to understand about each one?	Analytical profile and priorities
Matrix	How do we compare and classify?	Positioning by criteria
Engagement	What will we do based on the analysis?	Strategy and actions

In simple projects, these activities may take place in a single meeting. In multidisciplinary projects, complex contracts, brownfield environments, regulated environments, or projects with many interfaces, treating them as distinct stages improves traceability and reduces improper simplification.

Why stakeholder analysis is critical in engineering projects

Stakeholder analysis creates value when it stops being a list of names and begins connecting influence, impact, requirements, decisions, and dependencies. In complex projects, this understanding is part of technical governance.

Learn about Engineering Project Management

Engineering projects depend on distributed decisions. The project team rarely controls budget, requirements, access to areas, operational clearances, input data, technical approvals, civil and electromechanical interfaces, shutdown windows, safety, permits, procurement, and acceptance on its own.

This means that many apparently “technical” delays originate in governance. A project may have the correct solution and still miss deadlines because the party responsible for approving an assumption was not identified as a decision-maker; because operations was consulted too late; because a utility had an incompatible lead time; or because an informal stakeholder had the ability to block a change despite not appearing on the organization chart.

A well-conducted analysis helps anticipate this type of situation by connecting actors to decisions, deliverables, dependencies, risks, and responsibilities.

When to perform the analysis

The first analysis should be performed as soon as there is enough information to recognize the main stakeholders. This normally occurs during initiation, mobilization, scope definition, or the beginning of planning.

However, the analysis is not an opening document that remains frozen. It should be reviewed whenever relevant changes occur, such as:

changes in scope or requirements;
entry or departure of suppliers;
change of sponsor, manager, supervisor, or key team members;
beginning of a new life-cycle phase;
field mobilization;
change in implementation strategy;
occurrence of a relevant conflict;
new regulatory requirement;
discovery of a critical interface;
need for commissioning, acceptance, or transition to operations.

The review frequency does not need to be bureaucratic. The criterion should be a material change in context.

Start by correctly identifying stakeholders

No analysis technique can compensate for incomplete identification. Before classifying power, interest, or urgency, it is necessary to verify whether the analyzed universe actually represents the project environment.

The initial list can be built from the contract, terms of reference, business case, WBS, responsibility matrix, organization charts, project plans, risk registers, requirements, minutes, supplier lists, permits, external interfaces, and operations documentation.

The Stakeholder Register should function as the controlled repository for this information. The analysis uses the register, adds criteria, and feeds updated classifications and decisions back into it.

Do not restrict stakeholders to people who attend meetings

A frequent mistake is to confuse operational presence with relevance. Some parties appear little in day-to-day activities but have significant capacity to affect the project: sponsors, legal departments, procurement, operational safety, utilities, licensing authorities, investment committees, or authorities responsible for releasing access and interventions.

Also identify those who are impacted

A stakeholder is not only someone who decides. An operations area may have little formal authority and still receive a high level of impact. Users may not technically approve a system, but they can be decisive for usability, transition, and operational acceptance requirements.

This distinction is essential to prevent the analysis from becoming a simple hierarchical ranking.

Which criteria to use in stakeholder analysis

There is no single mandatory combination of criteria. The selection should reflect the type of project, the decision the analysis is intended to support, and the organization’s maturity. However, some criteria recur frequently and provide a robust basis for engineering.

Power and influence

Power represents the ability to determine, authorize, or block decisions. Influence is a broader concept: it includes the ability to change perceptions, priorities, behaviors, or decisions even without formal authority.

Sources of power or influence may include:

hierarchical authority;
contractual responsibility;
budget control;
approval authority;
control of resources or access;
control of critical information;
regulatory authority;
ability to interrupt operations;
relationships with decision-makers;
recognized technical legitimacy.

For this reason, assessing influence only by job title tends to produce errors.

Interest

Interest indicates how closely the stakeholder follows, values, or engages with the project. It may be driven by an expected benefit, operational impact, risk exposure, functional responsibility, cost, reputation, safety, or consequences for the stakeholder’s own goals.

High interest does not imply support. A stakeholder may follow the project very closely precisely because they disagree with the solution or perceive a high level of risk.

Impact received

Impact received assesses how much the project changes conditions that are relevant to the stakeholder. In engineering, this may involve asset availability, safety, productivity, maintenance, operational routines, physical access, architecture, CAPEX, OPEX, compliance, training, or service quality.

This criterion is especially important because highly impacted parties may have little formal authority. Ignoring them can lead to late resistance, rework, and acceptance difficulties.

Legitimacy

Legitimacy considers whether the stakeholder’s participation or claim has a recognizable basis within the project context. Its origin may be contractual, legal, regulatory, technical, institutional, operational, or social.

The concept is useful for distinguishing factual influence from legitimacy. A person may have strong informal influence and little formal responsibility; another may have an important legal or contractual obligation despite limited day-to-day presence.

Urgency

Urgency represents the degree of immediacy with which a demand needs to be considered. It is not synonymous with verbal pressure. It should be assessed based on time criticality, the consequence of delay, the decision window, regulatory deadlines, operational impact, or dependency on other activities.

The combination of power, legitimacy, and urgency is associated with the stakeholder salience model developed by Mitchell, Agle, and Wood. In projects, it is useful precisely because it prevents prioritization from being restricted to a two-dimensional matrix.

Attitude

Attitude describes the stakeholder’s current position regarding the project, decision, or change: supportive, neutral, resistant, critical, or variable. Its value lies in understanding the tendency and its rationale, rather than labeling people as “positive” or “negative.”

A critical position may reveal an unmet requirement, a real risk, lack of evidence, an underestimated operational impact, or a legitimate contractual conflict.

Critical knowledge

Some parties hold knowledge without which engineering cannot make sound decisions. This may include process knowledge, asset history, installed technology, maintenance restrictions, user behavior, internal standards, legacy integrations, or operating assumptions.

This stakeholder may have little hierarchical authority and still be essential to decision quality.

Dependency

Dependency assesses how much an activity, deliverable, or decision depends on that stakeholder’s actions. Examples include document approval, provision of data, access to a facility, issuance of a permit, electrical shutdown, release of a shutdown window, equipment approval, or availability of the operations team.

Dependency makes the analysis immediately useful for schedule and interface management.

Ability to enable or block

In complex projects, it is useful to explicitly record whether a stakeholder can enable or block a decision, work front, investment, approval, or acceptance. This capacity may result from formal authority, control of resources, access, knowledge, or influence over other decision-makers.

How to turn criteria into a usable analysis

A good analysis needs to balance simplicity and explanatory power. Models with dozens of criteria may appear sophisticated, but they become difficult to update. Overly simplistic models, on the other hand, hide relevant factors.

A practical structure is to start with four core dimensions — influence, interest, impact received, and attitude — and add legitimacy, urgency, critical knowledge, or dependency when the context justifies it.

Criterion	Analysis question	Example evidence
Influence	Can they change or block a decision?	authority level, contract, authority, history
Interest	How closely do they follow or care?	participation, responsibilities, goals
Impact	How much will they be affected?	operations, cost, routine, safety
Legitimacy	Is there a basis for their claim?	law, contract, assignment, operations
Urgency	Is there real time pressure?	deadline, window, criticality
Attitude	What is the current position?	statements, decisions, actions
Knowledge	Do they hold critical information?	technical or operational expertise
Dependency	Does the project depend on their action?	approval, data, access, resource

The method should be documented so that two different people can understand why a particular classification was assigned.

Qualitative or quantitative scales

The scale may be qualitative — low, medium, high — or quantitative, such as 1 to 5. The choice depends on complexity and the need for comparison.

Qualitative scales are faster and work well when the team understands the context. Numerical scales help rank many stakeholders, but they create a risk of false precision. The difference between a score of 4 and 5 may not be objectively demonstrable.

When numbers are used, each level should have an operational definition. For example, influence 5 may mean “has authority to directly approve, reject, or stop the matter under analysis,” while influence 3 may represent “does not formally decide, but is consulted and their recommendation frequently changes the decision.”

Without defined criteria, scoring becomes opinion disguised as data.

How to assess influence objectively

Influence can be broken down into observable sources. Instead of asking only “is this person influential?”, analyze:

do they have approval authority?
do they control the budget?
do they control access to a resource or facility?
can they interrupt operations?
do they have contractual authority?
are they responsible for a requirement or acceptance?
do they hold knowledge without an immediate substitute?
do they influence the decision-maker?
do they participate in a governance committee or forum?
do they represent an external authority with approval powers?

Answering these questions reduces bias and makes the classification more defensible.

Formal influence and informal influence

Formal influence derives from structure, contract, standards, processes, or delegated authority. Informal influence arises from reputation, experience, trust, relationships, knowledge, or the ability to mobilize other actors.

Projects can fail when they analyze only the first type. In brownfield environments, for example, a maintenance professional with decades of experience may not hold an executive position, but their opinion may determine whether a solution is accepted by operations. In other cases, an external technical specialist may influence the decision-maker without having contractual responsibility.

Stakeholder mapping helps visualize these relationships that the organization chart does not show.

How to analyze interest without confusing it with support

Interest should reflect the intensity of attention and the relevance of the project to the stakeholder. Attitude is analyzed separately.

This separation creates useful combinations:

high interest and support: tends to be an active ally;
high interest and resistance: requires deep understanding and structured dialogue;
low interest and high influence: needs to be kept appropriately informed and engaged at decisive moments;
high impact and low influence: requires protection against exclusion from the decision-making process;
low influence and low impact: proportional monitoring, without abandonment.

The objective is not to create automatic responses, but to guide the intensity and form of the relationship.

How to analyze impact received

Impact should be assessed both during implementation and after delivery. An operations team may experience little impact during the project and significant impact after the system enters service. A finance area may be highly impacted by CAPEX and contracts, but participate very little in future operations.

A complete analysis asks:

what will change for this party?
is the change temporary or permanent?
is there an impact on safety or continuity?
is there a change in process, routine, or responsibility?
are there additional costs?
will training be required?
will the party assume future maintenance?
will they depend on documentation, permits, or support?
will they participate in acceptance?

This understanding brings stakeholders closer to requirements and success criteria.

How to assess legitimacy and urgency

Legitimacy and urgency are useful criteria when several actors compete for the project’s attention. However, they should be used carefully.

Legitimacy does not mean agreement. A claim may be legitimate and technically unfounded; in that case, it deserves analysis and a response, not automatic acceptance. Likewise, an urgent demand may be of little relevance, while another demand without immediate pressure may represent a high risk to future operations.

The value of these criteria lies in broadening the assessment. They prevent hierarchical power from becoming the sole prioritization mechanism.

Stakeholder salience model

The salience model proposed by Mitchell, Agle, and Wood combines power, legitimacy, and urgency to analyze the degree of attention stakeholders tend to receive. In project management, it can complement the power-interest matrix when the environment includes actors with very different claims.

The model is particularly useful in projects involving authorities, communities, regulatory agencies, sponsors, critical suppliers, or multiple internal areas with different responsibilities.

It should not be used as a definitive classification. Salience changes with events. A utility may have low urgency at the beginning of engineering and become critical when the connection reaches the critical path. An operations area may gain urgency during the transition to commissioning and acceptance.

How to analyze attitude and resistance

Resistance should not be treated as a behavioral failure. Before defining a strategy, it is necessary to understand its origin.

Resistance may result from:

unaddressed operational impact;
omitted requirements;
perceived risk;
previous negative experience;
loss of autonomy;
change in responsibility;
lack of technical evidence;
insufficient communication;
conflicting objectives;
contractual concerns;
budget or schedule constraints.

When the cause is known, the team can decide whether it needs to review the solution, produce evidence, negotiate trade-offs, clarify responsibilities, or escalate a decision.

The article on Conflict Management in Engineering Projects explores the treatment required when disagreements cease to be merely different positions and begin blocking decisions or deliverables.

How to analyze dependencies between stakeholders and decisions

The analysis becomes much more useful when each stakeholder is associated with the decisions they can affect.

Instead of recording only “high influence,” record what the stakeholder influences. A sponsor may decide on investment, but not on technical specifications. Maintenance may have strong influence over maintainability, but not over commercial strategy. Supervision may accept or reject contractual deliverables, while operations validates conditions of use.

This contextualization reduces generic classifications and improves governance.

Relationship between stakeholder analysis, decisions, and management actions

Stakeholders and decision rights

A project may have many interested parties and few formal decision-makers. Confusing participation with authority creates long meetings, diffuse approval, and delays.

The analysis should record who:

recommends;
provides information;
performs technical review;
approves;
provides contractual acceptance;
authorizes implementation;
can veto due to legal or safety requirements;
only needs to be informed.

The RACI Matrix helps detail responsibilities for activities and deliverables. Stakeholder analysis, however, remains necessary because RACI does not measure influence, interest, legitimacy, urgency, or attitude.

Stakeholder analysis and interface management

When interfaces, contracts, and responsibilities intersect, the analysis needs to be integrated with supervision, requirements, and the client’s decision forums. This is a typical Owner’s Engineering function in multidisciplinary projects.

See how Owner’s Engineering works

Stakeholders become especially critical at interfaces. A technical interface almost always also has an organizational interface: two disciplines, two companies, two departments, or two authorities need to coordinate information and responsibility.

Interface Management in Engineering Projects should be connected to the analysis to identify who is responsible for each boundary and who has the capacity to resolve impasses.

This integration makes it possible to distinguish three situations:

a technical problem within one discipline;
an interface problem between responsibilities;
a governance problem because the decision has no clear owner.

The third tends to remain invisible when stakeholder analysis is superficial.

Relationship with requirements and acceptance criteria

Stakeholders are sources, owners, validators, or users of requirements. For this reason, the analysis should record which parties are related to critical requirements and in what role.

Requirements Management in Engineering helps connect need, specification, change, verification, and acceptance. When this traceability includes stakeholders, it becomes possible to answer:

who originated the requirement;
who has authority to change it;
who validates compliance with it;
who will be impacted if it changes;
who needs to participate in acceptance.

This reduces the risk of decisions that are technically correct in isolation but incompatible with the client’s or operations’ actual needs.

Relationship with risk management

Stakeholders may be a source of risk, be affected by risks, or be responsible for responses. The analysis should therefore feed the risk management process.

Examples:

late approval may create schedule risk;
dependency on an external authority may create regulatory risk;
low participation by operations may create acceptance risk;
a critical supplier may create supply risk;
conflict between departments may create late-change risk;
a stakeholder with unique knowledge may create information concentration risk.

It is important to avoid deterministic wording such as “the stakeholder is a risk.” The risk is the uncertain event or condition; the stakeholder participates in the causal context, consequence, or response.

How to connect analysis to the communication plan

The Project Communication Plan should derive from the analysis, not from a standard meeting calendar.

Stakeholders with high influence over a critical decision may need objective executive communication, with alternatives, impacts, and the decision required. Technical teams may require detailed, traceable communication. Operations may need demonstrations, workshops, and performance evidence. External authorities require formal channels and documents.

The analysis guides content, frequency, channel, responsible party, level of detail, and response deadline.

How to connect analysis to engagement

Communicating does not mean engaging. Stakeholder Engagement uses the results of the analysis to define how each party should participate in decisions, validations, reviews, tests, changes, and transition.

A stakeholder who is highly impacted and has little influence may need greater participation precisely to prevent their needs from being ignored. Another stakeholder with high influence and low interest may require targeted involvement at decision gates, without being included in the entire operational routine.

The strategy is proportional to the context, not to hierarchical status.

Step-by-step stakeholder analysis

1. Define the object of the analysis

Do not start by scoring people. Define whether the analysis covers the entire project, a phase, a decision, a change, an implementation, an interface, or a specific problem.

The influence of the same stakeholder varies depending on the object.

2. Consolidate the stakeholder register

Verify that the register includes internal, external, contractual, operational, regulatory, and impacted parties. Eliminate duplicates without losing distinct roles.

3. Link stakeholders to deliverables and decisions

Associate each party with the elements that actually matter: requirements, approvals, interfaces, risks, resources, milestones, acceptance, and operations.

4. Choose criteria

Select a small number of criteria capable of explaining the context. Influence, interest, impact, and attitude provide a good basis. Add legitimacy, urgency, dependency, or knowledge when necessary.

5. Define scales

Describe the meaning of each level before classifying. Avoid scores without rules.

6. Collect evidence

Use documents, interviews, workshops, decision history, formal responsibilities, and observation of how the project actually operates.

7. Classify and record rationale

The classification should be accompanied by a brief rationale, especially in higher-priority cases.

8. Analyze relationships

Check who influences whom and where coalitions, dependencies, conflicts, and informal decision paths exist.

9. Define priority and strategy

Convert the analysis into actions: communication, participation, technical review, negotiation, escalation, monitoring, or protection of impacted interests.

10. Assign an owner

Every relevant action needs an owner. Otherwise, the analysis becomes a diagnosis without execution.

11. Integrate with other controls

Connect the analysis to the communication plan, risks, requirements, RACI, interfaces, schedule, procurement, and governance.

12. Review when the context changes

Update the analysis when events change power, impact, urgency, attitude, or dependencies.

Applied example: infrastructure modernization in an operating facility

Consider a systems modernization project in a facility that will remain in operation during implementation.

The sponsor controls budget and relevant scope changes. Their influence is high, but their interest in technical detail is moderate. The operations team experiences significant impact and holds critical knowledge; it may not control the budget, but it has the practical ability to prevent an unsafe or infeasible intervention. Maintenance holds legacy knowledge and maintainability requirements. Supervision evaluates contractual compliance and evidence. The main supplier controls equipment information and lead times. An external utility participates only at certain connection points, but it can block the corresponding milestone.

If the team uses only job titles, the sponsor appears at the top and everyone else below. If it uses influence, impact, knowledge, legitimacy, urgency, and dependency, the assessment changes by phase.

During conception, operations and maintenance gain relevance because of requirements definition. During procurement, supplier and procurement dependencies increase. Before intervention, safety and operations become critical. During commissioning, supervision, operations, and those responsible for acceptance receive concentrated attention.

This dynamic shows why the analysis needs to be time-dependent.

Analysis by life-cycle phase

Stakeholder priority may change between conception, design, contracting, implementation, commissioning, and assisted operation.

Phase	Frequently critical stakeholders	Reason
Conception	sponsor, users, operations	needs and objectives
Design	engineering, operations, maintenance	requirements and technical decisions
Procurement	procurement, engineering, suppliers	specification and contracting
Implementation	contractors, supervision, operations, safety	interfaces and execution
Commissioning	engineering, operations, supplier, supervision	evidence and performance
Acceptance	client, supervision, formal responsible parties	compliance and closeout
Assisted operation	operations, maintenance, support	stabilization and handover

The table is not universal; it illustrates how salience changes according to the stage.

How to address external stakeholders

External stakeholders require special attention because the project team has less control over their availability, priorities, and decision-making processes.

Utilities, public agencies, authorities, communities, neighbors, property owners, strategic suppliers, and certification bodies may operate under timelines and processes that differ from internal ones.

The analysis should record:

the legal, contractual, or institutional basis of the relationship;
the formal communication channel;
required documents;
lead times;
internal parties responsible for the relationship;
schedule dependencies;
decision points;
delay risks;
evidence and protocol requirements.

Failing to address these factors is a common source of unrealistic schedules.

Confidentiality and ethics in the analysis

Some stakeholder information is sensitive: attitude, informal influence, conflicts, interests, perceptions, and relationship strategies. The fact that this information is useful to management does not mean it should circulate widely.

The organization should define the access level, purpose, and form of recordkeeping. Derogatory language, personal judgments, and psychological diagnoses do not belong in a professional stakeholder register.

Prefer observable descriptions, such as “has approval authority,” “expressed concern about operational downtime,” or “requests validation before issuance,” rather than subjective adjectives.

The analysis should support governance, not create a file of opinions about people.

Biases that undermine the analysis

Hierarchy bias

Assuming that the highest-ranking position is always the most relevant stakeholder.

Availability bias

Prioritizing only those who participated in the most recent meetings.

Affinity bias

Classifying those who agree with the team as more relevant.

Conflict bias

Overestimating stakeholders who create pressure and ignoring quieter parties who are nevertheless strongly impacted.

Persistence bias

Keeping old classifications even after a change in phase, team, or context.

Precision bias

Believing that a numerical score eliminates professional judgment.

Recognizing these biases improves the quality of the analysis and encourages review by more than one person.

Stakeholder analysis workshops

In multidisciplinary projects, short workshops can produce a more complete view than individual assessments. Participants from engineering, PMO, operations, contracts, procurement, and supervision see different dimensions.

An effective workshop should have a clear object, an initial list, defined criteria, and a facilitator. The objective is not to reach absolute consensus on every score, but to reveal differences in perception and produce decisions about relationships and governance.

When two departments classify a stakeholder very differently, that is relevant information. It may indicate that the influence applies only to one part of the project or that there is information asymmetry.

How to document rationale

Every relevant classification should be explainable. A short rationale column greatly increases the usefulness of the register.

Example:

Stakeholder	Influence	Impact	Urgency	Rationale
Operations	High	High	Medium	validates windows and will receive the system
Sponsor	High	Medium	Low	approves budget and major changes
Critical supplier	Medium	Medium	High	equipment on the critical path
Users	Low	High	Medium	usage and transition requirements

The rationale should reflect the actual project, not generic formulas.

How to define priority without excluding stakeholders

Prioritizing means allocating attention proportionally. It does not mean ignoring groups classified as having lower influence.

A party with low formal influence may experience high impact and have legitimacy. An affected community, an end user, or a maintenance team may require appropriate consultation mechanisms even without decision-making authority.

Mature governance separates management priority from the right to participate.

From analysis to action

The analysis only creates value when it produces observable actions. Each priority stakeholder should have, as applicable:

a relationship objective;
an internal owner;
associated topics or decisions;
a communication strategy;
the expected level of participation;
upcoming milestones;
related risks;
an escalation mechanism;
required evidence or deliverables.

Stakeholder engagement is the execution layer of this strategy.

Indicators for monitoring effectiveness

Indicators should not measure stakeholder “likeability.” They should assess whether the relationship enables the project to obtain decisions, inputs, and validations within the required time.

Possible indicators include:

pending decisions by stakeholder;
average response time;
overdue approvals;
requirements without an owner;
interfaces without an owner;
overdue engagement actions;
changes resulting from late requirements;
escalated conflicts;
acceptance issues linked to stakeholders who were not previously involved.

These indicators connect the analysis to project performance.

Stakeholder analysis maturity

At low maturity, the organization maintains only contact lists and reacts to conflicts. At an intermediate level, it uses matrices and communication plans. At higher maturity, it connects stakeholders to requirements, risks, decisions, interfaces, responsibilities, schedule, and acceptance, reviewing the analysis throughout the life cycle.

The benefit does not come from producing larger documents, but from using the analysis to anticipate decisions and dependencies.

Stakeholder analysis in PMO and governance

A PMO or governance structure can standardize minimum criteria, templates, and review cadence without removing project autonomy.

Across portfolios, standardization helps identify recurring stakeholders, approval bottlenecks, conflicts between initiatives, and overload in critical departments. It also allows escalated decisions to reach the appropriate forums with sufficient context.

The article on processes and governance in engineering projects expands this view of integration between management, controls, and Owner’s Engineering.

When Consulting Engineering adds value

A Consulting Engineering structure can turn analysis into a governance routine: register, workshops, matrix, communication, risk management, decision traceability, and action tracking.

Learn about Consulting Engineering services

The analysis becomes especially relevant when the client needs to coordinate multiple disciplines, companies, contracts, suppliers, internal departments, and authorities but does not have a dedicated structure to consolidate interfaces and decisions.

In these scenarios, Consulting Engineering can structure the register, facilitate workshops, define criteria, connect stakeholders to requirements and risks, organize governance, prepare decision forums, and track engagement actions without replacing the client’s authority.

The value lies in turning a diffuse network of interests and responsibilities into a traceable decision-making process.

Checklist for reviewing the analysis

Before considering the analysis usable, verify whether:

internal and external stakeholders have been considered;
impacted parties without formal power are represented;
the criteria have clear definitions;
influence has not been confused with job title;
interest has been separated from support or resistance;
impact received has been analyzed;
legitimacy and urgency have been considered when relevant;
decisions and dependencies are associated with stakeholders;
classifications have rationales;
sensitive information has controlled access;
communication and engagement actions have been defined;
risks and requirements are integrated;
there is an owner responsible for updating the analysis;
there are clear triggers for review.

If the analysis does not lead to different decisions or actions, it is probably not capturing enough context or is recording information with little management value.

Final considerations

Analyzing stakeholders means understanding the actual structure of influence, impact, legitimacy, urgency, knowledge, and dependency surrounding a project. The technique is not limited to filling out a matrix; it organizes evidence to decide who needs to participate in which matter, with what priority, through which channel, and at what time.

In engineering, this capability is particularly important because requirements, interfaces, risks, approvals, and acceptance depend on distributed actors. Stakeholder analysis turns this complexity into governance: it identifies decision-makers, impacted parties, sources of knowledge, dependencies, and conflict points before they become delays or rework.

When integrated with the register, mapping, matrix, communication plan, RACI, interface management, and engagement, it ceases to be an isolated exercise and becomes a permanent component of project management.

Technical references

[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Geneva: ISO, 2020. Available at: https://www.iso.org/standard/74947.html

[2] PROJECT MANAGEMENT INSTITUTE. Stakeholder analysis: a pivotal practice of successful projects. Newtown Square: PMI, 2000. Available at: https://www.pmi.org/learning/library/stakeholder-analysis-pivotal-practice-projects-8905

[3] HUEMANN, Martina; ESKEROD, Pernille; RINGHOFER, Claudia. Rethink! Project Stakeholder Management. Project Management Institute. Available at: https://www.pmi.org/learning/library/2019/09/05/21/29/rethink-project-stakeholder-management-11644

[4] ASSOCIATION FOR PROJECT MANAGEMENT. Stakeholder engagement. Buckinghamshire: APM. Available at: https://www.apm.org.uk/resources/find-a-resource/stakeholder-engagement/

[5] MITCHELL, Ronald K.; AGLE, Bradley R.; WOOD, Donna J. Toward a theory of stakeholder identification and salience: defining the principle of who and what really counts. Academy of Management Review, v. 22, n. 4, p. 853–886, 1997. Available at: https://doi.org/10.2307/259247

Frequently asked questions

What is stakeholder analysis?

It is the process of assessing the influence, interest, impact, legitimacy, urgency, attitude, knowledge, and dependencies of interested parties to guide priorities, communication, engagement, and project decisions.

What is the difference between stakeholder analysis and a stakeholder matrix?

Analysis is the broader process of understanding and prioritizing stakeholders based on evidence and context. The matrix is only one of the tools used to classify or visualize part of that analysis.

Which criteria should be used to analyze stakeholders?

Influence, interest, impact received, and attitude provide a practical basis. Depending on the project, legitimacy, urgency, critical knowledge, dependency, contractual power, and the ability to enable or block decisions can also be added.

Should stakeholder analysis be performed only at the beginning of the project?

No. It should be reviewed whenever changes in phase, scope, team, contracts, risks, interfaces, or decisions alter influence, impact, urgency, or dependencies.

What is the stakeholder salience model?

It is an approach that uses power, legitimacy, and urgency to understand the degree of attention required by different stakeholders. In projects, it can complement power-interest matrices.

How can subjectivity be reduced in the analysis?

Define criteria and scales before classification, record evidence and rationale, use more than one perspective when possible, and review assessments when the context changes.

Can a stakeholder with little influence still be a priority?

Yes. A party may have low formal authority and still experience high impact, have legitimacy, hold critical knowledge, or play an essential role in operations and acceptance.

How does the analysis relate to the communication plan?

It guides which audiences need to receive which information, how often, through which channel, at what level of detail, and with which response deadlines.

Complementary technical materials