The risk practice I: the approach and identifying risks

Every plan is a forecast, and every forecast rests on assumptions that may turn out to be wrong. The risk practice exists to identify, assess and control uncertainty so that the project is more likely to succeed. This lesson covers what PRINCE2 means by risk, the risk management approach that sets the rules for a project, how risk appetite and risk tolerance shape those rules, and the first step of the risk management procedure: identifying risks and recording them well. Lesson 4 covers assessing, planning, implementing and communicating.

What a risk is

In PRINCE2, a risk is an uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives. Two features of this definition matter. First, a risk has not happened yet; once it has happened it is an issue, handled by the issues practice. Second, the effect can be negative or positive. A risk with a negative effect is a threat; a risk with a positive effect is an opportunity. Many projects manage only threats, which means they quietly give up the chance to finish early, cheaper or with more benefit than planned.

Writing a risk well: cause, event, effect

A risk description that reads simply 'supplier' or 'budget overrun' cannot be managed, because nobody can tell what might happen or why. PRINCE2 guidance recommends describing each risk in three parts: the cause, which is a definite fact or situation that gives rise to the uncertainty; the event, which is the uncertain thing that might happen; and the effect, which is the impact on objectives if it does. A useful pattern is: because of a cause, an event may occur, which would lead to an effect.

Separating the three parts helps later. Responses aimed at the cause tend to reduce probability; responses aimed at the effect tend to reduce impact. Assessors can estimate probability for the event and impact for the effect. And the same cause can produce several risks, which is useful when many risks share a root, such as an aging billing system.

The risk management approach

During initiation the project manager prepares a risk management approach, which describes how risk management will be carried out on this project. It sits in the project initiation documentation and is approved by the board. It should reflect any corporate risk policy, the board's risk appetite and the nature of the project. A small internal project might have a page; a large public infrastructure project might have a substantial document aligned with an organizational risk framework.

Risk appetite and risk tolerance

Risk appetite is an organization's unique attitude toward risk taking: broadly, how much uncertainty it is prepared to accept in pursuit of its objectives. A start-up developing a new product may have a large appetite; a water utility responsible for public health has a small appetite for anything that affects water quality but may accept more risk in its customer service systems. Risk tolerance turns appetite into thresholds: the level of risk exposure which, if exceeded, triggers an escalation. Risk tolerance is one of the performance targets on which the business layer and board set tolerances, alongside time, cost, scope, quality, benefits and sustainability.

Roles: risk owner and risk actionee

Each risk in the register should have a risk owner: a named individual responsible for managing it, including monitoring triggers and making sure responses are carried out. Where a response involves specific actions, these may be assigned to a risk actionee, who carries out the actions under the owner's direction. The owner is chosen for being best placed to manage the risk, not for seniority or convenience. A risk that belongs to everyone is managed by no one.

Identifying risks

The risk management procedure begins with identification, which has two parts. First, identify the context: the objectives at risk, the scope of risk management, the stakeholders and their appetite, and any relevant corporate rules. Much of this is captured in the risk management approach. Second, identify the risks themselves, recording each as cause, event and effect, along with early warning indicators where possible. Identification is not a one-off workshop in initiation: new risks appear throughout the project, and the board should expect to see the register change at every stage boundary.

Ridgeline Water's project manager combines several techniques at the start of the pilot stage: a review of lessons from another utility's metering project, an assumptions analysis of the business case, and a two-hour workshop with the board members, team managers and a representative of the customer contact center. The workshop uses a simple risk breakdown structure as its agenda, so that every source of risk gets attention.

The risk register

Identified risks are recorded in the risk register, which in PRINCE2 7 is part of the project log. A register entry typically includes an identifier, the author and date, the category, the description as cause, event and effect, the probability, impact and expected value, proximity, the response category and actions, the risk owner and actionee, and the current status. The register is a working tool for the project manager and owners, not a document to impress the board. Its usefulness depends on keeping descriptions specific and statuses current.

The code below takes a draft register and checks two quality points that assurance often finds lacking: whether each description contains a cause, an event and an effect, using the 'because ... may ... leading to' pattern, and whether each risk has a named owner. It then counts risks by source in the risk breakdown structure to show where they concentrate.

import re
from collections import Counter
risks = [
    ("R1", "supplier", "Because the supplier has one factory, pilot meters may arrive late, leading to a later start of installation", "senior supplier"),
    ("R2", "customer", "Customers ignore alerts", ""),
    ("R3", "technology", "Because the billing system is old, the interface may take longer, leading to schedule overrun", "project manager"),
    ("R4", "technology", "Because hills block radio signals, coverage may fall below 98 %, leading to more estimated bills", "senior supplier"),
    ("R5", "funding", "Because a subsidy program is under review, a grant may be announced, leading to lower net cost", "executive"),
    ("R6", "technology", "Head-end vendor risk", "IT manager"),
    ("R7", "customer", "Because some homes have meters in flooded pits, installers may be unable to fit meters, leading to scope shortfall", ""),
]
pattern = re.compile(r"because .+ may .+ leading to .+", re.I)
for rid, src, text, owner in risks:
    problems = []
    if not pattern.search(text):
        problems.append("not cause-event-effect")
    if not owner:
        problems.append("no owner")
    print(f"{rid}: {'ok' if not problems else '; '.join(problems)}")
print("risks by source:", dict(Counter(r[1] for r in risks)))

R1: ok
R2: not cause-event-effect; no owner
R3: ok
R4: ok
R5: ok
R6: not cause-event-effect
R7: no owner
risks by source: {'supplier': 1, 'customer': 2, 'technology': 3, 'funding': 1}

Four of the seven entries pass. R2 and R6 are vague labels rather than risks, and R2 and R7 have no owner. The count by source shows three technology risks, two customer risks and one each for supplier and funding. The concentration in technology is not surprising for a metering project, but the absence of any risk in categories such as legal, privacy or people suggests the workshop may have missed whole areas; the project manager might revisit the prompt list before the register is presented to the board.