Agile risk management – What might that look like?


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?


About Author

Leo Sadovy

Marketing Director

Leo Sadovy currently manages the Analytics Thought Leadership Program at SAS, enabling SAS’ thought leaders in being a catalyst for conversation and in sharing a vision and opinions that matter via excellence in storytelling that address our clients’ business issues. Previously at SAS Leo handled marketing for Analytic Business Solutions such as performance management, manufacturing and supply chain. Before joining SAS, he spent seven years as Vice-President of Finance for a North American division of Fujitsu, managing a team focused on commercial operations, alliance partnerships, and strategic planning. Prior to Fujitsu, Leo was with Digital Equipment Corporation for eight years in financial management and sales. He started his management career in laser optics fabrication for Spectra-Physics and later moved into a finance position at the General Dynamics F-16 fighter plant in Fort Worth, Texas. He has a Masters in Analytics, an MBA in Finance, a Bachelor’s in Marketing, and is a SAS Certified Data Scientist and Certified AI and Machine Learning Professional. He and his wife Ellen live in North Carolina with their engineering graduate children, and among his unique life experiences he can count a singing performance at Carnegie Hall.


  1. Pingback: Best approach for agile risk management | Hornby Research

  2. Pingback: Best approach for agile risk management | Hornby Research

  3. Hi Leo … great topic.

    I personally believe there is only one way to do risk management … and that’s in an agile environment – especially if you are practicing operational risk management.

    There are two reasons behind this.

    The first is access to data and knowledge, and the second the quality of scenario planning. Both present problems “agile” can address.

    I’ve written a blog post explaining the logic and approach: Best approach for agile risk management

    Would love to know what you and your readers think.

    Kind regards, Jonathan

  4. Robby Powell

    I find it interesting how processes in general share the same fundamental risks and constraints. The primary difference being the magnitude of the impact of failure. Two-to-four year projects typically end up looking quite different than the original plans. What criteria should be used to measure the success of these projects since they are quite different than what was originally designed? Waterfall processes work for certain projects, but applying agile, lean thinking to cumbersome processes is an approach to break these large processes into manageable, atomic elements that can be addressed and measured individually. In Jonathan’s comment, he points out the Demming PDCA Cycle which changed manufacturing processes forever. DevOps methodologies are now being well received by IT as a way to apply agile, lean thinking to the entire process of software design, development and deployment of software projects. I have posted the topic that discusses DevOps at a high level - "What's with all the fuss about DevOps?" I think agile and lean are the best approaches to address complex processes – regardless of domain.

  5. Pingback: Changing Corporate Culture is Like Losing Weight | EPM Channel

  6. Pingback: Changing corporate culture is like losing weight - Value Alley

Leave A Reply

Back to Top