How to Communicate a Project Risk and Recommend a Response in English

A risk update that only names the problem forces the sponsor to ask three follow-up questions before they can act. A risk update that also names the response answers them before they're asked.

Too alarming:

"This could really derail the project."

Too thin:

"There's some risk, but we're on it."

More useful:

"The vendor integration is the risk — if their API changes slip again, it pushes our test window by two weeks. We're de-risking it now by running against their staging environment early. We have about a week of wiggle room in the schedule before that becomes a hard problem. If the slip goes past that, I'd recommend pivoting to a phased launch rather than holding the full release."

That message gives a steering committee everything it needs in one pass: what's at risk, what's already being done about it, how much room exists before a decision is forced, and what the fallback would be if it comes to that.

Name the risk in terms of impact, not just existence

Before proposing a response, state what the risk actually threatens — not just that a risk "exists."

Vague:

"There's a risk with the vendor."

Specific:

"The risk is the vendor's API change. If it slips past next Friday, our integration testing window shrinks from two weeks to three days."

Useful phrases:

• "The risk is [event], and it would affect [specific impact]."
• "If [condition] happens, the effect is [impact], not just delay in general."
• "The exposure here is [what's actually at stake]."

A risk statement without a named impact reads as anxiety. A risk statement with a named impact reads as something the committee can actually weigh against other priorities.

State the de-risk action already in motion

"De-risk" means taking a concrete, deliberate action that reduces how likely a plan is to fail, or how bad it would be if it did — before the risk becomes a live problem. You de-risk the launch, the plan, the decision. You do not de-risk "the risk" itself; the action targets the undertaking, not the threat.

Weak:

"We're being careful about it."

Concrete:

"We're de-risking the integration by running our test suite against the vendor's staging environment starting this week, so we catch any API break before it hits our real deadline."

Useful phrases:

• "We're de-risking [the plan/decision/launch] by [concrete action]."
• "The de-risking step here is [action] — it doesn't remove the risk, but it catches it earlier."
• "This is now largely de-risked, but not risk-free."

Name the mechanism, not just the intent. "We're de-risking it" alone is closer to "we're being careful" than to an actual answer. "We're de-risking it by starting integration tests two weeks early" gives the committee something they can evaluate as sufficient or not.

For the distinction from a related but different verb, see De-Risk vs Mitigate: What's the Difference? and De-Risk vs Contingency Plan: What's the Difference?.

Name the wiggle room that's actually left

"Wiggle room" is the bounded flexibility that still exists inside a constraint — not open-ended slack, and not a euphemism for "we don't really know."

Overstated:

"We've got some flexibility, it should be fine."

Bounded:

"We have about a week of wiggle room in the test schedule before the slip affects the release date. Past that, there's no wiggle room left — the date moves."

Useful phrases:

• "We have [amount] of wiggle room in [schedule/scope/budget] before [consequence]."
• "There's no wiggle room left on [item] — that one's fixed."
• "The wiggle room we have is in [specific area], not in [fixed area]."

Naming an amount — a week, two sprints, one review cycle — is what makes "wiggle room" useful instead of reassuring-sounding filler. It also sets up the next part of the update: what happens once that room runs out.

For more on how this differs from a formal reserve, see Wiggle Room vs Buffer: What's the Difference? and Wiggle Room vs Contingency: What's the Difference?.

Recommend a pivot only when the wiggle room is actually gone

"Pivot" means a deliberate change of direction made in response to evidence, while keeping something real from the original plan — not abandoning it, and not a euphemism for a minor adjustment.

Too vague:

"We might need to pivot."

Named and scoped:

"If the vendor slip goes past next Friday, I'd recommend pivoting to a phased launch: ship the core flow on the original date and hold the integration feature for two weeks after. We keep the launch date and the core scope — only the integration timing changes."

Useful phrases:

• "If [condition], I'd recommend pivoting to [specific alternative]."
• "The pivot would keep [what stays the same] and change [what changes]."
• "This isn't a full restart — it's a pivot on [specific dimension]."

