Stakeholder Analysis and Engagement: A Practical Guide for Business Analysts

Written by Jude Mahoney

Agile Delivery Lead | Business Analyst Mentor | 20 Years Experience

LinkedIn: Jude Mahoney

Stakeholder management is sometimes presented as one of the softer parts of Business Analysis. Identify the stakeholders, put their names on a Power/Interest grid, decide who needs to be “kept satisfied” and move on to the serious analytical work.

In reality, stakeholder analysis can determine whether the serious analytical work is any good in the first place.

Requirements come from people. Business rules are understood by people. Processes are performed by people. Decisions are made by people. Organisational politics, conflicting priorities, operational knowledge and resistance to change all sit somewhere within the stakeholder landscape.

Miss the right person and you can miss an entire set of requirements. Listen too heavily to the wrong person and you can design a solution around one stakeholder's view of the world. Fail to engage an influential stakeholder early enough and months of otherwise competent analysis can suddenly become very expensive.

Good stakeholder work is therefore much more than making a list of names. It is about understanding who matters, why they matter, what they know, what they need, how much influence they have, where conflicts might exist and how you should work with them throughout the change.

For a Business Analyst, a practical approach looks like this:

1. Understand the change → 2. Identify stakeholders → 3. Understand their relationship to the change → 4. Analyse influence and interest → 5. Understand needs and perspectives → 6. Identify conflicts and risks → 7. Plan engagement → 8. Engage appropriately → 9. Validate understanding → 10. Review as the change evolves

The tools can vary. The thinking behind them is what matters.

1. Understand the change before analysing the stakeholders

Stakeholder analysis needs context.

If you are told that a new customer-service platform is being introduced, immediately producing a stakeholder list is possible, but you will do a better job if you first understand why the change exists.

What problem is being solved? Which part of the organisation is affected? What processes might change? Is this a technology replacement, a broader transformation or both? Who benefits? Who might have to work differently? What decisions need to be made?

Suppose an organisation wants to introduce an online self-service capability because its contact centre is receiving 40,000 avoidable calls each month.

That immediately suggests several stakeholder perspectives. Customers use the service. Contact-centre employees understand why people call. Operations owns the process. Technology understands the existing systems. Customer Experience may own the digital journey. Security and Compliance may constrain what customers can do. Finance may be interested in the cost reduction. Senior leadership may be sponsoring the investment.

Understanding the purpose gives you a much better starting point for asking:

Who needs to be involved for us to understand and deliver this change properly?

2. Identify the stakeholders systematically

Stakeholder identification is easy when somebody hands you an organisation chart.

Unfortunately, organisation charts tell you who reports to whom. They do not necessarily tell you who understands the problem, influences the decision or will be affected by the change.

Start broadly.

Consider people and groups who:

• sponsor or fund the change;

• own the affected business area;

• perform the current process;

• use the product or service;

• manage people affected by the change;

• make important decisions;

• own relevant systems;

• provide or consume data;

• understand regulatory or legal obligations;

• support customers;

• will build or test the solution;

• will operate the solution after implementation;

• could significantly influence or block the change;

• are affected outside the immediate project team.

A simple stakeholder register can help:

Stakeholder	Role/Area	Why they matter	Initial involvement
Executive Sponsor	Leadership	Owns business case and funding	Decision-making
Product Owner	Product	Owns priorities and product direction	High
Contact Centre	Operations	Performs affected work	High
Customers	End users	Experience the problem/service	High
Technology	IT	Systems, feasibility and dependencies	High
Security	Risk	Authentication/data constraints	Medium/High
Compliance	Compliance	Regulatory requirements	Medium/High
Finance	Finance	Cost/benefit information	Medium

This is not the finished analysis. It is a starting point.

Look beyond job titles

One of the most valuable stakeholders on a process-improvement project may be the employee who has performed the process for twelve years and knows every workaround in existence.

They may have very little organisational power.

They may have enormous analytical value.

Conversely, a senior director may have considerable power but little understanding of how the process operates day to day.

Both matter, for different reasons.

That distinction is fundamental to good stakeholder analysis.

3. Understand what each stakeholder actually has at stake

Once you know who the stakeholders are, establish their relationship to the change.

Ask what they want, what they know, what they control and what might concern them.

