I had the opportunity to moderate a roundtable discussion on risk management at the International Institute for Analytics’ (IIA) winter symposium in Orlando earlier this month.  I set the stage for the session with a brief overview of my favorite risk approach, “Competing on Value”, by Mack Hannan and Peter Karp, with their three-part framework of: How much, How soon and How certain.

As I describe in more detail in one of my early Value Alley posts (linked above), the basic framework is:

• How much?  Nearly everyone can instinctively evaluate this first criterion.  How big is your paycheck, your bank balance, the sticker price on that car, how much is that doggy in the window?  Even a small child knows when his older brother took the bigger “half”.
• How soon?  The domain of finance; the time value of money, discounted cash flow, internal rate of return, net present value, a dollar today is worth more than a dollar tomorrow.
• How certain?  We know the price to the penny, and the IRR to three decimal places, but what about the uncertainty around those numbers?  The risk?

Or as I put it in my follow-up post (“How Certain is that Number in the Window”), while you may know that the expected IRR is 39%, is that 39% sitting on top of a gentle hill, so that if some disturbance comes along it only get knocked down a dozen points or so, still well above your 20% hurdle rate, or is it sitting precariously at 28,000 feet atop K2, such that any deviation from plan causes it to avalanche downwards into single digit or negative territory?

Lastly, you need a risk management and mitigation plan with which to evaluate and monitor the investment decision.  Here I shared some ideas from the third and last of this series – “Making the “How Certain” Decision”.  My own approach involved evaluating the uncertainty around five key variables: cost and revenue cash flows, margins, working capital and time-to-market.  Looking back at my initial attempts, how I wish I had had some of SAS’ risk analytic capabilities at my disposal, such as sound statistical cash flow distributions, confidence intervals, and Monte Carlo simulation – not available via spreadsheets but a piece of cake for SAS analytics.

With the stage now set, the roundtable discussion began in earnest.  The first point to become clear was the confirmation of the obvious – that very few companies are actually engaging in even this minimal level of operational risk analysis and management.  Outside of credit risk, and outside of the market risk analysis that dominates the financial services industry, adequate operational risk management seems to be confined to a relative minority of the Fortune 1000, perhaps 20% tops.  It’s not just that the risk / uncertainly element is missing on the front end, it’s that the basic follow-up and the post-mortems aren’t there either; there is little tracking and monitoring of even the How much and How soon components, no follow-up to see if the actual outcome was anywhere close to the 39% promise.

When we talk about swinging the finance function from being 80/20 transaction weighted to an 80/20 analysis focus, risk management and investment post-mortems would be one of my top priorities for that new-found, hard-earned free time.

But the topic that really captured our attention for the remainder of the session was: what role does risk management play in an agile environment?  What might it look like?  How might it be different from today’s risk management approach, if at all?

The group consensus was that “agile” does in fact change the game.  In today’s environment, it is highly unlikely that your typical two-to-four year new product / new market / IT system initiative/project/investment will end up looking much like it was originally drawn up. Therefore, does every project get re-planned as the business actively responds to changes in the market with changes at the strategic level?  If you were to conduct a post-mortem, what should the final success measurement criteria be – the original, or the last version left standing?

My own opinion is that ‘agile’ translated into ‘risk’ means scenario planning.  Just as I discussed scenario planning at the enterprise level in this post (“Rolling forecasts, or Who ordered that?”), with its Plan B, Plan C and Plan V (for volatility), if a project is large enough, important enough, or risky enough to warrant a full-blown, quantitative business plan and analysis, then that project plan needs to incorporate optimistic and pessimistic, best case and worst case scenarios (at a minimum) as part of its business plan.  When the enterprise as a whole moves from Plan A to Plan B, the projects move from their respective Plan A’ to Plan B’.

And if the business shifts its strategy sufficiently such that none of the project scenarios are applicable, then yes, I think the project and the investment decision get revisited and re-analyzed.

But I don’t think this approach mollified the group’s concerns.  Can you even be agile with these relatively cumbersome risk management processes in place?  The consensus seemed to be that these operational risk management processes as currently construed cannot survive.  The risk management processes themselves need to become agile.

But at this point the conversation stalled.  What an agile risk management process might look like was beyond the scope of our mere sixty minutes, but hopefully not beyond the experience and insight of my audience.  I’d like to hear from you in the COMMENTS section:  What do you think about this relatively recent intersection of agile and operational risk management?  Can they be made complementary?  Can we expect them to play well together, or does one of them have to go?  How can we make risk management as agile as the rest of the business?