Risk Management
Risks need to be managed throughout the life of any project or delivery. Here I’m summarising the key steps in risk management and I’ll provide some links to useful tools and approaches towards the end of the page.
Risks are an inevitable part of our work. Avoiding risks only compounds the problem. Assume that there are risks, root them out, be transparent about them and deal with them head on.
As soon as you set any plan in motion, you introduce risks. Risks such as not completing work by a particular deadline, risks that you lose key staff, risks that the end product will not be good enough or not fit for purpose, risks that you don’t know about yet.
In order to manage your risks properly you need to identify them, assign them an owner, assess the risks and the possible mitigation, decide whether to avoid, share, deal with or transfer the risk, and understand the value behind the risk and the likelihood that it will occur.
The discovery phase is a great place to begin looking for risks. Minds are generally quite fresh at this stage and there will be some obvious risks as well as those that you’ll uncover when digging into the problems that the discovery phase covers.
Recording the risks in a simple register takes very little effort but it’s a tool that will be used to review and manage the risks while they’re still active.
When recording risks be sure to capture the following information:
- Description. A reasonable summary of the risk faced and the impact it will have should it occur.
- Value. We need to know the value hidden behind the risk so we can assess whether it’s worth investing effort to manage this.
- Mitigation. If there is one or more ways to manage this risk then record them here. Whether you can manage the risk, avoid it, transfer it or avoid it altogether, put your ideas down here.
- Owner. The sooner a risk is owned by someone in the team, the sooner it’ll get the love it needs.
- Probability. Whether you use numbers or a high-low scale, provide an indication of how likely this risk is to occur.
- Impact. What will be the impact to the delivery if the risk occurs? Use the same scale as probability so you have the option to map the two together.
- Status. We need to know if a risk is active or closed.
Now that you’ve got a record of the risks you’re aware of it’s time to assess them. All risks are different and we need to understand the facts and prioritise our efforts based on what we know, or roughly know. The facts to consider for each risk are:
- Value. Sometimes it’s difficult to put an actual number on the value of something but use a scale or some kind of sizing indicators here if necessary. If the effort involved in managing a risk is far greater than the value gained then you need to consider whether the investment is justified.
- Probability. What are the chances of this occurring?
- Impact. If this risk occurs, what will be the impact on the delivery?
Another factor to take into account is your risk appetite. What level of risk are you comfortable with? Some of us are bigger gamblers than others. Taking a chance on a big risk can pay massive dividends but it can also spell disaster.
Now that you’ve identified your risks, you’ve decided which to manage and who is responsible for them, you need to have the processes in place to manage these.
Our organisation is set up for constant improvement and there are certain cycles into which we can work the management of our risks.
When delivering a discovery or when we’re iterating through a delivery, there are natural points in the cycle when risks can and should be reviewed.
A sprint starts with planning. During the sprint planning session talk about any risks you find with the team and the customer. It’s important that we’re open and that we pool our knowledge. In doing this we give ourselves the best chance of successfully managing a risk. Capture the details of the risk and any mitigation in the register and cross check with the user story or epic if possible.
Daily standups provide another natural point in our work cycle to highlight risks. A risk here could be that a story requires more effort than originally estimated, that you’re not receiving the input required from the customer to finish a story, that the module you initially identified doesn’t seem to meet the requirements or that you’re having technical problems. All of these are examples of things that will impact the delivery and therefore pose a risk. Highlighting these early gives us the best chance to manage them successfully or reduce their impact.
Sprint reviews allow us to put risks into the context of a larger programme of work. If a sprint has under-delivered for whatever reason we need to talk through the impact this has. What is the initial impact? Are there dates we need to consider? Do we need to reprioritise work in the next sprint? Do we need to add more people or different skills into the team? What is the longer term effect? Can we make up the loss over the course of the next couple of sprints? What originally might seem like an uncomfortable conversation with a customer will actually help to develop a transparent relationship.
Taking each of these opportunities in any two week sprint means that risks have the opportunity to be raised every day while being reviewed 1-2 times each sprint. However, a Scrummaster should be making the point to review risks more regular, at least once a week with the Product Owner. If you want the delivery to be a success then keep on top of the things that can quickly derail the delivery.
It’s often difficult to measure a risk or the value behind the risk but it’s worth using different methods to reasonably size risks. It could be that you use a scale or you could size risks against each other in the same way you would with user stories.
What’s vital in the management of risks is identifying them, talking openly about them, having someone “own” the risk and reviewing them regularly.
If you’re prepared for a risk to occur then you’ve already reduced its impact which hopefully has saved the delivery.
For more on risk management see
Last modified 4yr ago