From dependencies to risks
A dependency tells you the order things must happen. A risk tells you where that order could break: the hire that arrives late, the dictionary that turns out half-empty, the cloud bill that triples on 80 TB of reprocessing. Every serious build carries a handful of these, and the ones that hurt are always the ones nobody wrote down. The risk register is the artifact that drags them into the light - one row per risk, each scored, mitigated, owned, and watched. Today we build Northwind's in full.
Risk register anatomy & probability x impact 5 min live
A risk is an uncertain future event with a probability (how likely) and an impact (how much it hurts). Score each on a scale - a 1-to-5 for each works well - and multiply the two for a severity score. That single number turns "I have a bad feeling about the dictionary" into "probability 5, impact 4, severity 20 - top-right corner, act now." The matrix below is where Northwind's risks land.
LiveScoring probability and impact3 min▶
Pick one scale and use it for every risk so the numbers compare. A 1-to-5 on each axis is the common practitioner choice: 1 is "rare / trivial", 5 is "near-certain / severe". Multiply the two for a severity score from 1 to 25, then read the cell colour to decide urgency.
- Probability - how likely, honestly, given what you know today. A rushed handover dictionary being low quality is near-certain, so R1 scores a 5.
- Impact - how much it hurts the outcome, not how loud it feels. Hiring slipping blocks every technical milestone, so R3's impact is a 5.
- Severity = probability x impact - the single number that ranks the register. It tells you the review order, not a promise; a low-probability, catastrophic risk still earns a plan.
Score with the room, not alone. The most useful thirty seconds of a risk workshop is when the source-dev lead says "actually the dictionary is worse than you think" and the impact ticks up. Scores are a conversation starter - the point is a shared, written number everyone argued over, not a spreadsheet you filled in quietly.
Self-studyRisk vs issue vs assumption2 min read▶
Three words get muddled and the muddle costs you. A risk is uncertain and in the future - it might happen. An issue is certain and in the present - it has happened and needs fixing now. An assumption is something you are treating as true without proof - if it turns out false, it becomes a risk or an issue.
| Type | Tense | Northwind example |
|---|---|---|
| Risk | Might happen | R3: critical hiring could slip and block M2 |
| Issue | Has happened | Keys are not aligned across POS and e-commerce today |
| Assumption | Taken as true | Source teams will deliver ERDs on the agreed date |
Keeping them in separate columns of the RAID log stops the classic mistake: managing a live issue as if it were a maybe.
Every risk needs a mitigation, an owner, a trigger 5 min live
A score without a plan is just anxiety with a number on it. A complete risk row carries five more things after the severity tag: a mitigation that reduces the risk, a single owner who is accountable, a trigger that tells you it is materialising, and an escalation path for when it does. Here is R1, Northwind's highest risk, opened up into its full anatomy.
LiveMitigate, avoid, transfer, accept3 min▶
You have four honest responses to any risk. Naming which one you are choosing keeps the register from being a wish list of "we'll be careful."
- Mitigate - reduce probability or impact. Most rows land here: R1's independent profiling pass makes the bad-dictionary outcome smaller and earlier.
- Avoid - change the plan so the risk cannot occur. Deferring real-time streaming out of scope avoids a whole class of pipeline risk.
- Transfer - move the risk to someone better placed to carry it, via a contract or SLA. R6 cost overrun can be partly transferred with a committed-spend agreement.
- Accept - decide the risk is small enough to live with, and say so on the page. Acceptance is a valid choice only when it is written down and owned, not when it is forgotten.
Self-studyThe owner-with-no-authority trap2 min read▶
The most common failure in a risk register is naming an owner who cannot actually act. You assign R3 (hiring delay) to the PMO, but the PMO cannot approve senior salaries or unblock a hiring freeze - only the sponsor can. So the trigger fires, the "owner" raises a hand, and nothing moves.
- Match owner to authority: the owner must be able to pull the mitigation lever, not just report that it is stuck.
- Escalation is not ownership: if the real lever sits two levels up, the escalation path names that level explicitly - it does not pretend the reporter owns the outcome.
- Northwind's R3 is therefore owned by the Executive Sponsor (who leads the senior-hire panel), not by Marcus in the PMO, who tracks it.
RAID and the review cadence 5 min live
The risk register does not live alone. It sits inside a RAID log - Risks, Assumptions, Issues, Dependencies - the four things a PMO tracks continuously. Risks are the R column, but the log's value is the discipline around it: reviewed on a cadence, each risk either burned down (mitigated to closed) or escalated, never quietly abandoned.
LiveRunning the risk review3 min▶
A register is only as good as its review rhythm. On a data platform build, the risk review rides on the regular status cadence - weekly or fortnightly - and takes ten minutes if the log is kept honest between meetings.
- Sort by severity and walk the top rows first. The HIGH risks (R1-R4) get airtime every meeting; the MEDs get a glance.
- For each, ask three things: has the score changed? has the trigger fired? is the mitigation on track? Update the number, not just the notes.
- Close, hold, or escalate - every reviewed risk leaves the meeting with a verb. A risk that is neither improving nor escalating is a risk nobody actually owns.
Self-studyRisk burn-down over the project2 min read▶
A healthy project's total risk should trend down over time as mitigations land and uncertainty resolves. Plotting the sum of severity scores meeting by meeting gives you a burn-down line - a single chart that tells a board whether the build is getting safer or scarier.
- Early spike is normal: as you learn the estate, you find risks you did not know to name. The line often rises before it falls.
- The shape is the signal: a line that will not come down by mid-project means mitigations are not working - or the real risks are still hidden.
- New risks are healthy: a register that never adds a row is not de-risked, it is stale. Northwind's should gain and retire rows as milestones pass.
Score R2, R5 and R6 on probability x impact ★ 7 min · everyone scores
Take three Northwind risks: R2 archive completeness & reconciliation gaps, R5 scope creep ("100% of everything" vs a curated set), R6 cloud cost blowout on 80 TB. For each, agree a probability 1-5 and an impact 1-5 with your neighbour.
Multiply to get a severity score, then place each on the matrix. Sanity-check against the canon: R2 lands HIGH, R5 and R6 land MED. If your scoring disagrees, say why out loud - that argument is the exercise.
For R6, notice how a "medium" can still demand action: high impact, moderate probability. Severity ranks urgency, it does not excuse ignoring the corner cases.
Read one pair's scores aloud. The room checks: did impact reflect the outcome, not the noise? Did anyone confuse a live issue with a risk?
Scope creep (R5) is the risk teams most often under-score because it feels like nobody's fault - it arrives one "small addition" at a time. Scoring it explicitly, and pointing at the peer-benchmark curated set from Session 6, is how you give the PMO a written reason to say "that is a change, not a given."
Write mitigation, owner and trigger for R1 and R3 ★ 9 min · everyone writes
For R1 (low-quality dictionary), write the three fields: mitigation ("independent profiling pass, do not trust the handover"), owner (one name - Priya, Head of D&A), trigger ("profiling finds >10% of columns undocumented or mis-typed").
For R3 (hiring delay), write the same three. Watch the owner: it is the Executive Sponsor who leads the hire panel, not the PMO who merely tracks it - avoid the owner-with-no-authority trap.
Name the response type for each: R1 is mitigate, R3 is mitigate-plus-avoid (parallel internal transfers so external delay cannot fully block the build).
Read a pair aloud. Room test: is the trigger observable? "The dictionary is bad" is a feeling; ">10% of columns undocumented" is a signal you can actually watch for.
Assemble the full 8-row register ★ 6 min · everyone assembles
Fill the register table below from the canon: R1-R4 are HIGH, R5-R8 are MED. Each row needs an ID, the risk, its severity, a one-line mitigation, and a single owner.
Check the owners spread sensibly - governance risks to the Governance office, cost and vendor risks to the Cloud/Infra partner, data risks to Priya, hiring to the Sponsor. No single person owns everything.
Order the rows by severity so a reader sees the HIGH four first. This is the artifact Session 6 reviews at status; make it scannable.
| ID | Risk | Severity | Mitigation | Owner |
|---|---|---|---|---|
| R1 | Low-quality / incomplete data dictionary | HIGH | Independent profiling pass; treat handover as a draft | Priya (Head of D&A) |
| R2 | Archive completeness & reconciliation gaps | HIGH | Row-count + checksum reconciliation against source | Marcus (PMO) + source dev |
| R3 | Critical hiring delayed - blocks all tech milestones | HIGH | Parallel internal-transfer track from day one | Executive Sponsor |
| R4 | Governance not defined before architecture | HIGH | Governance sign-off as a hard gate before M2 | Governance office |
| R5 | Scope creep - "100%" vs a curated set | MED | Peer-benchmark working set + change control | Priya (Head of D&A) |
| R6 | Cloud cost blowout on 80 TB + reprocessing | MED | Tiered storage, budget alerts, committed-spend deal | Cloud/Infra partner |
| R7 | Over-reliance on a single infra/vendor dependency | MED | Exit plan + portable infrastructure-as-code | Cloud/Infra partner |
| R8 | Network security & data residency not formalised | MED | Residency + network-security baseline sign-off | Governance office |
This week ◐ 30 min total
- Build a 6-row register for a real project at your desk - score each on probability x impact, tag the severity, and give every row a mitigation, an owner, and a trigger.
- Find your owner-with-no-authority row: look for a risk you have "assigned" to someone who cannot actually pull the lever, and re-owner it correctly.
- Read the self-study cards above: risk vs issue vs assumption, the owner-with-no-authority trap, risk burn-down over the project.
- Optional deep end: skim a RAID-log primer or the PMI risk-management process - both extend today's register into a full risk lifecycle.
Three questions before you go 🎯 ◐ 90 seconds
1 · How is a risk's severity score derived?
Severity = probability x impact. Both are scored on the same scale (1-5 works well), and the product ranks the register so you review the top-right, most-critical risks first.
2 · What is a trigger in a risk row?
A trigger is the early-warning signal - like "profiling finds >10% of columns undocumented" for R1. It must be observable, so the owner watches for a fact, not a feeling.
3 · What is the difference between a risk and an issue?
Risks are managed with probability, mitigation and triggers because they might happen. Issues are already real, so they are fixed now. Managing a live issue as a "maybe" is the classic RAID mistake.
Frameworks covered & their origins
This course teaches the working 80% of each tool and cites the canon - full standards stay the deep end for anyone who wants them.