01-Verification and Validation of Deliverables
01-Verification and Validation of Deliverables
01-Verification and Validation of Deliverables
Verification is the key output from the Control Quality process in the PMBOK® Guide and is focused on
ensuring a product service or result complies with the relevant requirements and specifications. This
function may involve specific tests and inspections, as well as evaluating1 any test records and inspection
logs completed during the course of the work. At the end of this process you have verified deliverables.
Validation is a scope management process in the PMBOK® Guide focused on formalising the acceptance of
the project deliverables by the client. You have accepted deliverables at the end of this process.
The problem with separating verification and validation is the two functions, normally referred to by
engineers as V&V, are in reality part of a continuum. Verification looks at the basics (structure) of the item
being verified such as, performance, design, functionality, and checking that all of the specified tests and
inspections were completed correctly; to make sure the deliverable meets the requirements that drove the
1 www.mosaicprojects.com.au
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
For more White Papers see: http://www.mosaicprojects.com.au/WhitePapers.html
creation of the item. Validation goes beyond the basics to assess how well the item addresses your
stakeholder’s needs and expectations while operating in the intended operational environment.
V&V can be a function that is internal to the project team, conducted by independent experts (often called
IV&V where I = Independent) may focus on components or be focused on the integrated functioning of an
organisational system either as a competed unit, or after the deliverable has incorporated into its operating
environment (also called IV&V where I = Integrated).
Regardless of the acronym used2, and the people involved, V&V is not a one-off function; rather it is a
continuum working towards the final acceptance of the product by the customer. In a simplified view of a
typical ‘PMBOK Project’ the requirements are gathered3, the scope is defined (a design process) and then
the required ‘system’ is built and tested. This process is basically the same for a building new hotel or
developing a software upgrade using the ‘waterfall approach’. However, regardless of the deliverable
being created, to be sure of receiving the final acceptance of the delivered system at the end of the project
verification and validation need to be planned functions undertaken at regular/appropriate intervals with
the validation element involving the customer and other key stakeholders.
2 A recognised issue is the same acronyms can have different meanings and different acronyms can define essentially
the same process – providing a clear definition of the acronyms used in a project plan is essential to avoid
unnecessary confusion. Some of the more common are:
- V&V - Verification and Validation
- IV&V - Integrated Verification and Validation
- IV&V - Independent Verification and Validation
- ISVV - Independent Software Verification and Validation
- SQA - Software Quality Assurance
- T&E - Test and Evaluation
- ITEA - Integrated Test, Evaluation and Acceptance
3 For more on requirements gathering see:
http://www.mosaicprojects.com.au/WhitePapers/WP1071_Requirements.pdf
2 www.mosaicprojects.com.au
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
For more White Papers see: http://www.mosaicprojects.com.au/WhitePapers.html
These ‘review points’ may represent phase boundaries, contractual hold points and/or gateway review
points4 in the overall project lifecycle, or they may simply be ‘sensible’ points to check work is progressing
correctly in the development of the product.
Requirement Validation confirms by inspection and analysis that the resulting requirement set:
1. Clearly communicates the baselined stakeholder needs and expectations
2. Are in a language understood by the project team; and
3. If the intended project deliverables fulfil the requirements they will meet the intent and needs of
the stakeholders.
Design Validation confirms that the design will result in a system that meets its intended purpose in its
operational environment; and will fulfil the stakeholder needs and expectations that were baselined in the
requirements.
System Review
System Verification asks two questions, did we build the right thing, and did we build it right? Methods
used for system verification include: test, simulation, demonstration, inspection, and analysis of quality
assurance information. The first consideration is to verify that the built deliverable clearly represents the
requirements that drove the design (requirements traceability5), the second is focused on the processes
and components used in the build to verify they meet specifications.
System Validation occurs after verification to make sure the designed, built, and verified system meets its
intended purpose in its operational environment. The focus is on the completed system and how well it
meets the baselined stakeholder needs and expectations that were defined and baselined during the scope
definition phase.
This final validation is much easier to obtain if the client has been involved, or informed, of the flow of V&V
processes throughout the project lifecycle. This is a key stakeholder engagement and communication
processes that needs planning into the flow of the work.
3 www.mosaicprojects.com.au
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
For more White Papers see: http://www.mosaicprojects.com.au/WhitePapers.html
Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.
Alternative Proxies: