Stakeholder Management in Practice: Engaging the Right People in the Right Way

01 / Simply explained

What is stakeholder management in a project?

Projects change things. They introduce new systems, change processes, create new responsibilities or replace existing ways of working.

These changes affect people and organisations in different ways.

Some decide on budgets or approvals. Others will work with the result every day. Others provide essential information, represent interests or can significantly influence the project through their decisions.

These people and groups are known as stakeholders.

Stakeholder management means identifying relevant people and groups early, understanding their interests, influence and how they are affected, and using that understanding to define appropriate engagement and communication activities.

The aim is not to collect as many names as possible in a matrix.

The questions that matter are:

• Who can influence the project or important decisions?
• Who is particularly affected by the change?
• What expectations, interests or concerns do they have?
• What information does each person or group need?
• How should we involve them, and how often?

Stakeholder management is therefore not a one-off exercise at the start of a project. Roles, interests and attitudes can change during the project and should be reviewed regularly.

02 / Why it matters

Technically complete does not mean successfully introduced

A project can be well planned and technically well executed, yet still run into difficulties.

Perhaps an important interest group was involved too late. Perhaps an affected business team only learns shortly before the rollout what will change for them. Or a stakeholder involved in decisions receives regular status updates, but not the information they actually need for an upcoming decision.

The result is questions, additional coordination, resistance or delayed decisions.

It can then look as though a new problem has suddenly appeared.

In fact, that stakeholder may have been relevant from the start; their perspective was simply not sufficiently considered.

Good stakeholder management does not eliminate every disagreement. It makes different interests visible early and helps you plan communication and participation deliberately.

This is particularly important for projects that affect many areas or involve substantial organisational change.

03 / Practical Example: IT Rollout Across Multiple Sites

One solution, different perspectives

Imagine a company introducing a new digital application at several sites.

The technical solution is ready. Yet different stakeholders view the rollout from very different perspectives.

Management and the project sponsor are primarily interested in progress, costs, risks and whether the planned objectives will be achieved.

Local leads need to know when their site will be affected, what resources are required and how deployment can fit around day-to-day operations.

IT and support teams need technical information, clear responsibilities and a planned handover to operations.

End users, on the other hand, mainly want to know: What will change for me? What do I need to do? Where can I get support?

Employee representatives, data protection, information security, external suppliers or other business teams may also be involved.

A single status email to everyone would hardly meet these different information needs.

The project team therefore analyses early which groups are relevant, how strongly they are affected, how much influence they have and what form of involvement makes sense.

For management, a concise monthly status update highlighting decisions needed may be appropriate. Local leads may need regular rollout coordination meetings. Closer to deployment, end users receive information about specific changes, practical guidance and training opportunities.

In this example, stakeholder management means more appropriate communication, rather than more communication.

And the analysis does not stay static.

For example, if a site joins the rollout earlier than planned, or an organisational decision affects additional people, the stakeholder landscape changes too.

This example describes a generalised project situation and contains no confidential customer information.

04 / How to Put Stakeholder Management into Practice

Step 1: Identify stakeholders systematically

Start with the question:

Who influences the project, and who is influenced by it?

Look beyond the immediate project team.

Relevant stakeholders may include the project sponsor, management, business teams, end users, operations and support teams, employee representatives, data protection, information security, external suppliers or other projects with dependencies.

It helps to start with groups and record individuals only where this is genuinely necessary for decisions or communication.

Keep the register manageable.

Step 2: Assess influence and impact

Not every stakeholder needs the same level of attention.

A simple assessment of influence and impact, each rated low or high, is enough to get started. Here, impact means how strongly a stakeholder is affected by the change.

This provides a straightforward guide:

This matrix is deliberately simple.

It is not a mathematical truth and does not replace an assessment of the specific project environment. A stakeholder with little formal influence may, for example, have valuable expertise or be particularly important for acceptance of a change.

The matrix helps us think; it does not decide for us.

Step 3: Understand interests and stance

Influence alone tells us little about how a stakeholder views the project.

It is therefore worth considering interests, expectations and current stance as well.

A simple classification could be:

• supportive
• neutral
• critical

This assessment should not be treated as a label.

A critical stance may point to legitimate risks, missing information or effects that the project team has not yet sufficiently considered.

That is precisely why it is valuable.

It is also important to remember that attitudes can change. An assessment made at the start of a project should not be treated as fixed for its entire duration.

Step 4: Identify communication needs

This is where the analysis becomes practical project work.

