How to explain a risk to stakeholders clearly

Do not make a risk sound more serious by making it sound more certain.

First: risk or issue?

A risk is something that might happen. An issue is already happening.

Risk:

If the vendor confirmation does not arrive by Thursday noon, Friday's cutover window is at risk. We can keep the window only if we receive it before that checkpoint.

Issue:

The vendor confirmation did not arrive, so Friday's cutover window is no longer achievable. We are checking the next available slot now.

The distinction matters because the listener's options are different.

Weak and better versions

Weak:

We have some concerns around the cutover because the vendor has been slow to respond and there are still a few things we need to confirm. It could potentially affect Friday.

This sounds cautious but gives the listener little to do.

Better:

Friday's cutover is at risk if the vendor confirmation is not in by Thursday noon. If it misses that checkpoint, we need to move to the next slot. I need the escalation owner confirmed today.

The second version exposes the event, trigger, consequence and decision.

Give the listener a job

Before speaking, decide which situation is true.

Listener need	Make this explicit
Awareness only	What might happen and what you are watching.
Mitigation choice	The action, cost or trade-off.
Decision	What must be decided and by when.
Escalation	Why the current team cannot contain the impact alone.
No action yet	What evidence or event will trigger the next update.

A risk update without a trigger or decision often becomes a recital of concern.

A practical structure

Use the parts you need:

1. Risk: what might happen?
2. Impact: what would it affect?
3. Trigger or evidence: what would make the risk more or less real?
4. Mitigation: what can reduce the impact or likelihood?
5. Decision: what does the listener need to choose or approve?

Do not force a percentage into the update unless you have a defensible basis for it.

We do not have a reliable probability yet. Thursday's load test will tell us whether the current capacity assumption still holds.

can be more useful than an unsupported “70% chance.”

Practice it out loud

Use a real non-confidential risk, or use this scenario:

Scenario: Friday's deployment depends on a vendor confirmation arriving by Thursday noon. It has not arrived yet. If the checkpoint is missed, the deployment must move. The team can escalate today.

Take A

Answer naturally:

“What is the main risk to Friday?”

Do not script the response.

Listen

Notice:

• Can you hear what might happen?
• Is the consequence separate from the possibility?
• Is there a concrete trigger or checkpoint?
• Does the listener know whether they need to act?

Change one thing

For Take B, make one change only:

Add the trigger that turns concern into action.

Keep everything else as natural as possible.

Take B

Answer again.

Do not make the risk sound certain just because the sentence becomes more direct.

Compare

Ask:

• Which take makes it easier to know when action is required?
• Did Take B preserve the distinction between “might happen” and “has happened”?

Transfer

Now switch scenarios:

A performance test next Wednesday will determine whether the current infrastructure can support launch traffic. If it fails, the team must either reduce launch scope or add capacity work.

Explain the risk to a product lead.

The transferable skill is not a memorized risk sentence. It is making possibility, consequence and action trigger visible in a new situation.

Common mistakes

Calling an issue a risk. Once the event happened, the conversation should move to impact and recovery.

Using “risk” without a consequence. The label alone does not tell the listener why it matters.

Inventing probability precision. A percentage without a defensible source can make uncertainty look measured when it is not.

Dumping the risk register. One spoken update should foreground the risk that changes the current decision.

Escalating emotion instead of options. “This is very serious” is less useful than the condition, impact and action the listener controls.

Where this advice breaks

Some formal risk processes require documented probability, severity, controls or governance fields. This spoken structure does not replace those records.

And not every risk needs escalation. If no action is possible yet, the useful ending may simply be the next evidence or checkpoint.

Continue with Ptichi

Record one real risk explanation. Listen for whether the possibility, consequence and action trigger are recoverable. Change one missing part and try again, then transfer the same structure to a different risk.

The pre-meeting rehearsal supports the same short loop. Ptichi is being developed around practising real messages, comparing attempts and changing one thing at a time rather than generating a generic confidence score. An ordinary recorder works for this exercise while the desktop product remains in development.