A RAID log is a single document where a project team records four categories of problems: risks that might happen, assumptions the plan depends on, issues happening right now, and decisions that have been made

The name comes from the first letter of each category: Risks, Assumptions, Issues, and Decisions. Instead of these things scattered across emails, Slack messages, and meeting notes, a RAID log puts them in one place that everyone on the team can see and update. This matters because a risk nobody mentioned in a meeting might derail the project three weeks in, and an assumption that turned out to be wrong often does not get flagged until it costs time and money to fix.

A RAID log is usually a straightforward spreadsheet or a table in a shared document. Each row is one item. The columns typically show what the item is, who is watching it, when it was added, what status it has now, and what the team plans to do about it. Some teams add a column for how serious it is — a risk that would stop the whole project ranks higher than one that would slow down one task.

Key Takeaways

  • A RAID log collects risks, assumptions, issues, and decisions in one document so nothing gets forgotten in email threads or meeting notes.
  • Each entry names the problem, who is responsible for watching it, and what the team will do about it, with a status that updates as things change.
  • The log is most useful when the whole team can see it and adds to it during meetings and between them, not just when a manager updates it alone.
  • Reviewing the RAID log at the start of each meeting keeps problems from being overlooked and shows the team what has been resolved since last time.

The four categories and what goes in each one

Risks are things that might happen and would hurt the project if they do. A team member might leave in the middle of a phase. A vendor might not deliver on time. A feature might turn out to be harder to build than the estimate said. The point of listing a risk is not to panic — it is to name it early so the team can plan what to do if it occurs. Some teams add a backup plan to each risk row, like "if the vendor delays, we will use the older API instead."

Assumptions are things the plan takes for granted. The project assumes the client will approve the design by a certain date. It assumes the database can handle the expected number of users. It assumes the team will have access to a particular tool or system. Assumptions often hide in the background until they turn out to be wrong. Writing them down makes it possible to test them early — to ask the client about the approval timeline or run a load test on the database before the project depends on it.

Issues are problems that are happening now, not things that might happen. A team member is sick and will miss a week. A piece of software broke and needs to be replaced. A stakeholder changed their mind about a requirement. Issues need faster action than risks because they are already affecting the work. The RAID log tracks what the team is doing to fix each one and when it should be resolved.

Decisions are choices the team or leadership has made that affect the project. We decided to use this technology instead of that one. We decided to cut this feature from the first release. We decided to hire a contractor for this part. Recording decisions in the RAID log means the team has a record of why something was chosen, and new team members can see what was decided without having to ask.

How to set up and maintain a RAID log

Start with a spreadsheet or a table in a shared document that everyone on the team can open and edit. The columns you need are: item name or description, category (Risk, Assumption, Issue, or Decision), owner or person responsible, date added, status, and action or plan. Some teams add a severity or priority column so high-impact items stand out. Keep it straightforward — a RAID log that is too complicated will not get used.

Add items as they come up, not just at the start of the project. During meetings, when someone says "we are assuming the client will approve this by Friday" or "I am worried the database might not scale," that is a moment to add a row. Between meetings, team members can add items they notice. The log should feel like a living document that grows as the project unfolds.

Review the RAID log at the beginning of each team meeting or status check-in. Go through each item, update the status, and decide what happens next. If a risk has been managed or an issue has been resolved, mark it as closed. If an assumption has been tested and confirmed, move it off the active list. This keeps the log from becoming a graveyard of old items that nobody reads anymore.

Why RAID logs prevent surprises and rework

Without a RAID log, problems stay invisible until they blow up. A risk that nobody mentioned in a meeting might not surface until it actually happens — by then it is too late to plan around it. An assumption that was never written down might be different for different team members, and the project discovers the mismatch halfway through. An issue that one person is handling might not be known to the rest of the team, so they keep working on something that depends on it being fixed.

A RAID log makes these things visible early. When a risk is named and tracked, the team can decide whether to avoid it, reduce it, or accept it and plan for it. When an assumption is written down, it can be tested before the project depends on it. When an issue is logged, everyone knows about it and can adjust their work if needed. This prevents the kind of rework and delay that comes from discovering problems late.

Common mistakes when using a RAID log

The most common mistake is letting one person own the RAID log while everyone else ignores it. If only the project manager updates it, the log becomes out of date and the team stops trusting it. The log works best when team members add items themselves and feel ownership of the problems listed.

Another mistake is adding too many items and never closing any. A RAID log that has 50 open risks and issues becomes noise — people stop reading it because nothing ever seems to get resolved. Review the log regularly and close items that have been handled. If something is truly resolved, take it off the active list.

A third mistake is treating the RAID log as a place to blame people. If an issue row says "John missed the important date," that creates defensiveness and makes people less likely to report problems. Instead, frame issues as things the team is solving together: "Database performance testing delayed by two weeks; team is running tests this week to unblock the next phase."

RAID logs in different project types

In software projects, RAID logs often track technical risks like performance bottlenecks or integration problems, assumptions about how users will behave, issues like bugs or broken dependencies, and decisions about architecture or technology choices. In construction or facility projects, they might track weather delays, assumptions about site conditions, issues with permits or inspections, and decisions about materials or contractors.

The structure stays the same across different types of work. What changes is what kinds of risks, assumptions, issues, and decisions matter for that particular project. A marketing campaign might track the risk that a competitor launches something similar, the assumption that the target audience will see the ads, an issue with a vendor not delivering assets on time, and a decision to change the messaging. The RAID log format works because it is flexible enough to fit any project.

Frequently Asked Questions

Should every item in a RAID log have an owner?

Yes. If nobody is responsible for watching an item or taking action on it, it will be forgotten. The owner does not have to be the person who solves the problem — they just need to track it, update the status, and make sure something is happening. Without an owner, items sit in the log and nothing changes.

How often should a team review the RAID log?

At minimum, once per week or at each team meeting. Projects that move fast or have high risk might review it more often. The point is to keep it current so the team trusts what is in it. If the log has not been updated in two weeks, people will stop looking at it.

Can a RAID log replace a project timeline or task list?

No. A RAID log tracks problems and decisions, not the work itself. You still need a timeline or task list to show what work needs to happen and when. The RAID log sits alongside those tools and helps the team manage the things that could go wrong or change along the way.

What should happen to a RAID log after the project ends?

Keep it. After the project closes, the RAID log becomes a record of what risks actually happened, what assumptions turned out to be true or false, and what decisions were made. This information is valuable for the next similar project — you can see which risks you should watch for again and which assumptions to test earlier.