Executive Summary
Are you a new PMP or CAPM trying to apply the proper techniques to manage your projects? A long-standing project management tool has been used for years and will save your project before it has to be rescued! RAIDLOG.com walks you through the fundamentals of a RAID log, how to create your RAID log template, and how to manage your projects effectively using this methodology.
- What is a RAID Log?
- How to Create a RAID Log
- RAID Log Risk Tab
- RAID Log Action Tab
- RAID Log Issues Tab
- RAID Log Decisions Tab
- RAID Management; How to Use Your RAID Document
What is a RAID Log?
A RAID log is a simple but powerful tool for managing the delivery of work. In its original and most simple form, a project manager would create a RAID log on an excel spreadsheet with four tabs, one tab each for tracking Risks, Action items, Issues, and Decisions (R.A.I.D.) for a project.
RAID logs can’t be beat as a project management tool because of their simplicity and how much they add efficiency to managing projects. Why? Because at its core, RAID Management is:
Project Tracking Tool
- A RAID log is a simple tool to track operational activities related to your project. This log lists everything going on with your project and tasks you need to mind to keep your plan on track. More specifically; Risks, Action items, Issues, and Decisions.
A Methodology
- Using a RAID log will give you a method for being “always-on” and up to date with your project and plans. It is a way of managing your projects which keeps you focused on your project schedule and keep things moving, especially when you have multiple projects going on at once.
A Communication Tool
- A RAID log helps you more clearly and efficiently communicate with your stakeholders, sponsors and team members. As we’ll see later, the more challenging the environment, the more valuable your RAID log will become.
However, a RAID log is primarily an operational tool, not a planning tool. It is a way to help you implement your plan and execute your project, but it is generally not the project plan itself.
Save your project before it has to be rescued!
You would want to use this PM tool to run your projects or potentially rescue projects that are in trouble. The detailed project plans created for a project’s overall execution of a project’s goals, objectives, the scope of work, milestones, and resources are better served in a purpose-built scheduling or task management tool rather than your RAID log.
You may be searching right now for a RAID log template because you had that “ah-ha” moment. You realize that a RAID is an indispensable tool you cannot live without, and you need a RAID document right now to manage your projects. Below you will find all the columns you need to account for to create your template.
How to Create a RAID Log
The following outlined columns for the Risks, Actions, Issues, and Decisions Tabs are essential points of data to track because this information helps you implement your plan and execute your project.
RAID Log Risk Tab
| Column | Description |
| Title, in a “Problem Statement” | Use a problem statement form: as a result of , may occur, which would lead to |
| State | State of the Risk. Usually, a picklist denoting the lifecycle, including:
|
| Description | Detailed description of the risk and its potential impacts and influencing factors |
| Date Raised | Date the risk was added to the log. This is good for tracking new vs. old risks |
| Source | Source of the risk – the person who raised it or the forum it was raised in. This is handy when someone says, “where did this come from?” |
| Category | Categorization for grouping risks for effective planning and review |
| Probability of Occurrence | Value representing the probability that the risk could happen. Can be a percentage, a numerical scale (1-5) or even text (Remote, Low, Medium, High, Nearly Certain) |
| Impact of Occurrence | Value representing the impact of the risk, should it occur. You could use a monetary value, but assigning an accurate value usually takes too much effort, so it is best to use a numerical scale (1-5) with a definition of each level. See Risk Appendix for recommendations |
| P*I | Probability Score * Impact Score – use this column to sort risks in order of importance |
| Owner | The Owner is the person responsible for managing this risk. Most of the time that’ll be the PM. But it could be the technical lead, the Product Owner, or the Sponsor. The PM should keep on top of the Risk, but the Owner is the one Accountable on the RACI. |
| Response Strategy | Picklist of the strategy used to respond to the risk
|
| Response Update | A text field with the latest update on the risk. These can be timestamped entries or just the latest update |
| Date Updated | Date the last time the risk was reviewed or updated |
| Date Closed | Date the risk was closed or canceled |
| Reason Closed | Picklist or text describing the reason the risk was closed
|
Optional Risk Columns
| Column | Description |
| Contract Reference | Link back to contract assumptions and dependencies. This can be handy if the issue turns into a risk and has contractual implications – for you, your suppliers, or clients |
| Impact Category | Some organizations like to be more specific with the Risk Impact and categorize risks by the constraints they may impact. Typical Impact Categories may include:
|
| Trigger Date | The date on which (or by which) the risk could become an issue. After this date, the risk is immaterial. |
| Escalations | If you need to create a paper trail for who you escalated the risk to, when, and their response, then a special Escalations column can be useful! |
| Status of Response | Red/Amber/Green indicator showing the status (on-track, at risk, off-track) of the risk response plan. When this is red, it means that the plan to mitigate the risk is going off track. |
| Residual Probability | Residual probability is the probability the risk will occur even AFTER the response strategy is implemented. It’s typically more efficient to simply update the Probability of the risk after implementing these strategies, but sometimes it is nice to demonstrate the effective impact of your response and thus, the value of your risk planning |
| Residual Impact | Like Residual Probability, Residual Impact is the measure of expected impact after the response strategy. Like Residual Probability, it is more efficient to simply update the Risk Impact score after implementing these measures, but it can be nice to break it out if you have to demonstrate the value of your risk planning. |
| Residual P*I | Residual Probability * Residual Impact |
| Residual Risk Description | Explains what risk remains after the mitigation strategies are implemented. Even when Residual Probability and Impact are not used, it can be useful to describe what risk is remaining after your response actions, especially for more serious risks. |
| Financial Cost of Impact | Typically used only for the most impactful risks where EMV is used, this represents the total financial impact if the risk were to occur. If you use this field, then you should have an explanation ready for how you came up with this number. |
| Expected Monetary Value (EMV) | Probability * Financial Cost of Impact represents the Expected Monetary Value of the risk, which can be useful for more advanced financial analysis. |
RAID Log Action Tab
| Column | Description |
| Brief Task Description, in the form of a “Cause and Effect Statement” | We need to do x so we can get y |
| Source | Source of the action – the person who raised it or the forum it was raised in. This is handy when someone says, “where did this come from?” |
| Assigned | Person accountable for completing the action |
| Due Date | Date the task should be completed |
| Comments/Notes | Either a running log of the status or details about the activity |
Optional Action Column
| Column | Description |
| Priority | Optional. I personally don’t do this – date is enough of a driver. If you use L/M/H, it’s not long before everything is a high-priority item. |
RAID Log Issues Tab
| Column | Description |
| State | Lifecycle state of the Issue. This will vary depending on your processes, but at a minimum:
|
| Title, in a “Problem Statement” | Use a problem statement form: This is wrong, causing this impact |
| Description | Detailed description, including any data related to cause. |
| Impact | Description of the impact of the issue. Be sure to clarify if issue impacts are limited to the project or extend to business operations |
| Category | Category – should match the categories of Risks |
| Owner | Person responsible for resolving the issue |
| Date Raised | Date the issue was identified and documented |
| Response Actions | A running log of actions and next steps in resolving the issue |
| Date Resolved | Date the issue was resolved |
| Resolution | Summary description of the issue resolution |
| Remediation Actions | List of actions required to remediate the impacts |
Optional Issues Columns
| Column | Description |
| Escalations | If you need to create a paper trail for who you escalated the issue to, when, and their response, then a special Escalations column can be useful |
| Stakeholders (Comm List) | List of stakeholders who need to receive communications regarding this open issue |
| Root Cause | Root cause of the issue. If you use this column, it may not be necessary for all issues, but it may be a good idea for very impactful issues. |
| Internal Only (Team Only) Flag | Flag indicating if this issue should be kept internal to your team. Instead of a flag, you can create data classification for “Team Only,” “Management only,” “Internal company only,” or “Public,” for example. |
| Schedule Impact (to Critical Path) | The estimated impact in duration to the duration of the critical path. If using this field, you should be able to summarize the total duration impact to the critical path across all issues, and this should match how late your project is. |
| Cost Impact (Amount) | The estimated cost impact of the issue. Ideally, if you add up all the issues with cost impact, you arrive at something like the difference between your budgeted and actual cost. |
| Lessons Learned | Description of lessons that can be learned from this issue and applied to future projects to avoid similar issues |
RAID Log Decisions Tab
| Column | Description |
| State | Lifecycle state of the Decision. This will vary depending on your processes, but at a minimum:
|
| Decision to be Made
|
Concise description of the decision that needs to be made including options. Use a problem statement form: We need a decision on “X” so we can “Y”. |
| Decision Needed By | Date decision needed in order to avoid impacts |
| Decision Maker(s) | Person or group responsible for making the decision |
| Impact | Description of the impact of the decision, including the impacts of NOT making a decision by the “needed by” date. Be sure to clarify if issue impacts are limited to the project or extend to business operations |
| Impacted Stakeholders (To Be Informed) | Those impacted by the decision and how they are impacted. This is the list of stakeholders who must be informed about the result of the decision |
| Owner | Person responsible for following up with the Deciding parties to get the decision made |
| Response Actions | A running log of actions and next steps in resolving the issue |
| Date Resolved | Date the decision was made and documented |
| Decision Made | Description of the decision that was made |
| Justification | Details about why the choice was selected in the decision. This is not strictly necessary but adds a lot of valuable insight into key project decisions and rationale |
Optional Decisions Columns
| Column | Description |
| Description | Detailed description, including any data related to cause. this isn’t usually needed – the Decision field is usually enough. If used, it describes each of the options available for selecting in the decision with a description of the impacts |
| Category | Where there are a large number of decisions to track across a large number of stakeholders, it can be useful to categorize the decisions |
| Decision Requested By | Origination point for the decision request. This can be a person, a team, or an event like a meeting or workshop |
No matter what industry you are in or your working methodology, the odds are against your success. Analysts at The Standish Group reported in the CHAOS Report 2020 that as few as 31% of projects succeed in meeting all their goals. As many as 19% of all projects fail, leaving the remaining 50% floundering somewhere in between.
The goal of your RAID log is to help you keep operationally aware and on top of your projects. Risks, Actions, Issues, and Dependencies are the most important things you need to capture to keep a project moving forward, also the fundamental building blocks of your RAID log which keep you operationally present and you on top of your project.
RAID Management; How to Use Your RAID Document
To effectively use your RAID log in project management, it is best to follow the sequence I-R-D-A.
Issues:
- Review your open issues by priority order. You may need to focus on urgent issues first before proceeding further.
Risks:
- Sort by risk score and trigger date if you use that field.
- Check up on your remediations to ensure they are on track.
- Think through any additional risks that have come up since your last review.
Decisions:
- Filter for open decisions and sort by the decision date.
- Review each entry to ensure you are on track with plans to get decisions made.
- Identify open decisions and work on those entries that still need options figured out or the decision-makers.
Action Items:
- Filter for open items that have upcoming due dates.
- Ensure all entries have a due date and assignee. If some are missing, work on that.
- Review action items assigned to you – wherever possible, DELEGATE!
- Prioritize those Action Items that are important and have a long-term effect on the project over those that are urgent and need attention immediately.
This tip is part of David Allen’s, Getting Things Done methodology. If you don’t, you’ll end up spending more time managing the action item than it would take for you to get it done.
Related: How Applying RAID Methodology to Your Project Can Keep you On Track.
The Power of the RAID Log is its Simplicity
I encourage you to keep your log as simple as possible. The more chaotic the environment is, the more critical it is to keep your RAID log a safe harbor of clarity and simplicity.
Your RAID document should be light, easy to use, easy to understand, and accessible. If you lose any of these characteristics, your RAID starts losing some value. You think of ways to create a Project and Portfolio Management system with a schedule, budget, resource plan, etc., for one project. Don’t. Keep it simple, up-to-date, and accessible.
Another way to keep this safe harbor of clarity and simplicity and ditch the excel sheet is to check out the latest tech stack solution that makes organizing, managing, and sharing your RAID log a breeze.
A Platform, A Methodology, A Solution for Managing Projects
Save your project before it has to be rescued!
Projects don’t go wrong because of your project plan or user stories. They go wrong because of unmanaged Risks, neglected Action Items, unresolved Issues, and poor Decision making.
RAIDLOG.com is a purpose-built project management tool that is coming to market and helps you keep your RAID log simple, accessible, and secure.
Why keep struggling with a spreadsheet-based RAID log when RAIDLOG.com can aggregate data to the master RAID log, provide central reporting and access control, and is easy to use and share with project shareholders and team members.
Bring order to the chaos in your project management life!
Signup for exclusive access to the only tool that’s purpose-built to save your project before it needs to be rescued and give yourself peace of mind.
BE THE FIRST TO USE IT – FOR FREE
Join Now