Every time you start working on a project, regardless of what the project relates to, you’re going to encounter a number of problems to resolve. How you handle these problems can make or break the success of your project.

Ideally, a project team would anticipate these elements, and, at the very least, track them so they don’t derail the project. A RAID log is the perfect tool to anticipate and track all these elements, which can be done as simply as using a spreadsheet.

What does RAID mean?

RAID is an acronym to help you remember the primary factors that influence the success of your project.

RAID stands for:

• Risks — Something that might have an adverse impact on the success of your project
• Actions — What needs to be completed by someone involved in your project
• Issues — Events and happenings identified as not being originally planned
• Decisions — A resolution or judgment that needs to be made by someone involved in the project

As you run a project of any kind you will need to have a number of regular checkpoints with the project team to ensure that the project is running smoothly and you’re still on track to achieve the project goals. The RAID log can provide an area of focus within these checkpoints. It is an opportunity to go over all outstanding points to make sure the project remains healthy.

Handling risks in the RAID log

When you start to look at the potential risks while delivering a project, the list can seem like it goes on forever.

Some examples might include stakeholders adjusting the scope during the project, resources such as people or funds being diverted to other areas, and uncertainty around the way to integrate with a third party application.

It’s important to acknowledge that the risks exist. By acknowledging them, you can consider ways to mitigate them as well as monitor the likelihood of them actually occurring.

For each risk you should record the following:

• Identifier — A unique reference to ensure everyone knows which risk is being discussed
• Description — A description of what the risk relates to, written in a way so everyone involved in the project understands what the risk is
• Status — The status of said risk, which could be “open” and still relevant, or “closed” and no longer a risk to the future of the project
• Impact — The intensity of the impact that the risk could have on the project, typically on a scale of 1–5 (1 being low impact and 5 being high impact), or high, medium, and low
• Likelihood — The chance of the risk actually occurring, typically on a scale of 1–5, or high, medium, and low
• Priority — Combining the scores from both impact and likelihood, you are then able to assess which risks are high priority; risks with the biggest impact and highest likelihoods are of the utmost priority to address
• Owner — Identifies who from the project team will be responsible for monitoring and ensuring that the mitigation of the risk occurs
• Mitigating actions — What has to be done in order to reduce the risk so that it is at an acceptable level for the project to proceed
• Start date — When was the risk identified
• End date — When the risk should be reduced or removed
• Comments — Any additional relevant information

As with all elements of the RAID log, the thing that makes it valuable is the regular review and update of the risks to ensure that everything is being done to support the smooth operation of the project.

Here is an example of what risks might look like in a RAID log:

Handling actions in the RAID log

Whereas we want to track and mitigate risks, actions need to be recorded and pursued to ensure that all the tasks that need to get done are not missed.

For each action you should record the following:

• Identifier — A unique reference to ensure that everyone knows which action is being discussed
• Description — A description of what the action relates to, written in a way so everyone involved in the project understands what the action is
• Status — the status of said action, which can be “not started”, “in progress”, “completed”, “on hold”, or even “overdue”
• Owner — Identifies who from the project team will be responsible for ensuring that the action is completed. This might not be the person who actually completes the action, just the person responsible for the action
• Start date — When was the action was created
• End date — When the action should be completed by
• Comments — Any additional relevant information

Here is an example of what actions might look like in a RAID log:

Handling issues in the RAID log

Issues can look very similar to risks when it comes to being recorded in the RAID log. However, issues tend to be more specific and can be more directly resolved.

An example of the difference between risks and issues can be demonstrated through the use of a third-party app. Uncertainty over the way to integrate with a third-party app is a risk to the project because it could cause technical problems. However, not being able to connect to the third-party app because of a firewall problem is a specific issue that can be directly resolved.

For each issue you should be looking to record the following:

• Identifier — A unique reference to ensure everyone knows which issue is being discussed
• Description — A description of what the issue relates to, written in a way so everyone involved in the project understands what the risk is
• Status — The status of said issue, which could be “open” and still relevant, or “closed” and no longer an issue for the project
• Impact — The intensity of the impact that the issue can have on the project, typically on a scale of 1-5 or high, medium, and low
• Owner — Identifies who from the project team will be responsible for ensuring that the issue is resolved one way or another
• Start date — When was the issue identified
• End date — When the issue should be resolved by
• Comments — Any additional relevant information

The aim is to ensure that the highest impact issues are resolved as quickly as possible, working your way down to the lowest impact ones.

Here is an example of what issues might look like in a RAID log:

Handling decisions in the RAID log

When it comes to a project team, there are numerous people involved who all have different roles to play. Some are the day-to-day operators, involved in getting lots of the detailed work done (for example, the project manager or the technical lead), and others are project stakeholders who are interested in the outcomes of the projects (for example, the head of sales or finance director).

Day-to-day operators are more heavily involved with risks, actions, and issues, whereas stakeholders focus more on the decisions that need to be made.

The aim of tracking decisions is to ensure that the project has got some direction for all of the key areas that it covers. Also, it allows you to know who made the decision and why, with an audit that can be referred to when reviewing the project outcomes.

For each decision you should try to record the following:

• Identifier — A unique reference to ensure that everyone knows which decision is being discussed
• Description — A description of what decision needs to be made, written in the form of a question
• Status — The status of said decision, which could be “open” and still relevant, or “closed” and no longer an issue for the project
• Priority — Measures the priority for a decision to be made on a scale of high to low.
• Raised by — Identifies who raised the question to the project team
• Owner — Identifies who from the project team will be responsible for ensuring that a decision is received
• Start date — When was the question is identified
• End date — When the decision should be made by
• Comments — Any additional relevant information

Here is an example of what decisions might look like in a RAID log:

What does a RAID log look like?

As you can see from the above descriptions of the four main elements, a RAID log is a series of data points that are regularly reviewed and updated by the project team.

A RAID log needs to:

• Be able to show potentially lots of data
• Allow multiple people to access the log and see what they need to take action on
• Provide an audit of changes

RAID log template

Many project teams set up a RAID log within an Excel or Google spreadsheet. You can use our RAID log template, but you can also see numerous examples online. As you start to use them within your own organization, you’ll start to adjust the log so that it works for you and your projects.

What are the benefits of using a RAID log?

The most obvious benefit to using a RAID log is that the log becomes a central repository for lots of information relating to your project. This supports all project team members in keeping on top of the elements that are influencing the success of their project.

You can see who has or hasn’t done what they’ve said they were going to do, or where the project is most likely to struggle. You can see who is making all the decisions and can look back to justify the approaches taken with clarity.

Finally, they are flexible. This means you can adapt them over time to meet the needs of your organization. If you want to make departments responsible rather than individuals, you can. If you want to have multiple status levels, you just need to update your template to cater for it. Whatever you need, a RAID log gives you the flexibility to find a way to meet that need.

Nonetheless, the log is only as good as the information put in it and the regularity with which it is updated and addressed. There’s no point in recording all the risks if no one seeks to mitigate them. There’s no point in only including half of the decisions being made as you won’t be able to generate the complete picture when you come back to look at what happened.

Should you use a RAID log?

At the end of the day, it depends on you and your approach for project management. If you see value in keeping track of risks, actions, issues, and decisions, then give it a try. If you’ve already got this covered in another system, such as Jira or DevOps, then maybe you can do without it. The choice is yours!