When organizations embark on the Enterprise Risk Management (ERM) journey, one of the first (…and biggest) mistakes they make is to simply cut and paste one of the common risk management standards or frameworks and think it will meet their needs.

Companies will often say “this one looks good, let’s go with it” and hope the framework will provide the value the company needs and expects. (Hope is not a strategy, remember?)

In many cases, a standard framework like the Project Management Book of Knowledge (PMBOK), JAVA for developing computer- and web-based applications, or some other business framework is the correct and best approach to take.

It’s understandable – after all, there’s a strong temptation to get ERM up and running as a quickly as possible for a variety of reasons. As Richard Anderson and Dr. Mark Frigo explain in this eBook on implementing ERM:

Boards and management are constantly faced with decisions ranging from strategy decisions to day-to-day decisions. An ERM process provides additional risk information related to the strategies to enable them to make better informed decisions to create and protect value.”

However, an ERM framework is not one-size-fits-all.

The two most common frameworks companies will look at for risk management needs are ISO 31000 and COSO. The ISO standard defines terms while COSO gets into more of the details on execution.

Since COSO goes a fit farther as a “how-to” framework, many will choose it to get started in my experience. Regardless of which one your company ultimately chooses though…

Implementing any “standard” ERM framework by cut/paste or any sort of “done-for-you” fashion will end up in failure.

This is a lesson I had to learn personally early on in my career as an ERM practitioner…

There are an infinite number of possibilities why an ERM initiative fails, but when it comes to implementing standards in this sort of haphazard way, there are a few important points a company is neglecting to consider, including:

• Why was a particular standard created in the first place (see the ISO and COSO articles linked below).
• Culture, structure, and other elements are different for every company.
• What the company’s needs are and what do executives want to get out of ERM. Is it due to regulatory demands or are executives or the Board clamoring for better risk management?

Instead of expanding on each of these important points to choosing a framework here, I strongly recommend checking out my previous articles discussing the background of ISO 31000 and COSO and other pieces I link to in the bulleted  list above.

Only once this is understood can risk managers begin examining each framework piece-by-piece to see how it can meet the company’s needs.

Again, it’s tempting to rush headfirst into implementing a framework but doing so can lead to failure.

Therefore, carefully comparing what a framework says is needed with what that would look like in practical terms for your company has to be the next step. Will the standard mesh well with your company?

Okay, I’m going to kind of show my age for a moment.

If you’re over the age of 30-35, you may remember overhead projectors like the one pictured below, especially from your days in high school and college. These devices use light to magnify information on a clear sheet and “project” onto a screen on the wall. This is definitely in the days before PowerPoint and computer integration in classrooms and conference rooms.

You don’t need to literally do the following – it’s simply an analogy or concept for determining how well a framework will mesh with your company.

Let’s say the bottom sheet is your company and you begin to “overlay” components of the process in the form of additional sheets. By doing this in a figurative way, you should be able to see what parts of an ERM framework will need modification to make it work for your company. Since every company is different, it’s challenging to provide a specific list, but some common examples can include:

• Changing terminology to reflect how the business communicates.
• Changing executive titles in the framework to reflect how roles and responsibilities are handled in your company.
• Changing who will be the owner of both the ERM function itself as well as individual risks and opportunities. This will drive who you will talk to.
• Setting up a sort of governance and/or oversight.

Once this “overlay” process is complete and modifications have been made to the particular framework you are using, you are not quite ready for a big roll out.

Like other new processes or physical items, there needs to be a trial or introductory phase where you  have a “pilot” of your framework in one or two departments. This allows you to work out the kinks that inevitably occur as you move from the development to implementation phase.

One thing I learned early on in my career as an ERM practitioner…copying and pasting a particular framework may work in some circumstances, but when it comes to ERM, it can lead to wasted resources, costly delays, and a loss of confidence from executives.

Therefore, save yourself the trouble, and don’t try to make a square peg fit into a round hole!

This article, originally published at https://www.erminsightsbycarol.com/ was re-published with permission.