Introduction
A Hazard and Operability Study (HAZOP) is one of the most widely used process hazard analysis techniques in the oil and gas industry. When done well, it identifies genuinely hazardous scenarios that were not anticipated in design — scenarios that, left unaddressed, could cause fatalities, major equipment damage, or significant environmental harm.
When done poorly, a HAZOP produces a long list of low-consequence recommendations, misses the scenarios that matter, and gives the project team a false sense that hazards have been systematically addressed.
The difference lies in facilitation and preparation. Here are ten lessons from years of leading and participating in HAZOP studies for onshore and offshore upstream facilities.
1. Do Not Start Without a Frozen P&ID
The single most common cause of a wasted HAZOP is starting with P&IDs that are not yet developed. A HAZOP is only as reliable as the design it reviews. If the P&ID is still being revised — instrumentation not placed, control philosophy not finalised, tie-in points not shown — the HAZOP will either be repeated or will miss deviations that only arise from the actual design.
The minimum standard for HAZOP P&IDs is "developed for HAZOP" — issued for review and accepted by the discipline lead as representative of the final design intent.
2. Select Nodes That Match the Process Function
A HAZOP is organised into nodes — sections of the process that share a common design intent. Node selection is a skill. Nodes that are too large generate unmanageable numbers of causes for each deviation. Nodes that are too small create repetition and exhaust the team.
The right node size typically corresponds to one unit operation or a coherent section of piping between major items of equipment. A production separator, including its control loops and outlets, is a good node. The entire inlet manifold, separators, and export system is not.
3. Match the Team to the Hazards
A HAZOP team should include:
- Facilitator — independent of the project, experienced in HAZOP methodology
- Process Engineer — understands the design intent and process behaviour
- Instrument/Control Engineer — understands the control and protection systems
- Operations representative — understands real-world operating behaviour and potential misuse
- Safety engineer — tracks risk register and ensures integration with other hazard studies
Absent team members means absent expertise. A HAZOP run without operations representation consistently misses operability issues — scenarios that are not dangerous in the engineering model but are problematic in practice.
4. Control the Size of the Session
A HAZOP team with more than eight people is inefficient. Beyond eight, some participants are spectators. Others dominate. The facilitator spends more time managing group dynamics than guiding technical discussion.
For complex nodes with multiple discipline inputs, schedule parallel half-day sessions for different sections of the team rather than assembling everyone in one room for five days.
5. Follow the Guide Words — Do Not Skip Them
Guide words (No/None, More, Less, Reverse, Other Than, Part Of, As Well As) exist to structure the team's thinking around each design parameter. Experienced engineers often feel they can skip guide words and address hazards intuitively. They cannot.
The guide word structure is what prevents the team from anchoring on the hazards they expect and missing the ones they do not. A systematic approach finds the non-obvious scenarios. Intuition finds only the familiar ones.
6. Record Causes, Consequences, Safeguards — In That Order
For each deviated parameter, the team should identify:
- Causes — what could lead to this deviation?
- Consequences — if the deviation occurs, what happens?
- Safeguards — what existing measures reduce the likelihood or consequence?
- Recommendations — where are the safeguards insufficient?
Jumping straight from cause to recommendation — without characterising the full consequence chain — produces recommendations that address the wrong problem. The consequence must be understood before the adequacy of the safeguard can be assessed.
7. Distinguish Between Initiating Events and Safeguards
A common error is recording an instrumented safeguard (such as a high-pressure shutdown trip) as a cause rather than a safeguard. The initiating cause is the process event that creates the deviation — a blocked outlet, a failed control valve, an unexpected exothermic reaction. The trip is a response to the deviation, not its cause.
Conflating the two leads to circular logic and underestimates the residual risk after safeguard failure.
8. Do Not Try to Resolve Actions in the Room
When a HAZOP identifies a recommendation, the team's job is to record it clearly, assign an owner, and move on. It is not to design the solution in the workshop.
Engineering decisions made under time pressure in a HAZOP room are rarely optimal. The assigned engineer should assess the recommendation properly — consulting design calculations, checking vendor data, reviewing the control philosophy — and return a response that is technically justified.
An action that says "Provide high-level shutdown on separator V-101" may be the right answer. Or it may be unnecessary if an existing safeguard already provides equivalent protection. The workshop is not the place to make that determination.
9. Close the Loop Between HAZOP and Design
Every recommendation from a HAZOP study should have a traceable response: either a design change (with a revised P&ID revision), a documented justification for no action, or a risk acceptance signed off by the appropriate authority.
HAZOP action registers that disappear into a project filing system — never formally closed, never incorporated into the design — are a regulatory liability and a genuine safety risk. The HAZOP is only complete when every action has a closed-out response that can be demonstrated in audit.
10. HAZOP Is Not the Last Layer of Defence
A HAZOP is a hazard identification tool, not a safety case in itself. The scenarios it identifies should feed into:
- Layer of Protection Analysis (LOPA) — quantifying residual risk and determining SIL requirements
- Safety Instrumented System design — specifying and verifying the SIS to IEC 61511
- Emergency Response planning — ensuring consequence scenarios are covered in the ERP
A HAZOP that generates a long action register but does not feed into a coherent process safety management framework has done half the job.
Conclusion
A productive HAZOP requires preparation, the right team, disciplined facilitation, and rigorous follow-through. It is not a box to tick on a project schedule — it is a structured opportunity to find the hazardous scenarios that design review alone will miss. Treat it as such, and it delivers genuine value. Treat it as an administrative requirement, and it will deliver administrative results.