Validation Ensures the Right Product Is Designed & Developed (illustrated)

Recall the overall objective of product development is to develop the ‘right product’ and to develop the “product right”.  In previous articles, we defined validation as a continuous process throughout product development to establish complete and correct requirements.  Consider the following illustration: 

Valid requirements represent the voice of the customer and acceptability of the product.  Product performance represents the “voice of” the design and process.  Product performance outside of spec limits result in defects and rework (it is not the right product to meet customer needs).

Let’s start with the easiest (and arguably, most likely) scenario:  A product requirement isn’t known with good specificity.  There is pressure to deliver the product to the customer and the customer expects a ‘fully qualified” product.  Some validation doesn’t start until testing in the customers environment.

Parameters without clear specification limits result in rejects.  Specification limits are clarified and escapes are prevented, however, defects and rework at the factory is now necessary.  A redesign or process improvement is needed.  Meanwhile, engineering has moved on to new products and may leave this activity up to operations or contract manufacturers to figure-out.  This is illustrated as follows, with the diagram now showing valid specification limits:

This messy scenario can be avoided with (1) valid requirements and specification limits before the design phase and (2) statistical design methodologies.  Here, validation starts with product requirements, not a post-development phase-gate.  This also enables statistical design to consider optimizing tolerances to fall within the (valid) spec limits; a design according to design targets and process capability (mean and variability).

This illustrates an optimized design, verified according to valid requirements and an acceptably small percentage of defects.  It is the right product and the product is built right (designed and manufactured) with few defects.

Consider another example involving specification limits that are unnecessarily tight:    

With over-specified limits, we can still build the product “right” but with an unnecessarily expensive design or process.  This is the product and process cost aspect of requirements validation…recall our goal is to maximize customer value and minimize cost.   

Validation is a continuous process throughout product development to establish complete and correct requirements.

There should be no pretending the product is the right product, or maximizes customer value.  Starting validation early in the product development process mitigates this risk. The goal is to verify the design and process vs. valid requirements to the maximum extent possible.

Meanwhile, not every requirement can be considered complete and correct until testing by the customer, in the customers environment (especially where the customers environment is not duplicatable internally). This subset of requirements and testing represents risk and should therefore be minimized and mitigated accordingly. The goal remains the same for this subset of testing: clarify acceptability by the customer, in the customers environment, clarify the corresponding requirements and show that the product meets these requirements. 

A suggestion for the post-development product lifecycle phases might therefore comprise of the following:

Here we’re acknowledging validation testing as an activity that occurs during (internal) qualification and extends into “limited availability” where the product is provided to a few external customers environments. Of course, if full validation is achieved in qualification, then there is less risk mitigated by limiting the availability of the product. Therefore, another benefit of robust validation is a shorter limited availability phase.     

Using the “Qualification” terminology for the post-development phase should help prevent a mindset whereby validation isn’t viewed continuous process starting with requirements and throughout product development.

Conversely, if the “Validation” terminology is used as post-development phase, this may normalize a design-by-test and trial and error approach to product development. At the very least, starting validation with requirements would help minimize product development risk.