Here, I am going to re-cap on some pre-existing risk management theory in order to set the scene for the next section which heads back to looking at risk on software projects.
Most developers are familiar with recording issues in an issue tracker. For all of the same reasons, it's good practice to record the risks you face running a project or an operation in a Risk Register. Typically, this will include for each risk:
- The name of the risk, or other identifier.
- A categories to which the risk belongs (this is the focus of the Risk Landscape section in Part 2).
- A brief description or name of the risk to make the risk easy to discuss.
- Some estimate for the Impact, Probability or Risk Score of the risk.
- Proposed actions and a log of the progress made to manage the risk.
Four quick points about this description:
1. A Continuum of Formality
In the planning-a-dinner-party example the Risk Register happened entirely in your head. There is a continuum all the way from "in your head" through "using a spreadsheet" to dedicated Risk Management software.
It's also going to be useful in conversation and this is where the value of the Risk-First approach is: providing a vocabulary to talk about risks with your team.
2. Probability And Impact
Probability is how likely something is to happen, whilst Impact is the cost (usually financial) when it does happen.
In a financial context (or a gambling one), we can consider the overall Risk Score as being the sum of the Impact of each outcome multiplied by its Probability. For example, if you buy a 1-Euro ticket in a raffle, there are two outcomes: win or lose. The impact of winning would be (say) a hundred Euros, but the probability might be 1 in 200. The impact of losing would be the loss of 1 Euro, with
|+ 99 EUR
|1 in 200
|- 1 EUR
|199 in 200
Risk Management in the finance industry starts here and gets more complex. But often (especially on a software project), it's better to skip all this and just estimate a Risk Score. This is because if you think about "impact", it implies a definite, discrete event occurring (or not occurring) and asks you then to consider the probability of that.
3. Risk And Uncertainty
Arguably, Risk-First uses the term 'Risk' wrongly: most literature suggests risk can be measured whereas uncertainty represents things that cannot.
(Later, we'll dig into Health, which puts this on a better foundation.)
4. A Bug Tracker Is Also A Risk Register
As covered in Just Risk, we know that all work is managing risk. So therefore it stands to reason that if you are using a bug tracker then actually you are tracking risks. After all, bugs are capturing the risk that:
- your customers stop using your product
- someone is harmed by your product
- you suffer loss-of-reputation from some issue with your product
... and so on. Prioritising the bugs in the tracker is a prioritisation by risk.
A risk matrix presents a graphical view on where risks exist. The diagram above is an example, showing the risks from the dinner party in the A Simple Scenario section.
This type of graphic is helpful in deciding what to do next, although alternatively, you can graph the overall Risk Score against the Payoff. Easily mitigated risk (on the right) and worse risks (at the top) can therefore be dealt with first (hopefully).
In the preceding discussions, I have been careful to point out the existence of Hidden Risks for that very reason. Or, to put another way:
"What we don't know is what usually gets us killed" - Petyr Baelish, Game of Thrones
Donald Rumsfeld's famous Known Knowns is also a helpful conceptualisation:
- A known unknown is an Attendant Risk. i.e. something you are aware of, but where the precise degree of threat can't be established.
- An unknown unknown is a Hidden Risk. i.e a risk you haven't even thought to exist yet.
Out of the Window
Carefully tracking risks with a matrix or in a risk register is great when the going is good.
But all this goes south when you hit Crisis Mode, right?