6th Edition PMBOK® Guide–Process 5.5 Validate Scope: Inputs

This process is where the customer or sponsor of the project validates and then formally accepts (formally here means “in writing”) the project deliverables.   It is preceded by the process 8.3 Control Quality where the project deliverables are first verified internally by the project team.   And, if the project deliverables are the final ones for the project, and the customer or sponsor of the sponsor does actually formally accept the deliverables, this process is then immediately by the process 4.7 Close Project or Phase.

The inputs for this process then will be the documents which were created at the beginning of the project that outline the acceptance criteria for validating the scope, and the deliverables that were just verified through the Control Quality process and that will be validated by the customer or sponsor in this process.

5.5.1  Validate Scope:  Inputs

5.5.1.  Project Management Plan

Just as a review, the project management plan is not a single plan, but a collection of planning documents that include a) knowledge area management plans, b) subsidiary management plans, and c) baselines for the major three constraints of scope, schedule, and cost.   All three of these categories of planning documents are included in the inputs below.

  • Scope Management Plan–remember that the scope management plan, created as an output to the process 5.1 Plan Scope Management, contains the guidelines of how to do all of the other processes, including this one, process 5.5 Validate Scope.    Specifically, the plan should include how the formal acceptance of the completed project deliverables will be obtained (will the final product be delivered to the customer, or will the customer come and inspect it?)
  • Requirements Management Plan–one of the subsidiary management plans that is related to the Scope Management Plan, but of course focusing specifically on the requirements.   Remember that the scope is created in the following stages:  first the requirements are set (these are included in the Requirements Documentation as an output of the process 5.2 Collect Requirements), then the deliverables are developed which fulfill those requirements (these are included in the project scope statement, the output of process 5.3 Define Scope), and then those deliverables are decomposed into more manageable components called work packages (these are contained in the work breakdown structure or WBS, with other information about the work packages being included in the WBS dictionary, both of these being outputs of process 5.4 Create WBS).
  • Scope baseline–this consists of the Project Scope Statement (containing the scope at the level of deliverables) and the WBS and WBS dictionary (containing the scope at the finest level of detail in the form of work packages).     The deliverables included in these documents, along with the requirements that the deliverables fulfill (included in the Requirements documentation listed in the second paragraph below), are compared to the actual results (the verified deliverables listed in the third paragraph below) in order for the customer or sponsor to validate them.  The result will be one of the two possibilities:
    • Formally accepts the deliverables, in which case the project is now formally closed in the process 4.7 Close Project or Phase.
    • Rejects certain of the deliverables, in which case a change request is made to bring the deliverables into line with what the customer or sponsor originally requested.  Project Documents

  • Lessons learned–since the Validate Scope is done with the intermediate deliverables throughout the project, any lessons learned earlier on in the project with regard to this process of validating deliverables can be applied to later phases in the project so that the process of validating the final deliverables of the project goes smoothly.
  • Quality reports–these are the findings from the process 8.2 Control Quality, which is the process which internally verifies the quality of the deliverables before they are delivered to the customer or sponsor in this process.
  • Requirements documentation (including the requirements traceability matrix, if used)–these are compared to the deliverables which fulfill these requirements in order for the customer or sponsor to validate them (see the first paragraph above regarding the Scope Baseline).  Verified Deliverables

These are the deliverables that have been completed by the project team which have been verified internally for quality through the process 8.2 Control Quality.    Verifying the quality in this case specifically means comparing the completed deliverable to the acceptance criteria set up in the earlier planning processes 5.2 Collect Requirements and 5.3 Define Scope. Work Performance Data

These are the raw observations and measurements done during the activities of the process 4.3 Direct and Manage Project Work.   These observations and measurements can include those that show the degree of compliance of the deliverables produced with the requirements, and if any non-conformities with those requirements are identified.

With the verified deliverables, documentation (from Work Performance Data and the quality reports from the process 8.2 Control Quality), and acceptance criteria (from earlier scope management processes), you should be ready for the validate scope process itself, which is outlined in the next post.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: