Keep a Living Risk Register the Team Actually Believes

Workflow area: Delivery & Reporting · Tier: Core · Hands-on time: ~30 minutes setup, ~15 weekly

The traditional register is written once at kickoff, reviewed never, and consulted only in the retro, where its authors discover it predicted nothing. Meanwhile the actual early warnings were all uttered out loud: "still waiting on the platform team," "that vendor API is flakier than we thought," "has anyone heard from the security review?" AI is built for exactly this gap — reading a week of standup notes, blocker flags, and channel threads and surfacing what recurs, what ages, and what escalates in tone. What it cannot do is judge which candidate risks are real, which are noise, and which are politically radioactive if published raw. That judgment is the weekly ritual, and the ritual is why the register stays believed.

When to use — and when not to

• Use it for any project with cross-team dependenciesdependency risks live almost entirely in conversation ("waiting on X") and are the class the tracker captures worst.
• Use it on programs big enough to have a weekly cadencethe synthesis needs a week of signal and a standing 15 minutes; both come free with any real program rhythm.
• Use it when leadership asks "what are your top risks?"the honest answer should take thirty seconds to produce, because the register is current.
• Skip auto-publishing, permanentlya raw AI-synthesized register pushed to stakeholders will eventually name a person, misread a vent as a crisis, or announce a risk to the exact audience it concerns before you've verified it; curation is not optional overhead, it is the product.
• Skip it for a two-week projectthe overhead exceeds the horizon; a pinned list of three known risks is enough.
• Skip feeding it private channelssynthesis reads team-visible spaces (standups, project channels, blocker fields), never DMs or 1:1 notes; a risk register that mines private conversation is surveillance wearing a process badge.

The recipe

1. 1.

   Set up the register and its sources. The register: one table wherever the team lives (Confluence, Notion, a pinned doc) — risk, category (dependency / technical / people-capacity / external), likelihood, impact, owner, mitigation, status, last-reviewed date. The sources: the week's standup notes or summaries, tracker items flagged blocked with their age, and exports from team-visible project channels. Agree with the team, openly, that these spaces feed the register — no silent listening.

2. 2.

   Run the weekly synthesis before the ritual.

   Copy

   You maintain a candidate-risk feed for an engineering program.
   Read this week's signals and propose register updates. You
   PROPOSE; a human meeting decides. Nothing you output is
   published directly.
   
   CURRENT REGISTER: [PASTE TABLE]
   THIS WEEK'S SIGNALS:
   - Standup notes: [PASTE]
   - Blocked items + age: [PASTE]
   - Channel excerpts (team-visible): [PASTE]
   
   Produce:
   1. NEW CANDIDATES — possible risks not on the register, each
      with: one-line description, category, the verbatim signal
      lines that triggered it (with dates), and a confidence tag
      (RECURRING — 3+ mentions / AGING — same blocker growing
      older / SINGLE — one mention, may be noise).
   2. UPDATES — register risks whose signals changed: escalating
      (mentions increasing, language sharpening), quiet (no
      mention in 2+ weeks — candidate to downgrade), or
      MATERIALIZED (it happened; move to issues, stop calling it
      a risk).
   3. DEPENDENCY AGING TABLE — every "waiting on X" with days
      waited, trend, and last contact.
   4. NOT RAISED — the register's top-impact risk that had zero
      signal this week (silence on a big risk is itself worth a
      question).
   
   Rules: quote signals verbatim, with dates. Never name a person
   as a risk — convert "R is overloaded" to "single-owner
   capacity risk on [area]". No mitigation advice unless asked.
   

3. 3.

   Hold the 15-minute curation ritual. Same time weekly, leads plus anyone whose area is on the table. Walk the candidates: accept (onto the register with an owner), reject (noise — say why, which trains your own reading of the feed), or watch (SINGLEs that need another week). Good synthesis output looks like:

   Copy

   NEW CANDIDATES
   - Vendor sandbox instability — external — RECURRING: "sandbox
     down again" (Mon), "third outage this week" (Thu), "can't
     test payouts" (Fri)
   UPDATES
   - Security review delay — ESCALATING: age 19 days, tone shift
     from "pending" to "now blocking the release branch" (Wed)
   DEPENDENCY AGING
   - Platform schema review — 12 days — no contact since Jul 28
   

   The human questions in the room are the ones the model cannot answer: Is the vendor issue our contract's problem or theirs? Is the security delay a queue problem or a findings problem? Who picks up the phone about the schema review, today?

4. 4.

   Publish the curated register, not the feed. After the ritual, the human-approved table goes to stakeholders — updated risks, owners, and the one-line "what changed this week" summary. The AI's candidate feed, with its verbatim quotes and misfires, stays internal to the ritual. Two artifacts, one boundary, no exceptions.

5. 5.

   Close the loop on materialized and retired risks. When a risk hits, note whether the register saw it coming and how early — that is your system's detection latency, and it should shrink over quarters. When a risk goes quiet for a month, retire it visibly rather than letting the register bloat into an unread wall; a 40-row register is how registers die the old death again.

Make it yours

• Small team, light tooling: sources are just standup notes and one channel export; the ritual is five minutes inside the existing weekly sync. The register is ten rows maximum — a small team holding forty risks is holding anxiety, not information.
• Program lead across multiple teams: run per-team synthesis, then a cross-program pass asking one additional question — "which risks appear on 2+ team feeds under different names?" — shared-dependency risks fragment across team registers and are invisible until merged.
• Client-facing delivery: maintain the internal register with this recipe, and derive the client-facing risk summary from it manually each week — same facts, contractual framing, and nothing about internal capacity or personnel; the derivation is always human, because pb-33's client-communication rules apply.

Quality check

• Every accepted risk traces to verbatim, dated signalsspot-check the quotes against the sources; a synthesized signal that was never actually said poisons the whole feed's credibility.
• No person appears as a riskscan the register for names; capacity and knowledge-concentration risks are framed by area and role, and the conversation about a struggling individual happens in a 1:1, never in a register.
• The aging table drove actiona dependency at 12 days with "no contact since" should have produced a phone call by Friday; if aging rows persist untouched, the register is observing, not working.
• Rejects were reala ritual that accepts every candidate is rubber-stamping the model; track your reject rate, and worry when it hits zero.
• Stakeholders never saw the raw feedaudit the published artifact monthly against the internal one; the boundary between synthesis and register is the trust boundary.