This is the process of formalizing the acceptance of the completed project deliverables. The project charter identifiers who can sign-off that the project is complete and the project scope statement includes and identifies such criteria for completion.
It is important to understand the difference between validation and verification.
Verification means that the product complies with the requirements is a process to obtain customer acceptance whereas Validation means the product meets the needs of the customer.
Put another way, verify scope is concerned with the acceptance of the product by the project manager, the sponsor, or other key stakeholders, and by way of contrast, perform quality control focuses on adherence to the quality specification. Verify scope is normally performed after perform quality control that may be performed at the same time.
Whereas the process perform quality control ensures that deliverables are technically correct, verify scope is there to obtain customer acceptance. There may occasionally be situations where such deliverables are not those originally defined, but that the customer can accept what has been delivered.
In short, verify scope determines completeness, and perform quality control checks correctness.
To summarize, verify scope is verifying that the product, service, or result of the project matches the scope that was originally documented and agreed.
Obviously the verify scope process will be used after some or all of the product components have been delivered, and for this reason may be performed several times during the project
There are four inputs to the verify scope process:
Project management plan.
This set of documents includes the scope baseline consisting of the work breakdown structure and the work breakdown structure dictionary accompanied by the project scope statement. Since this is the agreement of what the project is to create, it acts as the benchmark against which the deliverable is measured.
The process of verify scope is the activity of comparing the actual deliverables against what was documented within the scope baseline, and to ensure that all products have been delivered. Because of the nature of this process, validating deliverables my or her many times throughout a project.
This key document describes the stakeholder requirements for the product, and therefore provides important information to be used when comparing what was documented with the actual product, service, or result.
Requirements traceability matrix.
This identifies the source of each individual requirements and can therefore be helpful when performing the verify scope process since it provides background information on who requested the requirements and why.
There are three outputs for the verify scope process:
This is the primary outputs of this process and is normally performed by the project manager, the customer, the sponsor, and the functional or operational managers. The product of accepted deliverables is normally a formal written acceptance by the appropriate stakeholder.
Project document updates.
As a result of verifying the project scope, there may be many updates two project documentation, possibly in terms of schedule, budget, or scope for example.
Since this process is all about verify and the scope of the actual deliverables against what was originally planned, then change requests are a normal result resulting from any such inspection, as change requests will often result from such inspection.
There is one main tool used within the verify scope process:
This is the only tool that would be used within this process and typically involves eight detailed review of the scope to be compared with the actual deliverable. If this were software, then the user acceptance testing would normally be used here.
For more information on passing the PMP exam first time, check out my PMP Primer!