Practical steps to wider adoption of risk management: simplifying risk models for more frequent use

What went before ...

In the early '00s, the relevance of using risk models was very much disputed. A number of leading companies in the risk management field did not see the reason to use models, as they felt that practice impeded organizations from assessing the entirety of their risks. In the late '90's of the past century, Arthur Andersen was one of the first companies to start structuring risk models as a basis for the structural implementation of enterprise (wide) risk management.

The wider adoption of risk models

Risk models really came to the fore towards the end of the '00s, when experiments in implementing enterprise risk management or ERM systems showed a significant flaw in the prior reasoning: people did not share a mutual understanding of the term 'risk', much less individual risks. They even failed to agree on a common definition for the most traditional of risks.

This was broadly solved by the development of risk models: industry specific structured overviews of potential risks which could occur in companies active in a certain industry, with a clear definition of what the risk means in agreed upon terms. Agreed upon terms would be adapted to company specific terms, in order to limit the risk of misunderstanding and thus mistreatment of a specific risk.

The challenge of today's risk models

But in our quest to increase the transparency and the unified interpretation of risk models, I fear we may have overcomplicated matters. We actually overcomplicated risk models themselves.

Overcomplicating a risk model – or any model for that matter – lowers the adoption rates by its potential users. It's pretty much like using formula in a book, or in a blog post for that matter. It is 'understood' that each formula halves your audience. Risk models are not necessarily different. The more specific the model, the fewer its users.

Therefore, while the move towards a more complex set of risk models was necessary to develop enough detail in the risk models, we now need to make the reverse move. This move should not be towards no risk models, but towards another method of using these risk models. What I have in mind is a list, an overview of possible risks.

The added value of risk management

Let's examine what the actual added value of risk management can be? It is the optimization of our response to priority, identifiable risks if and when they occur. I may be insulting quite a few experts with the following statement, but risk management should NOT be a central pillar of a management system. It adds to better risk response, and can be added to ways in which an organization is run, but should not be the central element.

In essence, even if no management exists, this would not preclude risk management systems to exist across an entity or a group of entities.

An example of simplied risk models in risk management - the case of distributed ad hoc structures

The context of the example

We see the demise of certain (types of) corporations, especially, but not only in the services sector. These mastodont, monolythical structures are being replaced by decentral, distributed networks of independent contractors which come together on a project-by-project basis. This is the context in which I want to develop this short example.

The case for risk management

Given their increased exposure to larger and larger projects, hence larger and larger responsibilities and linked to that larger and larger potential liabilities, perhaps now more than ever, these decentralized networks need risk management, but they inherently do not have a management structure to, well, structure or 'manage' their risk management.

A quick detour - the trigger list in Getting Things Done

So, how do you manage risk in a distributed, decentralized environment, or in any type of environment for that matter, in an as cost-effective way as possible? You develop a risk trigger list for that specific environment or for that specific project they are engaging in.

Actually, this idea is not new. I borrow the central idea from David Allen, who in his excellent book "Getting Things Done" refers to an incompletion trigger list as an essential tool for the brain dump, in essence a way of clearing any issues in your head and getting them on paper, for further processing.

