If you’re a PMO veteran, you’re probably well versed in maintaining a RAID log, but for those new to projects or who are about to sponsor a project, RAID logs may not be as familiar.
A RAID log records R-isks, A-ssumptions, I-ssues and D-ependencies throughout a project, and is one of the top tools used to keep a record of everything you need to keep an eye on to ensure a project stays on track. There are many variations of RAID log templates (built in Excel), but they generally track the same things.
If your business is undergoing change, it’s good practice for a project manager to keep a RAID log to make sure that work, actions, preparations, etc. for the project are being addressed as you go along. (Extra tip: Sometimes you’ll see something similar called an A-RAID in which the first ‘A’ stands for A-ctions. These actions detail steps that need to be carried out in order to manage the RAID.)
Equally, a project sponsor benefits from keeping themselves informed and involved with the RAID log, ensuring the project is meeting expectations required of the investment, and is on course for deployment or project end. At Veran, when we work with businesses to implement Cloud HR technology, we always use a RAID log to keep us on track and our project sponsors in the loop.
Breaking down the RAID log
Now that we’ve covered what RAID stands for, let’s look into what each individual part means. For the examples provided, let’s pretend we’re implementing a people analytics tool in a global business.
Risks
Risks are events that will have a harmful impact on your project if they end up happening. One way you can measure risk is by combining the likelihood the risk will occur with the impact on the project if it does occur, ultimately giving you a scale that can be used to prioritise risks. The log usually includes descriptions, impacts, and probabilities.
Example: An example of a risk in the scenario described above is that the data being collected for the tool is currently being maintained in several systems, and there is a chance the data is inconsistent and may require additional resources to ‘clean’ the data in order to be acceptable to migrate into the new system.
Assumptions
Assumptions are any factors you assume that will already be in place that will result in the success of your project. The log usually includes descriptions, impacts, and agreement statuses (see image below).
Example: An assumption is that the data collected from different centres will be complete and formatted correctly to the migration requirements.
Issues
Issues are things that have gone (or are currently going) wrong on your project and need managing. Failure to manage issues may result in a poor delivery or possibly a complete failure of the project. The log includes descriptions of each issue, impacts, and actions needed to be taken.
Example: An example of an issue in this scenario (if it were to happen) is that some of the people data has been written over because two offices in different countries have assigned the same employee number for different people.
Dependencies
Dependencies are events/actions/work that your project is dependent on, or, are dependent on the outcome of your project. The log details description, impact of late/non delivery, and priority/RAG status. It may also include items that are dependent on you.
Example: One dependency could be our reliance on third party benefits vendors to provide us with the data needed to migrate to the new system.
What next? Action!
A RAID log is very useful when maintained, but what truly makes it count is the actions that arise from it. Creating a RAID log at the beginning of the project can help you prepare for unfavourable events, but if the PMO doesn’t address the actions needed to be done, the project is prone to derailment as nothing is done to prevent, mitigate or resolve logged items. Every action needs a plan to carry out that action, and a RAID log is just a tool to help you organise and do that.
Good luck with your RAID logs!