Unsure what a RAID log is? Or perhaps you need to implement one, but you're not sure where to start. If that's you, you've come to the right place.
RAID logs are a way of organizing project information for stuff that comes up in any project – stuff that can stop progress if not managed properly. So it's a way of organizing and managing items that are not created as part of scope, schedule and budget, but could impact any or all of those.
In this article, we'll explain what goes into making a RAID log, together with some benefits and drawbacks of using them. We'll also walk through a simple way to create a RAID log for your business or project in just a few minutes.
RAID log defined: A letter-by-letter explanation
A RAID log is a project management tool that tracks four important areas in a given project. The RAID acronym stands for (note the dual acronyms for A and D):
Risks
Action Items (or Assumptions)
Issues
Dependencies (or Decisions)
The “log” is where these areas are documented and managed, a task the project manager usually leads. Initially created during the project planning phase, it's a dynamic document that needs to be updated repeatedly during the project. It can even be used during a post-mortem meeting to identify lessons learned from past projects and apply them to future projects.
The information that goes into the log comes from various sources, including risk assessment, meeting minutes, previous projects, and client intake forms. The level of detail required depends on the complexity of the project.
Risks
Project risks are possible future events that might affect your project negatively, such as limited resources, regulatory risks, and potential risks that affect the market as a whole.
Summarize each risk individually in the RAID log, document who's responsible for managing it, and consider how likely the risk is to occur and how severely it would affect the project.
You should also develop a plan to reduce the probability of each risk becoming an issue and set up review dates to monitor how the risk progresses. It’s best to identify a future solution, such as a mitigation plan, before the risk turns into a full-blown issue and share it with the rest of the team. But sometimes, all you can do is accept the risk or transfer it to a third party, like an insurance company.
Assumptions or Action Items
The first of our dual acronyms. Your RAID log can use assumptions, action items, or both, depending on your project plans. Use assumptions if your project is complex and has many known unknowns that must be documented. In addition, use action items to document items that arise and need to be assigned and addressed in any project.
What Are Assumptions?
A project assumption is something important about the project that you believe to be true. It has important consequences for the project depending on whether it is, in fact, true. For example, whether or not a team member delivers a critical piece of the project on time could affect the rest of the project. Your assumption in that case is that the piece will be delivered on time.
Document each assumption individually, together with why you're making it. Also, document what information would disprove the assumption and how the project would change if the assumption is wrong.
What Are Action Items?
Actions in the context of RAID are synonymous with action items, a well-known part of project management. Unlike scope, schedule or budget items that are planned well in advance, action items come up during any project.
Document each action item, who’s responsible for it, and when it needs to get done. The project manager should confirm that action items are completed, ensure the team is on track, and help them remove any obstacles to progress that caused the action item to be noted in the first place.
Issues
Issues are distinct from risks in the sense that potential risks are potential roadblocks that may or may not happen, whereas issues are problems that arise and have now become reality. Key issues typically delay deliverables, interrupt ongoing processes, or may force the project to use additional resources.
For each issue, document how severe it is in the issue log, when it started, who's responsible for dealing with it, and when it will be resolved (assuming it can be resolved). This is very useful if future issues arise due to an initial issue because your team can work backward through the issue log and see what happened to identify the root cause.
Dependencies or Decisions
Your RAID log can use dependencies, decisions, or both, depending on your project.
What Are Dependencies?
The dependencies in a RAID log are usually events instead of internal task dependencies. But, they can affect project tasks and project outcomes. For example, deliveries from supplier XYZ must arrive by February 15 to launch the project on time.
Document who’s responsible for each dependency and when it will be completed. You'll most likely need to get buy-in from other project stakeholders so that you don’t hold someone accountable for a dependency they don’t control.
Gantt charts are frequently used to gain a visual overview of major task dependencies. This is something that you can easily generate, view and modify inside Lark.
The dependencies in the RAID log often arise during the project and therefore can’t be anticipated like task dependencies, which are recognized during schedule planning.
What Are Decisions?
Companies can also use the RAID log to document anticipated future decisions, such as whether to use subcontractor A or subcontractor B. Decisions arise in any project, though, that are not anticipated. These are the kinds of decisions that can be kept in a RAID log.
For example, if a key resource is delayed by another project, a decision must be made on how to fill the void. In this regard, decisions that can impact project progress should be logged and managed, so log significant decisions, not every tiny decision.
The backlog of past decisions becomes particularly useful if you need to go back through documentation to figure out the thought process behind a particular decision or if you need to see where an error originated.
What are the benefits and drawbacks of using a RAID log?
Like any project management tool, using a RAID log has upsides and downsides.
Increased organization and visibility
Considering that the RAID log is a place to log items that could affect project progress if left unaddressed, it’s a key tool. This is a great way to keep the team organized since these important to-dos are more likely to be dealt with if documented than if they are left to chance. And, provided it’s kept up to date, the log can eventually become a central repository of project information for the team.
Improved project management planning
By giving you a structured approach to organizing a mass of data, RAID helps you think in a more strategic, logical way. It prevents you from conflating issues with action items, and keeps them in view, as opposed to forgotten. Though documentation is sometimes considered a burden, this kind of shared document gives you more control over the project, and the team’s collective memory. Our brains weren’t meant to be digital repositories.
There's some overlap here between the RAID log and a risk register — the latter being the place where potential risks are often anticipated and managed for complex projects. A given project might use one or the other, or use a RAID log but maintain risks only in the risk register.
Opportunity cost
A RAID log is only an effective tool if it’s kept up to date. Otherwise, the information becomes obsolete — which might confuse stakeholders who aren’t regularly involved in the project. Or worse, it could confuse the project manager.
Keeping the log updated incurs an opportunity cost. The time team members spend updating their parts of the log might be better spent elsewhere (such as moving the project forward) rather than documenting things. This is especially true in a start-up context, where survival often rests on the ability to iterate more quickly than the competition.
Incompatibility with the rest of your stack
If you're using a big tech stack, there might be a problem if your RAID log tool doesn't integrate with the rest of your stack. For example, if you need to pass data between Google Docs and your RAID tool, but those tools aren’t natively integrated, passing the data manually might end up being very time-consuming. Not only that, it’s imperative to be able to include different types of data within your log, which can often involve using multiple separate apps.
Lark has its own Docs program built into its software suite, and it's extremely straightforward to share Docs inside Lark or to invite others to collaborate on updating the RAID log. So you won’t need to switch tasks or apps.
It’s easy to get lost in the details
The greatest challenge with RAID is that it’s tempting to document absolutely everything, be a perfectionist, and lose sight of the forest for the trees. On the other hand, if you don’t document enough, the log is almost entirely useless. Often, it’s tricky to see in advance how much information will be too much and how much is too little.
To mitigate this problem, agree on what information should be documented and what shouldn’t be. This will vary from project to project.
Creating a RAID log in Lark
If you want to create a RAID log in Lark, do yourself a favor, and don’t start from scratch! Instead, use one of the 100+ templates that Lark provides – one of which just happens to be a tailor-made RAID template:
Follow the prompts that say, “Use this template,” and you’ll be taken to a version of the template that you can edit inside your Lark account:
Next, add your data. If you have pre-existing data, such as spreadsheets, click the dark green icon on the right to use the “Excel compare and import” feature.
This will bring up this menu, which will allow you to import your Excel sheet with one click:
If you’re worried you’ve input data twice, the little purple icon on the right sidebar will handily let you check for duplicate entries.
As you update the RAID log to make it suitable for your purposes, you’ll likely want to notify the rest of your team whenever a change is made. Lark will let you do this without going to a third-party app like Slack. Click on “Automations” in the top navigation:
This will bring up this modal:
Now click where it says, “When a record changes → Send a Lark message.”
Lark will now let you clarify under what conditions you want to notify particular colleagues on your project team:
The UI is flexible so that you won’t spam colleagues with notifications but also don’t let important changes fall through the cracks.
You can also use this feature of Lark to send notifications:
When a button is clicked
When a new record is added
At a record’s trigger time
Or at a scheduled time each day
If you want to go back and see what changes were made, Lark will let you do that as well. Right-click a particular record:
Click “View Record History”:
You can now see all the data for that record in one place, together with a history of changes made. There’s even a sharing option if you need to share this one particular record with colleagues. Due to the breadth of solutions that Lark offers, you could even discuss the log on a video call without having to leave the platform.
Once you have all the data and automation set up, Lark gives you many options for visualizing your data. For example, a view of your item types by Kanban column:
Here’s the calendar view:
And the Gannt chart is great for visualizing dependencies:
Common FAQs about RAID logs
Should you use a RAID log in Agile?
You can use a RAID log to keep Agile projects organized, particularly when documenting action items and when there are larger project teams. Doing this can also help a team learn from the failures of past iterations.
Agile projects generally don’t use extensive documentation because they focus on iterating quickly rather than creating a record of everything they do. A RAID log is sometimes not used in the Scrum framework because other Scrum elements provide similar functionality. For example, dependencies are handled in daily stand-ups as blockers.
Who uses RAID logs?
Any business, large or small, can use a RAID log. But, in practice, the businesses that use them the most often are enterprises, large, medium and small.
The team member who uses RAID logs most often is the busy project manager. Note, however, that the log still needs to be maintained by the project teams, even if it's the PM who takes the lead.
What are some best practices for RAID logs?
RAID log updates are the most important thing to remember when you use a RAID log. It should be updated throughout the project lifecycle. More importantly, make sure that items are completed, not just documented. Designate an owner for each action item, issue, risk, and dependency, and ensure those individuals manage their respective items.
Even after the project finishes, review your RAID log. It can be a key source of learning for future projects. Too many businesses create RAID logs during the project planning phase and then forget about them. Their usefulness requires USING them.
Additionally, ensure the level of detail is appropriate. Too many tactical updates might overwhelm stakeholders who aren’t involved in the project every day. On the other hand, too few details might not provide enough context to make key decisions.
How do you encourage team members to fill out their RAID logs?
Individual team members don’t have their own personal RAID log as such. But they must manage, complete, and update any items they own.
To encourage them to do this, communicate why the log is important. Let them know that they own certain entries, and make clear their responsibilities in executing that ownership. Issues are resolved when they are owned, acted upon, and the resolution is communicated. The same is true of action items – they are there because failure to act can slow or stop progress.
To help make this happen, make updating log items as easy as possible. Each individual team member should know which items in the log they’re responsible for, and when each is due. The team is counting on them to make things happen, and you don’t want them waiting for the result. Waiting means time and cost lost.
Not just RAID – using and sharing digital information with Lark
So a RAID log is a way of organizing digital information necessary to manage projects. A few other ways of organizing and productively using digital information include:
PARA to categorize and access your digital information, especially for knowledge workers
Amazon’s method for presenting ideas and conducting meetings
Lark can accommodate these approaches, and more, to deploy and use digital information. It gives you the means to capture it, use it, share it, message about it, conduct effective meetings about it, auto-generate minutes or meeting notes, and translate all of it in real time for international teams without leaving the app. Without the productivity and budget hits of a tech stack that requires context switching. But, back to the subject, here.
Create a RAID log today
An effective RAID log is a great way to stay organized and track risks, assumptions, issues, action items and dependencies all in one place, share it and discuss it live. It will help you execute your projects more effectively and ensure key project data is visible to the right team members.
If you’d like to build a RAID log today, Lark’s template makes it super easy. But don’t take our word for it. Sign up for a free trial of Lark today and see for yourself!
