Verification & Validation
When I was in college training to become an engineer one of my professors told me communication was 90% of the job. I didn’t believe him at the time because the majority of my time in class and after class was spent doing calculations. Boy was I wrong. Over two decades later I believe he was being gentle with a 90% estimate. Today good communication is more than 99% of my time. So it is critical we choose the right words when communicating with others. Two words I hear interchanged all of the time are verification and validation. These words have a lot in common, and in the dictionary they are even listed as synonyms. However in engineering they have different meanings that are important when dealing with product risk. Since I find myself reminding people of the correct use of these words I thought it would be a worthwhile subject to write about.
For this article lets assume we are introducing a new product with significant risk and therefore we will use a two phase product introduction program (Program contains both Prototype phase and Pilot phase).
First off let’s talk about what it means to verify something. The dictionary definition is; to make sure or demonstrate that (something) is true, accurate, or justified. Verification is what we do when we have an assumption we want to prove. So when I create a design that has a required output, I will run a test on that design to ensure it meets the required output and performs as it should. I verify/prove the design meets its intent.
If you are testing to prove something is true or not use verify.
As engineers we have lots of ways we can verify a design. We can verify through calculations that we are not breaking any laws of physics. We can build virtual models of the design that show it will fit in the space provided. We can build physical models and test those models to ensure they meet the design specifications. All of these are verification activities where the engineer proves the design will meet its intent.
The dictionary definition of validate is to, demonstrate or support the truth or value of something. So validation proves something quite different. It proves the value of the product or process not the requirement which the design was built to. When we validate we sign off and approve at a higher level. Think of this as a customer’s perspective of the design. The customer validates that the design meets their needs. What makes this a bit more confusing is when we validate a process. In this case the engineer is the customer. He/She is validating that the process is capable of making the design consistently to the engineering specification.
If you have a customer who is approving of something use validate.
What this implies is that there is an order to verification and validation. First the customer has a need. Next the engineer translates the customer need into design specifications. Then the engineer verifies the design meets its intent by testing if it meets the design parameters he/she has specified. The Verification is typically completed in the Design and Prototype Phase of a New Product Introduction Program (NPI). Next there should be a validation event where the customer validates or approves the design meets their needs. If the customer’s needs are met, the process that will be used to make the product should be approved or validated by the engineer to ensure it is capable of consistently making the product to specification. This is usually done in the Pilot phase of the New Product Introduction Program.
One might argue that verification is “good enough”, but that assumes the engineer translated the need into design specifications properly. As a quality manager I have seen this to be a false assumption way to many times. One might also argue that this is just nitpicking at words, but if people understand those words to have different meanings then they can assume customers or engineers have signed off on a design when they have not. It is also common for the business needs to rush the risk mitigation process and attempt a single phase New Product Introduction Process (single phase eliminates the Pilot phase from the program and jumps from Prototype to Production). That is okay if the New Content of the program is low and the amount of risk mitigation required is low, but in this case we are talking about a program with significant risk.
So when deciding whether to use verify or validate think about what the result will be. If you are testing to prove something is true or not use verify. If you have a customer who is approving of something use validate. Good communication starts with those who are conveying the message.
Like it? Leave a comment & feel free to share it!
