Projects are a bit like road trips. You need a map, snacks, fuel, and someone to say, “Wait, did we book the hotel?” A RAID log is that helpful someone. It keeps track of the things that can help or hurt your project, before they turn into chaos with a calendar invite.
TLDR: A RAID log is a simple project management tool that tracks Risks, Assumptions, Issues, and Dependencies. For example, if your website launch depends on legal approval, that goes in the dependency section. In one small marketing team, using a RAID log cut surprise delays by about 30% over three months because problems were spotted earlier. It is easy to create, easy to update, and very useful in weekly meetings.
What Is a RAID Log?
A RAID log is a project document used to track four important areas:
- Risks: Things that might go wrong.
- Assumptions: Things you believe are true, but have not fully confirmed.
- Issues: Problems that are happening right now.
- Dependencies: Things your project needs from someone or something else.
Think of it as your project’s “watch list.” It does not run the project for you. Sadly, it will not make coffee either. But it will help your team see what needs attention.
A RAID log is often used by project managers, product teams, marketing teams, construction teams, software teams, and operations teams. It works for big projects. It also works for small ones.
Why Is a RAID Log Useful?
Projects fail for many reasons. People miss deadlines. Vendors get delayed. Budgets shrink. Approvals get stuck in someone’s inbox forever.
A RAID log helps because it makes hidden problems visible. It gives the team one place to check what is risky, blocked, unclear, or dependent on others.
Here is what it can do:
- Reduce surprises: You spot trouble early.
- Improve communication: Everyone sees the same information.
- Support decisions: Leaders can act with better context.
- Increase accountability: Each item has an owner.
- Save meeting time: You discuss what matters most.
Without a RAID log, teams often rely on memory. That is risky. Human memory is great for song lyrics from 2009. It is less great for tracking six vendor approvals.
The Four Parts of a RAID Log
1. Risks
A risk is something that might happen and could affect the project. It has not happened yet.
Example: “The designer may not finish the homepage draft by Friday.”
For each risk, you should note the likelihood, impact, owner, and action plan. This helps the team decide what to do before the risk becomes a fire.
2. Assumptions
An assumption is something the team believes to be true. But it still needs to be checked.
Example: “We assume the client will provide product photos by Monday.”
Assumptions can be sneaky. They feel safe until they are wrong. Then everyone says, “Oh. We thought…” That is never a good project sentence.
3. Issues
An issue is a problem that is happening now. It is not a maybe. It is real.
Example: “The payment gateway is failing during checkout testing.”
Issues need clear owners and deadlines. They should be reviewed often until closed.
4. Dependencies
A dependency is something your project relies on. It may be a person, team, system, vendor, document, or decision.
Example: “The launch depends on finance approving the final budget.”
Dependencies matter because your team may not control them. That means you need to track them closely.
How to Create a RAID Log
Good news. You do not need fancy software to create a RAID log. A spreadsheet works fine. A shared document works too. A project management app is also great.
Follow these simple steps:
- Create four sections: Risks, Assumptions, Issues, and Dependencies.
- Add key columns: Include owner, status, priority, date raised, due date, and next action.
- Collect input: Ask the team what could go wrong, what is blocked, and what is unclear.
- Assign owners: Every item needs one person responsible for follow-up.
- Set review dates: Review the log weekly, or more often for fast projects.
- Update status: Mark items as open, in progress, resolved, or closed.
- Archive old items: Keep history, but do not let the log become a dusty attic.
Simple RAID Log Template
Here is a basic template you can copy into a spreadsheet:
| Type | Description | Owner | Priority | Status | Next Action | Due Date |
|---|---|---|---|---|---|---|
| Risk | Client feedback may arrive late. | Project Manager | High | Open | Confirm review date with client. | May 10 |
| Assumption | Sales team will provide final pricing. | Sales Lead | Medium | In Progress | Send reminder. | May 8 |
| Issue | Test server is offline. | Tech Lead | High | Open | Contact hosting support. | Today |
| Dependency | Launch depends on legal approval. | Legal Contact | High | Pending | Schedule approval meeting. | May 12 |
RAID Log Example: Website Launch
Let’s say your team is launching a new website in six weeks. Exciting. Also slightly scary. Here are some RAID log entries you might use:
- Risk: The content team may not finish all service pages on time.
- Assumption: The client will approve the design within three business days.
- Issue: The contact form is not sending email notifications.
- Dependency: The analytics setup depends on access from the IT team.
Now the team can talk about these items in weekly check-ins. No guessing. No “I thought you had it.” No dramatic music needed.
Best Practices for Using a RAID Log
A RAID log only works if people use it. Treat it like a living tool, not a museum piece.
Keep It Simple
Do not add 40 columns unless you enjoy confusing everyone. Start with the basics. Add more only if needed.
Use Clear Language
Write short descriptions. Avoid vague entries like “client stuff.” That helps nobody. Say what the problem is and what needs to happen next.
Review It Often
For most projects, review the RAID log once a week. For urgent projects, review it twice a week or daily. The faster the project moves, the faster risks can grow legs.
Assign One Owner Per Item
If everyone owns it, no one owns it. Each RAID item should have one clear owner. Other people can help, of course. But one person must lead the follow-up.
Focus on Action
A RAID log is not just a list of worries. Every open item should have a next step. If there is no action, ask why it is on the log.
Use Priority Levels
Mark items as High, Medium, or Low. This helps the team focus on the big stuff first. Not every issue deserves a red alarm and a group panic.
Common RAID Log Mistakes
Even good teams can misuse a RAID log. Watch out for these traps:
- Not updating it: An old RAID log is just project archaeology.
- Adding too much detail: Keep it useful, not exhausting.
- No owners: Items without owners drift forever.
- Ignoring assumptions: Bad assumptions can become big issues.
- Only reviewing risks: Remember all four parts of RAID.
Final Thoughts
A RAID log is simple, but powerful. It helps your team see risks, check assumptions, solve issues, and manage dependencies. It also makes meetings better because everyone can focus on facts and actions.
You do not need to be a project management wizard. Start with a spreadsheet. Add your first few items. Review them each week. Soon, your project will feel less like a mystery novel and more like a plan.