What is the difference between change management and management of change — and what is MOC in process safety?

The difference between change management and management of change is the difference between managing people and managing a plant. Management of change, usually shortened to MOC, is a process-safety discipline: a written procedure that must be followed before anything about a hazardous process is altered, so that a new pipe, a new chemical, a new setpoint or a new operating step is reviewed for what it could do before it is done. In the United States it is required by law at facilities covered by OSHA's process safety management standard. Change management, in the sense most managers mean, is the organizational discipline that works on the people a decision affects: why the change is happening, what it asks of them, how they are trained and what is done about their resistance. One governs the change itself and asks whether the plant will survive it; the other governs the people and asks whether they will adopt it. The two share four words and almost nothing else, and the useful thing about putting them side by side is what each is missing that the other has.

What is management of change (MOC) — and what does management of change mean in safety?

Management of change in safety means that no modification to a hazardous process is made until someone has written down what is changing, why, what it could affect and who authorized it, and until the people who will run the changed process have been trained. It is a control on the plant, not on morale. The phrase is used in much the same way in the chemical, oil, gas and pharmaceutical industries, in aviation safety management systems and in shipping: a gate between the idea of a change and the change itself.

The discipline exists because a process plant is a set of decisions that have hardened into steel. The diameter of a pipe, the rating of a relief valve, the material of a gasket, the order of steps in a start-up procedure were each chosen against a hazard someone could see at the time. When any one of them is changed, the hazard the original choice guarded against does not announce itself. A plant does not fail because someone changed it; it fails because someone changed it without finding out what the original designer knew. Management of change is the institution's way of asking the designer's question again, every time, before the wrench moves. It resembles the change control IT departments run on production systems, covered in an earlier post on what change management means in IT, with one difference: what is protected is not uptime but the people inside the fence and the town outside it.

What is management of change in process safety: what the OSHA standard actually requires

In process safety the requirement is written into federal regulation. OSHA's process safety management standard, 29 CFR 1910.119, issued in 1992 in the years after the Bhopal disaster, lists fourteen elements a covered facility must have in place. Paragraph (l) is management of change. It requires the employer to "establish and implement written procedures to manage changes (except for 'replacements in kind') to process chemicals, technology, equipment, and procedures; and, changes to facilities that affect a covered process."

The standard then names five considerations that must be addressed before any change is made: the technical basis for the proposed change; its impact on safety and health; the modifications to operating procedures it requires; the necessary time period for the change; and the authorization requirements for the proposed change. A sixth clause is about people. Employees who operate the process, and maintenance and contract employees whose tasks will be affected, "shall be informed of, and trained in, the change prior to start-up of the process." Two more clauses close the loop: if the change alters the process safety information or the operating procedures, those documents are updated accordingly.

Those clauses are a small complete theory of how changes go wrong: nobody could say why the change was being made; nobody asked what else it would affect; the procedure still described the old plant; a temporary fix became permanent; the person who approved it was not the person who understood it; the night shift arrived to a plant they were not trained on. Every one has an accident attached, and the standard reads the way it does because the people who wrote it had the reports on their desks.

When is management of change required — and what counts as a replacement in kind?

Management of change is required for any change to a covered process that is not a replacement in kind, and the whole weight of the discipline rests on that one exception. The standard defines a replacement in kind as "a replacement which satisfies the design specification." Swapping a worn valve for an identical one is a replacement in kind and needs no MOC. Swapping it for a different model that fits the flange and seems equivalent is a change, and needs one.

The definition does two jobs. It keeps the procedure from drowning in paperwork, because routine maintenance passes through untouched. And it forces the question every accident investigation eventually asks: did anyone check whether this was really the same? The plants that get into trouble are rarely the ones that skipped the MOC on a new reactor. They are the ones where a smaller substitution looked like kind and was not: a pipe of a different diameter, a gasket of a different material, a vendor's "equivalent" part, a procedure shortened by one step because the step seemed redundant. The replacement-in-kind test makes "it's basically the same" a claim that has to be shown against the design specification rather than asserted on the shop floor.

