6th Edition PMBOK® Guide–Process 5.6 Control Scope: Outputs


As we stated in a previous post on the inputs to this Control Scope process, the process consists of asking three questions:

  1. “what’s the plan?”
  2. “is the project going according to the plan?” and if the answer to question 2 is no,
  3. “how can we get the project back to the plan?”

The outputs are based on the answers to question 2 (Work Performance Information, and updates to the Project Management Plan and Project Documents) and question 3 (Change Requests).

Here are the specific outputs to this process:

5.6.3 Control Scope:  Outputs

5.6.3.1 Work Performance Information

Just as a review, there are three levels of knowledge on a project.

  1. Work performance data–generated in the Process 4.3 Direct and Manage Work by the project team
  2. Work performance information–this level of knowledge is useful to the project team;  the work performance data is analyzed in the separate monitoring and controlling processes connected with each knowledge area, like this one Process 5.6 Control Scope; they are then in turn inputs into the overall monitoring and controlling process 4.5 Monitor and Control Project Work
  3. Work performance reports–this level of knowledge is useful to the stakeholders; the work performance information is organized and presented in the overall monitoring and controlling process 4.6 Monitor and Control Project Work so that it is useful to those stakeholders who are engaged with the project.

This output is work performance information that is based on the analysis done in the Process 5.6 Control Scope.  The main tool/techniques of this process (described in the last post) are variance analysis and trend analysis.   These not only answer the question 2 above, i.e., is the project going according to the plan, but if the answer is “no”, then they dig deeper into the reason for the variance existing now or the trend that a variance may exist sometime in the near future.   Other parts of the analysis are determining the impact the variance in scope has on the other two major constraints, that of schedule and cost.

The Work performance information is then input into the overall monitoring and controlling process 4.6 Monitor and Control Project Work.

5.5.3.2  Change Requests

The answer to question 3 above, “how can we get the project back to the plan?”, will determine the change request which will either

  • fix the project scope back to fit the plan OR
  • in the case that the plan has been discovered to be unrealistic, it may be necessary to change the plan to fit the project scope

If the scope needs to be changed, then there will be a change request outlining what needs to be changed.   If the plan needs to be changed, then the scope management plan, the various project baselines, and the project documents may need to be changed (see next paragraph).

There are three types of change requests:   defect repair, corrective action, and preventive action.   Here’s how to keep them straight in your head.   In Charles Dickens’ novel A Christmas Story, the main character Ebeneezer Scrooge is visited by ghosts, the Ghost of Christmas Past, the Ghost of Christmas Present, and the Ghost of Christmas Future.   As a project manager, you too may be visited by three ghosts, but in this case these are:

  • The Ghost of Nonconformities Past (i.e., variances from the plan that have already occurred):   in this case you need to make a defect repair to make sure that the variance is repaired and the project scope can continue as planned
  • The Ghost of Nonconformities Present (i.e., variances from the plan discovered in the Variance Analysis tool and technique mentioned in the last post):   in this case you need to take corrective action to make sure that the variance is corrected and the project scope can continue as planned
  • The Ghost of Nonconformities Future (i.e., trends towards a future variance from the plan discovered in the Trend Analysis tool and technique mentioned in the last post):   in this case you need to take preventive action to make sure that the a potential variance in the future is prevented by reversing the downward trend in the performance baseline.

The change requests are then inputs to the process 4.6 Perform Integrated Change Control, which analyzes and decides upon what changes to perform on the project based on change requests from ALL monitoring and controlling processes, not just this one.

And remember, there is the fourth possibility that the analysis done in this process uncovers that the plan was unrealistic because it did not realistically account for all the project scope that had to be done.   That is covered by the next two sections listed below.

5.6.3.3 Project Management Plan Updates

  • Scope management plan–it may be uncovered in the Lessons learned register (see section below on Project Document Updates) that during this process, more efficient and effective ways of controlling the scope are discovered, including getting at the cause of the variances and choosing the best type of action to take with a change request.   In this case the portion of the scope management plan that gives the guidelines for this particular process may be updated.   The change in scope may be severe enough to change not just the deliverables and the work packages, but the requirements themselves, in which case the requirements documentation will also need to be updated (see section below on Project Document Updates).
  • Baselines–the scope baseline may be changed if the change requests outlined in the above paragraph are approved, which may in turn cause changes in the baselines for the other two major constraints, the schedule baseline and the cost baseline.   If the scope baseline is determined to have been unrealistic, then the scope baseline, and the other baselines of the schedule baseline and cost baseline may need to be changed as well.   This will in turn change the performance measurement baseline (used in earned value analysis), because this combines measures of all three constraints.

