Strategies for Opportunities

Risk technique · See it on the map

Runnable here

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

When to use it

For any identified risk with a positive effect: a chance to finish early, spend less, or exceed a requirement. Use it in the same pass as threat response planning, not as an afterthought — a risk register that only ever lists things that could go wrong is only doing half the job.

When to avoid it

This is the strategy set most teams skip entirely, not because it's wrong for their project but because nobody asked the question. If you genuinely have no upside risks — every identified risk in the register is a pure threat — don't force one in to look complete. But check that assumption before accepting it; opportunities are systematically under-reported because 'this might go well' doesn't feel urgent enough to write down.

Steps

1. For the opportunity, ask whether you can make the favorable outcome certain — that's exploit, the upside mirror of avoid, and the strongest response when you can pull it off (e.g., assigning your best resource to guarantee an early finish rather than hoping for one).
2. If it can't be made certain, ask whether its probability or positive impact can be increased — that's enhance, the mirror of mitigate.
3. Ask whether a third party is better placed to capture the upside and share the benefit — that's share, the mirror of transfer (a teaming arrangement or joint venture is the classic form).
4. If none of the above is worth pursuing actively, accept — take the upside if it happens, without spending effort chasing it.
5. Record the chosen strategy and the owner responsible for pursuing it, the same way a threat response is recorded.

What it produces

• One response strategy recorded per opportunity — Driftless has no separate opportunity-response vocabulary; the four ``RISK_RESPONSES`` values (avoid, mitigate, transfer, accept) are threat-shaped and don't literally spell exploit/enhance/share/accept, so record the opportunity strategy in the risk's description or notes rather than expecting a dedicated field.
• An owner assigned to pursue the opportunity.

Common pitfalls

• Never identifying opportunities in the first place — the single most common failure mode for this technique, and the reason it's worth a deliberate prompt during identification rather than assuming they'll surface on their own.
• Treating 'accept' as the default for an opportunity the way it's often the safe default for a threat, when a modest investment in exploit or enhance might have captured real value.
• Trying to force the opportunity's response into a field literally named for threat responses and getting confused when 'exploit' doesn't fit — see the outputs note above.

Worked example

On the same robotics build, the team notices that if the connector qualification finishes early, a full week opens up before the next hardware milestone. Rather than leaving that as a passive hope, the PM enhances the opportunity by front-loading the connector team with an extra engineer for the first week, raising the odds of finishing early enough to use the slack on integration testing instead.

Source

• PMBOK-6 §11.5.2.5

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