For example, a project to automate part of an operational process might produce very different reactions.

The sponsor may want a 20% reduction in operating cost.

The Operations Manager may want faster processing but worry about service disruption.

Employees may worry that automation threatens their jobs.

Compliance may worry that controls will be removed.

Technology may be concerned about integration with a legacy system.

Customers may simply want the process to become quicker and easier.

Nobody necessarily has to be wrong.

They are viewing the same change through different interests.

For significant stakeholders, try to understand:

What do they need from the change? What do they know that we need? What decisions can they make? What might they gain? What might they lose? What concerns are they likely to have? How could they influence the outcome?

This moves stakeholder analysis away from names and towards behaviour.

4. Analyse power, influence and interest

The familiar Power/Interest grid is useful when used sensibly.

Stakeholders can broadly be considered according to how much influence they have over the change and how interested or affected they are.

A typical model is:

	Lower interest	Higher interest
Higher power	Keep satisfied	Manage closely
Lower power	Monitor	Keep informed

This can help you decide where engagement effort needs to be concentrated.

A senior sponsor with high power and high interest probably requires close engagement. A regulator may have enormous influence despite relatively little day-to-day involvement. An operational employee may have little formal power but very high interest because the new process changes their job completely.

But do not treat the grid as an unquestionable truth.

A stakeholder's influence can change.

An apparently low-power subject-matter expert may become critical when a technical problem emerges. A previously disengaged executive may suddenly become highly interested when cost increases. A group of employees with little individual power may collectively become capable of preventing successful adoption.

The grid is a thinking tool, not a permanent label.

5. Analyse knowledge as well as power

This is particularly important for Business Analysts.

If you only prioritise stakeholders according to organisational authority, you risk building your analysis around the people who can approve the change rather than the people who understand it.

Consider three stakeholders:

Director of Operations: high authority, broad understanding.

Team Manager: medium authority, strong understanding of performance and staffing.

Operations Assistant: low authority, exceptional understanding of the actual process and its workarounds.

If you only “manage closely” the director, your analysis may be politically efficient and operationally terrible.

For BA purposes, it can therefore be useful to consider another dimension:

How important is this person's knowledge to understanding the problem?

You might informally rate stakeholders across:

Influence | Interest | Knowledge | Impact

That often gives you a much richer picture than Power/Interest alone.

6. Find the people who are missing

Stakeholder analysis should include a deliberate attempt to find the people nobody initially mentioned.

Ask existing stakeholders:

“Who else should I speak to?”

Then ask:

“Who deals with this when something goes wrong?”

That second question can be particularly revealing.

The normal process may involve Operations and Finance. The exception process may involve Fraud, Customer Complaints and a specialist support team nobody remembered to invite to the original workshop.

Other useful questions include: Who provides the information you use? Who receives the output? Who approves unusual cases? Who understands the system? Who owns the policy? Who would be affected if we changed this? Who is likely to disagree with this proposal?

Stakeholder discovery is not necessarily complete because you held the kick-off meeting.

Keep looking.

7. Understand conflicts before they become surprises

Different stakeholders frequently want incompatible things.

That is normal.

Imagine you are working on a customer registration journey.

Marketing says:

“We want registration to be as quick as possible.”

Compliance says:

“We need additional identity checks.”

Data says:

“We want to capture more information about customers.”

Customers say:

“Why are you asking me all these questions?”

Technology says:

“The identity provider cannot return the result immediately.”

There is no workshop technique that makes those tensions disappear.

The BA needs to expose them clearly enough for sensible decisions to be made.

Start by distinguishing between positions and underlying needs.

Marketing's position may be:

“Remove the additional verification screen.”

Their underlying need may be:

“Reduce customer abandonment during registration.”

Compliance's position may be:

“Every customer must complete additional verification.”

Their underlying need may be:

“Meet the organisation's regulatory obligations and control identity risk.”

Those underlying needs create more room for analysis than the two original positions.

Perhaps verification can occur differently. Perhaps only certain customers require additional checks. Perhaps information can be reused. Perhaps the journey can be redesigned.

The BA's role is not necessarily to decide which stakeholder wins.

It is to make the conflict understandable and help the right people make an informed decision.

8. Plan engagement rather than communicating with everyone in the same way

