How to build a risk trigger list

What is a risk register?

A risk register is an as complete as possible overview of all the risks that may potentially impact an activity, a process, a division or an entire organization within the scope of a risk assessment.

What is the purpose of a risk register?

A risk register is a tool to assist a process owner in being as complete as possible in the identification of the risks to his area of responsibility. It aims to “trigger” the user into thinking about whether certain risks may occur as well as triggering associated thinking about adjacent risks. Ideally, the use of a risk register will trigger an association that will lead to a new, not before considered, yet possible risk. As such, the tool assists in coming closer to completeness in risk identification.

Why would you use a risk register?

There are a number of advantages to using a risk trigger list beyond the stated purpose. Most of these advantages are related to knowledge.

• Knowledge consolidation: – As multiple points of view are considered and represented when building a risk trigger list, it allows users to consider and better understand the multitude of risks and challenges other people involved in the process face. The risk trigger list will consolidate knowledge about potential exposures in a process.
• Knowledge tranfer: – new collaborators have a tool in the risk trigger list that will allow them to more quickly understand what can potentially go wrong in their new area of activity. Knowledge about these potential issues is tranferred, and need not be transferred in real time, person to person.

How can you build a risk trigger list?

The following steps are steps I have used a couple of times in building a risk trigger list. They are by no means the only or even the best way to build it, they have just worked for me and they make sense:

1. Identification of issues related to roles and responsibilities: through open interviews with process collaborators where the interview focuses on roles and responsibilities, not on the process, we aim to identify issues the collaborators have faced in the past or consider possible to occur now or in the future, within a certain stated time horizon. We avoid talking directly about the process because this tends to reduce the scope, which initially should be as wide as possible. Note that some risks do not directly relate to process;
2. Identification of issues related to process: only in a second phase we interview in a closed manner, where we take the participants through the process and consider what can go wrong within each step of the process. We often combined this with process mapping. Rather than using existing process descriptions, we ask the participants to explain how they execute their activities in reality. It is our experience that there exists a significant difference between what is written on paper and what is actually done in reality when considering processes.
3. Identification of issues in support activities: issues can occur in support activities that may significantly impact the activities under review. Consider for example the impact of errors in recruiting, or late budgeting. In order to identify these issues, we conduct joint interviews between process owners of the process under review and owners of the support processes.
4. Identification of contextual issues: A process happens in a context, in a reality. To understand how that reality influences the process, we need to get information on issues in that context that may impact the process. Think for example a highly regulated environment, where you need input from legal experts on how that regulation will impact specific processes. Production yields, for example, may be directly or indirectly influenced by factory emmission norms.
5. Issue clustering and consolidation: these interviews yield a lot of issues. A relatively small assessment I was involved in yielded 800 potential issues, with some other exercises yielding well above 1.000 issues. Of course, an important number of these issues are reflections of the same underlying risk. We cluster similar issues and try to consolidate them in risks, supported by a description of those risks.
6. Structuring of risks: Once risks have been established with related risk descriptions, we start structuring them. Structuring makes a groep of risks into a risk identification model, with the structure allowing for easier consultation of the model. I like structures with two levels: the first level distinguishes by category, linking risks to where they can occur. My models typically have risks related to the environment (contextual risks), risks related to the actual activities (operational risks) and risks related to the available information about the activity and the decisions made based on that (decision making risks). This, by the way, is based on a model Andersen developed in the late 1990’s. A second level is clustering of risks per type. I will often cluster risks depending on the kind of risks they are: there are risks related to human resources, risks related to process quality, risks related to ICT …
7. Validate the structure: once the initial risk identification model is complete, we have the process owners and all other stakeholders validate it. As they will be using a risk trigger list based on this risk identification model, they need to see that model as representative of what they have offered as information during the interviews. During the validation phase, we typically go through a number of iterations to get it right.
8. Developing the risk trigger list: each risk in the risk identification model needs to be presented by a word, an image, a phrase which will trigger associative thinking about a risk. I find that while a risk identification model may be generic to an industry, the risk trigger list is highly specific to the organization because it needs to use the vocabulary of the organization. Each risk is “translated” to the risk trigger list and finally the whole is validated by the owners.

Examples from other areas

I will be posting a number of risk trigger lists to this blog in the coming days. I need to render them anonymous first and get them translated to English, since most of them are in Dutch or French. However, if you want to see a really functional risk trigger list in action, look no further than the “Incompletion Trigger List” David Allen proposes in his book “Getting Things Done”. It is a good example of a list of ideas that are aimed to trigger associative thinking to make you think about what else needs to get done.