RAID is an acronym which should be at the forefront of your mind if you are a project manager or a program manager. RAID stands for Risks, Assumptions, Issues, and Dependencies. At the bottom of this article, you’ll find a link to download a free RAID Log template.
The RAID acronym can help you to remember to give appropriate attention to each area. In my own personal experience, I know that I have a tendency to give ample attention to risks and risk management but can overlook assumptions, so reminding myself of the RAID acronym daily, so as not to overlook any of these areas comes in very handy.
Below you’ll find a quick recap of Risks, Assumptions, Issues, and Dependencies. Each has been covered before on Expert Program Management (especially Risks – I told you I was biased towards this area 😉 ) and a link to that section has been provided if you need more detailed information.
Risks
A risk is any specific event which might occur and thus have a negative impact on your project or program. Each risk will have an associated probability of occurrence along with an impact on your project if it does materialize. An example of a risk might be that a change in legislation to tax law could mean you will have to redo some of your projects and this will impact the schedule by x and cost y. As a project manager, it is your responsibility to ensure a Risk Management Process is undertaken, managing and mitigating risks, along with ensuring risks are routinely and effectively communicate with your stakeholders.
Assumptions
An assumption is something we set as true to enable us to proceed with our project or program. Typically this happens during the planning and estimation phase of the project. As an example of an assumption, during the early planning phase, we might assume that we have access to 10 skilled specialists throughout the entire duration of the project. By making this assumption it enables us to produce our plan. If this assumption turns out to be false then the project is negatively impacted. Because assumptions can turn out to be false and impact your project adversely, it is your responsibility as project manager to monitor and manage all assumptions so minimal impact to the project occurs.
Issues
An issue is anything which arises on your project which you have to deal with in order to ensure your project runs smoothly. Issues differ from risks in that they exist as a problem today, unlike risks which might turn into issues in the future. An example of an issue might be that a key project resource as called in ill and is unlikely to attend the office for the remainder of the week. Issues need to be managed through the Issue Management Process.
Dependencies
A dependency exists when an output from one piece of work or project is needed as mandatory input for another project or piece of work. An example of a dependency in a building project might be that the architectural diagrams need to be complete before the foundations can be laid. Managing inter-dependencies is critical to ensuring projects, regardless of their size, run smoothly. As project and program managers it is your responsibility to record, monitor, and manage these dependencies.
RAID Log Template
A project management RAID Log Template is obviously a template that allows us to log and monitor risks, assumptions, issues, and dependencies. Typically this will be done using an Excel spreadsheet. If you want to download our RAID template you can do so using the button below:
The first sheet in the Excel RAID template provides an overview showing the status of each area within the template, which you can see in the diagram below:
As you can see in the RAID Log Template above the summary page gives us a one-page status snapshot, showing both the total number of risks, assumptions, issues, and dependencies, as well as providing a breakdown for each by criticality or priority. This enables us to very quickly ascertain how the project is doing across all areas that make up the RAID Log.
If you download our RAID Log for your own use, then you’ll need to remember to delete or archive rows within the log as they are closed, otherwise, the summation figures will not be accurate (basically closed issues will appear on the summary page).
RAID Log: Risks Sheet
When using the Risk Log the first thing we need to do is give the risk a name and description. Then we need to assess the impact of the risk – what will happen if the risk materializes, for example, will the project overrun or go over budget? Next, we need to enter an impact and likelihood score, giving each a value between 1 (low) and 5 (high). Impact describes how large the impact on the project will be if this risk materializes, and likelihood describes how likely a risk is to materialize.
When using the template, once you enter the impact and likelihood then the corresponding Score and Risk Level cells will be calculated automatically by the RAID spreadsheet and automatically populated. The score is calculated automatically by multiplying impact by likelihood, and risk level is graded according to the Risk Score Key at the top of the sheet.
Next, we need to outline the plan to manage the risk – will the risk be mitigated, accepted, transferred, or avoided. We also record key dates relating to the risk. The Trend cell gives us an opportunity to record if the outlook for the risk is improving or deteriorating. Finally, it is very important to give each risk an owner who is responsible for both handling the risk and reporting on its status at the next update due date.
It is worth remembering to record risks that impact the project both positively and negatively.
Raid Log: Assumptions Sheet
The Assumptions Log is very similar to the Risk Log. Again, we begin by providing an assumption name and description and describing the implication (impact) on the project if this assumption turns out to be false. Next, we specify if we’re making an assumption or handling a constraint. Assumptions are things you assume will be true based on your professional knowledge and past experience, for example, that the tax on sales rate will remain at 15%, or that you will be provided the resources you need to complete the project. Unlike assumptions, constraints are forced upon you, for example, you will only have access to one software engineer for this project, or that the budget under no circumstances can overrun.
Once we understand our assumption/constraint, we give it a criticality level. This level determines how disruptive to the project it would be if that assumption was to turn out to be false. We also need to record any next actions associated with the assumption as well as giving the assumption an owner who is responsible for monitoring the status of the assumption.
RAID Log: Issues Sheet
To enter a new issue in our RAID Log, we first provide the issue with a name and description. Next, we must describe the impact the issue will have on our project if the issue is not resolved. Then we need to provide the issue with a priority of either low, medium, high, or critical. This value determines how important to the project it is to resolve this issue. The issue also needs to be given a status – Open if the issue is yet to be resolved, or Closed if the issue has already been resolved.
If using our RAID Log template then remember to delete or archive to a different Excel sheet closed issues so as not to distort the Issue Numbers calculation (you can see this miscalculation in the diagram above where there are 5 open issues but 6 are being reported in the Issue Numbers at the top of the sheet).
Next, on the sheet, we have space to record when each issue was last updated, when the next update on the issue is expected, and what next steps need to be performed to move towards resolving (closing) the issue. Finally, each issue must have an owner who will ensure the next actions are performed and report on their status.
RAID Log: Dependencies Sheet
Finally, let’s take a look at the dependencies sheet. Again, we need to provide a name and description. We must also specify whether the dependency is inbound or outbound. Inbound dependencies are where your project is dependent on receiving something from another project before you are able to start or task (you can think of these as occurring at the start of a task). Outbound dependencies are where another team cannot start an activity before you finish (you can think of these as occurring at the end of a task).
Next, we need to provide the dependency with a priority. This will usually be determined based on how critical the dependency is to the successful completion of the project. Next, we have the opportunity to specify if the priority is committed or not. This allows for situations where we know we have a really critical dependency but we haven’t yet reorganized and rescheduled it to allow it to be completed in a timely manner so it doesn’t disrupt the project.
The Last Updated and Next Update columns allow us to keep track of key dates pertaining to each dependency. The Next Actions column allows us to monitor what needs to happen next for each dependency. Finally, just as in every other sheet, it is important for the dependency to have an owner, who will negotiate with other teams and report status.
Remember, if you’d like to download and use the templates above you can do so here:
Conclusion
I’m sure you’re all familiar with Risks, Assumptions, Issues, and Dependencies, but may not have come across the acronym RAID before, which can serve as an aide-memoire to give appropriate attention to each area. Links to the relevant posts have been provided if you need to refresh your memory on any of the areas which make up the RAID Log acronym.