A pivot recommendation needs a from and a to. "We might need to pivot" gives the committee nothing to approve. "Pivot to a phased launch, keeping the original date for the core flow" gives them an actual decision. Note also that "pivot" is not "pivotal" — a pivotal decision is simply a hugely important one; it says nothing about changing direction.

For that specific mix-up, see Pivot vs Pivotal: What's the Difference?, and for the difference between a genuine pivot and a full restart, see Pivot vs Abandon, Scrap, Start Over, or Transform.

A practical risk-update structure

Combine the four parts into one steering-committee-ready statement:

"The risk is [event and impact]. We're de-risking it by [concrete action]. We have [amount] of wiggle room before [consequence]. If that runs out, I'd recommend pivoting to [specific alternative], keeping [what stays] and changing [what changes]."

Example:

"The risk is the vendor's API change — if it slips past next Friday, our test window shrinks to three days. We're de-risking it by running against their staging environment starting this week, so we catch any break early. We have about a week of wiggle room before the slip forces a schedule change. If it goes past that, I'd recommend pivoting to a phased launch: ship the core flow on the original date and hold the integration feature two weeks."

This gives the sponsor a decision they can actually make now — approve the current plan and revisit only if the trigger condition happens — instead of an open-ended worry to carry into every future update.

A realistic steering-committee dialogue

Sponsor: How worried should I be about the vendor dependency?

Project manager: The risk is specific: if their API change slips past next Friday, our test window drops from two weeks to three days, and we'd be testing against an unstable target.

Sponsor: What are you doing about it now?

Project manager: We're de-risking it by starting integration tests against their staging environment this week, ahead of the real deadline, so we surface any break early instead of at the end.

Sponsor: And if it does slip?

Project manager: We have about a week of wiggle room in the schedule before that becomes a forced decision. If we run out of that room, I'd recommend pivoting to a phased launch — core flow ships on the original date, integration follows two weeks later. We keep the date and the core scope; only the integration timing moves.

Sponsor: That works. Let's revisit if you hit that trigger point.

The PM never claims the risk is gone, and never claims the plan is in danger without a named cause. Each answer maps to one part of the structure.

Common mistakes

Mistake 1: Announcing the risk without a response

Incomplete:

"There's a real risk with the vendor timeline."

Complete:

"There's a real risk with the vendor timeline, and here's what we're doing about it: [action]."

A named risk with no response forces the room to ask "so what are you doing about it?" — make that unnecessary.

Mistake 2: Saying "de-risking it" instead of naming the mechanism

Vague:

"We're de-risking the launch."

Specific:

"We're de-risking the launch by running a staged rollout to 5% of traffic before the full release."

"De-risking" without a stated action is closer to a feeling of caution than an actual step the committee can evaluate.

Mistake 3: Recommending a pivot with no from and to

Unusable:

"We might have to pivot if things don't improve."

Usable:

"If the vendor slip continues, I'd recommend pivoting from a single full release to a phased launch — same date for the core flow, integration two weeks later."

A pivot recommendation is a decision request. It needs a current direction, a new direction, and what carries over between them.

Practice scenarios

Practice communicating project risk in situations like:

• a steering committee update where a vendor dependency is at risk of slipping
• a sponsor conversation where "we're being careful" needs to become a named action
• a status report that needs to state exactly how much schedule room remains before a decision is forced
• a recommendation to change direction that needs a clear before-and-after, not just "we might pivot"

Useful practice phrases:

• "The risk is [event], and it would affect [impact]."
• "We're de-risking [the plan] by [concrete action]."
• "We have [amount] of wiggle room before [consequence]."
• "If that runs out, I'd recommend pivoting to [alternative], keeping [what stays]."

Lyra Practice gives project managers realistic risk-update and steering-committee scenarios, with feedback on whether the response actually answers the risk, not just names it.

A risk statement earns the room's trust when it comes with an action, a boundary, and a clear fallback — not when it sounds calm.

Return to English for Project Managers for more language on scope, dependencies, risk, and stakeholder alignment.

Lyra Practice helps advanced non-native English professionals learn the nuance of high-value workplace expressions and practice using them in realistic scenarios, so their English sounds natural, precise, and senior at work. Try Lyra Practice.