5.6.3.4  Project Document Updates

  • Lessons learned register–rather than the results of the process, i.e., possible changes in the scope, if the process 5.6 Control Scope itself needs to be changed, then this is where you would put updates to the process that are more effective and efficient in controlling the scope, which would in turn be used to change the portion of the Scope management plan that gives guidelines on how to do the process.
  • Requirements documentation (including requirements traceability matrix)–if there is a change request that makes a recommended change in the scope, the scope baseline (which contains the deliverables in the Project Scope Statement, and the work packages in the WBS and WBS dictionary) will normally be what is altered if the change is approved.   However, the variance in the scope may be so great that even the requirements, from which the deliverables and eventually the work packages are derived, may need to be changed, in which case the requirements documentation will need to be updated.

And that, my friends, is the end of the fifth chapter of the 6th Edition PMBOK® Guide; the next chapter will cover the knowledge area of Schedule Management.

 

Advertisement

6th Edition PMBOK® Guide–Process 5.6 Control Scope: Tools and Techniques


As we discussed in the last post on the inputs to this process 5.6 Control Scope, there are three questions to be asked in the monitoring and controlling of the scope:

  1. “what’s the plan?”
  2. “is the project going according to the plan?” and
  3. “how can we get the project back to the plan?”

The first two questions are the monitoring part of this process, and the third question pertain to the controlling part.

This post will discuss the two main tools and techniques used in this Control Scope process, which are also used in the monitoring and controlling processes for the other major constraints (schedule and cost).

5.6.2 Control Scope:  Tools and Techniques

5.6.2.1 Variance Analysis

Variance analysis is where you take the work that was supposed to be done on the scope of the project in the last reporting period (obtained from the Scope Baseline input) and compare it to the actual work done during the last reporting period (obtained from the Work Performance Data input).   Let’s say there is a variance detected between the two.   Then what do you do?

  • See if the variance exceeds any threshold amount set at the beginning of the project.   If it exceeds that threshold, the sponsor may need to be informed, for example.
  • Analyze how the variances in the scope affect the other constraints of schedule and cost.
  • Find out if defect repair or corrective action is required to bring the scope back to the baseline (using the Requirements Documentation and/or Scope Baseline inputs).

5.6.2.2  Trend Analysis

A comparison of current performance with the performance measurement baseline (usually using Earned Value Analysis) will show if there is a trend towards improving or deteriorating performance.   If it is deteriorating, then find out if preventive action is required to reverse that trend.

The output of these two analyses will be recommendations for change requests, which are the main output of this 5.6 Control Scope process.   (Change requests in fact are the main output of any monitoring and controlling process for other knowledge areas as well, not just for scope.)

We will discuss the types of change requests when we cover the outputs of this process, which are covered in the next post.

 

 

6th Edition PMBOK® Guide–Process 5.6 Control Scope: Inputs


If a project scope keeps expanding without any adjustments to the other constraints such as the time, cost, and resources, you have a situation referred to as scope creep.   That is why you have this process called Control Scope.   Now, a change in the scope is probably inevitable, but the key here is to make sure that it is done in a controlled way that takes the other constraints into account.

The inputs you will need for this process are covered in this post.

5.6.1  Control Scope:  Inputs

5.6.1.1 Project Management Plan

Here are the components that may be needed as inputs to this process.

Remember that the project management plan consists of

a) 9 knowledge area management plans, (one plan for each of the knowledge areas besides Integration, which integrates all of them into the overall project management plan)

b) 3 subsidiary management plans

  • for requirements, related to the Scope management knowledge area,
  • for change, related to the Integration management knowledge area (this covers the contents of the changes)
  • for configuration, also related to the Integration management knowledge area (this covers the structure of the changes, so that everybody is working off the same version of the project and/or product)

c) 4 baselines, covering the 3 major constraints of scope, schedule and cost, plus the performance measurement baseline, which uses earned value analysis to combine measures of all three of these constraints

PLUS

d) A description of the project life cycle (will it be split up into phases) and development approach (traditional or predictive, also known as waterfall, incremental/iterative, agile, or hybrid)

and a lot of project documents.

In the inputs for this process, we have examples from all of the first three categories of elements from the project management plan.    They can be divided into three groups, based on what question they answer:

  • “what’s the plan?”
  • “is the project going according to the plan?” and
  • “how can we get the project back to the plan?”

A.  What’s the plan?

Here are the elements of the project management plan related to the scope, which should give a measure of what the scope is according to plan.

  • Scope management plan–remember that the scope management plan, developed in process 5.1 Plan Scope Management, contains guidelines on how to do all of the other processes of scope management, including this one 5.6 Control Scope.
  • Requirements management plan–this shows specifically how the project requirements will be managed.
  • Scope baseline–contains the project scope statement, the WBS and WBS dictionary.
  • Requirements documentation (including the requirements traceability index)

