How to Run a What-If Review Before a Process Modification in 8 Steps

A What-If review before a process change is a decision test, not a brainstorming session. Its job is to slow the team down long enough to ask what could fail, who could be exposed, and whether the proposed change still looks safe when the field, the shift, or the startup sequence is different from the meeting room.

OSHA 29 CFR 1910.119(l) requires management of change for covered process changes, while ISO 31000:2018 gives leaders a risk-management framework and IEC 31010:2019 gives them the reference family for risk-assessment techniques. That is why a What-If review belongs before approval, not after the project is already too expensive to question.

Across 25+ years leading EHS in multinational operations, Andreza Araujo has seen process changes fail when teams tested the form and not the field. In Safety Culture: From Theory to Practice, the pattern is clear: culture shows up in repeated decisions under pressure. In The Illusion of Compliance, the warning is sharper still. A complete-looking form can hide an incomplete control.

This article is for process engineers, maintenance planners, plant managers, and EHS leaders who need a practical method they can use before the next change becomes normal work. The goal is simple. Make the review strong enough to slow, reshape, or stop the change before exposure moves downstream.

What you need before starting

Before the review starts, gather the change request, the current operating description, the drawings or line walk reference, the affected procedures, the list of people who will work inside the change, and the owner who can accept or reject the decision. If the team cannot name those inputs, the review will drift into generalities.

• The change description written in operational language, not only project language.
• The current process condition, including normal operation, startup, shutdown, and temporary operation.
• The people who may be exposed, including contractors, operators, maintenance crews, and nearby trades.
• The field evidence that shows how the current controls actually work.
• The decision owner who can pause, redesign, or stop the change.

The best precondition is clarity about scope. If the team cannot explain the change to a shift supervisor in one minute without hand waving, the change is not ready for a What-If review. It is still a drafting exercise.

Step 1: Define the real change in operational language

Start by naming what changes in the work, not just what changes in the file. Does the change alter pressure, temperature, chemistry, software, staffing, sequence, ventilation, isolation, access, or temporary equipment? If the answer is only that a form exists, the team has not described the exposure.

The point matters because a process can look stable on paper while the real change sits in the details that operators and maintenance teams will feel first. A new bypass, a relocated sensor, a different cleaning sequence, or a temporary hose can create a different hazard profile even when the project brief sounds routine.

Use a sentence that names the field condition. For example, say what the crew will touch, what the system will do, and when the change becomes active. That level of precision helps the reviewer see whether the planned control still fits the actual task.

Step 2: Separate normal, startup, upset, and temporary modes

A What-If review is weak when it only checks the stable operating case. Many process changes are safe in steady state and unsafe during startup, shutdown, cleaning, testing, or temporary operation. The review should therefore ask what happens in each mode, because the hazard often appears during the transition rather than during the finished condition.

This is where the review earns its value. A pump replacement, valve change, software update, or piping modification may be benign once the system settles, yet the first fill, purge, pressure test, or restart can expose the weak point. If the review never asks about transition, it misses the moment where the work is most fragile.

For a field version of that same discipline, compare this review with dynamic risk assessment field triggers. The What-If review lives before the change. Dynamic risk assessment takes over when the field starts to drift from the approved plan.

Step 3: Identify who can be hurt and who can stop the work

Name the exposed people by role and location. Do not stop at the obvious operator. Include maintenance, contractors, operators in adjacent areas, control-room staff, cleaners, forklift drivers, and anyone who can be caught by line-of-fire, pressure release, heat, chemical exposure, traffic, or fatigue created by the change.

Then name the people who can stop the work. A review without stop authority is only a discussion. If the process engineer, production lead, and EHS partner all agree but no one can pause the task in the field, the organization has consensus without control.

As Andreza Araujo has seen in more than 250 cultural transformation projects, weak decisions often hide behind polite agreement. The crew hears that the change is approved, yet nobody knows who can intervene when the field condition turns different from the assumption.

Step 4: Ask one What-If question per credible failure path

Use the same discipline every time. Ask what happens if the change starts earlier, runs longer, fails open, fails closed, leaks, bypasses, vibrates, overheats, or meets a different crew than planned. Each question should connect cause, consequence, and recovery. If the team cannot explain recovery, the scenario is not controlled.

IEC 31010:2019 is the standard reference for risk-assessment techniques, so the review should feel structured rather than improvised. The questions need to be specific enough that the group can see the failure path, not just agree that risk exists.

