Skip to content

Lesson 4 — Advanced Risk Management

At a glance

Learning objectives

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

  1. Identify risks that are correlated through a shared cause, and explain why a register of individually scored risks understates exposure.
  2. Distinguish primary, secondary, and residual risk, and give an example of a response that creates the risk it was meant to avoid.
  3. Reason about risk at the level above one project: concentration, single points of failure, and shared suppliers.
  4. Use expected value and ranges to size a reserve, and state honestly what a simulation does and does not add.
  5. Distinguish risk appetite from risk tolerance, and say who owns each.
  6. Recognise the limits of risk management: unreliable probabilities for novel events, registers used as compliance evidence, and risks that are really unfunded obligations.

Prerequisites

  • Module 08 Lesson 1 — the risk register, the 1–3 scoring scale, and the five response strategies.
  • Module 07 Lesson 2 — three-point estimates and why a range is more honest than a single figure.

Introduction

The core course teaches risk management on one project with one register. That is the right place to start, and it leaves three gaps that show up on larger or longer work:

  1. Risks are treated as independent. In practice they share causes, and the shared cause is often the thing that matters.
  2. The response is assumed to be free of consequences. Most responses create new risk, and the new risk is rarely registered.
  3. Exposure is assessed one project at a time. An organisation can have three green projects that fail together because they depend on the same supplier, the same specialist, or the same assumption.

This lesson closes those gaps, and then states what risk management genuinely cannot do — because the commonest failure is not a missing risk, it is a register that creates confidence disproportionate to the knowledge behind it.

1. Correlated risk: the portfolio view of one project

A register scores risks one row at a time, which implicitly assumes they are independent. Two consequences follow.

Expected values add; variability does not cancel. For a reserve, expected values are added across risks, which is arithmetically fine. But the useful question is different: which risks would occur together? If four risks all depend on the security review queue, then the queue being slow does not produce four moderate impacts — it produces one large one.

Common causes deserve their own row. When several risks share a cause, the cause is the risk to manage:

Individual risks Shared cause What to manage
Integration slips; testing start slips; UAT slips One external review queue The queue: its length, its owner, and whether it can be bypassed or bought out
Two features need rework; estimation proves optimistic One unfamiliar technology The uncertainty itself: a spike, a proof of concept, or a different design
Several deliverables depend on the records office One unavailable stakeholder The stakeholder: escalation, delegation, or an interim data source

The practical test is to read the register and ask, if the worst quarter happened, which rows would all happen at once? Those rows usually have a common cause worth naming explicitly.

2. Primary, secondary, and residual risk

Type Definition Example
Primary risk The risk you identified The integration review slips by three weeks
Response-induced (secondary) risk A new risk created by the response Fast-tracking to protect the date means integration starts before the data model is frozen, raising rework
Residual risk What remains after the response The review slips by under a week, or the assessor finds issues that need a second pass

Secondary risk is the one most often missed, and it is the reason a response can make a project worse. Two habits help: when a response is chosen, ask "what has to go right for this to work?" and register the answers; and prefer responses that reduce the cause over responses that move the consequence (transferring a risk usually improves the project's exposure while increasing someone else's cost, which is a decision that needs to be made explicitly rather than by default).

Falling risk is worth noting too: as the project proceeds, the opportunity to influence cost decreases while the cost of change rises. Risks about requirements and design therefore need managing early, and risks about deployment late — the same register, but with a sense of when the response still has leverage.

3. Above one project: concentration and shared dependencies

Organisations rarely manage the risks that emerge from the shape of their portfolio rather than the content of any project. The common patterns:

  • Supplier concentration — most projects depend on one vendor, whose failure is now an organisational risk rather than a project risk.
  • Single-person dependency — one specialist is required by three projects in the same month.
  • Shared assumption — several business cases assume the same platform capability that does not yet exist.
  • Shared release or environment — a single deployment pipeline, or a single test environment, which becomes a queue when it matters most.
  • Regulatory change with a common deadline — several projects that must all comply by the same date.

