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