Theories of Management of Change, Applied to Safety MOC

Two different things wear the same name

Search for theories of management of change and you get two libraries that rarely talk to each other.

One is organisational: Lewin, Kotter, ADKAR, Bridges. It is about people, behaviour, resistance and adoption. The other is operational: management of change as a controlled procedure, the MOC that sits inside a safety management system and decides what happens when a line, a setpoint, a procedure or a role changes.

Same words, different problem. And in a Seveso III or ARIE environment you need both, because a change that people accept but nobody documented is still a finding, and a change that is perfectly documented but nobody works to is still a risk.

This article walks through the theories that are worth knowing, says plainly what each one is good for, and then gets concrete about the part the theories do not cover.

The organisational theories, and what each is actually for

Lewin: unfreeze, change, refreeze

Kurt Lewin's force field thinking is the oldest layer. The popular three stage version, unfreeze, change, refreeze, is a later simplification of his work, so treat it as a metaphor rather than a method.

What it is good for: reminding you that current practice is held in place by forces, not by ignorance. People are not doing it the old way because they never heard about the new way. They are doing it the old way because the old way is faster, familiar, and rewarded.

What it is bad at: the refreeze idea suggests organisations come to rest. Regulation, personnel turnover and ageing installations mean they do not.

Kotter: eight steps, in order

John Kotter's eight step model adds sequence: urgency, a guiding coalition, vision, communication, removing obstacles, short term wins, consolidation, anchoring.

What it is good for: large programmes with a start and a finish. A new safety management system, a merger of two sites, a cultural push after a serious incident. The step most often skipped is also the most useful one, which is removing obstacles. If a change asks someone to walk a four page checklist across a large installation in two hours, no amount of vision fixes that.

What it is bad at: continuous, low drama change. Most changes in a safety management system are small, frequent and technical. You will not build a guiding coalition for a modified pressure relief setting.

ADKAR: change happens one person at a time

ADKAR, developed by Jeff Hiatt and used by Prosci, breaks adoption into Awareness, Desire, Knowledge, Ability, Reinforcement, and asks which of the five is missing for a specific person.

What it is good for: diagnosis. It separates "they do not know" from "they do not want to" from "they cannot". Those three failures look identical in a compliance report and need completely different responses.

What it is bad at: anything above the individual. It tells you nothing about whether the safety report still matches the installation.

Bridges: the change is not the transition

William Bridges drew the distinction most safety professionals recognise immediately. The change is the external event, the new procedure goes live on the first of the month. The transition is the internal process, ending the old way, a messy middle, then a new beginning.

What it is good for: timing. It explains why the weeks after go live are the weeks with the most workarounds, and why that is predictable rather than a sign the change failed. The grief curve sometimes bolted onto this comes from Kübler-Ross and was never written about work, so use it loosely or not at all.

Systems models: 7-S and its relatives

The McKinsey 7-S framework, and systems thinking more broadly, makes one point: change one element and the others have to move with it. Strategy, structure, systems, staff, skills, style, shared values.

What it is good for: catching the knock on effects. A new inspection round changes who is competent to do it, who reviews the findings, which procedure describes it, and which document now needs updating.

What it is bad at: telling you what to do on Monday.

The theory that is missing from the theory

None of the models above has anything to say about the question an inspector will ask you.

Not "did your people adopt the change", but "is the change traceable from the moment it was proposed to the moment its effects were verified". That is a different discipline, and in process safety it has a name and a procedure.

A workable MOC procedure usually contains the same elements, whatever the site calls them:

• Initiation and screening. Something is proposed. Someone decides whether this is a change at all, and whether it is temporary or permanent. Temporary changes that quietly become permanent are a classic source of drift.
• Technical and risk review. What scenarios does this touch, which barriers are involved, which studies and bowties are affected.
• Approval at the right level. Who is allowed to say yes, and on what basis.
• Implementation. The physical or procedural work.
• Documentation follow through. The safety report, the PBZO document, procedures, drawings, labels, training material, emergency plans. This is the step that falls over most often.
• Communication and competence. The people who will work with it know, and can.
• Closure and verification. Someone confirms the change did what it was supposed to do, and that nothing was left half finished.
• Periodic review. The change is still there a year later, and still makes sense.

The organisational theories govern the sixth and seventh of those. The rest is process, and process is where most of the pain lives.

Where change actually goes wrong

In practice the failures are boring and repeated. A modification is implemented and the safety report is not updated, so a later inspection finds a mismatch nobody intended. A temporary bypass outlives the person who installed it. The technical specialist who explained something verbally three years ago has left, and what was once a conversation is now a finding. Generic measures written years ago are still in the studies, while the standards they referred to have moved on.

None of that is resistance to change. It is a change process with no memory.

That distinction matters for how you fix it. If the problem is adoption, you work on awareness, ability and obstacles. If the problem is memory and traceability, more communication will not help you, and neither will a model. You need the change record, the affected documents and the verification to sit in one chain rather than in six places. We wrote at more length about why that chain is hard to build in generic tooling in why generic safety management software falls short for Seveso III companies.

What to do with all of this

A practical way to use the theories without drowning in them:

1. Name which problem you have. Adoption, or traceability. They look the same in a management review and they are not.
2. Use ADKAR for people, MOC for changes. One per person, one per change. Do not run a cultural programme to fix a documentation gap.
3. Make the obstacle list before the communication plan. Kotter's most useful step is the one about removing obstacles, and it is usually the cheapest.
4. Decide what "done" means in advance. The next colleague should not have to assume anything. If documentation, settings, labels and test results are part of done, write that into the procedure rather than into people's heads.
5. Close the loop on purpose. Plan and Do are the easy half. Check and Act are where changes are verified and where drift is caught, which is the subject of our piece on building and running PDCA workflows in HSE management.
6. Review temporary changes on a fixed rhythm. Not because something will be wrong, but because something usually is.

If you want the wider picture of how MOC sits next to studies, evidence and corrective actions, our overview of compliance management covers the surrounding elements.

A closing thought

The theories are useful, and they are all about getting people to a new way of working. Almost none of them ask what the organisation should be able to prove afterwards. In a safety management system, that second question is the one that comes back at you.

At Capptions we build inspection and audit software, custom forms and workflows, and corrective action tracking, and we spend most of our time with teams who are in the middle of exactly this. No system takes the judgement off your plate, and we are not going to pretend otherwise. If you are working through an MOC procedure or an update cycle right now and want to compare notes on where it leaks, send me a message and we will look at it together.

Which of the two problems is yours this quarter: people not working to the change, or nobody able to show what the change did?