Chapter 1 paragraph 1.4(xi) requires approval 'prior to implementation'. Most change control failures cited by inspectors are, at bottom, sequence failures: something was implemented before it was approved, used before it was verified, or released before a pre-requisite was complete. The dates on the record tell the story, and the record cannot be argued with.
Two approvals, not one
A well-designed change control has two distinct approval points. The first, pre-approval, follows the impact assessment and says: this change is acceptable in principle, this is the classification, and these are the actions that must be completed before it goes live. The second, implementation approval or go-live approval, follows the completion of those actions and says: the pre-requisites are done, the evidence is attached, the change may now be used. Collapsing the two into one signature creates the situation where a change is 'approved' and everyone assumes it can be used, when half the action plan is still open.
- Pre-approval: QA and the affected functions approve the assessment, the classification, the risk assessment and the action plan. Nothing is changed yet.
- Implementation: the action plan is executed. Documents are revised and approved, training is delivered, qualification and validation activities are performed and reported, regulatory submissions are made and their status tracked, suppliers and customers are notified.
- Go-live approval: QA confirms each pre-requisite is complete with evidence, confirms any regulatory or customer constraint is satisfied, and authorises use of the change. The date of this approval is the date after which the change may appear in commercial product.
- Verification: after go-live, confirmation that what was implemented is what was approved, that the documentation reflects the new state, and that the process is running as expected.
The action plan
The action plan is the list of things that must happen, in order, with owners and target dates, and with a distinction between actions that gate go-live and actions that can follow it. Gating actions typically include qualification and validation, document approval, training of the people who will operate the changed process, regulatory clearance where the classification requires it, quality agreement notifications, and physical verification that the change is installed correctly. Post-go-live actions might include long-term stability, effectiveness monitoring, and archiving the old version.
Implementing in a running plant
Changes to equipment and systems in use need a plan for the transition: what is the last batch on the old state, when does the equipment come out of service, how is the old version of the document withdrawn, what happens to inventory of the old material. The record should show which batches were made before and after the change, because that is the first question in any later investigation and the first question a PQR reviewer asks. For changes with regulatory constraints, the plan should include how batches made during the waiting period are held or diverted to markets where the change is already permitted.
Verification: what was done is what was approved
Verification is often confused with the effectiveness check. They are different. Verification asks whether the implementation matches the approved change: the correct part was fitted, the parameter was set to the approved value, the software version installed is the one tested, the SOP in use is the approved revision, the P&ID was updated. It is done immediately after implementation, by someone other than the implementer where practical, and it is evidenced by the qualification report, the as-built drawing, the configuration record or a signed inspection. The effectiveness check, which comes later, asks whether the change achieved its purpose.
Dates, and what they prove
An inspector reading a change record puts the dates in order: raised, assessed, pre-approved, actions completed, go-live approved, first use, verified, effectiveness checked, closed. If any pair is in the wrong order, the sequence failed. The commonest inversions are first use before go-live approval, training after first use, document approval after first use, and regulatory notification after first use for a change that required prior notification. These are not paperwork findings. They are evidence that the system did not control the change.
Changes that do not go to plan
Implementation reveals things the assessment did not anticipate. The procedure should say what happens: the change is put on hold, the assessment is revised, the revision is approved before work resumes. What must not happen is the change being adjusted in the field and the record left as it was. If the change is abandoned, the record should say so, describe any partial implementation and how it was reversed, and be closed as withdrawn rather than left open indefinitely. Module 4 of the course works through the action plan and the two-approval model on a real equipment change, including the go-live checklist that QA should run.