Management of Change (MoC) for Process Installations

Author: Engineer Hub
Version: 3.0
Date: 2026

A process plant does not fail because it changes. It fails because it changes without understanding what that change does to its barriers.

Management of Change is the discipline that forces the organisation to stop and answer one uncomfortable question before implementing a modification: “What assumptions in our design, risk assessments, and operating model does this change invalidate?”

Why MoC Fails in Mature Plants

In new projects, change control feels natural. Drawings are fresh, design basis is known, review culture is active. In operating plants, MoC fails for a different reason: familiarity.

People know the system. They have operated it for years. Small modifications feel safe. A setpoint shift. A different valve supplier. A bypass “just for this week”. A different purge gas. A new contractor taking over maintenance.

No single change appears dangerous. The danger emerges when small deviations accumulate and silently erode safety margins that were built into the original design.

What Counts as a Change

A robust MoC system clearly defines scope. If scope is vague, people create loopholes. The most dangerous phrase in weak systems is “replacement in kind”.

Replacement in kind must mean: identical design basis, identical materials, identical ratings, identical performance characteristics, identical failure modes, identical interfaces.

If the new component changes any of those, even subtly, it is not replacement in kind. It is a change.

The Real Function of MoC: Protect the Design Basis

Every process installation has an implicit or explicit design basis. That design basis defines maximum pressure, temperature, composition, inventory, ventilation assumptions, relief capacity, ignition control philosophy, operator response expectations, and maintenance concepts.

Most changes do not look dramatic. But they often shift one of these assumptions:

• Increase maximum credible pressure.
• Alter flammable concentration envelope.
• Reduce operator response time margin.
• Change failure probability of a component.
• Increase frequency of isolation or line breaking.

MoC forces the question: Does this change move us outside the assumptions used in our HAZID, HAZOP, ATEX classification, FERA, relief study, or emergency response plan?

A Workflow That People Will Actually Follow

An MoC workflow must be structured, but not bureaucratic. When people see MoC as an obstacle, they will bypass it. When they see it as a decision framework, they use it.

A practical structure looks like this:

• Initiation: Define what is changing, why, and the physical/system boundary.
• Screening: Determine review depth using explicit criteria.
• Risk review: Identify new hazards and barrier impacts.
• Technical basis: Document the engineering reasoning and assumptions.
• Action list: Drawings, procedures, training, tests, PTW updates, isolation updates.
• Implementation: Controlled execution and testing.
• Readiness review: Verify safe startup conditions (PSSR or equivalent).
• Closeout: Confirm documentation and training completion.

Right-Sizing the Review

Over-engineered MoC systems collapse under their own weight. Under-engineered systems miss hazards. The balance is achieved by screening logic embedded directly into the form.

Example screening logic:

• If the change affects relief systems, SIS logic, hazardous area classification, ignition control, maximum pressure/temperature/inventory, or emergency response → Major review required.
• If the change alters procedures, equipment type, materials, control setpoints, staffing, or maintenance methods → Standard review.
• If the change is demonstrably identical in design basis and function → Minor, with documented justification.

The important point is that the decision logic must be written and visible. It should not depend on who is on shift.

Human and Organizational Change: The Silent Drift

Plants often run stable for years. Then staffing changes. Experienced operators retire. Maintenance is outsourced. Alarm philosophy is adjusted to reduce nuisance alarms. Supervision layers thin.

None of these changes move a pipe. Yet they move risk.

Organizational change MoC should ask:

• Who owns each safety barrier after this change?
• Is competence equivalent?
• Are response times altered?
• Does fatigue exposure increase?
• Does local knowledge disappear?

Temporary Changes: Where Discipline Breaks First

Temporary modifications are often implemented under time pressure. A hose instead of a pipe. A bypass instead of a repair. A manual override during troubleshooting.

Without strong controls, temporary states become normalized. Months later, nobody remembers the original configuration.

Minimum controls for temporary changes:

• Explicit expiry date.
• Named owner responsible for revalidation.
• Visible field labeling.
• Defined restoration plan or conversion to permanent MoC.

MoC and Operational Systems: PTW, LOTOTO, Isolation

MoC is not isolated from operations. If a change modifies equipment, it often modifies:

• Isolation boundaries.
• LOTOTO steps.
• Permit to Work hazards.
• Gas testing requirements.
• Emergency response instructions.

A strong MoC process forces explicit confirmation that PTW forms and isolation certificates are updated. Otherwise, the field continues working with outdated information while management believes the change is controlled.

Readiness Review Before Startup

Hardware installation is not the end of a change. Restarting without verifying readiness is how changes create incidents.

A structured readiness review (PSSR or equivalent) should confirm:

• All MoC actions are complete.
• Drawings reflect reality or are temporarily controlled.
• Procedures are updated and staff trained.
• Trips, alarms, and interlocks are function tested.
• Isolation philosophy remains valid.

The startup decision must be based on evidence, not optimism.

KPIs That Reveal MoC Health

Useful indicators are not the number of MoCs raised. They are:

• Average age of open MoCs.
• Percentage of temporary changes past expiry.
• Percentage of MoCs with document updates confirmed.
• Post-change incidents linked to missing training or incomplete review.

A plant with many MoCs is not necessarily risky. A plant with few MoCs in a dynamic environment probably is.

Common Failure Modes

• MoC applied only to capital projects, not day-to-day operational drift.
• “Replacement in kind” used as a shortcut without technical comparison.
• Approvals obtained after implementation.
• MoC closed without verifying procedure updates and training.
• Organizational changes excluded from scope.
• Temporary changes left in place indefinitely.