The Risk Register, also known as a Risk Log, is a master document which is created during the planning stage of your project, as part of your risk management plan. This document contains all unidentified project risks, severity analysis, and evaluation of possible solutions.
The information in the Risk Register can be presented in a number of different ways, including database, spreadsheet, or a simple, paragraph-style document. One thing to note here, however, the spreadsheet-table layout is probably the best way to display the information contained in your Risk Register as a paragraph-style document will run the risk of people failing to fully read the document, skipping over important information.
Once created, the Risk Register becomes a project management tool that is used to track, review, and manage risks down to an acceptable level in order to deliver the expected project benefits and results. A good practice is to share the Risk Register with all of the project stakeholders as this will allow everyone involved to keep track of issues, flag new risks, and make suggestions on which action steps should be taken.
So what does the Risk Register compose of? While there are no standard components, your Risk Register should include information such as:
- Dates (Date Unidentified, Date Updated, Target Date, Closure Date)
- Risk Identification Number (unique number within the log)
- Description of the risk
- Risk type
- Risk severity
- Impact
- Possible response actions
- Risk owner
- Risk status
To get you started with creating your Risk Register, here is an Excel Risk Register template and tips on how to get started, courtesy of Natasha M. Baker at BrightHub:
1. Create your first risk register when the project plan is approved, using the risk section of the Project Plan as initial content.
2. Change the title of this document by clicking “View” in the Tools Menu and selecting “Header and Footer” and then “Custom Header.”
3. 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.
4. Identifying new risks and updating this log should be part of an ongoing risk management process (more in the article 4 tips-to-know on risk management for strategic IT management) with clear roles and responsibilities. See the Risk Management Plan Template for suggestions on these.
5. 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.
6. There should be specific definitions for the terms high, medium, low, near-term, medium-term, and far-term.
7. 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.
Follow us
