Management of Change: 5 Failures That Turn Temporary Workarounds Into Permanent Risk

Across more than 250 cultural transformation projects supported by Andreza Araujo, one pattern repeats with stubborn consistency. A team introduces a temporary workaround to keep production moving, the original problem gets fixed or softened, and the workaround stays because nobody owns its removal. What began as a bridge becomes ordinary work, and the organization starts treating a controlled exception as if it were standard practice.

That is the real failure mode of management of change. In Safety Culture: From Theory to Practice, Andreza Araujo argues that culture is visible in repeated decisions, not in the labels the organization puts on its process. If the same exception keeps living past the event that justified it, the file may look complete while the field keeps carrying the risk.

This article takes a diagnostic view. It is not a checklist for paperwork. It is a way to see why MOC breaks, where the break starts, and which decisions tell you the change has already escaped its temporary box.

Why temporary change becomes permanent risk

Management of change exists because the work does not stay still. A new route, a bypassed interlock, a revised sequence, a substitute material, or a one-off staffing decision can shift exposure faster than the organization can absorb it. James Reason's work on latent failures helps here because the visible workaround is usually only the last layer of a longer decision chain.

The trap is that a temporary measure often feels safer than doing nothing, which is why people keep it. Bird and Heinrich are useful in this part of the discussion because repeated exceptions are precursor events, not proof that the hazard disappeared. If the organization keeps normalizing the precursor, the next layer of the pyramid is already being built.

In The Illusion of Compliance, Andreza Araujo makes the same point from a different angle. A process can look orderly on paper while the worksite keeps adapting around it. That gap matters because the paper file does not absorb the consequence if the workaround fails at 2 a.m., on night shift, or under contractor pressure.

The practical thesis is simple. A temporary change is not controlled just because it was approved once. It is controlled only if the organization can prove who owns the removal, when the workaround expires, and how the field will show that the change still matches reality.

1. Why do exceptions survive the original fix?

The first failure is the most common one. The original problem gets fixed, but the exception survives because nobody revisits it after the pressure eases. A damaged guard is repaired, yet the alternate manual step stays in the procedure. A spill route is cleared, yet the temporary storage pattern remains. A staffing shortage passes, yet the task still depends on the short-cut that was introduced during the busy period.

That is how a short bridge turns into a permanent lane. Once people have used the workaround enough times, they start to trust it more than the original control, especially if the workaround feels faster or easier. The organization then has two processes, not one, and the second one is usually less visible to leadership.

Across the 250+ project pattern, Andreza Araujo has seen that removal often fails because the team closes the problem that started the change, not the change itself. Those are different tasks. The repair may be complete, but the exception still needs a separate owner, a separate date, and a separate field check.

If the work still depends on the workaround after the reason for the workaround has passed, the system has stopped managing change and started managing memory. Memory is a weak control.

2. Why does ownership disappear after approval?

Approval is not ownership. A manager may sign the change, an engineer may design the fix, and a supervisor may live with the consequence, yet none of them may actually own the removal of the temporary state. That gap matters because exceptions without a named owner tend to survive every handoff.

The weak version of MOC stops at permission. The stronger version asks who will bring the work back to normal, who will verify that the field matches the file, and who will escalate if the workaround needs a second extension. Without those answers, the organization has a document with signatures, not a control with accountability.

Patrick Hudson's maturity model is useful here because immature systems assume that the act of approval is enough. More mature systems treat approval as the start of verification, not the end of it. They know that a change which is not owned after approval is often the kind that stays forever.

In practice, ownership should sit with the person who can actually remove the exception, not only with the person who was available to approve it. When the approver and the remover are different people, the file needs a visible bridge between them or the temporary state will drift into normal work.

3. Why do handoffs break the control?

Handoffs are where temporary changes go to die because every shift, contractor turnover, and supervisor rotation creates a chance for the exception to disappear from living memory. A day-shift leader may know that a route is blocked, a machine is bypassed, or a material is being staged differently, while night shift receives only a short note that says the issue is being handled.