These belong to whoever owns the portfolio, not to a project manager. A project's contribution is to name its dependencies on shared assets accurately at initiation, so that the concentration is visible while it can still be mitigated — buying a second supplier relationship or training a second specialist takes longer than any project's schedule.

4. Quantifying exposure without pretending to precision

Three levels of quantification, in increasing order of effort and decreasing order of honesty gain:

Level Method Cost Use when
Ordinal 1–3 probability × impact, threshold at 6 Minutes Always — for ranking and triage
Expected value Probability × monetary or schedule impact, summed Hours Sizing a contingency reserve
Range or simulation Three-point estimates, repeated addition of sampled values Days A small number of large, genuinely uncertain variables

On simulation, one honest sentence is worth more than the tooling: a simulation is arithmetic repeated many times over distributions you chose. It produces a distribution of outcomes that reflects your assumptions, not reality — including the assumption that the variables are independent, which is precisely what section 1 says is usually false. Simulation is most defensible where a few well-understood variables dominate and their ranges come from data; it is least defensible where the ranges are made up, since the output then carries a precision the inputs never had.

Reserve sizing is the practical output. A defensible approach on a small project:

  1. Sum the expected value of identified risks that are accepted or partly mitigated → reserve floor.
  2. Add the pessimistic tail of the two or three largest risks → reserve for concentration.
  3. State that unconsidered risks are not covered, and hold a management reserve for those.
  4. Name who may release each band, as in the risk response plan.

5. Appetite, tolerance, and who owns them

These two terms are often used interchangeably and they are not the same:

  • Risk appetite is the amount and type of risk the organisation is willing to take to pursue its objectives — a strategic statement: "we will accept schedule risk to be early to market with this product, but not compliance risk."
  • Risk tolerance is the measurable deviation from plan that will be accepted before action is required — an operational threshold: "a three-day slip on a milestone is tolerated; five days requires a sponsor decision."

Appetite is owned by the sponsoring executive, not the project. Tolerance is agreed with the sponsor and set per measure. A project with no stated tolerance will have one imposed retrospectively, usually at the moment of a slip, which is the worst time to invent the threshold — see the project dashboard, whose thresholds must be agreed before they are needed.

6. What risk management cannot do

Limitation What it means in practice
Novel events have no meaningful probability For a genuinely unprecedented event, a 10%/30%/60% estimate is invented. Record it as unquantified and plan the capability to respond instead of a numeric response
A register is not a control A risk whose response was never funded has not been managed, only described
Ordinal scores drift Once scoring is discussed in meetings, scores migrate toward the middle. Re-anchor periodically against the written scale
"Unforeseen" is usually "unconsidered" Most large surprises appear in someone's list at the start. Ask, at initiation, what would have to be true for the project to fail badly
Some risks are unfunded obligations If the mitigation needs capacity the project does not have, the honest record is a decision to accept the risk — with the decider named — not a response with no owner
Risk management cannot fix underfunding A project too small to absorb variance has a budget problem, not a risk problem, and no register changes that

The last row is the most useful thing in this lesson. A register that absorbs a chronic shortage of people or budget by converting it into a long list of accepted risks is providing the appearance of management while the actual constraint goes unaddressed.

Key terms

Term Meaning
Correlated risk Risks that share a cause and therefore tend to occur together
Common cause The single factor underlying several risks, and the thing most worth managing
Secondary risk A new risk created by the response to another risk
Residual risk The risk remaining after the response has been applied
Falling risk The declining opportunity to influence outcomes as a project proceeds
Concentration Portfolio-level exposure from many projects depending on one asset, supplier, or person
Risk appetite The amount and type of risk the organisation will take to pursue objectives
Risk tolerance The measurable deviation accepted before action is required
Management reserve A reserve held for risks not identified, distinct from contingency for identified ones

Worked example

Task: reassess the admission portal's risk position before a re-baselining decision. Figures are invented for teaching.

