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.
Exploring The Black Box 