For each relevant stakeholder or group, ask:

• What information do they need?
• What do they need it for?
• How detailed does it need to be?
• Which channel is suitable?
• How often, or at what point, should communication take place?
• Who is responsible for communicating?

A steering committee may need a concise monthly overview of status, risks and decisions.

A local rollout team, by contrast, needs operational information about dates, prerequisites and outstanding tasks.

End users mainly need clear information about what will change for them and where they can find support.

Good communication is shaped by what the recipient needs, rather than by how much information the project team can send.

Step 5: Define actions and responsibilities

An email will not meet every stakeholder need.

Possible actions include regular coordination meetings, workshops, decision papers, status reports, information sessions, training or targeted one-to-one conversations.

For important actions, it should be clear who is responsible.

This avoids a general task called “inform stakeholders” appearing in the project plan without anyone ultimately taking ownership.

Stakeholder management therefore goes beyond communication planning. Depending on the situation, it can also mean involving people early in decisions, testing or designing a solution.

Step 6: Review and adjust regularly

Projects change, and so do their stakeholders.

New people become involved. Responsibilities change. Decisions alter the project scope. A group that was initially neutral may suddenly be affected much more strongly by specific changes.

Review the stakeholder register regularly, for example as part of the project status review or before important phases and rollouts.

A “Last reviewed” field helps show when an assessment was last consciously reconsidered.

The key question is not:

“Have we carried out a stakeholder analysis?”

It is:

“Is our assessment still current, and are we acting on it?”

05 / Tool: Stakeholder Register and Communication Planning

The matrix is only the starting point

An influence–impact matrix can help you quickly structure the stakeholder landscape.

For everyday project work, however, the matrix alone is rarely enough.

The assessment needs to lead to specific actions.

That is why our planned template combines a stakeholder register, communication planning and a simple overview matrix.

One possible structure:

The examples are deliberately fictional.

The Excel version will provide simple dropdowns for influence, impact and stance. An additional overview can visualise stakeholders by influence and impact.

The Confluence version uses the same essential fields in a concise, copyable table.

The important point is: the template is a working tool, not an end in itself.

A simple, up-to-date list with clear actions is more useful than an elaborate matrix that is no longer maintained after the project starts.

Stakeholder management or change management?

The two topics are closely related, but they are not identical.

Stakeholder management primarily asks: Who is relevant, what interests and influence do they have, and how should we organise engagement and communication?

Organizational Change Management takes a broader view of how a change can be accepted, implemented and sustainably embedded in an organisation.

Stakeholder management is therefore often an important part of change management, but does not replace it.

06 / Avoid Common Mistakes

Analysing stakeholders only at the start: A matrix quickly loses its value if changes are not taken into account.

Considering only hierarchy: Influence does not come only from a formal management role. Expertise, acceptance and operational dependencies can be equally important.

Giving everyone the same information: Different stakeholders have different information needs. A lengthy standard email is not automatically good communication.

Treating critical stakeholders as a problem: Criticism can highlight risks, impacts or missing information. The aim is not to “win over” critical voices, but to understand their perspective and involve them appropriately.

A matrix without actions: Placing people in four quadrants achieves little if it does not lead to a specific communication or engagement approach.

Recording too much personal information: Only include information that is actually needed to manage the project. Personal judgements and unnecessarily sensitive information do not belong in the register.

07 / Takeaway

Projects change systems, and almost always change how people work too.

Stakeholder management helps you consider this perspective before resistance, questions or delays arise.

Identify relevant stakeholders early. Understand their influence, how they are affected and their interests. Define specific actions and review your assessment regularly.

The stakeholder matrix is not the outcome. What matters is what we do with it to improve communication and collaboration.

You often do not need a complex tool.

A simple, current stakeholder register with clear responsibilities and communication activities can already make a significant difference.

08 / Matching Template

Stakeholder Register & Communication Plan

The planned template combines stakeholder analysis and communication planning in one simple working tool.

Excel template: a stakeholder register with dropdowns for influence, impact and stance, plus a simple matrix and overview sheet.

Confluence template: a concise, copyable table with the same essential information for collaborative project work.

Core fields:

• Stakeholder / group
• Role / interest
• Influence
• Impact
• Stance
• Communication needs
• Action / channel
• Owner
• Frequency
• Last reviewed

Stakeholder Register & Communication Plan – Excel and copyable Confluence template

Related topics: Decision Management · Risk Management · Organizational Change Management · Project Status Reports