Use the What-If review to press on the assumption that feels too convenient. If the control depends on memory, a perfect handover, or a spotless shift, the review should say so plainly.

Step 5: Challenge the controls in the field

Walk the work area before the change is accepted. Verify the tags, barriers, temporary controls, signage, isolation points, interlocks, access routes, alarm settings, and the exact place where the new condition will exist. A control that only lives in the meeting room is not yet a control.

Check whether the change depends on a barricade, a warning sign, or a training slide to stay safe. If it does, the protection is fragile. That is not a reason to reject every administrative control. It is a reason to test whether the stronger layers were also considered and whether the field can prove they still work.

This is also where the review should ask the uncomfortable question that appears in compliance theater before the next audit. If the proof exists only because the room looked busy, the process has not been verified. It has been performed.

Step 6: Decide whether the change needs redesign, added control, or stop

A serious What-If review should end in one of three actions. Approve the change as written, approve it with added control, or stop it until the design is changed. Anything else invites drift. If the review only produces notes and a handshake, it has not answered the decision.

The strongest reviews do not treat every concern as equal. A minor exposure may need a simple procedural note. A high-consequence exposure may require engineering change, a different sequence, a new hold point, or a different startup path. If the only defense is training, the review should be skeptical.

As Andreza Araujo warns in The Illusion of Compliance, a complete form can disguise an incomplete safeguard. A What-If review protects the organization only when it is willing to say that a change is too weak to approve as designed.

Step 7: Record owners, deadlines, and reopen triggers

Write every action with one owner, one due date, and one verification method. Avoid vague words like review, remind, or monitor unless the line item also says what will change in the field. If the action is not testable, it is not finished.

Each action also needs a reopen trigger. If the temporary hose stays in place longer than planned, if the crew changes, if the operating window expands, or if the startup sequence shifts, the review must reopen. That rule keeps the team from assuming that one meeting covered every version of the change.

For a practical follow-on, connect the action log to the safety exception register. A change that still needs exceptions after the review should be visible in a register, not buried in email.

Step 8: Close only after field proof and handover

Close the review only when the changed condition matches the approved condition and the field proof exists. If the change includes startup, hand the final step to the PSSR process, because the pre-startup review confirms that the change is ready for operation while the What-If review confirmed what could fail before the decision was made.

The handover matters because a project can finish while the plant is still learning how to live with the change. That is the moment when weak assumptions become normal behavior if nobody checks the field again. A clean closure note is not enough.

Ask one last question before release: if this change fails on the next shift, what assumption would the investigation say we never tested? If the team can answer that question, the review has done its job. If it cannot, the change is still open.

Final checklist

Use this checklist before approval:

• The change is written in operational language that the shift supervisor can repeat.
• The review covers normal, startup, upset, and temporary operating modes.
• People at risk and people with stop authority are both named.
• Each action has an owner, a deadline, a verification method, and a reopen trigger.
• The review closes only after field proof, and PSSR takes over if startup is part of the change.

A What-If review before a process change is not a paperwork ritual. It is the moment when the organization decides whether the new condition deserves to exist. If the answer is still uncertain, the safest move is to keep the decision open until the field can prove the control.

For teams that want a deeper diagnostic lens, the book Safety Culture: From Theory to Practice gives the culture side of the same problem, and Headline Podcast keeps the leadership conversation practical when process changes start outrunning the people who must live with them.

FAQ

What is a What-If review before process change?

It is a structured risk check that asks what could fail if the change is approved, who could be exposed, and whether the proposed controls still work in the field. It is meant to happen before the change becomes normal work.

How is a What-If review different from MOC?

MOC is the formal change-management process, while the What-If review is the thinking discipline inside that process. MOC tells the organization that a change must be controlled. The What-If review tests whether the control is strong enough to approve.

When should PSSR take over?

If the change includes startup or return to service, PSSR should take over after the What-If review has shaped the design. The two steps work together, but they do not do the same job.

Who should lead the review?

The process owner should lead it, with operations, maintenance, and EHS in the room. If the change touches contractors or specialized equipment, those owners should also be present. A review led by only one function usually misses the field consequence.

What if the review finds a weak control?

Then the team should redesign the change, add a stronger control, or stop the change until the design is safe enough to move forward. A weak control should not be hidden behind a positive meeting outcome.