The same problem appears when contractors leave and the host site assumes the temporary arrangement will self-correct. It will not. If the handoff does not name the change, the reason for it, the end date, and the stop condition, the next crew will treat the workaround as normal because it is now the only version they can see.

This is why management of change needs a handoff standard that is as explicit as the work itself. A change that is clear in one crew and invisible in another is not controlled. It is fragmented.

One practical test is blunt. Ask the next supervisor, the night shift lead, or the incoming contractor coordinator to explain the exception without looking at the file. If they cannot do it in plain words, the handoff failed and the change has not been transferred with enough discipline.

4. Why do documents outrun field reality?

A clean MOC record can hide a dirty field. The form says one thing, the worksite shows another, and leaders who stay inside the document never see the mismatch. That is how compliance theater grows inside a supposedly disciplined system.

The document may say the change is temporary, but the field may show extra signage, moved barriers, a new habit, a bypassed step, or a tool stored in a different place because the workaround has already reshaped the work. If the file does not reflect those realities, the process is no longer describing operations. It is decorating them.

As Andreza Araujo argues in Safety Culture: From Theory to Practice, repeated operational choices reveal the real culture. A field check is therefore not an audit ritual. It is the only way to see whether the change still matches the stated control.

The table below separates weak from strong evidence. It is a short test, but it forces the right question.

5. Why do leaders call it temporary after normalization?

Leaders often keep calling a workaround temporary long after it has become normal work because the label is easier to defend than the reset. Once production has adapted, the person who proposes removal may be seen as the one creating disruption, even if the disruption is only the return of proper control.

That is the political part of MOC. A workaround that solved a problem under pressure creates its own constituency, which means the team can start depending on the very thing it was supposed to retire. The longer that state lasts, the harder it becomes to admit that the exception is now the operating model.

When a supervisor keeps a temporary barricade in place for weeks because the original defect was never fully repaired, the organization has not just tolerated an exception, it has rewritten standard work around a risk that everyone now sees as ordinary.

This is where leadership quality matters. In more than 250 cultural transformation projects, Andreza Araujo has seen that the strongest teams are not the ones that keep every workaround alive. They are the ones that force the reset, because they understand that familiar risk is still risk.

What to do in the next 30 days

Leaders do not need a larger MOC binder. They need a tighter operating rule. The next 30 days should be used to expose every live exception, assign a removal owner, and make field verification non-negotiable before closure.

• List every temporary change that still affects work, not only the ones that are still in the formal tracker.
• Write a removal owner beside each exception, and make that name visible to the next supervisor or contractor handoff.
• Give each exception an expiry date and a clear trigger for escalation if the workaround needs an extension.
• Verify the field, not only the file, before closing the change.
• Sample at least 10 live exceptions and reopen any item that cannot prove the worksite matches the record.

The last step matters most. A system that never reopens an exception may look stable, but it is often just afraid to say that the change was not really temporary. In The Illusion of Compliance, Andreza Araujo makes the case that useful systems tell the truth about drift before drift becomes culture.

If the change has been extended once, ask why. If it has been extended twice, ask whether the exception is now the standard. If the answer is yes, the real management of change decision is no longer about the file. It is about whether the organization is willing to redesign the work.

MOC vs PTW vs PSSR

These three controls are related, but they are not interchangeable. A lot of weak programs blur them together, which is why temporary states survive far longer than they should.

If you use PTW to solve an MOC problem, the exception will keep returning. If you use PSSR to close a temporary workaround that never got retired, you are restarting around drift. The right gate matters because each one asks a different question, and the wrong one leaves the real problem untouched.

Conclusion

Management of change fails when leaders let a temporary workaround survive the reason that created it. The field then learns a dangerous lesson, which is that exceptions are easier to keep than to remove.

The practical test is blunt. If the exception still exists after the original reason disappeared, the system is not managing change. It is normalizing risk. That is the moment to reopen the file, verify the field, and decide whether the work itself needs to change.

Follow Headline Podcast for more diagnostic articles that connect leadership, risk, and field discipline.