Learn 100% online from anywhere in the world. Enroll today!


An project management tool used for centralizing and simplifying the collection, monitoring, and tracking of project information

What is a RAID Log?

Project management involves multiple facets, whose implementation and monitoring can be quite time-consuming. Therefore, it is crucial for project managers to identify opportunities that help increase efficiency and quality. One strategy that individuals use is RAID, which stands for Risks, Assumptions, Issue, and Dependency. A RAID Log is an effective project management tool that is aimed at centralizing and simplifying the collection, monitoring, and tracking of project information. Read on to learn more about RAID log in managing projects.


RAID Log example


Risks and Issues in RAID

Risks are future uncertainties that can affect a project negatively. A project manager should put measures in place that help to deal with risks, which arise along the way. There are several ways that he can go about the process. They include risk identification, classification, risk evaluation and creating risk response plans. For a project to run smoothly, there should be as few risks as possible.

Also, it is crucial that risks are identified in the early stages before they advance to severe issues that can cause an entire project to fail. Some of the risks and issues that can come up are:


1. Resource Availability

Perhaps the biggest concern among project managers is whether they will get the resources they need throughout the project. But with proper planning, a project manager can guarantee that resources won’t run out midway through the project. Apart from resource availability, resource continuity should also be taken into account. To put it simply, this is meant to ensure that the same resources are available for the duration of the project. Replacing resources in the middle of the project can cost a considerable amount of time and money.


2. Market Risk

Another uncertainty that must be taken into account is market risk. Put simply, it is the impact on a project that can result from new changes being introduced into the market. For instance, consider an industry where technology and innovation happen rapidly. For projects to thrive in such an environment, they must be completed in time before they are rendered obsolete.


3. Fluidity

Project managers also need to assess whether the organizations they work in are fluid. For instance, are the project members likely to change their minds? Or will you be introducing your product in a market that changes quickly? If so, there should ample flexibility on the part of the project manager so as to adapt to the ever-changing industry.


4. Regulatory

The laws that apply in a state can also pose risks to your project. So, before anything else, project managers should familiarize themselves with the laws that apply to their industry to avoid breaching them unknowingly. They also need to check the corporate structures being adopted by stakeholders. This way, they can ensure that the actions of a particular player don’t put the entire project at risk.


Project Dependencies

There are two main varieties of dependencies: outbound and inbound. Outbound means that the project relies on one activity being carried out by a particular team so as to proceed to another task or deliver results. Conversely, inbound means that other parties are relying on a particular team to finish a task before they deliver results. An example of an outbound dependency is when one has to wait for the legal department to review and approve a particular document before being allowed to make any adjustments to the system.

Getting a good understanding of the dependencies helps to identify and solve problems in their early stages. Other examples of dependencies are:

  • The owner of a system needing to complete coding changes before another individual can perform an end-to-end testing
  • When real estate officers must approve building designs before construction projects commence


Project Assumptions

People make lots of assumptions when undertaking a particular project. It happens during the initial stages of the project. The one thing you shouldn’t forget to do is to document these assumptions formally. This way, if disputes arise later, the stakeholders involved can always refer to the fine print.


The RAID Log

Now that we are familiar with what the RAID acronym stands for, the next thing to look at is the RAID log. The log is simply a list of all the risks, assumptions, dependencies and issues. It is introduced at the project’s initiation stage, where it’s used to capture vital elements. The raid log becomes refined as the project progresses.

The RAID log highlights each factor separately. Here are the main elements listed under each section of the log.


1. Risks and Issues Section

The risk and issues part includes:

  • A distinct identifier for easy referencing
  • The date when a particular item is logged
  • A summary of the key issue or risk
  • A detailed description of the issue or risk
  • The impact that could arise if the risk develops into an issue. Will the impact be high, low or medium?
  • Probability or likelihood of the risks occurring

Every risk and issue needs a mitigation plan. There are several ways of mitigating risks such as informing your management of the issue or risk, accepting the risks and acknowledging that there’s nothing that can be done or taking the necessary action to eliminate the risks.


2. Dependencies Section

Dependencies always need to be agreed upon by the parties involved. It means that a project manager cannot hold a stakeholder liable for an issue that he did not agree to in the first place. The dependencies section of a RAID log highlights:

  • A distinct and sequential indicator for easy referencing
  • The date an issue is logged
  • Specification of whether the dependency is inbound or outbound
  • A detailed description of the dependency
  • A summary of the dependency
  • The specific date when the dependency will be delivered
  • The parties that consent to the dependency
  • Comments – All the comments are listed in the log. Each comment needs to be preceded by the date and name of the individual who made the comment.


3. Assumptions Section

It’s important to always document the assumptions that come up in the course of the project. It helps to prevent miscommunication and potential conflicts. Assumptions are useful at the start of a project. The assumptions section will highlight:

  • A distinct and sequential indicator for easy referencing
  • The date when an item was logged
  • A summary of the assumptions
  • A detailed description of the assumptions
  • Status – Are the items brand new, in progress or closed?
  • The stakeholders consulted when coming up with the assumptions


The Bottom Line

The RAID log is a must-have communication tool for project managers. Not only does it make it easy to track activities, but is also key to keeping all stakeholders informed. However, the RAID log should be updated from time to time to keep it effective.


Related Readings

CFI is the official provider of the global Financial Modeling & Valuation Analyst (FMVA)™ certification program, designed to help anyone become a world-class financial analyst. To keep advancing your career, the additional resources below will be useful:

  • Guide to Data Presentations
  • Project Budget Template
  • Market Risk Premium
  • Systemic Risk

Financial Analyst Certification

Become a certified Financial Modeling and Valuation Analyst (FMVA)® by completing CFI’s online financial modeling classes and training program!