ISO 9001: Understanding the Difference Between Validation and Verification

Perhaps one of the most misunderstood pair of terms in ISO 9001, is Design and Development Verification, and Design and Development Validation. Since the terms are so similar in normal, non-ISO usage, it is difficult to understand the difference that the ISO standard intends. From sections 7.3.5 (ISO 9001-2008), we know that verification is to ensure that the design and development outputs have met the design and development input requirements. From sections 7.3.6, we know that validation is to ensure that the resulting product is capable of meeting the requirements for the specified application or intended use, where known. So how is it possible for something to be verified but not validated? Or validated, but not verified? The answer lies in what is really being examined in each case. In the case of verification, only the inputs and outputs of the design and development process are being examined. While for validation, the requirement is for the specified application or intended use. The following example will clarify how a product might be verified but not validated: An organization makes radios, and a customer requests a custom radio that will only operate on two specific frequencies. Unfortunately, during the acceptance of the order, a clerical error is made, and one of the frequencies never makes it onto the order. Engineering designs and develops the radio, unaware of the additional frequency needed. Drawings are produced, and production builds to those drawings. The radios are tested to the specifications, and meet all specifications. Thus, we can say that the output requirements do, indeed, meet the input requirements (as understood by the organization), and the design is thus verified. However, have we met Design and Development Validation? Of course not- the customer cannot use the radio for what it was intended for, with the extra frequency.

Permission is granted by Jim McSpiritt 24-Jan-12 to use, share, and modify this material for commercial and non-commercial use as long as this license is included in any copy.

It is more unusual for a product to be validated, but not verified. Certainly, if a product does not do what the customer wants, the organization will hear about it, but could a product be produced which was does what the customer wants, but was not verified? One scenario where this could happen could be a case where the verification of a requirement was not performed due to an internal error within the organization, but a particular customer never uses a product in a certain way, and the lack of a requirement is never uncovered. This might seem like a so what? situation, since the customer doesnt care, but should the organization care about the requirement anyway? This example shows why validation without verification, even in a scenario as above, could matter: An organization makes a plastic part, and in the original requirement from the customer, a low temperature requirement was listed with the initial specifications. During the design and development of the part, verification is not performed of the inputs and the outputs for design and development. The part is built, validated for the intended use, and shipped, and the customer is satisfied. Unfortunately, unknown to the organization, the low temperature requirement had been included in the original specifications specifically for future products made by the customer, and eventually the customer starts using the part where the part will be exposed to low temperatures. The organization has been supplying the part for years with little or no returns. Suddenly, a flood of returns occurs for this part. What has happened? Are the organizations machines failing? Is it operator error? Is a different plastic being used? Has the plastic supplier changed? None of these- it is lack of verification during the design and development at the beginning of the manufacture of this part. This should illustrate both the difference between verification and validation, as well as why these clauses exist in the ISO standard, and why they are so important. Verification can address both internal errors (like the clerical error in the radio example) or external errors (such as vague or inadequate specifications). Validation can address both internal errors (the organization failed to understand what the customer needed) or external errors (the customer didnt understand itself what was needed).

Permission is granted by Jim McSpiritt 24-Jan-12 to use, share, and modify this material for commercial and non-commercial use as long as this license is included in any copy.