What is Risk Register? All you need to know [ OverView ]
Last updated on 11th Jul 2020, Blog, General
(5.0) | 17954 Ratings
1674
The Risk Register contents Jump to the Risk Register Template Risk ID – a unique identifier for the risk Date raised – the date the risk was identified Risk description – best written as ‘There is a risk that xxxxx, because of xxxx if this occurs it will xxxx’ Likelihood – How likely is that the risk will occur. Can be 1- 5 or High / Medium / Low Impact – What will the impact be if the risk occurs. Severity – Likelihood x Impact Owner – The person who will be responsible for managing the risk. Mitigating action – Actions that can be taken to reduce the likelihood of the risk occuring. May also be acceptance of the risk or transferance of the risk e.g. insurance. Risk Mitigation techniques. Contingent action – What will be done if this risk does occur. Usually actions to reduce the impact on the project Progress on actions – A regular update on progress of the mitigating actions Status – For example Open, Waiting, Closed, in Progress etc.
Further reading on Risk Management Risk Assessment Business Risk Construction Risk Management Risk Management Glossary Risk Management Guidelines Risk Identification Risk Mitigation Techniques NHS Risk Register Risk Management Report Risk Responses Prince2 Risk Register Prince2 Risk Management Strategy
Needs of Risk Register
If you know what risk management is, then you’ll know that the next step to managing risk is strategically working to control the potential issues that are most likely to occur when you’re managing a project. Therefore you should have a mechanism in place to collect potential risks and then map out a path to get the project back on track, should those risks become realities.
The first thing you have to do is identify the risks. No one is asking you to consult a soothsayer, but experience should guide you. Projects are all different, of course, but for organizations that run similar projects year over year, there might be historical data to review to help identify common risks to those types of projects. Additionally, you can anticipate some risks based on market forces (supply and demand risks, for example), or based on common staffing or personnel issues, or even based on the weather.
To collect the possible risks that can show up when managing a project requires a systematic approach to make sure you’re as thorough as possible. The project risk register is a system, which can then track that risk if it in fact appears and then evaluate the actions you’ve set in place to resolve it.
When registering these risks on a spreadsheet or within your project management software, you have a place to put all this data and follow the specific risk throughout the project, thereby seeing if the actions you’ve put in place to remedy the risk are working. A risk tracking document therefore keeps the risk on a tight leash so it doesn’t run ruin over your project.
Of course, a document is static. To take your risk tracking to the next level, try ProjectManager.com. Our online project management software allows you to identify, assign and track risks on your project. This lets you track risks in real time, while communicating with team members via task comments and file attachments. Plus, email alerts help remind team members to resolve their risks in a timely manner.
12 KEY ELEMENTS OF A PROJECT RISK REGISTER
1. Risk Category – This is where you categorize your risk. Does it fall under the category of scope, time, cost, resources, environmental, or another key category? Using these categories helps tease out likely risks and groups them into relevant categories for future reference.
2. Risk Description – A brief description of the potential risk. For instance, the first potential risk identified in the Resources category is: “There is conflict over resources and team members don’t have enough time due to competing demands.”
3. Risk ID – This is a unique identification number used to identify and track the risk in the risk register. If Resources is Category 8, then the first risk identified in this category has a unique ID of 8.1.
4. Project Impact – A description of the potential impact on the project as a result of the risk. For example: “The project schedule may slip, budget may increase and project scope may not be achieved.”
5. Likelihood – The estimated likelihood or probability that the risk will occur at some point and become a project issue. This can be qualitative: high, medium, or low; but it can also be quantitative if enough information is available. For our example, we know that resources have been over-committed in the past and we assess the likelihood of occurrence as “High.”
6. Consequence – The potential consequence or impact of the risk if it did become a project issue. For our project, time is a fixed constraint, and so any risk that has the potential to significantly delay the project schedule has a “High” consequence.
7. Risk Rank – This is the magnitude or the level of the risk. It is a combination of likelihood and consequence. As they are both “High” in our example, then the risk rank is also “High.”
8. Risk Trigger – What are the triggers that would indicate the need to implement contingency plans? “If resource conflicts have not been resolved three weeks before the scheduled start date, then implement contingency plans.”
Get JIRA Training Course from leading Professional Certification Training Provider
Weekday / Weekend BatchesSee Batch Details9. Prevention Plan – This is an action plan to prevent the risk from occurring. For our example, the Prevention Plan includes: Liaise with functional managers and team members to pre-empt future conflicts; and specify and agree resource needs (staff and equipment) with functional managers.
10. Contingency Plan – This is an action plan to address the risk if it does occur. For our example, the Contingency Plan includes: “Train and up-skill existing team members in combination with HR department.”
11. Risk Owner – This is the person responsible for managing the risk and implementing the Prevention or Contingency Plans. Stakeholders, members of the project team, the Project Manager and the Project Sponsor can all be risk owners.
12. Residual Risk – This is the risk that remains after treatment is carried out. After treatment, we assess the residual risk level as “Low.”
HOW TO BUILD YOUR RISK REGISTER
GRC CONSULTANT EVAN STOS
By Sarah Nord
Risk Management is a business function with abundant insider terminology. Just as astrophysicists talk of quasars and gravitational waves and financial planners opine about amortization and turnover rates, risk management professionals speak fluently about velocity, persistence, inherent and residual risk, heat maps and more. For the “uninitiated,” the jargon can be dizzying.
One term you’ll hear while standing around the water cooler with a bunch of risk management professionals (don’t we all?) is risk register. The basic definition is simple: A repository of all risks that could impact a project, a legal entity or an entire enterprise.
But when you get beyond the basic definition, you’ll find plenty of variation in the details. To gain a better understand of what a risk register is, why it exists and what information it should contain, I interviewed Evan Stos, a Governance, Risk and Compliance (GRC) consultant who has helped more than 60 Fortune 500 companies gain control of audit, risk, compliance and information security processes. Here are a few insights from our conversation:
purpose of a risk register
A. A risk register allows you to see all of your potential risks in one place, to prioritize those risks and assign ownership, and to respond to them in some way. Risks pop up all over the organization, and if you don’t have a mechanism to capture and track them, you’ll never have a clear picture of risk (and potential business consequences) from a management perspective.
When you talk about risk ownership, what does that look like
A. Every risk needs an owner, and it’s usually 2-3 layers deep. First, you have the actual “risk owner,” who is typically an executive who’s responsible for managing and controlling identified risks. This is the big-picture person. Then you have a “risk manager” or “risk delegate” who is responsible for keeping tabs on the risk. That’s the detail person.
Risk owners and managers are not typically your Chief Risk Officer or VP of Risk Management (though for global, company-wide risks, they can be). In most cases, the owners and managers are out in the lines of business, deeply involved in the projects and processes where risks arise. By contrast, the CRO or VP of Risk Management is responsible for leading enterprise-wide identification, analysis and response to risks.
When logging a risk in the risk register, who’s involved and what info should you capture
A. In an ideal world, anyone in the organization could establish a risk, which would then go into a review process to determine its validity. But in reality, it’s typically the Enterprise Risk Management (ERM) Office that’s interfacing with different areas of the business to draw out information and capture it in the risk register.
When logging a risk, you need:
- A title and description with sufficient detail to understand what the risk is and how it could impact the organization
- An assigned risk owner and manager/delegate who will be responsible for monitoring and responding to the risk
- The risk category: strategic, financial, reputational, operational, IT, compliance, etc.
- The likelihood that the risk could occur and the potential impact the risk could have on the organization (typically measured on a 5×5 scale…more on this below)
- What causes (or could cause) the risk to occur, which is not always known
- How you’re going to respond to the risk, which is also called “risk treatment” (i.e., mitigate, accept, transfer or avoid) (See “Understanding Risk: Just Like Learning to Ride a Bike” for more details on risk response.)