1. The “Extreme MOC”: Stripped to Essentials
Before we explore different scenarios, imagine a Management of Change system reduced to its bare minimum — doing only what’s strictly necessary for compliance — no more, no less.
So, what is required?
Per OSHA 29 CFR 1910.119(l), a compliant MOC must address these nine core elements:
- Technical basis for the proposed change
- Impact of the change on safety and health
- Necessary modifications to operating procedures
- Time period necessary for the change
- Authorization requirements for the proposed change
- Informing and training affected employees
- Updating process safety information (if applicable)
- Updating operating procedures (if applicable)
- Pre-startup safety review (PSSR), if required
This thought experiment isn’t about cutting corners — it’s about understanding what must be addressed and who is responsible for addressing it, especially when other business processes like capital projects or turnarounds are in play.
2. Capital Projects: MOC as a Quality Gate
Large capital projects — often in the tens or hundreds of millions — are highly structured, with embedded controls for safety, design, training, and documentation. These projects often inherently satisfy all nine MOC elements.
What’s left for MOC? Primarily, confirmation and accountability.
In this setting, MOC plays a passive role — serving as a quality assurance checkpoint to ensure essential safety components have been addressed by the project team.
Importantly, the size or complexity of the project doesn’t exempt it from MOC — unless it is entirely new, independent construction on a greenfield site. In almost all other cases, MOC is still required.
3. Small Projects: MOC in the Driver’s Seat
Now contrast that with smaller projects — like installing a pressure gauge or modifying a pump circuit — typically fast-moving and informal.
In many cases, there’s no structured project process. Design, risk review, and documentation responsibilities fall entirely on the MOC workflow.
In these cases, MOC is an active process — it defines, drives, and tracks the change from start to finish.
This makes usability and clarity in your MOC system critical. Poorly designed systems can delay needed work or introduce untracked risk.
4. Turnarounds: The Most Complex Scenario
Turnarounds are high-stakes, resource-intensive events where hundreds of maintenance and upgrade tasks are bundled into a compressed shutdown window. MOCs intersect with turnarounds in several ways:
- Pre-planned MOCs: Initiated months in advance, awaiting the turnaround for safe implementation.
- Turnaround-driven MOCs: Defined by the turnaround team to improve efficiency or performance.
- Reactive MOCs: Triggered by issues discovered once the plant is opened.
- Design-intensive MOCs: Similar to capital projects, where MOC becomes a passive oversight tool.
MOCs during turnarounds can be both active and passive, depending on timing, scope, and origin.
This context demands tight integration between MOC workflows and turnaround planning systems to avoid conflicts or implementation gaps.
5. One MOC System — Multiple Roles
The big takeaway? MOC is not a one-size-fits-all process.
For example:
- In capital projects, MOC confirms that work already done meets regulatory expectations.
- In small projects, MOC is the project manager.
- In turnarounds, MOC adapts — supporting long-lead plans and just-in-time changes alike.
Solution: Use a lifecycle-based MOC model that accommodates different roles and scenarios, rather than forcing a rigid workflow on every case.
This design flexibility is key to compliance, efficiency, and safety.
6. Context-Smart Metric
Process safety leaders rely on metrics — but MOC metrics only make sense if interpreted through the right lens. For example:
- A growing backlog of MOCs might indicate delays — or it might signal healthy planning ahead of a turnaround.
- Long MOC durations could point to inefficiency — or they might simply reflect coordination with long-cycle projects.
Metrics must be tailored to MOC type — active vs. passive, standalone vs. project-tied — to be meaningful.
Final Thought: MOC is a Framework, not a Form
Whether you’re managing a billion-dollar project, a simple instrumentation tweak, or a major turnaround, the MOC process should do more than just check a box.
It should:
- Drive change safely where no structure exists,
- Confirm compliance where structure is already in place,
- And flex to support complex operations without becoming a bottleneck.
For engineering managers, safety leads, and plant executives, this means ensuring your MOC system is context-aware, scalable, and integrated — not just compliant, but effective.
