I’ve said previously that I used to struggle with risk management, which I mostly came across when running projects, but also when dealing with business situations more generally. These days I have a different, more practical approach. In this post I’ll discuss four truths about so-called “risks”, which are the basis of this shift in approach.
The ideas for this come significantly from Matthew Leitch. He also kindly posted on his site a link to a presentation I made recently on this subject.
First some context, which will be familiar if you read my piece on Why projects go wrong despite risk management.
Context
When I used to manage projects it was standard practice to have a “risk register”, which listed known risks and actions against them—the so-called “mitigation strategies”. Each risk also had a “risk owner” who made sure the action got done.
Although this was a nice idea these so-called “mitigation strategies” weren’t at all practical. They generally listed actions which were either not useful, or something the “owner” would do anyway. For example if the risk was “supplier does not produce goods of sufficient quality” the action might be “consider other options”. Really, if “other options” were possible then they would have been specified already.
In the worst cases the actions were outright denial. For example, for the risk of “System too complex for users” the action might be “We have selected the best training company”. Unfortunately selection of training company does not change the system’s complexity.
Three example risks
To help explain the shift in approach, here are three example risks I’ve come across recently. I’ll use them throughout this post to illustrate my points.
- The unhappy CEO. A team has just embarked on a six month project. The CEO has commented to them that he wants the result to be “punchy” but won’t elaborate, because to him it’s obvious what that means. The team don’t feel able to ask. They have a project risk (which they can’t write down, for fear of looking dysfunctional) that the CEO will look at their work after six months and condemn it.
- The single customer. A company has built its key product around a single customer. It is the only customer in the world for this product. It’s just a matter of time before their needs change and they no longer need the product.
- The competitor launch. A company has built its revenue projections on launching in Germany ahead of its competitor. But the competitor might get there first.
Once upon a time I would struggle with all these things. If we can’t ask the CEO the important question then we have to just hope for the best. Similarly we cannot control our single customer, much less our competitor. Again, we just have to cross our fingers. If I was the risk owner for these I wouldn’t know what to do… except cross my fingers on behalf of everyone else.
But there is another view. Here are four truths about risks…
Truth #1: Risks aren’t concrete objects
It’s not at all shocking to understand that “risks” are abstract entities, not concrete objects. But the consequence is important. A “risk” is abstract like an idea, and as such it cannot be owned by anyone. It doesn’t make sense to “own” a risk, which means having a risk owner on a risk register isn’t practical.
It does make sense to own a meeting action, which might be to look at options for dealing with a particular risk, but we must acknowledge that the solution might involve many people.
No-one can “own” the risk of our CEO’s unhappiness, our single customer’s needs, or our competitor’s launch. We need to accept that, and accept that we might all have a hand in the solution.
Truth #2: It’s not either/or
Too often we see a risk as a binary thing, that either happens or doesn’t happen: we’re at the end of our project and the CEO is unhappy, our single client has stopped buying, our competitor has launched first. But this is a false view. The truth is that these bad things can vary all over the place.
The CEO’s level of unhappiness may vary from furious to slightly displeased, and have a thousand points in between. And the level of that unhappiness matters, because the consequences are very different.
Our single client may stop buying from us. Or they may reduce their purchasing a bit. Or they may reduce it a lot. Again, there’s a big difference between any of these scenarios, and we don’t do ourselves any favours by lumping them all together.
Similarly our competitor may launch before us, but there’s a world of difference between them launching a month ahead of us and launching a year ahead of us. What if they launch a day of ahead of us? It’s different again.
In these situations we tend to focus on a “risk event”, but we would see things more realistically if we look past that and see our concern as much more fluid, as a variable which can slide back and forth.
Truth #3: It’s only half the story
If our variable can slide back and forth across a range of values, then it can also slide the other way: not just potential bad things, but potential good things, too. This is the opposite of risk: opportunity.
If we are to handle bad possibilities we would do well to handle good things happening, too, and be ready to exploit them.
Our CEO may be unhappy… or he may be happy. Our single customer may reduce their purchasing… or they may increase it. Our competitor may launch first… or we might.
Again, all these things are variable. Are we ready to exploit them? If we aren’t then we’re missing a trick, and our project (or business) is only prepared for meeting expectations or worse. We really ought to be prepared for exceeding expectations, too.
Truth #4: Risks have fuzzy edges
These so-called “risks” are described and defined entirely by us, and in my experience we define them much too tightly. The truth is that the problems we’ve highlighted have much fuzzier boundaries than we typically realise, and are often part of a bigger picture, or a network of other issues. I find it helps a lot to zoom out to see that bigger picture.
Take the unhappy (or happy) CEO. Isn’t the bigger problem something about stakeholder engagement? Isn’t that a more practical and useful problem to be grappling with and getting right?
What about that single customer’s needs? Isn’t the problem really that we are reliant on just one customer? If we actively seek out other customers with potentially related needs then perhaps that original risk will diminish. Yes, it may require investment and time, but I would say it’s a more practical approach than just crossing our fingers.
And what about our competitor launching in Germany before us? The fact is there is more to success in a territory than just the launch date. There is the feature set, the marketing, the initial customers and their testimonials, and much, much else besides. And anyway, if they do launch first, then what do you think will happen in the next territory, and the one after that? Perhaps the concern should not be with our competitor… perhaps the focus should really be on our own time to market. Perhaps we should concentrate on that, and continually work at it to improve it. Systematic improvement will ensure we get to the best position we can.
Conclusion: Not risks, but uncertainty
The real outcome of all this is to move away from the idea of “risks” as concrete objects which can be passed around like a pass the parcel game. They are not concrete. Nor are they either/or. They are more fluid than that. And they are not always bad. There is a much more applicable word which sums up all of this: uncertainty.
Dealing with uncertainty is arguably more difficult. To take one example above, it is much more difficult to continually scrutinise and improve our own time to market than it is to worry about our competitor launching once in a given territory. But I would argue that it is much better to tackle the difficult-but-right problem than the easy-but-wrong one.
Dealing with uncertainty is best handled by systemic means—i.e. by processes which are part of our day to day lives. If we relegate them to a separate process then that can all too easily be forgotten—and I’d suggest that indicates we don’t really understand them.
Handling uncertainty is a much bigger deal than putting risks onto a risk register. But it is much more practical, and therefore much more productive.
niksilver.com 