Practicing the practices II: risk, issues and progress

Risk, issues and progress are the practices that handle uncertainty, change and control. They generate more scenario questions than any other part of the method, because almost every situation in a project raises the same three questions: is this something that might happen or something that has happened, who is allowed to decide what to do about it, and does it threaten a tolerance? This lesson revises the three practices and then works through original practice questions, including a long scenario sequence on Ridgeline's lead service line replacement, where Ana practiced routing events correctly under time pressure.

Risk: revision points

Issues: revision points

Progress: revision points

One routing rule underlies most scenario questions in these practices. A forecast breach of work package tolerance goes from the team manager to the project manager as an issue. A forecast breach of stage tolerance goes from the project manager to the board as an exception report. A forecast breach of project tolerance goes from the board to the business layer. Each level manages within its tolerance and escalates only when a tolerance is forecast to be exceeded.

Foundation-style practice

Practitioner-style practice: the lead service line replacement

Scenario extract. Ridgeline Water's lead service line replacement (6.2 million) is replacing about 1,700 lead lines found by the pilot. The board has delegated change authority to a change control group for changes up to 50 thousand each, from a change budget of 300 thousand. Stage 4 has cost tolerance of plus or minus 120 thousand and zero time tolerance on the regulator's compliance milestone. The project manager is Ana's colleague, Marcus Hale. During stage 4 the following events occur.

The compliance milestone comes from the federal Lead and Copper Rule Improvements, under which systems must replace lead service lines over roughly a decade, with compliance requirements beginning in November 2027. Zero time tolerance on that milestone means any forecast slip is escalated immediately.

A matching question on progress products

Forecasting against tolerance

Practitioner questions often describe a forecast and ask whether escalation is needed. The program below checks a stage forecast against cost and time tolerances, showing that both must be checked: a stage can be within cost tolerance and still require an exception report because of time.

stage_budget, cost_tol = 1_450_000, 120_000      # invented stage 4 figures
milestone_week, time_tol = 30, 0
forecasts = [
    ("after copper line finds", 1_405_000, 30),
    ("after back-order risk response", 1_430_000, 30),
    ("after failed pressure tests", 1_520_000, 32),
]
for label, cost, week in forecasts:
    cost_ok = abs(cost - stage_budget) <= cost_tol
    time_ok = week - milestone_week <= time_tol
    action = "manage within the stage" if cost_ok and time_ok else "exception report to the board"
    print(f"{label:<32} cost {cost - stage_budget:+,} ({'ok' if cost_ok else 'over'}), "
          f"milestone week {week} ({'ok' if time_ok else 'late'}): {action}")

after copper line finds          cost -45,000 (ok), milestone week 30 (ok): manage within the stage
after back-order risk response   cost -20,000 (ok), milestone week 30 (ok): manage within the stage
after failed pressure tests      cost +70,000 (ok), milestone week 32 (late): exception report to the board

The third forecast is within cost tolerance, at 70 thousand over budget against a tolerance of 120 thousand, but two weeks late on a milestone with zero time tolerance. The correct answer in an exam would therefore be an exception report, and an option saying 'no escalation, because cost is within tolerance' would be a distractor.

Risk management questions in depth

Risk questions often test the difference between the cause, the event and the effect of a risk. A well-described risk states all three: because of a cause, an uncertain event may occur, which would lead to an effect on objectives. 'Fittings may be back-ordered' is the event; 'the supplier's factory is changing production lines' is the cause; 'crews would stand idle and the compliance milestone could slip' is the effect. Exam options that describe only a cause or only an effect as 'the risk' are often distractors, especially in questions that ask how a risk should be recorded in the register.

Questions also test proximity, probability and impact, and the roles of risk owner and risk actionee. The owner is responsible for managing the risk and monitoring its responses; the actionee carries out a specific response on the owner's behalf. In the lead line project, the procurement lead might own the back-order risk, while a buyer acts as actionee for the response of placing an early order with a second supplier.

Finally, risk appetite and risk tolerance are tested more often in PRINCE2 7 than in earlier editions. Appetite describes how much risk the organization is willing to accept in pursuit of its objectives; tolerance sets the thresholds that trigger escalation for the project. A utility that will accept almost no risk to drinking water quality but more risk to schedule has a low appetite for quality risk and a higher appetite for time risk, and its risk management approach should reflect that.

Progress reporting in agile and hybrid projects

Progress questions on agile and hybrid projects test tailored reporting. A burn-up chart or release dashboard can serve as the highlight report if it shows the information the board needs: progress against the plan, forecasts against tolerances, issues and risks. Sprint reviews can provide checkpoint information from the team to the project manager. What cannot be tailored away is the board's ability to see whether tolerances are threatened and to decide at stage boundaries. An option claiming that agile teams need no progress reporting to the board because they demonstrate working software each sprint is a distractor.

Tolerances on agile projects are often expressed differently too. Time and cost may have zero tolerance because release dates and budgets are fixed, while scope has tolerance expressed by priority: must-have features are required, and lower-priority features may be dropped. A forecast that some could-have features will not be delivered is therefore within tolerance, while a forecast that a must-have will be missed is not.