4squareviews

After the inspection process which is the main tool/technique of the Validate Scope process, there are one of two possible outcomes.   Either the customer or sponsor

1. formally accepts the final deliverables of the project, in which case the project can be considered complete, and the next process is then process 4.7 Close Project or Phase
2. rejects certain of the deliverables as nonconforming to the acceptance criteria decided upon at the beginning of the project, in which case a change request is made so that those nonconforming deliverables can be brought in line with the acceptance criteria.

The outputs related to either of these outcomes are listed below.   If the final deliverables are accepted as in paragraph 1 above, the output will be any accompanying formal documentation of that acceptance (see 5.5.3.1 below).  If they are NOT accepted as in paragraph 2 above, the output will be the change requests (see 5.5.3.3 below), along with any documentation outlining the reasons why they have not been accepted (see 5.5.3.2 below).

There are project documents updates done in either case, whether the final deliverables are accepted or not (see 5.5.3.4 below).

5.5.3 Validate Scope: Outputs

5.5.3.1 Accepted Deliverables

If the customer or sponsor has accepted the deliverables, then the formal documentation acknowledging that acceptance is forwarded on to process 4.7 Close Project or Phase

5.5.3.2  Work performance information

Information on which deliverables have been accepted, which have not been accepted and the reasons why, is described and communicated to shareholders.

5.5.3.3  Change requests

If there have been some of the completed deliverables that have not been formally accepted, documentation on the reason for the non-acceptance of those deliverables is used to create a change request for defect repair.   The change request goes through the usual process for such requests, 4.6 Perform Integrated Change Control.   Once the deliverables have been corrected to be in line with the acceptance criteria, they are submitted again to the process 5.5 Validate Scope.

5.5.3.4  Project Documents Updates

• Lessons learned register–what challenges were encountered in the Validate Scope process.   What approaches worked well for validating deliverables?
• Requirements documentation (including the requirements traceability matrix)–the result of the Validate Scope process for the requirements should be documented.  What methods were used to validate the requirements and what was the outcome of the validation process? Did the actual results fulfill the requirements?   Did any of them exceed the requirements?    Were any requirements waived by the customer or sponsor?

Now let’s turn to the monitor and controlling process that usually comes BEFORE the Validate Scope process related to the final deliverables, that of 5.6 Control Scope, which is the process of monitoring the status of the project and product scope and managing any changes to the scope baseline (which consists of the Project Scope Statement, the WBS, and the WBS dictionary).

Filed under: Uncategorized |