WBS - Work Breakdown Structure

Revision as of 18:45, 9 April 2023

Author: Manuela Vazquez, s222648

Disclaimer: Most of the figures are still missing, and I need to fix the resolution of the two ones that I added.

Abstract

The International Organization for Standardization (ISO) defines the Work Breakdown Structure (WBS) as a “decomposition of the defined scope of a project or programme into progressively lower levels consisting of elements of work” ^[1]. It represents all the deliverables to be produced by the project or program for which work activities will be defined, planned, and executed ^[2]. No matter whether the project solution will result in a physical product, service, or process, all can be defined from the deliverables’ perspective. Therefore, the WBS is a key component in the project planning process, regardless of industry or discipline. Failing to do an appropriate WBS can result in rework, schedule changes, poorly distributed resources, and budget increases ^[3].

The present article first summarizes the different definitions of the WBS and references the current standards which directly address it. The history of its origin and development are also presented. In addition, the key attributes of the WBS are described, as well as the aspects that need to be considered when creating and evaluating the tool. The different possible visualizations for the WBS are presented, along with an extensive example of its application. Furthermore, the limitations of the WBS will be explored, as well as other complementary and related tools, such as the Organizational Breakdown Structures (OBS). Finally, additional bibliography is recommended for readers who want to learn more about the topic.

Definition and use

The WBS is a hierarchical decomposition in which the project or programme scope is divided into successively smaller work breakdown structure elements to be carried out by the project team ^[4]. ISO 21511 standard provides guidance on the use of this tool for those involved in developing and using it, and complements ISO 21500 and ISO 21504.

• ISO 21511:2018 Work breakdown structures for project and programme management
• ISO 21500:2021 Project, programme and portfolio management — Context and concepts
• ISO 21504:2022 Project, programme and portfolio management — Guidance on portfolio management

In addition, the Project Management Institute (PMI) released the third edition of the "Practice Standard for Work Breakdown Structures" in 2019. As explained by the PMI, "this practice standard aligns with other recent PMI standards, including A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition, providing practitioners with an indispensible tool to consistently track schedule, budget, risk and performance, regardless of discipline" ^[5].

History

Origin and development of the tool, retrieved from “Getting Started with Work Breakdown Structures (WBS)” ^[6].

• In 1957, the U.S. Navy’s Fleet Ballistic Missile (Polaris) Program developed the Program Evaluation and Review Technique (PERT) .
• In 1962, the Department of Defense (DOD) and NASA published the first description of the work breakdown structure process, although they did not referenced it by name.
• In 1968, the first reference by name came. The Work Breakdown Structures for Defense Materiel Items (MIL-STD-881) established work breakdown structures as a standard across the DOD.
• In 1987, the Project Management Institute, through PMBOK, established work breakdown structures as standard practice for a range of nonmilitary applications.
• In 1993, the term “work breakdown structure” was introduced for applications in corporate and other organizational projects.
• In 1995, “The Intelligent Structure of Work Breakdowns Is a Precursor to Effective Project Management” by Homer & Gunn was published.
• In 1999, the PMI Standards Program issued a project charter to develop the Work Breakdown Structure (WBS) Practice Standard.
• In 2001, the PMI published the first edition of the WBS Practice Standard.

WBS Dictionary

The WBS Dictionary contains all the details of the WBS which are needed to successfully complete the project. It is prepared by the project team to ensure that all work scope has been identified and to eliminate duplication and overlap of work assignments (cita). It defines each Work Package, and it can include the description, deliverables, activities, milestones, cost, level of effort, resources assigned, and responsible. The lower the level of a WBS element, the greater the level of descriptive detail needed. The dictionary may also contain an index that lists the WBS elements in indented format to show their hierarchical relationship. Resources on the project will look at the WBS dictionary to determine the scope of the Work Package they have been assigned, so it is important to be detailed and clear when writing the definition.

Key attributes

• It is “deliverable orientated”.
• It is hierarchical
• The 100% Rule (Haugan, 2002, p 17)
• Develop them down to a level of detail using the 8 to 80 rule
• Can be represented in a variety of ways

How to create a WBS

Even though there is no single "correct way" to prepare a WBS, some generally recommended guidelines can be followed by the project team to ensure that proper WBS characteristics exist for any project. Considering the following general guidelines will assist in creating and implementing the WBS:

1. The WBS is prepared as early as the project definition will permit ^[7].
2. A preliminary WBS is initially developed early in project formulation to define the top levels of a WBS. These preliminary elements should reflect the entire scope of the project including project definition, development, launch, and operations ^[7].
3. A brainstorming session should be organized with the various departments involved in the project, inviting all relevant stakeholders. Furthermore, involvement in planning leads to motivation to carry out the plan ^[8]. All relevant stakeholders need to be involved to ensure that proper planning is done and that all parties agree on the final WBS prior to approval.^[7].
4. In this aforementioned session, first identify the main goal of the project, then the deliverables, and lastly the activities required for each deliverable. Focus primarily on one higher level element at a time, this way the ability to think about the lower-level elements required is enhanced and omissions are avoided ^[8].
5. Changes in the project are usually inevitable as learning happens during the life cycle of the project. Therefore, “consideration should be given in developing the WBS as to how changed requirements and work content will be incorporated into the approved WBS” ^[8]. Hence, change control is crucial. As the project scope of work changes, the WBS is revised to reflect formally approved changes. Again, all parties involved must agree on the changes.
6. All top-level WBS elements do not have to be subdivided to the same level of detail. As associated element risk, cost, or complexity increases, further breakdown may be necessary ^[7]. It is an iterative process: to go up the structure “why?” should be asked, and “how?” when going down, until the WBS is ‘stable’ and no major changes are required.
7. To ensure accurate and good communication between the people involved, the definition of the terms used should be consistent over the entire WBS and, ideally, across all projects carried out in the same organization ^[8].

