Where we are: week 5, the map exists, now what breaks it
Northwind has a charter (b2), six milestones with gate criteria (b3), and as of last week a dependency map with a hard gate drawn across the critical path (b4). You know that M3 raw ingest has to sign off by 10 August, that M4 modelled warehouse cannot start until two data engineers exist, and that Veridian - the POS extract vendor - sits on an unconfirmed external arrow. The plan is now good enough to be worth defending, and that is exactly what a risk register is: the list of things that could break the plan you just built, written so specifically that you would notice them starting. Not a compliance annex, not a wall of amber. A short list of named futures with a named human watching each one and a written signal for when to act.
The anatomy of a risk row 6 min live
Nine fields. You already know eight of them and half your registers are missing the ninth. Take them one at a time, because each field has a specific failure mode and the failures compound: a vague description makes probability meaningless, a missing owner makes mitigation optional, and a missing trigger makes the whole row decorative.
LiveCause, effect, and why nouns are useless3 min▶
Most registers are lists of nouns. "Vendor risk." "Resourcing." "Data quality." A noun cannot be mitigated, triggered or closed, because nobody can tell what would have to change for it to go away. The fix is a sentence with three parts, and written that way the row tells you where to look for the trigger, what mitigation would even mean, and when to close it:
- Because [cause that is true today] - the condition that already exists. "Because Veridian has no signed SLA on the POS extract..."
- [effect] may happen - the uncertain event, stated once, singular. "...the field spec may arrive after our build window..."
- leading to [consequence on the plan] - the damage, in the currency of your programme. "...leading to M3 missing the 10 August gate and M4 moving with it."
Eleven rows that said "integration". A programme review found a 40-row register where eleven rows were one-word nouns and four of those eleven were the same risk described by four different workstreams. Nobody had noticed, because you cannot spot a duplicate between "integration" and "interface complexity". Rewritten as cause-effect sentences, the eleven collapsed into three real risks - and one of the three turned out to have no owner at all, which is how it had survived for seven months.
LiveThe trigger: the field that turns watching into acting3 min▶
A trigger is the observable, dated fact that means "act now". Not "if things look bad". Not "if the vendor seems slow". Something a person could check on a Tuesday morning in thirty seconds and answer yes or no without any judgement at all. Three tests:
Could a colleague check it without asking you what you meant? "No written response on VN-2291 by 6 August" passes. "Vendor engagement deteriorates" fails.
Does it have a date or a threshold, and does it say what happens next and who does it? A trigger without a deadline never fires, it just gets more true slowly until it is an issue. "Escalate to Elena V. and start the contract-engineer option" is a trigger; "review" is not an action, it is a way of deferring one.
The risk everyone was watching and nobody acted on. A vendor-dependency risk sat amber on a register for four months. It was discussed at every weekly. Everyone agreed it was concerning. Then it became an issue, cost six weeks, and the post-mortem asked the only useful question: at what point should we have acted? Nobody could answer, because no point had ever been defined. Four months of attention with no decision rule is not risk management. It is a group of professionals worrying together on a schedule.
Self-studySeverity, RAID hygiene, and the rule you write once2 min read▶
- Use a coarse scale - low, medium, high on both axes. Five-point scales invite an hour of debate about whether something is a 3 or a 4, which is an hour not spent on the trigger. Decide the rule once, put it in your house rules, and stop renegotiating it per row.
- Severity ranks the register, it does not manage it. Its only job is to say which eight rows get read at the steerco. And a hard gate outranks its score: R-03 could compute as medium and still be the most important row on the page.
- A risk has not happened yet. If it has, it is an issue - different list, different cadence, and an owner acting today rather than watching. "Read this register and tell me which rows have already happened" is a thirty-second prompt that usually finds two.
- An assumption is a risk you decided not to test, and every unconfirmed external dependency from b4 becomes a row here. Keep all four in one document with four tabs, or nothing gets reviewed.
What AI is genuinely good and bad at here 5 min live
Risk is the place where AI assistance is most tempting and most dangerous, because the output looks like analysis. It will hand you a register with a probability column full of confident percentages, and every one of them is a language model producing a plausible-looking number. Here is the split, and it is sharper than in any other session of this track.
| Genuinely good at | Genuinely bad at, and do not let it try |
|---|---|
| Turning a vague worry into a cause-effect risk statement. "I'm nervous about the vendor" becomes a three-part sentence in seconds, and it will be a better sentence than the one you would have typed at 6pm. | Probability. It will produce "30%" with total confidence and it means nothing. There is no base rate, no data, no history - just a plausible-shaped number. Probability is your judgement and the team's. |
| Drafting a testable trigger. Ask for the observable dated fact and it will propose three candidates. You pick, and picking is much easier than inventing. | Whether a vendor will actually deliver. That lives in Priya N.'s relationship with Veridian, in how the last two deliveries went, and in a tone of voice on a call. None of it is in your workspace. |
| Spotting duplicates and near-duplicates across a 40-row register, and diffing this week against last week - what is new, what moved, what has not changed in six weeks. Reading at scale, and the single reason registers stay alive. | Anything about people, and deciding what to escalate. Whether Marcus L. is about to resign or the sponsor has lost interest is invisible to the pack, and escalation is a political act priced by what your sponsor tolerates and what you spent last time. |
LiveWhy the probability column is the trap2 min▶
Ask for a risk register and you will get probabilities. They will be varied, they will look considered, and they will be produced by the same process that produces fluent prose - which is to say, by what a probability usually looks like in a document of this kind. Two things go wrong immediately. First, the number gets treated as analysis: a sponsor reads "35%" and assumes somebody computed something, nobody did, and being unable to defend a number in front of a steerco costs more credibility than the risk itself. Second, it stops the conversation that matters - the value of assigning probability is the five-minute argument between you, Sofia K. and Marcus L. about how likely this really is, and a pre-filled number ends that argument before it starts.
So the rule in the drafting prompt is blunt: leave probability and impact blank, and hand back a list of who should fill each one in. That is rail two - the dates come from the team - applied to the risk register. Put it in your house rules file from b1 as one line, "never fill probability or impact, leave them blank and name the person who should set them", and you never have to catch it again.
The weekly refresh, in fifteen minutes 4 min live
Registers do not die because people stop caring about risk. They die because the refresh is boring and undated, so it loses every week to something urgent. The way out is to make the refresh mechanical - four questions of every row, always the same four - and to make the output short enough that someone actually reads it.
LiveThe refresh prompt, and why the output must be short3 min▶
Feed it last week's register and this week's evidence - stand-up notes, ticket updates, the vendor thread - and ask the four questions. The critical instruction is about the output, not the analysis: a delta, not a document.
The "do not restate the register" line does more work than any other instruction on this page. Without it you get a beautifully formatted forty-row table every week, which nobody reads, which means the refresh has technically happened and practically has not. Put the fifteen minutes in the calendar on the same morning every week, just before the status report goes out - a refresh with no downstream consumer is the first thing dropped in a bad week - and bring the "what moved" list to the meeting rather than editing the register live in it. Session b9 automates the evidence-gathering half; the four questions stay yours forever.
The stale-row question that found the real problem. A delivery lead ran the refresh and the "no evidence of movement for 3+ weeks" section came back with five rows. Four were genuinely dead and got closed. The fifth was the biggest risk on the register - and it had shown no movement for six weeks because its owner had quietly left the programme in March and nobody had reassigned it. The register said it was being managed. Nobody was managing it. That one line of the prompt is worth the whole habit.
Build the Northwind register ★ 14 min · everyone builds
Five rows. R-03 the hiring hard gate, R-05 the legacy warehouse decommission, R-07 the Veridian SLA, R-09 sponsor availability, R-11 data quality below the 99% gate. Draft them with the prompt, then spend the real time on owners and triggers - that is the part only you can do.
Here is what the five core rows look like after the team has argued with the draft for ten minutes and filled in the columns the model was forbidden to touch. Read the R-09 owner column especially: sponsor availability is a real risk on almost every programme and almost never on a register, because the owner would have to be you and the mitigation would have to be an uncomfortable conversation. Put it on anyway. A risk you are too polite to write down is still there, and it will still cost you the quarter.
| ID | Because... may happen... leading to | Owner | Trigger |
|---|---|---|---|
| R-03 | Because two data-engineer roles are unfilled, the M4 build may have nobody to start it, leading to M4, M5 and M6 sliding one week per week of delay. Hard gate on the critical path. | Elena V. | No accepted offer by 24 Aug, or fewer than 3 candidates at final stage on 10 Aug |
| R-05 | Because the legacy warehouse decommission window is owned by IT ops and unscheduled, the M5 cutover may have no slot, leading to governed BI going live behind a system it was meant to replace. | Elena V. (sponsor to broker) | No written decommission window agreed by 31 Aug |
| R-07 | Because Veridian has no signed SLA on the POS extract, the field spec may arrive after our build window, leading to M3 missing the 10 Aug gate. | Priya N. | No written response on VN-2291 by 6 Aug |
| R-09 | Because the sponsor has three competing programmes this quarter, gate decisions may wait more than five working days, leading to every milestone inheriting the delay. | The delivery lead (you) | Any gate decision open more than 5 working days |
| R-11 | Because 3 of 9 sources have no upstream validation, nightly loads of 812k rows may fall below the 99% DQ gate, leading to M3 sign-off being refused. NWD-412 is the current instance. | Marcus L. | DQ below 99% on any two consecutive nights |
The blank column that started the best meeting of the month. A PM brought a register with probability and impact deliberately empty and one question: "you three tell me." Twenty minutes later Marcus L. and Sofia K. were arguing about whether the DQ risk was high or medium, and in the argument Marcus mentioned that three of the nine sources had no upstream validation at all - a fact that had never appeared in any document. The empty column bought that fact. A pre-filled number would have bought silence.
The trigger-writing drill ★ 8 min · turn worries into tripwires
Take three vague risks - yours, or the three below - and convert each into a tripwire. This is the highest-value eight minutes in the session, because a register full of good descriptions and bad triggers is still a register nobody acts on. And a trigger has one more job on an AI-assisted programme: a model can watch a register and tell you what changed, but only if the rows contain checkable facts. Hedged risk prose is unwatchable by humans and machines alike.
Every one of them is unfalsifiable. There is no Tuesday on which you could look at any of them and say "yes, that has happened, act now", so nobody ever does and each one sits amber until it becomes an issue. Converted:
| Vague worry | Tripwire: observable, dated, with the action attached |
|---|---|
| The vendor might be slow | If VN-2291 has no written SLA response by 6 Aug, escalate to Elena V. and start the contract-engineer option for the POS ingest. |
| Data quality could become an issue as we scale | If the nightly DQ score falls below 99% on any two consecutive nights, Marcus L. stops new source onboarding and raises it at the Wednesday gate review. |
| Resourcing is a concern for the build phase | If fewer than 3 candidates are at final stage on 10 Aug, or no offer is accepted by 24 Aug, Elena V. approves two contract engineers that week. |
Take your three vaguest rows and ask: what would I see on a Tuesday morning that means this has started? Write that sentence, then put a date or a threshold in it - no date means it never fires, and "two consecutive nights" is a threshold where "occasionally" is not.
Attach the action and the person - if the action is "review", you have not finished, because review is how you defer a decision while feeling productive. Then read it to the owner and ask: "if I sent you this on the day it fired, would you know what to do?" If they hesitate, the trigger is not done.
Try it yourself - this week ◐ 40-60 min total
- Rewrite every row of your real register into cause-effect form, and count the ones that collapse into each other - that number is how much of your register was dialect rather than risk. Then write a real trigger for your top eight rows: observable, dated, with an action and a name. If a row resists having a trigger written, that is usually a sign it is an assumption, not a risk.
- Delete or close every row that has not moved in six weeks and has no trigger, then put the fifteen-minute refresh in your calendar, weekly, before your status report goes out. Run it once this week and keep the "what moved" list.
- Take every UNCONFIRMED external dependency from your b4 map and add it as a risk row, with the confirmation message as the mitigation and a date as the trigger.
- Add the one risk you have been too polite to write down. Every programme has one. Yours is probably about a person, a sponsor, or a promise somebody made that nobody wrote in.
Official sources covered
Risk practice comes from the delivery canon; the human-oversight rule that keeps probabilities out of a model's hands comes from PMI's AI standard. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Your drafted register comes back with a probability column full of confident percentages. What do you do?
There is no base rate behind those numbers - they are plausible-shaped, not computed. Worse, a pre-filled number ends the five-minute team argument that surfaces facts like "three sources have no upstream validation".
2 · Which of these is a real trigger for R-07, the Veridian SLA risk?
A trigger is observable, dated, checkable by a colleague in thirty seconds, and attached to an action and a name. B needs judgement to evaluate, so it never fires. C is monitoring, which is not a decision rule.
3 · Your weekly refresh returns a beautifully formatted 40-row table every Tuesday. What is wrong?
The refresh has technically happened and practically has not. Ask for a "what moved" list of at most eight lines plus stale rows and new risks, and add "do not restate the register" - it is the highest-value line in the prompt.