HAZID vs What-If vs LOPA: Which Process-Risk Method Fits a New Design Review?

A new process design can pass through several risk reviews and still leave the most important decision unanswered. The problem is often not a lack of methods. It is choosing a method whose evidence does not match the decision that engineering, operations, and leadership need to make.

HAZID, What-If, and LOPA are not interchangeable versions of the same workshop. HAZID is strongest when a team needs to expose broad hazards early. What-If is useful when experienced practitioners can challenge a defined design or operation through disciplined questions. LOPA is more demanding and more focused because it tests whether independent protection layers can reduce a specific consequence to an acceptable level. The right choice depends on design maturity, consequence, uncertainty, and the decision boundary.

What should a design review prove'

Before selecting a method, define the decision that the review must support. A concept-stage review may need to show that major hazard scenarios have been identified before layout, equipment, and emergency arrangements become expensive to change. A process-safety review before approval may need to show that a credible consequence has enough independent protection. A temporary change may need a focused challenge to assumptions rather than a broad study that repeats information already available.

IEC 31010:2019 presents risk-assessment techniques as tools that should be selected according to the situation, not as a universal ranking. That principle matters because an impressive workshop can still be the wrong control if it produces a list without an owner, a decision, or a verification route.

Use four tests before opening the meeting. Ask what is known about the design, which consequences matter most, whether the team needs breadth or depth, and what evidence will allow the approving authority to say yes, no, or not yet. The answer usually makes the method clearer.

Evaluation criteria for HAZID, What-If, and LOPA

The comparison below uses six criteria that reflect how the methods behave in real design governance. None of them is a score of quality in isolation. A method can be technically rigorous and still be poorly matched to the question in front of the team.

This matrix also shows why a design team should resist the phrase 'the risk assessment is complete' unless it can state what was assessed and what remains outside the method's scope. Completion of a workshop is not the same as completion of the decision.

HAZID is the broadest lens for early design

HAZID, or hazard identification, earns its place at the front of a project because it can expose hazard sources before the design has enough detail for a more granular study. The team can examine materials, energy sources, interfaces, occupancy, utilities, environmental conditions, human factors, emergency response, and external events while the project still has room to change direction.

Its value is breadth. A strong HAZID helps the project see issues that may disappear when each discipline reviews only its own drawing. It also creates an early risk register whose owners can be tracked through design development. The useful output is not the number of hazards recorded. It is the number of decisions that changed because the hazards were visible soon enough.

The common failure is to treat HAZID as a catalogue. If every conceivable concern receives the same wording, priority, and action, the list stops helping the project decide. The facilitator should force distinctions between a credible major-hazard scenario, a design quality issue, an operational concern, and an item that belongs in a later study.

HAZID is the best first choice when the team is still asking, 'What could matter here'' It is weaker when the decision requires proof that specific safeguards are independent and sufficient. That is where a focused method should follow.

What-If is strongest when experienced people can challenge assumptions

What-If analysis turns expertise into a disciplined set of questions. What if the cooling medium is lost' What if a valve remains closed' What if the wrong material reaches the line' What if power fails during a critical sequence' Each question should lead to a consequence, an existing safeguard, an additional action, and an owner who can close the gap.

The method works well when the design or operating change is defined enough for participants to ask concrete questions but not so complex that a generic workshop becomes unmanageable. It can be valuable for modifications, operating envelopes, utility changes, commissioning activities, and interfaces between systems that are not captured clearly in one process diagram.

The method depends on disciplined questions. 'The operator would notice' is not a safeguard until the team defines the detection point, response time, alarm quality, competence, and expected action. 'The procedure covers it' is not evidence until the procedure is current, usable, owned, and tested against the scenario.

What-If is the right choice when the central question is, 'Which assumptions should we challenge before this design or change is released'' It is not a substitute for deeper scenario quantification when the consequence is severe and the protection decision needs explicit independence.

LOPA tests whether protection layers can carry the decision

Layer of Protection Analysis, or LOPA, focuses on a defined initiating event and a defined consequence. The team asks which independent protection layers prevent the consequence, whether each layer is sufficiently independent, and whether the combined protection is adequate for the required risk-reduction decision.

LOPA is valuable because it makes vague assurance harder to hide. A procedure, alarm, interlock, relief device, or response action cannot simply be counted because it exists on a drawing. The team must explain how the layer works, what initiates it, how independence is maintained, and what evidence demonstrates that it will perform when demanded.

That focus also creates a limitation. LOPA cannot rescue an undefined scenario. If the initiating event, consequence, enabling condition, demand frequency, or safeguard performance is uncertain, the numeric result may look more exact than the underlying knowledge deserves. Engineering leadership should treat weak inputs as a reason to improve the scenario definition, not as permission to decorate uncertainty with decimals.

LOPA is the best choice when the decision is, 'Are these specified independent layers enough for this consequence and initiating event'' It is usually a poor first workshop for a concept that has not yet exposed its broad hazard picture.

When should the methods be combined'

Projects often need more than one lens, but combining methods does not mean repeating the same workshop with different labels. A sensible sequence can start with HAZID during concept selection, use What-If to challenge a defined modification or operating assumption, and apply LOPA to the small number of scenarios whose consequence and protection decision require deeper analysis.

The sequence should preserve the purpose of each method. HAZID finds the scenarios that deserve attention. What-If tests whether the design and operating assumptions survive practical challenge. LOPA examines whether critical protection layers are independent and adequate for a defined case. If the later method produces a new major scenario, the project should return to the hazard register rather than forcing the discovery into an unsuitable worksheet.

Andreza Araujo's Safety Culture: From Theory to Practice emphasizes the difference between declared values and repeated operating choices. That distinction applies to risk studies as well. A company declares that serious hazards matter, yet its process only becomes credible when the review changes equipment, ownership, release criteria, or operating authority.

Decision matrix for a new design review

The following matrix gives engineering leaders a practical default. It is a starting point, not a replacement for professional judgment or the requirements of the applicable process-safety program.

A project should retain the trace from the first hazard description to the final control decision. That trace prevents a familiar failure in which a broad issue is logged during concept design, narrowed into a workshop action, and then disappears before the approval gate.

Recommendation by design context

Choose HAZID first for a new facility, a major layout change, a novel material, or a project whose hazard picture is still emerging. Choose What-If for a defined change where the team needs a practical challenge of assumptions, interfaces, and operating response. Choose LOPA when a specific high-consequence scenario has been defined and the approval depends on the quality and independence of its protection layers.

Use all three when the project contains a new hazard picture, a series of operational assumptions, and a small set of consequences that require explicit protection-layer decisions. The methods should form a chain, not a stack of duplicate reports. Each step should narrow uncertainty and improve the next decision.

Across 25+ years leading EHS at multinationals, Andreza Araujo has seen that risk governance becomes credible when leaders connect technical analysis to authority, resources, and field verification. A review is not finished because the workshop ended. It is finished when the responsible owner can show what changed, why the change is adequate, and how the organization will know if the control weakens.

For practitioners building that connection, Safety Culture Diagnosis offers a practical way to examine whether the organization's stated risk process is reflected in everyday decisions. Safety is about coming home, and the design review is one of the earliest places where that promise becomes engineering reality.

Explore risk boundaries that separate managed exposure from uncontrolled risk, compare this decision logic with the evidence risk owners should trust before accepting residual risk, and review how management of change, pre-startup review, and field verification divide responsibility.