Step 1 — Find the shared cause and rewrite the register around it. Five registered risks are: security review slips; integration testing starts late; UAT is compressed; documentation is late; the release misses the window. All five depend on one external review queue of ten working days that the project does not control. Scored individually, they read as five medium risks, which understates them: the queue running to twenty days does not produce five moderate impacts, it produces one failed release. The register is restructured so the queue is one risk at exposure 9, with the others recorded as its consequences.

Step 2 — Register the secondary risk that the current response creates. The chosen response — start integration before the data model is frozen, in order to protect the window — reduces the schedule risk and creates a rework risk whose exposure is comparable. The register records it with its own owner: the technical lead, with a trigger of "any change to the shared data model after integration begins".

Step 3 — Size the reserve in three parts. Identified risks with expected values sum to 11 working days (the reserve floor). The two largest tails — the review queue and the rework risk — add 6 days for concentration. A separate management reserve is held for unconsidered risks, released only by the sponsor. The three bands are written into the response plan with the release authority for each, because a reserve without a release authority is spent on the first inconvenience.

Step 4 — State appetite and tolerance, and get them agreed. Appetite, from the sponsoring executive: schedule risk is accepted to protect the application window; compliance risk is not, so the data-protection review cannot be compressed to recover time. Tolerance, agreed with the sponsor: three days of milestone slip is tolerated; five days requires a decision; any slip that would push the release past the window is an immediate escalation. Both are written down before they are needed.

Step 5 — Plan capability rather than probability for the unquantifiable. Two risks are unquantifiable: a change in the admissions policy mid-cycle, and a change of external assessor. No probability is invented. Instead each is given a capability response: a named person who would lead the response, a checklist of what would need to be reassessed, and a standing agenda item on the monthly review. This is what "managing the response to an unknown event" looks like in practice.

Step 6 — Name what is not being managed, and who decided that. The register ends with two accepted risks whose mitigation would need capacity the project does not have: no second tester, and no pre-production copy of the student-records data. Both are marked as accepted by the sponsor, with the consequence described in plain terms and the decision recorded — rather than left as mitigations with no owner, which is the same decision made silently.

Common misconceptions

“A longer risk register is a better-managed project”

Length is not the measure. A register of forty small risks with no common causes named, no reserve, and no trigger is a list of worries. A register of eight, with the shared causes identified, a funded reserve, and an owner for each response, is a control.

“Probability × impact gives us the expected cost of the risk”

It does, if both inputs are real numbers. On the 1–3 ordinal scale it gives a ranking score, and those scores cannot be summed or read as money. Mixing the two uses is one of the most common errors in risk reporting — the risk assessment matrix keeps them apart deliberately.

“Transferring the risk removes it”

Transfer moves the consequence, usually at a price, and the price is someone else's contingency. It also leaves interface risk behind: the deliverable still has to be integrated, accepted, and supported. Transfer is a legitimate strategy — it simply is not a deletion.

“If we identified it, we have managed it”

Identification without a funded, owned response is the most common way a register misleads. The test is whether the response appears in the schedule and the resource plan; if it does not, the risk is accepted in practice, whatever the register says.

Practical activity

Reassess a risk position you know — your capstone, or a project at work.

  1. Take your risk register and group the rows by shared cause. Name each cause as a risk in its own right, with an owner, and record which rows are its consequences.
  2. For each response, write the answer to "what has to go right for this to work?" and register anything that is a new risk. Mark at least one secondary risk explicitly.
  3. Size a reserve in three parts: expected values, the largest tails, and a management reserve. State who may release each band.
  4. Write one sentence of risk appetite and two measurable tolerances, and name who owns each.
  5. Identify one risk you are accepting because the mitigation needs capacity you do not have. Write it as an explicit acceptance with a named decider.

What "good" looks like: at least one risk expressed as a common cause rather than as a list of consequences, one secondary risk created by your own response, three reserve bands with release authorities, tolerances with numbers, and one honest acceptance rather than a response without an owner.

