RAID Log

A RAID log is a project tracking artifact that captures four categories of delivery threat in a single document: Risks, Assumptions, Issues, and Dependencies, so the team can manage them proactively throughout the engagement.

RAID stands for Risks, Assumptions, Issues, and Dependencies. It is broader than a risk register, which covers only the R column. It also supersedes a standalone issue log, incorporating issue tracking as one of its four categories alongside the others.

The four categories

Risks are events that have not happened yet but could damage the engagement if they do. Each risk entry should include a probability rating, an impact rating, a mitigation plan, and a named owner. Risks are forward-looking and require active monitoring, not just logging.

Assumptions are facts the team is treating as true without confirmation. Unvalidated assumptions are latent risks: if the assumption turns out to be wrong, the project is affected in a way that was not explicitly planned for. When an assumption proves false, it moves immediately to the Issues column and requires a resolution owner and target date.

Issues are problems that have already materialized and require active resolution. An issue is not a risk that might occur; it is something that has occurred and is affecting the project now. Each issue entry carries an owner, a resolution plan, and a target close date.

Dependencies are external factors the project relies on to proceed. A dependency on a client data migration, a third-party API, or a formal sign-off from a steering committee is a delivery constraint. Dependencies that are not tracked tend to block delivery without warning, because no single person on the team treated them as their responsibility to chase.

Why RAID logs fail in practice

A RAID log only works if someone owns it and it is reviewed in every status meeting. The most common failure mode is treating it as a one-time setup exercise at kickoff and never updating it. By week four, the log no longer reflects the real project. By week eight, it is ignored entirely.

The fix is structural: assign a single named owner, typically the engagement manager or delivery lead, schedule a weekly review cadence, and close or archive items when they are resolved. A RAID log reviewed once per week with five minutes of attention is more valuable than a comprehensive log that is updated monthly.

What a healthy RAID entry includes

• A short, concrete description. “Dependency on client to complete data migration by 15 July” is useful; “data risk” is not.
• An owner by name, not by role or team.
• A status and the date it was last updated.
• A mitigation or resolution action.
• A target resolution date for issues and dependencies.

Entries without owners and without resolution actions are documentation, not management.