5 exercises — learn how to communicate project delays, rejected requests, and scope cuts with clarity, honesty, and professionalism.
0 / 5 completed
Key phrases for delivering bad news professionally
"I want to be upfront with you: there's a significant challenge I need to share."
"The primary reason is [X], not [Y] — I want to be clear about that distinction."
"I take responsibility for not identifying this risk earlier in the planning phase."
"I know this is disappointing — let's discuss how we move forward from here."
"I'd like to revisit this during [Q1 planning / the next sprint / our next review]."
1 / 5
You need to tell a client that the project will be delayed by 3 weeks. Which opening is most professional?
Option B is the gold standard for delivering bad news. It follows the "BLUF" principle (Bottom Line Up Front): (1) signals bad news is coming ("difficult news"), (2) states the specific impact immediately (3 weeks, exact dates), (3) names the cause ("technical blocker"), (4) commits to explanation and mitigation. Option A buries the lede with vague softening. Option C uses bureaucratic language ("unforeseen circumstances") without specifics — clients find this evasive. Option D over-explains team effort before stating the actual problem — the client hears this as an excuse before a problem. Always lead with the specific impact, then context and next steps.
2 / 5
You must tell a developer their feature request has been rejected due to budget cuts. Which response is most effective?
Option B handles rejection professionally by: (1) "After reviewing" — shows the decision was considered, not arbitrary, (2) stating the specific reason (budget, not Q4 cycle), (3) "The idea itself is solid" — separates the decision from the merit of the idea, which preserves the developer's motivation, (4) offering a concrete next step ("revisit in Q1 planning"). Option A is vague and patronising. Option C is accurate but blunt without context or next steps. Option D deflects responsibility to "management" — this undermines trust and sounds like you're distancing yourself from the decision. When delivering rejections, always: give the reason, validate what's valid, and offer a path forward.
3 / 5
You need to communicate a significant scope reduction to the team — a key feature is being cut from the release. Which phrasing best delivers this news?
Option A is the complete professional package for scope reduction news. It contains: (1) a clear signal ("tough news"), (2) specific feature name and timeline ("offline mode / v2 release"), (3) the business reason with supporting data ("73% of complaints are performance-related"), (4) acknowledges the emotional impact ("I know this is disappointing"), (5) concrete next step ("archive the work cleanly for v2.1"). Option B is accurate but abrupt — "business decision" without rationale feels dismissive. Option C over-apologises and attributes the decision to "management" passively. Option D uses corporate language ("deprioritised", "resource constraints") that feels evasive. Include data when you have it — it shows the decision was evidence-based.
4 / 5
Which phrase is most effective when you need to soften the delivery of bad news without being evasive?
Option B is the most professional framing. "I want to be upfront with you" signals honesty and respect — it positions you as someone who doesn't hide difficult information. "Significant challenge" acknowledges gravity without catastrophising. This phrase prepares the listener without triggering a defensive reaction. Option A is too dramatic — "it's really bad news" raises anxiety before the actual content. Option C is apologetic to the point of sounding like you're asking for forgiveness for the news itself, which undermines your credibility. Option D is informal and slightly confrontational — it predicts the listener's reaction, which can feel presumptuous. The goal of the opening is to signal honesty and seriousness while keeping the listener calm and receptive.
5 / 5
After delivering bad news about a project delay, a stakeholder asks "How did this happen?" Which response best balances honesty with professionalism?
Option B is the professional model for explaining what went wrong. It provides: (1) a specific root cause ("sandbox didn't reflect production behaviour"), (2) the moment it was discovered ("sprint 4"), (3) the exact impact ("full rework of transaction module"), (4) personal accountability ("I take responsibility for not identifying this risk earlier"). The last point is critical — accountability without blame-shifting is what builds long-term trust. Option A blames the QA team publicly, which is professionally damaging and likely to create conflict. Option C defers the answer entirely — this sounds like you're hiding something. Option D minimises with a platitude ("these things happen") which can feel dismissive to a stakeholder who is financially impacted. Own the cause, provide specifics, and show you understand what should have been done differently.