What is a RAID Log?

A RAID log is a project planning tool for identifying key (R)Risks, (A)Assumptions, (I) Issues, and (D)Dependencies. Based on what is identified, the impact is assessed and appropriate strategies are put in place. This ensures that everyone stays aligned and the project is not negatively impacted. 

This is created at the start of a project and continues to be referred to throughout the life cycle of the project to ensure everyone continues to be aware of what is important. 

GroupMap RAID log board tracking risks, assumptions, issues and dependencies

Start a RAID Log in GroupMap

A RAID log template lets you continuously record project risks, assumptions, issues and dependencies over a period of time in an organized way. The team can easily refer to it in project audits and update meetings. This helps keep the conversations flowing.

The RAID log focuses on four key areas:

  • Risks – events that can have an adverse impact if they occur. They may not have happened yet, but would result in a negative consequence.
  • Assumptions – things you assume are in place which contribute to the success of the project. These can be both from a positive or negative point of view.
  • Issues – current matters that need to be considered and addressed by the group. These are risks that have already occurred and need to be addressed.
  • Dependencies – other projects or triggers that your project depends on, or are a beneficiary of your project outcomes.

The actions and decisions variant

Not every project reads RAID the same way. The common alternative keeps the R for risks and the I for issues, but uses A for actions, the tasks the team has agreed in order to deal with what has been logged, and D for decisions, the choices made along the way with the reasoning behind them. Delivery leads who already track assumptions and dependencies in a plan often prefer this reading, because the log then doubles as the record of what was agreed and who is doing it.

Both versions are in everyday use, and neither is more correct than the other. Settle on one before the first session, write the four words at the top of the log, and keep them consistent so nobody has to work out whether an item is an assumption or an action.

Who can use a RAID Log?

Project teams, especially those in the engineering, construction and IT industries, routinely use a RAID log. However, because of its simplicity, the methodology is relevant to:

  • All industries
  • Existing and new businesses
  • All levels of an organization
  • Business processes

Why maintain a RAID Log?

A RAID log is a practical tool for managing projects. Use it:

  • During the initial planning phase to perform a broad environmental scan.
  • To consolidate information to assist regular reviews that keep the project on track.
  • As a way of involving the whole team to identify critical issues that have an impact on the project.
  • To assess changed project conditions.
  • As a way to optimize effort and use of resources.
  • To show stakeholders that the project is under control.
  • As evidence for input or support from management.

RAID Log template

A RAID log template is an organized and effective way to ensure that your project team is given the opportunity to share and capture risks, assumptions, issues and dependencies that may impact your project. By having an easy way to capture, assess and take action each one reduces the overall risk in your project, and ensures there is alignment of understanding in the team. 

A RAID log template is organized as a 2 x 2 matrix, resulting in four quadrants; one each for Risks, Assumptions, Issues, and Dependencies. Each area is addressed by either mitigating, monitoring, validating, or removing it from the project.

Risks

Risks are things that will have an adverse impact on the project if they eventuate. Their significance is calculated from the likelihood they’ll occur, along with the impact on the project if they do.

Ask: What events might occur that will have an adverse impact?

Actions: Implement risk mitigation strategies based on the significance of each risk.

See also: Risk Assessment

Issues

Issues are risks that have already occurred and have impacted on the project. You must get them under control immediately to keep the project on track.

Ask: What events do we need to address to ensure the project runs to plan?

Actions: Contain or remove the issue.

Assumptions

Assumptions are things that you assume will happen to assist the project, but aren’t guaranteed. If the assumptions are incorrect, there will be a consequence for the project.

Ask: What presumptions have we made about things that will make our project successful?

Actions: Regularly reassess assumptions to test if they’re still valid.

Dependencies

Dependencies may relate to other projects, partners, or suppliers. They are things that must start or finish so your project can progress. They might also be others that rely on your project as an input.

Ask: Who or what do we depend on and who depends on us?

Actions: Monitor and manage dependencies.

RAID log columns

Once items leave the quadrants and go into the log, the log works as a table with one row per item. These are the columns most projects use. Add or drop columns to suit the work, but keep an owner and a status against every row, or the log quietly turns into a list nobody acts on.

