This is the third in a three part series on process hazard meetings, such as HAZOPS, PHAs, What-Ifs, Checklists, and HAZANs. Part 1 introduced the concepts. Part 2 discussed meeting attendees and preparation. Part 3 will provide advice for running the meeting smoothly.
In Part 1 we saw what makes up a hazard meeting and how to fill out the meeting worksheet, and in Part 2 we met the attendees and learned how to prepare for meetings. In part 3, below, I will provide some subjective advice on how to run a good hazard meeting, and warn you about the most common pitfalls.
For this post, like Part 2, we again will be focusing on large safety meetings that involve a dedicated facilitator, and possibly two or more companies or divisions collaborating to implement a project. For minor work in operating facilities, the meeting may be a handful of people who work together every day, and so these problems are less prevalent.
The advice in this post is ideally directed at the facilitator, but anyone can pick up the ball and save a meeting. Anyone can chirp up to get the meeting back on track. I have sometimes seen project leaders come to the rescued of floundering facilitators this way.
At the start of the meeting, clearly explain the hazard meeting process, and the detail level and scope of your meeting
You would be surprised how often this is an issue: people cannot agree on why they are here. People keep getting bogged down in nitty-gritty details during a preliminary design review, or do not dig deep enough into the issues in detailed reviews. Although the facilitator and project leaders have an understanding of the level of detail they want, the rest of the meeting does not.
Part of the solution is to schedule time in the meeting, right up front, to define what the meeting is about and what it’s not. The facilitator needs to make this clear and keep people on track. The project leaders should pitch in and help with this, supporting the facilitator. The meeting needs a clear scope.
However, try to just do this explanation once. I’ve literally seen hours go by where people try to redefine and re-affirm the purpose of the meeting. A waste.
A hazard meeting is not a design review
With so many people around the table, there may be a desire to talk design issues or change the design. This is especially true in meetings at the early stage of design.
Resist this. The fundamental assumption of a hazard meeting has to be “we are assuming that this system is competently designed and will work as shown. We are only here to analyze hazards and deviations.”
If a brilliant design idea does accidentally come up during the meeting – and that’ll probably happen – you can include it as a recommendation anyway with a caveat that it’s a design and not a safety recommendation. Or even better: make a “design list” or “parking lot” of ideas to be studied that aren’t strictly hazard details. Keep this list separate from the hazard meeting worksheet.
Blabbermouths (people who talk too much)
Sometimes there is someone in the meeting who just loves the sound of their own voice. They may be a know-it-all. Or, they may have low self esteem or feel under attack by the very idea of a safety meeting, and need to expound on how safe and well-done and well-proven the design is. Or they may constantly repeat a mantra about how many years they’ve safely operated this plant and how this meeting is a waste of time. Whatever.
It is expensive to have all the project leadership sit around the table listen to this. Someone – anyone – ask the person to try to boil down what they’re saying into a succinct point. “Help the poor scribe out: what specifically do you want to see written down on the worksheet?”
Relentlessly re-focus the effort on filling out that worksheet!
The Dead Crowd (people who don't talk enough)
This is the other side of the coin. Sometimes hazard meetings have almost no one contributing. The meeting becomes a painful pulling of teeth. Usually one experienced person from the design team will reluctantly step up to the plate, and you end up with a slow back-and-forth between them and the facilitator while everyone else sits in silent, agonizing boredom.
There are several possible reasons. If it’s fear of speaking out, remind everyone that this is really a brainstorming session of possible hazards. It’s OK to suggest a deviation, even if you think it may have already been thought of or think it may “sound stupid.” If that happens, then everyone around the table is going to discuss it and then conclude as a group “yes we do have that handled, good” or find out that they missed it. Do whatever can you to defuse the risk of embarrassment.
Some groups act like the facilitator is going to carry the meeting solo. This is a misunderstanding and it’s not their role. Don’t let it happen.
Most often it is boredom or lack of engagement. Hazard meetings can be very dull, especially if you are one of the meeting attendees who are rarely being called on. I have heard (true) stories of people literally falling asleep during hazard meetings!
For yourself, watch yourself, and “wake up” if you start drifting. Maybe taking notes of your own would help keep focus. If you see other people in the meeting dying away, engage them: “hey Frank, can you see anything we missed here?” When the meeting flags, do something to inject energy back in the group. Be engaging.
The facilitator can run through the list of common deviations verbally, like a coach or a drill sergeant, asking: “High/low/no/reverse flow. High/low pressure. High/low temperature. Come on people, are these sparking any ideas?” You may want to hand out a list of keywords/deviations before the meeting, so people can thumb through it when they’re stuck.
Lastly, you could consider an early break or early lunch if people are really fading. Maybe you can recapture the momentum after a break. People can’t think when they need to use the bathroom or haven’t had their morning coffee.
A design that’s not ready
In general, a well-designed project schedule will include whatever hazard meetings are considered necessary and desirable, they will be given ample time and they will be scheduled to occur after key steps in the process have occurred. For example, you might have one hazard meeting when PFDs and early P&IDs are ready, and then other hazard meetings down the line.
The facilitator is called in, told this, and is given the P&IDs. But uh oh – two days later, they’re given changes that were just finished yesterday. And then more changes. And there are huge “hold clouds” all over the P&IDs where sections haven’t been designed yet. And no one knows what chemicals are being used in the skid package. And key vendors haven’t gotten back to us yet…
You can’t do a hazard meeting in this environment. You need a “frozen” set of documents for the meeting, and these documents must be done to a level of detail that supports the hazard meeting you are trying to accomplish. If things are in constant flux or grossly under-defined, call the meeting off, or only do the most complete and stable areas. Wait until there is enough clarity in the design to have some stable facts to analyze.
Sometimes you run into problems because document revisions are too rigorously defined: Rev C is hopelessly out of date, “but according to our procedures Rev D has to include certain details that won’t be ready for 3 months.” To get around this, you can usually issue something with the marker “in progress – for hazard meeting.” E.g. stamp the latest drawing “Rev D In Progress - Issued for PHA” and keep that separate from whatever the final Rev D will be.
A fight at the table
If you get into a discussion about how safe something is, or some other fact, sometimes it is healthy. But sometimes it gets out of hand, turning into a battle of wills or personal attacks, and you need to cut it short to save time or just to keep things civil. Capture it as a compromise recommendation like “ensure fact XXX” or “ensure YYY is safe for this service and redesign if necessary” and assign responsibility to one of the warring parties. Outside the meeting, they can hash it out with the other person and resolve the recommendation one way or the other. You’re not ignoring the problem; you’re just not letting it eat the entire meeting up.
I have been pleasantly surprised: usually assigning responsibility to recommendations is not too hard. But sometimes people try to get out of it. Remind them: assigning responsibility tightly (to just one or two people) assures that someone is constantly trying to move this issue along. It does not mean they have to go it alone. In fact, you can assign responsibility for something to the mechanical lead, and then after the meeting he assigns it to some junior engineer who entirely takes care of it. That’s completely fine. The responsibility just ensures someone starts the ball and keeps it rolling.
An analogy is Volleyball: you know how the ball can fly in between the position of two players? If no one calls it, sometimes the ball lands between them uncontested “because the other person should have got it.” Or both people go for it and get in each other’s way. If one person "calls it" (i.e. declares that hitting the ball is their responsibility), that’s almost always better than no one calling it. And if necessary, the person who called it can redirect the ball to their teammate to ultimately put it over the net.
Not enough time for the meeting
This is the common. Sorry. 🙁 For a start, schedule the time you do have effectively. Make a plan that can plausibly work. If you start slipping from your schedule during the meeting, point it out, and motivate the group to move faster. Use the tips above to resolve the common lags. Use the list of recommendations aggressively, to cut off discussions and ensure any lengthy debates occur outside the meeting hours.
Try to have coffee, water, and lunch available at the meeting site. Then you won’t have people getting stuck in a restaurant during lunch hour.
Here’s a scheduling secret: normally the first morning will go much slower than the rest, because everyone is getting used to the hazard meeting process, and to each other, and therefore feel uncertain. So you can budget the more time on the first node to compensate. Or, to be sneaky, budget a “normal” amount of time for the first node. Then you won’t meet your schedule for Node #1, and can use this fact to scare people into moving quickly through the rest of the meeting. After the first node, or after everyone’s eaten lunch together the first time and loosened up with some non-business chatting and small talk, things usually pick up.
Sometimes meetings do go long. You should never plan for this, but sometimes people decide it’s preferable to stay an extra hour rather than try to get so many people’s schedules free again in the future. (In a few cases people decide to stay an extra hour so that they can finish off the meeting a day early! Lucky them).
In the worst case, you have to defer things to a future meeting. Drop the least developed part of the process, or move a node into a future meeting, skip some general issues like storms, etc. The utilities and off-sites section may represent a convenient section to defer.
But don’t lie. Don’t have the facilitator fill out the final node alone in the bathroom after the meeting. This is a safety exercise after all. Treat it with some integrity.