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.
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.
There are a number of benefits to having a solid risk management process, including:
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:
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.
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.
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.
In my opinion, the three key factors needed to successfully manage risk are:
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.
Program Management Primer
The Change Equation
What is the Long Tail?
Program Management: Understanding Effort and Influence
Customer Journey Programmes in Financial Services
Lean Startup and Program Management
Project Management Culture determines Project Success
Simple Scope Management