ColumnWhat it is for
IDA short reference such as R1, A2 or I3, so an item can be named in a meeting without reading out the whole description.
CategoryWhether the item is a risk, an assumption, an issue or a dependency.
DescriptionOne plain sentence: what the item is, and why it matters to this project.
Impact and probabilityHow hard it would hit the project, and how likely it is. Rate both, or rate impact alone if you want to keep the log light.
OwnerThe one person accountable for acting on the item and reporting back. Shared ownership means no ownership.
StatusWhere the item stands today: open, in progress, monitoring, validating, mitigating, or closed.
Due dateWhen the next action or review is expected. This is the column that makes the log a working document rather than an archive.

Some teams add a date raised, so they can see how long an item has been sitting, and a mitigation column that records the agreed response next to the item itself.

In GroupMap, the rows come out of the session itself. Export the results to PDF, CSV or Excel and they populate or refresh the log you keep between meetings.

RAID log example

Here is what a RAID log looks like part-way through a project. The project is a website replatform for a mid-sized retailer, with cutover set for the first week of October.

IDCategoryDescriptionImpactOwnerStatusDue
I1IssueStaging does not match production, so test results are not trustworthyHighPlatform engineerIn progressAug 29
D1DependencyNew payment provider API keys must be issued before the checkout build startsHighDelivery leadOpenSep 5
R1RiskLegacy product data may not map cleanly onto the new catalog schemaHighData leadOpenSep 12
A1AssumptionThe content team will have the priority pages rewritten before the content freezeLowContent managerValidatingSep 19
R2RiskSearch rankings drop if the redirect map is incomplete at cutoverHighSEO leadMitigatingSep 26
D2DependencyThe campaign launch depends on the new site being liveLowMarketing leadMonitoringNov 2

Read down the impact column and the shape of the project is obvious: the staging environment, the payment keys, the schema mapping and the redirects are where the attention goes, and A1 is the one item somebody has to go and confirm rather than manage.

Two of these rows show the log doing its real work. R2 is a risk, so it is being mitigated before it lands. I1 was a risk once as well. It has eventuated, so it moved to the issues list and picked up the nearest due date on the log. That movement between categories is the point of keeping the log current rather than writing it once at kickoff.

RAID log vs risk register

A risk register tracks risks only. A RAID log tracks four kinds of item, risks, assumptions, issues and dependencies, in one place.

The difference is scope, not rigor. A risk register usually sits inside a formal governance process: every risk gets a likelihood, an impact, a mitigation, an owner and a review date, and the register is reported upward. A RAID log is the project team’s working record. It holds risks too, but it also holds the things you are quietly relying on, the problems already in front of you, and the other teams whose timing you cannot control.

Plenty of projects run both, and that is a reasonable answer rather than a compromise. The register satisfies governance; the log is what the team actually looks at in the weekly review. If you keep only one, keep the RAID log, because an assumption nobody checked and a dependency nobody chased will sink a project just as fast as an unmanaged risk.

If you want risks rated before they land in the log, run a Risk Assessment with the group first. The risks that come out of the top of that matrix are the ones worth a row.

How to use the RAID Log template

At the start of your project, create a new template and share the purpose and how it is to be used with the team. Explain that one of the goals is that it can be used as a parking lot for those risks, assumptions, issues and dependencies that come up so that meetings do not become stuck. 

Items can be captured under each heading as conversations progressed, although it is possible just to use it as a stand alone activity to brainstorm ideas generally on what could have a positive or negative influence on your project.

Items on your RAID log can then be rated to assess its impact on your project.

High Impact – Will have a significant negative impact on the speed, profitability or outcomes of your project.

Low Impact – Will have a low negative impact on the speed, profitability or outcomes of your project.

Invite representatives from all areas of the project to help complete the RAID Log. Using online technology allows you to involve remote teams. Collaborative brainstorming tools such as GroupMap enable facilitators to bring together distributed teams and ensure everyone’s ideas and ratings are captured. Not only will it capture ideas in real time, but it will also show you the average and spread of the rating results so that you can use it to facilitate conversations when there is a difference in views.

Clarify the objectives of the session and define the scope of the RAID Log. Provide context for participants by presenting relevant data and information. Examples might include:

  • The project scope or briefing document.
  • Stakeholder expectations or key deliveries.
  • Relevant outcomes from a Business Impact Assessment, Business Model Canvas, or SWOT Analysis.
  • Quality control data.
  • Retrospectives from previous projects.
  • Relevant rules and legislation.

As discussions progress, participants capture risks, assumptions, issues, and dependencies that will influence the project.

This is generally done collaboratively so that everyone can see the ideas in real time throughout the life of the project. You can capture additional descriptions and comments so that you can get a complete picture.

