Communications

Stakeholder management, meeting facilitation, written communication, and conflict resolution for BAs and SAs.

What is a Stakeholder?

Anyone who has an interest in or is affected by the outcome of a project. This includes:

•People who use the product (end users)

•People who fund or approve (sponsors, executives)

•People who build it (developers, QA, UX)

•People affected by it (compliance, legal, operations)

•External parties (regulators, partners, competitors)

Stakeholder Register

For each stakeholder, capture:

•Name / Role

•Department

•Interest in the project

•Influence level (High / Medium / Low)

•Attitude (Champion / Supporter / Neutral / Critic / Blocker)

•Communication preference (email, Slack, bi-weekly call)

•Key concerns

Power/Interest Grid (Stakeholder Matrix)

High Power │ Manage Closely │ Keep Satisfied
           │ (key stakeholders)│ (executives with low interest)
───────────┼─────────────────┼──────────────
Low Power  │ Keep Informed   │ Monitor
           │ (end users)     │ (minimal effort)
           └─────────────────┴──────────────
               Low Interest     High Interest

Communication Plan

For each quadrant, define:

•What information they receive

•How often

•In what format

•Who sends it

Common Mistakes

Identifying stakeholders too late (after scope is set)
Under-communicating with senior stakeholders ("no news is good news" — not in projects)
Treating all stakeholders the same (one-size-fits-all communication)
Ignoring resistors — they need more attention, not less

Project: CRM System Replacement

A regional bank is replacing its 15-year-old CRM with a modern cloud platform.

Stakeholder Map

Executive Sponsors (High Power, High Interest)

•CFO: concerned about cost overruns; wants monthly financial status

•CIO: champion of the project; wants weekly tech status

•Head of Retail Banking: needs zero downtime during migration

Key Users (Low Power, High Interest)

•Branch Managers (x42): will use system daily; worry about learning curve

•Customer Service Reps (x380): actual day-to-day users; highest change resistance

Influencers (High Power, Low Interest)

•Chief Compliance Officer: only cares about data protection and audit trails

•Head of HR: concerned about retraining budget

Minimal Engagement (Low Power, Low Interest)

•IT Support Team: will handle level-1 tickets post-launch

BA's Communication Approach

Stakeholder	Frequency	Channel	Content
CFO	Monthly	PDF Report	Budget spent, forecast, risks
CIO	Weekly	Slack + Meeting	Technical progress, blockers
Branch Managers	Bi-weekly	Email + Town Hall	What's changing, training dates
CS Reps	Before Go-Live	In-person workshop	How-to, FAQ, support contacts
CCO	On milestone	Email summary	Compliance checkpoints met

Result

By proactively managing the Branch Managers (High Interest group), the BA discovered that 12 branches used a custom Excel workflow not covered in the new system's scope — surfaced 3 months before go-live, saving a post-launch crisis.

Why Meetings Fail

No clear objective ("let's sync up")
Wrong people in the room
No pre-read or preparation
Dominant participants, silent others
No decisions made or documented
Actions assigned but not followed up

Meeting Types for BAs

Type	Purpose	Typical Length
Requirements workshop	Elicit and validate requirements	2-4 hours
Stakeholder review	Review documents/prototypes	1-2 hours
Sprint planning	Prioritize and plan work	1-2 hours
Daily stand-up	Sync on blockers	15 min
Retrospective	Improve process	1-2 hours
Steering committee	Status and decisions	1 hour

Before the Meeting

Define the outcome: what decision or artifact will exist after the meeting?
Invite only essential people
Send agenda and pre-reads 24-48 hours in advance
Prepare visual aids (wireframes, diagrams, templates)

During the Meeting

State the objective at the start
Time-box each agenda item
Use a parking lot for off-topic items
Capture decisions, actions, and owners in real time
Summarize at the end: "We agreed that… The next steps are…"

Facilitation Techniques

Fist to Five: quick consensus check (0 fist = strong no, 5 fingers = strong yes)
Dot Voting: prioritize options by giving each participant N votes (stickers)
Round Robin: go around the table to ensure everyone speaks
Affinity Mapping: group ideas on sticky notes to find themes
RACI Matrix: clarify who is Responsible, Accountable, Consulted, Informed

After the Meeting

Send meeting minutes within 24 hours
Include: decisions, action items, owner, due date
Follow up on overdue actions before the next meeting

Scenario

The BA must run a 3-hour requirements workshop with 10 stakeholders to define the scope of a new customer portal feature: "Self-Service Contract Management."

Preparation (1 week before)

Sent pre-read: current pain points survey results (5-minute read)
Prepared: 3 agenda items + sticky notes + dot stickers + whiteboard
Confirmed: product owner, 2 branch managers, 1 compliance officer, 2 devs, UX designer, QA lead

Agenda

Time	Item	Method
0:00-0:15	Welcome, objective, ground rules	Facilitation
0:15-0:45	Current pain points	Affinity mapping
0:45-1:45	Feature scope: what must/should/won't we build	MoSCoW voting
1:45-2:00	Break
2:00-2:45	Define acceptance criteria for top 3 stories	Small group work
2:45-3:00	Review, next steps, actions	Summary

Key Moments

Problem 1: The Head of Compliance dominated early discussion, pushing for full audit logging on all actions.

BA's action: Used round-robin to hear from all attendees. The UX designer revealed that excessive logging pop-ups caused users to abandon workflows in a previous project. This shifted the discussion — compliance accepted a selective logging approach.

Problem 2: Two branch managers disagreed on whether contract templates should be editable by branch staff.

BA's action: Moved the item to the parking lot, scheduled a follow-up with just those two managers + compliance. Kept the workshop moving.

Output

MoSCoW-prioritized scope list (19 items: 7 Must, 5 Should, 4 Could, 3 Won't)
Draft acceptance criteria for the 3 "Must" stories
4 action items with owners and due dates
Meeting minutes sent next morning

The Core Principle

Always write for your reader, not for yourself. The same information must be presented differently for a CEO, a developer, and an end user.

Pyramid Principle (Barbara Minto)

Structure all written communication top-down: 1. Start with the conclusion (the answer to the reader's question) 2. Support with key arguments (usually 3-5) 3. Provide evidence for each argument

Example opening — instead of: > "We conducted a 6-week analysis of the current state of the CRM system, evaluating 15 parameters across 3 business units, and after reviewing findings with stakeholders..."

Write: > "We recommend replacing the CRM system by Q3. The current system costs €280K/year in maintenance, causes 3 hours of manual work daily for each CSR, and cannot support our planned expansion."

Audience Adaptation

Audience	Focus	Avoid
C-suite	Business impact, cost, risk	Technical jargon, details
Product Owner	Features, user value, scope	Architecture diagrams
Developers	Technical specs, data model, APIs	Business strategy
End Users	What changes, how to do it	System internals

Types of BA Documents

Executive Summary (1 page): problem, solution, impact, decision needed

Business Requirements Document (BRD):

•Background and business context

•Problem statement

•Proposed solution scope

•Stakeholders and their needs

•High-level requirements

•Constraints and assumptions

•Success metrics

Functional Specification:

•Detailed system behavior descriptions

•UI wireframes and flows

•Business rules

•Data requirements

•Error handling

Email Best Practices

Subject line = the ask or the point: "Decision needed: CRM vendor by Friday"
Keep emails under 5 bullet points
Make the call to action explicit: "Please review and reply by Wednesday 5pm"
Attachments: always reference them in the body