Pharma Logistics Dispensing Rollout - inspection instead of quality, and a rubber-stamp change board

Quality planning decides what quality means and how it will be achieved: the standards to be applied, acceptance criteria per deliverable, the quality activities and who performs them, and the review/approval gates. Missing entirely at Pharma Logistics - the only criteria are the words "system working", which are not measurable and cannot be tested.

Quality assurance (QA) is process-focused and preventive: it confirms that the agreed method is being followed consistently - audits, method statements, checklists, peer review of the rollout pack, verification that site 27 is doing what site 4 did. Missing: nothing checks consistency between sites, so variation goes undetected until an incident.

Quality control (QC) is product-focused and detective: inspecting, testing or measuring the output against the acceptance criteria - the 20-prescription check the project manager performs.

What is happening: the project manager is doing QC personally, and only QC. Three consequences:

1. There is nothing to control against - no criteria, so the check cannot fail and therefore proves nothing.
2. The project manager is marking their own work. QC should be independent of the person who built or installed the deliverable; self-inspection at go-live is assurance in name only.
3. Sampling 20 prescriptions at one moment checks the output but not the process, so a printer-integration fault introduced at design can pass site acceptance and surface later.

Fix: write a quality plan with measurable acceptance criteria per site, define QA activities (rollout audits, standard installation checklist, independent reviewer), and separate QC from the person accountable for delivery.

Evaluation. Twenty-three changes, all approved by the project manager, by email, within a day, with no impact assessment, and 18% scope growth. This is not change control; it is a change log. Three specific defects:

1. No impact assessment. Without analysis of effect on cost, schedule, quality, risk and benefits, approval is an opinion. The third-party printer integration is the direct consequence - nobody weighed the integration risk before saying yes.
2. Wrong decision-maker. The project manager is accountable for delivering the baseline; allowing them to move that baseline unilaterally means there is no control at all. The authority to approve must sit with whoever owns the funds and the business case - the sponsor - above a defined threshold.
3. No baseline discipline. With 18% growth, the original estimates and the business case are now meaningless, and nobody knows the true cost or date.

A proportionate process for 40 sites:

• Single front door: one change request form - what, why, who, urgency.
• Tiered thresholds: minor changes (below, say, £5k and no schedule impact, no safety or regulatory effect) approved by the project manager and logged; anything above, or touching patient safety, regulatory compliance or go-live dates, escalated to the sponsor with a written impact assessment.
• Mandatory impact assessment across scope, time, cost, quality, risk and benefits - one page is enough.
• Decision within a stated turnaround (e.g. 5 working days), so control does not become paralysis across 40 sites.
• Rebaseline and re-communicate after approval, and re-issue the baseline at a defined point so the 18% drift stops growing unnoticed.
• Change board need only be the sponsor plus the operations lead; a full board for a 40-site rollout would be disproportionate if thresholds are set sensibly.

Risk vs issue. A risk is an uncertain future event that might occur and would affect objectives if it did; an issue is something that has happened and is now affecting the project, requiring management action rather than analysis. "Third-party printer incompatibility" was a risk for four months. It became an issue the moment 60 prescriptions printed with the wrong dosage.

How it should have been handled as a risk. Registration is not management. A live risk needs: a named owner who is accountable for the response (here, the integration lead - not the project manager by default), an assessed probability and impact (impact clearly at the patient-safety end of the scale), a defined response (e.g. a compatibility test before any site goes live with the third party, plus a fallback to the incumbent printer), and a trigger - a supplier confirmation, a test result, a first site go-live. A risk with no owner has no response; it is a wish.

What must happen now:

1. Containment first. Site 12 dispensing suspended or reverted to the approved fallback; identify and contact every patient affected; check all 39 other sites for the same printer configuration. Safety outranks schedule.
2. Transfer to the issue log - assigned owner, actions, target resolution, escalation.
3. Escalate to the sponsor and beyond - a dosage error is a regulatory matter; the clinical/governance route must be triggered, not just the project route.
4. Treat as evidence, not an accident: review every approved change for similar unassessed integration risk, and check whether the missing quality plan allowed a design fault to pass site acceptance.
5. Update the risk register - the risk was real, was logged, and was ignored. That is the finding the post-incident review should lead with.