Skip to main content

Just Risk

In this section, I am going to propose the idea that everything productive you do on a software project is Risk Management.

All Work is Managing Risk

Think about your development process at work. Maybe it involves weekly releases, a continuous-integration system, unit-testing and beta-testing. All these activities have a part to play in managing different risks. They work to manage risks before they create bigger problems in production.

Can we go further? Is it just those parts of our development process that manage risk, or is it actually all of them?

Lets look at one of the tools in the Project Manager's tool-box, the RAID Log, and observe how risk-centric it is. Then, we'll generalise from there.


Many project managers will be familiar with the RAID Log. It's simply four columns on a spreadsheet: Risks, Actions, Issues and Decisions.

Let's try and put the following item into the RAID Log:

"Debbie needs to visit the client to get them to choose the logo to use on the product, otherwise we can't size the screen areas exactly."

  • So, is this an action? Certainly. There's definitely something for Debbie to do here.
  • Is it an issue? Yes, because it's holding up the screen-areas sizing thing.
  • Is it a decision? Well, clearly, it's a decision for someone.
  • Is it a risk? Probably. Debbie might go to the client and they still don't make a decision. What then?

This example is deliberately chosen to be hard to categorise. Normally, items are more one thing than another. But often, you'll have to make a choice between two categories, if not all four.

This hints at the fact that at some level it's all about risk:

Every Action Attempts to Manage Risk

The reason you are taking an action is to manage a risk. For example:

  • If you're coding up new features in the software, this is managing Feature Risk (which we'll explore in more detail later).
  • If you're getting a business sign-off for something, this is managing the risk of everyone not agreeing on a course of action (a Coordination Risk).
  • If you're writing a test, then that's managing a type of Implementation Risk.

Every Action Has Attendant Risk

  • How do you know if the action will get completed?
  • Will it overrun, or be on time?
  • Will it lead to yet more actions?
  • What Hidden Risk will it uncover?

Consider coding a feature. The whole process of coding is an exercise in learning what we didn't know about the world, uncovering problems and improving our Internal Model. That is, flushing out the Attendant Risk of the Goal In Mind.

And, as we saw in the Introduction, even something mundane like the Dinner Party had risks.

An Issue is Just A Type of Risk

  • Because issues need to be fixed...
  • And fixing an issue is an action...
  • Which, as we just saw also carries risk.

One retort to this might be to say: "an issue is a problem I have now, whereas a risk is a problem that might occur. " I am going to try and break that mind-set in the coming pages, but I'll just start with this:

  • Do you know exactly how much damage this will do?
  • Can you be sure that the issue might not somehow go away?

Issues then, just seem more "definite" and "now" than risks, right? This classification is arbitrary: they're all just part of the same spectrum, they all have inherent uncertainty, so there should be no need to agonise over which column to put them in.

Goals Are Risks Too

In the previous sections, we introduced something of a "diagram language" of risk. Let's review it:

Risk-First Diagram Language

Goals live inside our Internal Model, just like Risks. It turns out, that functionally, Goals and Risks are equivalent. For example, The Goal of "Implementing Feature X" is equivalent to mitigating "Risk of Feature X not being present".

Let's try and back up that assertion with a few more examples:

GoalRestated As A Risk
Build a WallMitigate the risk of something getting in / out
Land a man on the moonMitigate the risk of looking technically inferior during the cold war
Move HouseMitigate the risks/problems of where you currently live

There is a certain "interplay" between the concepts of risks, actions and goals. After all, on the Risk Landscape they correspond to a starting point, a movement, and a destination. From a redundancy perspective, any one of these can be determined by knowing the other two.

Psychologically, humans are very goal-driven: they like to know where they're going, and are good at organising around a goal. However, by focusing on goals ("solutionizing") it's easy to ignore alternatives.

By focusing on "Risk-First", we don't ignore the reasons we're doing something.

Next, let's look at how we should Consider Payoff when we choose what to do next.