RAID Logs: Bring Order and Control to Complex Projects

A RAID log gives project managers a single, structured view of the risks, assumptions, issues, and dependencies most likely to affect delivery before they be…

Topic: Project & Program Management

Why It Matters

Project complexity rarely announces itself clearly at the start. A mid-delivery conversation that surfaces a key dependency nobody had formally tracked, a stakeholder assumption that was never challenged, or a problem that quietly became a crisis: these are the moments that prompt experienced managers to reach for a RAID log. The tool exists precisely because the moving parts of a complex project rarely stay still long enough for informal tracking to work.

A RAID log captures four categories of uncertainty that most affect project delivery: Risks, Assumptions, Issues, and Dependencies. It is not a sophisticated technology or a proprietary methodology. It is a structured discipline, applied consistently, that prevents information from falling through the cracks between team members, workstreams, and stakeholder conversations. Used well, it shifts a project team from reactive firefighting to informed decision-making.

The tool is most commonly found in medium-to-large projects, cross-functional programmes, and any environment where multiple teams or vendors interact. But its value is not limited to scale. Even a modest six-week initiative benefits when there are stakeholders with different assumptions about what success looks like, or when external factors such as regulatory decisions or third-party deliverables sit outside the team's direct control.

Before reading further, consider three questions. First, are there uncertainties in your current project that different team members are tracking separately, in different formats, or not at all? Second, have you ever reached a project milestone and discovered that a dependency or assumption was never formally validated? Third, do your project status reports tend to surface issues only after they have already affected delivery? If one or more of these feels familiar, a RAID log is worth putting in place.

Origin and Underlying Logic

A RAID log is a structured project management tool designed to surface and track four specific categories: Risks (things that might go wrong), Assumptions (things the team is treating as true without confirmed evidence), Issues (problems that have already occurred and need resolution), and Dependencies (external factors or deliverables the project relies on from others). Some practitioners use extended versions, including RAIDO (adding Opportunities) or RAAID (adding Actions), but the core four categories remain consistent across most implementations.

The tool emerged from formal programme management methodologies, particularly those developed in the UK public sector during the 1980s and 1990s, with strong roots in PRINCE2 and related frameworks. Its underlying logic is straightforward: visibility precedes control. If a project team cannot see the full landscape of what might affect delivery, they cannot make informed decisions about priorities, resources, or escalation. The RAID log converts invisible complexity into a manageable and reviewable register.

It sits within a broader school of proactive project governance and is closely related to risk registers, issue logs, and assumption logs. What distinguishes a RAID log is the deliberate combination of all four categories into a single document. This encourages teams to see how risks, assumptions, issues, and dependencies interact, rather than treating each in isolation. An unvalidated assumption, for example, is often a risk in disguise. Seeing them in the same log makes that connection visible.

Structure and Application

The RAID log typically takes the form of a spreadsheet or table. The most common format uses a single log with a type column to distinguish between R, A, I, and D entries, alongside columns for a description, a named owner, a severity or priority rating, the current status, and a planned review or resolution date. Some teams use a dedicated tab for each category; others keep all entries in a single list and filter by type. Either approach works, provided the log is actively maintained rather than periodically assembled.

Each category serves a distinct purpose. Risks capture potential problems that have not yet materialised, along with their likelihood, impact, and a mitigation plan. Assumptions record the beliefs the project is operating on, which need to be validated before they silently become issues. Issues are live problems that require active resolution and a named owner. Dependencies identify deliverables or decisions the project needs from outside its direct control, whether from another team, a vendor, a regulator, or a wider programme.

The tool works at the project and programme level equally well. At the team level, it keeps track of the day-to-day complexity that would otherwise exist only in conversation. At the programme level, it becomes the basis for escalation and executive reporting: what needs a decision, what needs a resource, what is blocking progress. This dual function is one of the RAID log's most practical qualities. The same document that helps a project manager stay on top of weekly activity also provides the raw material for a steering committee briefing.

A RAID log is most effective when it is reviewed weekly, maintained in advance of governance meetings, and owned clearly by the project manager rather than treated as a shared document that nobody actively curates. The format is the easy part. The discipline of keeping it current is where most teams either succeed or quietly abandon the tool.

A useful first step before reading further: open a simple spreadsheet and create four columns labelled Risks, Assumptions, Issues, and Dependencies. Spend 20 minutes with your project team identifying two or three entries for each column. The exercise itself will quickly reveal how much complexity has been held informally, and it will also surface the question the deep dive answers in detail: how to prioritise, escalate, and maintain the log so it drives decisions rather than becoming a filing system.

FAQ

The following questions reflect what managers typically search for when encountering a RAID log for the first time.

Q: What does RAID stand for in project management?
A: RAID stands for Risks, Assumptions, Issues, and Dependencies. It is a structured tracking tool used by project managers to monitor the four categories of uncertainty most likely to affect delivery. Some teams use extended versions such as RAIDO (adding Opportunities) or RAAID (adding Actions), but the core four elements remain consistent across most implementations and methodologies.

Q: How is a RAID log different from a risk register?
A: A risk register focuses exclusively on potential future problems, their likelihood, and mitigation plans. A RAID log is broader: it also captures assumptions that need validation, live issues requiring active resolution, and external dependencies the project relies on. For straightforward projects, a risk register may be sufficient. For anything involving cross-functional teams, external vendors, or regulatory factors, a RAID log is usually more appropriate because it brings all four categories of uncertainty into a single view.

Q: How do I know if a RAID log is right for my situation?
A: If your project involves multiple teams or stakeholders with different assumptions about scope or success, or if you have deliverables that depend on decisions or outputs from outside your team's direct control, a RAID log is likely to add real value. It becomes especially useful when informal tracking is creating gaps: risks discussed but not recorded, or dependencies assumed to be on track without anyone formally monitoring them.

Q: Can a RAID log work for smaller or short-duration projects?
A: Yes, though the format should match the complexity. A short project with a small co-located team may need only a lightweight one-page log with a handful of entries. The discipline of capturing risks, assumptions, issues, and dependencies matters more than the formality of the document. Even a six-week project benefits from making implicit assumptions visible and ensuring someone owns each open issue.

Q: How often should a RAID log be updated?
A: Most project managers update their RAID log weekly, typically in advance of a project governance or team review meeting. The log should be reviewed at each meeting, not simply distributed. Entries that are resolved should be closed and dated rather than deleted, as the record of how issues were managed often becomes valuable during project retrospectives or audits. The deep dive covers how to structure reviews and maintain the log without it becoming a burden.