The Dreaded Design Control

Everyone that works in product development knows the dread words, "design control." If we set the Wayback machine for 1985 we will find that design controls, as the ISO and FDA expressed them in their first attempts, were developed based on that absurdly inane academic development model called the "cascade" model. I love academics for a lot of things, but letting a room full of PhDs write rules is almost as dangerous as letting the lawyers do it — both groups are too attached to big clean ideas and casuistry.

Back to the cascade model, which is often diagrammed as a little stream flowing from the top left to the bottom right through a serious of pools. Design inputs are written, then they get approved. Next is the execution phase with verifications, and at the end you have formal design review and the results are approved. Then product validation. Review. Approval. Manufacturing Transfer. Review. Approval.

Product development has NEVER worked like that. I learned drafting in the days when the top end engineering workstation was a Vemco Mark V on an 8' power table (I still have it). Even in that terrible dark age, when a rapid prototype might be made with cardboard and an X-acto knife, we didn't do serial development. So why is it that many years later, every design control system I see is written as if projects were sequential. Input. DR1. Output. DR2. Validation. DR3. Transfer. DR4.

The thing is, ISO 13485 and the FDA’s 21 CFR 820.30 don’t mandate a waterflow model. Read carefully and you find that the activities are expected, along with documentation of the activities, but you are allowed to design your process for design control (ahem, design realization) so that it is an effective and realistic tool which is also compliant.

"The organization shall establish documented procedures for design and development." So establish, or change, your procedures to enable the project team to achieve the objectives in this real and messy world.