Most RAID logs die because they’re created once, then forgotten. Here’s how I keep mine alive so executives trust it and teams act on it.
Start with intent
- Who reads it? Steering, core team, auditors—write for them.
- How often? Set a cadence: weekly for team, biweekly for steering.
- What changes? Note what’s new since last review; people skim deltas.
Structure that drives action
- Risk: driver, trigger, probability/impact (H/M/L), owner, next action, due date, residual view.
- Assumption: statement, validation date, proof owner, contingency.
- Issue: impact, severity, owner, root cause, workaround, ETA.
- Dependency: upstream/downstream, owner, due date, test of readiness.
Color honestly, not optimistically
- Use a three-point scale and define it (e.g., High = >30% likelihood AND cross-team impact).
- Separate trend arrows from status colors to show movement.
- Keep a “last updated” column; stale items lose credibility fast.
Link to decisions and change
- Every red item should have a decision request or mitigation in flight.
- Significant new risks should appear on steering decks and change logs.
- When a dependency slips, automatically update the schedule risk register.
Reviews that matter
- Core team: 15 minutes weekly; close resolved items, add new triggers.
- Steering: focus only on reds and trending ambers; ask for decisions, not sympathy.
- Auditors/compliance: export with history; show owners and evidence of follow-up.
Tools that work
- A lightweight spreadsheet for small teams (with filters for “new this week”).
- Tracker in your work management tool (Jira/ADO/Asana) with tags for RAID type.
- Single source of truth—no competing logs in slides or email threads.
The RAID log is your early-warning radar. Keep it current, tie it to decisions, and use it to show where you need help before surprises hit your schedule.