The HAZOP method has been around for decades, since Trevor Kletz and his farsighted colleagues at ICI developed the technique in the 1960’s. So you might think all the bugs would have been pretty well worked out by now, and that HAZOPs would run like the proverbial well-oiled machine.
But HAZOPs aren’t machines. You can’t just push the “start” button and off they go on their own. HAZOP is a people process from start to finish. People are needed to plan and organize them, to lead and participate in them, and to report them intelligibly afterwards.
And like any kind of activity that depends on people at every step in the process, things can go wrong at every step in the process.
Forewarned is forearmed. In this blog, RiskCom will examine a few ways that a HAZOP can go off the rails before the workshop even starts, and what can be done to keep things on the straight and narrow.
In Part One (this post) of 13 Practical ways to sabotage your HAZOP, we examine how things can go wrong before the workshop even begins.
In Part two of 13 Practical ways to sabotage your HAZOP, we turn to saboteurs’ tactics once the workshop is actually underway.
The Facilitator has a lot of work to do (the “prep,” usually underfunded) before the workshop even starts. This is the time to get things right. You don’t want to be taking workshop time to fix things that should have been sorted out in advance.
This wastes time and money (bad), and makes you look inept (worse).
We’ll walk through six all-too-common problems caused by inadequate preparation.
What’s the “right” size for a node? As with many aspects of HAZOP, there is no “right” answer. In the early days of HAZOP, nodes tended to very small. This made for a very thorough analysis, but it also caused the workshop to become very long and tedious, leading to complaints about “HAZOP’ing pieces of pipe” and the like.
Today, nodes are defined as sections of the process that have a single process operation (react, separate, heat, cool, circulate, collect, receive, compress, remove, etc.) Typically, they will include a major process vessel, along with the major lines entering and/or leaving that vessel.
In the final analysis, the definition of nodes is a subjective process that depends on the Facilitator’s experience and personal preferences.
The nodes need to be large enough to be interesting, but not so large that they become hard to manage causing important issues to get lost.
It’s a judgment call – and that’s why we have Facilitators, to supply that judgment and the expertise that goes with it.
Have you ever been in a HAZOP workshop where a large room was filled with twenty, twenty-five, thirty, or even more participants? Probably.
Did you find that everyone in the room participated, paid attention, and made a useful contribution? Probably not.
What usually ends up happening is that three to five people do most of the talking. The other people sit mute, check their email, or work on other projects. If you’re lucky, they’ll only distract themselves. Most of the time, you aren’t so lucky.
What about the other extreme – where only two or three people show up for the workshop?
The reason you have a team in the first place is that no one person knows everything that you need to know to have a successful workshop. If only two or three people show up, chances are that some of the essential knowledge that you need won’t be there.
So what’s the “right” number of participants?
Usually, about six to eight persons (not counting the facilitator and scribe) will be required to ensure that all aspects of the design and operation are covered.
If the team is very much bigger than that, the Facilitator will be too busy trying to keep everyone focused and getting the shrinking violets to contribute.
If the team is too small, things will get missed, or there’ll be too many questions that no one in the room is able to answer.
You can have the right number of people in the room, but it doesn’t count for anything unless you have the right knowledge. The HAZOP team should include, at the very minimum:
- Process design
- Independent process engineer – not associated with the project or plant. Essentially a disinterested party.
- Controls / instrumentation
- Mechanical / rotating equipment
- Project engineer – coordinating the workshop, booking the room, notifying the attendees, and in general making sure that everything happens smoothly and on time
Other skills that may be required depending on the size and scope of the HAZOP include:
- Mechanical / vessels
A good facilitator has specialized training and years of process engineering and facilitation experience to draw on. It would be nice if the same was true (albeit to a lesser extent) of scribes as well.
Too often, however, this is not the case.
Scribing is often considered to be a “hey you” job – “Hey you, we’re having a HAZOP starting tomorrow, and you’re scribing.”
This is a particular area where I have especially strong feelings. A good scribe is a pearl beyond price, while a bad scribe is a handicap almost beyond redemption. In general, there are two types of scribes:
- The Administrative scribe takes dictation from the Facilitator
- The Technical scribe can follow the conversation and proactively record the discussion in the worksheet, so that the team can see it in “real time” to review and revise as necessary.
An Administrative scribe, who just sits and waits for the Facilitator to tell him/her what to type, brings no value to the workshop.
On the other hand, a competent Technical scribe can do almost as much as the Facilitator to make the workshop run smoothly.
It is inefficient for a HAZOP to consider every possible scenario that the mind of man can devise. Some scenarios are so unlikely to occur that they can safely be regarded as not credible. Examples include:
- “Double jeopardy” situations, where a hazard scenario requires two or more independent simultaneous failures, are not considered. These situations are properly considered in a fault tree analysis (FTA).
- Failures of safeguards are not a deviation or a cause of a hazardous scenario.
- Inadvertent opening / closing of valves is not considered if valves are locked open or closed.
Regardless of what scenarios you choose to include or exclude:
- First, agree on the scenarios before the workshop begins,
- Second, stick with them during the workshop, and apply them consistently.
The HAZOP Terms of Reference document is a useful place to define these scenarios.
Which brings us to …
- The scope of the HAZOP – which areas will be included, and which will not
- The methodology summary, including the deviations that will be used
- The node definitions and boundaries
- The risk matrix that will be used, along with the definitions of the severity and frequency terms
- The workshop schedule and location
- A list of not credible scenarios
- Any other key assumptions that will be used
When possible, the Terms of Reference (ToR) should be a formal document, issued, and agreed to, ahead of the workshop. Most of the ToR can be incorporated, with minimal changes, into the HAZOP report after the workshop is finished.
So now you’ve got a good Terms of Reference, you’ve got a first-rate facilitator and scribe, and you’ve got your team lined out so that all the right people are there.
In the next installment, we’ll turn to the ways that your HAZOP can go wrong once the actual workshop starts.