Once you understand the stakeholders, decide how you need to work with them.

Not everybody needs to attend every workshop.

That sounds obvious, yet stakeholder engagement can quickly become a calendar-management exercise in which fifteen people are invited to every meeting “just in case”.

Think about the purpose of each interaction.

Need	Possible engagement
Detailed specialist knowledge	1:1 interview / working session
Shared understanding	Workshop
Resolve conflicting views	Facilitated workshop / decision session
Understand real work	Observation / shadowing
Validate requirements	Review / walkthrough
Senior decision	Concise decision paper / meeting
Keep wider group informed	Update / demonstration
User perspective	Research / interview / usability session
Technical feasibility	Technical discussion / Three Amigos

The method should fit the stakeholder and the purpose.

A busy executive may need a ten-minute decision conversation supported by a one-page summary.

A subject-matter expert may need two hours at a whiteboard.

A group of operational users may need a workshop where they can challenge each other's understanding of the process.

Good engagement is not about maximum communication.

It is about useful communication with the right people at the right time.

9. Prepare properly for stakeholder conversations

“Arrange meeting with stakeholder” is not an analysis technique.

Before an important interaction, know what you need from it.

If you are interviewing the Head of Operations, perhaps you need to understand business objectives, major constraints and success measures.

If you are sitting with an operational employee, perhaps you need to understand the real process, exceptions and workarounds.

If you are speaking to Technology, perhaps you need to understand integrations, existing system behaviour and technical constraints.

Go in with questions, but do not turn the conversation into an interrogation.

Listen to the answers and follow what you learn.

A stakeholder saying:

“That's how the process works, except at month-end.”

should immediately make a BA curious.

What happens at month-end? Why is it different? Who decided that? How often does it create problems?

The best stakeholder conversations rarely follow the question list perfectly.

The questions give you structure.

The stakeholder gives you the analysis.

10. Build trust by being useful

Stakeholder engagement is easier when people believe there is a point to speaking to you.

Employees can become understandably cynical about project teams asking them to explain the same process for the fourth time in two years.

Do your homework.

If documentation already exists, read it before asking someone to explain everything from scratch. If somebody gave you information previously, remember it. If you said you would investigate a question, come back with an answer.

Most importantly, show people what happened to their input.

If an Operations employee spends an hour explaining a broken process and never hears from the project again, don't be surprised if they are less enthusiastic next time.

You might return with a process map and say:

“This is what I understood from our conversation. Have I got it right?”

That does two things.

It validates your analysis and demonstrates that their time produced something tangible.

Trust is not created by a stakeholder-engagement plan.

It is created by how you behave.

11. Learn to challenge stakeholders properly

Stakeholder engagement does not mean stakeholder obedience.

Business Analysts need to challenge.

A senior stakeholder might say:

“The system needs an approval button here.”

Rather than writing a requirement for an approval button, ask:

“What decision is being made at that point?”

Perhaps you discover the approval exists because of a policy written ten years ago.

You can then ask whether the rule still applies, what risk the approval controls and whether every case needs the same treatment.

Good challenge is curious rather than combative.

Useful phrases include:

“Help me understand why that needs to happen.”

“What would happen if we didn't do that?”

“Is that true for every case?”

“What problem would that feature solve?”

“Who makes that decision today?”

“What evidence do we have?”

“Could you show me an example?”

You are not trying to prove the stakeholder wrong.

You are trying to make the requirement right.

12. Handle difficult stakeholders without turning them into villains

Sooner or later, you will encounter somebody described as a “difficult stakeholder”.

Sometimes they genuinely are difficult.

But it is worth understanding why.

A stakeholder may appear resistant because the change creates more work for their team. They may have been excluded from an earlier decision. They may believe the project is solving the wrong problem. They may have seen three previous transformations fail. They may be protecting a legitimate risk nobody else understands.

Or they may simply have different priorities.

Before deciding that somebody is obstructive, ask:

What does this situation look like from their side?

That does not mean accepting unacceptable behaviour or allowing one person to derail a project.

It means treating resistance as information.

If an Operations Manager repeatedly objects to a proposed process, perhaps they are protecting their empire.

Or perhaps the proposed process genuinely cannot cope with the volumes their team handles.

