Skip to main content

Derisking

In this section, we're going to more closely at Taking Action and separate out the ways in which this can be done. Along the way, I'll introduce the correct risk management terms and we'll see how each of these apply to software development.

So far in Risk-First, we've talked about Taking Action as having two effects:

  1. It's the way in which we Meet Reality to learn about the world and uncover Hidden Risks.
  2. It's the way we change our position on the Risk Landscape via actions with a positive Payoff.

So the concept of Taking Action is doing a lot of heavy lifting. This second effect is also called De-Risking:

"To remove the risk from; to make safe. " - Derisk, Wiktionary

Let's look at some common strategies for derisking.

Mitigate (or Reduce)​

Mitigating risk is taking steps towards minimising the impact (as we discussed in the Evaluating Risk section) of a risk arising.

"To reduce, lessen, or decrease and thereby to make less severe or easier to bear." - Mitigate, Wiktionary

Some simple examples of this might be:

  • Safety-nets and ropes mitigates some of the risks of climbing. The fall damage you'll take when you lose your grip is hopefully much reduced but the activity of climbing itself is otherwise much unchanged.

  • Backups and Source-Control mitigates the impact of computer failure. Hardware still fails but the impact is less if we can restore from a recent backup. 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.

Avoid​

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. Of course, you may pick up other, more serious risks as a result: Relational Databases are software solutions to many kinds of Coordination Risk problem, such as concurrent writes or consistency.

Not launching an online service avoids the Operational Risk involved in running one. Although you avoid the upsides too.

Transfer (sometimes Share)​

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.

Transfer of risk is an essential feature of Software-as-a-Service (SaaS): someone else is responsible for making sure the service is up-and-running, backed up, etc.

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 fall-out if they left, often they are a risk worth accepting because of the value they bring.

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, so 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.

Learned Helplessness​

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

Contain​

Containing risks means setting aside sufficient time or money to deal with them if they occur.

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.

Exploit​

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.

A Vocabulary​

Here we've been building towards 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.