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.



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

Before I go into the particulars of this next process in the scope management knowledge area, namely, process 5.5 Validate Scope, I wanted to make two general comments about the process.

  1.  When is this process done?

The two processes in the scope management knowledge area that belong to the Monitoring and Controlling phase of processes are

  • process 5.5 Validate Scope and
  • process 5.6 Control Scope

Although PMI has decided to list Validate Scope BEFORE Control Scope, but in an actual project, the Validate Scope process is the LAST process you will do before you close out the project.   Why?   Validate Scope is what happens when you take the completed deliverables.  After the project work is done, if they accept the final deliverables, then congratulations, your project is done!   You then move onto the final process 4.7 Close Project or Phase.    If they don’t ‘accept them, then you need to move on to change the scope so that the final deliverables DO meet the acceptance criteria of the customer or sponsor.   Then you would go to the process 5.6 Control Scope, where the scope baseline can be changed.   So in that case, Control Scope would be done after Validate Scope.   You redo those deliverables that had problems and then you try again and have the customer validate the final deliverables.   If you get it right, then Validate Scope is the last scope process to be done before you move on to 4.7 Close Project or Phase.

However, there are intermediate deliverables that may be completed during the course of the project, and these can be validated by the customer on an ongoing basis during the process 5.5 Validate Scope.  So although it is the last process to be done, it can be done intermittently throughout the project as deliverables become completed.

2. What is the difference between validating deliverables and verifying deliverables?

Okay, “verify” and “validate” sound sort of similar so it is important to make this distinction on a project.   Once the scope of a particular deliverable is done, the work on that deliverable is considered complete.   However, was it done correctly, that is, does the completed deliverable match the acceptance criteria set forth at the beginning of the project, where it satisfies the requirements set forth by the customer or sponsor?  The knowledge area that deals with the completeness of the work is the SCOPE, but the knowledge area that deals with the correctness of the work is the QUALITY.    Once a deliverable is complete, you then VERIFY that it is done correctly in the process 8.3 Control Quality.   If you have verified internally within the project team that it is done correctly, you then present that deliverable to the customer or sponsor in the current process 5.5, and have them VALIDATE that the work was done correctly.

However, on an exam if you see the word “verify” and “validate”, and wonder, “now which of those meant to be checked by the project team, and which of those meant to be checked by the customer”, then here’s a way I found of keeping the terms straight.

Say I going to visit a customer, who has a large office with a huge parking garage attached.   When I park the car, since all the levels of the parking lot look alike, I’m afraid that if I don’t verify where I parked, I might have trouble finding my car when I leave the customer’s office building.   So I usually write the level, and parking space number on my parking ticket I get from the machine as I enter the garage.   Now, after my appointment with the customer, if they are nice, they might offer to validate my parking ticket so that I don’t have to pay a fee for parking in the garage.   So verify is what I do as a project manager, and validate is what the customer does.   That’s one way to keep the terms straight in your head!

Now with those preliminary issues of terminology and timing out of the way, let’s talk about the inputs to this process, which I will take up in the next post.

6th Edition PMBOK® Guide–Process 5.4 Create WBS: Outputs

Here’s a trick question:   what is the output of the “Create WBS” (Work Breakdown Structure) process?   If you answer “the WBS” on the exam, you will get it wrong.   The correct answer technically is “the scope baseline”, but that is only because the result of the “Create WBS” is both the “WBS” and the “WBS Dictionary.”   These two components, plus the Project Scope Statement, which is the output of the last process 5.3 Define Scope, all are included in what is called “the scope baseline.”    So please remember that the scope baseline is not one document, but three separate documents combined!

Okay, let’s discuss the outputs to the proces 5.4 “Create WBS”.

5.4.3 Create WBS:  Outputs  Scope Baseline

Remember my analogy from a previous post:   the scope is like a series of blueprints for a building under construction that contain several layers of detail:

  • the requirements, analogous to the structural elements of a building  like the scaffolding of the building and its foundation,
  • the major deliverables, analogous to the walls, ceiling and floors that connect the structural elements and give the building a shape,
  • and the WBS which gives the minor deliverables all the way down to the work package elements, analogous to the furnishings, etc. that will go into the individual rooms.