Find out.

13. Manage dominant voices in workshops

Workshops create their own stakeholder problems.

A senior person speaks first and everybody agrees.

One subject-matter expert talks for 40 minutes.

The quietest person in the room actually knows the process best.

Two departments begin arguing about something that happened six months ago.

The BA needs to facilitate the discussion rather than merely attend it.

Set a clear purpose. Ask specific people for their views. Use visual artefacts such as process maps, requirements or scenarios to give the discussion a focal point. Record disagreements rather than forcing artificial consensus.

If necessary, say:

“We've heard the Product view. I'd like to understand what this looks like from Operations.”

Or:

“It sounds as though we have two different interpretations here. Let's capture both and establish what evidence or decision we need to resolve them.”

That is much more useful than allowing the loudest voice to become the requirement.

14. Don't confuse the stakeholder with the requirement

A stakeholder asking for something does not automatically make it a valid requirement.

Suppose a manager says:

“I need a dashboard showing all 47 performance measures.”

You might discover that they only use six of those measures to make decisions.

The requirement may not be:

“Display 47 measures.”

The underlying need may be:

“Managers need timely visibility of the measures required to identify deteriorating service performance.”

That gives you something worth analysing.

This principle is central to requirements work: stakeholders provide knowledge, needs, constraints, opinions and proposed solutions.

The BA analyses them.

You are not a transcription service.

15. Validate what you think you heard

Misunderstandings are remarkably easy to create.

You leave a meeting believing the stakeholder said one thing.

The stakeholder believes they said something slightly different.

Three weeks later the difference becomes a defect.

Validation does not have to mean formal sign-off.

You can play back a process map, requirement, user story, prototype, decision log or written summary.

Ask:

“Is this an accurate representation of what we agreed?”

For complex or contentious areas, go further:

“What have I missed?”

“Which part of this concerns you?”

“What would make this wrong?”

Those questions are often more productive than:

“Are you happy with it?”

People say yes to the latter far too easily.

16. Keep track of decisions and disagreements

Stakeholder-heavy projects generate decisions.

If those decisions disappear into meeting notes and Teams chats, the same debates tend to return.

A simple decision log can be enormously useful:

Decision	Reason	Decision maker	Date	Impact
Manual review only for high-risk cases	Reduce processing delay while retaining control	Operations Director / Risk	12 June	TO-BE process and requirements
Customer email not required at stage 2	Existing account notification sufficient	Product Owner	16 June	Notification requirements

You may also maintain assumptions, issues and unresolved questions.

The objective is not bureaucracy.

It is organisational memory.

When somebody asks three months later:

“Why did we decide that?”

you should not have to search through 900 Slack messages.

17. Review the stakeholder landscape as the work changes

Stakeholder analysis is not something you complete during week one and file away.

New people appear.

The solution becomes clearer.

Risks emerge.

A system integration introduces another team.

A policy change brings Legal into the discussion.

A senior stakeholder leaves.

A group that previously had little interest becomes heavily affected by the proposed TO-BE process.

Revisit your analysis periodically and ask:

Who matters now? Who has become more or less influential? Whose knowledge do we need next? Who is affected by what we are proposing? Who have we still not heard from?

Your stakeholder strategy should evolve with the work.

---

A Structured Stakeholder Analysis and Engagement Method

If you want a repeatable BA approach, use this:

Stage	Key question	Typical activity	Output
1. Context	What change are we analysing?	Understand problem, scope and objectives	Change context
2. Identify	Who matters?	Stakeholder discovery	Stakeholder register
3. Understand	Why do they matter?	Role, impact and knowledge analysis	Stakeholder needs
4. Analyse	How influential/interested are they?	Power, interest, knowledge and impact analysis	Stakeholder assessment
5. Perspectives	What do they need or believe?	Interviews, research, workshops	Needs and viewpoints
6. Conflict	Where do interests differ?	Conflict/dependency analysis	Issues and decisions
7. Plan	How should we engage them?	Engagement planning	Engagement approach
8. Engage	What do we need from them now?	Workshops, interviews, reviews	Analysis and decisions
9. Validate	Have we understood correctly?	Playback and review	Validated understanding
10. Review	Has the stakeholder landscape changed?	Reassessment	Updated engagement

