3.3 Scenario Practice for 7 PRINCE2 Practices

Risk — Managing Uncertainty

The Risk practice identifies, assesses, and controls uncertainties that could affect objectives. A risk is either a threat (negative) or an opportunity (positive). PRINCE2 7 recommends describing risks in cause–event–effect form: the cause is the source, the event is the uncertain occurrence, and the effect is the impact on objectives.

The practice owns two key products: the Risk Management Approach (a PID section defining procedures, roles, and the risk budget) and the Risk Register (which logs each risk's probability, impact, proximity, owner, and chosen response). Distinguish a risk owner (manages the risk overall) from a risk action owner (carries out a specific response).

Risk Responses (a Classic Scenario Trap)

Responses depend on whether the risk is a threat or an opportunity. Mixing them is a frequent exam trap.

The risk appetite is the organisation's tolerance for risk; risk tolerance sets the threshold at which a risk must be escalated. A risk forecast to breach tolerance is escalated to the Project Board, often via an Exception Report.

Issues — Controlling Change to the Baseline

The Issues practice (called Change in the 6th edition) captures and assesses anything that needs management attention and controls changes to the project's baselined products. Every event is logged either in the Daily Log (minor, informal) or the Issue Register (formal). The Issue Management Approach defines the procedure, and the change authority plus a change budget handle approved changes within delegated limits.

The Three Issue Types

PRINCE2 forces every formal issue into exactly one of three types — a favourite scenario question:

1. Request for change — a proposal to alter a baselined product (e.g., the customer wants an extra feature).
2. Off-specification — a product that does not, or is forecast not to, meet its acceptance criteria (a missing or below-standard requirement).
3. Problem or concern — any other issue the Project Manager must resolve or escalate.

Scenario tip: if a customer asks for something new, it is a request for change; if a product fails to meet what was already agreed, it is an off-specification. Candidates routinely confuse these.

Change Control Flow

Notice the assessment step explicitly checks the Business Case and risk — the practices are interdependent.

Working a Risk Scenario

Foundation scenarios often hand you a sentence and ask for the right term. Practise decomposing into cause, event, effect. Example: "Because a key supplier is short-staffed (cause), there is a chance the test environment will be delivered late (event), which would delay user acceptance testing (effect)." This is a threat. A suitable response might be to reduce it (add a second supplier) or transfer it (a penalty clause). Choosing exploit here would be wrong — that response only applies to opportunities.

The risk owner is accountable for managing the risk; the risk action owner carries out the agreed action. The risk budget is a sum set aside specifically to fund risk responses, distinct from the change budget, which funds approved changes under the Issues practice. Confusing those two budgets is a common distractor.

Working an Issue Scenario

Apply a simple decision tree when an event arises:

1. Is it minor and informal? → Record in the Daily Log; the Project Manager handles it.
2. Is it formal? → Record in the Issue Register and classify it.
3. Classify the formal issue:
   • Someone wants something new or different → request for change.
   • A product will not meet its agreed acceptance criteria → off-specification.
   • Anything else the Project Manager must act on → problem/concern.

Severity and Escalation

Not every issue goes to the Project Board. Within delegated change authority limits and the change budget, the Project Manager (or a delegated change authority) can approve minor changes. Only when an issue is forecast to push a stage or the project beyond tolerance does it become an exception requiring board escalation — the same manage-by-exception logic used in the Progress practice. This is why the Risk, Issues, and Progress practices are frequently tested together: they share the escalation mechanism.

One more scenario distinction worth drilling: a risk is something that might happen (an uncertainty), whereas an issue is something that has happened or is certain to happen and now needs managing. If a scenario says "there is a chance that...", it is a risk for the Risk Register; if it says "the supplier has gone bankrupt" or "the customer has formally requested...", it is an issue for the Issue Register. A risk that actually materialises is said to have occurred, at which point it is typically raised as an issue and managed through change control.