Risk Register - Introduction
The Risk Register is the document containing the results of the qualitative risk analysis, quantitative risk analysis, and risk response planning. The risk register details all identified risks, including description, category, cause, probability of occurring, impact on objectives, proposed responses, owners, and current status. It is a spreadsheet containing all the statements of risk identified for the project.
The risk register is developed and maintained in accordance with Public Services and Procurement Canada (PSPC) risk management policies and standards.
The Risk Management Knowledge Area provides guidance on risk management processes and tools.
Risk Register Template
Risk Register
Table Summary
Section 1: This table describes detailed information about risks, project management team decisions, tracking and control, and risk closure.
| Risk # | Date Opened | Risk OPI | Risk Description | Risk Category | Probability | Impact |
|---|---|---|---|---|---|---|
| (#) | (dd-mm-yy) | (Name) | H M L | H M L | ||
Table Summary
Section 2: This table describes detailed information about risks, project management team decisions, tracking and control, and risk closure.
| Risk Treatment Strategy | Priority |
|---|---|
| (A)ccept, (M)itigate, (T)ransfer, (E)liminate | H, M, L |
Table Summary
Section 3: This table describes detailed information about risks, project management team decisions, tracking and control, and risk closure.
| Risk Management Plan | Risk Status |
|---|---|
| (O)pen (C)losed | |
Table Summary
Section 4: This table describes detailed information about risks, project management team decisions, tracking and control, and risk closure.
| Date Closed | Issue # | Lessons Learned |
|---|---|---|
| (dd-mm-yy) | (#) | |
Definition
Table Summary
This table describes the columns heading and descriptions in the project risk log template.
| Column Heading | Description |
|---|---|
| Risk # | The unique number of the risk being documented and managed. # is assigned by the Project Manager or delegated Risk Manager. |
| Date Opened | Date when the risk is identified and OPI is assigned. |
| Risk OPI | Name of the person assigned to develop, implement and manage the risk response plan. |
| Risk Description | A brief description of the risk. |
| Risk Category | Category or group to which the risk belongs. E.g. Business, Application, Project Management Process, etc. See Taxonomy worksheet for more examples. |
| Probability | (H)igh = >75% chance of occurring. (M)edium = 25 to 75% chance of occurring. (L)ow = <25% chance of occurring. |
| Impact | Impact of the risk: (H)igh, (M)edium, (L)ow. |
| Risk Treatment Strategy | (A)ccept: take no action as risk probability and impact are low. (M)itigate: take steps to reduce the probability and/or impact of the risk. (T)ransfer: assign the risk to an external body outside of the project. (E)liminate: take steps to completely eliminate the risk. |
| Priority | (H)igh, (M)edium, (L)ow. |
| Risk Management Plan | Brief description of the Risk Management Plan to be implemented to manage the risk. |
| Risk Status | Open = Risk is being managed. Closed = Risk is no longer being managed. |
| Date Closed | Date the risk is closed. |
| Issue # | If a risk is realized, most often, it becomes an issue. If it becomes an issue, the risk is closed and is recorded in the Issue Log. Record the associated issue # here. Risks that become issues remain in the Risk Log. |
| Lessons Learned | Yes or No: were lessons learned from the management of the risk? Optional summary text may be added. |
Taxonomy
The following includes some examples of risk categories and risks. These are intended to help during the risk identification stage.
This is not a complete or final list but is offered for suggestion only.
Table Summary
This table describes detailed risks related to product development, project management and project constraints.
| A. Product Development | Think about risks to the project that may arise from the nature of the product being developed. | |
|---|---|---|
| 1 | Requirements | Are there risks that may arise from requirements being placed on the product? |
|
||
|
||
|
||
|
||
|
||
|
||
|
||
| 2 | Design | Are there risks that may arise from the design chosen to meet the project's requirements? |
|
||
|
||
|
||
|
||
|
||
|
||
|
||
| 3 | Code and Unit Test | Are there risks that may arise from the method chosen to subdivide the design and construct the pieces? |
|
||
|
||
|
||
| 4 | Integration and Test | Are there risks that may arise from the way the project team is choosing to bring the pieces together and prove that they work as a whole? Examples of risk areas: hardware and software support facilities; integration of parts of the product; integration with the larger system. |
|
||
|
||
|
||
| 5 | Non-Functional Attributes (formerly : Functional Attributes) | Are there risks that may arise from special attributes of the product? |
|
||
|
||
|
||
|
||
|
||
| 6 | Development Process | Are there risks that may arise from the process being used to develop the product? |
|
||
|
||
|
||
|
||
|
||
| 7 | Development System | Are there risks that may arise from the hardware and software tools being used to control and facilitate the development process? |
|
||
|
||
|
||
|
||
|
||
|
||
|
||
| 8 | (Other) | Are there other risks that may arise from the nature of the product, but that are not covered by the above categories? |
| B. Project Management | Think about risks to the project that may arise from the way the product is being developed. | |
| 1 | Project Management Process | Are there risks that may arise from: the way the project budget or schedule is planned, monitored, or controlled; management experience; the project's organizational structure; or the way that internal and external organizational interfaces are handled? |
|
||
|
||
|
||
|
||
| 2 | Management Methods | Are there risks that may arise from the way the development or project personnel are managed? Risks may occur in areas such as status monitoring, personnel management, quality assurance, or configuration management. |
|
||
|
||
|
||
|
||
| 3 | Work Environment | Are there risks that may arise from the general environment in which the project is found? Risks may arise from areas such as attitude, cooperation, communication, and morale. |
|
||
|
||
|
||
|
||
| 4 | (Other) | Are there other risks that may arise from the way the project is being developed that are not covered by the above categories? |
| C. Project Constraints | Think about risks to the project that may arise from sources outside the project team's control. | |
| 1 | Resources | Are there risks that may arise because of resources needed for the project that cannot be obtained or maintained? |
|
||
|
||
|
||
|
||
| 2 | Contract | Are there risks that may arise from the [already legally] binding contract? |
|
||
|
||
|
||
| 3 | Project Interfaces | Are there risks that may arise from outside interfaces that the project team cannot reasonably expect to control? |
|
||
|
||
|
||
|
||
|
||
|
||
|
||
| 4 | Legal or Regulatory | Are there risks associated with legal or regulatory requirements? |
| Privacy | Are there risks associated with the privacy of employees, contractors or the Canadian public? | |
| 5 | Security | Are there risks associated with security, protection of assets, documents, data, etc? |
| 6 | Other | Are there risks that may arise from factors outside the project team's control, but that are not covered by the categories above? |
- Date modified: