To engage stakeholders, understand how your project affects them, agree what they can influence, involve them before decisions are fixed, and explain what you do with their feedback. Give each action an owner and keep checking whether the approach is working.
This guide shows how to turn the four groups from your stakeholder analysis into an engagement approach, useful conversations, decisions and follow-up. A worked example shows how to apply each step when introducing a new staff booking system.
This is Step 4 of our stakeholder management guide. If you need the earlier steps, start with stakeholder identification, stakeholder analysis and stakeholder planning.
What is stakeholder engagement?
Stakeholder engagement is the ongoing work of involving people who can affect, or are affected by, your project. It includes understanding their concerns, sharing information, seeking their input and following through on commitments.
A project update tells people what is happening. Engagement also gives them a way to question, contribute and receive a response. It can help you discover requirements, test assumptions and identify problems before they become expensive changes.
You do not need everyone to agree with every decision. You do need to be clear about how decisions are made and take concerns seriously. A stakeholder can remain opposed to a proposal while taking part constructively.
The Association for Project Management's engagement principles stress understanding people, consulting early and building relationships. AccountAbility's AA1000SES overview also connects engagement with decisions and ongoing evaluation.
How to engage stakeholders in 8 steps
Use these steps for a project, service change or business initiative. Start with a small, clear plan and add detail where the impact or complexity calls for it.
Worked example: introducing a staff booking system
In this fictional example, an organisation is replacing a spreadsheet used to book shared equipment. The team needs a process that staff can use during busy shifts. Throughout the guide, follow how the project manager involves users, supervisors, IT support and the sponsor.
1. Define the decision and purpose
Start with the question you need stakeholders to help answer. Write down the decision, when it must be made and who has authority to make it. Then separate what is open to change from what has already been agreed.
Replace a vague aim such as “get staff on board” with a useful objective: “Understand how staff book equipment on each shift so we can agree the booking process before configuration begins.”
- What do you need to learn? For example, exceptions that the current spreadsheet does not capture.
- What can people influence? For example, the booking steps, reminders and training times.
- What are the limits? For example, the approved budget or a fixed contract end date.
- What will you give back? For example, a decision summary showing which suggestions were accepted and why.
Example: The sponsor has agreed to replace the spreadsheet, but the workflow is still open. Tell staff this before asking for input. If the team discovers that a fixed assumption makes the process unworkable, take the evidence back to the sponsor.
What you should have: a short purpose statement, clear boundaries and a decision date.
2. Understand the people affected
Use your existing stakeholder analysis as a starting point. Check it through conversations with the people involved. A job title alone will not tell you what someone needs, fears or knows.
Ask how the change affects their work, what a good result would look like and how they would prefer to take part. Record specific concerns alongside your assumptions, and mark anything you still need to confirm.
- Who will use, deliver, support, approve or experience the change?
- Who gains something, and who takes on extra work or disruption?
- Whose experience is missing from the current discussion?
- Could timing, language, accessibility or lack of internet access prevent someone taking part?
- Who else should you speak to, beyond the people already on your list?
Example: The department manager supports the new system. Night staff worry that they will lose time logging in, while IT support needs a clear process for account problems. Those are different needs, so one briefing will not answer them all.
The IFC stakeholder engagement handbook considers the extent of project impacts and whether vulnerable groups need particular efforts to involve them. Apply that principle when checking who your usual meetings leave out.
For the detailed mapping process, use our stakeholder analysis guide and stakeholder analysis questions.
What you should have: an updated list of stakeholder needs, concerns and practical arrangements for involving them.
3. Use your stakeholder analysis to choose an approach
Start with the four groups in your stakeholder analysis: manage closely, keep satisfied, keep informed and monitor. These groups describe combinations of influence and interest. The engagement model above connects those combinations to ways of involving people.
From stakeholder group to engagement approach
| Group from stakeholder analysis | Influence and interest | Starting approach in the model |
|---|---|---|
| Manage closely | High influence, high interest | Partnership |
| Keep satisfied | High influence, low interest | Participation |
| Keep informed | Low influence, high interest | Consultation |
| Monitor | Low influence, low interest | Push and pull communications |
The analysis page explains how to assess and group your stakeholders. Here, use that result to choose their role in the work. For example, “keep satisfied” can mean inviting a senior specialist to participate at the decisions where their expertise is needed, supported by concise updates between those points.
How to read the pyramid
At the bottom, pull and push communications let you reach more people with less individual effort. Moving upwards through consultation, participation and partnership means investing more time in discussion, shared work and decisions with fewer stakeholders. Use this to plan your time and resources.
The higher approaches can include the lower ones. A project partner still needs updates, and someone receiving updates may also need consultation on a particular issue. Choose a combination that fits the decision.
Use the group as a starting point. Check the level of involvement against people's needs, the effect on them and the authority you can share. Your analysis guide also asks you to consider impact. Someone with little organisational influence may need closer involvement because their experience is essential to the solution.
Apply the model to the booking system
Suppose your analysis identifies the service owner as high influence and high interest. Agree how they will work in partnership with the project team on service decisions. A senior technical specialist with high influence but little day-to-day interest could participate in a focused design review.
Consult regular users with high interest and lower influence about booking problems. Invite a smaller group to participate in testing because you need their practical experience. Staff who rarely use the equipment and have little influence may only need a launch notice and access to instructions. Review these choices if their needs change.
The five stakeholder engagement approaches
The table below explains what each approach involves. Use it to turn your chosen level of engagement into a clear role and activity.
| Approach | How stakeholders take part | What the project team should do | Booking system example |
|---|---|---|---|
| Partnership | Share responsibility for agreed decisions and outcomes. | Agree decision authority, resources and how to resolve disagreements. | Operations and IT jointly agree how to support the service, within the approved budget. |
| Participation | Help design, deliver or test the solution. | Explain their responsibilities and which decisions they can make. | Staff from different shifts test the booking process and help develop training. The project lead approves the release. |
| Consultation | Give views, experience and evidence before a decision. | Consider their input and explain the decision, including why some suggestions were not adopted. | Users describe failed bookings to help the team choose a better workflow. |
| Push communications | Receive information sent directly to them. | Make the message clear, highlight required actions and provide a contact for questions. | Staff receive an email with the launch date, actions to take and support contact. |
| Pull communications | Find information when they need it. | Make information easy to find and keep it up to date. | Staff look up booking instructions and frequently asked questions on the intranet. |
Push and pull communications support engagement, but sending information does not show that people understood it or had a chance to influence the work. Combine approaches when you need both informed users and their practical input.
Example: Consult staff about current problems, involve representatives in testing, then publish instructions and send launch reminders. You do not have to put every stakeholder through every activity.
Once you have chosen the approach, browse 60 practical stakeholder engagement ideas for activities to use. For help with the core techniques, see five key ways to engage stakeholders.
What you should have: an agreed role for each group and a clear explanation of what their involvement can change.
4. Turn your approach into an action plan
Turn “consult users” into an activity someone can organise. Name the relationship owner, the people involved, the timing and the result you need. Check that the owner has time and authority to follow up.
Schedule engagement before the relevant decision. If workflow approval is in Week 4, interviews in Week 5 will arrive too late.
| Stakeholders and objective | Activity and timing | Owner | Evidence and follow-up |
|---|---|---|---|
| Staff on each shift: understand booking difficulties | Short interviews and a walkthrough of current bookings in Week 1. | Business analyst | Check the findings with participants in Week 2, including any differences between shifts. |
| User representatives: test the proposed workflow | Try a prototype using normal and unusual bookings in Week 3. | Test lead | Log problems, assign fixes and repeat failed tasks before approval in Week 4. |
| IT support: agree how users get help | Review account problems and support ownership in Week 3. | Service owner | Agree the support route and test it before launch. |
| Sponsor: decide whether the service is ready | Review test evidence and unresolved issues in Week 4. | Project manager | Record the decision, conditions and actions; explain the result to affected staff. |
Ask participants whether the arrangements are workable. Offer sessions across shifts and another way to contribute for people who cannot attend. Keep confidential contact details and sensitive comments out of widely shared versions of the plan.
What you should have: a schedule of named actions tied to project decisions. See the plan contents below to bring it together.
5. Run a useful conversation
Send a short explanation of the purpose, the questions and any options in advance. Say how much time you need and when participants will hear back. Use language and examples that fit their experience.
For a first meeting, this simple 30-minute agenda can help:
- First 5 minutes: explain the purpose, what is open to change and who will decide.
- Next 15 minutes: ask people to describe their experience. Explore a real example and check what you have understood.
- Next 5 minutes: discuss possible changes, practical limits and any differences of opinion.
- Final 5 minutes: agree the actions, owners and date for a response.
Ask open questions such as “Where does this process cause extra work?” or “What would make this option difficult on your shift?” Follow an opinion with “Can you show me an example?” to find the underlying problem.
Example: A user says the new system will be slower. Ask them to walk through an urgent booking. You discover that shared equipment sometimes changes hands without access to a desk. That gives the team a specific scenario to test.
Make room for quieter participants. Ask for individual notes before group discussion, or offer a separate conversation where people may hesitate to speak openly. Check that a representative's account reflects the wider group's experience.
End by reading back the main points. Record agreement and disagreement separately, and do not promise a change you cannot approve. For a briefing or demonstration, use our tips on presenting to stakeholders.
What you should have: checked notes, specific concerns and agreed next actions.
6. Act on feedback and explain decisions
Give each issue an owner and a response date. Decide whether it needs an answer, further investigation, a project change or a decision from someone with more authority.
Keep a short record of what was raised, the decision, the reason and who was told. Link changes affecting scope, cost or timing to your project's change process.
Example: show what happened to a suggestion
You told us: urgent bookings need to be made away from a desk.
We changed: the prototype now includes a mobile booking route, which staff will test on both shifts.
We could not agree yet: an offline option needs a technical check because two people could book the same item.
Next response: the service owner will report the findings at the Week 4 review and send an update to everyone who raised the issue.
The IFC handbook's section on reporting to stakeholders explains why people need to know what happened to their suggestions and concerns. Report back even when the answer is that a proposal cannot be adopted.
Ask whether the response addresses the concern. If it does not, record what remains unresolved and the next route for review. A closed action in your spreadsheet does not automatically mean the stakeholder's problem is solved.
What you should have: a decision and action record, plus responses sent to the people who contributed.
7. Check whether engagement is working
Review the result against the purpose you set in Step 1. Choose a few checks that tell you whether people were included, understood the change and could influence the relevant decisions.
| Question | Evidence to look for | Action if there is a gap |
|---|---|---|
| Did we hear from each affected shift? | Who contributed, which roles they covered and whose experience is still missing. | Arrange a separate session or another way to contribute. |
| Can users carry out the booking tasks? | Observed prototype tests, including urgent bookings and corrections. | Investigate whether the problem is the design, instructions or access. |
| Did feedback affect the decision? | A record of suggestions, decisions and reasons. | Take unresolved findings to the decision owner before approval. |
| Did we keep our promises? | Actions completed by the agreed date and responses confirmed with stakeholders. | Assign overdue work, explain delays and agree new response dates. |
Attendance and email opens can help you check reach. Pair them with evidence of understanding, useful input and follow-through. Silence may mean people are busy, uncertain or unable to respond.
Example: A well-attended demonstration still leaves night staff unable to complete an urgent booking. Repeat the task with them and fix the cause before treating training as complete.
What you should have: a short review of what worked, what is missing and what you will change.
8. Keep people involved as the project changes
Review the stakeholder list and plan at major decisions, when the scope changes and when new concerns appear. Change the frequency and type of contact to match the work ahead.
Example: Before launch, users need practice and clear instructions. During the first weeks of use, they need quick answers and a way to report problems. Once the service settles, the service owner can use regular feedback to decide improvements.
At handover, transfer open commitments, the contact route and responsibility for future updates. Tell stakeholders who will respond once the project team has moved on. If the project closes or is cancelled, explain what this means for outstanding promises.
What you should have: a current plan and a named person responsible for the relationship after handover.
What to include in your stakeholder engagement plan
Your plan brings the decisions from these steps into one place. For a small project, a short introduction and an action table may be enough. Use the following headings where you need a fuller document.
Purpose of the document
State what the engagement should achieve, which decisions it supports and how you will judge whether it worked. Include the boundaries of stakeholder involvement.
Project background
Explain the change, why it is needed, who is affected and the key dates. Include budget or delivery limits where they affect what stakeholders can influence.
Introduction and scope
Explain how you identified stakeholders, what consultation has already happened and which groups or issues the plan covers. Record assumptions and gaps you still need to check.
Stakeholder analysis and engagement actions
Summarise each group's needs, concerns, influence and exposure to the change. Add the chosen approach, activity, owner, timing and expected result. You can use the worked action table as a starting point.
Stakeholder communication plan
Record what each group needs to know, who will communicate, which channels to use and when. Add the route for questions and how you will report decisions back. The communication plan supports the wider engagement work.
Stakeholder list
Keep the people, groups, representatives and contact preferences you need to deliver the plan. Store sensitive details separately where appropriate and record who will keep the list current.
Review, unresolved issues and approval
Set review dates, success measures and a route for decisions beyond the team's authority. Agree resources and responsibilities with the sponsor and delivery owners. Obtain client or board approval where your project governance requires it.
Build your own engagement plan
Use the example above to draft your actions, or explore the stakeholder management ebook and accompanying templates.
View the ebook and templatesHow to handle common engagement problems
A stakeholder does not respond
Check whether your request is clear, relevant and arriving through a channel they use. Ask for one specific contribution by a realistic date. If their decision is essential, explain the impact of a delay and ask the agreed decision owner to help.
A stakeholder opposes the project
Ask what would become worse for them and what evidence supports their concern. Separate a practical problem you can address from a decision outside your authority. Record unresolved objections fairly and explain who will consider them.
Two groups want different outcomes
Write down each group's needs and compare options against agreed criteria, such as usability, cost and service availability. Show the trade-offs to the decision owner. Explain the decision to both groups, including any action to reduce its disadvantages.
The same people dominate every discussion
Ask for individual input before opening the discussion. Invite contributions from missing roles, locations or shifts. Offer a private route where people may feel uncomfortable disagreeing in public.
People are tired of meetings and surveys
Check what you already know before asking again. Combine requests, shorten sessions and show what changed following earlier input. Contact people when you have a useful question or update.
Your next steps
Choose one upcoming project decision. Identify the people affected, write down what they can influence and arrange a conversation before the decision is fixed. Leave that conversation with an action owner and a date for reporting back.
Before sending the invitation, check:
- Can you explain the purpose in one sentence?
- Have you included the people who will experience the change?
- Is there still time for their input to affect the decision?
- Can they take part using the arrangements you have offered?
- Does someone have responsibility for responding to what they raise?
Templates and related guides
- 60 ways to engage stakeholders: choose activities for your agreed approach.
- Five key ways to engage stakeholders: explore the core engagement techniques.
- Presenting to stakeholders: prepare a clear briefing or demonstration.
- Stakeholder planning: use your analysis to decide priorities.
- Stakeholder management templates: resources to help record your analysis and plan.
- HS2 and St Mary's Field Museum: explore a community engagement example.
- Stakeholder management case studies: examine what happened on other projects.
- Stakeholder identification questions and 105 typical stakeholders: check for missing people and groups.
Sources and further reading
The eight-step walkthrough, booking system scenario and example tables are practical guidance developed for this article. The sources below provide further guidance on engagement principles, inclusion and follow-through.
- Association for Project Management: 10 key principles of stakeholder engagement. Guidance on understanding people, early consultation, relationships and responsibility.
- AccountAbility: AA1000 Stakeholder Engagement Standard. Overview of identification, planning, engagement, integration into decisions and evaluation.
- International Finance Corporation: Stakeholder Engagement, a Good Practice Handbook (2007, PDF). See stakeholder identification and analysis, printed pages 13 to 25; reporting to stakeholders, pages 87 to 98; and sample plan contents, pages 164 to 168.
Sources checked 14 September 2026.