The scope baseline includes the:

  • Project scope statement–this contains a description of the project scope, the major deliverables, plus the assumptions and constraints that put a boundary around the scope (the analogous to the second level of detail of the scope listed above).
  • WBS–this contains a breakdown of the total scope of work (the third level of detail of the scope listed above) into work packages that needs to be carried out in order to create the deliverables (the second level listed above) that fulfill, in turn, the requirements (the top level listed above) of the project.    As mentioned in the last post on how to create the WBS, there may be some control accounts included in the WBS which are used to help keep track of a group of related work packages for the purpose of measuring the performance of that part of the project.
  • WBS dictionary–for each element of the WBS dictionary, which describes the work that needs to be done, consider the WBS dictionary the “flip side” of that work package which contains information on the costs, schedule, resources and other information needed to do that work.  Project Documents Updates

Both the assumption log (output of process 4.1 Develop Project Charter) and the requirements documentation (output of process 5.2 Collect Requirements) may be updated with items created or elaborated upon as a result of the Create WBS process.

Now that the scope is complete, it needs to go to the planning process of the next knowledge are, that of schedule management, in order to be implemented.   Now the scope is like a list of ingredients for a recipe, but a true recipe requires something else equally as important, if not more so:   the list of instructions on how to put it together!   That is where the process of creating the project schedule comes in, and that will be covered in the next series of posts on Schedule Management.

In the meanwhile, the next few posts will go on to cover the two processes in the next phase of processes for Scope Management, namely, 5.5 Validate Scope and 5.6 Control Scope.   The next post will take up the inputs to the first of these two processes, 5.5 Validate Scope.

6th Edition PMBOK® Guide–Process 5.4 Create WBS: Decomposition

“My life amounts to no more than one drop in a limitless ocean. Yet what is any ocean, but a multitude of drops?”–Cloud Atlas, by David Mitchell.

The process of decomposition of the scope done in this process is where the seeds of the miraculous “power of we” on a project are sown.   What do I mean?   A project is a large undertaking that, in some cases, would be impossible for one single, solitary human being to do on their own.   From the construction of the pyramids to the landing of a man on the moon, projects have succeeded because they take a huge amount of work–what is called the scope of the project in PMI language–and break it down into manageable parts that individual human beings can perform.   The project manager takes the individual human beings and puts them on a team so that they became a team with the “power of we”, that is, the power of doing more than any group of individuals of the same size could do on their own (the power of “I” alone).   When you are on a good team, as the poet Rumi once said:

“You are not just the drop in the ocean. You are the mighty ocean in the drop.”

The process of creating the work breakdown structure or WBS is called “decomposition” and it is the main tool and technique used in this process.

5.4.2 Create WBS:  Tools and Techniques  Expert Judgment

Of course, the people you will turn to in order to create the work breakdown structure are those with expert judgment, particularly those who have worked on similar projects.  Remember, a project team member who wants to avoid work may be lazy, but a project team member who wants to avoid unnecessary work that has been done before is smart.   The best place to look for your model of a WBS on a project in terms of the structure of the WBS is the procedures and templates for the WBS,  one of the organizational process assets that is an input to this process.    For the contents of the WBS, the best place to look would be project files and lessons learned from previous projects, again, some of the organizational process assets that are inputs to this process.  And the people that created those documents would be great experts to have as consultants for the creation of the WBS on your particular project.  Decomposition

There is only one main tool & technique for this process, and that is decomposition, which is the process of dividing the scope of the project from the level of deliverables, which are contained in the project scope statement (the output of the last process 5.3 Define Scope), to smaller, more manageable parts called work packages, which are the lowest level of the WBS for which cost and duration can be reasonably estimated and managed.

