Your team tells you that the deliverables are complete and Quality control team certifies delivery to be good.
Who decides when deliverables are truly complete?
The customer, or project sponsor.
Validate Scope is the process in which validated deliverables are compared against scope baseline to decide whether team has produced what was planned and documented. This is a process of formal acceptance of completed delivery by the customer.
What’s needed to validate project scope?
Quite simple – you compare completed and tested deliverable against requirements documentation.
This contains the product and project requirements, the technical and non-functional requirements, and acceptance criteria for each of them. Compared using requirements traceability matrix. This is the way to trace each of the test cases, activities, work packages all the way back to the documented requirements.
Now to understand how this is done we need the project management plan. In particular, scope management plan and the scope baseline.
How is this done?
Inspection is simply the exercise of comparing validated deliverables to requirements using acceptance criteria and confirming whether deliverables are satisfactory to the customer. In different industries, this is called by different names such as product walk-through, product review, or audit.
The second one is few decision-making techniques that we saw in the project management activity for collection project requirements.
Since customer is verifying validated deliverables, the what you get in this project management activity is accepted deliverables. These are signed off by the customer or project sponsor. This formal acceptance and acknowledgement is essential and part of Close Project or Phase process.
Many customers accept deliverable even when they find some deviations, if they decide that they are not life-threatening. They may be okay with fixing the deviations as part of subsequent delivery. In such cases, as the rule goes, first a change request is raised and documented. Hence, change requests are the second output of this process.
When customer finds some deviation in the deliverables project documents (such as the ones that keep track of scope deviation) are updated.
What if customer finds major gaps in deliverables as compared to the requirements and rejects the whole delivery?
Chances are you have witnessed such instances. I know I have. In such cases we go back to the same exercise of raising change request, running through change control board, re-planning the work, reworking the schedule, updating baselines and getting on with changes. The reasons for deviations and type of project contract will decide whether customer will bear the cost of these changes or the performing organization.
When scope is controlled regularly effectively, validating scope of completed work deliverables with customer should be fairly painless.
Many teams involve customer in the process of managing scope to keep them ‘in the know’ and look for early signs of scope slippage.
This is a great practice especially when customer ties milestone releases to business events such as product showcase events or industry trade conferences. Cost-of-failure in such cases are much higher. Also, this practice is a good ‘manage stakeholder expectations’ exercise that you can implement.
In the next lesson, let us see how do we control scope in the project.
