Some project managers tend to focus more on issue or risk management rather than giving equal focus to the four areas of RAID for project management (Risk, Assumptions, Issues, and Dependencies).

 A lack of focus on any one of these areas is a risk itself and can result in a negative effect and take a project off course.

What is a RAID Log in Project Management?

RAID refers to Risks, Assumptions, Issues, and Dependencies on the project.

• A risk is a possible future issue, i.e., something that may go wrong.
• An assumption is a factor that is assumed to be true for project success.
• An issue is a risk that has occurred, is current, and must be properly addressed to avoid delays in project execution.

A dependency occurs when an output from one task or another project is needed as a mandatory input for another task or project, which can impact the project schedule and affect the project outcome.

What Are the Benefits of Using a RAID Log for Project Tracking?

The RAID log is used to track these elements during the project, adding an extra layer to RAID risk management strategies.

The log should be created at the outset of the project to capture details early on and constantly update as work progresses.

The document, often a spreadsheet or BrightWork 365 project template, typically records information such as:

• Project name
• RAID item and ID number
• Date raised
• Description
• Likelihood of occurrence
• Impact on the project
• Action plan, including owner and due date
• Date closed

The RAID log project management tool is a useful way to track progress, maintain control over the project, and share updates easily with stakeholders during project meetings.

How BrightWork 365 Helps in Managing RAID Elements

A great benefit of BrightWork 365 is the management of Issues and Risks is part of the solution with automated, configurable RAID metrics and the ability to customize Microsoft 365 templates to suit the needs of an individual organization.

To meet the requirement of a complete focus on RAID including the Assumptions and the Dependencies, I typically customize the Project Statement on the Project Template being used so these two areas are captured by the Project Manager when creating a project.

This means that information on Risks, Assumptions, Issues, and Dependencies is always visible to someone managing and reviewing the project so they have a full understanding of the RAID context and status.

4 Key Areas for Project RAID Management Success

Each area of RAID management requires careful tracking to mitigate the potential negative impacts on project success. Identifying these elements enhances project control and stakeholder communication.

1. Risks

• A risk is a possible future issue, i.e., something that may go wrong.
• The definition of a risk is any specific event which might occur and thus have a negative impact on your project or program.
• Each risk has an associated chance of occurrence along with an impact on your project if it does materialize.
• This is the one key area where project managers focus upon in the managing and mitigating of risks.
• Your project risks are the “issues” waiting to happen.
• If the likelihood of the event happening and the impact on the project are both high, the event is classed as a risk.
• All risks should be logged, no matter how small, and recorded in the RAID log project management system to ensure they’re addressed effectively during the project lifecycle.
• All risks should have an ID number and all risks should be owned by someone who has been involved in the discussion about the specific risk.
• In addition, all risks should be measured in a standard way with probability and impact.
• In the risk log section, there should be columns for the risk owner, status, and any dates that may be relevant.

 2. Assumptions

• The definition of an assumption is something that is set as true to enable an organization to go ahead with a project.
• As part of the initial project planning phase and project brief, assumptions are identified and documented. Unfortunately, many times, they are just forgotten after this first activity, which can jeopardize the project scope if they turn out to be incorrect.
• Including assumptions in the RAID document ensures that they are monitored and adjusted throughout the project execution.
• A common assumption in many projects is there will be access to the required specialist resources for the duration of the project.
• The purpose of tracking assumptions is you need to be ready for your assumptions to be wrong.
• Most project plans are produced on this assumption, but if this assumption turns out to be false, then the project will falter.
• It is important to include the identified assumptions in a project document such as a Project Brief (PRINCE2).
• Any assumptions made about the delivery of externally controlled deliverables should also be included.
• If there are actions that can be taken to avoid the consequences of an assumption not being true, it should be considered (and managed) as a risk.
• If an assumption cannot be changed,  it should be considered (and managed) as a constraint.
• If an assumption uses words like ‘relies on’ or ‘depends,’ it should be considered (and managed) as a dependency, which in itself should be managed as a risk.

3. Issues

• An issue is a risk that has occurred, is current, and must be properly addressed to prevent disruptions in project tasks.
• Like risks, issues need to be managed through an agreed management process.
• An issue is anything which arises on your project which you have to deal with to make sure your project runs smoothly, for example, deviation from the approved scope.
• As with risks and actions, all issues should have an assigned ID, owner, and timescale to ensure they’re properly managed and integrated into RAID project management practices.

Consequences of Poor Issue Management

Failure to manage issues may result in poor delivery or even failure.

The RAID log includes a description of each issue, the impact it is having, its seriousness, and actions needed to contain and remove it.

Types of Project Issues to Monitor

Issues can be any of the following:

• A risk that has gone live and requires attention.

• An unresolved question (e.g., from the Project Brief).

• New ideas or concerns.

• Potential changes, e.g., a need to change a deliverable.

• An unexpected event that has occurred, e.g., a contractor going bankrupt.

• A problem that will impact another project’s objectives.

Strategies for Resolving Project Issues

Issues can be resolved in several ways, such as:

• Cleared immediately with no action required.

• Additional planning is undertaken, and new deliverables are added, or existing project deliverables are changed.

• An issue becomes a risk with an appointed owner.

4. Dependencies

• Dependencies exist when an output from one task or another project is needed as a mandatory input for another task or another project.
• Managing dependencies with a clear RAID framework helps project team members coordinate their work, which minimizes delays in the project management process.
• Dependencies form a key part of workload prioritization during the programme and are a basic agenda item for any meetings and decision-points. As such, they must be consistent with all other aspects of the plans, projects, and programs.
• It is a key responsibility for project managers to record, monitor, and manage these dependencies.
• As dependencies may be items being delivered from elsewhere, they are not always under the direct control of a project manager.
• Poor management of project dependencies often leads to project failure.
• The dependencies log captures these relationships, what is required, and when.
• PMs should also keep details of the actual agreement and when it was made, along with any iterations of this agreement.

Editors note: This post has been updated for freshness, comprehensiveness, and accuracy. This post and One-Page Plan was provided by Ken Martin.