How does the process work?   For visual examples you may want to refer to while looking at these steps, see pages 158 and 159 of the PMBOK® Guide.

  1. Look at the Scope Management Plan for guidelines on how your organization does the WBS (the plan should indicate how all of the scope management processses are to be done, not just this one).     The Scope Management Plan is an output of process 5.1 Plan Scope Management.
  2. Look for the templates for the WBS that your organization may use (these are some of the organizational project assets that are an input to this process).    You will use these templates to create the WBS based on instructions contained in the Scope Management Plan.
  3. Look for the deliverables of the project scope in the Project Scope Statement, which is the output of the previous process 5.3 Define Scope.   Remember the scope is developed first at
    • the level of requirements (high-level requirements are in the Project Charter, more detailed requirements are developed in the Collect Requirements process 5.2 and placed in the Requirements Documentation)
    • the level of deliverables (the Define Scope process 5.3 develops the deliverables that will fulfill those requirements), and then finally
    • the level of work packages (this process 5.4 Create WBS takes the deliverables and breaks them down into work that a person can reasonably do in a matter of hours).
  4. Okay, now let’s build the WBS!   The top level is the name of the project itself.
  5. The second level will any phases of the project life cycle if the project is broken up that way (design, creation of prototypes, testing, etc.).
  6. The product and project deliverables are the next level of decomposition, which can organized by the requirements they relate to.    These can be further subdivided into “major deliverables” and “deliverables” based on the complexity of the project.
  7. The deliverables are further broken down until they reach the lowest level, that of work packages.
  8. Once the decomposition of the deliverables is verified as appropriate, then you can develop and assign identification codes to the components of the WBS, where the first level has the identification 1.0, the second level has the identification 1.1, 1.2, 1.3, etc., the third level has the identification 1.1.1, 1.1.2, 1.1.3, etc.   This identifies the level to look for any particular component and which component is the “parent” of any particular component.    The parent is the component which is broken down into subcomponents at a lower level.
  9. Once the work packages have all been uniquely identified, you can start adding “control accounts” associated with a group of associated work packages.   These are used in the monitor and control phase and contain a hierarchical summation of the costs, schedule, and resources used for that group of work packages.
  10. For those work packages which are not done immediately, or are as yet without detailed estimates of schedule, cost, or resources, you can create “planning packages” which essentially are a way of saying TBD or “TO BE DETERMINED”.
  11. Additional information on each work package can be compiled into something called the WBS dictionary, which is information created from other processes in other knowledge areas that supports the scope information contained in the WBS.

That is the detailed process of creating the WBS.   The outputs of the process are described in the next post.

6th Edition PMBOK® Guide–Process 5.4 Create WBS: Inputs

After my brief introduction in the last post to what a Work Breakdown Structure or WBS is, let me now turn into what inputs are required to actually creating one.

5.4.1  Create WBS:  Inputs  Project Management Plan

The relevant component of the Project Management Plan namely, the Scope Management Plan, should spell out how to do all the other processes in he scope knowledge area, including this one, process 5.4 Create WBS.  Project Documents

The project documents used as inputs into this process are

  • Project Scope Statement–output of process 5.3 Define Scope
  • Requirements Documentation–output of process 5.2 Collect Requirements Enterprise Environmental Factors

  • Industry-specific WBS standards–these are standards that are relevant to the nature of the project that may serve as external reference sources for creating the WBS, Organizational Process Assets

  • Policies, procedures, and templates for the WBS (usually maintained by the Project Management Office)
  • Project files from previous projects (again, why re-invent the wheel?)
  • Lessons learned from previous projects

In the next post, I will discuss the tools and techniques for this process, the main of which is decomposition, or the process of breaking down the scope from the deliverables listed in the Project Scope Statement (the output of process 5.3 Define Scope) down to the smaller, more manageable elements called work packages.

6th Edition PMBOK® Guide–Process 5.4 Create WBS: Introduction

The Work Breakdown Structure or WBS is one of the most powerful tools in project management.   Before going into the inputs, tools & techniques, and outputs of this process, I wanted to use this post to make a few introductory remarks about the WBS.

The process of creating the WBS is where you take the project deliverables and break down or subdivide the project work into smaller, more manageable components called work packages.   As the PMBOK® Guide puts it, “it provides a framework for what has to be delivered.”

Elaborating on this concept of framework, I can elaborate on an analogy I used in an earlier post.   What is the relationship of the requirements (output of process 5.2 Collect Requirements), the deliverables (output of process 5.3 Define Scope), and the WBS (output of this process 5.4 Create WBS)?   Think of a set of architectural blueprints for a building.    The structural components, like the steel beams that make up the scaffolding of the structure, plus the foundation of the building, are what hold the building up.   These are like the requirements, and are the first elements that will be built.   Next are the connecting structures, like the roof, walls, and floors, which hold the building together into a single connected space.   The deliverables are like this next level of detail in the architectural drawings:   they give shape to the building as a whole.    Finally, the WBS is like the detailed drawings of the interiors of the rooms, including furnishings etc. the next and final level of detail of the architectural blueprints.

