A beautifully maintained RAID log can still be useless.
If a dependency has been yellow for six weeks but nobody changed the plan, assigned an owner or escalated a decision, the team is documenting uncertainty rather than managing it.
I think of RAID as a forcing function. Every meaningful item should answer: what changes because we know this?
Examples of useful consequences.
| Signal | Action |
|---|---|
| Source data may arrive late | Sequence build around mock data and define a hard reconciliation gate |
| Identity decision unresolved | Stop downstream personalization design until source of truth choice is made |
| Capacity is oversubscribed | Make the roadmap trade-off explicit instead of silently slipping work |
| Consent interpretation unclear | Escalate decision before audience logic is finalized |
I prefer fewer, more actionable items.
A giant list creates equal visual weight for everything. I would rather maintain a smaller set of items with clear impact, owner, due date, mitigation and escalation path.
The point is not to prove the team identified every conceivable risk. It is to make the risks that can materially change the outcome hard to ignore.
The practical rule.
For every material RAID item, ask what decision, sequence, owner, test or contingency changes because the item exists. If the answer is “nothing,” either the item is not material or the team has not acted on it yet.