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

 

Webinar: 3 Simple Steps for Managing Project Risks in SharePoint

 

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?

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.
• A dependency occurs when an output from one task or another project is needed as a mandatory input for another task or another project.

 

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

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

The document, often a spreadsheet or SharePoint list, 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 is a useful way to track progress, maintain control over the project, and share updates easily with stakeholders.

A great benefit of BrightWork is the management of Issues and Risks are part of the solution with automated, configurable metrics and the ability to customize project 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 are 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

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 PMs do take 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 impact to the project are both high, the event is classed as a risk.
• All risks should be logged, no matter how small.
• 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 planning phase and project brief, assumptions are identified and documented. Unfortunately, many times they are just forgotten after this first activity.
• 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 being 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 into 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.
• 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.

 

Failure to manage issues may result in a 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.

 

Issues can be any of the following:

1. A risk that has gone live and requires attention.
2. An unresolved question (e.g. from the Project Brief).
3. New ideas or concerns.
4. Potential changes e.g. a need to change a deliverable.
5. An unexpected event that has occurred e.g. a contractor going bankrupt.
6. A problem that will impact on another project’s objectives.

 

 Issues can be resolved in ways, such as:

1. Cleared immediately with no action required.
2. Additional planning is undertaken and new deliverables added or existing deliverables changed.
3. 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.
• Dependencies must be delivered to enable successful outcomes. Dependencies must be identified and tracked as they will impact on the project going forward and being successful.
• 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 programmes.
• 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.

 

 

Image credit