The Risk Register Nobody Reads

Why it's not used - three causes, and the fix is different for each:

1. It's too big to read. 42 entries means nothing is a priority. A register where everything is tracked is a register where nothing is watched. The team's 20-minute discussion producing two entries and no changes is the symptom: people scan 42 rows, feel they've "reviewed" it, and move on.
2. The mitigations aren't actions. "Monitor closely" is not a mitigation - it's a note that you're worried. Entry #3 was rated high with no actual plan, so when enrollment fell behind, the register had nothing to offer. The team learned that reading the register doesn't help, which is a rational reason to stop reading it.
3. It's disconnected from the work. Risk review is a separate meeting about a separate document. If risks aren't tied to the schedule, budget, and decisions the team is already making, the register is overhead.

Rebuild it:

• Cut to the risks that matter. Triage the 42 into roughly 8-12 active risks. Retire the rest to a watch list or close them. A risk that hasn't changed in 5 months and has no live trigger is not active.
• Rewrite every mitigation as an action with an owner and a date. "Monitor closely" becomes "Enrollment sub-team reviews screening rate by site every two weeks; if rate falls below [X], PM triggers backup-site activation." If a risk has no actionable mitigation, that's a finding - either accept it explicitly or escalate it.
• Add triggers. Each risk gets a defined threshold that says "this is now happening." Triggers are what convert a register from a document into a decision tool.
• Fix the two misses. Central lab shipping changes had no entry - add it and ask why change management didn't surface it (the real gap may be that vendor change notifications aren't routed to you). Site attrition was predicted and still unmitigated - that's the more instructive failure: the register was right and nobody acted, which means the problem is the review process, not the content.
• Attach the register to existing meetings. Five minutes at the weekly ops meeting on active triggers only, not a separate quarterly review. Risk review should be a standing agenda item where decisions get made, not an event.

Give them the top three - and use the request as the forcing function to make the register useful.

The sponsor is telling you something important: they don't want a document, they want a decision. A 42-row register presented to an executive is a way of avoiding the conversation about what actually threatens the study. So bring the conversation:

At the review, present three risks with this structure for each:

• What it is, in one sentence.
• What it costs if it happens - in time, money, or subjects, not in "high/medium/low." "If enrollment stays 15% behind, LPLV moves 4 months and the Month 24 interim analysis is at risk" is a risk statement. "Enrollment: high" is not.
• What we're doing, by when, and who owns it.
• What I need from you - the decision or resource that only the sponsor can provide.

That last bullet is the point. A risk review where the sponsor makes no decisions is a status update, and status updates don't need a register.

On the register itself: don't argue for it. Say: "The register is my working tool; you'll get the top three and the decisions. If you want the full picture, it's one page in the appendix." Then make sure the top three are genuinely the top three - not the three that are easiest to talk about. Slow enrollment and the central lab changes are the live ones; site attrition is the one that already happened, so it belongs in a "what we learned" note rather than the forward-looking top three.

The deeper move: the sponsor's request is a quality test on your register. If you can't name the top three risks to your study from memory, the register has failed regardless of how many rows it has. The rebuild should get you to the point where the top three are obvious and the other 35 are supporting detail.