What’s a RAID log? Think of it as the solution to your project management organizational woes.
Instead of combing through your old meeting notes to find a record of past decisions or wishing you had documented the assumptions behind that pesky requirement that is now giving you grief, a RAID log offers a single repository of project risks, assumptions or actions, issues, and dependencies or decisions that you can quickly share with your stakeholders.
What Is A RAID Log In Project Management?
In case you’re having trouble keeping track of the many tricks of the project management trade, here’s a quick refresher on RAID logs. A RAID log is a project document that summarizes the following key pieces of information:
- Risks
- Assumptions or actions
- Issues
- Dependencies or decisions
As a project manager, you can use a RAID log to keep your stakeholders—and yourself—straight on the latest project deets. When executed well, a RAID log can act as a key strategy document for summarizing project health at the leadership level.
A quick interlude here:
What Does ‘RAID’ In RAID Log Stand For?
Let’s define each of the components of the RAID acronym, along with a few practical examples to help you contextualize.
| RAID Log Component Definition | Examples |
|---|---|
| Risks. Identify and categorize risks and opportunities, their probability of occurrence, their impact/severity should they occur, and the mitigation plan and actions | - Inclement weather delays data collection schedule |
| Assumptions or Actions. Document project parameters to prevent scope creep; maintain a “to do” list based on ongoing project work | - Assumption: required resources are available to execute project work - Action: engage with finance team for a cost breakdown of existing third party suppliers |
| Issues. Document events that have occurred that impact project progress and explain the path to resolution | - A security breach compromises the integrity of customer data |
| Dependencies or Decisions. List activities that cannot be started or completed without another activity being started or completed; document previously agreed upon courses of action and the rationale for pursuing or failing to pursue them | - Dependency: conduct alternatives analysis prior to procuring new vendor management system - Decision: build in-house talent management system to maintain focus on high-performance culture, even though this will be more costly in the short-term |
You’ll see that the definition of RAID includes some dual acronyms: assumptions or actions, dependencies or decisions. Here are my hot takes on how to approach these in your RAID log:
- Assumptions vs. Actions. I can’t tell you how many times having a list of assumptions stopped scope creep in its tracks. If you’d like to keep your RAID log geared towards a senior audience, I’d recommend keeping action items in a separate document focused on tactical execution.
- Decisions vs. Dependencies. In my experience, no one ever remembers why decisions were made; specifically, the alternatives considered but rejected and the reasons why. To avoid circular thinking over the course of a lengthy engagement, I’d recommend documenting decisions in your RAID log in addition to dependencies.
RAID Log vs Risk Register
RAID logs may be confused with risk registers or risk logs as there is some overlap between the two. The difference is that a RAID log is more comprehensive. In addition to documenting risks, a RAID log also includes assumptions or actions, an issues log, and dependencies or decisions.
RAID Log Template
We’ve included a download of a RAID log template in Microsoft Excel (you'll need to be a member to get the template). You can use this template to document risks, assumptions, issues, and dependencies. Columns M and N track decisions and the decision date.
RAID Log Sample And Examples
In addition to the RAID log template, we’ve also included an example Excel RAID log so you can get a feel for the finished product (you'll need to be a member to access this as well).
How To Create A RAID Log
Now that you’ve got your template ready to go, how exactly do you go about populating your RAID log? During the project planning phase, you’ll be able to source content for the following components of your RAID log:
- Risks
- Assumptions
- Dependencies
Actions, issues, and decisions don’t come into play until after the project begins.
Potential Sources Of Content For A RAID Log
You can source content for a RAID log from multiple channels:
- Stakeholder interviews
- Current or prior project documentation
- Examples: lessons learned, retrospectives, post mortems, project charters, project plans, project schedules
- Prior experience executing similar projects
- Open source materials online
- Critical thinking based on information you’ve gleaned from the above sources (e.g., your stakeholders aren’t explicitly saying something is a pain point, but their reluctance to address the topic suggests this area would benefit from additional discovery.)
How To Use RAID Logs
Once your project starts, and you’ve got your draft RAID log ready to go, keep in mind these best practices for how to use the RAID log while managing your project:
- Tune to the appropriate level of detail for the audience. Stakeholders rely on the RAID log to understand the context for this project and any risks or issues that may threaten project success. Keep the focus on business impacts, rather than tactical updates that may not be meaningful to someone who is not engaged in the day-to-day.
- Monitor and update the RAID log throughout the project lifecycle. This artifact is useless if you don’t update it. That’s another reason to keep the content concise so that the document is not onerous to maintain. Most of your time should be spent unblocking problems, rather than documenting them.
How Are RAID Logs Used In Agile?
Typically, agile projects tend to shy away from documentation in favor of developing a working product. That being said, I’d contend that developing a RAID log is worth the extra effort.
The reason? Agile projects typically follow an iterative approach to project execution that invites greater experimentation. This approach is great for failing fast to generate learnings more quickly.
Yet, destigmatizing failure introduces additional risks that could derail your project. And, an organization can only learn from failure if it documents the assumptions and decision-making that informed each experiment.
In this way, the RAID log is an effective tool for risk management and managing projects.
RAID Log Benefits
RAID logs benefit stakeholders, project team members, the business, and you as the project manager.
- Stakeholders: Access a one-stop-shop for pertinent project information that readily offers real-time insights into project health
- Project Team: Assign junior project managers the task of updating the RAID log as a training tool for managing future projects of their own someday
- Business: Track risks (ideally before they become issues); quickly triage issues if risks are realized
- Project Manager: Document assumptions and decisions to mitigate the risk of having to backtrack on discussions that may delay the project.
What’s Next?
Looking for more project management tools and tips? Check out my blog and newsletter, and don’t forget to subscribe to The Digital Project Manager newsletter for more on how you can get on top of risk management as a project manager.
Related Listen: What's A RAID Log (And How To Integrate One Into Your Project Workflow)