8.3 Risk: Threats & Opportunities
Key Takeaways
- The Risk practice identifies, assesses, and controls uncertainties that could affect project objectives; PRINCE2 v7 treats both threats (negative) and opportunities (positive) as first-class risks.
- A risk is decomposed into cause (the source of uncertainty), risk event (the threat or opportunity itself), and effect (the impact on objectives) — this decomposition is central to scenario analysis.
- The Risk Management Approach (in the PID) defines how risk is managed, including categories, tolerance, roles, and reporting; the Project Board approves it and the PM produces it.
- Risk is evaluated using probability × impact, alongside proximity and tolerance; a risk budget funds agreed responses, distinct from a general contingency.
Risk Is Two-Sided
A persistent beginner's misconception is that 'risk' means 'bad thing that might happen'. PRINCE2 v7 is explicit that risk is two-sided: a threat is an uncertain event that, if it occurs, would have a negative impact on objectives, while an opportunity is an uncertain event that, if it occurs, would have a positive impact. Both are risks because both arise from uncertainty and both affect whether the project meets its objectives. A scenario that asks you to identify whether a described uncertainty is a threat or an opportunity is testing this single concept.
Treating opportunities as risks is not a theoretical nicety. A project that only plans for threats will systematically miss the upside — the chance to deliver early, to reduce scope cost-effectively, or to capture additional value. The Risk practice therefore applies the same discipline to both: identify, assess, plan responses, implement, and communicate.
Cause, Event, Effect
PRINCE2 analyses every risk as a three-part chain:
| Element | Meaning | Example |
|---|---|---|
| Cause | The source or condition that gives rise to the uncertainty | 'The supplier is using an unfamiliar technology stack' |
| Risk event | The uncertain occurrence itself — the threat or opportunity | 'The team may take longer than estimated to learn the stack' (threat) or 'The team may discover reusable components that accelerate delivery' (opportunity) |
| Effect | The impact on one or more project objectives if the event occurs | 'Delivery slips by three weeks and costs rise by 8%' or 'Delivery accelerates by two weeks and costs fall by 5%' |
Decomposing a risk this way is not pedantry — it is the foundation for choosing a useful response. You cannot avoid an effect, you can only intervene in the cause or the event. A response that targets the wrong element will fail. Scenario questions frequently describe an effect and ask which cause or event produced it, or describe a cause and ask which risk event flows from it; the cause-event-effect chain is the tool for answering them.
Assessing Risk
Risks are assessed using a combination of factors:
- Probability (sometimes called likelihood) — how likely the event is to occur, typically on a scale such as high/medium/low or a percentage.
- Impact (sometimes called consequence) — the magnitude of the effect on objectives, often expressed on a monetary, schedule, or qualitative scale.
- The combined probability × impact (the expected value) is a common ranking measure, but it is not the whole picture.
- Proximity — how soon the risk could materialise. A high-proximity risk demands attention now; a low-proximity risk can be monitored.
- Risk tolerance — the threshold of risk the project is willing to bear without a planned response, defined in the Risk Management Approach.
A common exam trap is to assume that the highest probability × impact risk is automatically the top priority. Proximity matters: a moderately scored risk that could occur next week often outranks a slightly higher-scored risk that cannot occur for six months.
Risk Management Approach and Register
The Risk Management Approach is produced by the Project Manager during initiation, included in the PID, and approved by the Project Board. It defines how risk will be managed across the project: the risk categories to be considered (e.g. commercial, technical, operational), the risk tolerance above which a response is mandatory, the roles (Risk Owner, Risk Actionee), the reporting frequency and format, and the techniques to be used for identification and assessment. Producing it is the PM's job; approving it is the board's.
The Risk Register records each identified risk with its cause, event, effect, category, probability, impact, proximity, owner, response, and status. In PRINCE2 v7, the Risk Register is consolidated into the Project Log alongside issues, lessons, and quality checks. The function is unchanged — a single, queryable record of all project risks — but the container has been unified.
Risk Budget vs Contingency
A risk budget is a sum set aside to fund agreed risk responses — it is part of the planned cost of managing risk, not a slush fund. A contingency (sometimes called a contingency reserve) is a buffer held by the Project Board or PM for risks that materialise but were not explicitly planned for. Confusing the two is a frequent exam error. Drawing on the risk budget implies a previously agreed response is being implemented; drawing on contingency implies an unplanned event is being absorbed within tolerance.
Who Owns What
- Project Manager produces the Risk Management Approach and is accountable for the day-to-day management of risk on the project.
- Project Board approves the Risk Management Approach and owns the project-level risk tolerance; it is also the escalation point for risks beyond PM tolerance.
- Risk Owner is the person assigned to manage a specific risk — typically because they have the authority or expertise to influence its causes or responses.
- Risk Actionee is the person who carries out the agreed response action on behalf of the Risk Owner. The two roles may be the same person, but they need not be.
Exam Scenario Patterns
- Threat vs opportunity. If the scenario describes a possibility of gaining time, cost, or benefit, it is an opportunity; if it describes losing them, it is a threat.
- Cause/event/effect. Match each fragment of a scenario to the correct element before reading the question. The cause is the source; the event is the uncertain occurrence; the effect is the consequence on objectives.
- Risk Management Approach ownership. The PM produces it; the board approves it. This pairing is one of the most heavily tested in the Risk practice.
A scenario states: 'Because the vendor is using a new framework the team has not used before, the team may take longer than planned to become productive, which could delay the first release by two weeks.' Which part is the risk event?
Who is responsible for producing the Risk Management Approach, and who approves it as part of the Project Initiation Documentation?