Self-assessment

  1. Why does a register of individually scored risks understate exposure when the risks share a cause?
  2. Give an example of a secondary risk, and say what habit prevents them from being missed.
  3. What is the difference between risk appetite and risk tolerance, and who owns each?
  4. What does a simulation of schedule risk actually produce, and when is it least defensible?

  5. A project has sixty accepted risks and no reserve. What is the real problem, and how would you raise it?

  6. Apply it — correlated risk. A programme runs four projects. Each has a risk register listing “vendor delivery delay” at a rating of medium. All four projects use the same integration vendor, and the programme's exposure is reported as four mediums, none of which individually requires action.

    Hint: A strong answer explains what the register is understating and what the response has to consider.

Show answers
  1. Because scoring each risk independently assumes they can occur separately, and the expected values are added as though the impacts were independent events. When a shared cause fails, the impacts arrive together — so a single cause can defeat several mitigations at once, which is a larger and more likely loss than the individual scores suggest.
  2. For example, fast-tracking the integration to protect a date, which means work begins before the data model is frozen, creating rework risk. The habit that catches these is asking, of every chosen response, "what has to go right for this to work?" — and registering the answers as risks with owners of their own.
  3. Appetite is the amount and type of risk the organisation is willing to take to pursue its objectives, and it is owned by the sponsoring executive as a strategic statement. Tolerance is the measurable deviation from plan accepted before action is required, it is set per measure, and it is agreed between the project and the sponsor.
  4. It produces a distribution of possible outcomes that reflects the ranges and the dependencies you assumed. It is least defensible when the ranges are invented — it then adds precision without adding knowledge — and when it assumes independence between variables that in reality share a cause.
  5. The real problem is that risks have been recorded without being funded, which usually means the project's capacity is insufficient for its commitments rather than that it has an unusually long risk list. The way to raise it is to price the accepted risks: state the exposure they represent in days or money, and present the choice — fund the responses, extend the date, or reduce scope — as a decision for the sponsor. Presenting it as a decision rather than as a worrying register is what makes it actionable.
  6. The four rows are not independent: they share a cause, so a single vendor failure materialises in all four projects at once, and four mediums read separately badly understate the exposure. Treat the shared cause as one risk owned at programme level, with the individual projects' consequences recorded beneath it, and consider concentration: a single supplier, one specialist, or one environment that every project depends on. Then ask the secondary-risk question of any response you choose — adding a second vendor creates interface risk, cost, and a new negotiation, so the response may be mitigation that reduces the impact (decoupling the interface, building a fallback path, holding buffer on the shared dependency) rather than the probability. Quantifying it precisely is not the point and the lesson says so: the value here is that the correlation was invisible in the artefact that was supposed to show it.

Summary

  • Risks share causes, so a register of independent rows understates exposure. Name the common cause as its own risk and record the consequences beneath it.
  • Every response creates secondary risk. Ask what has to go right, and register the answers.
  • Above one project, watch for concentration: shared suppliers, single-person dependencies, shared assumptions, shared environments, common regulatory deadlines.
  • Use ordinal scoring for ranking and real units for reserve sizing, and never mix them. Simulation is arithmetic over your assumed ranges — most useful where a few dominant variables have data behind them.
  • Appetite is strategic and owned by the executive; tolerance is measurable and agreed with the sponsor. Agree tolerances before they are needed.
  • Risk management cannot quantify genuinely novel events, cannot control by documentation, and cannot fix a project that is simply too small for its commitments. Those are capability and funding problems, and saying so is part of the job.

Further learning

For a verifiable reference on risk management as a discipline, ISO 31000 (Risk management — Guidelines) is the most widely used generic standard and is explicit that it applies to organisations rather than projects; it is a useful corrective to the assumption that risk management is a register. For the falling-opportunity argument in section 2, the PMBOK® Guide (Project Management Institute) presents risk as a process that runs throughout the project, with the cost of change rising as the project progresses — a claim worth reading in the source rather than taking second-hand.