HAZOP Analysis for Process Engineers: How to Run One That Actually Catches Something

After 13 years in process engineering, I’ve participated in over 50 HAZOP studies. I’ve seen HAZOPs that caught near-misses before they became incidents, and HAZOPs that were expensive box-ticking exercises. The difference between them isn’t the methodology — everyone uses the same guide words. The difference is three things: the facilitator, the node boundaries, and what happens after the meeting.

This article covers what makes a HAZOP actually work, from someone who’s been on both sides of the table.

What HAZOP Actually Is

HAZOP (Hazard and Operability Study) is a structured, systematic examination of a process design to identify potential hazards and operability problems. It’s governed by IEC 61882, and it’s the most widely used process hazard analysis method in the chemical, oil & gas, pharmaceutical, and lithium battery industries.

The core idea: Break the process into nodes, apply guide words (No, More, Less, Reverse, etc.) to each parameter (flow, pressure, temperature, level), and ask: “What can go wrong? How bad would it be? How do we prevent it?”

When HAZOP Is Required

Trigger	Requirement	Standard
New process plant design	HAZOP during detailed design (before IFC)	Company standard / PSM
Major modification	HAZOP on modified sections	OSHA PSM, SEVESO
Existing facility (unstudied)	Retrospective HAZOP	Insurance requirement
MOC threshold exceeded	HAZOP or What-If per MOC policy	PSM element
5-year revalidation	Re-HAZOP or checklist review	OSHA PSM

HAZOP vs. Other PHA Methods

Method	When to Use	Pros	Cons
HAZOP	Continuous processes, complex piping & instrumentation	Exhaustive, systematic	Time-consuming, expensive
What-If	Simple processes, minor changes	Fast, flexible	Easy to miss scenarios
FMEA	Equipment-focused, mechanical failures	Quantitative (RPN)	Misses process-level interactions
LOPA	After HAZOP, where risk needs quantification	Frequency-based, defensible	Requires HAZOP output
Fault Tree	Top events, complex logic	Quantitative, visual	Requires specialist

The Three Things That Make or Break a HAZOP

1. The Facilitator Is 80% of the Outcome

A good HAZOP facilitator is worth their weight in gold. They are not the smartest engineer in the room — they are the person who keeps the room focused on the right questions.

What a good facilitator does:

• Keeps the team pinned to the guide word. The team wants to drift into design optimization. The facilitator brings them back: “That’s a design improvement, not a hazard. Let’s stay with ‘Low Flow’ — what causes it, what are the consequences?”
• Draws out the quiet experts. Every HAZOP has one person who knows the process better than anyone but won’t speak unless asked. The facilitator actively asks them: “You’ve been running this unit for 12 years. What have you seen go wrong?”
• Manages the dominant voice. Every HAZOP also has someone who talks too much. The facilitator diplomatically limits them without embarrassing them.
• Writes quality worksheets in real time. A good scribe/facilitator writes the cause-consequence-safeguard-recommendation in clear, actionable language. No one should need to ask “what does this mean?” three months later.

What a bad facilitator does:

• Lets discussions drift into 30-minute design debates
• Accepts “add an alarm” as a safeguard (it’s not — an alarm is an operator prompt, not an independent safeguard)
• Allows vague worksheet entries like “Check the pump” (check what? How? Against what criteria?)
• Fails to manage the room’s energy (post-lunch HAZOP sessions are notorious for rubber-stamping)

The cost of a bad facilitator: A HAZOP that takes 3 weeks instead of 2, produces a 500-page report nobody reads, and misses the one scenario that actually happens 18 months later.

2. Node Boundaries Determine What You See

HAZOP divides the process into nodes — sections of the P&ID that can be studied independently. Where you draw the node boundary determines what scenarios you catch and what you miss.

Good node boundary principles:

Principle	Example	Why
Process function grouping	Reactor + feed/effluent lines up to isolation valves	Keeps functionally related equipment together
Use natural isolation points	Block valves, equipment flanges, battery limits	Clear scope — no ambiguity
Include utility connections	Cooling water supply/return within the node	Utility failures affect the process
Include instrument connections	Sensing lines, purge connections	Small-bore connections are major leak sources
10-15 P&IDs per node maximum	—	Manageable scope for a half-day session

Common boundary mistakes:

• Drawing boundaries at equipment nozzles only. This misses the piping, instruments, and connections between equipment. A node should be “from isolation valve to isolation valve” or “from equipment A discharge to equipment B inlet.”
• Making nodes too large. A node that spans 30 P&IDs can’t be studied effectively in one session. The team gets fatigued, scenarios blur together, and the afternoon sessions become rubber-stamping.
• Making nodes too small. If every pump and its immediate piping is a separate node, you spend more time managing node transitions than finding hazards. You also miss interactions between closely coupled equipment.

3. What Happens After the HAZOP (The Real Failure Point)

Most HAZOP recommendations die in the tracking spreadsheet. They’re assigned to engineers who weren’t in the HAZOP room, who don’t understand the context, and who have 47 other action items.

How recommendations die:

Death Mode	Example	Prevention
“Not my problem”	Action assigned to wrong discipline	Assign during HAZOP, with the person in the room
“What does this mean?”	Vague action: “Review pump sizing”	Write specific, measurable actions
“Too expensive”	Cost estimate was never obtained	Include rough cost estimate with recommendation
“Forgotten”	Action buried in a 500-item tracker	Monthly review meeting, escalate overdue items
“Doesn’t apply anymore”	Design changed, action became irrelevant	Link actions to P&ID revision numbers

