Risk management is critical to the success of any project. If during the planning stage of the project management process, a risk management plan is not implemented, the project in all likelihood will fail. In my previous article ‘A Practical Approach to Creating a Risk Management Plan,’ I introduced a seven-step process for creating a risk management plan. In this article, I will highlight the next step in the risk management process, creating a risk register.
An essential tool in any project man
agement methodology is the risk register or risk log. This document is a means of recording the identified risks, their severity, and the actions steps to be taken. The risk logic can be a simple document, spreadsheet, or a database system. The most effective format for this document is a table, because it will allow a great deal of information to be conveyed in a few pages. If the information is presented in a paragraph form, you run the risk of people not reading it, although all of the relevant information is there.
As the use of risk management as an integrated process of project management has grown over the years, risk management information systems (RMIS) have evolved. RMIS stores data for creating reports and serves as the repository for all current and historical information related to project risk. The risk register should evolve over time with potential risks removed and new ones added as the project progresses.
The best way to view the risk register is as a management tool through a review and updating process that identifies, assesses and manages risks down to acceptable levels. It provides a framework in which problems that may arise and adversely affect the delivery of the anticipated benefits are captured and actions instigated to reduce the probability and the impact of that particular risk. Make your risk register visible to the project stakeholders so they are able to see risks that concern them being addressed. They may flag new risks you haven't identified, and give other options for risk mitigation.
There is no standard list of components that should be included in the risk register. The Project Management Institute Body of Knowledge (PMBOK) and PRINCE2 among other organizations make recommendations for risk register contents, but they are not set in stone. I have comprised a list of some of the most widely used components. They are as follows:
- Dates: As the register is a living document, it is important to record the date that risks are identified or modified. Optional dates to include are the target and completion dates.
- Description of the Risk: A phrase that describes the risk.
- Risk type (business, project, stage): Classification of the risk, business risks relate to delivery of achieved benefits, project risks relate to the management of the project such as timeframes and resources, stage risks are risks associated with a specific stage plan.
- Likelihood of Occurrence: Provides an assessment on how likely it is that this risk will occur. Examples of classifications are: L-Low (<30%), M-Medium (31-70%), H-High (>70%).
- Severity of effect: Provides an assessment of the impact that the occurrence of this risk would have on the project.
- Counter Measures: Action to be taken to prevent, reduce or transfer the risk. This may include production of contingency plans.
- Owner: Individual responsible for the ensuring this risk is appropriately managed and counter measures are undertaken.
- Status: Indicates whether this is a current risk or if risk can no longer arise and impact the project. Example classifications are: C-current or E-ended.
- Other columns such as quantitative value can also be added if appropriate.
Provided below are two sample risk registers. Sample 1 is a simple risk register with standard components. Sample 2 is more complex. It includes columns for the how the risk affects the project cost how the risk affects the project schedule.
The following are tips for using the risk register template that is available in the project management media gallery, or any other risk template.
- Create your first risk register when the project plan is approved, using the risk section of the Project Plan as initial content.
- Change the title of this document by clicking "View" in the Tools Menu and selecting "Header and Footer" and then "Custom Header."
- Active risks in a period should be recorded in the Project Status Report for that period according to the thresholds for reporting risks in the risk management plan.
- Identifying new risks and updating this log should be part of an ongoing risk management process with clear roles and responsibilities. See the Risk Management Plan Template for suggestions on these.
- Each risk should be assigned a number as a unique identifier (see left hand column) that does not change over the life of the project and that is also used on the Project Status Report, Risk Identification Form, and Risk Impact Form.
- There should be specific definitions for the terms high, medium, low, near-term, medium-term, and far-term.
- If something is already occurring, it is an issue, not a risk. All risks that have become issues should go through an issue management process, but do not delete them from this record.
It is recommended that you review your risk log regularly, especially prior to progressing to the next phase of the project and ensure your Project Sponsor is aware of the risks associated with the project. Risks exist in all projects. Don’t skip the risk management process because not taking the time to indentify and document the risks could end up killing the project. Creating, maintaining and utilizing a risk register is a great tool for successfully managing a project.