1. Introduction—Verify Scope
If your project is to produce a product on behalf of a customer, then whether or not your project is a success or not will depend on whether that customer finally and formally accepts that product and signs off on the project. But waiting until the very end of the project to gain that acceptance is unwise, because the cost of making changes towards the end of the project is prohibitive. The general rule in the PM world is, if you’re going to get bad news, then the earlier, the better. The interim deliverables are shown to the customer for acceptance during the entire course of the project when suitable milestones have been reached. It is this acceptance process by the customer of these interim deliverables that is referred to in the process 5.4 Verify Scope.
2. Common Problems with Understanding 5.4 Verify Scope
In reviewing this process in our study group, I find it creates a lot of confusion. Here are the problems people have with understanding this process.
Fig. 1 Problems with Understanding 5.4 Verify Scope Process
| Problem | Explanation | |
| 1. | Verify Scope ≠ Control Scope | Upon first hearing the term “Verify Scope”, to some people it sounds like it means to check and see that the scope you have now is the same scope that is in the Project Scope Statement, i.e., verifying that you’re not experiencing the dreaded PM malady known as “scope creep”. However, what I have just described is actually what the process 5.5 Control Scope is about. Verify Scope, on the other hand, means rather having the customer verify the scope of the product, not the project manager.
|
| 2. | Validated vs. accepted deliverables | “Validate” and “accept” sound close in meaning, but to validate a deliverable is to go through the process 8.3 Perform Quality Control and show that the deliverable meets the quality standards and the scope requirements. Validated deliverables then become an input to the 5.4 Verify Scope Process, where they are shown to the customer. If the deliverables are accepted, they now become accepted deliverables.
|
| 3. | Negative outputs | Both the 8.3 Perform Quality Control and the 5.4 Verify Scope Process CAN have a positive output, i.e., validated deliverables and accepted deliverables, respectively. Both either process can have a negative output, namely, change requests. What do I mean by a negative output? If the 8.3 Perform Quality Control process shows that the deliverables do NOT mean the quality standards, then change requests need to be generated so that a) the defective deliverables are repaired AND b) the processes that produced them can be improved so that the deliverables DO conform to the quality standards. Likewise, if the deliverables are validated and sent to the customer, then the customer may accept them, but if the customer does NOT accept them, then this also generates a change request to bring the deliverables in line with what the customer wants.
|
| 4. | Interim ≠ final deliverables | The Verify Scope is for interim deliverables. When discussing this process and saying “the deliverables are shown to the customer for acceptance”, people sometimes think that this refers to the final deliverable, i.e., the completed product. That showing of the final completed product is NOT part of 5.4 Verify Scope, but part of 4.6 Close Project of Phase. The process 5.4 Verify Scope is only for interim deliverables.
|
3. How the Verify Scope process fits in with other PM processes
The flow of these processes can be summed up in the following diagram:
I hope this post helps clear up not only the purpose of Verify Scope, but how it fits in with other processes.
Filed under: Uncategorized |
4squareviews 
Leave a comment