Skip to content

Lab 11 — Developing a Risk Register

At a glance

Learning objectives

By the end of this lab you should be able to:

  1. Write risk statements in cause–event–impact form.
  2. Score probability and impact against scales you define, and rank risks by expected exposure.
  3. Explain why expected exposure is the wrong basis for ranking some risks.
  4. Select a response strategy for each risk and identify residual and secondary risk.

Scenario

This lab uses the Hospital Appointment and Patient Portal scenario also used in Lab 05. The portal lets patients book, reschedule, and cancel outpatient appointments, with reminders sent by an external messaging vendor. Clinic staff see their schedules; the portal reads appointment data from the existing patient-record system.

The project is nine weeks into a twenty-week schedule. An initial risk workshop has produced the findings below. Every risk here is invented for teaching — it is a plausible set, not a record of a real project.

# Finding from the workshop
R1 The patient-record interface is specified by a third party. Its specification may change during our build, forcing rework of the integration.
R2 Clinic staff are delivering patient care alongside this project. Their availability for reviews may fall below plan, delaying sign-off of clinic scheduling behaviour.
R3 Hosting approval involves a separate governance process with its own queue. If it is granted late, launch is blocked entirely.
R4 The appointment rules are only partly documented. Requirements may continue to be discovered after build starts.
R5 Only one developer understands the reporting stack. If they are unavailable, reporting work stalls.
R6 Accessibility of the patient-facing booking screens may not meet the required standard, requiring redesign of the booking flow.
R7 The reminder messaging vendor may have an outage at launch, so no reminders are sent during the first week.
R8 Departments may keep adding appointment rules and exceptions faster than the team can deliver them.

Your role

You are the project manager. The register goes to the steering committee next week and must be good enough that each risk has a named owner and a next action — not merely a score.

Project information and assumptions

The scenario is part of the example-project library — read the full description there if you want the wider context.

Use these agreed scales. Do not invent different ones mid-lab; if you want to change them, state why.

Probability scale

Score Meaning
1 Unlikely — roughly one project in ten behaves this way
2 Possible — roughly one in five
3 Even — roughly one in two
4 Likely — roughly three in four
5 Near-certain — expected unless something changes

Impact scale (cost of the risk materialising, in PKR)

Score Financial impact Schedule impact
1 under 100,000 under 3 days
2 100,000 – 200,000 3 – 7 days
3 200,000 – 300,000 1 – 2 weeks
4 300,000 – 450,000 2 – 4 weeks
5 over 450,000 over 4 weeks, or launch blocked

Given probabilities and impacts, agreed with the team:

Risk Probability Impact
R1 40% 350,000
R2 70% 200,000
R3 25% 400,000
R4 60% 300,000
R5 30% 250,000
R6 45% 180,000
R7 20% 220,000
R8 65% 320,000

Additional constraints you must respect:

  • The launch date is fixed by a hospital board decision and cannot move.
  • The messaging vendor is under contract; changing vendor is not an option inside this project.
  • The security and hosting approval processes are owned by others; you may request, not direct.
  • Two developers are available to respond to risks without stopping build work.

Tasks

Task 1 — Rewrite every risk in cause–event–impact form

Take all eight findings and rewrite each as:

Because ‹cause›, there is a risk that ‹event›, which would result in ‹impact›.

Do not simply reword the finding. The impact clause must state a consequence you could observe, and where possible the impact should match the impact score in the scale table.

Task 2 — Calculate expected exposure and rank

Calculate exposure as probability × impact for each risk, then rank the register by exposure.

Present the results as a table, highest exposure first, and state the total expected exposure for the project.

Task 3 — Override the ranking, with reasons

At least one risk has a lower exposure score than another but should be ranked more urgently. Identify it, and explain in two or three sentences why expected-value ranking misleads in this case.

Then state the rule you would apply in future to catch this class of risk.

Task 4 — Choose responses

For each of the eight risks, record:

