How to Build Work Breakdown Structures

How to Build Work Breakdown Structures Additional Lecture Material from Garrett Rowley, Adjunct Professor, UMGC

 

WBS Overview

To begin, here is how the PMBOK® defines the WBS: “The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project and represents the work specified in the current approved project scope statement.” (Project Management Institute, 2017)

Notice the emphasis placed on project scope. It is the starting point for getting from a high-level concept down to the details of the work needed to execute the project and ultimately satisfy the scope. That happens through something called decomposition.

“Decomposition is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. The work package is the work defined at the lowest level of the WBS for which cost, and duration can be estimated and managed.” (Project Management Institute, 2017)

IMPORTANT:

• A WBS is not a schedule

• A schedule is not a WBS

• Neither a WBS nor a schedule is an unordered checklist

It is important for you to understand how all this works before you begin Week 3. A correctly structured WBS will enable you to produce the results expected from ITP-1 Project WBS with Durations, TTP-4 Project Costs and Resources and TPP-6 Project Execution, Tracking and Changes.

Top-Down WBS Creation

• Step 1: Identify the final products of the project – what must be delivered to achieve project success. A thorough review of high-level project scope documents is recommended to ensure consistency between the WBS and the project requirements.

• Step 2: Define the project’s major deliverables, which are often interim deliverables (such as a design specification) necessary for the project, but which in themselves do not satisfy a business need.

• Step 3: Decompose major deliverables to a level of detail appropriate for management and integrated control. These WBS elements are normally tied to clear and discrete identification of stand-alone deliverable products. The sum of the elements at each level should represent 100% of the work in the element above it (the 100% Rule). Each work package of the WBS should contain only one deliverable.

• Step 4: Review and refine the WBS until project stakeholders agree that project planning can be successfully completed, and that execution and control will successfully produce the desired deliverables and results.

(Project Management Institute, 2006)

 

 

Page 2 of 9 June 2021

Definitions

This is where Microsoft Project® diverges from Haugan, PMI, and other project management experts. PMI uses three descriptors in the WBS:

1. WBS Element

2. Work Package

3. Activity

Project® uses only two:

1. Summary Task

2. Subtask

Since we are using Project® in this class, we will use Microsoft’s descriptors. (Microsoft Office Support, n.d.) Summary Task:

• Is the Project® equivalent of a WBS element1

• Is made up of subtasks (or other summary tasks) indented below it

• Shows a rollup of the combined information from subtask(s)

• Never has work or resources assigned

• Named using adjective/noun format (represents a deliverable)

• Does not use verbs in the name (no action is performed)

Subtask:

• Is the Project® equivalent of an activity

• Is a component of work performed during the course of a project

• Named using verb, adjective, and noun format (conveys action)

• Has defined start and finish points

• Has expected duration, cost, and resource requirements

• Has a single person or organization responsible for the work

• Has tangible output or product at completion

• Fits logically under an existing Summary Task

WBS Example

Here is a hypothetical project from Haugan. Watch as I decompose it into smaller parts. Assume the objective statement goes something like, “Develop a Time-Sharing System (TSS)”. Rather simple, but I like it. As an experienced TSS project manager, I know we need to deliver:

1) A requirements specification

2) A design specification

3) The TSS software

 

1 At the lowest level of the WBS, the summary task is equivalent to a work package and provides a logical basis for defining activities as

subtasks.

 

 

Page 3 of 9 June 2021

Figure 1: TSS Project at WBS Level 1

When building the WBS, you must understand how WBS numbering works. Figure 1 shows WBS Level 1 for the TSS project. This level represents the major deliverables of the project. Now we can decompose the WBS into lower levels. As you might suspect, there is a convention for structuring WBS levels:

• The high-level product elements, or major deliverables, belong at Level 1

• The Project Management element also belongs at Level 1

o This is for the managerial responsibilities and activities of the project including such items as reports, project reviews and other activities of the project manager and staff

o The WBS always has a Project Management element

• The decomposition of the Level 1 elements belongs at Level 2 or lower

• Decomposition of a WBS branch ends with a Work Package element (no more decomposition allowed)

• Use an outline numbering scheme, a simple hierarchy of numbers and decimals representing WBS levels2

 

Figure 2: TSS Project at WBS Level 2

That’s it! My WBS is finished. Notice:

1) I did not indent any WBS elements

2) I used Excel® to build my WBS3

Here are several points to take into consideration when building your WBS:

