A PHA leader succeeds by enforcing scenario discipline: match each system to a defensible method, cut nodes with clear design intent, write rows as single causal chains, credit only independent safeguards, and document so a future revalidation team can reconstruct every hazard. Practice on paper with a rubric before attempting timed drills.
The PHA leader's job: facilitation and worksheet ownership
A PHA leader plans the study, matches each system to a method, keeps a multidisciplinary team moving one deviation at a time, and owns the completeness of every worksheet row. The role is facilitation plus documentation, not just hazard knowledge.
Before the first session, define the charter: which units are in scope, the risk matrix the team will use, who attends from operations, process engineering, controls, and maintenance, and how recommendations will be tracked. Decide node boundaries in advance and draft parameter lists per node. Skipping this planning surfaces mid-session as stalled debates about scope and ranking — the two things a team cannot settle on the fly.
During sessions, hold the team to one scenario at a time and push vague contributions into specific terms. If someone says 'pump failure,' ask which failure mode, detected how, and what happens downstream. Record disagreement rather than forcing instant consensus; a documented dissent is reviewable later, while an unrecorded objection disappears. Close each session by reading back incomplete rows and assigning owners.
Choosing between HAZOP, What-If, FMEA, and checklist
HAZOP works deviation by deviation through process nodes; What-If poses structured questions; FMEA walks component failure modes; checklists screen known hazards. Match the method to the system type, the maturity of hazard knowledge, and the decisions the study must support.
Pick HAZOP when the hazard lives in deviations from design intent — continuous chemical processes, transfer lines, reacting systems. Pick What-If for simpler or batch systems, or early design stages without firm P&IDs. FMEA suits studies organized around equipment reliability, and checklists suit mature, well-documented technology where past hazards are already catalogued and codified.
A single study often mixes methods: HAZOP the main process nodes, a checklist for utilities, What-If for the tank farm. The leader should be able to defend the method choice for each node in the report, because reviewers judge whether the chosen method could plausibly find the hazard classes relevant to that system — not which method is 'best' in the abstract.
| Method | Core question | Best fit | Leader watch-out |
|---|---|---|---|
| HAZOP | How does the process deviate from design intent? | Continuous processes, piping, vessels, reacting systems | Nodes too large; generic, unanalyzable causes |
| What-If | What if this condition or event occurred? | Batch systems, simpler units, early design stages | Questions too broad; ranking discipline slips |
| FMEA | How does each component fail and with what effect? | Equipment- and machinery-centered studies | Misses human and procedural interactions |
| Checklist | Are known hazards for this technology addressed? | Mature, well-documented processes and utilities | Only finds what is already on the list |
Cutting nodes and building deviations that can be analyzed
Cut nodes at breakpoints — line size or service changes, major equipment boundaries, operating-condition shifts. Pair each node's parameters with guide words so every deviation is concrete: 'more flow' is analyzable; 'abnormal operation' is not.
Standard guide words — no, more, less, reverse, as well as, part of — combine with parameters such as flow, level, pressure, temperature, and composition. Build the combinations per node in advance, then test each one: can the team name at least one realistic cause? Discard combinations with no credible cause for that node, and keep the reasoning for the rejection so later reviews do not reopen settled questions.
Node size is a judgment the leader must own. A node covering half a plant produces generic causes and skipped deviations; micro-nodes stall the session in repetition. A practical test: can the team describe one design intent for the node in a single sentence? If not, split it. If the intent barely differs from the previous node's, merge them and move on.
Scenario 1: writing one consistent worksheet row
A worksheet row is one causal chain: one initiating cause, one consequence traced to its endpoint, existing safeguards listed before anything new is proposed, a rank from the agreed matrix, and each recommendation pointing back to a specific gap in that chain.
Paper scenario: a feed tank transfers solvent to a reactor pump; the node is the transfer line. Deviation: more level in the tank. A weak row writes cause 'operator error,' consequence 'release,' and recommends 'install instrumentation.' The problems: 'operator error' hides whether the makeup valve stuck or the operator misread a failed transmitter, and the recommendation ignores the safeguards already present — so the team cannot tell whether anything new is needed at all.
A stronger row names one cause — the level transmitter reading low after a calibration error — traces the consequence to its endpoint, overflow through the vent into the containment dike, and lists what exists first: a high-level switch that shuts the makeup valve. The genuine gap is detecting transmitter drift before the switch is challenged, so the recommendation becomes a periodic verification task or an independent sensing point, traceable to this row. That traceability is what lets a reviewer, or a revalidation team, judge the decision years later.
Scenario 2: safeguard credibility and the double-counting trap
Credit a safeguard only when it is independent of the cause and of other credited layers, capable of stopping the event, and available to the person or system expected to act. Shared sensors, shared power, or the same operator response cannot be counted twice.
Paper scenario: the team studies reactor overpressure and credits three safeguards — a high-pressure alarm with operator response, a relief valve, and a safety instrumented system that trips the feed. A reviewer's question exposes the flaw: the alarm and the SIS trip read the same pressure transmitter, so one transmitter failure silences both, and the operator response depends on that same lost signal. What looked like three layers of protection is closer to one.
The better decision is to verify independence before crediting: separate sensing points, separate logic, separate final elements. If the team cannot demonstrate independence on paper, downgrade the credit and either record the gap as a recommendation or escalate the scenario to LOPA, which evaluates each independent protection layer against order-of-magnitude frequency criteria instead of qualitative judgment. Know the boundary between the two tools: a HAZOP rank expresses team judgment on a matrix, while LOPA tests whether a specific layer meets a numeric target.
Documentation quality and when change triggers revalidation
The worksheet is the deliverable. Every row needs a specific cause, an endpoint consequence, safeguards, a ranked risk, dated recommendations with owners, and closure status. Changes to process, chemistry, or safeguards after the study must trigger a documented revalidation decision.
Quality-check worksheets as the leader, not the scribe alone: no row with a generic cause, no safeguard credited without a stated basis, no recommendation without a scenario reference and an owner. Read ten random rows per session and ask whether someone outside the team could reconstruct the hazard from them. That is the standard the record must meet for reviewers and for the revalidation team that inherits it.
Tie the study to management of change: a new catalyst, a relocated relief discharge, an altered interlock, or a changed operating envelope should raise a documented question — does this change invalidate any node or row? Keep a change log linked to node boundaries so the revalidation team can review the affected nodes first instead of re-deriving the entire study from scratch.
A paper drill, a rubric, and a preparation sequence
Run one paper node end to end: list deviations for flow and level, complete a full row for one deviation, and score it against the rubric below. Then cycle through method comparison, timed rows, and change-management cases as your study sequence.
Drill: a cooling-water line supplies a shell-and-tube exchanger condensing reactor overhead. Take flow as the parameter and generate the no, more, and less deviations; pick 'less flow' and write the complete row — cause, consequence endpoint, safeguards, rank, recommendation. Then self-score against the rubric. Treat an incomplete rubric result as a study signal pointing at the weak row element, not as a prediction of any exam or assessment outcome.
An adaptable sequence: first, learn worksheet anatomy and guide-word pairs until you can draft rows unaided; second, compare methods by running the same paper system through HAZOP and What-If and noting what each finds and misses; third, drill safeguard independence with deliberately flawed scenario sets like Scenario 2; finally, practice revalidation cases and timed full-node runs. The free practice questions page and the wider study-guide collection on this site slot naturally into the drill phases.
- Rubric — the row states one cause with a named failure mechanism.
- Rubric — the consequence is traced to a physical endpoint (vent, dike, flare, containment).
- Rubric — existing safeguards are listed before any new recommendation, with independence stated.
- Rubric — each recommendation references its row and names an owner role.
- Readiness check — you can defend a method choice for a given node in two sentences.
- Readiness check — you can spot a double-credited safeguard in a sample worksheet quickly and explain the shared element.
- Readiness check — you can split or merge nodes using the design-intent test.
- Readiness check — you can state what a process change must trigger after a completed study.