Why is Management Of Change (MOC) so poorly executed

Why is Management Of Change (MOC) so poorly executed?

Management of Change (MOC) under OSHA Process Safety Management standard is rarely weak because people don’t know the rule, it’s weak because it conflicts with how work actually gets done in operating environments. The failure is structural, not procedural. Here’s why it consistently breaks down:

1) It competes directly with production pressure

MOC introduces friction such as reviews, approvals, hazard analysis, documentation. In reality:

• Operations are incentivized to restore service quickly
• Maintenance is incentivized to close work orders
• Engineering is incentivized to deliver projects on schedule

MOC, by design, slows all of that down.

Result:

People subconsciously (or explicitly) look for ways to classify changes as:

• “replacement in kind”
• “temporary”
• “minor”

Not because they’re careless, but because the system rewards speed over deliberation.

2) “What is a change?” is far more ambiguous than it sounds

The regulation defines change broadly, but field conditions don’t. Therefore, gray areas are left open to interpretation such as:

• Material substitutions (same spec, different performance)
• Control logic tweaks in DCS/PLC systems
• Operating envelope drift (pressure, temperature, rates)
• Maintenance-driven modifications

Without sharp boundaries, MOC becomes judgment-based, and judgment varies widely.

Result:

Two equally experienced engineers can make opposite calls and both think they’re compliant.

3) Temporary changes are structurally mismanaged

Temporary changes are one of the biggest hidden risks. A common pattern develops with these type of changes:

1. Install a temporary bypass, jumper, or workaround
2. Document it (sometimes)
3. Extend it, extend it again, etc.
4. It becomes permanent without ever going through full MOC

Result:

The facility drifts away from its design basis without a formal review.

4) MOC is treated as a form, not a risk evaluation

Many systems reduce MOC to workflow software or paper forms:

• Fill out fields
• Route for approval
• Close the action

But the core intent, hazard evaluation, gets compressed or skipped. This creates weak points:

• Superficial hazard reviews instead of real scenario analysis
• Safeguards listed but not validated
• No challenge of assumptions from prior HAZOP or design

Result:

The MOC information is complete, but the risk hasn’t actually been evaluated.

5) Field-level ownership is weak

MOC responsibility often lives with engineering or safety groups, but changes originate in the field. This creates disconnects:

• Operators and supervisors don’t feel ownership of MOC decisions
• Crafts implement changes without understanding hazard implications
• Contractors may not even recognize when MOC applies

Result:

The people closest to the change are the least integrated into the control process.

6) Digital and control system changes fly under the radar

Modern facilities make constant changes in:

• PLC/DCS logic
• Alarm setpoints
• Interlocks and permissives

These are often:

• Fast
• Easily reversible
• Poorly tracked

Result:
You get configuration drift in critical safeguards, often outside formal MOC.

7) Cumulative risk is invisible

Each individual change may seem low risk. But MOC systems rarely:

• Track aggregate impact of multiple small changes
• Reconcile changes back to the original design basis
• Revalidate assumptions used in Layer of Protection Analysis or PHAs

Result:

The cumulative risk of the sum of the individual risks increases gradually without triggering any single alarm. Unfortunately, there is no single, prescriptive recommended practice that tells you exactly how to track cumulative MOC impacts. There are widely accepted KPIs that can help:

• Number of overdue MOCs
• Temporary MOCs exceeding time limits
• MOCs impacting safety systems

8) Approval authority is misaligned

Approvers often:

• Lack deep process knowledge
• Are too removed from field conditions
• Are overloaded with volume

So approvals become:

• Rubber stamps
• Schedule-driven decisions

Result:

The system appears controlled, but decisions aren’t technically rigorous.

9) Post-implementation verification is almost nonexistent

Most companies focus on approving the change, not verifying that it worked as intended. These steps are rarely done well:

• Field validation that installation matches design
• Confirmation that procedures and training were updated
• Functional testing of safeguards

Result:

Even “good” MOCs can introduce unintended hazards.

10) Culture: MOC is seen as bureaucracy, not protection

If MOC is viewed as:

• Slowing work
• Adding paperwork
• Owned by “safety” or “engineering” instead of operations

It will always be bypassed under pressure.

In strong organizations, MOC is framed differently:

• A design integrity control, not an administrative one
• The last line preventing unknown risk introduction

The core issue

MOC fails because it tries to impose deliberate, analytical thinking into environments optimized for speed and execution. Unless the organization:

• Aligns incentives with risk control
• Defines “change” unambiguously
• Verifies effectiveness after implementation

The MOC procedure exists, but the control does not. Below is a flow chart of how we at AOC sees this work process:

https://assetoptimization.sharepoint.com/:i:/s/SharedData/IQCbdph-YfZzSJjPIJlLDuuKAQyFvHQ7W7X8gbhs8F2mDQk?e=0TMF5A

Be the first to comment

There are no comments for this article.