Last week while attending a banking conference I found myself in a conversation about Enterprise Risk Management (ERM). I had made the comment that I was tired of constantly hearing different definitions of what the discipline is and how it should be applied. It’s the latest hot buzzword fueled in large part by the banking crisis that’s still unfolding and how industry experts believe that much of the mess could have been avoided if management was better at measuring and managing risk more effectively. And while in theory I agree that ERM would certainly have helped, that’s only true if the concept is applied effectively.
While I’m no expert on the subject I have plenty of experience working in organizations that either have successfully implemented ERM practices or who are attempting to do so. I am routinely amazed by what I discover along the way, how some have a firm grasp on what needs to be done and how others simply rebrand a group or function as Enterprise Risk but do little else to further the initiative. There are some core activities that need to be in place and functioning in order for management to achieve any measure of success and ultimately they’re either there or they’re not.
My entire perspective is a bit tainted. I first learned about ERM at the hands of a master practitioner. A few years back I attended a two-day workshop taught by Tim Leech who has been often referred to within my circle of associates as the “Godfather of ERM”. Tim has been assisting companies of all sizes, complexities and verticals for decades in building out programs to first define their risks and figure out what to do about it. His approach is so effective that to the casual observer it would almost seem simple, even easy to implement. However what I learned after two days of listening and learning was that there was a right way and a wrong way to build out ERM programs, that the approach needed to be tailored to the organization and that if the wrong people are leading the way it could cause more harm than good. A few months later I had the pleasure of participating in an actual ERM engagement where Tim applied his theories to assist a healthcare company in designing the foundation of an ERM program. It was fascinating how much information he was able to collect from an audience comprised entirely of the “C” suite, how he engaged them in a lively dialogue which resulted in a frank and honest identification of risks and allowed them to begin building out a framework. What was key to the early success of the newly forming program was that it resonated with management because it echoed their sentiments and incorporated their thoughts and concerns. The risks that they were being asked to address made sense to them because they were the ones who helped identify them to begin with.
Unfortunately what I didn’t realize at the time was that I might never have a reason to feel as good about ERM ever again.
In the time since my introduction to Enterprise Risk I have routinely encountered approaches where a team of really smart people sit in relative isolation and come up with a list of risks they perceive as being relevant to the organization. They then try and figure out what to do about it so that they can provide direction to management. Management often receives the information more as a directive rather than guidance and attempts to operationalize it. People in the proverbial trenches are often attached to activities as a result, struggle to implement new controls and associated processes and report on progress. And in the end no one really even knows if the work was either necessary or useful. I’ve encountered several variations of this approach, sometimes where external experts are brought in, sometimes where internal audit leads the way but almost always with the same general limitations; no one talks to the people who live with the risks.
I’m reminded of a phrase I encountered years ago and have always liked: “It is not the same to speak of bulls as to be in the ring”.
Rare is the ERM approach where the approach incorporates an active dialogue with the people “in the ring”. How can you identify any measure of risk without first talking to the people who have to deal with it every day? Sure there are frameworks that predefine some of what needs to be done but any regulation, any guidance that currently exists advocates for an organization to identify and measure risk as it exists within their world, their infrastructure. And the only reliable way to begin such an exercise is to talk to the experts, the people who know how things really get done. And how do you even know which people to talk to without first starting atop the organization and finding out what management is committed to doing, what their business goals and objectives are? This information isn’t found in a document or in a spreadsheet, it only exists in the minds of those people who help run the organization. Without knowing what they know and understanding what they’re concerned about you don’t really have a meaningful clue about what or where the risks are.
Doing what I do for a living you get pretty good at forming qualifying questions that quickly frame a clients environment. Recently I asked a network manager about his institutions vendor management program and he wasn’t sure if they had one; I told him they didn’t because in his role, if they did, he would have to know about it. And so when I ask someone serving in a critical role about their institutions ERM efforts I can more or less assess its effectiveness based on the answer. If I hear anything along the lines of “I’m not really involved” or “I think it’s covered as part of our audit process (a popular misconception)” I know that ERM is just a buzzword and not a true discipline. Because if it existed in any meaningful way they would have needed to contribute somehow. And thus my reason for being frustrated.
I really don’t want to hear about ERM or talk about it unless it’s contextually effective. If the “E” in ERM doesn’t represent “Enterprise” but rather “Executive” or “Existential” or some other unrelated perspective I’ll take a pass. It’s like when Cobit-based became the defacto standard and everyone wanted to know if your framework was Cobit-based as if that somehow conveyed something akin to pedigree. There’s real work behind the discipline and all because you label a group or project ERM doesn’t mean it is. And I’ll promise you this, if you’re applying some or all of ERM’s most basic tenets there’s no way you’ll ever speak of it in conceptual terms ever again. Because once you’ve been in that ring you’ll never look at a bull the same way.