Organisational Change & Adoption
Making an organisational change actually take: stakeholder analysis, impact assessment, readiness, communication, participation, transition support, reinforcement, and whether the intended benefit arrived. A change that is implemented but not adopted produces the worst of both states — the old way is prohibited and the new way is not established, so people improvise in the gap. In regulated work, that gap is where undocumented practice appears.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 21 LINKSA change is not implemented when it is approved but when people work the new way — and the gap between those two moments is where a validated process and its documented version quietly diverge.
06 · QUALITY MATURITY — ORGANISATIONAL CHANGE & ADOPTION, REACTIVE TO ADAPTIVE
Change is announced and documents are issued. Adoption is assumed from the training completion record.
Implementation plans include communication and training, and effectiveness is judged by whether the plan completed.
Adoption is verified in practice — the work is observed against the new procedure — and the change is not closed until it is.
Resistance is treated as information: where people did not adopt, the reason is examined before the change is enforced.
Changes are designed with the people who will work them, so adoption is a consequence of the design rather than a phase after it.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 4
Derived from the 4 standards SPEQ maps to this subject, across 2 regulatory bodies: EMA, ICH.
RECORDS & OBJECTIVE EVIDENCE
- Change implementation plans including how adoption will be verified
- Verification that the new way is being worked, performed after implementation
- Records of where practice diverged from the change, and what was done
- Effectiveness checks that examined behaviour rather than document issue
- Evidence of end-user involvement in designing the change
COMMON INSPECTION FINDINGS
- Changes closed on document issue and training completion with no adoption check
- Practice diverging from the current procedure, discovered at audit rather than at implementation
- Workarounds in routine use because the changed process is harder than the old one
- Effectiveness checks that re-read the document rather than watching the work
- Repeated changes to the same process, each addressing symptoms of the previous one
Implemented and adopted are different states
Change control tracks implementation: the procedure is issued, the system is configured, training is assigned, the record is closed. None of that establishes that the new way is how the work is now done. Between those two states sits a period in which the old method is prohibited and the new one is not yet fluent, and the work still has to happen.
What fills that gap is improvisation, and in a regulated environment improvisation is undocumented practice. This is why the deviation rate rises after a significant change even when the change was correct and well executed — the rise is a property of the transition, not evidence that the change was wrong, and it is predictable enough to be planned for.
The people who will absorb the change should shape it
Changes designed by the function that owns the problem and delivered to the function that will live with them fail at a predictable rate, because the designers cannot see the constraints of the receiving work. A new documentation requirement that adds four minutes per batch is trivial at a desk and material on a line running to takt.
Participation is not consultation theatre; it is the mechanism by which those constraints are discovered while the design can still change. It also has a second effect that matters more in regulated environments than elsewhere: people who helped design a control understand what it protects against, which is the difference between a step followed and a step understood.
Regulated change has two impact assessments and usually runs one
Every significant organisational change carries a regulatory-impact question — does this alter a validated state, a filed process, a defined responsibility, a qualification requirement — and an adoption question: can the people affected actually work this way, and what will they do while they are learning. Change control reliably asks the first. The second is usually nobody’s.
ICH Q12 frames change management as a lifecycle capability rather than an approval gate, and ICH Q10 places change management among the enablers of the quality system. Both point at the same thing: a change that is approved and not adopted has not been managed, it has been authorised.
SPEQ interpretation — check that the benefit arrived
Change records are closed on implementation. Almost none are reopened to ask whether the intended benefit materialised — whether the deviation the change was meant to prevent stopped occurring, whether the cycle time actually fell, whether the risk the change addressed is measurably lower.
That check is cheap, and its absence has a compounding effect: an organisation that never verifies benefit accumulates changes that added burden without producing the improvement that justified them, and it has no basis for removing any of them. A defined benefit-realisation check at a stated interval after implementation is the only mechanism that lets a control be retired for good reason rather than by neglect.
FREQUENTLY ASKED
Why does the deviation rate rise after a well-executed change?
Because implementation and adoption are different states, and between them the old method is prohibited while the new one is not yet fluent. The work still has to happen, so people improvise — which in a regulated environment is undocumented practice. The rise is a property of the transition and is predictable enough to plan for.
Why involve the affected function in designing the change?
Because the designing function cannot see the constraints of the receiving work — a documentation step that is trivial at a desk can be material on a line running to takt. Participation surfaces those while the design can still change, and people who helped design a control understand what it protects against.
What does change control usually not ask?
Whether the people affected can actually work this way, and what they will do while they are learning. The regulatory-impact question is asked reliably; the adoption question is usually nobody’s. A change approved and not adopted has been authorised rather than managed.
Why check whether the benefit arrived?
Because without it an organisation accumulates changes that added burden without producing the improvement that justified them, and has no basis for removing any. A benefit-realisation check at a stated interval after implementation is what allows a control to be retired for a reason rather than by neglect.