Salesforce BA Zero to Hero Module 3 — Stakeholder Management & Communication
🤝 Salesforce BA Zero to Hero — Module 3 of 15
Stakeholder Management & Communication
You now know how to gather great requirements. This module covers the equally critical human skill: managing the people, the politics, the conflicting priorities, and the difficult conversations every real project involves.
Module 3 of 15 (counting Module 0 as a bonus prerequisite) · Phase 1: BA Foundations (Final Module)
🎯 What You Will Master in This Module
Technical BA skill alone is not enough — every real project involves people with different priorities, different levels of authority, and sometimes genuinely conflicting needs. This module gives you concrete frameworks and techniques for navigating the human side of BA work professionally and effectively.
✓ Identifying and mapping every stakeholder who genuinely matters to a project
✓ The Power/Interest Grid — prioritizing your limited engagement effort wisely
✓ RACI — clarifying exactly who decides, who is consulted, and who is just informed
✓ Managing genuinely conflicting priorities between different stakeholders
✓ Status reporting that builds trust rather than just covering yourself
✓ Navigating difficult conversations — pushing back, saying no, addressing scope creep
✓ Building genuine, long-term trust with stakeholders, not just managing one project
📋 In This Module
Concept 1 of 7
Identifying & Mapping Stakeholders
Before you can manage stakeholders effectively, you need a complete, deliberate picture of WHO they actually are. This sounds obvious, but the most common stakeholder management failure is simply missing someone important early on — discovering a key stakeholder's existence only after a decision has already been made without their input.
⚡ Why This Matters
A stakeholder discovered late in a project, after design decisions are already made, often (understandably) pushes back hard precisely because they were excluded from the process — not necessarily because their feedback is wrong. Thorough upfront stakeholder mapping prevents this entirely avoidable category of conflict.
Categories of stakeholders to deliberately consider:
DIRECT USERS
└─ Who will actually use the solution day-to-day?
DECISION MAKERS
└─ Who has formal authority to approve scope, budget, or sign-off?
INDIRECTLY AFFECTED TEAMS
└─ Who is impacted by this change but doesn't directly use the solution?
(e.g. Finance affected by a change to how Opportunities close)
TECHNICAL STAKEHOLDERS
└─ Admins, Developers, Architects, IT Security/Compliance
EXTERNAL STAKEHOLDERS
└─ Customers, partners, or vendors genuinely affected by this change
🛠️ Practical: Build a Stakeholder List for a Real Project
1Project: "Automate the process for approving large customer discounts over 20%."
2Using the five categories above, list at least one specific stakeholder or stakeholder group under EACH category for this project.
3Strong example list: Direct Users — Sales Reps requesting discounts, Sales Managers approving them. Decision Makers — VP of Sales (owns the discount policy itself). Indirectly Affected — Finance (cares about margin impact), Legal (cares about discount consistency for compliance). Technical — the Admin who will build the Approval Process. External — none obvious here, but worth explicitly confirming rather than assuming.
4Notice Legal and Finance specifically — these are exactly the kind of "indirectly affected" stakeholders that get missed if a BA only thinks about who directly clicks buttons in Salesforce, rather than who is genuinely impacted by the underlying business process change.
⚠️ Common Gotcha — Confusing "Who I Already Know" with "Who Actually Matters"
It is natural to default to mapping stakeholders you already have an existing relationship with. This creates a real blind spot for stakeholders who are genuinely important to the project but happen to be outside your existing network. A deliberate practice: explicitly ask early stakeholders "who else should be involved in this that I might not be thinking of?" — this single question consistently surfaces people who would otherwise be missed.
Concept 2 of 7
The Power/Interest Grid — Prioritizing Your Limited Engagement Effort
Not every stakeholder needs, or deserves, the same level of engagement. The Power/Interest Grid is a simple, widely-used framework that plots stakeholders along two dimensions — how much POWER (formal authority/influence) they have, and how much INTEREST (genuine personal stake) they have in this specific project — to help you allocate your genuinely limited time wisely.
⚡ Why This Matters
A BA who treats every stakeholder identically either wastes significant time over-engaging low-priority people, or under-engages a quietly powerful stakeholder who could derail the project later if ignored early. This framework makes that prioritization decision deliberate rather than accidental.
| Quadrant | Engagement Strategy | Example |
|---|---|---|
| High Power, High Interest | Manage Closely — these are your primary partners; engage frequently and thoroughly | The VP sponsoring the project, who is also personally invested in its success |
| High Power, Low Interest | Keep Satisfied — they could derail things if ignored, but don't need constant detail | A senior executive who must approve budget but isn't involved day-to-day |
| Low Power, High Interest | Keep Informed — they care deeply and are a great source of detailed input, even without formal authority | A frontline Support Agent who will use the new process daily |
| Low Power, Low Interest | Monitor — light-touch awareness is sufficient; do not over-invest time here | A peripheral team only marginally affected by this specific change |
🛠️ Practical: Plot Your Discount Approval Project Stakeholders
1Using the stakeholder list you built in Concept 1's exercise, plot each one onto the four quadrants above.
2Where would the VP of Sales likely fall? (High Power — owns the policy; likely High Interest too, since this directly affects their team's effectiveness) → Manage Closely.
3Where would an individual Sales Rep likely fall? (Lower Power — doesn't set policy; but High Interest — this directly affects their daily work) → Keep Informed, and genuinely value their detailed input.
4Where might Legal fall, if they care about discount consistency but are not deeply hands-on with this specific project? (Possibly High Power, Low-to-Medium Interest) → Keep Satisfied — make sure their compliance concerns are addressed, without necessarily looping them into every detail meeting.
5This exercise should genuinely change how you plan your time across the project — notice you would NOT spend equal time with every stakeholder on your list.
⚠️ Common Gotcha — Treating This Grid as Permanently Fixed
A stakeholder's position on this grid can genuinely shift as a project evolves — someone with Low Interest at the start might become High Interest once they realize how the change will actually affect them. Revisit your stakeholder mapping periodically throughout the project rather than treating your initial plotting as permanent and unchanging.
Concept 3 of 7
RACI — Clarifying Roles and Decision Rights
RACI is a simple but genuinely powerful framework for explicitly clarifying who does what on a given decision or deliverable: Responsible (does the work), Accountable (owns the final decision — exactly one person per item), Consulted (provides input before the decision), and Informed (notified after the decision is made). Ambiguity about these roles is one of the most common, entirely avoidable sources of project friction.
⚡ Why This Matters
Without explicit RACI clarity, projects commonly experience two opposite failure modes: decisions made without consulting someone who should have had input, or decisions stalling indefinitely because nobody is clearly Accountable for actually making the final call.
| Role | Meaning | Key Rule |
|---|---|---|
| R — Responsible | Actually does the work to complete this task or deliverable | Can be multiple people |
| A — Accountable | Owns the final decision and is ultimately answerable for the outcome | Must be EXACTLY ONE person — never zero, never more than one |
| C — Consulted | Provides input BEFORE the decision is finalized — genuine two-way input | Their input should be genuinely sought, not just a formality |
| I — Informed | Notified AFTER the decision is made — one-way communication | No input expected, just awareness |
🛠️ Practical: Build a Mini RACI for the Discount Approval Project
1Decision: "What exact discount percentage threshold requires VP approval?"
2Assign RACI roles for this specific decision among: the BA, the VP of Sales, the Sales Managers, and Finance.
3Strong example: BA = Responsible (gathers input, drafts the recommendation, documents the final decision). VP of Sales = Accountable (owns the final call on the threshold — exactly one decision-maker). Sales Managers and Finance = Consulted (their input genuinely shapes the recommendation before it's finalized). Sales Reps = Informed (notified of the final threshold once decided, but do not need to be consulted on setting the policy itself).
4Notice there is exactly ONE Accountable person. If you found yourself wanting to mark two people as Accountable, that is itself a sign of unresolved ambiguity worth surfacing and resolving before the project proceeds further.
💡 RACI Is Most Valuable When There's Already Confusion
You do not need a formal RACI matrix for every trivial decision on a project. RACI earns its value specifically in situations with genuine ambiguity — multiple stakeholders who might reasonably believe THEY are the decision-maker, or a decision significant enough that getting the process wrong would be costly. Use it deliberately where it adds real clarity, not as bureaucratic overhead for every minor choice.
⚠️ Common Gotcha — Confusing Responsible and Accountable
These two roles are frequently confused. The BA is very often Responsible for DRIVING a decision process — gathering input, facilitating discussion, drafting a recommendation — without being Accountable for actually OWNING the final decision itself. A BA recommending a discount threshold is doing real, valuable work, but the VP remains Accountable for the actual final call. Conflating these roles can lead to a BA either overstepping their actual authority, or conversely, failing to drive a decision process that genuinely was their responsibility to push forward.
Concept 4 of 7
Managing Conflicting Priorities Between Stakeholders
Module 2's synthesis exercise already showed you ONE form of conflict — different stakeholders giving different factual answers. This concept addresses a deeper, more common form: stakeholders genuinely WANTING different, sometimes incompatible things, each with legitimate reasoning behind their position. Navigating this well is a core, learnable BA skill, not just innate diplomacy.
⚡ Why This Matters
Conflicting priorities are not a sign something has gone wrong — they are a NORMAL feature of any project touching multiple teams with genuinely different goals. A BA who can navigate this constructively, rather than avoiding it or picking sides reflexively, becomes a genuinely trusted figure across the whole organization.
A practical approach to navigating conflicting priorities:
1. UNDERSTAND THE "WHY" BEHIND EACH POSITION
Surface-level conflict often masks a deeper, genuinely valid concern
on each side — dig into the underlying reasoning, not just the stated ask
2. LOOK FOR THE ACTUAL SHARED GOAL
Conflicting stakeholders are often optimizing for the SAME ultimate
business outcome, just via different, conflicting tactical approaches
3. PROPOSE OPTIONS, NOT JUST ONE ANSWER
Present 2-3 possible paths forward with honest tradeoffs, rather than
unilaterally picking a side yourself
4. ESCALATE WHEN GENUINELY STUCK
If stakeholders cannot align even with your facilitation, escalate to
whoever holds genuine Accountability (per Concept 3's RACI) to decide
🛠️ Practical: Navigate a Real Conflicting-Priority Scenario
1Sales wants Opportunities to require minimal fields to close quickly, prioritizing speed. Finance wants extensive fields captured at close, prioritizing accurate revenue reporting. Both are pushing you for opposite designs.
2Apply step 1 above: what is the genuine underlying "why" for each side? Sales: every extra required field is friction that can cost them a deal in the moment, or annoy reps into entering bad data just to get past validation. Finance: incomplete data at close creates real downstream problems for revenue recognition and forecasting accuracy.
3Apply step 2: is there a shared goal underneath this conflict? Likely yes — both teams genuinely want accurate, healthy, well-tracked business outcomes; they disagree only on the tactical mechanism (when/how data gets captured), not the ultimate goal.
4Apply step 3: draft 2 possible compromise options. Option A: keep close-time fields minimal, but require Finance's additional fields within 48 hours post-close via a separate, lower-pressure follow-up process. Option B: make only the 2-3 most business-critical Finance fields required at close, with the rest optional but encouraged.
5Notice neither option simply "picks a side" — both genuinely attempt to serve the real underlying needs of both teams, which is a far stronger position to bring back to both stakeholders than declaring one team's priority more important than the other's.
⚠️ Common Gotcha — Avoiding the Conflict Entirely
A common but unhelpful BA instinct is to avoid explicitly surfacing a conflict, hoping it somehow resolves itself or quietly favoring whichever stakeholder is easier to deal with. Unaddressed conflicts do not actually disappear — they typically resurface later, often during UAT or even post-launch, at a far more costly point in the project. Surfacing conflict explicitly and early, even though it feels uncomfortable, is genuinely the more professional and ultimately easier path.
Concept 5 of 7
Status Reporting & Setting Expectations
Regular status communication is not bureaucratic overhead — it is the primary mechanism that keeps stakeholders aligned with reality as a project progresses, and prevents the genuinely damaging experience of a stakeholder being surprised by a delay or change they had no warning of.
⚡ Why This Matters
Stakeholders generally tolerate bad news communicated proactively and early far better than they tolerate the same bad news discovered late, or worse, discovered through someone other than you. Good status reporting is fundamentally about managing the TIMING and FRAMING of information, not just its content.
| Status Reporting Principle | Why It Matters |
|---|---|
| Be Specific, Not Vague | "On track" tells stakeholders nothing actionable; "75% of requirements signed off, on pace for the agreed date" does |
| Flag Risks Before They Become Issues | "This might slip if X doesn't resolve by Friday" gives stakeholders time to react; a surprise on Friday does not |
| Tailor Detail to the Audience | An executive needs a 2-sentence summary; a hands-on stakeholder may want the full detail (recall the Power/Interest Grid) |
| Consistent Cadence | Predictable, regular updates build trust; sporadic updates only when something is wrong creates anxiety |
🛠️ Practical: Draft Two Versions of the Same Status Update
1Real situation: requirements gathering for the discount approval project is running about a week behind schedule because Legal has been slow to confirm compliance requirements.
2Draft a status update for the VP of Sales (High Power, likely Lower day-to-day Interest per Concept 2's grid) — keep it brief and focused on the bottom line.
3Strong example: "Quick update: Requirements are about a week behind schedule due to pending Legal compliance review. I'm following up directly to keep this moving — will flag immediately if it impacts the overall go-live date."
4Now draft a more detailed version for the hands-on Project Manager who needs to actually adjust the project plan.
5Strong example: "Requirements gathering is currently ~5 business days behind plan. Root cause: Legal needs to confirm specific compliance language for the approval workflow before we finalize that section of the BRD. I've scheduled a follow-up with Legal for Thursday. If resolved then, we absorb most of the delay by compressing Design review by 2 days. If it slips further, recommend we discuss adjusting the overall timeline."
6Notice both versions are honest and specific — the difference is depth and framing tailored to what each specific audience actually needs to act on, exactly the audience-tailoring principle from the table above.
⚠️ Common Gotcha — Sugarcoating Bad News
A natural instinct under pressure is to soften or delay communicating bad news, hoping the situation resolves before you have to report it. This consistently backfires — stakeholders lose far more trust discovering a problem was known about and not communicated promptly, than they lose simply hearing honest, timely bad news. Report problems as soon as you have genuine clarity on them, not once they are already fully resolved or impossible to hide.
Concept 6 of 7
Navigating Difficult Conversations
Every BA eventually needs to push back on a stakeholder, say no to a request, or flag that something is now out of scope. These conversations are genuinely uncomfortable, but avoiding them entirely causes far worse long-term outcomes — uncontrolled scope creep, unrealistic expectations, or a project that quietly drifts away from its original, agreed purpose.
⚡ Why This Matters
A BA who can never say "that's actually out of scope" or "I don't think that will achieve what you're hoping for" is not actually serving stakeholders well, even though avoiding friction might feel like the more pleasant short-term choice. Respectful, well-handled pushback is a core part of genuine BA value.
A practical structure for a difficult conversation:
1. ACKNOWLEDGE THE REQUEST GENUINELY
"I understand why this would be valuable" — show you took it seriously
2. STATE THE CONCERN CLEARLY AND SPECIFICALLY
"This wasn't part of the original signed-off scope, and adding it now
would push our timeline back by roughly two weeks"
3. OFFER A PATH FORWARD, NOT JUST A "NO"
"I'd recommend we log this as a Change Request and evaluate it
alongside the timeline impact — or we could consider it for a
follow-up phase after this initial launch"
4. LET THE RIGHT PERSON DECIDE
If this affects timeline/budget, the actual decision-maker (recall
RACI's Accountable role) should make the final call, not you alone
🛠️ Practical: Script a Difficult Conversation
1Scenario: A stakeholder who was not part of the original sign-off now wants a significant new feature added mid-Build, insisting it is "small" and should "just be added quickly."
2Using the four-step structure above, draft what you would actually say in this conversation, in your own words.
3Strong example: "I can see why this would genuinely help your team — that makes sense. That said, this wasn't part of what we originally scoped and signed off on, and even something that feels small can have real downstream impact on testing and timeline that isn't always obvious upfront. I'd suggest we log this properly as a Change Request so we can honestly assess the impact, rather than quietly squeezing it in. If it's genuinely urgent, I'm happy to flag it to [the Accountable decision-maker] for a quick call on priority."
4Notice this response never says a flat "no" — it validates the request, explains the genuine concern specifically, and offers a clear, professional path forward, exactly the structure that builds trust even while delivering an unwelcome message.
⚠️ Common Gotcha — Confusing "Agreeable" with "Helpful"
Always saying yes to keep stakeholders happy in the moment is not actually helpful — it often leads to unrealistic expectations, uncontrolled scope, and ultimately a worse outcome for everyone, including the stakeholder who made the original request. Genuine BA professionalism sometimes means being the person willing to say the harder, more honest thing, delivered respectfully — this is a feature of the role, not a failure of diplomacy.
Concept 7 of 7
Building Long-Term Trust with Stakeholders
Everything covered in this module compounds over time into something genuinely valuable: a reputation. Stakeholders who have worked with you across multiple projects develop real trust (or real distrust) based on a consistent pattern of behavior — and this reputation directly determines how smoothly your future projects go.
⚡ Why This Matters
A BA with strong stakeholder trust gets more candid information during elicitation (Module 2), faces less resistance during difficult conversations (Concept 6), and generally moves projects forward with far less friction. This trust is not innate charisma — it is the cumulative, earned result of consistently demonstrating the behaviors covered throughout this entire module.
What consistently builds genuine long-term stakeholder trust:
✓ Following through on what you said you would do, every time
✓ Communicating bad news promptly, not just good news
✓ Remembering and honoring past commitments and context
✓ Being honest even when it's uncomfortable (Concept 6)
✓ Genuinely listening, not just waiting for your turn to talk
✓ Giving credit to stakeholders for good ideas, not claiming them yourself
What consistently erodes it:
✗ Overpromising and underdelivering, even occasionally
✗ Surprising stakeholders with bad news they should have heard earlier
✗ Being inconsistent — different behavior with different people
✗ Avoiding necessary difficult conversations
🛠️ Practical: Audit Your Own Communication Habits
1Think of a real working relationship in your own life, professional or otherwise, where you genuinely trust the other person's word completely.
2Identify which specific behaviors from the "builds trust" list above that relationship actually demonstrates. Be concrete, not vague.
3Now think of a working relationship where trust is genuinely weaker. Identify which specific behaviors from the "erodes trust" list are present there instead.
4Honestly reflect: which of the "erodes trust" behaviors are you personally most at risk of falling into under pressure or a tight deadline? Naming this honestly now is a genuinely useful act of self-awareness before you are actually under that pressure on a real project.
⚠️ Module Wrap-Up — Phase 1 Complete
This module completes Phase 1: BA Foundations. Module 1 gave you the structural lifecycle every project moves through. Module 2 gave you the technique for gathering genuine requirements. This module gave you the human skill of managing the people and relationships involved. Phase 2 begins next, covering the core BA DELIVERABLES — User Stories, Process Maps, Gap Analysis, and BRDs/FRDs — the actual documents and artifacts that everything from Phases 1 feeds directly into.
💬 Module 3 Interview Questions (6)
Q1Why does failing to identify a key stakeholder early in a project often cause more friction than the same stakeholder simply disagreeing with a decision they were properly consulted on?
When a stakeholder is missed entirely during initial stakeholder mapping, they typically discover the project, and any decisions already made, only after those decisions have effectively been finalized, which understandably feels exclusionary regardless of whether their specific feedback would have changed the outcome. Their resulting pushback often becomes as much about the process failure of being excluded as about the substance of the decision itself, making the conversation harder to resolve constructively. A stakeholder who was properly identified, consulted, and ultimately disagreed with a decision experiences a fundamentally different situation, since they had genuine opportunity to provide input and can see their perspective was at least considered, even if the final decision did not fully align with their preference, which generally produces far less friction even when the substantive disagreement is similar.
"A missed stakeholder discovers decisions after the fact, making their pushback as much about being excluded from the process as the decision's substance, while a properly consulted stakeholder who simply disagrees has had genuine input considered, producing far less friction even with a similar substantive disagreement."
Q2Using the Power/Interest Grid, how would you justify spending significantly less time with a High Power, Low Interest stakeholder compared to a High Power, High Interest stakeholder, without this seeming like you are neglecting an important person?
A High Power, Low Interest stakeholder genuinely needs to remain satisfied and aware enough that they do not become an obstacle, since their formal authority means they could meaningfully impact the project if ignored entirely, but they have not expressed deep personal investment in the day-to-day details, meaning frequent, detailed engagement would consume their time without providing proportional value to either party. The appropriate strategy, "Keep Satisfied," involves periodic, concise, high-level updates focused on the outcomes and decisions that matter most to their specific concerns, rather than the frequent, detailed engagement appropriate for a High Power, High Interest stakeholder who has explicitly signaled deep investment in the project's specifics. This is not neglect; it is correctly calibrating engagement depth to match what each specific stakeholder actually needs and wants, which respects their time rather than imposing unwanted detail on someone who has not asked for it.
"A High Power, Low Interest stakeholder needs periodic, concise updates to stay satisfied and non-obstructive, not frequent detailed engagement they have not asked for and would not value — this is correctly calibrating engagement to match actual stakeholder need, not neglect."
Q3In a RACI matrix, why must exactly one person be marked as Accountable for a given decision, never zero and never more than one?
If zero people are marked Accountable for a decision, there is no clear owner responsible for actually making the final call, which commonly results in the decision stalling indefinitely as different stakeholders assume someone else will resolve it, or alternatively results in an unplanned, ad-hoc decision being made by whoever happens to act first, without genuine authority to do so. If more than one person is marked Accountable, this creates the opposite problem, where multiple people each believe they hold final decision-making authority, which can lead to conflicting decisions being made independently, or a different kind of stalemate where neither party wants to override the other's perceived authority. Having exactly one Accountable person ensures there is always a single, clear point of final decision-making authority and clear ownership of the outcome, which is the entire purpose RACI's Accountable designation is meant to serve.
"Zero Accountable people causes decisions to stall indefinitely or get made ad-hoc by whoever acts first without real authority; multiple Accountable people risks conflicting independent decisions or a stalemate — exactly one person ensures a single, clear point of final decision-making authority."
Q4Two stakeholders want genuinely conflicting outcomes for the same feature. Rather than simply choosing the stakeholder with more organizational authority, what approach would you take first, and why?
The first approach should be to genuinely understand the underlying reasoning, the "why," behind each stakeholder's position, rather than treating this purely as a contest of relative organizational authority to be resolved by simply deferring to whoever ranks higher. Conflicting stakeholders are very often actually optimizing for the same broader business outcome but disagree on the tactical approach to achieve it, meaning there may be a genuine third option that reasonably satisfies both underlying concerns once they are properly understood, rather than requiring an either-or choice at all. Defaulting immediately to organizational authority as the tie-breaker, without first exploring whether a better mutual solution exists, risks an unnecessarily worse outcome and can also damage trust with the stakeholder who was not deferred to, who may reasonably feel their genuine concern was never actually heard or considered.
"Understand the genuine underlying reasoning behind each position first, since conflicting stakeholders are often optimizing for the same broader goal via different tactics, meaning a mutually satisfying option may exist — defaulting immediately to organizational authority without exploring this risks a worse outcome and damages trust with whoever is not deferred to."
Q5Why does proactively communicating bad news early generally preserve more stakeholder trust than delaying the same bad news until it is fully resolved or undeniable?
When bad news is communicated proactively and early, stakeholders generally interpret this as a sign of honesty and competence, since it demonstrates the BA is monitoring the project closely enough to identify emerging risks and is willing to share difficult information promptly rather than only when forced to. When the same bad news is delayed until it becomes undeniable or fully resolved, stakeholders often discover not just the original problem, but also the secondary issue that the problem was apparently known about for some time without being communicated, which raises legitimate questions about what else might be similarly withheld in the future. This secondary trust violation, the implication of concealment, frequently causes more lasting damage to the working relationship than the original bad news itself would have caused if it had simply been shared honestly and promptly.
"Early, proactive bad news signals honesty and competence, while delayed bad news creates a secondary trust violation, the implication that information was withheld, which often damages the relationship more lasting than the original problem would have if it had simply been communicated promptly and honestly."
Q6A stakeholder insists on adding a feature mid-project that was not part of the original signed-off scope, and frames it as urgent and necessary. Walk through how you would handle this conversation professionally.
The conversation should begin by genuinely acknowledging the request and the stakeholder's reasoning, demonstrating that their concern is being taken seriously rather than dismissed outright, since this sets a collaborative rather than adversarial tone for what follows. Next, the specific concern should be stated clearly and concretely, such as explaining that this request falls outside the originally signed-off scope and would have a real, specific impact on timeline or testing effort, rather than vaguely resisting without explanation. Rather than ending with a flat refusal, the appropriate next step is to offer a constructive path forward, such as formally logging the request as a Change Request to properly evaluate its impact, or considering it for a subsequent phase after the current scope is delivered. Finally, since this kind of decision affects timeline and budget, the actual Accountable decision-maker, as defined by the project's RACI, should make the final call on whether to proceed, rather than the BA unilaterally deciding alone, ensuring the decision carries genuine organizational authority and appropriate ownership.
"Acknowledge the request genuinely, clearly state the specific scope and timeline concern, offer a constructive path forward like a formal Change Request rather than a flat no, and ensure the actual Accountable decision-maker per RACI makes the final call rather than the BA deciding unilaterally."
📝 Module 3 Recap — Stakeholder Management & Communication Mastered
✅ Map stakeholders deliberately across 5 categories — missed stakeholders cause friction rooted in exclusion, not just disagreement
✅ The Power/Interest Grid prioritizes limited engagement time — Manage Closely, Keep Satisfied, Keep Informed, Monitor
✅ RACI clarifies roles explicitly — exactly one Accountable person per decision, never zero, never more than one
✅ Conflicting priorities are normal, not a failure — understand the underlying "why," find shared goals, propose options rather than picking sides
✅ Status reporting is about timing and framing — be specific, flag risks early, tailor detail to the audience, never sugarcoat bad news
✅ Difficult conversations follow a structure: acknowledge, state the concern specifically, offer a path forward, let the right person decide
✅ Long-term trust is the cumulative, earned result of consistent behavior — not innate charisma
🎉 Phase 1 Complete — BA Foundations Mastered!
Modules 1 through 3 gave you the complete foundation: the structural lifecycle every project moves through, the technique for genuinely effective elicitation, and the human skill of managing stakeholders and difficult conversations professionally. Phase 2 begins next — Core BA Deliverables — where you will turn everything from Phase 1 into the actual documents and artifacts real BA work produces: User Stories, Process Maps, Gap Analysis, and BRDs/FRDs.
🎯 Before Moving to Module 4...
1. Build a complete stakeholder map AND Power/Interest Grid plotting (Concepts 1 & 2) for a real or imagined project of your own choosing.
2. Draft a mini RACI matrix (Concept 3) for one genuine decision within that same project.
3. Write out a full difficult-conversation script (Concept 6) for a scope-creep scenario you have personally witnessed or can realistically imagine.
4. Honestly complete the trust self-audit from Concept 7.
Module 4 begins Phase 2, covering User Stories and Acceptance Criteria — the first of the core BA deliverables that everything from Phase 1 now feeds directly into.
2. Draft a mini RACI matrix (Concept 3) for one genuine decision within that same project.
3. Write out a full difficult-conversation script (Concept 6) for a scope-creep scenario you have personally witnessed or can realistically imagine.
4. Honestly complete the trust self-audit from Concept 7.
Module 4 begins Phase 2, covering User Stories and Acceptance Criteria — the first of the core BA deliverables that everything from Phase 1 now feeds directly into.
← Module 2: Requirements Gathering & Elicitation
Module 4: User Stories & Acceptance Criteria → (Coming Soon)
☕
☕ Enjoyed this article?
SF Interview Pro is 100% free and maintained by a Salesforce professional. No ads, no paywalls, and no signup required. If this guide helped you prepare for an interview, earn a certification, or grow your Salesforce career, consider buying me a coffee! ☕💜
🇮🇳 UPI (India)
Pay by QR
GPay · PhonePe · Paytm · BHIM
📚 Keep Preparing
New interview questions every week 🚀
Follow for fresh Salesforce Q&A, free courses, and real interview experiences — straight from the trenches.
👥 Follow on LinkedIn