Stakeholder Management & Communication
Topic 3 of 11 · In Business Analysis · September 9, 2026
Learn to identify, classify, engage, and communicate with stakeholders throughout the project lifecycle — the skill that separates good BAs from great ones.
Overview
Stakeholder management is the process of identifying everyone who is affected by a project, understanding their needs and influence, and engaging them in a way that keeps the project on track. A Business Analyst who can manage stakeholders effectively is worth ten times one who can only write requirements.
Why? Because requirements do not fail on their own — they fail because the wrong people were not consulted, expectations were not managed, or conflicts between stakeholders were not resolved. This topic teaches you the soft skills that make or break your BA career: how to map stakeholders, build communication plans, manage expectations, resolve conflicts, and report progress to different audiences.
Before You Start
- Re-read the power/interest grid table and give each of the four quadrants from memory.
- Re-read the communication-plan template so you can reproduce its five columns.
- Re-read the five conflict-resolution styles and their rows of risk.
- Open the hospital EHR mini-project brief: the stakeholder mix in the worked example comes from it.
- Mindset prep: stakeholder attitudes shift during a project, so I will treat the grid as a living document.
Learning Objectives
- Identify all stakeholders for a project or initiative using multiple techniques
- Classify stakeholders using the Power/Interest Grid and other models
- Develop a stakeholder engagement plan with tailored strategies for each group
- Create a communication plan that specifies who gets what information, when, and how
- Manage stakeholder expectations throughout the project lifecycle
- Apply conflict resolution techniques when stakeholders disagree
- Prepare and deliver stakeholder reports for different audiences (executive, technical, end user)
- Recognize and handle hidden agendas and political dynamics
Prerequisites
Complete Business Analysis Fundamentals before starting this topic. Familiarity with elicitation techniques from Requirements Elicitation is also recommended.
Why Stakeholder Management Matters
A project can have perfect requirements, a perfect technical solution, and a perfect plan — and still fail if the right stakeholders are not on board. Stakeholder management is the discipline of ensuring that everyone who matters to the project is informed, engaged, and supportive (or at least not actively blocking).
The Business Analyst is uniquely positioned for stakeholder management because the BA is the person who talks to everyone: executives, end users, developers, compliance officers, vendors, and everyone in between. No other role has this breadth of contact.
Identifying Stakeholders
A stakeholder is anyone who has an interest in the project outcome, is affected by the change, or has influence over the project. Common stakeholder categories:
- Sponsors — fund the project, make final decisions, remove roadblocks
- End users — the people who will use the solution daily
- Subject matter experts (SMEs) — domain experts who know the current process in detail
- Technical team — developers, architects, QA, DevOps
- Compliance/Legal — ensure regulatory requirements are met
- Vendors/Partners — external companies providing tools or services
- Operations — the team that will support the solution after delivery
- Finance — budget approval and cost tracking
Techniques for discovering stakeholders:
- Review the project charter or business case
- Ask existing stakeholders "who else should be involved?"
- Review organizational charts
- Check who uses the current system or process
- Consider indirect stakeholders (customers of the output, regulatory bodies)
Power/Interest Grid
The Power/Interest Grid (also called the Mendelow Matrix) is the most widely used stakeholder classification model. It plots each stakeholder on two axes:
- Power (vertical axis): how much authority or influence they have over the project
- Interest (horizontal axis): how much they care about or are affected by the project
This creates four quadrants:
| Quadrant | Strategy | Example |
|---|---|---|
| High Power / High Interest | Manage closely — regular meetings, direct involvement in decisions | Project sponsor, CEO |
| High Power / Low Interest | Keep satisfied — periodic updates, address concerns proactively | CFO, Legal head |
| Low Power / High Interest | Keep informed — newsletters, demos, feedback sessions | End users, customer support |
| Low Power / Low Interest | Monitor — minimal effort, but do not ignore them entirely | Other departments not directly affected |
The grid is dynamic — stakeholders move between quadrants as the project progresses. Review it monthly.
Communication Planning
A Communication Plan defines what information is shared, with whom, how often, through what channel, and by whom. It is the operational blueprint for stakeholder management.
Communication Plan template:
| Audience | Information | Frequency | Channel | Owner |
|---|---|---|---|---|
| Project Sponsor | Status, risks, budget | Weekly | 1:1 meeting | PM |
| Technical Team | Requirements, design decisions | Daily standup + shared docs | Standup, Jira | BA |
| End Users | Progress, demos, feedback opportunities | Bi-weekly | Email + demo session | BA + PM |
| Finance | Budget tracking, cost-benefit updates | Monthly | Report | PM |
Key principles:
- Tailor the message to the audience — executives want summary, developers want detail
- Choose the right channel — sensitive topics in private, updates in groups
- Be consistent — if you promise weekly updates, deliver weekly updates
- Document everything — written communication creates a paper trail
Managing Expectations
Expectations fail when stakeholders assume the project will solve everything, when scope is unclear, or when promises are made without checking feasibility. Managing expectations is proactive, not reactive:
- Set clear boundaries early — define what is and is not in scope in the first week
- Use a RACI matrix — so everyone knows who decides, who does, and who is consulted
- Communicate constraints — budget, timeline, technical limitations — upfront
- Provide regular updates — no surprises. Bad news early is better than bad news late
- Use visual aids — burndown charts, demo sessions, and roadmaps make progress tangible
- Document agreements — every meeting decision goes into minutes or a shared document
The golden rule: under-promise and over-deliver, never the reverse.
Conflict Resolution
When multiple stakeholders have competing needs — which they will — the BA must resolve conflicts without damaging relationships. Five conflict resolution styles:
| Style | When to Use | Risk |
|---|---|---|
| Collaborating (Win-Win) | Both perspectives matter and time allows discussion | Time-consuming |
| Compromising (Give-Get) | Both sides need to give up something to move forward | Neither side fully satisfied |
| Accommodating (Yielding) | The issue matters more to the other party; preserving the relationship is critical | You may appear weak |
| Competing (Forcing) | A quick decision is needed and you are certain of the right path | Damages relationships |
| Avoiding (Withdrawal) | The issue is trivial or emotions are too high for productive discussion | Problem festers |
In practice, collaboration is preferred. When collaboration fails, escalate to the sponsor with clear facts and options — do not let conflicts linger.
Reporting to Different Audiences
Stakeholders at different levels need different information. Tailor your reports:
- Executive reports: One page, focus on business value, risk, and decision points. Use dashboards, not tables.
- Technical reports: Detailed requirements status, open questions, integration risks, and technical constraints.
- User reports: Focus on what changes for them, when training happens, and how to give feedback.
A good BA report answers three questions: Where are we? (status), Where are we going? (plan), and What is in the way? (risks/blockers).
Hands-On Practice
- Identify 8 stakeholders for a hypothetical project to launch a company intranet. Map each one on the Power/Interest Grid.
- Create a RACI matrix for 5 key activities (requirements gathering, design approval, development, testing, go-live) with at least 6 stakeholders.
- Write a one-page communication plan for the intranet project.
- Scenario: the Head of IT and the Head of HR disagree on whether the intranet should prioritize announcements or collaboration tools. Write a brief conflict resolution approach.
- Prepare a one-page executive status report for the project sponsor — include status, risks, and one decision needed.
Deeper Worked Examples
Resolving the IT versus HR battle over the company intranet
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Common Mistakes
- Identifying only obvious stakeholders — miss hidden ones like compliance, legal, or operations
- Treating all stakeholders the same — different groups need different levels of detail and communication
- Over-communicating to executives and under-communicating to end users
- Avoiding difficult conversations — conflicts fester and become project blockers
- Promising what you cannot deliver to keep a stakeholder happy
- Failing to document agreements — verbal commitments are forgotten or denied
- Ignoring stakeholder attitude changes — a supporter can become an blocker at any point
Real-World Usage
In a real job, stakeholder management is often 60% of the BA role. You will walk into an ERP implementation where the CFO wants cost savings, the IT Director wants modern architecture, and the warehouse manager just wants a system that does not crash at 3 PM. Your job is to find the overlapping ground, document the trade-offs, and present clear options. When two stakeholders disagree on priority, you escalate with facts, not opinions. When a sponsor is disengaged, you pull them back in with demo sessions that show real progress. The stakeholder management skills you learn here are what will get you promoted from junior to senior BA faster than any technical skill.
Mini Project
Business problem: A hospital is implementing a new Electronic Health Records (EHR) system. Multiple departments are affected.
Objective: Practice identifying, classifying, and planning communication with a complex set of stakeholders.
Task 1
Task 2
Task 3
Task 4
Task 5
| Deliverable | What it proves |
|---|---|
| Stakeholder list (10) | You can identify all affected parties |
| Power/Interest Grid | You can classify stakeholders strategically |
| RACI Matrix | You can define roles and responsibilities |
| Communication Plan | You can plan information flow |
| Executive summary | You can report to leadership effectively |
Key Takeaways
- Stakeholders are anyone affected by or influencing the project
- Use the Power/Interest Grid to classify stakeholders and assign engagement strategies
- A Communication Plan specifies who gets what information, when, how, and from whom
- Manage expectations proactively: set boundaries, communicate constraints, provide regular updates
- Five conflict resolution styles: collaborating, compromising, accommodating, competing, avoiding
- Tailor reports to the audience: executives want summary, users want impact, tech wants detail
- Stakeholder management is a continuous, dynamic process — not a one-time activity
Key Terms & Glossary
| Term | Meaning |
|---|---|
| Stakeholder | Anyone who affects a project, is affected by it, or holds influence over its outcome. |
| Power/interest grid | A two-axis model that maps stakeholders by authority and concern so you can decide how closely each must be managed. |
| RACI matrix | A grid that assigns every stakeholder a role of Responsible, Accountable, Consulted or Informed for each task. |
| Sponsor | The person who funds the project, makes the final decisions and removes roadblocks. |
| Subject matter expert | A domain expert who knows the current process in detail and helps define requirements without holding decision authority. |
| Communication plan | A table defining who receives what information, how often, through which channel and from whom. |
Learning Resources
BABOK Guide — Elicitation & Collaboration
Covers stakeholder engagement, communication techniques, and collaboration guidelines.
Stakeholder Theory (Harvard Business Review)
Foundational article on why stakeholder management matters for organizational success.
Stakeholder Management (PMI)
PMI’s guide to identifying, planning, and managing stakeholder engagement.
Conflict Resolution in the Workplace (MindTools)
Practical strategies for resolving conflicts between stakeholders.
Communication Plan Template (Atlassian)
A ready-to-use communication plan template with examples.
Chapter Quiz
Chapter Quiz — Stakeholder Management & Communication
Five questions on the human side of BA: mapping stakeholders, communication plans, expectations, conflict and reporting.
Question 1 of 5
The project sponsor sits high on power and high on interest. The matching engagement strategy is:
Knowledge Check
End-of-Topic Exam
Hint: Low power/high interest means keep informed; add extras because resistance threatens adoption.
Model answer: Doctors sit in the low-power/high-interest quadrant, so the standing strategy is keep informed. I would add three deliberate extras because resistance threatens adoption: a monthly demo where doctors touch the working increment, a named clinical champion from their own ranks to surface concerns early, and a user-facing report focused on what changes for them and when training happens. Their concerns would go onto an open issues list that the executive summary picks up weekly, so they can see their voice reaches decision-makers.
Hint: High power/low interest means keep satisfied, and the risk is apathy turning into a late veto.
Model answer: A disengaged high-power stakeholder is dangerous because they can veto budget or scope late, and their absence leaves decisions unanchored to business value. First, repair the communication plan: give the CFO a one-page dashboard of cost, benefit and decisions needed, not operational detail. Second, hold a short one-to-one demo of one concrete result so progress becomes tangible rather than abstract. Third, agree the frequency they genuinely want, such as a 15-minute monthly briefing, and update the plan accordingly so re-engagement is scheduled, not assumed.
Hint: Use the five-styles table: competing is forcing, avoiding is withdrawal.
Model answer: Competing fits a security-critical decision on a hard deadline where the evidence is clear and waiting would cost more than the relationship; the risk is damaged goodwill, so I would put the reasoning in writing afterwards. Avoiding fits a trivial point or a moment when emotions are too high for productive discussion, such as a side debate mid-workshop; the risk is that the problem festers, so I would timebox it and reserve a proper slot rather than dropping it silently. The key discipline is to return to the avoided issue, never to abandon it.
Hint: Where are we, where are we going, what is in the way.
Model answer: I would reorganise the report around three headed sections and give each a concrete line. Where are we: 'requirements signed off, 60 per cent of use cases modelled and the seed data loaded'. Where are we going: 'prototyping the checkout flow next sprint, with two demos scheduled'. What is in the way: 'the licence decision is still open and needs your sign-off before Friday'. This turns 'interesting' into decision-ready information for the sponsor.