Of the four steps of the risk management process that we discussed in class, I find the first step, risk identification, to be the most important and intimidating. The scary part about risk is the surprise factor. It seems that most failures stem from the unforeseen problems. Therefore it is vital to determine the best way to identify all risks upfront so that they can be avoided.
The little experience I have with risk analysis is from participation in hazard and operability (HAZOP) sessions for process equipment that my company designs. Although I have only participated in a few sessions, the format of the HAZOP sessions left a lasting impression. During a session, there is one HAZOP expert that leads the meeting and, oddly, might not even be familiar with the system or how it operates. All of the other attendees usually have more knowledge about the system and how it should and could operate. After looking at a flowsheet of the system, the HAZOP expert dissects the system and defines certain “nodes” which allow for isolation within the system. From there, each node is evaluated through a set of standard possible upset conditions. It is a laborious process because each node must be evaluated at the same set of possible upset conditions even though the possibility of an occurrence could be nonexistent.
The approach used for HAZOP is similar to the Risk Breakdown Structure (RBS) that we discussed in class. If you can break a project up into tiny pieces and apply a standard set of thought provoking questions or scenarios, it will help in revealing risk. For me, I always got some enjoyment when a risk was found from what originally seemed like a nonsensical situation. Without the systematic approach of running each node through the same conditions, the risk would have been limited to what we imagine would happen based on previous experience. By having an outsider trained in risk assessment lead the group through the thought exercises, the questions asked were not bound by the bias of the engineers.
Based on my experiences with risk identification, I suggest including a variety of team members and non-team members when brainstorming the potential risks of a project. It is important to have both experts and non-experts on the project. Also, never feel like a question or potential scenario is not worth mentioning. You might find that the likelihood of the risk occurring is greater than you imagined or the question/scenario might spark an idea that reveals another risk.
Do you have any advice or tips to add on how to improve risk identification?