The prerequisite of executing this process necessitates crafting a scope statement. This statement involves the appropriate stakeholders, forming a work breakdown structure, constructing a verification plan, and clearly defining the acceptance criteria. Organizations that embrace this method can be confident their projects will be successful and clients will be delighted.
It is the process applied by obeying established rules or procedures. It is used to making it certain that the tangibles and intangibles of a project have been created at the end of the project.
The scope approval process is a confirmation by the client, under the guidance of the project manager, whether the delivery has been revealed in accordance with the specified condition or capabilities needed by stakeholders. It is done following the completion of the delivery intended to be covered under the project.
Whether the product produced meets stakeholder requirements is revealed at the end of the customer's review. This review forms the basis of this process.
The result of Scope validation is the recognition of a stage's delivery by the customer, thus allowing the project or phase to proceed with the closing steps. Nevertheless, if scope verification fails (the customer does not accept the deliverable), the integrated change control process will be initiated and the project management plans must be updated.
This process occurs at the intersection of the Scope Management Knowledge Area and the Monitoring and Controlling Process Group.
Now that the scope has been planned with a scope baseline in place, the next step is to validate the scope. The purpose of this process is to formalize the acceptance of the project team's completed project deliverable, such as a product, service, or result, by the customer. So, the customer has to accept it. In the case of Scrum Agile environment, we are trying to make sure that the Definition of Done has been met. So basically, the Scrum team will be sitting down and looking at the deliverable along with the customer and making sure that the scope requirements meet the Definition of Done. But in Waterfall, we are just validating the scope and making sure that we get customer acceptance.
If this process succeeds in getting sign-off or customer acceptance, then the project can initiate the Closed Project or Phase process. In Agile, once closing is initiated post-validation and completed, the Definition of Done has been attained.
Next, we'll be going over the Validate Scope ITTOs - Inputs, Tools, Techniques, and Outputs for Validate Scope. For inputs, we have Project Management Plan, Requirements Documentation which is coming from Collect Requirements process. Next, we have Requirements Traceability Matrix which ensures that requirements are tied to the correct resources and to the right deliverable. All requirements need to be tied to a specific resource or deliverable to ensure that a hundred percent role is being met as we had just talked about in the Create WBS process. Next, we have Verified Deliverables. Verified deliverables are coming from the Control Quality process where the project team is internally checking whether or not a product, service, or result of the project meets those requirements. This is internally controlled by the project team. When we're doing Validate Scope, however, we're going to get accepted deliverables as output, so that's really important to understand the difference between verified and accepted. They're not the same thing. Verified is internally verifying it to the requirements as a team. So, the other input we have is Work Performance Data - the raw observations of what a customer sees to validate the actual deliverable. So, for example, if we had a deliverable of a smartphone, we'd say that if the power button is not working, that would be a raw observation for that phone. What does that mean will become the information analyzed in context as the output. So that's the importance of knowing the difference between WPD and WPI.
Next, for tools and techniques, we have Inspection. This is nothing but a walkthrough by internal team members as well as a customer to make sure that the deliverable itself is working the way it's supposed to be, the way that the customer is desiring. And also, Group Decision-Making Techniques. We have Dictatorship where one person makes the choice, Unanimity where all parties agree, Majority greater than fifty percent agree, and Plurality where less than fifty percent can make the choice. But that's not going to be fair because it's not going to be fair for the whole team. We're not getting all inputs, so it's better to have unanimous decision making. So the output is then going to become accepted deliverables. That is the whole point of validating scope - the customer has to accept the deliverable, otherwise, they will reject it. And if they reject it, it will become a change request as we see as output, and they will raise a change request to make sure that the requirements are being met. This means the request will then have to go to Perform Integrated Change Control process to be approved or rejected. Once again, in the case of approval, the change request is going to be implemented during the Direct and Managed Project Work process in execution. The deliverable will then go to Control Quality once again to be verified by the project team. Once verified internally as a project team, we'll come back to Validate Scope, this time for the customer again to accept. Hopefully, they accept, and you don't want to have too many of these back and forth change requests at this point because then it will eat into your budget and schedule. So try to do it to the best of your ability of the project team at the first time. And if it doesn't happen in your first round, that goes to mean that this scope is not clear, as a result, a lot of change requests are happening during the validation session.
Next, we have Work Performance Information. This is where the raw data is analyzed in context. So for example, if we had Work Performance Data as a resource in your team is out sick, as a PM, we need to proactively understand the impact on the project in terms of schedule, cost, and risk. So now that we've accepted that a resource for managing our budget in the accounting team is out sick, that means we would have to delay certain activities in the critical path or it could be in the near-critical path, we don't know that, but this is an example. We need to understand what it means in terms of the budget.
Next, we would have Project Document Updates, and the updates are going to be made to the Requirements Documentation and Requirements Traceability Matrix in the case that they are going to be updated when the change request is being risen when the customer is not satisfied during inspection. The key benefit of this process is that it brings objectivity to the acceptance process and increases the chance of final product, service, or result acceptance by validating each deliverable.
See also: Define Scope Process