Risk-First Diagrams Explained

Throughout A Simple Scenario we used diagrams to explain the risks we faced and the choices we were making. These are called “Risk-First Diagrams”. Here, we’re going to look at what is going on in these diagrams so that when we come to apply them to software development, they’re not totally confusing.

Goal In Mind and Attendant Risks

The diagram above is taken from the dinner party example: we want to host a successful party, but in doing so, we know there are Attendant Risks.

Nothing To Eat

Here’s another. In the diagram above we are dealing with the risk of not having enough food at the party by considering buying lots of snacks.

What’s going on in these diagrams? How should we interpret them? Let’s work left-to-right.

On The Left

A Goal To Reach, A Risk To Avoid

On the left in the first example we can see our goal, of having a successful party. This is the goal we want to reach, it’s within our grasp to achieve this, if we only take the right actions.

Equally, we could have a risk that we wish to avoid, such as having nothing to eat at the party. To achieve that, we also need to take the right actions.

In biological terms the items on the left of the diagram are the stimulus part of the Stimulus-Response Model. They’re the thing that makes us Take Action in the world.

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. Equally, we should also try and achieve our most critical goals and let the lesser ones slide (at least, from a rational standpoint).

In The Middle

Taking Action

In the middle of a Risk-First diagram we see the actions you could take. In the diagram above, echoing the examples, they are “Hosting a Party” and “Buying Snacks”. One is moving us towards the goal of “A Successful Party”, the other, moving us away from the risk of “Not Enough Food”.

On The Right

Nothing comes for free. On the right, you can see the consequences of the actions you’ve taken: Attendant Risks are the new risks you now have as a result of taking the action.

Hosting a dinner party opens you up to attendant risks like “Not Enough to Eat”. As a result of that risk, we consider buying lots of snacks. As a result of that risk, we start to consider whether our guests will be impressed with that.

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. Are the things on the left worse or better than the things on the right?

Functions

As well as considering Risk First diagrams to be like the Stimulus-Response Model, you could also think in terms of functional programming, which might be more familiar to us as software developers.

We are tranforming an input condition (on the left) into an output condition (on the right) by way of a function (the action we take, in the middle).

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, spreadsheets, reports and programs.

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

The diagram above shows two other marks we use quite commonly: we put a “strike” through a risk to show that it’s been dealt with in some way and the “cloud” icon denotes Hidden Risks- those unknown unknowns that we couldn’t have predicted in advance.

Next

Risk-First is about understanding risk in software development, so next let’s examine the scenario of a new software project. Instead of a single person organising a dinner party, we are likely to have a team, and our Internal Model will not just exist in our heads, but in the code we write.

On to Development Process

Add Your Star On GitHub to receive an invite to the GitHub Risk-First GitHub team for new article notifications and discussion.

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