Validate The Scope of Project Deliverable


Validate Scope

Your team says that the deliverables are complete and Quality control team certifies delivery to be good. But who decides when deliverables are really 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 during project execution?

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 it’s 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 walkthrough, 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 found major gaps in deliverables as compared to the requirements and rejected the whole delivery?

I am sure you would 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 fixes. The reasons for deviations and type of project contract will decide whether customer will bear the cost of these fixes or the performing organization.

When scope is controlled regularly with good effect, validating scope of completed work deliverables with customer should be relatively painless. Many teams involve customer in process of controlling 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.

Recommended by Google

{ 0 comments… add one }

Leave a Comment