Field Content
Strategy Avoid, transfer, mitigate, or accept (threats); exploit, share, enhance, or accept (opportunities)
Response The specific action, not the category
Owner A role, not a name — and a role that can actually act
Cost The cost of the response, in person-days or money
Trigger The observable early warning that the risk is materialising
Fallback What you do if the response fails

At least one risk must be genuinely accepted, with a written justification. At least one must be transferred, and you must name what is actually transferred — because "the vendor handles it" is not an answer if the consequence still lands on the hospital.

Task 5 — Find the secondary risk

At least two of your responses create a new risk that did not exist before. Identify them and write each as a new register row. Then state which response you would still choose despite the secondary risk, and why.

Task 6 — Recalculate residual exposure

For each risk, estimate the residual probability and impact after your response is applied, and recalculate residual exposure. Then state:

  1. The reduction in total expected exposure achieved.
  2. The total cost of your responses.
  3. Whether the responses are worth their cost — with the arithmetic.

Task 7 — Turn the register into a weekly instrument

A register is only useful if it changes decisions each week. Write a short section describing:

  1. How each risk's trigger will be checked, by whom, and how often.
  2. What happens when a trigger fires.
  3. Which two risks you would report to the steering committee every week, and why those two.

Deliverable

  1. Eight risk statements in cause–event–impact form.
  2. An exposure table, ranked, with the total.
  3. The ranking override with justification and a general rule.
  4. Eight response plans, each with strategy, action, owner, cost, trigger, and fallback.
  5. At least two secondary risks as new rows.
  6. A residual exposure table with the reduction, the response cost, and the verdict.
  7. The weekly operating section.

Hints and guidance

  • A risk statement names a cause, or it cannot be managed. "Integration risk" tells you nothing; "the specification is owned by a third party" tells you who to talk to.
  • Impact must be observable. If you cannot describe what you would see, the score is a guess.
  • Exposure is arithmetic, not judgement — the judgement comes in overriding it.
  • A trigger must be observable and early. "We will notice" is not a trigger.
  • Accept is a real strategy. It must be recorded, with a reason, or its occurrence becomes a surprise rather than a plan.

Self-check criteria

Check How to verify it
All eight risks rewritten with all three clauses Count the "because", "there is a risk that", and "which would result in" phrases
Exposure arithmetic correct probability × impact, and the total equals the sum of the column
Ranking override justified by consequence, not preference The reason refers to irreversibility, not to how much you dislike the risk
Every risk has an owner role that can act No owner is "the project" or "the team"
Triggers are observable Each could be checked by someone with no context
One risk is genuinely accepted With a written justification, not a silent omission
Transfer names what moved The consequence, not the activity
Residual arithmetic shown Reduction and response cost both stated, with a verdict

Reflection

  1. Which risk did you find hardest to write in three-part form, and what did the difficulty reveal?
  2. Total expected exposure is a single number. What does it hide, and why should the committee not manage against it alone?
  3. Suppose R3 materialises despite your early response. What is your fallback, and who owns it?
  4. R8 is a scope risk. Should it be in the risk register at all, or is it really a scope-control problem? Justify your position and say what you would do about it either way.
Check your exposures

Expected exposure = probability × impact.

Risk Calculation Exposure (PKR)
R8 0.65 × 320,000 208,000
R4 0.60 × 300,000 180,000
R1 0.40 × 350,000 140,000
R2 0.70 × 200,000 140,000
R3 0.25 × 400,000 100,000
R6 0.45 × 180,000 81,000
R5 0.30 × 250,000 75,000
R7 0.20 × 220,000 44,000
Total 968,000

The override in Task 3 is R3: exposure 100,000, ranked fifth, but its occurrence blocks launch absolutely and cannot be recovered by working harder. Irreversibility, not probability, drives its priority. Full working is in the Intermediate labs answer key.

Extension challenge

Convert your register into a risk-adjusted budget: for each risk, state the amount you would hold as contingency, distinguishing (a) expected exposure, (b) the cost of the response, and (c) the cost if the risk materialises and the response fails. Then answer: what is the total contingency you would ask the steering committee to hold, and how much of it is under your control versus the sponsor's? Explain the difference between contingency and management reserve using your own numbers.