In shorthand:

CONTEXT → IDENTIFY → UNDERSTAND → ANALYSE → LISTEN → RESOLVE → ENGAGE → VALIDATE → REVIEW

That is a much more useful stakeholder method than simply filling four boxes on a Power/Interest grid.

---

A Worked Stakeholder Analysis Example

Imagine a retailer wants to replace its existing store returns process with a digital system.

The project initially identifies:

Sponsor → Product Owner → Store Operations → Technology

That looks reasonable.

Then the BA starts investigating.

Store employees explain that high-value returns require manager approval. Fraud owns the rules governing those approvals. Finance reconciles refund transactions. Customer Service handles complaints when refunds fail. The e-commerce team owns the customer account that may be used for digital receipts. Data Protection needs to review how customer information will be handled.

The stakeholder landscape becomes:

Sponsor → Product → Store Operations → Store Employees → Customers → Technology → Fraud → Finance → Customer Service → E-commerce → Data Protection

The BA then discovers competing perspectives.

Product wants a fast digital journey. Fraud wants stronger controls. Stores want fewer manual steps. Finance needs accurate reconciliation. Customers want immediate refunds. Technology knows the legacy payment system cannot always process them immediately.

That is the real stakeholder problem.

The BA now has to understand the needs, establish which constraints are genuine, expose conflicts and help the organisation make decisions.

A Power/Interest grid might help determine how these groups are engaged.

But the grid is not the analysis.

The analysis is understanding how their needs interact with the change.

---

A Practical Stakeholder Checklist for Business Analysts

Before considering your stakeholder work mature, ask:

• Do I understand why the change exists?

• Have I identified people affected by the change as well as people running it?

• Have I spoken to people who actually perform the current process?

• Have I considered customers or end users?

• Do I know who makes the important decisions?

• Do I know who owns relevant systems, data, policies and controls?

• Have I identified stakeholders with important knowledge but little formal authority?

• Do I understand what significant stakeholders want from the change?

• Do I understand what they might fear or lose?

• Have I identified conflicting needs?

• Have I distinguished stakeholder positions from underlying needs?

• Am I using the right engagement method for each purpose?

• Am I challenging proposed solutions where necessary?

• Have I validated my interpretation?

• Are important decisions being recorded?

• Have I reviewed the stakeholder landscape as the work has evolved?

If several answers are no, don't solve the problem by adding more names to a stakeholder spreadsheet.

Find out whose perspective you are missing.

Stakeholder Engagement Is Part of the Analysis

Stakeholder analysis is not administrative work surrounding Business Analysis.

It is Business Analysis.

A process map is only as accurate as the knowledge used to create it. Requirements are only as good as the needs and constraints you uncover. A TO-BE process is only useful if the people expected to operate it can actually make it work.

The Business Analyst sits in the middle of those different perspectives.

You will sometimes need to listen. Sometimes you will need to challenge. Sometimes you will need to bring people together. Sometimes you will need to tell an influential stakeholder that their requested feature does not appear to solve the problem. And sometimes you will discover that the supposedly awkward person in the room is the only one asking the question everybody else should have asked months ago.

Good stakeholder engagement is therefore not about keeping everybody happy.

It is about creating enough trust, understanding and constructive challenge for the organisation to make better decisions.

The Power/Interest grid can help.

The stakeholder register can help.

The RACI can help.

But none of those tools will build the relationship for you.

The real skill lies in knowing who to speak to, what to ask them, when to challenge them, when to listen and what to do when they disagree.

That is considerably harder to fit into four boxes.

And considerably more valuable.

Developing Your Stakeholder Analysis and Engagement Skills

You can learn how to draw a stakeholder matrix very quickly. Learning how to walk into a room containing an impatient sponsor, a defensive Operations Manager, a highly knowledgeable subject-matter expert and a Product Owner who has already decided what should be built is another matter.

That takes judgement and practice.

Elisto's Business Analyst training focuses on the practical application of BA techniques, including the situations where stakeholders disagree, requirements are unclear and the analyst needs to decide what question to ask next.

The Knowledge Hub can give you a structured method for stakeholder analysis and engagement.

The deeper capability comes from learning how to use that structure with real people — particularly when they don't conveniently behave like the stakeholders in a textbook.