How to evaluate a WBS

After finishing the WBS, there are some questions that the project team can ask themselves to ensure that all main factors have been considered during the development. For example, a checklist could be followed. Some possible questions are presented below:

1. It is advisable to break down the work around deliverables or goals, not tasks. Are they task oriented or deliverable oriented? ^[9]
2. Does the overall WBS structure include 100% of the project scope of work? The work content of an element must be the sum of the work content of all its immediately subordinate elements ^[8].
3. Is it comprehensive? Are all relevant stakeholders able to understand it?
4. Does the sub-division of WBS elements reflect accurate, logical, and compatible hierarchy of work scope? ^[7]
5. Do any elements of the WBS overlap? These should be mutually exclusive, meaning that no elements should overlap in scope definition. If there exists an overlap it could duplicate the team’s efforts and/or create confusion around accountability ^[6].
6. Does the WBS Dictionary provide complete and explicit content descriptions? ^[7]
7. Does the WBS sub-divide the project scope of work down to an adequate level of detail to provide for effective resource planning, management insight, and performance measurement?^[7] It should be accurate but not necessarily precise.
8. Are there significant clashes with organisational settings? ^[9]

Different visualizations of WBS

The WBS can be represented in many different ways, including graphical, textual, or tabular styles ^[5].

Outline

In the outline style, each level of the WBS is displayed by the level of indentation and is complemented by an alphanumeric outline code or numbering scheme. It is a very popular way to portray the WBS. In some cases, the outline style might not use indentation and instead simply use the numerical system to display the hierarchy. This can be done to save space but makes the WBS less intuitive for the reader.

Hierarchical Structure

It is also a very common type, in which each child element is connected to its parent element by a line inside a box. The hierarchical breakdown of the project and its constituent parts into progressively smaller parts is made very clear by this representation.

Figure 1: Illustration of Hierarchical Structure (own figure, based on Project Management Research example)

Tabular Structure

The tabular structure is a table view of the WBS. In this table, the columns stand in for the hierarchical structure. When using a text document with restricted formatting capabilities to build the WBS, the tabular style is frequently used.

Limitations

TBD, to be developed for the next hand-in. Some limitations could be:

• The process of creating the WBS can be long. The larger the scope of the project is, the bigger the WBS will be and the longer it will take.
• As mentioned before, all relevant stakeholders should participate in the brainstorming session. If it is a big project, there would be more people involved and differences of opinion may arise when defining the WBS.
• The WBS is expected to change in the life cycle of the project. The initial version is very often updated when the project's scope changes or is better defined.
• A very important design principle of WBS is applying the 100% rule. A project could be bound to fail if the WBS includes more than 100% of the scope.
• The WBS should contain all deliverables. It should not include activities and some teams tend to confuse this. How the work is completed (activities) can vary throughout the project, but deliverables cannot change without a formal change request, hence activities should not be included.
• The WBS does not include the project schedule. Its contents are not required to be followed in any type of order or sequence. Hence, it is recommended to complement the WBS with other tools, such as the Gantt chart.
• Connected to the last point, the WBS also does not display how challenging the deliverables are. It also does not show the budget or the resources the team will need to accomplish them. Therefore, to effectively use the WBS, other tools should be used in connection to it.

Related Tools

• Functional breakdown
• Organizational breakdown structures (OBS)
• Risk breakdown structure (RBS)

Figure 2: RBS for Construction Design (after Chapman, 2001)

• Product breakdown structure (PBS)

Annotated bibliography

Good resources on WBS include:

• “The ABC Basics of the WBS” by Paul Burek, 2013
• “The Intelligent Structure of Work Breakdowns Is a Precursor to Effective Project Management”, Homer & Gunn, 1995
• “Practice Standard for Work Breakdown Structures”, Third Edition, 2019
• ISO 21511:2018, "Work breakdown structures for project and programme management"
• ISO 21502:2020, "Project, programme and portfolio management — Guidance on project management"

References

1. ↑ ISO/TR 21506:2018, Project, programme and portfolio management – Vocabulary(Committee: ISO/TC 258)
2. ↑ Burek, P. (2013), The ABC basics of the WBS. Paper presented at PMI® Global Congress 2013—North America, New Orleans, LA. Newtown Square, PA: Project Management Institute.
3. ↑ Jones, C. (2007). Creating an effective WBS with facilitated team involvement. Paper presented at PMI® Global Congress 2007—North America, Atlanta, GA. Newtown Square, PA: Project Management Institute.
4. ↑ ISO 21511:2018, Work breakdown structures for project and programme management (Committee: ISO/TC 258)
5. ↑ ^{5.0 5.1} Practice Standard for Work Breakdown Structures – Third Edition (2019)(retrieved from: https://www.pmi.org/pmbok-guide-standards/framework/practice-standard-work-breakdown-structures-3rd-edition#)
6. ↑ ^{6.0 6.1} Kate Eby, Getting Started with Work Breakdown Structures (WBS), (Retrieved on 11. February 2023 from https://www.smartsheet.com/getting-started-work-breakdown-structures-wbs)
7. ↑ ^{7.0 7.1 7.2 7.3 7.4 7.5 7.6} NASA Work Breakdown Structure (WBS) Handbook, January 2010, NASA/SP-2010-3404
8. ↑ ^{8.0 8.1 8.2 8.3 8.4} Webster, F. M. (1994).The WBS. PM Network, 8(12), 40–46.
9. ↑ ^{9.0 9.1} Oehmen, Josef & Thuesen, Christian, Content of the course 42429/30 Project Management at DTU, 42430 - Week 2 - Part 3 - Complexity slides.