Knowing how to identify risks


When in spring 2020 most countries imposed a lockdown to tackle the onset of the Corona pandemic, plunging a lot of companies into economic problems, it was often said that “nobody could have foreseen this crisis!“. At the same time, there are plenty of standards and legal requirements providing the framework for companies to anticipate risks and threats and to take adequate precautions. But none of the existing guidelines has so far helped to answer the question of how a company can spot all relevant risks.

While there is no universally valid answer to this question – and probably never will be, still a couple of tried and tested useful devices and methods can help recognise risks.


A classic and widespread approach to risk identification is brainstorming. It is a simple question like: “What could happen if …?” that will give you enough information to fill your risk register. As, however, the number of identified risks will depend very strongly on the experience and the perspective of the involved person in question, you should remember two things if you intend to reach good results using this method:
First, you should bring together people with backgrounds as diverse as possible. The involved people’s feedback will be strongly influenced by their individual experience and preferences, particularly when it comes to identifying possible risks. If you engage a great range of different participants, their feedback will reflect this diversity, too.

Second, you should guide the debate during the brainstorming in different directions. Here various approaches will be useful, for instance 4Ss or 5Ms or PESTLE.

Process Analysis

Another way of facilitating the group process while identifying risks is process analysis. Here you first divide your project into clearly defined smaller, separate units of activities. For each unit you then think up risks that might occur and analyse how they might affect your target achievement.
This approach is ideal if your project consists of a sequence of clearly defined process steps and if you can easily show how the actual activities correspond with the final result. If, however, your task is more complex or if mulitple interdependencies are involved, this approach, which in fact very much resembles the design tool FMEA, is less suitable as it is extremely difficult to assess risks with it.

Case Studies

A third approach is investigating reference cases. Here comparable projects and ventures are scrutinised for unforeseen events and the impact they had on target achievement. To identify a valid list of risks in this way, you have to make sure that you have a sufficiently high number of past cases. Also, you should check if the found risks are relevant for your case in question.

We recommend this technique of recognising risks for situations in which you regularly carry out several rather similar tasks or projects – for example if you have to make adjustments to machines according to your client’s wishes or if you design software modules for a plant control system. Here you can detect standard risks relatively quickly and take measures appropriate to the corresponding project.
This method is less suitable, however, for situations with few or no reference cases. Further, this approach is unfit to consider novel hazards or rarely occuring extreme events.

Pre-Mortem Session

To take such extreme events into account, you should make use of so-called “pre-mortem sessions“. Here the team in question imagines that their project has already been completed and tries to come up with reasons for the project’s presumable failure.

At first glance this approach seems hardly different from the brainstorming method detailed above. However, the change of perspective, shifting from thoughts like: “What might happen?” to the hands-on question: “What has caused the failure?” will help to change your set of mind and explore new ways of thinking. This is particularly useful to identify those risks that are different to those people have encountered so far.
Which approach will you be using to spot risks in your next project?