But understanding what a WBS is NOT is as important as understanding what it IS.   The resulting WBS looks like an organizational chart, with the top level being the largest components, and the bottom level being the smallest components or work packages.  However, it is not a flowchart; it doesn’t show you HOW to actually do the project.   It is, to use another analogy, like the ingredients in a menu.   To actually create a dish from a recipe you need not just the list of ingredients, but the instructions on how to mix them together, etc.   That is the schedule, and is the subject of another knowledge area, that of Schedule Management.    The WBS is one of the inputs for creating the schedule, but it is not the schedule itself.

Okay, with those preliminary remarks out of the way to set up the relationship between the outputs of scope management we have seen so far–the requirements, the deliverables, and the work packages as part of the WBS, let’s go into the inputs of this process in the next post.

6th Edition PMBOK® Guide–Process 5.3 Define Scope: Outputs

In the last post, I discussed the tools and techniques used, in particular that of product analysis, which takes the requirements and translates them into meaning deliverables (i.e., the scope) that are needed to deliver the final product that fulfill those requirements.   Those deliverables are what get put into the Project Scope Statement, the major output of this process.    The process also creates updates to some of the project documents.

The PMBOK® Guide makes an important point in that some elements of the project charter seem, at first glance, to be the same as those in the project scope statement, but those elements which are similar are at a high or more general level of detail in the project charter, whereas those in the project scope statement are a greater level of detail.   I will note those distinctions below…

5.3.3  Define Scope:  Outputs

Here are the elements of the project scope description.

  1. Product scope description–a narrative description of the characteristics of the product, service, or result of the project.   At the high level of the project charter, this product description is sometimes referred to as the “statement of work”, essentially the “seed idea” of the project.   But in the project scope statement it is elaborated further.
  2. Deliverables–a deliverable is defined as “any unique and verifiable product, service, or result that is required to be produced to complete a process, phase, or project.   These deliverables are the “building blocks” of the project that when completed create the final deliverable which is then validated by the customer in the 5.5 Validate Scope process.   The equivalent category in the project charter are the high-level requirements–these are exactly what are translated as a result of this process into the deliverables that go into the Project Scope Statement.
  3. Acceptance criteria–the set of conditions that is required to be met before deliverables are accepted.
  4. Project exclusions–In July 1963 “The Plain Dealer” of Cleveland, Ohio published an article titled “Why Are Elephants?” with several cartoons and jokes on the theme of elephants.   The following quip described a common sense approach to creating a sculpture:

    “How do you make a statue of an elephant? Get the biggest granite block you can find and chip away everything that doesn’t look like an elephant.”

    This was obviously meant to be humorous because you can imagine the bewildered art student hearing that sage advice and finding it not very helpful at all.   However, when you are creating the project equivalent of a huge elephant, sometimes it is helpful at the beginning of the project to state explicitly what is not going to be in the scope.   This helps prevent unnecessary changes because you can point to this exclusion when someone decides to try to add that particular scope during the course of the project.   Now you can include exclusions in the project charter as part of the larger category of boundaries, which are requirements which are going to be in the scope, but can also include those features or characteristics which are not going to be in the scope.   This can be because they are envisioned to be part of a future project if the current project is successful, or because the excluded features are explicitly not wanted by the sponsor.    Putting such exclusions in the project charter as part of the boundaries can be pretty persuasive to those suggesting adding those features to the scope, because now rather than having to argue with the project manager to include them, they now have to talk to the project sponsor!  Project Documents Updates

  • Assumptions log–sometimes the Define Scope process of turning requirements into deliverables uncovers additional assumptions or constraints that were not previously apparent when the project scope was at the more abstract level of requirements.
  • Requirements documentation–sometimes the review of the requirements may result in adding requirements, or changing the requirements themselves, and these changes or additions are added to the requirements documentation, which can include the requirements traceability matrix.
  • Stakeholder register–when new information about the stakeholders comes to light during their participation in this process, particularly their views about the various requirements they care about, it is recorded in the stakeholder register.   It should be listed there whether they are to be consulted regarding a decision involving the requirements, or whether they should be informed afterwards regarding a decision involving those requirements.