In this section, I am going to propose the idea that everything you do on a software project is Risk Management.
In the Development Process section, we observed that all the activities in a simple methodology had a part to play in exposing different risks. They worked to manage risk prior to them creating bigger problems in production.
Here, we’ll look at one of the tools in the Project Manager’s tool-box, the RAID Log, and observe how risk-centric it is.
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 Risk 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.”
This is a completely made-up example, 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:
The reason you are taking an action is to mitigate a risk. For example:
Consider coding a feature (as we did in the earlier Development Process section). We saw here how the whole process of coding was 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.
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:
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.
In the previous sections, we introduced something of a “diagram language” of risk. Let’s review it:
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:
|Goal||Restated As A Risk|
|Build a Wall||Mitigate the risk of something getting in / out|
|Land a man on the moon||Mitigate the risk of looking technically inferior during the cold war|
|Move House||Mitigate 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.
Sometimes, there will be multiple moves available on the Risk Landscape and you have to choose one.
Let’s take a hypothetical example: you’re on a project and you’re faced with the decision - release now or do more testing?
Obviously, in the ideal world, we want to get to the place on the Risk Landscape where we have a tested, bug-free system in production. But we’re not there yet, and we have funding pressure to get the software into the hands of some paying customers. The table below shows an example:
|Risk Managed||Action||Attendant Risk||Payoff|
|Funding Risk||Go Live||Reputational Risk, Operational Risk||MEDIUM|
|Implementation Risk||User Acceptance Test||Worse Funding Risk, Operational Risk||LOW|
This is (a simplification of) the dilemma of lots of software projects - test further, to reduce the risk of users discovering bugs (Implementation Risk) which would cause us reputational damage, or get the release done and reduce our Funding Risk by getting paying clients sooner.
In the above table, it appears to be better to do the “Go Live” action, as there is a greater Payoff. The problem is, actions are not commutative, i.e. the order you do them in counts.
The diagram above shows our decision as moves on the Risk Landscape. Whether you “Go Live” first, or “UAT” first makes a difference to where you will end up. Is there a further action you can take to get you from the “Dead End” to the “Goal”? Perhaps.
So, when we talk about a project “failing”, what do we mean?
Usually, we mean we’ve failed to achieve a goal, and since goals are risks, it is simply the scenario where we are overwhelmed by Attendant Risks: there is no action to take that has a good-enough Payoff to get us out of our hole.
It makes it much easier to tackle the RAID log if there’s only one list. But you still have to choose a strategy: do you tackle the most important risk on the list, or the most urgent, or take the action with the biggest Payoff and deal with it?
In the next section, Evaluating Risk we’ll look at some approaches to choosing what to do.
Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.