• The WBS structure is not based on timing or sequence dependencies among components. Timing, sequencing, and dependencies are project schedule concerns.

• The WBS is not strictly structured by process or organization.

2 For example: 1, 1.1, 1.1.1, 1.1.2, 1.2, 1.2.1, 1.2.2, 1.2.3, etc. 3 Since Project® manages WBS numbering, I will only copy the WBS elements into Project® – not the WBS numbers.

 

 

Page 4 of 9 June 2021

• The WBS defines the logical relationships among all components of the project.

• All WBS elements are deliverable-oriented.

• Project activities are not listed, as these are components of the project schedule, not the WBS.

• All WBS element names are nouns. Verbs are not used to identify WBS elements.

• The WBS includes only sufficient and necessary deliverables as defined in the project scope.

• All project deliverables (i.e., regulatory permits, packaging, distribution, or marketing, as well as preliminary, interim, internal, external, or final deliverables) are identified and detailed.

• There are no WBS elements with overlapping responsibilities. Each WBS element must have one person who is clearly accountable for its completion.

The WBS is NOT the same as your project schedule. Over the years, I have seen a lot of Project Managers confuse the two. Don’t be that PM! On the other hand, the WBS will be used in the project schedule. That is why I did not indent any WBS elements. I am going to copy the list of WBS elements (but not the WBS numbers) and paste them into Project®.

Schedule Development Process

Starting with the WBS: 1) Enter the WBS in Project® 2) List all deliverable end items or services under their appropriate WBS element 3) Define and list tasks (activities) under each lowest-level summary task (WBS element, i.e., the

work package) 4) Establish task durations and, if applicable, task resources 5) Identify predecessor – successor relationships between tasks 6) Iterate steps 3 and 4 as necessary to achieve a workable schedule

(Haugan, 2002) Notice the WBS numbering in Figure 3. It has no decimals yet because the WBS elements are not indented. (Microsoft Office Support, n.d.)

Figure 3: WBS Entered in Project

 

 

Page 5 of 9 June 2021

Figure 4 shows the result of Steps 1 and 2 of the schedule development process. In this project, the finished WBS goes to WBS level 2 where the work packages show outlined in red.

Figure 4: WBS Level 2 work packages

 

 

Page 6 of 9 June 2021

Completing Step 3 of the process adds subtasks (activities) at WBS level 3 indented under the WBS level 2 summary tasks (work packages). Figure 5 shows the resulting project with subtasks outlined in red4.

Figure 5: WBS Level 3 activities

 

4 It is normal and usual to add two milestones to a project – one for Project Start and one for Project Complete, I placed them at WBS level 1.

 

 

Page 7 of 9 June 2021

Completing steps 4 (establish task durations) and 5 (identify predecessor – successor relationships) of the Schedule Development Process results in the fully loaded project shown in Figure 6.

Figure 6: The TSS project schedule

 

 

 

Page 8 of 9 June 2021

The “Hidden” Level There is a WBS Level that I have not yet explained. It is Level 0, also known as the Project Level of the WBS. Project® automatically creates it for you, based on the file name used when saving the project file. By default, Project® defaults to hiding Level 0 but you can (and should) reveal it:

• From the ribbon, open the Format tab

• From the Show/Hide group, select Project Summary Task

Here is what you get:

 

WBS Final Thoughts As you go through your assignments, it is important to get the terminology right. Since the beginning, Microsoft has called every row in a project schedule a task. This is not consistent with the PMBOK® Guide or with Haugan or with practically any career project manager. If you fall into the habit of thinking everything is a task instead of distinguishing between WBS elements and activities, your project schedules will not work as intended.

 

 

Page 9 of 9 June 2021

References Haugan, G. (2002). Effective Work Breakdown Structures. Vienna, VA: Management Concepts.

Microsoft Office Support. (n.d.). Create and work with subtasks and summary tasks in Project desktop.

Retrieved from support.office.com: https://support.office.com/en-us/article/create-and-work-

with-subtasks-and-summary-tasks-in-project-desktop-b3ff64ce-b121-42cc-905b-cb9b8ce0255f

Microsoft Office Support. (n.d.). Outline Level fields. Retrieved from support.office.com:

https://support.office.com/en-us/article/outline-level-fields-0453d348-d9ec-4172-9b00-

77702c18ce73

Project Management Institute. (2006). Practice Standard for Work Breakdown Structures, 2nd ed.

Newtown Square, PA: PMI.

Project Management Institute. (2017). PMBOK Guide – 6th Edition. Newtown Square, PA: PMI.