RAID Log: The One Document Every Project Manager Needs (But Most Skip)
Contact Us
What Even Is a RAID Log?
RAID log stands for Risks, Assumptions, Issues, and Decisions.
It is a single living document, could be a spreadsheet, could be a dedicated tool where your entire team captures the four things most likely to derail a project before anyone even notices they are a problem.
Think of it as your project's early warning system. While your project plan tells you what needs to happen, your RAID log tells you what could go wrong and what already has.
The concept originally came from PRINCE2, a structured project management methodology developed in the UK. But today, teams across industries and frameworks, waterfall, agile, hybrid — use RAID logs because the problems they solve are universal.
Every project has risks. Every team makes assumptions. Every project hits issues. Every project needs decisions. The only question is whether yours are documented.
Why Most Projects Skip It (And Pay the Price)
Here is the honest truth: RAID logs feel like extra work at the start of a project.
You are already dealing with stakeholder expectations, kick-off meetings, resource planning, and a timeline that someone has already decided is too short. Adding another document to maintain feels like bureaucracy.
So teams skip it.
And then three months in, something breaks. A key assumption turns out to have been wrong. A risk that someone mentioned in passing in Week 2 has now become a full-blown crisis. A vendor dependency nobody tracked is now blocking the entire release.
And the project manager probably you is stuck explaining to leadership why nobody saw this coming.
The painful irony is that a RAID log takes about 30 minutes to set up and maybe 15 minutes a week to maintain. The problems it prevents can cost weeks of delay and thousands of dollars in rework.
It is the cheapest insurance policy in project management.
Let's Break Down Each Letter
R Risks
A risk is anything that might happen that would negatively affect your project.
The key word is might. A risk has not happened yet. It is a future threat you are aware of and can prepare for. This distinction matters because the way you handle a risk is very different from the way you handle You have a project plan. You have a timeline. You have a budget.
And yet somehow the project still goes sideways.
A vendor misses a deadline nobody tracked. A team member made an assumption that turned out to be completely wrong. A decision got made in a meeting three months ago and now nobody remembers what was actually decided.
Sound familiar?
This is not a planning problem. This is a visibility problem. And there is one tool that fixes it.
It is called a RAID log.
something that has already gone wrong.
Examples of real project risks:
For each risk, you want to record three things: how likely it is to happen, how bad it would be if it did, and what your plan is if it does.
A risk with high likelihood and high impact is your top priority. A risk with low likelihood and low impact can sit on the list but does not need your attention today.
The goal is not to eliminate all risk that is impossible. The goal is to never be surprised by one.
A Assumptions
This is the one most teams underestimate.
An assumption is something your team is treating as true without actually confirming it. Assumptions are everywhere on every project and they are dangerous precisely because they feel like facts.
"We are assuming the client's IT team will handle the hardware setup."
"We are assuming the budget for Phase 2 has already been approved."
"We are assuming the integration with their CRM will work out of the box."
Each of those sentences sounds reasonable. Each of them has derailed a real project when it turned out to be wrong.
When you write down your assumptions, two things happen. First, someone will look at the list and say "wait, have we actually confirmed that?" which is exactly the right question to ask. Second, if an assumption does turn out to be wrong mid-project, you have a documented record of when it was made and who made it. That is not about blame it is about understanding what happened and learning from it.
What to record for every assumption:
I Issues
An issue is a risk that already happened.
It is a problem on your plate right now. Not a potential problem, an actual one that needs attention, has an owner, and needs a resolution plan.
Examples:
A supplier has delivered the wrong specifications and the fix will take two weeks
A stakeholder who needs to approve the design has been unreachable for ten days
A critical piece of equipment arrived damaged and a replacement is three weeks out
The difference between a risk and an issue sounds obvious: one is potential, one is real but in the chaos of a live project, teams often handle them the same way. They talk about issues in meetings, someone nods, and then nothing gets written down, no one is formally accountable, and the issue quietly sits there until it becomes a crisis.
Your RAID log forces you to treat every issue like it has an owner, a status, and a deadline for resolution. That structure is what gets things fixed.
D Decisions
Every project involves dozens of decisions. What scope gets cut. Which vendor gets chosen. Which approach gets taken when two options are on the table. Which stakeholder has final sign-off authority.
In most projects, these decisions live in someone's memory or in a long email chain nobody can find.
Six months later, when someone questions why a certain call was made, or when a new team member joins and asks why the product works the way it does, there is no record. People remember different things. Disagreements surface. Time gets wasted relitigating choices that were already made.
A decision log solves this completely.
For every key decision, record what was decided, when, who made the call, and this is the part most people skip why. The rationale behind a decision is often more valuable than the decision itself, especially when circumstances change and you need to revisit it.
Note on the D: Some teams use D for Dependencies rather than Decisions external things your project relies on that are outside your direct control. Others track both. The right call depends on your project. If dependencies are a major factor (your project involves multiple teams or third-party timelines), track them. If decisions are the bigger risk, focus there. You can always do both with a simple prefix in your log (D-DEC for decisions, D-DEP for dependencies).
What a Real RAID Log Looks Like
Here is a sample from a fictional but realistic scenario: a company rolling out a new customer support platform across four regional offices.
The project is eight months long, involves three internal teams, two external vendors, and about forty end users.
Risk Log
| ID | Description | Likelihood | Impact | Owner | Mitigation Plan | Status |
|---|---|---|---|---|---|---|
| R-01 | Vendor A has only one technical contact — if unavailable, integration work stops | High | High | Maya (PM) | Request backup contact from vendor by Week 2 | Open |
| R-02 | Office 3 network infrastructure may not support the new platform's bandwidth requirements | Medium | High | Dev Team | IT audit scheduled for Week 3 | In Review |
| R-03 | End-user adoption may be low if training is not completed before go-live | Medium | Medium | HR Lead | Training plan to be finalised by Week 5 | Open |
Assumption Log
| ID | Description | Owner | Impact if Wrong | Validated? |
|---|---|---|---|---|
| A-01 | Client will provide sample data for testing by end of Week 4 | Maya (PM) | High testing delayed by minimum 2 weeks | Not yet |
| A-02 | All four offices are running the same version of the existing CRM | Dev Team | High may require separate integration work per office | Confirmed Week 1 |
| A-03 | Budget approval for hardware upgrades in Office 3 is already in place | Finance Lead | High Office 3 go-live blocked | Pending confirmation |
Issue Log
| ID | Description | Raised | Owner | Priority | Resolution Plan | Status |
|---|---|---|---|---|---|---|
| I-01 | Vendor B has not responded to integration spec queries for 8 days | Week 3 | Maya (PM) | High | Escalate to Vendor B account manager by Friday | Active |
| I-02 | Office 2 lead has not attended last two project meetings — sign-off may be at risk | Week 4 | Maya (PM) | Medium | Direct outreach from project sponsor | Active |
Decision Log
| ID | Decision | Date | Made By | Rationale |
|---|---|---|---|---|
| D-01 | Office 4 moved from Phase 1 to Phase 2 due to ongoing renovation works | Week 2 | Project Board | Site access not available until Month 5 delaying whole project for one office not justified |
| D-02 | Vendor A selected over Vendor C despite higher cost | Week 1 | Project Sponsor | Vendor A has existing integration with legacy CRM; Vendor C would require custom build adding 6 weeks |
This is what a healthy RAID log looks like in Weeks 3 and 4 of a mid-size project. It is not overwhelming. It is not bureaucratic. It is just a clear, honest picture of where things stand.
How to Set Up Your RAID Log in 6 Steps
Step 1: Pick your format
The simplest RAID log is a Google Sheet or Excel file with four tabs one for each category. That is it. No special software required.
If your team already uses a project management tool like Jira, Notion, Asana, or Monday.com, you can build your RAID log there instead. Most tools support a table or database view that works perfectly.
The format matters far less than the habit. Start simple.
Step 2: Set up your columns
Every row in your RAID log needs at minimum:
For Risks: ID, Description, Likelihood (High/Med/Low), Impact (High/Med/Low), Owner, Mitigation Plan, Status
For Assumptions: ID, Description, Owner, Impact if Wrong, Validated? (Yes/No/Pending)
For Issues: ID, Description, Date Raised, Owner, Priority, Resolution Plan, Status
For Decisions: ID, Decision Made, Date, Decision Maker, Rationale
You can add more columns as your project demands target resolution date, linked risks, affected stakeholders. But start lean. You can always add columns; you cannot always get people to fill them in.
Step 3: Run a RAID kick-off session
The best time to populate your first RAID log is during or immediately after your project kick-off meeting — while everyone is in the room and the project is fresh in people's minds.
Run a quick 20-minute session with your team:
Ask everyone to answer these four questions out loud:
You will be surprised how much surfaces. Most teams walk away from a kick-off RAID session with 15 to 25 items — risks, assumptions, and decisions they knew about but had never formally documented.
Write everything down. Do not filter during the session. You can prioritise afterwards.
Step 4: Assign an owner to every single item
This is the most important rule in RAID log management.
Every item needs one named person responsible for it. Not "the team." Not "TBD." One person.
The owner is not necessarily the person solving the problem. They are the person responsible for making sure the item gets tracked, updated, and resolved. That is a different role and it is what keeps things from falling through the cracks.
If an item has no owner, it will not get resolved. That is not pessimism it is just how human accountability works.
Step 5: Review it every week
A RAID log that is only opened at kick-off is wallpaper.
Add a 10-minute RAID log review to your weekly project status meeting. Go through the open items. Check for updates. Add anything new that surfaced during the week. Close anything that has been resolved.
Ten minutes. Every week. That is the entire maintenance cost.
Step 6: Keep it clean
One thing that kills RAID logs is clutter. When the document becomes a graveyard of old issues and resolved risks that nobody ever closes, people stop engaging with it.
Close resolved items. Archive them in a separate tab or mark them clearly as closed. The active section of your RAID log should only show things that actually need attention right now.
A clean RAID log is a used RAID log.
RAID Log Mistakes That Kill Projects
Let's be direct about the ways teams mess this up because knowing the failure modes is just as valuable as knowing the setup.
Leaving items without an owner. Already covered this, but it bears repeating. Ownerless items are dead items. No exceptions.
Treating it as a one-time exercise. You set it up, it felt productive, and then it never got touched again. The kick-off session is step one, not the finish line.
Mixing up risks and issues. A risk needs a mitigation plan something you do to prevent it or reduce its impact. An issue needs a resolution plan something you do to fix it now. Treating them the same way means you are under-responding to issues and over-reacting to risks.
Making assumptions without validating them. Logging an assumption is only half the job. The other half is actually checking whether it is true. Your RAID log should include a "Validated?" column for assumptions and every open assumption should have a target date for confirmation.
Hiding it from stakeholders. Some project managers keep the RAID log as an internal document. That is a mistake. When stakeholders can see the risks and issues you are managing, two things happen: trust increases because they can see you are on top of things, and support materialises faster because decision-makers can see what is blocking progress.
Never closing anything. Items accumulate. The log becomes 200 rows of stale data. Nobody reads it anymore. Set a regular "housekeeping" date once a month at minimum to close resolved items and archive old decisions.
RAID Log vs Other Project Documents
Teams sometimes wonder how a RAID log relates to other documents they are already maintaining. Here is the quick breakdown.
RAID log vs Risk Register: A risk register is a deep-dive document focused exclusively on risks. It includes probability scores, financial impact estimates, detailed response strategies, and residual risk analysis. A RAID log is broader and faster it captures risks at a summary level alongside three other categories. For most projects, a RAID log is enough. For large, complex, or regulated projects, you may maintain both.
RAID log vs Issue Log: An issue log tracks only active problems in detail. A RAID log includes issues as one of four categories. If your project has a high volume of active issues, a dedicated issue log makes sense alongside your RAID log. For most projects, the Issues tab in your RAID log is sufficient.
RAID log vs Action Log: An action log tracks tasks and to-dos. A RAID log tracks risks, assumptions, issues, and decisions. They are different things though a RAID item will often generate an action that belongs in your action log.
The short answer: The RAID log is not trying to replace any of these documents. It is the high-level, fast-moving companion document that gives everyone team members, stakeholders, leadership — a clear picture of where things stand without wading through multiple detailed registers.
Does the RAID Log Work for Agile Teams?
Yes. Completely.
There is a misconception that RAID logs are a waterfall thing a PRINCE2 artefact that does not belong in agile environments. That misconception costs agile teams.
The problems a RAID log solves untracked risks, undocumented assumptions, unresolved issues, undocumented decisions exist in every project methodology. Sprints do not make these problems disappear. They just make them move faster.
In a scrum environment, your RAID log plugs into your existing ceremonies naturally:
Keep the agile RAID log light. You do not need 12 columns per row. Three to five is enough. The goal is visibility, not documentation for its own sake.
Who Should Own the RAID Log?
Typically the project manager but that does not mean the PM fills in every row.
The PM is responsible for making sure the log exists, gets reviewed regularly, and stays accurate. The content of the log is a team effort. Developers raise technical risks. The finance lead flags budget assumptions. The sponsor documents key decisions.
Think of the PM as the editor and the team as the contributors.
For larger programmes with multiple workstreams, each workstream lead can own their own RAID log, with the programme manager maintaining a consolidated view of the highest-priority items across all of them.
Your RAID Log Template (Copy and Use Today)
Here are the exact columns to set up across four tabs. Copy this into Google Sheets right now and you have a working RAID log in under five minutes.
Tab 1: Risks
| ID | Description | Likelihood | Impact | Owner | Mitigation Plan | Date Raised | Status |
|---|
Tab 2: Assumptions
| ID | Description | Owner | Impact if Wrong | Validated? | Validation Date | Notes |
|---|
Tab 3: Issues
| ID | Description | Date Raised | Owner | Priority | Resolution Plan | Target Resolution | Status |
|---|
Tab 4: Decisions
| ID | Decision | Date | Decision | Maker | Rationale | Impact on Project |
|---|
Status colour coding:
7 Questions People Always Ask About RAID Logs
Risks, Assumptions, Issues, and Decisions. Some teams use D for Dependencies instead of (or as well as) Decisions. The variation that works best depends on your project type.
A risk register goes deeper on risks alone probability models, financial impact, detailed response strategies. A RAID log is faster and broader, covering all four categories at a summary level. Most projects only need a RAID log. Complex or regulated projects maintain both.
At minimum, once a week during your project status meeting. Fast-moving projects in a critical delivery phase should update it more frequently daily standup is a good trigger for adding new issues in real time.
There is no magic number. A five-person project running three months might have 15 to 20 items across all four categories. A large programme might have 100 or more. The right size is "only things that actually matter." If everything feels important, nothing is.
Yes selectively. Sharing the full internal RAID log including all the "what-ifs" and raw team assumptions can cause unnecessary alarm. A curated view key risks, active issues, major decisions builds trust and keeps the client informed without overwhelming them. Many PMs maintain one full internal log and a summarised external version.
No. A status report tells stakeholders how the project is progressing against plan. A RAID log tells your team what to watch out for and what needs attention. They serve different audiences and different purposes. Some PMs pull a summary of top risks and active issues from the RAID log into their weekly status report that is a good practice.
Archive it. It becomes part of your project's historical record useful for post-project reviews, for informing future similar projects, and occasionally essential when questions arise months later about why certain decisions were made.
