In project management, verification and validation ensure that you build the right product correctly. Verification helps you develop the product according to the specifications mentioned in the project plan, and validation ensures that the product meets customers’ requirements and that they are satisfied with the product.
In today’s article, I will explain the difference between verification and validation.
Let’s get started.
What is Verification?
Verification is about checking whether the product meets the required standards and specifications. It involves reviewing and testing deliverables to ensure they are correct and complete according to the specified requirements.
ISO 9001: 2015 defines verification as follows: Design verification is confirmation by examination and provision of objective evidence that the specified input requirements have been fulfilled. Verification activities include modeling, simulations, alternative calculations, comparison with other proven designs, experiments, tests, and specialist technical reviews.
Verification ensures that the developed product is error-free and meets its quality requirements. It helps you build the product correctly. It is an objective process. All quality requirements must be well documented for proper measurement, analysis, and testing.
Verification is also known as static testing.
Verification Benefits
A few benefits of verification are:
- Ensures Quality: Confirms that the product meets predefined standards and specifications.
- Reduces Errors: Helps identify and fix issues early in product development, thus reducing costly fixes later.
- Improves Consistency: Ensures that project outputs align with the project plan and requirements.
- Facilitates Compliance: Ensures adherence to industry standards and regulations.
What is Validation?
Validation confirms that the product meets the customers’ needs and expectations. It involves checking whether the final product is what the customer wants and whether it solves the problem or fulfills its intended purpose.
ISO 9001: 2015 defines the validation as follows: “To ensure that the resulting product can meet the requirements for the specified application or intended use, where known. Design validation is similar to verification—except this time, you should check the designed product under actual use conditions.”
Unlike verification, which focuses on whether the product is defect-free, validation ensures that the product is valuable and useful to users.
Validation is about building the right product. It is a subjective process that shows how well the product has fulfilled the customer’s requirements. Modeling, simulation, and user evaluation are validation techniques.
Validation is also known as dynamic testing.
Validation Benefits
A few benefits of validation are:
- Confirms User Satisfaction: Ensures that the product meets the end-users’ needs and expectations.
- Enhances Value: Confirms that the product or service solves the problem or fulfills its intended purpose.
- Reduces Risk: Helps avoid costly changes or rework by validating requirements early.
- Supports Acceptance: Increases the likelihood of user acceptance and successful deployment.
Differences Between Verification and Validation
The following table shows the key difference between verification and validation:
| Feature | Verification | Validation |
| Purpose | To ensure that the product meets the specifications | To ensure that the product meets user needs |
| Focus | Correctness of deliverables against requirements | Suitability of deliverables for their intended use |
| Questions Answered | Is the product being built correctly? | Is the right product being built? |
| Tools | Reviews, inspections, and testing | User testing, feedback, and acceptance |
| Timing | Done throughout the product-development process | Done at the end of the product-development process or during the pilot phases |
Often, a product can pass verification but fail validation. For example, a company developed a cell phone that passed through the verification process. However, when they launched it, the customer response was not positive. The product failed, meaning it is not validated.
Real-World Example of Verification Vs Validation
Let’s start with an example of verification.
Verification Example
Let’s say that you are developing a cell phone. You have conducted market research and collected all the information on the required features. You develop a plan to build the product, completing all the requirements and developing the product accordingly.
The production process has started. You inspect it to ensure that everything is going according to plan.
If the product meets requirements, this means it has been verified.
Verification ensures that the product is of high quality and error-free. This is a thoroughly objective process; however, this does not mean the product will meet customers’ requirements, which is where validation comes in.
Validation Example
Let’s say you are developing a cell phone for your customers. You have conducted market research and determined what features the item should have. Then, you started the production.
However, when the cell phone is finally launched, it does not get the expected market response. Eventually, it fails.
In this situation, you would say that the product could not be validated because it failed to meet the customers’ expectations. Validation is about product testing, and it is a fundamentally subjective process.
Frequently Asked Questions
Q: Which process comes first: verification or validation?
Verification is done while developing the product, and validation is done after the product is built and delivered to the client. Therefore, verification comes first.
Q: Why is verification important in project management?
Verification is crucial because it helps ensure products are built correctly according to the specifications. It reduces errors and inconsistencies, ensuring quality and compliance.
Q: Why is validation important in project management?
Validation is important because it ensures that the final product delivers value to the end-users. It confirms that the product addresses user needs and expectations, increasing the likelihood of successful adoption and satisfaction.
Q: How can you effectively verify and validate your work?
You can ensure effective verification and validation by clearly defining requirements, establishing thorough testing and review processes, and engaging end-users for feedback. Regular communication and documentation of results are also key.
Summary
Verification and validation are independent processes. The project manager uses these processes to ensure that they have correctly built the right product. Verification is about conformance to specifications; it is an internal process. Validation is about customer expectations, and it is often an external, subjective process.
Further Readings:
This topic is important from a PMP exam point of view.
I am Mohammad Fahad Usmani, B.E. PMP, PMI-RMP. I have been blogging on project management topics since 2011. To date, thousands of professionals have passed the PMP exam using my resources.
Validation is about products while verification is about the process. What do you think about my summary of this article?
In verification you check if the product is developed as designed and requested by stakeholders.
Good example with the cell phone. Take the Microsoft Office Phone for example.
The project could be successful in terms of building the phone, but customers did not like the phone and it was not supported; therefore, as a product, it failed.
So, the phone was build correctly; meaning the phone was verified. The phone was a commercial failure, therefore it was not validated.
The subcontractor who built the phone had a successful project. The customer who had a failed product also had a successful product creation project, but a failed product lifecycle experience.
The point of confusion could be: don’t confuse the product lifecycle failure with the project success.
Do I have this correct?
Well said David.
Terms to be truly useful need to be have singular understanding when used. For validation and verification we have run into issues with interpretation by individuals familiar with systems engineering, but as much with people not familiar w/SE since they typically don’t have a clue.
At times we overthink a definition to the point the definition becomes confusing to the majority of individuals that hear the term. A good example is ‘Risk’. A layman using English langue hears the term ‘Risk’ and thinks something bad can happen. Someone following PMI terminology hears the term ‘Risk’ and ‘may’ think ‘threats & opportunities’.
So, with V&V terms, some additional work is needed to either make them very clear and distinguishable, or use terms no one knows and define them.
Well said Bill.
Verification
Verification is about building the thing in right way. <— huh? Building the thing in right way is not grammatically correct.
Corrected.
Can you tell me the difference between Subjective Process and Objective Process
In objective process you have measurable criteria, and in subjective process they are open to discussion and depends on the party.
And also how configuration mgmt. differs from project scope mgmt. as both addresses the actual result, product or service of the project.
Hi Fahad, ( I hope you do not get bored with so many questions) How change management differs from the perform integrated change control?
Thank you again
Hi Fahad, continued form the previous question from me on validated changes question, in 4.4.1.1 on page on.90 it says ” approved changes that results from the Perf. Inte. Change Control process require validation to ensure that the change was appropriately implemented. A validated change provides the necessary data to confirm that the change was appropriately executed.” To me it seems that an approved change request gets implemented through Direct & Manage project work & through Control quality deliverables ( which is the resultant of either first time work or approved change request work) gets validated & also the control quality validates that the approved change to the original plan worked well, delivered the validated result & hence should update proj. mgmt. plan & proje docu & should be archived as best practice for future references. Did I understand the cycle correctly? Pl. share your though.
Hi Fahad, could you pl. shed more light on Validated changes which is an O/P from Control Quality process & I/P to M & C Process. As per PMBOK page 262 it says that ” any changed or repaired items are inspected & will be either accepted or rejected before notification of the decision is provided. Rejected item may require rework.” By the definition it should go to validate scope (same as verified deliverables) unless if the only difference between verified deliverable & verified changes is the former deals with the result of the project & later deals with processes?? But once again the doubt is the definition itself which as above says that ” any changed or repaired items are inspected’.
Kindly share your thoughts at the earliest.
Hi Fahad,
You have not replied to this important question. I too have questions regarding Validated Changes. Your thoughts and explanations would be much appreciated.
Anil
I did not understand the above question. What is your doubt?
Thanks for this explanation. Quick questions:
1. Verification – control quality?
2. Validation – Scope management?
3. Is verification performed before validation or concurrently with validation?
1) Verification include quality control and quality assurance.
2) Validation include scope management plus quality assurance and control.
3) You can say, these are compliment to each other.