A critical component of any well-managed project is the discipline of risk planning and management. Risk is uncertainty concerning events which, if they occur, will have an impact on the project. Note that these impacts can be either positive or negative. The process of risk management entails planning for, identification, analysis, and controlling this uncertainty on the project. One of the primary tools used in project risk management is the Risk Register. This article presents the Standard Point Prox Risk Register Template and goes through the fields therein. It will give explanations on how you can use the Risk Register template in your project to increase the probability of success.
Risk – if your shoe becomes untied you might trip on the laces and fall down.
The above is a simple example of an identified risk: The uncertainty event is your shoe lace becoming untied and the impact of the risk occurring is that you may trip resulting in a fall.
To address the risk, you might:
- opt for shoes with buckles which are less prone to unfastening
- wear loafers
- hold your spouse’s hand in case
- accept that shoe laces sometimes become untied and to pay attention if they start to get loose
If your project was such that it identified the shoelace uncertainty as a risk, it would need to be documented, along with information about addressing the risk and tracking information concerning. One of the first places a detailed risk would be recorded would be on the project Risk Register.
A Risk Register is essentially a log of identified risks with analysis, tracking, and planning information associated with the individual risks incorporated. It is the only explicitly identified output of the Identify Project Risks process according to the PMBOK, which indicates its importance in risk management. The Risk Register can be as simple as a table in an MS Word document all the way to integrated tools in an enterprise project management platform. The Risk Register is used throughout the project to maintain visibility and status of the risks associated with the effort.
Project Management is a Risky Business
The practice of project management can, in part, be thought of as an attempt to plan for and predict the future. It is concerned with the alignment of staff, cost, and time to achieve a specific output. The future is always uncertain and the planning process is an attempt to reduce this uncertainty. Even as we polish our crystal balls and use management tools to make the future clearer, only one thing is certain: projects are a risky business that can and do fail.
Risk identification starts with the creation of the project charter, which will outline some high-level risks in this initiating project document. Although the PMBOK flows have the “Identify Project Risk” process commencing after “Plan Risk Management”, you will begin to understand and identify potential risks even before the Project Charter is signed.
An explicit requirement of the Risk Management Plan is the development of a Risk Register template. The template is important as it provides a practical framework of the level of risk management anticipated for the project. This expectation is implicit in the structure of the Risk Register template.
Seeing into the Future: Identifying Project Risk
Continuing our practice of trying to know the unknowable, we will begin the exercise of detailed identification of risks on the project. After the Risk Planning Process, you will have a Risk Management Plan which will contain, amongst other things, three critical pieces of information for the population of the Risk Register:
- Definitions of Risk Probability and Impact Terms
- Template of the Risk Register
- A Risk Breakdown Structure or Categories List
This is not a once and done process. Risk identification will continue throughout the project. Depending on the risk methodology for the project, this may be a formal and scheduled process, or it may be something that is completed as a matter of performing other project related tasks. With either approach, newly identified tasks, risks that occur, and responses to the issues will be recorded in the Risk Register.
What Does a Risk Register Look Like?
You can download the Point Prox standard Risk Register template here. You might find it helpful to download the template and read along as we detail the components of the document.
Note that the fields on our Risk Register template are just a suggestion, but a hopefully good suggestion. It is recommended that you review historical information and Organizational Process Assets from your organization for recommended templates and historical examples. These may differ from the Point Prox Standard Risk Register template, but you will likely find many of the fields will be common to most.
The Risk Register template consists of two spreadsheets in an Excel workbook. The first sheet is titled the Risk Register, where you will be doing most of the work related to the document. The second sheet is called Validation and contains lists of values used to constrain data entries in some of the columns to valid values.
Following is an explanation of all the fields on the temple Risk Register. Note that some the fields could contain quite a bit of data depending on the methodology you are using. If you need to provide more detail than can comfortably be displayed on an Excel cell, provide a summary with a link to the location containing the detailed documentation.
Fields of the Risk Register Template
ID – Each risk should have an ID number. This can be as basic as a simple sequence or as complex as the hierarchical numbering conventions used in the Risk Breakdown Structure. The convention used should be part of the methodology outlined in the Risk Management Plan.
Description – You need to state what the risk is. The first sentence should follow a pattern which should be outlined in the Risk Management Plan. The pattern used here is “Risk Event may occur causing Project Impact“, although other patterns are certainly acceptable. The description should then contain enough information to fully understand the identified risk.
Date Identified – This is the date that the risk was and added to the register.
Last Update – The date that the risk documentation was last updated. If you are using addition documentation outside of the Risk Register, this field should be updated if those documents are updated in any material way.
Category – The category field should be the category from the Risk Breakdown Structure or defined categories list from the Risk Management Plan that applies to this risk. The data entries are constrained to the values in column ‘F’ in the Validation sheet. Add the values from your Risk Breakdown Structure to this column and then these values will be available for validation and displayed in the drop down menus in the Risk Register spreadsheet.
Trigger – Elucidates the condition or event that can trigger the risk to occur.
Threat/Opportunity – Indicates if the risk is a threat (negative impact on the project) or an opportunity (positive impact on the project). The valid values are ‘T’ and ‘O’. The cell will turn red or green respectively.
Qualitative Probability – A value from one to five that represents the probably of the risk occurring as determined by the Qualitative Risk Analysis process. The values should follow the definitions as stated in the Definitions of Risk Probability and Impact from the Risk Management Plan. The higher the number the greater the probability of the risk occurring.
Qualitative Impact – Represents a qualitative assessment of impact on the project objectives if the risk were to occur. Like the Qualitative Probability field, the meanings of the numbers are stated in the Definitions of Risk Probability and Impact from the Risk Management Plan. The higher the number, the greater the impact on the project.
Risk Rating – Calculated value indicating the overall qualitative risk based on the qualitative probability and impact assessments. The column is calculated by a formula and does not require entry.
Quantitative Probability – The percentage of the risk occurring as calculated by the Quantitively Risk Analysis process. The value should be between 0 and 100, inclusive.
Quantitative Cost – The cost of the of the risk, were it to occur, as calculated by the Quantitively Risk Analysis process. We have the cost at thousands of dollars. You should adjust this to meet the needs for how closely you track costs on your project. Opportunities should be entered as negative values by convention.
Quantitative Schedule – Impact on the schedule of the risk, were it to occur, as determined by the Qualitative Risk Analysis process. We have the units at work days. As with the Cost column, adjust as required for the level of calculations on your project. Opportunities should be entered as negative values.
Risk owner – Staff responsible for monitoring and tracking of the risk. This should general be a single individual even if a group is responsible for the risk. Someone always needs to be responsible for every risk, otherwise, you run the risk of the risk being ignored.
Response Strategy – The selected strategy for the response. There are four types of response strategies for threats and four for opportunities. Valid values are from the PMBOK, 5th edition, and listed on the Validations sheet. The list used for a cell is dependent on the value entered in the Threat/Opportunity for the risk. If a risk has more than one planned response, add another line and fill in the additional response. Repeat and populate this and the columns to the right as needed to add more responses.
Response – The planned response to reduce or enhance the risk’s occurrence and contingency planning if it occurs. Note that a risk may have more than a single response. A response could be defined to reduce the likelihood of a threat or enhance an opportunity. Another response could be a potential contingency plan if the risk manifests in a specific way. There should be a separate line for each response.
Response Owner – Every response has a response owner. This is the person who is responsible for executing or managing the execution of the response. It can be the same individual as the Risk Owner or someone else.
Status – The status of the risk. The valid values are listed on the validation sheet. You may change them if your organization uses different terms. The terms used here are:
- Active – a risk can still occur but has not yet
- Occurred – the risk has occurred but the response has not been completed
- Complete – the risk has occurred and the response has been completed
- Watch – the risk can still occur but the probability is so low that active risk monitoring is not required
- Retired – a risk can no longer occur
Response Notes – Notes regarding the response’s effectiveness and steps performed in response to the risk’s occurance. The cell may include multiple entries, if such is the case, add date accordingly.
Going Your Own Way
As noted above, the template is a recommendation. The way that you document risk on your project will be dependent on a number of variables, everything from the culture of the performing organization, the complexity of the project, and the risk sensitivity of the stakeholders, to name just a few. No matter how you manage risk and whatever you use as a Risk Register, it is critical that you perform the process as needed for your project. A Risk Register should become a standard tool and a matter of course for your project management practices.
References
Leave a Reply