Minimum Viable Ass-Covering: how to use a RAID log to save your life.
As a project manager, a RAID log can be one of your most valuable tools. It’s a central location to capture everything outside of the individual tasks of a project. Personally, I find this particularly useful when managing many concurrent projects to use as a central location to capture all communications and decisions - then I only need to refer to one place other than the task tracker (e.g. JIRA, Trello, etc).
In case you don’t already know, RAID is an acronym (another one, right) that stands for:
Risks, Assumptions, Issues, Dependencies.
My favourite part of this is talking about risks. Risks are an opportunity to get ahead of anything that might go wrong in the project, and it really sets the expectations with your client or stakeholder of everything that might go wrong; including the things that might be because of them! When used correctly, this (in my opinion), is the project manager’s most powerful tool.
RISKS
In the first section we’ll capture all of the risks in the project. We log each of the risks that we can identify at the start before any work begins. We’ll then continue to use this throughout the project as new risks develop, ideally on a regular cadence (such as a sprint review).
We have a ranking system that can be used to prioritise which risks we need to tackle first, based on impact, budget and likelihood. We also assign each risk an owner, so we know that someone is responsible for making sure that the risk is mitigated.
At the start of the project, I like to discuss mitigation plans for the risks we are aware of, and as we go through the project we’ll need to regularly review those mitigations to ensure they are still relevant.
As new risks arise, we’ll need to openly discuss the mitigation plan for each - this helps for two reasons:
- It means that if we do have an issue, we’ve already discussed what we what are likely to do to mitigate it
- It reframes the conversation when this risk occurs, so rather than everyone panicking or getting frustrated that something bad has happened, as a project manager you can say “yes we knew this might happen, and we discussed what we might do, so now we’re going to follow the mitigation plan”.
If you’ve ever been in a position where stakeholders are panicking and getting stressed about something you already knew would happen internally within the project, then this is an example of when it can be particularly useful.
ASSUMPTIONS
The second section of a raid log is for assumptions. Here we capture all of the assumptions that we know about at the beginning of the project. These might be things that the team have assumed whilst estimating that weren’t necessarily captured in the original requirements. An example of this would be Browser Support:
- For our website, we may have assumed that it needs to work on the latest 3 versions of modern browsers, and we assume that we don’t need it to work on Internet Explorer 11.
As you are making major decisions during the project, it’s really handy to capture any assumptions that are discussed to refer back to, and flag to those involved that you have done so. A useful tool to avoid the potential “I thought we agreed this“ type of conversation.
ISSUES
The third section of the raid log is to log issues. This is particularly useful for capturing issues that happened during the project to be used as part of a retrospective or wash up meeting, as things can often get forgotten or lost.
As a project manager, this is also a great tool to help inform the narrative when there are bigger issues or delays towards the end of a project. It helps set the context for other stakeholders when trying to manage expectations around why things have gone wrong, as this may have been the compounded efforts of lots of smaller issues that led to this point.
DEPENDENCIES
The fourth and final section of the raid log is to log dependencies. Dependencies include anything that the project will depend upon for its success. There will be different phases of projects that require different dependencies at different times, and this allows us to centrally capture those and see the status of them. For example, we may depend on a third-party platform or API to be able to complete some functionality in an application build. We might also depend on an external contractor to complete a section of the work for us to be able to finish our section of work. With so many potential dependencies on a project, it’s really key to make sure we know if a dependency has been met or not, and who is ultimately responsible for ensuring that it has been met.
But can something be in two or more of the sections?
Absolutely - There are no hard and fast rules when using a RAID log; it really comes down to what makes the most sense for you in the context of the project An example of this:
- there might be a dependency that we need a third party API to be available and documented correctly for us to be able to continue the work
- there could also be an issue if this API is not available
- We are assuming that the API is documented correctly and will be available when we need to use it
- there is a risk that if this API is not available or documented correctly the project will have delays
In conclusion
Armed with your main project management tool or task tracker (JIRA, Trello, Monday, etc) and your RAID log, you will be well positioned to capture everything that happens in a project and have a central reference point to help you manage any challenges that may arise.
In summary:
- Identify risks and assumptions
- Monitor and track issues
- Ensure dependencies are met
- Update and review regularly
- Use your RAID log as a central reference
Some further reading:
