It’s important not only to consider the Attendant Risks you’re trying to mitigate, but the ones you’re likely to pick up in the process. This means picking a careful path through the Risk Landscape. This is the essence of De-Risking.
“To take steps to make (something) less risky or less likely to involve a financial loss.” - De-Risk,OxfordDictionaries.com
Some simple examples of this might be:
- Safety-nets and ropes de-risk climbing. But, the activity of climbing itself is otherwise much unchanged.
- Backups and Source-Control de-risk the development process by reducing the impact of computer failure. Our process is changed slightly by this imposition, but we’re not massively inconvenienced.
- Insurance de-risks owning a house, going on holiday or driving a car. Usually, the payment is small enough not to impact us too much.
- The National Health Service (NHS) de-risks medical expense by pooling health-care costs across the entire population. If you were struck down with a debilitating illness, then at least you wouldn’t also have to pay to get better.
Let’s look at some common strategies for De-Risking.
Mitigating risk is taking steps towards minimising either its likelihood or impact (as we discussed in the Evaluating Risk section). Safety-nets, for example, mitigate the impact of hitting the ground. This is the main approach we will be looking at in Part 2. We’ll break down risk into its different types and look at the general mitigations for each.
Avoiding risk, means taking a route on the Risk Landscape around the risk. For example, if you are working in a team which has no experience of relational databases, then storing data in files might be a way to avoid the Learning Curve Risk associated with this technology.
Not launching an online service avoids the Operational Risk involved in running one. Although you avoid the upsides too.
Transferring risk means making it someone else’s problem. For example, when I buy home insurance, the personal consequence of my house burning down is reduced. It hasn’t gone away completely, but at least the financial element of it is handled by the insurance company.
In part 2, we’ll see how Transfer of risk is an essential feature of Software-as-a-Service (SaaS). Inside organisations, Transfer of risk can become a political game:
“… ownership results in ‘one throat to choke’ for audit functions [and] from ownership comes responsibility. A lot of the political footwork in an enterprise revolves around trying to not own technologies. Who wants to be responsible for Java usage across a technology function of dozens of thousands of staff, any of whom might be doing crazy stuff? You first, mate. “ - Why Are Enterprises So Slow?, zwischenzugs.com
Ignore / Accept
Accepting risk is to deal with it when it arises. One example is the Key Person Risk involved in having a super-star programmer on the team. Although there would be fallout if they left, they are often mitigating more risk than they cause.
Another example is using particular software dependencies: building a mobile application which requires a Facebook account to log in might give rise to the risk that people without Facebook accounts can’t log in, but might simplify the software to such an extent that it’s worthwhile.
Whereas Accepting a risk seems to imply an eyes-wide-open examination; Ignoring seems to imply that either the risk is so insignificant it doesn’t warrant evaluation, or so daunting that it can’t be stared down. Either way, Ignoring a risk amounts to the same thing as Accepting it, since you’re not doing anything about it.
Accepting a risk has to occur before we can Mitigate it.
A Nice Problem To Have
Ignoring or Accepting risks is a lot less work than Mitigating them, and sometimes it can feel negligent to just add them to the backlog or risk-register without doing anything immediately about them. One useful test I have found is whether “This would be a nice problem to have”. For example:
“Running out of space in the database would be a nice problem to have, because it would mean we have lots of users” “Users complaining about lacking function X would be a nice problem to have, because it would mean they were using the system”
Applying this kind of logic at the start of a project leads you towards building a Minimum Viable Product.
Sometimes risks just go away on their own. Learned Helplessness, on the other hand, is where we could do something about the risk, but fail to see that as an option:
“Learned helplessness is behaviour typical of animals, and in rare cases humans, that occurs when the subject endures repeatedly painful or otherwise aversive stimuli which it is unable to escape or avoid. After such experience, the organism often fails to learn or accept “escape” or “avoidance” in new situations where such behavior would likely be effective. “ - Learned Helplessness, Wikipedia
Whenever a project-manager builds slack into a project plan, this is Containment. “Time-Boxing” is also containment: this is where you give a piece of work a week (say) to prove itself. If it can’t be done in this time, we move on and try a different approach.
In the section on Schedule Risk we are going to look in detail at how this works.
Exploiting as a strategy usually means taking advantage of the upside of a risk. For example, ensuring enough stock is available to mitigate the risk of a rush on sales over the Christmas period, or ensuring your website has enough bandwidth to capture all the traffic headed towards it after it’s featured on television.
Going back to the example of home insurance, the Insurance company is exploiting the risk of my house burning down by selling me insurance. This is a common pattern: wherever there is risk, there is likely to be a way to profit from it.
Later, in the section on Process Risk we’ll be looking at how exploiting risk can happen organically within a company.
Let’s look at the journey so far.
In A Simple Scenario we looked at how risk pervades every goal we have in life, big or small. We saw that risk stems from the fact that our Internal Model of the world couldn’t capture everything about reality, and so some things were down to chance.
In the Development Process we looked at how common software engineering conventions like Unit Testing, User Acceptance Testing and Integration could help us manage the risk of taking an idea to production, by gradually introducing it to reality in stages.
In Just Risk we took a leap of faith: could everything we do just be risk management? And we looked at the RAID log and thought that maybe it could be.
Evaluating Risk was an aside, looking at some terminology and the useful concept of a Risk Register.
What this has been building towards is supplying us with a vocabulary with which to communicate to our team-mates about which Risks are important to us, which actions we believe are the right ones, and which tools we should use.
In the next section we will see an example of this in action.