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?
Great post. From my personal experience in the aviation industry and leading different aircraft teardown projects there are always different risks that come up- some expected, some not. I think it’s very important to include people with expertise, as well as, “rookies” or people outside of the project. Also, including people with varying backgrounds is important (ex: finance, purchasing, sales, operations, etc). As far as tips to add on how to improve risk identification, it may be a good idea to keep a journal of “wins/losses” from past projects. These may be similar projects to the one you’re currently working on or projects that are completely different. When you start a new project you are then able to look back on what previously worked and didn’t work. It also helps you to remember little details that you may have forgotten about and have the potential to come up again. Learning from past mistakes is always a good way to improve risk identification.
You know, this is actually a bit of a revelation for me. I mean, when crafting a product for someone to use you’ll always want to make sure you have both experts and non-experts test it, but I never really considered taking that same approach within the setting of risk identification. It’s actually a really great idea. Even if you have a roomful of subject matter experts with different backgrounds, having that level of expertise may blind you from a viable possibility that you “know hasn’t ever been a problem.”
I think that, in addition to experts and non-experts, you’ll also want to consider a blend of experience and high rank with inexperience and low rank. The people in the trenches will see different risks than executives might, but executives will have had the background and the strategic scope to be able to connect dots that low-to-mid-level employees may not. Of course, you’ll want to make sure you’re inviting people with relevant backgrounds to the meeting, too, experience or no. Nevertheless, yours is a fantastic suggestion, and I’m walking away from this article with some good notes for both project work and personal work.