Remember that the scope comes in three levels of detail:

  • the requirements, which are set forth by the customer or sponsor of the project (located in the Project Charter at a higher level and then in the Requirements Documentation at a more detailed level)
  • the deliverables, which are the products of the project which fulfill the requirements (located in the Project Scope Statement, a part of the Scope baseline) and
  • the Work Breakdown Structure (or WBS) which breaks down the deliverables into manageable, “bite-size” chunks called “work packages”, accompanied by the WBS dictionary, which gives additional information on each work package (who it is to be done by, cost and time estimates, etc.).

B.   Is the project going according to the plan?

Okay, what if the monitoring process shows that the work is somehow NOT being done according to plan?   For that you need the following:

  • Performance measurement baseline:   the three major constraints on a project are scope, schedule and cost.   Earned value analysis combines measures of each of these constraints to get a measurement of the overall performance of the project.  (Details about earned value analysis are contained in chapter 7 on Cost Management.)    The important point here is that earned value analysis tells you whether you are ahead of schedule or behind schedule, and whether you are within your budget or exceeding your budget.

Based on the answer to question B, you may find that the project is NOT going to plan, and so you now have to go to question C:

C.   How can we get the project back to the plan?

This is where change requests come in.   For the guidelines on how to handle these, you need the following:

  • Change management plan (one of the three subsidiary management plans)–shows how to handle the change control process.   Will it be done by the project team as a whole?   Will it be done by a special Change Control Board?   If so, who will be on the Board, and how will decisions be reached?
  • Configuration management plan (if there is a change request that is accepted, how will the documents related to the project be designated so that everybody is working on the current version of the project and not an earlier version)
  • Lessons learned register (lessons learned earlier on in the project with regard to change requests may help the process go more smoothly as the project progresses)

5.6.1.3 Work Performance Data

The actual work done on the scope of the project in the last reporting period goes into the work performance data.   This is important because the tools and techniques in this process will compare the work planned to be done to the actual work done.   Data on the number of change requests received, and the number of requests accepted can be obtained from the change log.

5.6.1.4 Organizational Process Assets

The OPAs that can influence this process include:

  • Templates and reporting methods to be used for monitoring the scope
  • Existing  policies, procedures, and guidelines to control the scope

All of these should be included in the Scope Management Plan.

The next post will deal with the tools/techniques used in this process–the main one is change requests, to bring a project back to the plan (or if necessary, to change the plan to be more realistic).

 

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


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).

 

 

6th Edition PMBOK® Guide–Process 5.5 Validate Scope: Tools and Techniques


How is the process of validating the scope done?   That is the subject of this post.

5.5.2  Validate Scope–Tools and Techniques

5.5.2.1 Inspection

The main tool/technique is that of inspection, which in this case means measuring, examining, and comparing the characteristics of the deliverables to see that they fulfill the requirements and product acceptance criteria developed at the beginning of the project.   I think you can see why it is important that these product acceptance criteria have to be measurable and objective, rather than subjective, because then there is less room for potential disagreement on whether a deliverable does or does not meet those criteria.   For example, “I want the final product to look nice” would not be an objective criteria, because what “looks nice” to one person may not look nice to another person.

As the PMBOK® Guide mentions, in some application areas the inspection may be referred to as a “product review” or “walkthrough.”   The name doesn’t matter as much as the process.

5.5.2.2  Decision Making

As important as the process of inspection is, and in particular the necessity of deciding on the acceptance criteria, it is also important to agree ahead of time on how the decision will be made as to whether the product meets those acceptance criteria.   Who exactly will make the decision?   Will it be solely the customer or sponsor?   Or will the decision be done by a group of people, including some of the project team and;or other stakeholders.   And if so, what will be the method of voting?   Will it have to be a unanimous vote, by majority vote, or vote by a plurality vote?   This also needs to be spelled out ahead of time so if there is any disagreement, there is a clear path towards resolving it.

At the end of the day, there will be one of two possible decisions:   either

a) the final product meets the acceptance criteria, in which case the customer or sponsor sends formal acceptance in the form of a written letter to the project manager.   The project has now officially gone from the monitoring and controlling phase to the closing phase.

or

b) the final product does not meet all of the acceptance criteria, in which case a change request must be made which states the reason for the non-acceptance of certain deliverables.   The project then goes to the Perform Integrated Control process (4.6) and once the changes are made, another attempt is made to do the Validate Scope process (and hopefully get it right this time).

For the outputs to this process, let’s go to the next post.

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.

5.5.1.2  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).

5.5.1.3  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.

5.5.1.4 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

5.4.3.1  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.

5.4.3.2  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

5.4.2.1  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.

5.4.2.2  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

5.4.1.1  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.

5.4.1.2  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

5.4.1.3 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,

5.4.1.4 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.