Is it possible to “right-size” risk?
One aspect of service management that often seems to me to be misunderstood in IT, and misapplied, is risk. By this I mean that taking calculated risks can often yield a better outcome, not a worse one. It can also yield service management that’s closer to customer wishes than playing it safe would deliver.
If that seems to you to be an unusual slant in your world of IT service management, you’re right—it is. I suspect it stems from my having taken an unusual path into IT service management, and brought a number of different perspectives because of that
Instead of beginning in IT and moving to service management, I began in service management, and only got involved in IT services some 25 years ago.
I think that sequence was a lucky accident—something that has really helped me understand business priorities (like risk management) and the related complexities more easily. Instead of seeing risk in terms of specific technologies, I see it in a way that could almost be characterized as common sense.
All of this came to mind recently because I’ve been delivering a few ITIL Foundation training courses. In every such course, I find that I need to step back a little from the process-after-process flow these courses require, and dispel what I see as a common major misconception.
The misconception I’m talking about is this: that risk management in a business context is only about reducing risk. In fact, risk management should be about adopting the right level of risk on purpose.
It’s not a question of always struggling to eliminate risk, or even to mitigate it, but rather, of how risk can be best used to create the highest value (just like storage, processing power, or other IT resources, in fact).
We all understand the benefits of risk in the real world—why not apply the same reasoning to IT?
This idea is actually very common in non-business contexts; I think we’ve all utilised it in one fashion or another. It’s only when you try to express it to the business world that something usually gets lost in translation.
So, to get my point across more clearly, let’s begin with a non-business illustration. Say you’re in a taxi; generally you will be expecting the driver to drive carefully, avoiding risky manoeuvres, even if careful driving increases the time you spend in the taxi or the length of your trip.
Now let’s change the scenario slightly. Imagine you are some 10 km from the airport in Mexico City at the height of the Friday afternoon rush hour, and you really need to make your flight.
You know that, despite the traffic, making your flight might indeed be possible—if the driver would, to suit your interest, drive in a more rapid, aggressive, and generally risky way.
So you suggest to the driver how nice it would be if you got to the airport on time, and how pleased you would be as a result. You then leave him to imagine just how big the consequential tip might be.
At this point, you—as the customer—have made a deliberate decision to increase the risks, because you see it as a chance worth taking. You would, therefore, be displeased if previous levels of safety applied.
(Bear in mind, we aren’t talking about life-threatening safety here—not at the speed of Mexico City rush hour traffic. We are talking about increasing the odds of successful service delivery—defined here as catching the flight—even though that also means increasing the odds of a traffic accident.)
See what I mean about common sense applications of risk management? This is the kind of risk we’re all used to and take on a daily basis. If the risk doesn’t pay off for whatever reason—perhaps the taxi incurs a coming together with another car, or a hoped-for shortcut turns out to be a long way round—then you still miss the plane. But at least you know you tried. In fact, that every day phrase is probably key to what I am trying to get across, because we all understand the relevance of and value in the phrase “at least I tried.”
Service providers should assess risk from the customer’s outlook too—not just their own
Now, if we think about how all of this applies to the modern business environment, we discover two simple truths:
- Modern business success is built on sensible risk-taking. The risk may be mitigated by market research, analysis, etc., but there is still always a degree of gambling in any new product or innovative approach, exactly because it’s new and therefore has no proven history of working.
- The role of a service provider (internal or external) is to support the business choices of the customer—including choices that involve unexpected risk. Service providers may help set and modify those choices through advice, but the decisions are ultimately made by the customer.
Ergo, the service provider’s attitude to risk is dependent on the customer’s business strategies and risk profile... not just on the service provider’s.
Now, I’m aware this idea can get complicated given that service providers are typically using a common infrastructure to support multiple customers with different risk profiles. But the basic principle is, even so, simple and important—and common sense.
Unfortunately, I still see a lot of IT policies that defy common sense, and insist their main target should be simple risk reduction. That’s a shame; it ignores the fact that higher risk can sometimes deliver higher value for both the service provider and the customer. The cabbie who refuses to speed up doesn’t get the higher tip... and his customer doesn’t make that all-important flight.
What I see in many IT organisations is just this sort of diminished outcome for both service providers and customers. It’s nearly always a consequence of the way the service provider assesses risks only from their own perspective, not the customer’s as well. Both should be considered, weighed, and prioritised if an optimal strategy is really going to be created and implemented.
So now instead of a simple maxim—“always minimise risk”—we’re asked to consider a hierarchy of risks drawn from two different perspectives. And yes, that sounds complicated, but as I hope you can see, it is something we do actually manage every day in our ordinary lives.
Maybe the trick is not to overthink it?
Since I first started work in 1976, I have seen many, many arcane and sophisticated business tools, methods, practices, and approaches. But it has always seemed to me that the best ones begin with our everyday models and then modify and apply those models in a business context, however is required to allow us to cope with the speed and sheer volume of demands that modern business throws at us.
Risk management (as my experience with that friendly but avaricious Mexican cabbie suggests) is really just one more example of this general situation. And my outcome shows you how risk can and should be increased when the circumstances are right for it. Despite a number of en-route concerns involving other vehicles, fixed obstacles, law enforcement, and the laws of physics, I did make my flight, and he did get his tip.
Common sense also tells us that this kind of thinking is going to apply to the large majority of organisations. Some, perhaps, have found that in risk-taking they are always successful—but if you were that lucky, you would have won millions on the lottery and be relaxing with a cold glass of champagne on your yacht, not reading this. And other organisations really do have to minimise risks and maximise safety at all costs, like those in the air travel and nuclear power fields.
But if your customers are in an area where taking risks sometimes pays off in spades, it might be that in always trying only to reduce risk, you are simply not giving them the adequate level of support they need to pursue optimal market success.
This common sense outlook is, I think, gaining momentum even in the risk-averse world of IT. For instance, the latest version of ITIL defines “risk” in its glossary in a way that reflects the possibility of good outcomes as well as bad ones.
And I think, going forward, we need to see that possibility of good and bad outcomes in IT as part of a complex, holistic perspective (again, just as we do in our everyday lives).
For instance, I suggest that you don’t get too excited if following the launch of a new project, all your IT services went live with no apparent performance issues and no missing functionality.
Ask yourself a few questions. Does that mean our approach was too conservative? Was our implementation more expensive than it really needed to be? Did we really understand the risk profile our customer requires?
As a service provider, you will ultimately be judged on customer satisfaction—and that includes supporting their risk profile and risk-related decisions. So even if a project seems to have gone without a hitch, customers might still be dissatisfied because when the risks went down, so did their potential for a huge business success.
One last thought for now: when taking risks does go wrong, and we find ourselves in a crisis, we need to turn to a different approach to management—crisis management, which is very different from ordinary management practice. This is an area where some of my IBM colleagues are developing interesting approaches, and it’s something I’ll be writing about in the future.
After 23 years working for the UK government, moving from forestry to IT Service Management via prisons, stores and training, Ivor now works for IBM’s Tivoli organization helping customers understand and improve their Service Management. Ivor was an ITIL author (versions 1, 2 and 3), part of the panel that wrote BS15000 (fast-tracked to ISO/IEC 20000), an ITIL trainer and examiner since 1991 and active in itSMF since 1995, having spoken for them in 34 countries.
Additional Information:IBM Service Management
Innovate2012 - The premier event for software and systems innovation
Innovate 2012 is the software innovation conference focused on helping you transform software innovation and accelerate better business outcomes. Sign up for the Collaborative Development and Operations track to learn how to design, deliver and manage innovative services more quickly and effectively. Don't miss Innovate 2012, June 3-7, 2012.