My recommendation tracking approach:

1. Every action gets a one-sentence consequence statement written by the person who raised it. Not “Install pressure transmitter on discharge line.” Rather: “Install pressure transmitter on P-1001A discharge line to detect dead-head condition. A dead-headed pump operating for >2 minutes will overheat and fail, causing loss of production (8 hours downtime, $50K).”

2. Actions are categorized by risk reduction, not by discipline. Category A: must close before commissioning. Category B: must close before startup. Category C: should close within 3 months of startup.

3. Monthly HAZOP action review meeting. 30 minutes. Review overdue actions only. The HAZOP facilitator chairs it. The project manager attends.

HAZOP Preparation Checklist

Before you schedule the HAZOP sessions, verify:

• [ ] P&IDs are at HAZOP quality. This means: line numbers, instrument tags, valve types, materials of construction, and design conditions are shown. “To be confirmed” on a P&ID = “we can’t HAZOP this yet.”
• [ ] Heat and material balance is complete. The team needs to know normal flow rates, pressures, and temperatures to assess deviations.
• [ ] Equipment datasheets are available. Relief valve set pressures, pump curves, vessel design pressure/temperature — the HAZOP team needs these.
• [ ] Cause-and-effect matrix (C&E) is drafted. The HAZOP will validate and supplement the C&E; it shouldn’t invent it from scratch.
• [ ] The right people are committed for the duration. A full HAZOP for a medium-complexity unit takes 2-4 weeks of half-day sessions. You cannot do it in 3 full days — mental fatigue destroys quality.
• [ ] The facilitator is independent. They should not be the designer of the unit being studied. Independence matters — an independent facilitator will ask the obvious questions that the designer assumes everyone knows.
• [ ] A scribe is assigned. The facilitator facilitates; the scribe writes the worksheet in real time. Trying to do both reduces quality by 30-50%.

How to Run a Node: The 5-Minute Pattern

For each deviation, follow this strict pattern. Don’t skip steps. Don’t combine steps:

1. Deviation: Facilitator states: “Let’s look at Low Flow for line 6″-PW-A-001-CS1, process water to reactor R-100.”

2. Causes: Team brainstorms: “Control valve FCV-1001 fails closed. Pump P-1001 trips. Block valve upstream is inadvertently closed. Filter F-1001 plugs. Loss of water supply pressure.”

3. Consequences: For each cause: “If FCV-1001 fails closed, reactor R-100 loses cooling. Exothermic reaction temperature rises. At >120°C, runaway reaction possible. Relief valve PSV-1001 lifts. If PSV fails, reactor overpressure → potential rupture.”

4. Safeguards: “High temperature alarm TAH-1001 at 95°C. High-high temperature trip TA H H-1001 at 110°C closes feed valve. Relief valve PSV-1001 sized for fire case and runaway. Operator rounds check FCV-1001 position daily.”

5. Risk assessment: With existing safeguards, is the risk tolerable? If yes, move on. If no — recommendation.

6. Recommendation: “Install flow transmitter and low-flow alarm on 6″-PW-A-001-CS1. Low flow alarms in control room with operator response procedure. Consider automatic start of standby pump P-1001B on low flow.”

Common HAZOP Mistakes

Mistake 1: “More Instrumentation” as a Reflex

The most common HAZOP recommendation is “add a [transmitter/alarm/interlock].” Sometimes it’s needed. Often it’s lazy analysis.

Before recommending more instrumentation, ask:

• Is there already a safeguard for this scenario? (Check the C&E matrix before adding a duplicate)
• Can the existing safeguards be improved instead? (Better alarm rationalization, more frequent testing)
• Is this an inherently safer design change instead? (Replace the hazardous material, reduce inventory, simplify the process)

Mistake 2: Not Considering Multiple Failures

HAZOP traditionally considers single deviations. But in the real world, things fail together. A power failure causes pump trips AND instrument air loss AND control system degradation — multiple deviations simultaneously.

Solution: After completing the single-deviation HAZOP, dedicate 2-3 sessions to “global causes” — power failure, instrument air failure, cooling water failure, control system failure. These are the scenarios that cause the most severe incidents because they defeat multiple safeguards simultaneously.

Mistake 3: Assuming the Operator Will Save You

“The operator will notice and respond” is not a safeguard. It’s wishful thinking.

Operators have competing priorities, alarm floods, and human reaction times. A safeguard that depends entirely on operator action needs:

• A clear, unambiguous alarm (not one of 50 alarms on the same panel)
• A documented, trained response procedure
• Sufficient response time (typically >10 minutes for non-critical, >2 minutes for critical)
• Periodic drill verification

If any of these are missing, the operator response is not a safeguard — it’s a hope.

Summary

A HAZOP is the last systematic chance to find a design error before it becomes an incident. But it only works if:

1. The facilitator is skilled and independent — not the designer checking their own work

2. Node boundaries are thoughtfully drawn — not convenience-based

3. Actions are tracked to closure — not left to die in a spreadsheet

4. Multiple-failure and utility-failure scenarios are covered — not just single deviations

5. Operator response is validated — not assumed

The HAZOP report is not the deliverable. The closed actions are the deliverable.

---