As PMO teams know, a staple of any successful project management program is the “RAID log” to track and manage Risks, Actions, Issues, Decisions. The log provides a central dashboard or view of discussion items that arise during a project and need to be recorded and tracked. As with any tool, it’s important to use it for the benefit the team and the project.
3 keys to a successful RAID log are to:
1) Define the terms
2) Assign ownership and due date
3) Provide an explanation
In this piece, we’ll share more detail about each key and offer both guidance and recommendations.
1. Define the terms
When you ask project team members to define the words represented in the acronym, RAID, they should be able to do it easily. Then, when you ask what the words mean in the context of project management, you may get varied answers.
One common area where team members are not aligned is the understanding of the difference between a “risk” and an “issue”. A good way for me to remember the difference between a risk and an issue is that a risk is something that could impact a project; an issue has already taken place and the project has already been affected.
Another way I have explained this is by using the example of an egg. When an egg is on a table there is a risk that it could roll off. As the egg gets closer to the edge of the table, the risk of it rolling off increases. If the egg rolls off the table, you no longer have a risk but now the issue of cleaning up a broken egg!
If a OneStream project has a customer reporting requirement that is dependent on an update to the ERP system (e.g. SAP) and the project plan dictates that the SAP updates need to be in place by August 1, then on June 1 this dependency would be recorded as a risk. As this risk is tracked and the project approaches the August 1 deadline, the likelihood of the risk impacting the project increases until it reaches August 1. At that point, if the risk is not addressed, the timeline is impacted, and the risk becomes an issue.
As for actions, it’s important to not duplicate your entire project plan on your RAID log. You want to reserve the actions for high-level project-wide activities that require additional attention. Examples include certain signoffs, milestones, or other items that can become risks if not addressed.
The definition for decisions in terms of the RAID log is usually easier but not always clear-cut. When talking about decisions, the recommended approach is to agree to finalize items and close discussion on them once decisions are recorded on the RAID log. There are always exceptions to this rule. However, if you can implement this best practice, it saves time and avoids confusion, such as revisiting or rehashing previous decisions and their impact to the project.
Another consideration is that risks and issues have mitigation steps, so do not include those in actions because they are duplicative.
2. Assign ownership and due date
It is important that there is accountability for each entry in the RAID log. The best way to do this is to assign owners and due dates. Actions are usually easiest because there is a clear responsible party and clear deadline/date to complete the action.
For decisions, it is important to record who approved the decision and the decision approval date. As noted above, you do not want to revisit decisions. Therefore, knowing when the decision was made and who made the decision helps mitigate those conversations and avoid confusion or extra effort.
When recording risks and issues, outline the mitigation steps with the responsible party and determine a due date for each action. Using the original example, a mitigation step might be to assign the following activity to a team member, “By 15-Jun review the SAP update project progress and provide this PM group an assessment on timelines.” A follow-up step could be, “By 30-Jun provide 2 options for alternative solutions if SAP project is not completed on time.”
Items recorded without an owner and due date usually fall through the cracks and resurface at the wrong time, which can create delays.
3. Provide context
The third key for a successful RAID log is to offer context for the items. One way to think about this is to answer the question, “Why should I care?”
It is easy to forget why an item made its way into a RAID log. Providing context reminds the team of the situation. It will also enable leaders and sponsors who are not involved with the day-to-day activities to have a better understanding. To build on the example above, when talking about a risk or issue, it is best to add context or notes related to potential impact, such as, “If SAP cannot deliver customer level data by 1-August, the project will face significant delays.” If you are recording a decision related to this item, it helps to add something like, “If SAP cannot give customer level data by 1-August, the project will move forward with the customer reports removed from the project scope. The team estimates the cost to develop these reports later will be $XX.”
In both examples it is important to provide both the risk/issue or decision and why it matters to the project, along with a clear impact to either the timeline, to the cost, or both.
Every company, Project Management Office, or project can customize their unique version of a RAID log with varying fields and levels of detail. It is key to establish and agree on a version that best fits your project and the requirements of your organization.
No matter what format you choose, by following these 3 keys – 1) defining terms and agreeing on them, 2) assigning ownership and a due date, and 3) providing an explanation for context – you will drive a clear understanding and successful communication throughout your project.
For more information on this or any other topic please contact insights@finit.com.