RAID Log Review Cadence: How Often and How to Run the Meeting

## The short answer

Review your RAID log on a **fixed, regular cadence**, weekly for most active projects, with a short, focused meeting that does four things: capture new items, update existing ones, close what's done, and decide what to escalate. The cadence matters more than the duration. A 20-minute review every week beats a two-hour deep-dive once a quarter, because RAID logs decay fast and a stale log is worse than useless, it gives false comfort. Layer the cadence: frequent team-level reviews, less frequent summary reviews at steering or board level.

## Why cadence beats intensity

Risks change likelihood, dependencies approach their dates, assumptions get tested and issues escalate, all within days. A log reviewed monthly is constantly out of date with reality. A predictable rhythm means problems surface while they're still cheap to fix, and it builds the habit that keeps the log trustworthy. When people know the review happens every week without fail, they keep their entries current.

## A layered cadence

Different audiences need different frequencies and depth:

- **Weekly (delivery team).** The working review. All open items, with focus on reds, ambers and anything near a key date. This is where the real management happens.

- **Fortnightly or monthly (project/programme level).** A consolidated view, often led by the delivery manager, feeding the status report.

- **At each steering or board meeting (sponsor level).** Top risks and issues only, plus anything needing a decision or escalation. Senior stakeholders should see the vital few, not the full list.

Adjust frequency to project pace: a fast-moving delivery in a critical phase may warrant more frequent touchpoints; a stable, slow-burn project may need less.

## How to run the meeting

Keep it tight and disciplined:

1. **Prepare beforehand.** The delivery manager chases owners for updates before the meeting, so time isn't wasted gathering basic status live.

2. **Triage new items first.** Add anything raised since last time, assign an owner and an initial status.

3. **Walk the priorities, not the whole list.** Focus on reds, ambers, items near a committed date, and anything that's changed. Don't read every green item aloud, that's how reviews become unbearable and get cancelled.

4. **Update honestly.** For each item discussed: has likelihood or impact changed, is the mitigation working, has a dependency slipped, can it be closed?

5. **Decide escalations.** Identify what the team can't resolve alone and route it up the escalation path with a clear ask.

6. **Confirm actions and owners.** Every discussed item leaves with a clear next step, an owner and a date.

## What to do with stale and closed items

Discipline around closure keeps the log usable:

- **Close completed items promptly.** A log clogged with resolved entries hides the live ones. Mark them closed with a brief note of how, then archive.

- **Challenge stale items.** If something hasn't moved in several reviews, ask why. Either it needs action, it needs escalation, or it isn't really a live concern and should be closed.

- **Flag overdue actions.** An action past its date with no progress is a signal, surface it, don't let it slide quietly.

## Common review-meeting failures

- **Reading the entire log line by line.** This drains energy and trains people to dread the meeting. Focus on the vital few.

- **No preparation.** Gathering basic status live wastes everyone's time. Chase updates beforehand.

- **Logging without deciding.** A review that only notes status, without making decisions or assigning actions, is admiring the problem rather than managing it.

- **Inconsistent timing.** Skipping or constantly rescheduling the review breaks the habit and lets the log rot.

- **Wrong audience, wrong depth.** Don't drown the steering group in operational detail, or expect the team review to make board-level decisions.

## Keep the log trustworthy between reviews

The meeting is a checkpoint, not the only time the log is touched. Owners should update their items as things change, and anyone should be able to raise a new item the moment they spot it. The review then becomes a moment to consolidate, prioritise and decide, rather than the single point where the log briefly comes alive.

At neart.ai we build enterprise-grade delivery and PMO products, and the clearest signal of a well-run delivery is a RAID log that's obviously *current*, recently updated entries, prompt closures and a steady review rhythm, rather than a comprehensive log nobody has touched in weeks.

## Practical takeaway

Set a fixed weekly RAID review for the delivery team and lighter summary reviews for senior stakeholders. Prepare in advance, focus on the vital few rather than reading the whole list, make decisions and assign dated actions, and close completed items promptly. Consistency, not length, is what keeps the log alive and worth trusting.