Projects rarely succeed through technology, processes or requirements alone.
They succeed because the right people are identified, engaged and involved in making the right decisions at the right time.
Yet stakeholder management is often treated as a simple administrative exercise: create a stakeholder list, schedule some meetings and send regular updates.
Effective Business Analysis goes much further.
A Business Analyst needs to understand who the stakeholders are, what they need, how they are affected, how much influence they have, and how they should be engaged throughout the initiative.
This is the foundation of effective stakeholder analysis.
What Is a Project Stakeholder?
A stakeholder is any individual, group or organisation that can influence an initiative, be affected by it, or have an interest in its outcome.
Some stakeholders are obvious:
- Project Sponsor
- Business Owner
- Project Manager
- Product Owner
- Business Analyst
- Subject Matter Experts
- Technology Teams
- End Users
Others are less obvious:
- Finance
- Legal
- Cybersecurity
- Privacy
- Risk and Compliance
- Procurement
- Data and Analytics
- External vendors
- Customers
- Regulators
- Support teams
One of the first responsibilities of a Business Analyst during discovery is therefore to determine:
Who needs to be involved for us to properly understand the problem and define the right solution?
Missing an important stakeholder early can result in missing requirements, late design changes, rework and implementation problems.
1. Start With the Business Problem
Stakeholder identification should begin with the business problem or initiative, not with an organisational chart.
Ask:
What are we trying to change?
Then consider who:
- Owns the problem
- Experiences the problem
- Performs the affected processes
- Makes decisions about the process
- Uses the existing system
- Will use the future solution
- Provides or consumes information
- Owns related systems
- Controls funding
- Manages risk
- Will support the solution after implementation
This creates a much broader and more useful stakeholder view.
For example, imagine an organisation wants to replace its customer management system.
The obvious stakeholders may be Sales and IT.
But further analysis could identify:
Sales → Customer Service → Marketing → Finance → Data → Cybersecurity → Legal → Technology → Executives → Customers
Each group may have completely different needs.
2. Identify Stakeholders Across the Business
A useful technique is to consider stakeholders from several perspectives.
Strategic Stakeholders
These stakeholders are concerned with organisational outcomes and investment.
Examples include:
- Executive Sponsor
- Steering Committee
- Business Owner
- Senior Leadership
They typically care about:
Benefits | Cost | Risk | Strategy | Business Outcomes
Operational Stakeholders
These are the people performing or managing the affected business processes.
Examples include:
- Team Leaders
- Operational Managers
- Frontline Employees
- Subject Matter Experts
They often understand the real-world problems better than anyone else.
They care about:
Processes | Efficiency | Workload | Usability | Business Rules
Technology Stakeholders
Technology teams determine how the proposed change interacts with the organisation’s technical environment.
Examples include:
- Solution Architects
- Developers
- Integration Teams
- Cybersecurity
- Infrastructure
- Data Teams
- Application Support
They care about:
Architecture | Integration | Security | Data | Performance | Supportability
Governance Stakeholders
These stakeholders help ensure the initiative complies with organisational and regulatory requirements.
Examples include:
- Risk
- Legal
- Privacy
- Compliance
- Procurement
- Finance
- Records Management
They may not use the solution, but their requirements can significantly influence its design.
External Stakeholders
Some initiatives also involve people outside the organisation.
Examples include:
- Customers
- Students
- Patients
- Suppliers
- Partners
- Government agencies
- Regulators
- Technology vendors
Their needs should not be overlooked simply because they do not appear on the internal organisation chart.
3. Create a Stakeholder Register
Once stakeholders have been identified, document them.
A simple Stakeholder Register might contain:
| Stakeholder | Role | Interest | Influence | Impact | Engagement |
|---|---|---|---|---|---|
| Executive Sponsor | Funding & direction | High | High | Medium | Manage closely |
| Operations Manager | Process owner | High | High | High | Manage closely |
| End Users | System users | High | Medium | High | Consult regularly |
| Cybersecurity | Security assurance | Medium | High | Medium | Engage at key stages |
| Vendor | Solution provider | High | Medium | Medium | Collaborate |
The objective is not to create documentation for its own sake.
The register should help the BA determine:
Who needs to be involved, when, why and how?
4. Analyse Stakeholder Influence and Interest
Not every stakeholder requires the same level of engagement.
One widely used approach is an Influence–Interest Matrix.
Stakeholders are considered according to:
Influence — How much ability do they have to affect the initiative?
Interest — How closely are they interested in or affected by the initiative?
This creates four broad groups.
High Influence + High Interest
Manage Closely
These stakeholders should be actively involved.
Examples might include:
- Project Sponsor
- Business Owner
- Key Process Owners
High Influence + Lower Interest
Keep Satisfied
They may not need daily involvement but can significantly influence the project.
Examples might include:
- Executives
- Governance functions
- Senior Technology Leaders
Lower Influence + High Interest
Keep Informed and Consulted
These stakeholders may be heavily affected even though they have limited formal decision-making authority.
End users frequently fall into this category.
Their input can be critical to understanding operational requirements.
Lower Influence + Lower Interest
Monitor
These stakeholders require appropriate communication but generally less intensive engagement.
The classification should never be treated as permanent. Stakeholder influence and interest can change throughout an initiative.
5. Analyse Stakeholder Impact
Influence and interest are not enough.
A stakeholder may have limited organisational authority but be significantly affected by the proposed change.
For example, frontline employees may have relatively low formal influence but could experience major changes to their daily work.
A Business Analyst should therefore also ask:
- How will this stakeholder be affected?
- Will their process change?
- Will their responsibilities change?
- Will they use a new system?
- Will they need training?
- Are they likely to support the change?
- What concerns might they have?
This provides an important link between Business Analysis and Change Management.
6. Understand Each Stakeholder’s Perspective
Different stakeholders often describe the same problem differently.
Imagine an organisation has a slow approval process.
Executive:
“We need to reduce operating costs.”
Operations Manager:
“We have too many approval steps.”
Employee:
“I don’t know who needs to approve my request.”
Finance:
“We need stronger financial controls.”
Technology:
“The current workflow system is difficult to modify.”
Every statement may be correct.
The BA’s responsibility is to bring these perspectives together and develop a complete understanding of the problem.
This is why stakeholder analysis is not simply about creating a list of names.
It is about understanding perspectives, needs, priorities and constraints.
7. Determine How to Engage Each Stakeholder
Once stakeholders have been analysed, determine the most appropriate engagement method.
Different situations require different techniques.
Interviews
Useful for detailed conversations with executives, SMEs and process owners.
Workshops
Useful when multiple stakeholders need to explore problems, processes or requirements collaboratively.
Surveys
Useful when feedback is required from a large population.
Observation
Useful for understanding how operational processes actually work.
Document Analysis
Useful for understanding existing policies, procedures, systems and business rules.
Prototypes and Process Models
Useful when stakeholders find it easier to respond to something visual than to written requirements.
Strong Business Analysts adapt their elicitation approach to the stakeholder rather than expecting every stakeholder to communicate in the same way.
8. Identify Stakeholder Conflicts Early
Stakeholders will not always agree.
This is normal.
Finance may prioritise cost reduction.
Operations may prioritise efficiency.
Technology may prioritise maintainability.
Cybersecurity may prioritise controls.
Customers may prioritise simplicity.
The role of the BA is not necessarily to make everyone agree.
Instead, the BA should make the differences visible and structured.
For example:
Stakeholder Need → Business Value → Priority → Constraint → Impact → Decision
This allows decision-makers to make informed trade-offs rather than discovering conflicts during development or testing.
9. Connect Stakeholders to Requirements
Stakeholder analysis should directly support requirements management.
For every important requirement, the BA should understand:
Who needs this requirement and why?
This provides traceability.
For example:
Stakeholder: Finance Manager
↓
Business Need: Improve expenditure control
↓
Requirement: Purchases above an agreed threshold require additional approval
↓
Business Rule: Approval authority varies according to purchase value
↓
Acceptance Criteria: Requests above the threshold cannot proceed without the appropriate approval.
This makes requirements easier to validate and manage.
10. Keep Stakeholder Analysis Current
Stakeholder analysis is not something completed once at the beginning of a project and then forgotten.
Projects change.
New stakeholders appear. Responsibilities change. Vendors become involved. Governance requirements emerge. People leave the organisation.
The stakeholder register should therefore be reviewed throughout the initiative.
A useful BA habit is to periodically ask:
“Who are we not talking to that we should be?”
That simple question can uncover significant gaps.
Common Stakeholder Analysis Mistakes
Several mistakes appear repeatedly in projects.
Only engaging senior stakeholders
Executives understand strategic objectives but may not understand day-to-day operational problems.
Only engaging end users
Users understand operational needs but may not understand broader strategic or regulatory requirements.
Assuming one representative speaks for everyone
Different teams performing similar functions can still have different processes and requirements.
Engaging governance teams too late
Security, privacy, legal or compliance requirements discovered late can create significant rework.
Treating stakeholder analysis as documentation
A stakeholder register is only valuable if it changes how the project engages people.
A Practical Stakeholder Analysis Approach
A simple framework is:
Identify → Analyse → Prioritise → Engage → Validate → Review
Identify
Who is affected or can influence the initiative?
Analyse
What are their needs, interests, influence and concerns?
Prioritise
Who requires the greatest level of engagement?
Engage
What is the best method for involving them?
Validate
Have their needs and requirements been correctly understood?
Review
Has anything changed as the initiative progresses?
This provides a repeatable approach that can be used across projects of different sizes and industries.
Stakeholders Are Central to Business Analysis
Business Analysis is ultimately about understanding organisations — and organisations are made up of people with different responsibilities, perspectives and priorities.
A technically excellent solution can still fail if the people affected by it were not properly understood or engaged.
Effective stakeholder analysis helps a Business Analyst move from:
Individual Opinions → Shared Understanding → Agreed Requirements → Better Decisions
The earlier the right stakeholders are identified and engaged, the stronger the foundation for discovery, requirements, solution design and successful delivery.