The RAID Register a Steering Committee Can Actually Read
Most risk registers are written to prove that risk was considered. A useful one is written so somebody can decide what to do this week.
RAID stands for risks, assumptions, issues and dependencies. The four belong together because they convert into each other: an assumption that fails becomes an issue, a dependency that slips becomes a risk, and a risk that materialises becomes an issue with a cost. Keeping them in four separate places guarantees that the conversion is invisible, which is the moment the register stops describing the engagement.
The distinction that matters most is between a risk and an issue. A risk has not happened and has a probability. An issue has happened and has a cost. Registers that blur them produce the characteristic failure where everything is a risk, nothing is ever closed, and the register grows until nobody reads it.
Scoring that means something
A register without scores cannot be sorted, and a register that cannot be sorted is read from the top until the reader gets bored. Scoring is what makes the register usable at a governance meeting where twelve minutes are available for it.
The useful discipline is to score twice: inherent, meaning before anything is done about it, and residual, meaning after the mitigation that is actually in place. The gap between the two is the value of the mitigation, and it is the number that tells a steering committee whether the work being done on a risk is achieving anything. A register that scores only residual cannot answer the question of what would happen if the team stopped mitigating.
Issues are a special case worth handling explicitly. An issue has already happened, so its probability is certainty, and a scoring model that asks somebody to estimate the likelihood of a thing that has occurred produces nonsense. Forcing certainty on an issue is correct rather than a shortcut.
Heat, and why bands beat numbers
Multiplying probability by impact produces a number that looks precise and is not. Nobody can distinguish a fourteen from a sixteen, and pretending to invites arguments about the arithmetic rather than the risk. Banding the result into a small set of levels, four is usually enough, keeps the ordering useful without implying precision that is not there.
What the bands need is words as well as colour. A register that communicates severity only through a red, amber or green dot is unreadable to anybody with a colour vision deficiency, unusable in a printed board pack, and meaningless in a screen reader. Every band should have a name that appears in the text.
The review cycle is the whole discipline
A risk that has not been looked at in three months is not a risk being managed, it is a note. The single most valuable field on a register after the score is the next review date, and the most valuable report is the list of items past theirs.
Review cadence should follow severity. A severe risk reviewed monthly is not being managed; a low risk reviewed weekly is wasting the meeting. Setting the interval from the band, and then reporting what is overdue, converts the register from a document into a working queue.
Ageing is the companion measure. A register where the average open item is four months old is telling you something the individual scores are not: that items enter and never leave. Reporting the age profile alongside the severity profile catches the register that looks healthy because everything in it is low, having quietly abandoned everything that was not.
What to share with the client, and what not to
Some of a register is for the client and some is not. A dependency on the client providing data by a date is theirs to see and act on. An internal note that a team member is underperforming, or that the firm has priced the work badly, is not.
The mechanism that makes this workable is marking audience at the point of writing rather than filtering at the point of sharing. An item created as internal stays internal, and a client-facing register is the subset marked for the client, assembled by the system rather than by somebody copying rows into a second document before every meeting. The copying approach fails in the same way every time: the copy drifts, and one day an internal note reaches a client.
Keeping the register honest
- One register per engagement, not one per workstream lead, and certainly not one per meeting.
- Close things. A register that only grows is a register nobody trusts, and closure with a reason is how the firm learns what actually happened.
- Give every item a named owner who is a person rather than a team, because a team does not chase itself.
- Link risks that became issues to the issue, and issues that became changes to the change request, so the chain of cause is readable afterwards.
- Select the key risks in a status report from the live register rather than retyping them, so the report and the register cannot disagree.