Validation proves that a process does the same thing every time. It cannot tell you whether the process was a good idea. That is what development is for, and skipping it is the most expensive mistake in a kit launch.
The order people get backwards
A launch date arrives, someone asks for validation, and a protocol gets written against a process that has never actually been run at pace by the people who will run it. Three qualification lots get built under unusually careful conditions, everything passes, and the process is declared validated.
Then production starts, and the yield does not match, the cycle time does not match, and the defect modes that show up were never in the protocol because nobody had seen them yet. Now you are running a change control against a process you just validated, which is slower and more expensive than developing it properly would have been.
The order is not a preference. Validation is a confirmation activity. It has nothing to confirm until the process exists.
What development actually produces
Development is where you find out what the process is. It should end with a set of concrete answers, and if you cannot produce them you are not ready:
- The actual sequence of operations, in the order a person performs them, at a real station
- The tooling, fixtures and jigs that make the sequence repeatable rather than dependent on one skilled individual
- The parameters that matter and the range each one can move in without breaking the output
- The failure modes you found by breaking it on purpose, and what each one looks like to an operator
- Cycle time and yield at something close to production pace, not at demonstration pace
- The in-process checks, positioned where they catch a failure early rather than at the end
- The training content, because a process only one person can run is not a process
Most of that comes from building things badly on purpose. Run it with the wrong component orientation. Run it at the end of a shift. Run it with the tolerance stack at both extremes. Development is cheap failure, deliberately purchased, so that production failure does not have to be.
What validation is actually for
Once the process exists, validation answers a narrower question: does this defined process, run by trained people, on this equipment, in this environment, produce conforming output reproducibly?
The familiar structure follows from that. Installation qualification confirms the equipment is what you said and installed the way you said. Operational qualification confirms it performs across the operating range you defined. Performance qualification confirms the whole thing holds together over multiple runs under production conditions.
All three depend on a definition that development produced. Operational qualification against an operating range nobody established is a form, not a test.
How to tell you are validating too early
- The protocol was written by someone who has not watched the process run
- Acceptance criteria were set after the qualification lots were built
- The qualification lots were built by the engineer rather than by the operators
- There is no documented failure mode analysis, because nothing has failed yet
- Nobody can state cycle time and yield without qualifying the answer
- The batch record was created for the validation rather than used during development
Any two of those together and the validation will pass while the process will not hold.
ISO in production, not just on paper
A quality system that lives in a document library and a quality system that lives on the floor look identical during a paper audit and completely different on a Tuesday.
The practical test is whether the person doing the work is following the document. Not whether the document exists, is approved, or is current, though all of those matter. Whether the operator at the station is doing what it says, and whether the document describes what they actually do. When those two drift apart, the document is usually the thing that is wrong, and the fix is to go watch the work and rewrite it.
That drift is exactly what development prevents. A procedure written from a developed process describes reality, because reality is where it came from. A procedure written to satisfy a validation requirement describes an intention, and intentions drift.
How to sequence a launch
- Define the product and the acceptance criteria for the finished kit
- Develop the process against those criteria, including deliberate failure testing
- Write the procedure from the developed process, at the station, with the operators
- Train, and confirm the training took by watching rather than by signature
- Validate the defined process
- Move to production with the in-process checks and the sampling plan already in place
- Feed production findings back through change control, which is now a small mechanism rather than a rescue
The compressed version does not fail loudly at launch. It fails three months in, as a yield problem nobody can explain, and the investigation lands in the same place every time.
Related reading: Taking a collection device from prototype to pilot and AQL, sampling plans and the 100 percent inspection myth.
Development first, then validation. The order is not bureaucratic, it is the difference between a process that passes and a process that holds.
