RAID Log

RAID Log (risks, actions, issues, decisions) (XLSX)

Purpose of RAID Log

A RAID log is a simple, effective project/program management tool to organize a project/program by tracking risks, actions, issues, and decisions.  The risk log records information such as triggers, probability, impact, mitigation, owner, et cetera for things that could go wrong but have not yet occurred.  The actions log records information such as owner, due date, completion date, et cetera for things that need to be done.  The issues log records information such as issue description, owner, resolution, et cetera for known problems that have occurred (if a risk triggers, it becomes an issue as well).  The decision long records information such as decision description, date, who decision was made by for decisions made in the project/program.

The right level of detail needs to be determined for the RAID log, dependent upon the project/program so that it is an effective tool for audits, governance, and oversight of the project/program.  It is a dynamic document that is constantly maintained throughout the project/program.

RAID Log Participants and Audiences

Input into the RAID log will come from many sources such as the Information Risk Assessment (IRA) process, project documentation (charter, business case, intake form, meeting minutes, et cetera), sponsor, project team members, and other stakeholders.  Another valuable source would be documentation (risks, issues, lessons learned, et cetera) from other projects that may be similar in nature.

The author and maintainer is often the Program/Project Manager.  Sometimes others may be providing updates, especially to the issues log.  The Project/Program Manager will have to create a  process for ensuring the RAID log is kept up to date and proper version control occurs based upon the requirements of their project/program.  Some Project/Program Managers prefer to be the sole author, and some allow others to update.  Some Project/Program Managers may use others tools such as ACE Project or RT as their issues log and just use this document for risks, actions, and decisions.

Instructions

Risks:

1. Collect all inputs: scope baseline (scope statement, requirements, WBS), risk management plan, cost management plan, schedule management plan, quality management plan, human resource management plan, activity cost estimates, activity duration estimates, procurement documents, stakeholder register, project documents and University Policy 11
2. Identify risks, with special attention to review the risks in the risk register in Appendix A of the Risk Management Reporting Guideline
3. Analyse the risks for likelihood and impact and assigned risk ratings
4. Evaluate the risks according to the University’s and other stakeholder’s risk appetite.

5. If the risks scores indicate the risk is very low, low or medium, monitor the risks. If the risk’s score indicates the risk is high or very high, address this risk by assigning a risk response and identifying the individual who will be responsible for taking action and monitoring the results. Escalate risks as identified in risk management planning, monitoring and reporting requirements chart.

5. Communicate risks according to the communication plan and risk management planning, monitoring and reporting requirements.
6. Continue monitoring and updating risks throughout the project. Ensure those responsible are following through on any mitigations or actions to take advantage of opportunity risks.

Actions:

1. Add program/project action items to action log, according to the level of detail required for project/program and assign an owner.
2. Monitor action items continuously, and provide updates on status and when it is closed.

Issues:

1. Add issues as they arise to the issues log, according to the level of detail required for project/program and assign an owner.
2. Monitor issues continuously, and provide updates (on a recurrence cycle predetermined for project/program) on status and resolution.

Decisions:

1. Add decisions as the arise to the decision log, according to the level of detail required for project/program, with justification on why the decision was made.

Green italic text rows provide an example.  These rows can be deleted. 

File in document repository.

Next Steps

Update project documents, such as the project schedule, based on risk information. Contingency many need to be added to the schedule and the budget to account for risks that have been identified.

If a risk occurs, transfer the risk to be managed within the issue log, ensure somebody is named accountable for the issue, and manage it as an issue to be resolved for the project.

The risk register or RAID log is a living document. It should be reviewed with the project team and project governance regularly. During reviews, the RAID log will be updated with new information and new risks. Existing risks may also change in impact and likelihood so they need to be monitored as well.

At project closure the risk register or RAID log should be reviewed one last time. Which risks occurred and which did not? Outstanding issues and risks should be communicated during transition to operations. Decision information should also be shared during the transition to operations. Use this information to update the lessons learned from the project/program.