So MOC is required whenever the thing after the change would not match the design basis of the thing before it. A mature plant adds triggers it has learned the hard way (temporary changes, alarm setpoints, a new chemical supplier, shift staffing, control software) because those are the changes people talk themselves out of reviewing. Temporary changes get particular attention, for the reason the next section makes clear: a temporary change is a permanent change nobody has reviewed yet.

What happens when management of change fails: Flixborough, 1974

The case every process-safety course teaches is Flixborough, because the change that caused it looked small. On 27 March 1974, at the Nypro works at Flixborough in Lincolnshire, England, one of six stirred reactors in a cyclohexane oxidation train was found to be leaking through a two-meter crack. The reactors ran in series at about 8.6 bar and 155 degrees Celsius, holding cyclohexane well above its atmospheric boiling point. Reactor 5 was removed. To keep the plant running, a temporary pipe was fitted to carry the flow from reactor 4 to reactor 6, bridging the gap.

How that pipe came to exist is the entire lesson. The reactors were linked by 28-inch expansion bellows; the bypass was built in 20-inch pipe, the size to hand, with a dog-leg to connect two nozzles at different heights. According to accounts gathered for the fiftieth anniversary by the Institution of Chemical Engineers, the layout was sketched in chalk on the workshop floor. There were no engineering drawings. The pipe sat on scaffolding. The site's works engineer had left earlier in the year and the coordination of the engineering department had passed, temporarily, to an electrical engineer; the Court of Inquiry later found that he "was not qualified to act as a coordinator of the engineering department," and that none of the maintenance staff who built the bypass held engineering degrees or professional membership. Fabrication took about thirty hours; the plant restarted on 1 April, four days after the decision.

It ran for two months. On the afternoon of Saturday 1 June 1974 the bypass failed. Between ten and fifteen tonnes of hot cyclohexane escaped, flashed to vapor, drifted and found an ignition source. The explosion was later estimated as equivalent to between 14 and 40 tonnes of TNT. It killed 28 people on site, including all 18 in the control room, injured 36 more workers and 53 members of the public, and damaged close to two thousand houses, shops and factories in the surrounding villages. The fire burned for ten days.

The Court of Inquiry concluded that the disaster was caused by "the introduction into a well-designed and constructed plant" of a modification that destroyed its integrity, and added the sentence that became the founding text of the discipline: "a competent mechanical engineer would have understood the importance of the above measures." Nobody at Flixborough was reckless in the usual sense. A reactor was cracked, the plant stood idle, there was pipe in the yard, and capable men did what capable men do when the pressure is on and no procedure stops them. The system failed not because the people were bad but because there was nothing between the idea of the bypass and the bypass. Britain's Health and Safety at Work Act passed that same summer, and Trevor Kletz, then safety adviser to ICI, spent the rest of his career turning the lesson into the rule that modifications must be reviewed by someone competent to review them, before they are made. Management of change descends from a chalk drawing on a workshop floor.

Why is management of change important — the record since

Management of change is important because the record since Flixborough shows it is the element plants most often fail to run, and unreviewed change remains a recurring cause of serious incidents. The evidence is uneven, and the unevenness is part of the story.

In a 2018 paper for the Institution of Chemical Engineers' Hazards 28 symposium, Graeme Laughland, a process-safety consultant at ABB, reported a search of 891 incident reports in the European Union's eMARS major-accident database covering 1979 to August 2017. Only four were explicitly tagged as related to management of change, a figure he found "hard to believe." The same paper cites OSHA's data from its Refinery National Emphasis Program, in which management of change accounted for 92 citations, 9.0 percent of all citations issued, and 42 percent of those were for the most basic failure of all: an MOC procedure not established or not implemented. The gap between four tagged incidents and ninety-two citations is the point. Change is almost never recorded as the cause of an accident; the accident is recorded as a leak, a fire, an overpressure. Change is what inspectors find when they ask why the leak was possible.

The same paper records the other side of the ledger: a company cited in the UK Chemical Industries Association's best-practice guide tracked incomplete MOCs as a leading indicator and drove the count from 120 to zero. Run as a live control rather than a filing exercise, MOC is one of the few safety measures whose performance can be read off a single number before anything goes wrong.

What is the management of change process, step by step?

