How often should a RAID log be reviewed?
Most projects review the RAID log weekly, alongside the status report, and run a deeper pass monthly. The weekly review looks at overdue actions, anything scored high and anything raised since the last one — not every row. Reviews also happen on demand when scope, dates or ownership change, and daily during a cutover window.
Three cadences, doing different jobs
Asking how often a RAID log should be reviewed hides a second question: reviewed for what. The weekly working review, the monthly full pass and the event-driven review look at different subsets of the same log and produce different outputs. Running only one of them is where logs go stale.
The weekly review
This is the one that keeps the log alive, and it usually sits immediately before the status report is written, because the report reads from the log. It does not go row by row. On a log of two hundred items, going row by row takes ninety minutes and teaches nobody anything.
What gets looked at:
- Anything raised since the last review, so it can be scored and given an owner before it drifts.
- Anything with an action past its due date.
- Anything scoring above the agreed threshold, regardless of whether it moved.
- Anything a workstream lead flags as changed.
- Items proposed for closure, which need a resolution written before the status changes.
Fifteen to thirty minutes covers that on most projects. The output is a set of updated next actions and due dates, not a discussion of every risk in the log. What feeds through into the weekly status report is the top few by score plus anything that has moved colour.
The monthly pass
Once a month somebody goes through the whole log, including the parts nobody has looked at. This is slower and it is the review that finds the real problems.
| Check | What it usually surfaces |
|---|---|
| Rows not updated in 30 days | Items that were logged to be seen logging them, and have had no owner attention since |
| Assumptions past their validate-by date | Assumptions that are now facts, or now risks, and are still recorded as assumptions |
| Risks that have already occurred | Rows that should have been converted to issues, sometimes weeks ago |
| Closed items with no resolution text | An audit trail with a hole in it, and nothing for the lessons learned log to read later |
| Owners who have left or changed role | Rows with an owner who cannot act on them |
| Scores set at the start and never revisited | A register sorted by a judgement that was made under different information |
The monthly pass is also where duplicates get merged. Two people log the same integration risk in different words, both get owners, and each thinks the other is covered.
Event-driven reviews
Some changes make the log wrong immediately, and waiting for Friday means reporting a position that no longer holds. The common triggers:
- A milestone date moves, which changes the impact of anything that depended on it.
- A change request is approved, adding scope that carries its own risks and dependencies.
- A vendor, supplier or key person changes.
- An issue is raised at severity one.
- The programme enters a new phase — the risks of a build phase and a test phase are barely the same list.
None of these need a full review. They need the affected rows revisited and rescored, and the new items logged with an owner the same day.
What changes near go-live
In the final weeks the cadence tightens, because the window for mitigating anything is closing. Many programmes move to a short daily check of open issues and anything blocking a readiness criterion, while keeping the weekly review for risks. During the cutover window itself the RAID log largely stops being the working document — the cutover runbook takes over, with issues raised against runbook tasks and triaged in the bridge call. Anything unresolved at the end of the window comes back into the RAID log as a hypercare item.
Signs the cadence is not working
A log that is reviewed on paper but not in practice has recognisable symptoms. Every row has the same last-updated date, which is the date of the last review, because someone bulk-touched them. Nothing has closed in six weeks. New items stop being logged at all, which is not the same as there being fewer of them — it usually means the team has decided the log is an administrative exercise. Or the log grows steadily and never shrinks, because closure requires writing a resolution and nobody has time.
The cheapest correction is usually to reduce what the weekly review covers rather than to hold it less often. A ten-minute review that reliably happens beats a monthly hour that keeps being moved.
Who runs it
The project manager normally chairs the review; the owners bring their own rows. On a programme with workstreams, each lead reviews their own log weekly and the programme review looks only at items above a threshold or flagged for escalation. That structure is covered in more detail in programme governance. The RAID Log Template (Excel) flags stale and overdue rows automatically, which is what makes a short weekly review possible; the RAID Log & Program Governance Pack adds the action log and status report that the review feeds.
Questions
Can the RAID review be part of another meeting?
Commonly it is folded into the weekly delivery or workstream call. That works as long as it has its own slot and the log is on screen, rather than being reduced to asking whether anyone has new risks.
How long should a weekly RAID review take?
Fifteen to thirty minutes on most projects, because it covers new, overdue, high-scoring and proposed-closure items rather than the whole log.
Should closed items be deleted?
No. They stay with their status set to closed and a resolution recorded. The closed set is what the lessons learned log and any audit read from.
Does the cadence change for a small project?
The monthly pass often merges into the weekly review when the log is under about thirty rows, since reviewing everything is no longer expensive.