A management of change procedure exists because the injury and process safety risk during a plant modification is measurably higher than during routine operation, and that risk shows up precisely when a change slips through without the review it needed. A new pump specification, a revised setpoint, or a staffing cut in a maintenance department can each look routine on paper, but any one of them can quietly remove a safeguard the original design depended on. The plants that manage this well are not the ones with the longest MOC form, they are the ones where every change is classified correctly, routed to the right reviewers, and closed out with a pre-startup check before anyone assumes the new normal is safe. Most of that discipline breaks down not from bad intent but from paper trails that cannot keep pace with how often power plants actually change, and from small changes that look too minor to bother routing through a full review. See how a connected MOC workflow keeps pace at ifactory support.
Route Every Change to the Right Review, Every Time
AI-assisted MOC workflow that classifies equipment, process, and organizational changes automatically, routes them to the correct reviewers, and blocks startup until every pre-startup action is actually closed.
Why MOC Breaks Down in Power Plants Specifically
Power plants change constantly, from setpoint tweaks during a heat rate optimization push to full equipment swaps during a planned outage, and the sheer volume of changes is exactly what strains a paper-based or spreadsheet-based MOC process. A system built to review a handful of major modifications a year struggles under the weight of dozens of smaller changes a month, so shortcuts creep in.
The strain compounds because power plants rarely have a single MOC owner sitting in one office. A change touching a boiler feed pump might need input from a mechanical engineer, an instrumentation technician, and an operations shift lead, each working from a different system or a different physical location on site. When the review process depends on physically routing a paper form or chasing three separate email replies, the path of least resistance becomes skipping the review entirely, especially under outage schedule pressure where every day of delay has a visible cost attached to it.
Three Change Types, Three Different Reviews
Equipment, process, and organizational changes each introduce risk through a different mechanism, which is why treating them identically on one generic form tends to under-review some changes and over-burden others.
| Change Type | What Changes | Typical Review Focus |
|---|---|---|
| Equipment | Machinery, guarding, interlocks, instrumentation specifications | Design basis comparison, safety system impact, installation verification |
| Process | Setpoints, sequences, operating limits, cleaning or startup procedures | Deviation from proven operating envelope, effect on downstream systems |
| Organizational | Staffing levels, contracted labor, budget allocation, shift structure | Impact on the five PSM elements: mechanical integrity, training, procedures, and related controls |
Organizational changes are the category most often missed entirely, since nothing physical is being touched and the change can be authorized well outside the maintenance or engineering functions that normally trigger an MOC. A budget decision made at a corporate level, with no visibility into which plant-level procedures depend on the staffing or inspection frequency being cut, is exactly the kind of change that needs a screening step built into the approval chain rather than left to whoever happens to remember the connection.
Give Every Change One Auditable Record
Bring your current MOC form or template to the call. We will walk through how automated routing and pre-startup checks would fit your existing process.
Scoring Risk Before a Change Is Approved
A risk matrix gives reviewers a shared, repeatable way to weigh a proposed change instead of relying on individual judgment alone, plotting how likely a hazard is to occur against how severe the consequence would be if it did.
A change that lands in the low band can often proceed with standard sign-off, while one landing in the critical band typically needs a more detailed hazard review, additional safeguards, or escalation to a higher approval level before it is allowed to move forward. Recording the score alongside the approval, rather than relying on a reviewer's memory of the discussion, is what makes the decision defensible later.
From Change Request to Verified Startup
A consistent MOC workflow moves a change through the same gates regardless of type, though the depth of review at each gate scales with the risk score assigned earlier in the process.
Consistency across gates matters more than speed at any single gate. A change that skips straight from initiation to implementation because a reviewer was unavailable creates the same exposure as one that never went through review at all, and a workflow that allows that skip under schedule pressure is a workflow that will eventually let a real hazard through. Building the gate sequence into the system itself, rather than trusting each reviewer to remember their step, removes the option to shortcut it even when an outage clock is running.
Replacement-in-Kind or Full MOC Review
This is the decision point where most disputes happen, and getting it wrong in either direction has a cost: treating a real modification as replacement-in-kind skips a review it needed, while treating every minor swap as a full MOC buries reviewers in low-value paperwork.
A helpful test is to ask what the original design basis actually specified, not just what the part looks like. A valve that appears identical to the one it replaces can still carry a different pressure rating, a different actuator response time, or a different material compatible with a narrower range of process chemistry, any of which can move it out of replacement-in-kind territory even though it bolts into the same location. Keeping equipment specifications on record and checked against every proposed swap, rather than relying on visual similarity, is what keeps this decision consistent across different reviewers and different shifts.
Four Mistakes That Undermine an MOC Program
A Setpoint Change That Almost Skipped Review
An operations team at a combined-cycle plant proposed adjusting a feedwater control setpoint to squeeze a small efficiency gain during a period of high power demand, and the initial request was logged as a minor process tweak with a same-day turnaround expected. On paper it looked routine, since the plant had run close to that setpoint before during a different unit configuration.
When the request was scored against the risk matrix as part of the standard intake process, the likelihood of triggering a downstream alarm was rated higher than expected because the proposed setpoint sat closer to a protective trip point than the team had realized, and the consequence band was elevated given the unit's current load. That combination routed the change automatically to a full technical review instead of the same-day approval the team had anticipated. The review found that the previous instance of running near that setpoint had occurred with a different feedwater pump configuration no longer in service, and the proposed change was revised to a smaller adjustment with an added alarm buffer before it was approved. The setpoint change went ahead within the week, just with the margin the original request would have removed.
What made the difference here was not a reviewer catching the issue through diligence alone, but the intake process forcing a risk score before anyone could sign off informally. Under the plant's previous process, a same-shift verbal approval for a change framed as minor would likely have gone through without anyone cross-checking the pump configuration history, since that detail lived in a maintenance record most operators would not have thought to pull. Making the risk score a required step, rather than an optional judgment call, is what surfaced a fact the team did not already know to ask about.
Who Reviews and Approves an MOC
Readiness Checklist Before Your Next MOC Submission
Frequently Asked Questions
Turn Your MOC Process Into an Auditable System
Bring your current MOC form and a recent change example to the call. We will walk through how automated classification, risk scoring, and pre-startup checks would apply to it.
