Risks Actions Issues Decisions

RAID is a project-management acronym for a running log tracking a project's key items — but the letters don't always mean the same thing: this skill covers the Risks, Actions, Issues, Decisions expansion; Project Management's own RAID-log coverage uses the equally common Risks, Assumptions, Issues, Dependencies expansion instead. Both are real, widely-used conventions — confirm which one a specific team or document means before assuming, since "A" and "D" mean genuinely different things between the two.

The four components (this expansion)

• Risks — potential events that could negatively affect the project. Logged with likelihood, potential impact, and the planned mitigation or management approach.
• Actions — tasks needed to keep the project on track. Logged with the responsible owner, target completion date, and current status.
• Issues — problems that have actually arisen during the project and need addressing. Logged with impact on the project, the responsible owner, and status.
• Decisions — choices the project team has made that affect the project's direction. Logged with who made the decision, when, and its impact.

Risks vs. Issues (the distinction both RAID variants share)

A risk hasn't happened yet — it's a possible future event with a likelihood and potential impact. An issue has already happened and needs active resolution. Conflating the two on the log — treating an already-materialized problem as still just a "risk," or logging a speculative concern as an urgent "issue" — undermines the log's ability to prioritize attention correctly.

Why log Actions and Decisions specifically (vs. Assumptions/Dependencies)

This expansion's distinctive value: it tracks not just what could go wrong (Risks, Issues) but the concrete work needed (Actions) and the choices already made (Decisions) — useful for a project where tracking accountability for follow-through and maintaining a clear decision history matters as much as tracking risk. The Assumptions/Dependencies variant instead emphasizes what's being taken on faith and what the project needs from outside itself — a genuinely different (and also useful) emphasis; see Project Management for that version.

Why a RAID log matters

Lets a project manager proactively identify potential risks and act on them before they become major issues, provides one central location for project-critical information so nothing falls through the cracks, and serves as a communication tool keeping stakeholders informed of progress and concerns — an unmaintained or unreviewed RAID log, regardless of which expansion is used, functions as paperwork rather than an actual control (see Project Management's identical warning).

Common pitfalls

• Assuming everyone means the same RAID expansion — given two genuinely common, different expansions exist, confirm before assuming; a decision logged where a reader expected a dependency (or vice versa) causes real confusion.
• Conflating risks and issues — see above; this blurs the log's ability to help prioritize what needs attention now versus what needs monitoring.
• Logging decisions with no rationale — recording that a decision was made without why loses the context a later reader needs to understand or revisit it.
• A RAID log nobody reviews — as in Project Management's identical warning, logging isn't managing; a review cadence and clear ownership per item is what makes the log an actual control.

Learn more

• Project Management for the Risks/Assumptions/Issues/Dependencies expansion of the same acronym.
• Decision Records, Architecture Decision Record for a more structured way to document the "Decisions" component specifically.
• Key Risk Indicators for ongoing organizational risk monitoring, as distinct from this project-scoped risk log.