What are common misconceptions that can block success in your Enterprise Risk Management program? Your host Edward Robertson has a list of ERM myths, observed over several years’ experience as practitioner and educator. For each point, we will give you the practical take-away to apply in your risk management program.
In the first episode, we asked: Why is ERM so incredibly convoluted and seemingly complex? Why is there not better take-up? Why is there such a strange juxtaposition between the obvious need for ERM and the stagnation of methods and results?
We began to answer these questions by explaining that there has been a proliferation of advice, leading to a confusion of foundational definitions, and core methods and practices.
Myth #1: ERM is one thing. No, there is a proliferation of methods and definitions.
Myth #2: International standards (ISO 31000; COSO, etc.) give ERM implementation guidance. No, they are too general in nature. Don’t try to follow such standards as specific guides to implementation.
Myth #3: ERM is unproven. No, there undoubtedly examples of successful practice. But successful ERM occurs in specific instances that may not be comparable, due to the confusion of definitions explained above.
Myth #4: ERM imposes an unacceptable administrative burden. It would seem so, but only if the risk ID and assessment process is ineffective.
Myth #5: ERM is the purview of audit & finance. This is commonly the case, but does it make sense for audit to identify risk, if they are responsible for the quality of the risk process itself?
Myth #6: All the various pre-existing risk disciplines and practices will be replaced by ERM. People in various pre-existing risk management practices (eg., health and safety; environmental assessment; IT security) sometimes believe that ERM will try to impose its own methods on them. This is unnecessary.
Myth #7: Managers in all verticals can reasonably be asked to conduct risk assessment. On the contrary, most people in administrative settings are non-experts in conducting risk assessment.
“over 80 risk management frameworks…”
Ahmad, Saudah et al. (2014) “Enterprise risk management (ERM) implementation: Some empirical evidence from large Australian companies”
“30% of time spent in meetings was unproductive…”
S. Rogelberg, et al. “Wasted Time and Money in Meetings: Increasing Return on Investment”
Episode 002 Enterprise Risk Management: Busting Myths – part 1/2
[edited for clarity]
[00:43] This is the Risk Commentary. Podcast my name is Edward Robertson and this is Episode 2 Enterprise Risk Management – Busting Myths. You know last time we discussed some very important questions with respect to Enterprise Risk Management for example. Why is there such a strange juxtaposition between the obvious need for ERM and the stagnation of methods and results that have been showing up in the surveys? And related to that, why is ERM are so incredibly convoluted and seemingly complex?
Well, we started to answer these questions by explaining that there’s been a proliferation of advice quite naturally developing — people in the industry taking up the task — and leading to confusion of foundational definitions, not to mention a whole sort of kaleidoscope of different practices and methods that were introduced into the discourse on Enterprise Risk Management. Well I think we can take a closer look at this citing a series of what I take to be to be misconceptions that I’ve observed over the years. So what I want to do is introduce each myth and then explain why I think it’s a misconception and to give you maybe one or two examples and explain what the significance is, why it’s important understand that you know this is a wrong idea and then give you the positive take away (the thing that you need to remember to apply this principle in your risk management practice). So let’s get started.
[02:13] The first myth is that Enterprise Risk Management is one thing. No I think it’s quite easy to demonstrate that Enterprise Risk Management is not one thing. In fact it really depends on the interpretation that is given it to inform the implementation. You get the impression perhaps unconsciously that it is one thing. When you look at the term Enterprise Risk Management, let’s say in courses, in textbooks, in articles and so on, and you tend to assume after awhile that everyone is talking about the same thing. But because of that proliferation of advice that I was referring to, we can see that each implementation actually takes on its own character, so that after a while you’re not even sure that people are really comparing apples to apples. In fact in one article that I found the author had identified 80 different frameworks and associated definitions of Enterprise Risk Management — so you can see the kind of fragmentation that has occurred.
So what is the take-away from this point? I think the lesson is that when we select or even invent the definition of Enterprise Risk Management to inform the implementation in the organization, it has to fulfil certain things. 1. First of all it has to suit the character of your business and your organizational culture. 2. Secondly you have to be sure that everyone understands exactly the same thing by the terms that are used (that they don’t have different associations to the definition). 3. The third thing is it has to be detailed enough or specific enough to inform exactly how you’re going to go about doing things.
You know, I’ve seen quite a few definitions of ERM that seemed good on the surface, but when you look at them closely and sort of think how they might be operationalized, you realize that they’re really just too vague. So, of course, I do have definitions which I propose and can defend at length, and we’ll get there — but right now sort of too early to go there. I just wanted to alert you to the fact that ERM is not one thing and it really hinges on the definition and the interpretation that you assigned to it.
[04:30] The next myth that we want to address myth #2 is: International standards (for example ISO 31000, COSO and so on) give e. r. m. implementation guidance. Well that’s a reasonable assumption. And that’s what I thought too. I thought that you could get really close advice on how to roll out your program by going to these international standards.
If you take one of these standards, and maybe you’ve had this experience, and try to slavishly copy steps one by one, very quickly you find out that you actually have to interpret this standard to be able to apply to your business.
So there’s sort of a hierarchy in the regulatory framework. 1. At the top level, you’ve got the standards. 2. Then you’ve got, let’s say, a policy that you develop, that is suited to your organization that draws from or is based on the standard. 3. And then the next level would be a specific guidance, tools, templates and specific implementation.
I’ll give you one example. You’re familiar with the steps in the risk management process: establish context; identify risk; assess risk; and so on. Well, I wanted to become much better informed on specifically how to roll out IT security risk (management) and I saw on one of the big standard’s website that they had document addressing IT security risk. So I actually paid for this document and then I went to read it, thinking I was going to find out all about the special categories of analysis for IT security. And what did it say? ”…establish context; identify risk; assess risk…” exactly like the parent document! So I have to bring to the table (myself) all of the special knowledge on IT security to be able to do a risk assessment in that domain!
What is the positive take away on this myth number two with respect to international standards? It’s simply to recognize that they are good to select, making sure that you select something that suits the character the business of your organization, and to regard it as a repository for general advice; i.e., the steps in the risk management process, and perhaps the definition of terms, and vocabulary. That way you can have something to serve as a bedrock for your implementation — with the recognition that you have to interpret that document to be able to translate it into something that’s operationalized in your organization.
[07:00] The next myth that we want to address is myth #3: ERM is unproven. And I think this is probably the attitude of many people, let’s say at the board level or C-suite level, who are contemplating implementing Enterprise Risk Management, but regard the whole thing as too undefined — not really well proven, in the sense of specific results following on an authoritative definition.
Yet I characterized that statement ‘ERM is unproven’ as myth or misconception because there are undoubtedly successful examples of ERM, and it does make intuitive sense to manage uncertainty for the entire organization from the strategic right down to operational levels. The difficulty is that we can’t find the successful examples through one authoritative channel — and again, it will be a question of “Well, which version of ERM are we talking about?”
So I struggled with this question too. In the early years when I was working in the ministry of finance we were implementing Enterprise Risk Management, and in one meeting with the deputy minister we complained that we couldn’t find case studies that would really guide and inform our implementation. He said, ‘You know what at the end of the day we’re just going to have to create our own case studies’ and I think he was right on.
So that is really my take-away for this point. Once having decided on some definition of Enterprise Management that suits the character of your organization, then the best proof is the proof that you and your team demonstrate, on a step-by-step incremental basis, to establish the value of the process!
[08:35] Let’s move on to the next myth which is #4: ERM imposes an unacceptable administrative burden. Well this is a common objection, and I do understand the sentiment that people don’t want to have an extra layer of work imposed upon their already busy lives. But I do characterize it as a misconception or myth. I’ll tell you why.
First of all people don’t quite realize that, according to studies, fully one third of meeting times are wasted. Now, judging from experience in both public and private sectors, I would estimate that the amount of wasted time in meetings to be much higher than one third, maybe as much as 50% or 60%. And why is that? It’s because the meetings are not well structured, and they’re not well facilitated. And I’m talking about whether it’s regular stand ups, or project meetings, or the weekly or monthly department meeting.
But here’s the interesting potential with risk management. Of course it takes some initial work to build the risk register. But once you’ve got it built, then what you’ve got is a very powerful tool. You’ve got all of the crucial issues that you have to manage (in this particular context — whether it’s the project or your department business or whatever) ranked by consensus, with items of mitigation set out. If it’s done right initially, then it’s comprehensive. It really is giving you a much better view of the business, and an efficient way to manage it. This is much better than an ad hoc circuitous discussion.
My take away for this point is that ERM seems to impose an unacceptable administrative burden, but that depends entirely on the nature of your risk ID and assessment process. If it’s a really good one, a sharp one, and you develop a comprehensive and insightful risk register, then you can run meetings more efficiently. But not only that, you give people confidence that they’re managing, in a structured way, the uncertainty that is impinging on their business.
[10:37] Myth #5: ERM is the purview of audit and finance. In practice it is the audit function that takes charge of Enterprise Risk Management. But, conceptually, consider… this is just as the risk manager for Hydro One years ago stated at a conference: ‘We don’t want audit checking on the things that it has its fingerprints all over.’ In other words, if audit actually conducts risk assessment, and then on the other hand goes and audits the risk assessment process for the whole organization, are they not sort of losing their impartiality? So there may be a way to manage around that, but strictly speaking we want audit to maintain its impartiality.
Now similarly with financial risk, it’s often the case that Enterprise Risk Management is construed to be primarily or even solely financial risk management. And yet I would say that’s a misconception. Do we not want finance to be subsumed under the ERM umbrella, so that it can be taking into account corporate vision, mission, strategy and values, instead of being isolated? And if you want evidence for that sort of view, consider the many cases where companies who had really good finances and maybe their insurance portfolios were up to scratch and everything was good — but they failed to identify strategic risk in the form of, perhaps, other companies destroying their markets, or technology changing.
So our take away for this point is that Enterprise Risk Management is the umbrella function which really subsumes all the other risk management disciplines, and should not be governed or overly influenced by one or another pre-existing risk management practice.
[12:28] Myth #6: All the various pre-existing risk disciplines and practices will be replaced by ERM. Here we see people being concerned… Let’s say they’re involved in IT security, environmental audit, or health & safety, or some sort of established risk management discipline where they have their own certifications and methods and so on. They feel that going to be replaced by some mysterious ERM methodology, whereas it’s not the case at all.
Rather what we do — and here’s the take away for this point — is subsume all of these various practices under one under one umbrella. But how do we do that? Not through a uniformity of methods, but rather by making sure that everyone is supporting the same strategic and operational goals, objectives, and corporate values. This is an important point, because often these various sub-disciplines are sort of pursuing their own agenda. And this is the way we can proceed with Enterprise Risk Management with minimal disruption and yet unify everyone’s practice, so that everyone is reporting on the risk profile that is pertinent to the strategic aim.
I think the classic example of a department where risk management needs to be integrated with the Enterprise view is IT (information technology). In the past I think IT departments were prone to sort of go off in their own direction. That has largely changed, whereby they focus on core business.
But still it’s going to be taking some effort on the part of risk champions to go in and establish a dialogue with the IT folks; understand what their enterprise architecture is all about; what their enterprise plans are; their standards; their plans for total cost of ownership, life cycles and so on… so that they can come to agreement on the categories of analysis that are applied to the IT risk assessment, in support of the strategic direction.
Well we’ve reached almost halfway mark in our long list of Enterprise Risk Management myths to be exploded. We’ll do one more and then save the rest for the next podcast episode. In the meantime, if you’d like to subscribe you can go to my site Risk Commentary dot com. If you subscribe there then you can get on my list, and I’ll send you show notes, which includes a full transcript of the episode, along with links to articles that support some of the points I’ve been making, as well as a free giveaway: Enterprise Risk Management Tools and Templates. Let’s now consider myth #7.
[15:11] Myth #7: Managers in all verticals can reasonably be asked to conduct risk assessment. I think this was the unfair expectation that was imposed on managers in all kinds of different industries, where people were simply not experts in risk management methodology. The result was ad hoc and informal methods that led to bad results.
So what is our take away here? Above all, don’t let people manage risk by having vague, unstructured discussions. Try to lead them and train them in a high quality risk assessment process. And we will get into what that’s all about.