CQV Planning Starts in Design: Keeping Qualification Off the Critical Path

On most late pharmaceutical projects, commissioning, qualification, and validation is the last thing to start and the first thing blamed. The blame is misplaced. By the time protocols are being executed, most of the delay was decided months earlier — during design, when nobody was thinking about qualification at all. Here is how to decide it differently.

Why CQV slips

Qualification verifies that a system meets its requirements. That sentence contains two dependencies people routinely underestimate: there have to be requirements written in a testable way, and the design has to be traceable to them. When the URS is vague, the protocol author has to invent acceptance criteria and then negotiate them with quality. When the design has drifted from the URS without anyone recording why, the IQ finds discrepancies that are not deviations but look like them, and every one takes a meeting to close.

Layer on the practical problems — mechanical completion declared with hundreds of open punch items, FAT reports that cannot be leveraged because nobody planned to leverage them, a traceability matrix built after the fact — and the qualification phase absorbs every upstream failure of discipline. It is not slow. It is where the bill comes due.

Decision one: write the URS to be tested

Every user requirement should be a statement that a test can pass or fail. "The vessel shall be cleanable" is not a requirement; "the vessel shall be drainable to less than 100 mL residual and all product-contact surfaces shall be reachable by CIP spray coverage, verified by riboflavin test" is. The quality unit should co-author or approve the URS, because they will approve the protocols that verify it. A URS written this way is the first row of the traceability matrix, and it costs almost nothing compared with what it saves. See how we approach requirements and basis of design.

Decision two: do the impact assessment during design, not after

The system impact assessment — which systems are direct-impact, indirect, or no-impact on product quality — and the component criticality assessment determine what gets qualified and how deeply. Done during design, they let you right-size the qualification scope, decide whether ASTM E2500 risk-based verification or traditional IQ/OQ/PQ fits each system, and identify which design decisions (a shared utility header, an uncontrolled room, a non-sanitary valve) would drag a system into a higher qualification tier for no operational benefit. Done after construction, they can only describe the scope you are already stuck with.

Decision three: treat FAT as a qualification lever

A factory acceptance test is the cheapest place to find a problem: the vendor's shop, with the vendor's technicians, before shipping. It is also, if your quality system allows it and the protocol is written for it, a legitimate source of qualification evidence — instrument calibration, weld documentation, material certificates, functional tests that do not depend on site utilities. Planning FAT during procurement with the qualification protocol in mind can remove weeks from IQ and OQ. Planning it as a formality guarantees you repeat the work on site.

Decision four: run commissioning alongside mechanical completion

Commissioning — the engineering verification that a system is installed and functions as designed — is where problems should be found and fixed, under engineering control, before protocols are executed under quality control. Sites that wait for a contractor to declare mechanical completion and then begin commissioning discover the punch list twice. Sites that walk down systems as they approach completion, classify punch items by criticality, and start pre-commissioning on complete subsystems arrive at qualification with systems that actually work.

Decision five: build the traceability matrix from day one

A requirements traceability matrix maps each URS line to the design element that satisfies it and the test that verifies it. Built from the URS forward, it is a project management tool: it shows which requirements are not yet designed for, which tests are not yet written, and which changes have orphaned a test. Built backward from finished protocols, it is a compliance artifact that proves nothing except that someone had a spreadsheet. The difference is entirely a matter of when you start.

A phase-by-phase checklist

• Concept: identify the quality unit's CQV expectations and the site's qualification approach (E2500 or IQ/OQ/PQ); name a CQV lead now.
• Front-end design: URS written to be tested and approved by quality; preliminary system impact assessment; traceability matrix started.
• Detailed design: component criticality assessment; design qualification review against the URS; C&Q plan and test strategy approved; FAT strategy defined per system.
• Procurement: FAT protocols written to leverage into IQ/OQ; vendor documentation requirements in the purchase order; SAT scope defined.
• Construction: systems walked down as they approach completion; punch items classified; pre-commissioning on complete subsystems; protocol authoring in parallel.
• CQV: execution against approved protocols with deviations managed under quality; turnover packages assembled system by system, not at the end.

The organizational fix

Every item on that list is easy to agree with and hard to do, because it requires someone whose job spans design, construction, and qualification to own it across all three. In most owner organizations that person does not exist; design belongs to engineering, construction to the project manager, and qualification to validation. The fix is a role — an owner's engineer or a CQV lead engaged from design — that carries the thread. Our CQV services are built on exactly that premise: qualification is planned from the first design review, because we have seen what happens when it starts when construction ends.

If a project of yours is heading into design, or already in it, this is the moment to talk.