.svg){kind=small}
Stakeholder analysis is the structured process of identifying the people and groups connected to a change, understanding their interests, influence, needs and concerns, and deciding how they should be involved. For a Business Analyst, it is a foundation for effective requirements work because the quality of the analysis depends heavily on whose perspectives have been included.
A stakeholder is not simply a senior manager who approves a project. Customers, end users, operational staff, subject-matter experts, regulators, suppliers, testers, support teams and many others can all provide requirements, assumptions, constraints or important evidence.
What is a stakeholder?
The International Institute of Business Analysis describes a stakeholder broadly as an individual or group with whom a Business Analyst may interact directly or indirectly. Its business analysis guidance recognises stakeholder roles such as customers, end users, subject-matter experts, implementation specialists, operational support, project managers, regulators, sponsors, suppliers and testers.
The exact stakeholders depend on the initiative. A new HR system and a customer-facing payment service will have very different stakeholder landscapes.
Why is stakeholder analysis important?
Business change rarely affects everyone in the same way. One group may gain efficiency while another takes on additional work. A sponsor may prioritise cost reduction while end users prioritise usability. A compliance team may impose constraints that no operational user would think to mention.
Stakeholder analysis helps a Business Analyst avoid several common problems:
- missing important requirements
- hearing only the most senior or vocal perspective
- discovering opposition late
- failing to involve decision-makers at the right time
- overlooking people who will operate or support the solution
- treating conflicting needs as though they were the same
- using the same engagement approach for every stakeholder
Stakeholder identification comes first
You cannot analyse stakeholders you have not identified.
A useful starting question is: Who is affected by, has knowledge of, can influence, can constrain or has responsibility for this change?
Sources for identifying stakeholders include:
- organisation charts
- process models
- project documents
- system ownership records
- contracts and supplier information
- regulatory responsibilities
- previous project lessons
- interviews with sponsors and subject-matter experts
- workshops
- customer journey maps
Process modelling can be particularly helpful because every activity, hand-off, decision and external interaction can reveal another stakeholder group.
See What Is BPMN? for more on process modelling.
Internal vs external stakeholders
Internal stakeholders are part of the organisation, such as employees, managers, Finance, HR, IT, Operations and senior leadership.
External stakeholders may include customers, suppliers, partners, regulators, auditors, contractors, accreditation bodies and other organisations.
External stakeholders can be easy to overlook because the project team has less direct access to them. Their requirements may nevertheless be critical.
Primary vs secondary stakeholders
Some organisations distinguish between stakeholders who are directly affected by a change and those who have a more indirect relationship.
A new call-centre system, for example, directly affects advisers and supervisors. Finance, Information Security and external auditors may be affected more indirectly but can still impose important requirements.
The labels are less important than understanding the nature of each relationship.
What should a Business Analyst learn about each stakeholder?
Useful areas include:
- Role: What is the stakeholder's relationship to the business need or solution?
- Knowledge: What information or expertise can they contribute?
- Needs: What outcomes or capabilities matter to them?
- Impact: How will the proposed change affect them?
- Influence: How much ability do they have to affect decisions or outcomes?
- Authority: What can they approve or reject?
- Interest: How closely are they likely to follow the initiative?
- Attitude: Are they supportive, neutral, uncertain or resistant?
- Availability: How easy is it to involve them when needed?
- Communication needs: Which methods and level of detail are appropriate?
This information should be used thoughtfully. Stakeholder analysis is not about labelling people permanently. Influence, interest and attitude can change as an initiative develops.
What is a power-interest grid?
A power-interest grid is a simple technique that groups stakeholders according to two dimensions:
- their level of power or influence
- their level of interest in the change
This creates four broad groups.
High power, high interest
These stakeholders usually need close engagement because they both care about the initiative and can significantly influence it.
High power, lower interest
These stakeholders may need concise, well-timed engagement so they remain appropriately informed without unnecessary detail.
Lower power, high interest
These stakeholders may be deeply affected by the change even if they lack formal authority. End users often fall into this category and can provide essential operational knowledge.
Lower power, lower interest
These stakeholders may require lighter-touch communication, though their position can change as the project progresses.
The grid is a planning aid, not a reason to ignore people in a particular quadrant.
What is a stakeholder map?
A stakeholder map is a visual representation of stakeholders and their relationship to the initiative, organisation or one another.
Maps can show:
- formal reporting relationships
- influence networks
- communication routes
- support or resistance
- internal and external groups
- decision-making relationships
A map can reveal that the person with formal authority is not necessarily the person who has the greatest day-to-day influence on user behaviour.
Stakeholder analysis vs stakeholder engagement
The two are related but different.
Stakeholder analysis helps you understand who the stakeholders are and what matters about their relationship to the change.
Stakeholder engagement is the ongoing work of involving, communicating and collaborating with those stakeholders.
Analysis should inform engagement. A senior sponsor, a frontline user, a regulator and an external supplier should not automatically receive the same communication or be involved in the same way.
Stakeholder analysis and requirements gathering
Stakeholder analysis is closely connected to requirements elicitation. Before scheduling interviews and workshops, the Business Analyst needs to know whose knowledge is needed.
For example, when replacing an order-processing system:
- Sales may explain how orders are entered.
- Operations may explain fulfilment and exceptions.
- Finance may define credit and invoicing rules.
- Customers may explain pain points in the ordering experience.
- IT may identify integration constraints.
- Information Security may define security requirements.
- Legal may identify contractual or regulatory obligations.
- Support teams may explain recurring issues in the current system.
No single stakeholder can provide a complete view.
For more on elicitation techniques, see What Is Requirements Gathering?.
A practical stakeholder analysis example
Imagine a housing association plans to introduce a new online repairs service.
Potential stakeholders could include:
- tenants
- contact-centre advisers
- repairs planners
- maintenance contractors
- housing officers
- Finance
- IT
- data protection and security specialists
- accessibility specialists
- senior sponsors
Tenants need a simple way to report and track repairs. Advisers need accurate information when tenants call. Contractors need sufficient job details. Finance needs cost control. IT needs maintainability and integration. Accessibility specialists need the service to work for people with different access needs.
The Business Analyst's job is not to choose one group's needs and ignore the others. It is to understand the perspectives, identify conflicts and help the organisation make informed decisions.
How do you identify stakeholder needs?
Different stakeholders require different elicitation techniques.
You might use:
- individual interviews for sensitive or detailed topics
- workshops when groups need shared understanding
- observation for operational users
- surveys for large populations
- document analysis for regulators and compliance requirements
- prototypes when users need something concrete to react to
- process models when several teams contribute to one workflow
The chosen technique should reflect both the stakeholder and the information needed.
How should conflicting stakeholder requirements be handled?
Conflicts are normal. They should be analysed rather than hidden.
A useful approach is:
- Clarify each stakeholder's underlying need.
- Check whether the requirements really conflict or merely use different language.
- Connect each need to business objectives and constraints.
- Identify the consequences of each option.
- Explore alternatives or compromises.
- Use agreed decision-making authority where trade-offs remain.
- Record the decision and rationale.
The Business Analyst facilitates understanding and evidence. They should not quietly make major business trade-offs without the appropriate authority.
Power is not the same as importance
A stakeholder can have little formal power while still being essential to successful analysis.
Frontline users may know where a process actually fails. Customers may expose needs that internal managers cannot see. Support teams may understand recurring problems better than system owners.
A Business Analyst who speaks only to senior stakeholders risks designing an elegant solution that does not work operationally.
What about resistant stakeholders?
Resistance should be investigated rather than dismissed.
A stakeholder may resist because:
- the change creates additional work
- they fear loss of control or status
- previous projects have failed
- they do not understand the reason for change
- they have identified a genuine risk that others have missed
- they believe their requirements have been ignored
Understanding the reason for resistance can improve both the solution and the change approach.
When should stakeholder analysis be updated?
Stakeholder analysis should be revisited throughout an initiative.
New stakeholders may emerge as scope changes. A technical team may become more influential during design. Operational teams may become more important approaching implementation. A previously supportive stakeholder may become concerned when the practical impact becomes clearer.
Treating stakeholder analysis as a one-time document created at project initiation misses this changing context.
Stakeholder analysis in Agile environments
Agile delivery does not remove stakeholder analysis. Frequent feedback makes effective stakeholder involvement even more important.
Product Owners, users, subject-matter experts and other stakeholders may contribute to backlog refinement, Sprint Reviews, product discovery and acceptance decisions.
The Business Analyst still needs to consider whether the team is hearing a representative range of perspectives rather than only the people who are easiest to contact.
Common stakeholder analysis mistakes
- Identifying only senior stakeholders. Operational and external perspectives are missed.
- Assuming the sponsor speaks for every user. Strategic and operational needs may differ.
- Creating a stakeholder list but doing no analysis. Names alone do not explain influence, needs or impact.
- Treating classifications as permanent. Stakeholder positions change.
- Using power as the only measure of importance. People with critical knowledge may have little authority.
- Ignoring resistant stakeholders. Valuable risk information may be lost.
- Failing to protect sensitive analysis. Assessments of attitude and influence should be handled professionally.
- Overcomplicating the technique. The purpose is better engagement, not a perfect diagram.
Stakeholder register vs stakeholder map
A stakeholder register is usually a structured list containing information about identified stakeholders. A map presents selected relationships visually.
They can complement each other. A register might record role, interest, influence and contact arrangements, while a map makes relationships and clusters easier to see.
Stakeholder analysis vs RACI
A RACI matrix and stakeholder analysis solve different problems.
Stakeholder analysis examines people's relationship to a change.
RACI is typically used to clarify responsibility for activities by identifying who is Responsible, Accountable, Consulted and Informed.
A stakeholder may appear in both, but one technique does not replace the other.
What skills does a Business Analyst need for stakeholder work?
Useful skills include:
- active listening
- questioning
- facilitation
- empathy
- negotiation
- conflict resolution
- critical thinking
- clear written communication
- presentation skills
- commercial and organisational awareness
Stakeholder analysis provides structure, but the quality of the interaction depends heavily on interpersonal skill.
Frequently asked questions
Who counts as a stakeholder?
Anyone with a relevant relationship to the need, change or solution can be a stakeholder. This can include people who influence it, use it, support it, fund it, regulate it or are affected by it.
Is a customer always a stakeholder?
Customers are stakeholders when the initiative affects the product or service they use or their interests are otherwise relevant.
Is stakeholder analysis only for Project Managers?
No. Project Managers use stakeholder analysis for project engagement and governance, while Business Analysts use it heavily to plan elicitation, understand needs, analyse impacts and support requirements work.
What is the best stakeholder analysis technique?
There is no single best technique. Power-interest grids are simple and useful, but stakeholder maps, registers, onion diagrams and other approaches may be better depending on the question being explored.
Should stakeholder analysis be shared with everyone?
Not necessarily. Some analysis can contain sensitive judgements about influence, attitude or relationships. Organisations should handle this material carefully and separate useful engagement information from subjective commentary that could damage trust.
Develop your Business Analysis skills with ExperTrain
Stakeholder analysis, elicitation and collaboration are central parts of effective Business Analysis. ExperTrain offers instructor-led Business Analysis training covering requirements, processes, stakeholder work and professional analysis techniques.
The EXIN BCS Foundation Certificate in Business Analysis provides a structured introduction to the discipline, while Business Analysis: Requirements Development, Documentation and Management develops requirements and elicitation skills in greater depth.
You can also use our Business Analysis Glossary or read Business Analyst vs Project Manager and Functional vs Non-Functional Requirements.
Further reading
Found this article useful? Add ExperTrain as a Preferred Source on Google to help surface more of our training guides, articles and learning resources.
.png){kind=small}
