Strategies for Threats

Risk technique · See it on the map

Runnable here

Choosing a deliberate response to a risk that would hurt the project if it happened.

When to use it

For every threat (a risk with a negative effect on the project) once it's scored highly enough to warrant a response beyond just watching it. This is the mirror image of strategies for opportunities, below — same decision structure, aimed at downside instead of upside.

When to avoid it

Don't force a formal strategy choice onto a risk so low in exposure that 'accept, revisit later' is obviously correct and would only be dressed up by a longer discussion. Also don't default every threat to 'mitigate' without considering avoid or transfer — mitigate is the comfortable middle choice and it's easy to reach for out of habit rather than fit.

Steps

1. For the threat, ask whether the triggering activity can be eliminated entirely — that's avoid, and it's the strongest response when it's on the table.
2. If it can't be eliminated, ask whether its probability or impact can be reduced — that's mitigate, the most common response and the one Driftless defaults a new risk to.
3. Ask whether the consequence can be shifted to someone better placed to bear it — insurance, a contract clause, a fixed-price subcontract — that's transfer.
4. If none of the above is worth its cost relative to the exposure, choose accept, and decide whether that's passive (do nothing, absorb it if it happens) or active (set aside contingency, define a fallback).
5. Record the chosen response and the owner responsible for carrying it out.

What it produces

• One response strategy recorded per threat (matches the four ``RISK_RESPONSES`` values Driftless stores: avoid, mitigate, transfer, accept).
• An owner assigned to carry the response out.
• For an actively accepted threat, a contingency reserve or fallback plan — which is where contingent response strategies pick up.

Common pitfalls

• Choosing 'mitigate' reflexively because it feels like the responsible middle ground, when avoid or transfer would remove the exposure entirely for similar cost.
• Recording 'accept' without distinguishing passive from active acceptance, so a risk everyone assumed had a contingency plan turns out to have none.
• Picking a strategy once at register creation and never revisiting it as the risk's probability or impact changes over the project.

Worked example

A single-source component supplier is the sole vendor for a custom connector on a robotics build. The PM can't avoid the dependency (no second supplier exists) but negotiates a penalty clause for late delivery (transfer) and, separately, qualifies a slower backup part that could substitute if the primary slips more than three weeks (an active-acceptance fallback).

Source

• PMBOK-6 §11.5.2.4

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.