Contingent Response Strategies

Risk technique · See it on the map

Runnable here

A backup plan held in reserve and used only if a specific, named event actually happens.

When to use it

For a risk you've chosen to actively accept: you're not spending money now to reduce it, but you want a plan ready to go if it does happen, so the response isn't improvised under pressure.

When to avoid it

When the response would be the same whether or not the trigger is watched for — if the team would do the obvious thing regardless, writing it down as a formal contingent plan adds process without adding readiness. Also avoid this for a risk important enough to warrant real mitigation now; a contingency plan is not a substitute for reducing the risk in the first place.

Steps

1. Pick the risk being actively accepted, and confirm a mitigate-now response genuinely isn't the better choice.
2. Define the trigger precisely — an observable, checkable condition, not a feeling. 'Vendor delivery slips more than 10 business days past the contracted date' is a trigger; 'if things start looking bad' is not.
3. Write the response that activates once the trigger fires — what happens, who does it, and with what resources.
4. Assign someone to actually watch for the trigger; a trigger nobody is watching for never fires on time.
5. Hold the contingency reserve (budget, schedule slack, or people) the response will need, so it exists when the trigger does occur.

What it produces

• A written trigger condition, precise enough that two people would agree whether it has occurred.
• A predefined response tied to that trigger.
• An assigned watcher and a reserved contingency (time, budget, or capacity) the response can draw on.

Common pitfalls

• Writing a contingency plan with no defined trigger condition at all — the single most common failure of this technique. Without a trigger, the plan is a document sitting in the register, not a response: nobody knows when to act on it, so in practice nobody does, and the 'accept' the team thought was active turns out to have been passive all along.
• Setting a trigger so vague ('if the schedule looks tight') that it's really a judgment call dressed up as a trigger, which defeats the purpose of defining one in advance.
• Reserving the contingency budget on paper but letting it get absorbed into general spend before the trigger ever fires.

Worked example

A software team accepts the risk that a third-party payments API might deprecate an endpoint mid-project, judging the probability too low to justify rework now. The contingent plan: trigger is 'the vendor posts a deprecation notice with a sunset date inside the project's remaining timeline'; response is 'the two engineers already familiar with the integration switch to the documented replacement endpoint within the sunset window'; the reserve is one week of those two engineers' time, held out of the schedule rather than committed to other work.

Source

• PMBOK-6 §11.5.2.6

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