You can continue to capture items throughout the life cycle of the project. GroupMap lets you continue to add to your RAID Log Template so that it stays current and fresh.

Each item can then be assessed to understand the level of impact it can have on the project.

Low impact – minimal negative impact on the speed, profitability or outcomes of your project.

High impact – significant negative impact on the speed, profitability or outcomes of your project.

This has the effect of focussing your team’s actions and energy on the items that are the most important.

Identify actions to manage the priorities, then assign responsibilities and milestones.

  • Prevent, reduce, control, or insure against risks
  • Verify and monitor assumptions
  • Control or eliminate issues
  • Monitor and manage dependencies

Generate a report on the outcomes from the RAID logging session. Include the priorities, actions, responsible persons and deadlines for completion.

Regularly review and update the document.

  • Close out risks and move them to the issues list if they eventuate.
  • Close out issues once they’ve been dealt with.
  • As the project conditions change, reassess assumptions and dependencies and assign them as risks or issues if appropriate.

Align and integrate your RAID log with other project documentation.

GroupMap automatically generates visually appealing reports in several formats for distribution, saving time and effort after the workshop.

Tips for effective RAID Log

  • Create and introduce the RAID log to the team and explain it’s purpose in terms of being a parking lot for items that might come up during the project meetings.
  • Allow everyone to be able to add and comment on items in the RAID log so that all aspects can be captured and different perspectives are shared.
  • Ensure that people understand the difference between what is a risk, assumption, issue and dependency.
  • The RAID analysis can be conducted as an ongoing activity, or a standalone activity.
  • Use the Ratings feature to assess the level of impact each item can have on your project. This will focus the teams energy and attention.
  • Communicate outcomes to stakeholders and regularly update progress on actions.

The RAID Log template template shown in GroupMap on a laptop, tablet and phone

Save effort, time and money with GroupMap

GroupMap offers more than just an online digital whiteboard. Its innovative platform is designed to enhance the quality of your team’s decisions. With features that prevent bias and keep facilitation simple, GroupMap makes sure no single voice dominates and keeps conversations productive and inclusive. Its intuitive interface is easy for anyone to use, and its scalable design supports small teams and large groups whether they are face to face or around the globe. Customizable templates and workflows keep discussions focused on objectives, helping you drive actionable outcomes each and every time.

Frequently asked questions

What is a RAID log?
A RAID log is a project management tool for recording and tracking Risks, Assumptions, Issues and Dependencies over the life of a project. It is created at the start and referred to throughout, so the team stays aligned on what is important.
What is the difference between a RAID log and a RAID analysis?
A RAID analysis is the assessment that identifies and rates risks, assumptions, issues and dependencies. A RAID log is the living document that records those items and keeps them current as the project progresses.
What does RAID stand for?
RAID stands for Risks, Assumptions, Issues and Dependencies. Some project managers use the A for Actions and the D for Decisions instead, to suit the nature of their project.
What is the difference between a risk and an issue in a RAID log?
A risk is an event that could occur and would negatively affect the project. An issue is a risk that has already occurred and must be brought under control immediately. Once a risk eventuates, you close it as a risk and move it to the issues list.
How do you rate items in a RAID log?
Each item is rated by its impact on the speed, profitability or outcomes of the project. High-impact items have a significant negative effect and low-impact items only a minor one, which helps the team focus its energy on what matters most.
When do you create a RAID log?
You create a RAID log at the start of a project and keep adding to it as risks, assumptions, issues and dependencies come up. It often acts as a parking lot in meetings so discussions do not get stuck, and it is reviewed and updated regularly.

How to run it in GroupMap

  1. Illustration of the objective-setting step in a GroupMap session

    Scope

    Give context and identify the scope of the RAID Log template for your project.

  2. Illustration of the brainstorming step in a GroupMap session

    Brainstorm

    Gather input and ideas for each of the four quadrants.

  3. Illustration of the rating and prioritizing step in a GroupMap session

    Rate

    Rate the impact of each risk, assumption, issue or dependency on the project.

  4. Illustration of the action-planning step in a GroupMap session

    Action plan

    Create an action plan assigning responsibility for each issue to a group or individual.

  5. Illustration of the results and reporting step in a GroupMap session

    Share

    Report on the outcomes and monitor as part of your project management processes.

Ready to run a session?Use this template

Ready to get everyone on the same page?

Start a free GroupMap and turn your next discussion into clear, shared decisions.