Risk Identification

Introduction and relevance

In all areas of management and projects, it is crucial to be aware of the risks that may affect the outcome of objectives. Identifying what could go wrong, delay or even completely terminate a project is the initial process of risk assessment, and a part of risk management. Identification of risks is important, because once a risk has been identified, the risk can be dealt with. Non-identified risks are much more likely to have significant consequences for a project, because no action to mitigate, prevent or make a plan B can be done. However, complete information is never possible, meaning that unforeseen risk is always a threat. But by applying the correct methods, using and involving the right people, risks can be identified, and later handled in the risk management.

Definitions and context

Risk identification is defined as “the process of finding, recognizing and describing risks”. The goal of risk identification is to analyze what might happen, or what situations may affect outcomes or deliverables in a project. When a risk is identified, it is possible to identify any existing controls such as people, systems, design features and processes. These controls are important in the later stages of risk management, as they are the key to influence the risk. Risk identification can be split into the following sub-processes:

Risk description

A detailed description of the identified risk. Should include its sources, events, causes and consequences, explained in the following sections. The risk description is crucial tool for managing risks, allowing the manager to get detailed information about a specific risk.  

Risk sources: The element(s), which can result in a risk. It can be a single element, or a combination of several. They can have different strength, meaning that a risk can have many sources, but some may be more dominant than others. The source may be tangible or intangible. An example of an element could be weather conditions in a construction scenario. One element could be rain, another a storm. In rainy conditions, some building activities may have to be stopped, while a thunderstorm will bring the construction to a complete halt. Both, in a different degree, will cause delays to the construction. In conclusion, weather conditions could be a risk source. Weather is a risk that cannot be directly controlled, but might give rise to considering the advantages of different construction phases for different seasons.

Event: Occurrence or change of a particular set of circumstances, also known as an “incident” or “accident”. An event can have consequences, negative or positive, but an event can also be something not happening. If nothing happens from an event, it can be labeled as a “near miss”, “near hit” or “close call”. Some events can trigger more than once, and have one or several causes.

Hazard: A risk in the context of risk identification and management usually refers to a risk for the project or organization. A hazard is a risk that involves physical harm of people in the project or organization. A hazard can also be a risk source, and may have additional consequences in addition to the physical damage on employees or stakeholders. In the risk identification process, hazards and risks should be distinguished, allowing a focus on safety. Ethically, hazards should have priority in the management of risks, but that is not always the case.

Consequence: Outcome of an event, which affect objectives - An event can have several consequences. A consequence is usually associated with something negative, but in risk management, a consequence can affect an objective in a positive or negative way. Consequences can vary from a small delay to injury of personnel or termination of the project. In the end, risk management is about reduction, prevention and preparation for negative consequences of events. Therefore, identification of those consequences is vital for risk identification

Risk owner: Person, group or entity with accountability and authority to manage a risk. By identifying the risk owner, it is easier to handle the risk in later stages of risk management. Communication and cooperation can easier take place when the correct connection and responsibilities are established.

Context of risk identification: Risk identification can be done as standalone process, but it is close to useless if it is not followed by additional risk management processes, such as risk analysis and risk treatment. Therefore, it is important to carry out the risk identification while being aware of its context: a part of risk management. Risk identification should be seen as the first step in protecting the project or organization against unwanted events and their negative consequences.

Application of risk identification

Risk identification should be used when a project or organization faces unknown entities in their operations. It can be argued, that this is always the case, because there is a risk involved in being active in our society. It is always recommendable to be aware of risks, and try to identify them. But to initiate a complete risk identification, followed by risk management, is only recommendable for operations with a certain degree of uncertainty. Projects are a good example, as they are partly defined by their uncertainty. The scope should also be considered. Short, uncomplicated projects may have less need for a risk identification process, while it would be organizational suicide to do a mega-project without risk identification. Especially in smaller projects, it will come down to a matter of resources and prioritizing. Risk identification should never be completely ignored, but can have a lower priority in small-scope operations and projects.

Risk identification methods

Different methods for risk identification exists, each having strengths covering a certain area. The process should include as many methods as possible, to find the most risks. The more risks associated with a project, the more methods will be necessary to cover them all.

Brainstorming The most basic of methods, which has its strength as an initial method. During a brainstorm, quantity is central, and whatever risk comes to mind should be mentioned. The quality and relevance of the identified risks is not important at this stage. It is not allowed to comment on any suggestions, yet. After a set amount of time, the idea phase closes, which should result in a large number of risk associated with the given project. Now, each suggested risk can be debated, and it can be decided what risks are worth keeping for further analysis, and which should be discarded. If an identified risk is discarded, because it is concluded that it is not relevant, it will not be part of risk management later. Therefore, it should only be discarded if the identifier(s) agree that it will be a waste of resources to handle the risk at a later stage. To avoid that important risks are removed from the list of identified risks, it might be worth it to appoint a “devils advocate”. It is the job of the devil’s advocate to defend all risks from removal from the lists, with sane arguments of course. It also opens for further debate of the individual identified risks. The brainstorm excels at finding the obvious risks associated with the projects, but may lack in-depth analysis of some of the other tools. The brainstorm is recommendable for any risk identification process, because of the large amount of ground it covers, with minimal effort.

Evidence based method Identification of risks based on historical data and experience. The methods consists of finding similar organizations, projects or tasks, and review them. What went wrong and why, and what went well and why. The method includes analysis of heavy empirical and statistical data, to qualitative statements and interviews. The essence is to learn from the past in any way possible, in order to improve risk identification, and in that way avoid unwanted events and negative consequences. This method may require a lot of resources, because of the amount of potential data. It is most suited for projects which can be related to other projects, and not completely new ventures, because a certain amount of evidence is required. However, even by moving into relatively unknown territory, there will always be some aspects, organizational, technical or human, which will relate to previous experiences. A good example is the NASA space program, which constantly evaluate its own performance, especially when something goes wrong. If a risk has not been identified, but triggers an event, it results in learning and improvement.

Systematic team approach

Inductive reasoning techniques

Conditions for optimal risk identification

Use of a group

Diversity of the group

Involving stakeholders