The basic idea of the process is to take the deliverables which have been internally checked in process 8.3 Control Quality to see whether they meet the customer’s requirements, and then actually present them to the customer for formal acceptance, which means to validate them. These are the interim deliverables, of course; the final deliverables are formally accepted as part of the 4.7. Close Project or Phase Process.
NOTE: The 5th Edition PMBOK® reverses the definitions of verify and validate scope that were used in the 4th Edition. In the 4th Edition, validate means to check internally and to verify means to verify with the customer; in the 5th Edition, the reverse is true.
Here’s a summary of the inputs, tools & techniques, and outputs of the Validate Scope process.
|5.5 VALIDATE SCOPE|
|1.||Project Management Plan||Contains Scope Management Plan which specifies how formal acceptance of the completed project deliverables will be obtained.|
|2.||Requirements Documentation||Lists all the project, product, and other types of requirements for the project and product, along with their acceptance criteria.|
|3.||Requirements traceability matrix||Links requirements to their origin and tracks them throughout the project life cycle.|
|4.||Verified deliverables||Completed and checked internally for correctness through the Control Quality process.|
|5..||Work performance data||Includes degree of compliance with requirements, number and severity of nonconformities.|
|TOOLS & TECHNIQUES|
|1.||Inspection||Measuring, examining, and validating to determine whether work and deliverables meet requirements and product acceptance criteria.|
|2.||Group decision-making techniques||Used to reach a conclusion when the validation is performed by the project team and other stakeholders.|
|1.||Accepted deliverables||Deliverables that meet acceptance criteria are formally signed off and approved by the sponsor or customer.|
|2.||Change requests||Deliverables that do not meet acceptance criteria are documented, along with the reasons for their nonconformance. These deliverables may require a change request for defect repair.|
|3.||Work performance information||Information about which deliverables have been started, their progress, which deliverables have been finished, or which have been accepted.|
|4.||Project documents updates||Documents that define the product or report status on product completion.|
If the deliverables are accepted, then the project continues as before; however, if the deliverables are not accepted, then change requests are generated which will bring the deliverables in line with the customer’s requirements.
The next process is 5.6 Control Scope, which is covered in the next post.
Filed under: Uncategorized |