Every time you start working on a project, regardless of what the project relates to, you’re going to encounter a number of problems to resolve. How you handle these problems can make or break the success of your project.
Ideally, a project team would anticipate these elements, and, at the very least, track them so they don’t derail the project. A RAID log is the perfect tool to anticipate and track all these elements, which can be done as simply as using a spreadsheet.
RAID is an acronym to help you remember the primary factors that influence the success of your project.
RAID stands for:
As you run a project of any kind you will need to have a number of regular checkpoints with the project team to ensure that the project is running smoothly and you’re still on track to achieve the project goals. The RAID log can provide an area of focus within these checkpoints. It is an opportunity to go over all outstanding points to make sure the project remains healthy.
When you start to look at the potential risks while delivering a project, the list can seem like it goes on forever.
Some examples might include stakeholders adjusting the scope during the project, resources such as people or funds being diverted to other areas, and uncertainty around the way to integrate with a third party application.
It’s important to acknowledge that the risks exist. By acknowledging them, you can consider ways to mitigate them as well as monitor the likelihood of them actually occurring.
For each risk you should record the following:
As with all elements of the RAID log, the thing that makes it valuable is the regular review and update of the risks to ensure that everything is being done to support the smooth operation of the project.
Here is an example of what risks might look like in a RAID log:
Whereas we want to track and mitigate risks, actions need to be recorded and pursued to ensure that all the tasks that need to get done are not missed.
For each action you should record the following:
Here is an example of what actions might look like in a RAID log:
Issues can look very similar to risks when it comes to being recorded in the RAID log. However, issues tend to be more specific and can be more directly resolved.
An example of the difference between risks and issues can be demonstrated through the use of a third-party app. Uncertainty over the way to integrate with a third-party app is a risk to the project because it could cause technical problems. However, not being able to connect to the third-party app because of a firewall problem is a specific issue that can be directly resolved.
For each issue you should be looking to record the following:
The aim is to ensure that the highest impact issues are resolved as quickly as possible, working your way down to the lowest impact ones.
Here is an example of what issues might look like in a RAID log:
When it comes to a project team, there are numerous people involved who all have different roles to play. Some are the day-to-day operators, involved in getting lots of the detailed work done (for example, the project manager or the technical lead), and others are project stakeholders who are interested in the outcomes of the projects (for example, the head of sales or finance director).
Day-to-day operators are more heavily involved with risks, actions, and issues, whereas stakeholders focus more on the decisions that need to be made.
The aim of tracking decisions is to ensure that the project has got some direction for all of the key areas that it covers. Also, it allows you to know who made the decision and why, with an audit that can be referred to when reviewing the project outcomes.
For each decision you should try to record the following:
Here is an example of what decisions might look like in a RAID log:
As you can see from the above descriptions of the four main elements, a RAID log is a series of data points that are regularly reviewed and updated by the project team.
A RAID log needs to:
Many project teams set up a RAID log within an Excel or Google spreadsheet. You can use our RAID log template, but you can also see numerous examples online. As you start to use them within your own organization, you’ll start to adjust the log so that it works for you and your projects.
The most obvious benefit to using a RAID log is that the log becomes a central repository for lots of information relating to your project. This supports all project team members in keeping on top of the elements that are influencing the success of their project.
You can see who has or hasn’t done what they’ve said they were going to do, or where the project is most likely to struggle. You can see who is making all the decisions and can look back to justify the approaches taken with clarity.
Finally, they are flexible. This means you can adapt them over time to meet the needs of your organization. If you want to make departments responsible rather than individuals, you can. If you want to have multiple status levels, you just need to update your template to cater for it. Whatever you need, a RAID log gives you the flexibility to find a way to meet that need.
Nonetheless, the log is only as good as the information put in it and the regularity with which it is updated and addressed. There’s no point in recording all the risks if no one seeks to mitigate them. There’s no point in only including half of the decisions being made as you won’t be able to generate the complete picture when you come back to look at what happened.
At the end of the day, it depends on you and your approach for project management. If you see value in keeping track of risks, actions, issues, and decisions, then give it a try. If you’ve already got this covered in another system, such as Jira or DevOps, then maybe you can do without it. The choice is yours!
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
In this article, we’ll discuss outcome-driven roadmaps and why they can actually be more efficient and productive than feature-driven ones.
MQ Qureshi talks about his experience with “unexpected sparks of brilliance” — solutions get to the core of what you’re trying to do.
A product review is the moment where you evaluate what the team created over the last development cycle and align on the next steps.