“Watching two engineers argue is like watching pigs wallow in mud. Eventually you figure out that they do it because they like to.” — Anonymous
I’m still learning better ways to do HazOps. And since there are better ways, then what I am doing now couldn’t possibly be the best. So, what is the RIGHT way? It’s a way that achieves the objectives of a process hazard analysis: identify hazards, identify safeguards that are in place, recommend additional safeguards when necessary, and do it all as quickly and efficiently as possible.
There are certain questions about how to do HazOps that come up over and over. While there are certainly wrong ways to do HazOps, there are probably as many right ways to do HazOps as there are facilitators. Yet, we still argue.
A Pig Wallow
When a HazOp teams includes members with different experience with HazOps, any of three arguments frequently come up. The first is about how to break the process into nodes—large or small. The second is about the list of deviations the HazOp method uses to identify hazards. The third is about the correct place in the HazOp documentation to discuss specific causes or consequences.
An unseemly amount of time can be spent haggling over the answers to these questions when the personnel involved in the argument are obstinate engineers who are more concerned about the pleasure of being right than in identifying hazards, and especially when one of the people arguing is the facilitator. In these circumstances, the HazOp can turn into a real pig wallow, much to the dismay of the others in the room who aren’t participating in the argument.
I won’t pretend to settle these questions. But I am going to attempt to explain the approach that I take and teach others to take, and hope that the explanations will at least make sense.
Breaking the Process into Nodes
There are generally two schools of thought on HazOp nodes. One is to treat systems as nodes, so that a node may be described by two or more P&IDs. The other is to treat each vessel as a node and each line connecting vessels as a node. The argument for the system approach is that hazards are considered more holistically. The argument for the more granular approach that it allows for sharper focus by the team on each segment of the process.
Facilitators using either approach generally estimate that a review will take about 2 to 3 hours per P&ID, although some estimates a range of 1 to 4 hours per P&ID.
Many years ago, a client shared our curiosity about which approach was “better.” They agreed to review a process twice, once with the system approach to nodes, once with the granular approach. We found that the system approach took about 25% longer and that it missed hazards that the granular approach didn’t. It took longer because there was a greater tendency for the team to talk in circles. The granular approach was also a little quicker because with smaller nodes, it was more likely to find a previously discussed node that could be copied and used as the basis for another node.
Regardless of how it is done, dividing a process into nodes is a task that should be completed before the HazOp team convenes. HazOps should be about fires, explosions and toxic releases, about death and destruction. This is interesting and will keep a team focused, on its toes. Splitting a process into nodes is administrative and should not occupy the attention (or inattention) of the entire team. No two facilitators are going to split up a process identically, whether or not they use the same set of rules. So, regardless of how strong some opinions are, there should be deference to the choices made at the time the nodes were divided.
One recommendation when breaking a process up into nodes is to divide a section of a process into smaller pieces when there is any doubt. It is always easier and faster to combine multiple pieces on the fly during a review than it is to split an existing node into multiple pieces and then set up the additional worksheets for each piece.
The List of Deviations
Another aspect of the HazOp that prompts a lot of argument is the list of deviations. In a HazOp, a deviation is the combination of a parameter—pressure, temperature, flow, level, etc.—and guide words—too much, too little, reverse, other than, etc. It is in the “etc.” where the arguments can occur.
Every facilitator has their own preferred list of deviations. It’s one of the ways facilitators distinguish themselves from other facilitators. Some deviations make everyone’s list: pressure too high, temperature too high, reverse flow, level too low. There are other deviations, though, that can prompt a pig wallow.
We use seven parameters: pressure, temperature, level, flow, composition, mixing, and reaction. We use six sets of guide words: “too high,” “too low or no,” “reverse,” “varying,” “other than,” and “as well as.” We combined “too low” and “no” because we found that either only one applied or that the hazards were no different when one was used instead of the other. Even though there are seven parameters and six sets of guide words, there are not 42 valid combinations. For instance, temperature can be “too high” or “too low”, but “other than temperature” is really meaningless. We use “varying pressure” but not “varying flow”, since varying flow is always directly linked to varying pressure.
Other parameters that occasionally show up include “concentration,” “pH,” and “viscosity,” which we see as expressions of “concentration”. We sometimes see “maintenance,” “operation,” or “sampling” as parameters but don’t use them that way, not because they are unimportant, but because we see them as causes rather than the basis of deviations. Likewise, we sometimes see “vibration” and “corrosion” as parameters, but we consider them consequences rather than deviations.
The thing about a list of deviations is that it must be applied to every node. The longer the list, the more it bogs down a review. On the other hand, if a specific deviation makes it more likely to identify a hazard that would otherwise be overlooked, by all means, use it.
Where to Discuss Causes and Consequences
While discussing a deviation in a node, someone on the team inevitably states, “That cause doesn’t happen in this node,” or “Those consequences are not in this node,” and so there is a hesitation to discuss the cause or consequence while discussing the node. Or within a node, someone will want a hazard associated with a different deviation, such as “Isn’t that really high level rather than low flow.”
Where a hazard is identified and discussed is not nearly as important as that it get discussed.
As a rule, we consider the deviation in the node, but consider causes as a failure anywhere in the process that could lead to the deviation in that node. Likewise, we consider a consequence as an undesirable event anywhere in the process that results from of the deviation in that node.
As for differing opinions about the deviation with which to associate a hazard, we will simply ask, “As long as we capture it, does anyone have strong feelings about where?” If that doesn’t settle the question, then we just list it in both places. Hazards don’t have higher risk just because they are listed twice.
There are Many Ways to Do HazOps Right
Every HazOp facilitator has their own approach to leading a HazOp review. While every facilitator is convinced that their approach is best (after all, if they thought there was a better way, they would be doing it that way instead), the differences don’t really matter as long as hazards are identified and addressed. It is more important for a HazOp team to stay focused on finding hazards than on fighting a rearguard action on the details of HazOp methodology.
Save the Arguments for Another Time
There are arguments worth having. For some, though, the sheer joy of arguing makes every argument worth having. If you know you are one those, temper your need to be right with the need to keep the whole team engaged. Besides a poorly prepared and disorganized facilitator, there are few things that make a HazOp worse for team members than to have to endure arguments over minutia that don’t matter to the goal.
The goals of a HazOp are to identify hazards, identify safeguards that are in place, recommend additional safeguards when necessary, and do it all as quickly and efficiently as possible. If an argument doesn’t contribute to this, if it causes other team members to become disillusioned and disengaged, then it is not worth having. Don’t worry about being right—worry about identifying hazards.
