This post aims to explain what is a risk and describes the risk management process, so that at the end of this article you will have everything you need to successfully find, manage, and report on risks throughout the duration of your project or program.
What is a Risk?
There is no one single definition of a risk. How risk is defined depends on the context under consideration. For example, financial risk is often described as the volatility of returns, both above and below the expected rate of return. In the context of projects and programs, we can define risk as being the likelihood of a specific event occurring which has a negative impact on our project or program.
Often when we speak of risk, we really mean the risk severity, which is defined as the product of the probability that the risk will occur and the impact the risk will have on our program should it materialise:
Risk Severity = (probability of risk occurring) x (impact of risk)
I typically score both Risk Probability and Risk Impact using a scale of 1 to 5. A probability score of 1 for a given risk means the risk has a low probability of occurring, whereas a probability score of 5 means the risk has a very high probability of occurring. I use a similar 1 to 5 scoring for Risk Impact, with one being low impact on the program if the risk materialises, and 5 being a very high impact should the risk materialise.
How we manage a risk will depend very much on the combination of Risk Impact and Risk Probability. For example, although a risk may have a very high probability of occurring, we may not devote too much time to managing it if the impact on our program is negligible. If the impact of a risk occurring was very large, such that it resulted in the termination of our program mid execution, we would obviously be prepared to devote a lot of time to managing it even if the probability of it materialising was low.
If we always measure Risk Impact and Risk Probability using our scale of 1 to 5 then we have a standard range of 1 to 25 for our Risk Severity. Having a standard range for Risk Severity is important as it allows using to compare risks against each other and allows us to understand the total level of risk facing the program at any given time.
Benefits of Risk Management
There are a number of benefits to having a solid risk management process, including:
- Clear ownership and accountability for all risks
- Creation of an environment where risks and be accepted by the business on an informed basis
- An increased likelihood that the program will be a success, along with the increased likelihood that the objectives of the organisation will be met
The Risk Management Process
The risk management process I use looks like this:
One we have determined our Risk Strategy, which simply means we have decided how we are going to manage risk throughout the duration of the program, we enter a 6-step loop as follows:
- Identify Risk: here we must identify what is the risk, and what is at risk. It could be timescales, the realisation of a benefit, or the delivery of a capability.
- Allocate Ownership: As the program manager, it is ultimately your responsibility to manage the risks within the program, however, each risk should be given an owner who is best positioned to perform mitigating actions on the risk and monitor the risk.
- Evaluate Risk: this simply refers to evaluating and assigning the risk with an impact and probability score.
- Plan Mitigations:In a general sense, every risk has a standard set of mitigations which can be applied to it. These are commonly referred to as ‘The 4 Ts’:
- Transfer: can the risk be transferred to another party, for example, could an insurance policy be taken out.
- Tolerate: this is frequently used for risks with very low impact, and is effectively the do nothing option. Tolerate effectively means the risk is monitored but the program proceeds without proactive action being taken to address the risk.
- Terminate: this refers to adjusting the program so the risk is no longer applicable to the program, for example, a project may be removed entirely from the program so the risk can never now materialise.
- Treat: this is where concrete actions are taken to reduce the probability of the risk materialising or impact of the risk should it materialise.
- Implement Actions: here concrete actions are given to the risk owner to ensure they are carried out
- Monitor and Control: all risks and actions which have been created need to be reviewed regularly, so the risk impact and probability can be updated following any actions which have been performed to treat them.
This 6-step loop should be a continuous process throughout the program. Most program management textbooks will tell you that the frequency of the risk management process should vary with the complexity of the program, with more complex programs requiring a greater frequency, however, I would argue that most programs should carry out this process as frequently as practical, as risk management is one of the most important things to get right on any program.
Embedding Risk Management
It is obviously important that the risk management process described above be repeated continually throughout the duration of the program, but it is equally important that the risk management process be fully embedded into all the projects running within the program.
How frequently the risk management cycle is repeated will depend on the process being followed by each sub-project, and the Risk Strategy for each project within the program should be agreed when initiating each project.
As an example, let us consider an R&D team within the program using an Agile software development life cycle (SDLC). Within the R&D team there may be a number of sprints. The simple way to embed the 6-step risk process described above into this agile life cycle is simply to complete the risk management loop once for each sprint:
No matter which team a person is part of, or which project they are working within, every single person working within the program should have the opportunity at any time to raise risks to the program. The way I like to do this is by creating a form on a Wiki that allows risks to be submitted to the program. Then whenever I perform an Info Sharing session or write my weekly program team communications I actively encourage the team members to submit risks. If you do this well then you will have a lot of emails to sift through, but this is preferable to missing an important risk. The other benefit of this approach is that it flattens the organisation, allowing everyone to communicate directly with the program.
Highlighting Risks to Stakeholders
Now that we understand risks and the risk management process, we are ready to use a Risk Map to highlight key risks to stakeholders:
To learn how to create a Risk Map, read the article on Risk Mapping. We are also ready to track the total risk being faced by the program over time using a Risk Burn Down Graph:
To learn how to create a Risk Burn Down Graph, read the article on Charting Total Program Risk.
Key Success Factors in Risk Management
In my opinion, the three key factors needed to successfully manage risk are:
- Fully embed the risk management process into the program allow everyone the opportunity to engage with the risk management process
- Each risk should have an owner, with clearly defined actions against the risk.
- Clear communication with steering group, so that risks can be accepted by the business on an informed basis.
That’s it! It was a long article but I hope you enjoyed it. You should now have everything you need to successfully manage risk within your program or project. However, if you do want more, a good place to start is The Essentials of Risk Management, by Michel Crouhy et al.
