How do you efficiently achieve great stakeholder management?

How to manage project stakeholders in practice

Stakeholder management can sound more complicated than it needs to be. For me, the practical point is simple: find out who can affect the project or will be affected by it, understand what matters to them, and agree a sensible way to work together.

That does not mean making everybody happy or trying to control what people think. A project manager often has little formal authority over the people whose help is needed. The work is to listen, explain the choices honestly, make space for different perspectives and take concerns into the project’s decisions and plans.

In a project, stakeholders may include the sponsor, people who use the service, operational teams, delivery colleagues, suppliers, decision-makers, regulators and groups affected by the change. The right list depends on the project and can change as the work moves from design to delivery and handover.

Start with the outcome, not a template

Before building a stakeholder list or drawing a grid, write down what the project is meant to change. Then ask:

Who will use, operate, fund, approve or support the result?
Whose work, service or experience could change?
Who holds information, expertise, access or a decision the project depends on?
Who might be affected indirectly, including groups not represented in the project team?
Who should we ask, “Who else needs to be involved?”

Use more than the organisation chart. Ask delivery leads, operational managers and people close to the affected service. A senior person may have formal authority, while an experienced adviser or frontline team understands a practical dependency the project has missed.

Analyse enough to choose your next action

A power-and-interest grid can help a team start a conversation. It is not a scientific score or an instruction to put people in boxes. Power and interest are only part of the picture. Also consider how the person or group will be affected, what they know, how they currently view the change, what decision rights they hold and whether an issue is urgent.

Keep the assessment provisional. You may be working from assumptions, and people’s roles or views can change. Ask stakeholders directly where it is appropriate, compare what you hear with evidence and review your view when the project changes.

For example, a senior leader who seems to have low interest today may need to decide a funding issue next month. A group with no formal authority may still be essential: if their new process is unusable, the intended benefit may not happen. Neither case is captured well by a fixed “monitor” or “keep satisfied” label.

A practical six-step approach

Define the change. Be clear about the outcome, what is in scope, who is affected and what remains uncertain.
Identify people and groups. Include decision-makers, delivery partners, users, operational owners and people who may experience the effects.
Understand their perspective. Ask what success looks like for them, what concerns them, what information they need and what they can contribute. Do not assume resistance means someone is difficult; it may point to a real impact, a previous experience or a missing fact.
Choose an engagement action. Decide whether you need to inform, listen, consult, involve, negotiate, seek a decision or provide support. Pick a channel and timing that make sense for that person and the question.
Connect the response to project work. Record decisions, requirements, risks, actions and changes through the project’s normal routes. Engagement without a route for handling what people raise becomes a conversation that goes nowhere.
Review and adjust. Check whether the engagement was useful, whether the issue was resolved and whether the stakeholder picture has changed. Repeat at meaningful points, not just because a calendar says to.

Example: a new expenses process

This is an illustrative scenario. A project is replacing a manual expenses process with an online one. The sponsor wants faster processing and better reporting. Finance needs accurate evidence and a manageable control process. Employees want a process they can complete quickly, including when they travel or cannot access a laptop. Line managers need to understand what they are expected to approve. The technology team needs clear access and integration decisions.

A stakeholder grid might put the sponsor and finance lead in the high-power group, but that alone does not tell the project what to do. The PM could arrange a short decision session with the sponsor and finance lead about control requirements; ask a sample of employees to walk through common and awkward cases; confirm approval responsibilities with managers; and agree technical dependencies with the delivery team.

Suppose the user sessions show that staff often submit claims from a phone after travel. That is useful evidence. The team can test whether the proposed design works on mobile, record any requirement or limitation, and take a cost or scope trade-off to the authorised decision-maker if needed. The point is not to promise every request will be delivered. It is to show that the concern was heard, assessed and handled through a clear route.

After a pilot, ask whether the process works for different roles and situations, review support requests and error patterns, and check whether the expected benefit is appearing. If it is not, update the plan and explain what will change. A newsletter saying “the project is on track” is not a substitute for finding out whether the process works.

Use a small engagement record

You do not need a long profile for every person. For a small project, a few columns in the RAID or action log may be enough. For a larger project, keep a stakeholder register with only the information needed to deliver the work:

Person, group or role, and their project role or relationship to the change.
How they may be affected and what decision, input or support is needed.
Known concern, requirement or success measure, with its source or date checked.
Agreed engagement action, named project owner and next review point.
Related risk, assumption, decision, requirement or action reference where relevant.

Keep notes factual and proportionate. Do not collect family details, hobbies, personal opinions or other information just because a template has a field for it. Ask what is genuinely needed, use approved project systems, restrict access where appropriate and follow your organisation’s privacy and retention rules. “Concern about extra approval time, raised in user session on 12 May” is more useful and respectful than a speculative personality label.

Turn analysis into a communication plan

For each priority group, agree what the project needs from them and what they need from the project. A practical plan might look like this:

Group	Purpose	Method and timing	Owner	How we will use the response
Service users	Test common and difficult tasks	Short walkthrough before design approval; pilot feedback after launch	Business analyst	Confirm requirements and log gaps for a decision
Sponsor and finance lead	Agree the control and cost trade-off	Decision paper before the stage review	Project manager	Record the authorised decision and update scope or forecast
Line managers	Clarify approval responsibilities	Working session before training materials are final	Change lead	Confirm process, guidance and support needs

Use a meeting when discussion, challenge or a decision is needed. Use a written update when people need a consistent reference or a quick view of progress. Be clear about whether a message is for information, consultation or a decision. If you ask for feedback, say when it is due and how the project will consider it.

When stakeholders disagree

Do not turn disagreement into a popularity contest. First separate the facts, impacts, preferences and decision rights. Two groups may both be describing valid needs, such as tighter controls and a simpler user journey. Ask what requirement each need protects, what options are available and what happens if the team delays the choice.

Some choices belong to the sponsor or governance forum, not the project manager. Present options and consequences, recommend a way forward and make the decision route clear. If the answer is not yet known, record the open point, who will resolve it and by when. Then tell affected people what was decided and what it means for them.

Common traps to avoid

Sending everyone the same update. Different groups need different information, and some need a chance to respond.
Assuming silence means agreement. Ask for an explicit response where approval or consultation matters, and follow the agreed governance.
Calling people “resistant” too early. Find out whether the concern is about impact, timing, evidence, workload, trust or a genuine flaw in the proposal.
Promising influence you do not have. Be clear about what is open for change, what has already been decided and who can approve an exception.
Making the project manager the only relationship owner. Sponsors, service leads and delivery specialists should engage the people they are best placed to work with, using a shared view of the message and commitments.
Treating the register as the engagement. A spreadsheet does not build a relationship. Use it to remember the next useful conversation and follow through.

Before your next stakeholder conversation

Write down the outcome you need from the conversation, what you already know, what you still need to learn and who has authority to decide. Ask open questions, listen for impacts the plan may have missed, and close by agreeing what happens next. Afterward, record the useful project information and follow through on any commitment you made.

Stakeholder engagement is ongoing, but it does not need to become a large administrative exercise. A current list of the people who matter, a few honest conversations and a clear path from feedback to project action will usually help more than a detailed matrix nobody revisits.

For an example of how to reconnect scattered meetings, unclear plans and delivery activity, read my practical guide to bringing order to a messy project. If you need to prepare a decision-focused governance meeting, see the Steering Committee guide.