How to Run a What-If Review Before a Process Change

OSHA 29 CFR 1910.119(l) requires employers covered by Process Safety Management to address the technical basis, safety impact, procedures, time period, and authorization of process changes before the change is made. This guide shows senior EHS leaders how to run a focused what-if review before a process change becomes a hidden management-of-change failure.

Why a process change needs a what-if review before approval

A what-if review is a structured question session used to test how a proposed change could fail, affect people, weaken controls, or create new operating conditions. It belongs before approval because management-of-change paperwork often records intent while the what-if conversation tests whether the organization actually understands the new risk.

OSHA's Process Safety Management standard names management of change as a prospective duty, not a cleanup task after installation. The CSB Management of Change safety bulletin reaches the same practical conclusion from investigations: changes that look small on paper can carry serious consequences when no one tests the assumptions behind them.

On the Headline Podcast, Andreza Araujo and Dr. Megan Tranter often press for real conversations that make risk visible before the work reaches the field. In risk management, that means the senior EHS manager should treat a what-if review as a decision filter, not a meeting added to satisfy the file.

Step 1: What change are you reviewing?

The review starts by defining the change in one operational sentence. Name the equipment, procedure, raw material, control logic, staffing pattern, contractor interface, or operating condition that will be different after the change is approved.

OSHA Appendix C to 1910.119 describes management of change as covering modifications to equipment, procedures, raw materials, processing conditions, technology, instrumentation, and similar process elements other than replacement in kind. That boundary matters because teams often skip review when the change feels ordinary, although ordinary is exactly where untested assumptions survive.

Write the change statement so a shift supervisor could read it and point to what will be different in the field. If the team cannot do that, pause the review and correct the scope before moving forward.

Step 2: Set the review boundary

A what-if review fails when it tries to cover the whole facility, because the conversation becomes too broad to produce decisions. Set the boundary around the process unit, task, interface, energy source, people exposed, contractor scope, and time window affected by the change.

The boundary should also name what is excluded. If a valve replacement affects isolation, but not the downstream packaging area, say so explicitly. If the change affects a shutdown window with overlapping contractors, connect the review with the existing SIMOPS risk mapping before shutdown work, since simultaneous operations often turn local changes into shared exposure.

The test is practical. Everyone in the room should know where the review begins, where it ends, and which adjacent activity must be handled by another control process.

Step 3: Bring the people who can break the assumption

The best what-if review includes people who understand design intent, operating reality, maintenance limits, contractor tasks, emergency response, and supervision. A small group of experts can miss the field workaround that decides whether the change is safe.

As Andreza Araujo's risk-management grounding argues in Como Fazer uma CIPA Fora de Serie, sharp risk perception is a human capability independent of the method used. The tool matters, but the right people matter first because they hear weak assumptions that a template will never catch.

On a Headline Podcast conversation about safety technology, Cam Stevens made the same point from another angle: teams should start from the problem they want to solve, not from the tool catalog. A what-if review applies that discipline to change approval by forcing the group to ask whether the proposed solution solves the actual risk or merely moves it elsewhere.

Step 4: Convert the change into what-if questions

The facilitator should turn the change statement into direct questions that test failure paths. Ask what if the new setting is wrong, what if the temporary bypass remains in place, what if the operator follows the old procedure, what if the contractor starts before isolation is verified, and what if the alarm does not reach the person who can act.

This is where the review becomes different from a generic checklist. A checklist asks whether documents exist. A what-if review asks whether the changed system can still hurt someone when the documents are present but the work is pressured, noisy, late, unfamiliar, or split across teams.

For high-risk work, connect the question set with the JSA built before high-risk work. The JSA translates the review into task-level controls, while the what-if review keeps the team from approving a change whose hazards were never challenged upstream.

Step 5: Test controls before accepting the answer

Every answer to a what-if question should identify an existing control, a new control, or a reason the scenario is not credible. Weak answers usually sound like confidence statements: people know, operators are trained, maintenance will catch it, or supervision will watch it closely.

Those answers need pressure. Ask what evidence proves the control exists, who verifies it, how often it is challenged, and what happens when the verifier is absent. In Headline terms, this is the point where a leadership conversation becomes real because it moves from belief to evidence.

If the change touches fatal-risk exposure, pair the review with critical control verification in the field. A control that cannot be verified under normal work conditions should not be treated as a reliable barrier during change approval.

Step 6: How do you decide whether the risk is acceptable?

The team should decide acceptability only after naming the scenario, consequence, existing control, proposed action, owner, and due date. A risk matrix can support the conversation, but it should not replace judgment about whether people will be exposed while the change is unfinished.

Andreza Araujo's position in Sorte ou Capacidade, often translated as Luck or Capability, is useful here: well-managed risk is calculated and mitigated with method, not bravado. In a what-if review, bravado appears when the team accepts a red scenario because the project date is close.

The risk matrix is most dangerous when it makes a weak answer look disciplined. Use the matrix after the scenario is clear, and keep the distinction explained in risk matrix distortions leaders still believe close to the approval conversation.

Step 7: Write actions that survive handoff

A good action from a what-if review names the physical or administrative change, the accountable owner, the completion evidence, and the condition that must be met before startup. Actions such as retrain operators or review procedure are too vague unless they specify what changed, who must be competent, and how readiness will be proven.

OSHA 1910.119 connects management of change with process safety information, operating procedures, training, and startup readiness. That means the action list should not sit beside the MOC process as a separate note. It should update the documents, instructions, and verification steps that workers will actually use.

When the change affects startup after modification, align the action list with the pre-startup safety review process. The what-if review identifies what could fail, while the PSSR confirms that the agreed protections are in place before the system returns to service.

Step 8: Close the review only after field verification

The review is not closed when everyone leaves the meeting. It is closed when actions are complete, procedures reflect the new condition, affected workers understand the change, and the field verification confirms that the changed work can be done as intended.

This is the step many organizations compress because the project already feels complete. The trap is that the physical change may be finished while the human system still operates from the old mental model, old drawing, old habit, or old maintenance sequence.

Ask one final question before approval: if this change fails tonight, which assumption would an investigator say we never tested? If the team can answer that question honestly, the what-if review has done its job.

Comparison: paper MOC vs what-if review

Make the review useful enough to change the decision

A what-if review before process change is useful only if it can slow, reshape, or stop the change when the evidence is weak. If the answer is already decided before the questions begin, the review becomes a ceremony and the real risk moves silently into operations.

The Headline Podcast exists as the space where leadership and safety come together to shape better workplaces and better lives. Use this review before the next MOC approval, and let the conversation reveal whether the change is ready for the people who will inherit it.