Risk-First Diagrams Explained

What’s going on in a Risk-First diagram? Let’s look at a quick example:

Complexity Risk and some mitigations

This is taken from the Technical Debt discussion in Complexity Risk.

What’s going on here? Let’s work left-to right.

On The Left

Codebase Risk

On the left, we can see Codebase Risk, which is The risk to a project of having a large, complex codebase to manage.

Codebase Risk is an example - it could be any risk you’ve identified in your project / work / life / whatever. It’s something you want to fix.

There are all kinds of risks we face in life, and we attach different value or criticality to them. Most people will want to take action against the worst risks they face in their lives, and maybe put up with some of the lesser ones.

In The Middle

Refactoring

In the middle, we see the actions you could take against the risk. So for the problem of an unwieldy codebase we could try and reduce the size of our codebase with some refactoring, or alternatively, replace the whole codebase with a commercial or open-source library.

On The Right

Refactoring

Nothing comes for free. On the right, you can see the downside of the action you’ve taken: Attendant Risks are the new risks you now have as a result of trying to deal with the first one.

In the first diagram, the refactoring and simplification actions lead to Schedule Risk (because they’ll take time to do), Feature-Fit Risk (because a simpler product might not meet the user’s needs so well).

Meanwhile using new libraries and languages leads to Dependency Risk (because these libraries are new points of failure) and Boundary Risk (in the form of lock-in).

A Balance

It’s worth pointing out that sometimes the cure is worse than the disease.

By Taking Action you might end up in a worse predicament than you started. For example, cutting your legs off would definitely cure your in-growing toenail. We have to use our judgement to decide on the right course of action!

So Risk-First diagrams represent a balance of risk: whether or not you choose to take the action will depend on your evaluation of this balance.

Containers For Internal Models

The risks on the left and right are contained in rounded-boxes. That’s because risks live in our Internal Models - they’re not real-world things you can reach out and touch. They’re contained in things like brains and spreadsheets.

Blame Game

In the above diagram, you can see how Jim is worried about his job security, probably because he’s made a mistake at work. Therefore, in his Internal Model he has Funding Risks, i.e. he’s worried about money.

What does he do? His Action is to blame Bob. If all goes according to plan, Jim has dealt with his risk and now Bob has the problems instead.

What Else?

Mitigated and Hidden

There are two other marks we use quite commonly.

We put the strike through the risk to show that it’s been dealt with, or mitigated, and the cloud icon denotes Hidden Risks- those unknown unknowns that we couldn’t have predicted in advance.

Add Your Star On GitHub to receive an invite to the GitHub Risk-First team.

Rob Moffat
Rob Moffat Author of Risk-First Software Development. Developer. Working in the UK.