The management of change process, as most plants run it, is eight steps that map onto the OSHA clauses. First, the trigger: the proposal is tested against the replacement-in-kind definition; if it fails, an MOC is opened and the change waits until it closes. Second, the description: what is changing, from what to what, with the technical basis written in words an outsider could follow. Third, the classification: permanent, temporary or emergency, and if temporary, an expiry date and a named owner responsible for reversing it or converting it through a full review. Fourth, the hazard review, at a depth proportional to the risk. Fifth, the actions: the updates to drawings, procedures, alarm lists and maintenance schedules, each assigned to a person with a date. Sixth, the authorization, by someone with both the authority and the competence to understand what they are approving; Flixborough showed those are not the same qualification. Seventh, the training: everyone whose work is touched is informed and trained before start-up, not after. Eighth, the pre-startup review and close-out: every action done, the documents true to the plant, the training complete, the MOC formally closed.

The discipline lives or dies on three of those steps: the trigger, because a process that runs only when someone remembers it is not a process; the time period, because the temporary classification is where changes go to become permanent without review; and the training before start-up, the only clause in the standard about people and the one most often treated as a signature on a sheet.

Why is the management of change important in an organization — what change management can borrow

The organizational discipline is weak in exactly the places where the engineering one is strong. Change management, from Kurt Lewin's work in the 1940s through John Kotter's eight steps in the Harvard Business Review in 1995, has rich theory about why people resist and how to carry them through. What it lacks is a definition of change.

The plant has a trigger: a written test for which changes go through the gate, and an exception, replacement in kind, that is defined rather than felt. The organization has no such thing. A reorganization is obviously a change; a new approval step in an expense system is an IT ticket; a shift in who a team reports to is a line in an email. Nobody can say which changes require the people work, so it goes where someone with budget wants it, and the small changes that add up to a different job go through unreviewed. An earlier post on when to implement change management argued that the answer is at approval, on any project that changes how someone works. That is a replacement-in-kind test for the organization: the change is in kind if the work after it would match the work before it; if not, the gate opens.

The plant has a time period: temporary changes carry expiry dates and a named owner, because the industry learned at Flixborough what a temporary pipe does when nobody owns it. Organizations are full of temporary arrangements that became permanent: the interim manager still in post three years later, the stopgap spreadsheet that is now the system of record, the pilot team never stood down or scaled. An expiry date on everything called interim would end most of them.

The plant also writes the basis down before the change and updates its documents after it, so the next operator inherits a description that is true. Organizations change the work and leave the job descriptions, process maps and training materials describing the old one, then diagnose the confusion as a culture problem.

David Luria's Flatten the AI J-Curve, a book on enterprise AI adoption, makes a related argument from the other direction. It tells the project team to spend the first four weeks interviewing the people who actually do the work and documenting the workarounds that are not in the official process documentation, because, in its words, every enterprise process has a shadow version, the way it actually works versus the way the process map says it works. In the plant's terms, that shadow version is a backlog of changes made without MOC: each workaround is an alteration nobody reviewed, documented or trained anyone on. The book's audit is management of change run in reverse, catching up on a decade of unmanaged changes before a new one is laid on top; its locked-down workflows, which it calls protocol engineering, are the organizational cousin of the operating procedure the plant rewrites every time the plant changes.

So what is the difference between change management and management of change?

Management of change governs the change; change management governs the people. MOC is a legally required gate on physical and procedural alterations to a hazardous process, triggered by a written definition of what counts as a change, judged by whether the plant will remain safe, and closed only when the documents are true and the operators are trained. Change management is a voluntary discipline applied to the people a decided change affects, with no fixed trigger, judged by whether the change is adopted.

The two fail in mirror image. Management of change fails most often at its one human clause, the training before start-up that becomes a signature rather than a shift that understands the change. Change management fails most often at the clause it never wrote, the definition that would tell it which changes need it. Each could borrow the other's strength, and neither borrowing costs anything but attention.

Flixborough is usually told as an engineering lesson. But the Court of Inquiry's finding was not that the pipe was wrong; it was that nothing stood between a group of pressed, competent people and the pipe they built. That is the finding to carry into the next reorganization, the next system, the next interim arrangement to be reviewed later. A change is anything that is not a replacement in kind. Most of them are not, and the gate has to be there before anyone reaches the yard.

One email when a book ships. Nothing between.

← All posts