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. We continue our discussion with explanations and examples. For each point, we will give you the practical take-away to apply in your risk management program.

Show Notes



In Episodes 1 and 2, we asked: Why is ERM so incredibly convoluted and seemingly complex? and began to answer this question by explaining that there has been a proliferation of advice, leading to a confusion of foundational definitions, and core methods and practices. We did some myth-busting, an examination of misconceptions: and in this episode, we look at the remaining myths in the list of issues I identified. In each case, I’ll be giving you the lesson or point to take away for application in your own risk management regime.

Main points              

[01:40] Myth #8: Managers, directors, analysts, CEOs, etc. know how to implement new programs.
Take-away: In fact, the studies reporting on the implementation of management initiatives in all sectors show that failure and under-delivery are quite high, and there is a considerable literature on the causes. This should be taken into account when designing and implementing the ERM regime.

[04:42] Myth #9: Enterprise Risk Management can best be implemented by using a software application.
Take-away:  Technology and enterprise software implementations are indeed a notorious when it comes to program failure and chronic under-delivery, with extraordinary costs. Establish and understand your own business process and investigate thoroughly the success factors in IT implementation before contemplating a large commitment of resources to tech “solutions”. Above all, do not fall prey to the myth that the technology, in and of itself, will inspire acceptance and take-up of the new management program, whether it is ERM or something else.

[0639] Myth #10: Defining “risk tolerance ” is essential to an ERM program. 

Take-away: It is not necessary to make grand statements of risk tolerance, especially in non-financial organizations. It is perfectly acceptable to simply express goals, values, and aspirations, then employ risk tolerance as one of the criteria to evaluate identified risks. Those risks that affect more closely our core mission, we will have a low tolerance for, and thus try to mitigate. Other identified risks will be more peripheral to our mission and so less critical. Tolerance then is a relative, not absolute, notion.

[08:37] Myth #11: Monitoring compliance constitutes effective ERM.
Take-away: A compliance regime may be appropriate for the business or organization. But the danger is to construe apparent compliance as real adherence to the regulations or code. Risk assessment must investigate the possibility that a check-the-box or superficial monitoring operation is actually missing breaches. Then again, successful operational complliance will be insufficient if the organization does not examine strategic risk in light of the wider environment, industry trends, etc.

[11:23] Myth #12: Linking corporate strategy to ERM is difficult and complex.
Take-away: The risk ID and assessment process (I advocate for a process I call High Quality Risk Assessment) should be scalable and applicable to any context, including, of course, the strategic plan itself. We naturally assume that you have arrived at goals and objectives through a planning process. The questions then become: is the strategic plan well founded? Is it substantiated through research into industry trends and conditions? And is it properly formulated in terms of actionable goals? If the answer to any of these is no, then that is your first important risk.

[15:09] Myth #13: ERM takes 3-5 years to implement.

Take-away: Successful implementation, even in a complex organization can be a matter of weeks or months -- not years. I give the example of a post-secondary institution where I was the consultant for a successful ERM implementation in 18 months, and it is a robust practice that has stood the test of time.

[16:25] Myth #14: Good ERM predicts the future; it is effective forecasting.
Take-away: Forecasting uses historical data to establish the probability of certain definite outcomes, and so relies on the statistical method. Enterprise Risk Management, by contrast, rarely has the pertinent statistical data to bring to bear upon the full range of strategic and operational decisions, and so uses a round table method. We identify the uncertainties associated with a given plan, and then take immediate action to mitigate and nullify them.

Establish and understand your own business process and investigate thoroughly the success factors in IT implementation before contemplating a large commitment of resources to tech “solutions”. Above all, do not fall prey to the myth that the technology, in and of istelf, will inspire acceptance and take-up of the new management program.


Program implementation failure
A synopsis of various studies.

Technology implementation failure
Scroll down to audio post: innovation: successful tech implementation part one


The question is: How are these applications faring? The answer is, not very well.

Risk tolerance vs risk appetite
RIMS document, pdf download
Exploring Risk Appetite and Risk Tolerance

“Steering clear of compliance pitfalls” © Key Media Pty Ltd.
Unattributed, 31 May 2010. Corporate Risk and Insurance. Excerpt:

“The most common pitfall in compliance programs is an overreliance on policies, procedures and systems, according to Ulysses Chioatto, director of SSAMM Management Consulting.

A cursory glance over all the convictions and enforceable undertakings by ASIC in the past five years highlights this overreliance on policies, procedures and systems by financial services providers in their compliance programs, said Chioatto, with little to no work on people – or to put it another way, the company’s culture. 

‘Both internal and external auditors as well as compliance and risk officers pore over documents, flowcharts, plans and reports from computer risk and compliance applications, yet breach registers are overflowing, or worse still, completely empty.’ “