The trigger list is a very powerful tool: it is small enough (David Allen's trigger list, here in its excellent Merlin Mann interpretation covers at most 2 modest pages) to be used on a regular basis and yet complete enough so all elements you may have forgotten can be dealt with. What is even more interesting is that the tool can be used again and again in the same type of environment, and is easily adaptable to other types of environment.

The solution - The Risk trigger list

In order to enhance adoption of risk management as a tool, in order to make it usable on a regular basis and complete enough to deal with most risks one could forget about, I advise to develop a risk trigger list per project, process, organization or even industry. This trigger list, which should not be more than 2 pages long, contains trigger words, words that will result in a comprehensive listing of most of the relevant risks which can occur in that process, project, organization or industry.

You may be surprised. At least per industry, I believe at least 50% of the risks will be the same across organizations. The list will partly be generic, and partly specific to the organization, the process or the project. Developing a risk trigger list should be one of the first responsibilities in any new process or project.

The relevance

By simplifying the comprehensive risk models we've developed in the past 10 years and condensing them into risk trigger lists, we may reach the critical threshold to wider adoption of risk management principles, which will in turn lead to better managed processes, projects, organizations and industries.

Better risk based situational awareness using risk models

This is a rewrite of an article I wrote in 2010. I'm revisiting some of my earlier writings to update them to my current ideas.

Top five versus first five issues

Ask people for their top five issues in any area of concern other than an area they are personally and closely involved with, and they are more than likely to give you the first five important issues that come to their mind. Of course, these are not necessarily the top five issues, they are their top five issues at that moment.

This problem, by the way, is a typical challenge of idea generation which you try to counter with brainstorming. Ideally, you would ask them to tell you their top 50 issues, and then prioritize. However, quite often they don't have the time and you don't have the budget. And that is a critical problem. Why?

Getting an as complete as possible view on risks is essential in a risk management exercise. After all, risks not identified cannot be managed, and will come to the fore at the most inopportune of times.

Using risk models

This is where risk models come into the picture. A risk model aims to take a lot of the preparatory risk identification work out of your hands. There are certain advantages to using a predefined set of potential risks for an organization. Three of the most important ones are:

• it allows you to focus on the relevance of the proposed potential risks, thus reducing the actual effort invested in thinking about completeness;
• it allows you the time required to better and more clearly defined the risks which are considered as relevant;
• it allows you to identify those risks not already present in the risk model.

Errors in understanding the use of a risk model

People opposed to the use of risk models will make the case that the tool has limited value because you can never integrate all relevant risks in one framework.

It is indeed practically impossible to integrate all relevant risks in one overarching framework. However, rather than making a risk model a tool with limited value, the simple fact that the risk model has already defined a lot of potential risks and thus takes away the effort of performing the same analysis again and again, makes it a tool which saves you time and effort. Rather than reinventing the wheel again and again, the risk model allows for true value creation in defining new risks which you otherwise would have never thought about because you were so focused on the top 5 risks.

The relevance of the risk model

A risk model allows you to focus on the essential risks both present in and lacking from the model. This leads to a better degree of concrete, situational risk awareness in a risk assessment exercise.

What defines a risk model?

This post is a repost of a short article I wrote in 2009, on my then riskguy blog. I've rewritten it to more appropriately reflect my ideas on this, as of course over the past years this has evolved. I've revisited this article because it has become actual again in the ongoing discussion on whether or not to use a risk model.

In a lot of the articles on this blog about internal audit or risk management, I refer to the Risk Model or the Risk Identification Model, or Risk Model, but what defines a risk model to me?

The following are to me the two defining elements of the Risk (Identification) Model, with some explanation:

It’s a Model

It is a structured representation of a reality. It is important to realize that the map, or the model in this case, is but an abstraction of, and therefore not the territory. It is a representation, a ‘simplification’ for easier use or access. And as any simplification, it does not contain all dimensions or aspects of the real thing. We use a model to make it easier to deal with or to handle a complex reality.

So whatever way you look at it, you cannot ever blame the model for its inadequacies or its incompleteness. As a risk manager, you have the responsibility to make sure the risk model you use is adequate across all the dimensions you are using it for. In effect, having a subject matter expert looking at the model for each of the dimensions you will be using it for (operational, financial, strategic, human resources ...) is highly relevant and can only add to the relevance and the pertinence of the model.

It serves a purpose and only that purpose: identifying risks

The model is to be developed for and aims at supporting the user in identifying risks which are relevant to him or her. The structured representation of a model reduces the reality to a set of risks (the concepts) out of a risk universe (a set of all possible risk events which could occur) with respect to the objectives of the area in scope such as an organization, a division, a set of processes, a process, a sub process or a set of activities.

So, if you want to use the model for another purpose, it cannot serve as such. Much like you cannot use a map of London which is useful for a car as a means of finding public transportation. Other purposes, other tools.

A definition for a risk model

Thus, in short, a Risk Identification Model or Risk Model is a simplified representation of the risks to the objectives of the in scope area, for the purpose of identifying those risks.

Simplifying risk models

A brief history

The relevance of using risk models as the basis for risk management was disputed in the beginning of this century. It actually remains disputed as an approach by a number of authors. In the early ‘00’s, leading risk management advisory companies did not see the reason to use models. They felt it impeded organizations from assessing the entirety of their risks. In the late 1990’s, Arthur Andersen was the first company to start structuring risk models as a basis for the structural implementation of enterprise risk management. Some of their risk models remain as risk models you can for example find in Protiviti’s Knowledge Leader.

The wider adoption of risk models

Risk models really came to the fore towards the end of the ’00s, when experiments in implementing enterprise risk management or ERM systems showed a significant flaw in the prior reasoning: people did not share a mutual understanding of the term ‘risk’ and even failed to agree on a common definition for the most traditional of risks.

A solution wasthe development of risk models: industry specific structured overviews of potential risks which could occur in companies active in a certain industry, with a clear definition of what the risk means in agreed upon terms. Agreed upon terms would be adapted to company specific terms, in order to limit the risk of misunderstanding and thus mistreatment of a specific risk.

The challenge of today’s risk models

In our quest to increase the transparency and the unified interpretation of risk models, I fear we may have overcomplicated them. Overcomplicating a risk model – or any model for that matter – lowers the adoption rates by users. Therefore, while the move towards a more complex set of risk models was necessary to develop enough detail in the risk models, we now need to make the reverse move. This move should not be towards no risk models, but towards a list, an overview of possible risks.

The added value of risk management

Because what is the actual added value of risk management? It is the optimization of our response to priority, identifiable risks if and when they occur. Risk management should NOT be a central pillar of a management system. It adds to better risk response, and can be added to ways in which an organization is run, but should not be the central element.

In essence, even if no management exists, this would not preclude risk management systems to exist across an entity or a group of entities.

Let me explain: we see the demise of certain (types of) corporations, especially, but not only in the services sector. These are being replaced by decentral, distributed networks of independent contractors which come together on a project-by-project basis. Perhaps more than ever, these decentralized networks need risk management, but they inherently do not have a management structure to, well, structure their risk management.

The trigger list in Getting Things Done

So, how do you manage risk in a distributed, decentralized environment, or in any type of environment for that matter, in an as cost-effective way as possible? You develop a risk trigger list.

Actually, this idea is not new. I borrow the central idea from David Allen, who in his excellent book called Getting Things Done refers to an incompletion trigger list as an essential tool for the brain dump, in essence a way of clearing any issues in your head and getting them on paper, for further processing.

The trigger list is a very powerful tool: it is small enough (David Allen’s trigger list covers at most 2 modest pages) to be used on a regular basis and yet complete enough so all elements you may have forgotten can be dealt with.

The Risk trigger list

In order to enhance adoption of risk management as a tool, in order to make it usable on a regular basis and complete enough to deal with most risks one could forget, I would suggest to develop a risk trigger list per project, process, organization or even industry. This trigger list, which should not be more than 2 pages long, contains trigger words, words that will result in a comprehensive listing of most of the relevant risks which can occur in that process, project, organization or industry.

You may be surprised. At least per industry, I believe at least 50% of the risks will be the same across organizations. The list will partly be generic, and partly specific to the organization, the process or the project. Developing a risk trigger list should be one of the first responsibilities in any new process or project.

The relevance

By simplifying the comprehensive risk models we’ve developed in the past 10 years and condensing them into risk trigger lists, we may reach the critical threshold to wider adoption of risk management principles, which will in turn lead to better managed processes, projects, organizations and industries.