Using a Risk Register in Your Organization
If you have ever managed a project then you know all about risks. They are the things that keep you awake at night. What if the vendor delivers late? What if the quality is lower than I expected? What if the estimates are wrong? What if..?
When a risk is realised, your project suffers. The project deadline gets missed, the project schedule gets blown, or something else goes badly wrong. The project suffers - and so does your professional reputation.
It doesn't have to be this way. You don't have to be beholden to fortune. Studies have shown that the use of risk management techniques lead to better project outcomes. You can take back control of your project, and deliver to time, budget, scope and quality. But project risk management is hard - and that's where we can help.
Understanding Risk
But first we must look at some fundamentals. Project risk management is now considered a staple process in many organizations and has become an increasingly important component of regulatory compliance. Experience shows, however, that the concept is still not well understood. A risk is essentially an "uncertain event." Every project, especially in a competitive business environment, deals with uncertainty.
While project uncertainty is ubiquitous, not all uncertainties matter. We are usually only concerned with project uncertainties that may result in monetary loss, capability delays, overspend, injury, share price reduction, reputational damage, and so on.
Given this caveat, a good definition of risk is "uncertainty that matters." This definition aligns well with the Project Management Book of Knowledge (PMBOK), which defines project risk as "an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives."
Why You Must Manage Risk
Given risk is ubiquitous, it might be tempting to ignore it, and many companies do just that. This approach could be dangerous as risks can present a severe threat to your project and to your business. For example, a large McKinsey study found that the average software project exceeded its budget by 66%, overran its schedule by 33%, and delivered a 17% shortfall in benefits. The average nonsoftware project underdelivered benefits by an extraordinary 133% (reference).
Can these metrics be equated with poor risk management? The answer is "yes," almost by definition. Except in the case of sabotage, any unwelcome deviation from the project plan (cost, schedule, benefits) is necessarily due to uncertainty. In other words, it is due to the realization of risks (whether identified ahead of time or not). Poor risk management matters.
It is easy to see how such massive variations to a project can ultimately impact profitability, reputation, share price, and so on. But the situation is even worse. The McKinsey study found that a staggering 17% of projects perform so poorly that they threaten the organization's very existence.
A realized project risk can reduce profitability, damage your reputation, tank the share price, and even destroy your company. Few organizations can afford to ignore them.
The Risk Management Process
Dealing with project risk requires you to adopt a risk management process. There are various formal processes defined these days, for example in the Project Management Book of Knowledge or the PRINCE2 methodology. Whilst these differ in detail, they are all mostly compatible with the ISO 31000 risk management standard, and all follow the same broad process. which may be considered best practice:
1. Identify
Identify the risks that are relevant to your project. Some of the tools you can use to do this are brainstorms, workshops, checklists, interviews, and surveys. Involving people with subject matter expertise is especially important at this stage. Risks are typically recorded in a project risk register (see below).
2. Assess
Once you identify a risk, you must assess how it will impact your project. This is typically done using two criteria: probability and impact. Risk probability states how likely a risk is to be realized, whilst risk impact states how severely the risk will affect your project if realized. It is common to assess these criteria using a qualitative scale (high/medium/low etc), though some governance standards require quantitative assessment. Multiplying the two criteria together (either numerically or using a matrix) yields a result which is called the risk exposure or level of risk.
3. Respond
Every project risk requires a response that is appropriate, achievable, and affordable. The risk level will very much determine the response. For example, you may choose to simply accept a low-level risk while a high-level risk demands a more aggressive response. Possible risk responses include:
Avoiding the risk by not pursuing the activity that gives rise to the risk
Accepting the risk and the consequences if it is realized
Mitigating the risk by changing the probability and/or impact of the risk
Transferring the risk to another party
Having defined the response, an action plan is typically required to execute the response.
4. Monitor
Project risk management is not a single activity but an ongoing process that should be part of your project governance process. For example, a weekly project management meeting might allocate time to risk management. You must closely monitor your project risk register, adding new risks as they arise, changing the assessments as new information comes to light, and also tracking the progress of response plans. Most project governance regimes also require regular risk reporting.
The Risk Management Plan
Most project governance standards require you to define a risk management plan for your project. The purpose of the risk management plan is to describe how you will manage risk on the project. The typical components of a risk management plan are described below.
Introduction
This section describes the purpose of the plan and gives an overview of the contents. It should also include document identification, history, and approval information.
Project objectives
This section describes the project objectives, including functional scope, duration, cost, and quality.
Risk scope
This section describes what is in scope for the risk process. You might exclude one of the project objectives (such as functional scope) from the risk process for some reason. You might also wish to focus on particular types of risks (such as technical risks) and exclude others (such as commercial risks).
Risk process
This section describes the risk management process you are following. Although your organization probably has a standard process, there will be aspects that you need to tailor for each project. A sample risk management process was described above. You should also specify which tools and other resources you are using.
Roles and responsibilities
This section describes who is responsible for various parts of the risk process. Typical responsibilities include:
Preparing the risk management plan
Approving the risk management plan
Organizing and chairing risk workshops
Attending risk workshops and other meetings
Development of risk response plans
Creation and maintenance of the risk register
Reporting risk status
Ensuring risk process is being adhered to
Definition of probability and impact
Your organization likely has standard definitions for risk probability and impact, but you may need to customize them for your project. For example, if you define cost impact as low, medium, or high, you might attach specific dollar amounts to each level, proportionate to your project budget.
Risk categorization framework
This section describes any categorization you wish to apply to your risks. Some organizations define a risk breakdown structure that categorizes risks as:
Technical
Management
Organizational
Commercial
External
You can also categorize risks according to a work breakdown structure, a cost breakdown structure, an organization breakdown structure, and so on.
The Risk Register
A risk register is at the heart of the risk management process—but what is it, exactly?
A risk register is a record of the risks you have identified for your project, organization, or product. It is a tool used as part of the risk management process to help you identify, analyze, and manage your risks. Maintenance of a risk register is a common regulatory requirement and is usually necessary for compliance with project and organizational governance standards.
The exact configuration of a risk register varies by organization, but most contain these common elements:
Identifier: a unique code to refer to the risk
Description: an explanation of the risk, including the trigger and consequences
Probability: a qualitative or quantitative estimate of the risk likelihood
Impact: a qualitative or quantitative estimate of the consequences if the risk is triggered
Risk level (aka risk rating or risk score): this is calculated by multiplying the probability by the impact. For qualitative rankings, this is done using a 2-dimensional risk matrix.
Author: the person who raised the risk
Owner: the person responsible for managing the risk
Treatment: a strategy for dealing with the risk
Residual risk: the level of risk that remains after the treatment is applied
Sample risk register templates are readily available on the web.
The Risk Matrix
A risk matrix is a diagram that models risk outcomes using color gradients in a tabular structure. It usually has two dimensions, one representing risk probability and the other representing impact, with the intersection of the axis showing the level of risk. Once defined, the risk matrix can be used during risk assessment to quickly ascertain the level of each risk. It is a very common risk analysis tool and is part of any formal risk management process.
The risk matrix is also typically used during the monitoring phase, with either the risk count or the risk ids mapped directly onto the model, giving a simple representation of the total risk exposure for the project. Following is an example of a risk matrix:
If you think this looks like a lot of work, you are not alone. However, we can help…
Introducing Risk Register by ProjectBalm.
Risk Register automates best practice risk management techniques, and does so via an elegant, usable interface that works with you, and not against you. Risk Register will help you to identify, analyse, treat and monitor risks more easily and effectively than ever before.
If you are experienced at risk management, you will find in Risk Register a tool that works the way you want it to work. If you are new to risk management, our world class documentation will take you through the whole risk management process, using simple and fun examples.
Risk Register is fully compatible with risk management standards such as ISO 31000, and can also be used for governance, risk, and compliance (GRC) programs such as Sarbanes-Oxley and PCI.
A Great Solution at a Great Price
Many organizations are now implementing tools to automate the risk management process. Given the importance of risk management with regards to both projects and organizations, it is no surprise that most vendors charge steep rates for their risk solutions.
Risk Register by ProjectBalm is different. By leveraging the infrastructure of the Jira platform, we are able to deliver a fully-featured product at a fraction of the price of our major competitors.
Unlike our competitors, we are transparent about our pricing. And we don’t insist on an interview or consultation before we will let you see our software.