When suggesting how we might deal with risk in a project or an enterprise, one of the common options that’s suggested is that we “transfer” the risk. (Other options include to accept it, reduce it, or avoid it.) And a common example of what it means to transfer the risk is taking out insurance. Then the insurance company generally has to deal with paying for and making good on any bad event that might happen.
Even though there’s no universal agreement on what “risk” actually means, by most definitions this example of insurance is an odd one. If we are worried about our building being flooded then we can pay an insurance company a regular sum; in return for this, if there is a flood, then the costs of cleaning up the mess and replacing much of the damaged equipment is covered by the insurer. They may even pay for some loss of business.
However, simply taking out the insurance policy does not change the probability of a pipe bursting; it does not change the amount of water released; it does not alter the physical damage that occurs; it does not alter the fact that our and our colleagues’ time is diverted into dealing with the mess rather than getting on with our core business (although it does change the time and activity involved in dealing with the mess). In short, there is only a very narrow sense in which risk is transferred.
The idea of transferring is a very black and white idea, and regular readers will know I dislike that view, preferring to see things as shades of grey. The “shades of grey” form of transferring risk is to share it—i.e. it doesn’t go from entirely us to entirely a third party, but rather some of it shifts over. And if we are talking about someone else taking more risk then we also need to consider what a corresponding reward might be.
If we are building a product and want to transfer or share the risk then we should consider working with a partner, or even outsourcing the whole thing. This is very different to the insurance example, because it changes the system in which we work. A partner will have their own standards and approach; this in turn will influence how we work. Now we do change the probability of a bad outcome; we can change what success, or degrees of success, looks like like; we do change what it means to deal with the aftermath of a variously-successful product launch. In fact I know some people who work as these kinds of partners, and prefer to work on a “no cure, no pay” basis, and the flip-side of that is that they insist on owning key decisions and actions.
Transferring or sharing risk of a flood is more difficult. But as is so often the case, perhaps the answer lies in designing the risk out of the system. Maybe we shouldn’t even be in a fixed building; perhaps we should be adept at changing location, or even be working remotely. Perhaps we should shift our key technology and information infrastructure into the cloud, where it is looked after by people with more dedicated skills in site management and disaster recovery.
There is much accepted wisdom in traditional risk management which could benefit from some refreshed thinking. This is just one small example.
niksilver.com 