WBS - Work Breakdown Structure

Revision as of 22:15, 29 April 2023

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, regardless of industry or discipline, the WBS is a key component in the project planning process. 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. Also presented are the different WBS visualization options. 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. 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

• The “what” of the project

The Work Breakdown Structure (WBS) is a clear representation of the project's deliverables and scope - the project's "what" -. The WBS's primary focus is on describing and detailing the project's outputs, scope, or deliverables, and not on “how” or “when” these deliverables will be produced. ^[5]

• The 100% rule

The 100 percent rule is the principle that the total work at the lowest levels of a WBS adds up to the higher levels. This principle ensures that a WBS includes all known scope and deliverables. It applies to all levels of a WBS, so that “the sum of the work at the child level totals the work at the parent level”. ^[5]

• It is hierarchical

WBS numbering follows a hierarchical approach, starting from the top level (level 1) to the bottom level of decomposition (level x). The WBS' depth depends on the project's size and complexity and the level of detail necessary for project planning and management. There are no limits to the levels of decomposition in a WBS. Nevertheless, a “parent” deliverable or task should not be further decomposed when it results in only one “child”. ^[5]

• The "NOs"

The WBS elements do not include costs, imply importance, overlap, assign resources, or account for time or sequence. These elements are only focused on describing and detailing the project's deliverables and scope. ^[5]

• Can be represented in a variety of ways

The WBS can be represented in many different styles. Some of them are presented in section 8. Different visualizations of WBS of this article.

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.

Figure 2: Illustration of Outline Structure (own figure, based on Project Management Institute example ^[5])

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.

Figure 3: Illustration of Tabular Structure (own figure, based on Project Management Institute example ^[5])

Limitations

Some limitations of the WBS are:

• 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

• Resource Breakdown Structure (RBS)

When combined with the WBS, the resource breakdown structure (RBS), which outlines the project's resource organization, allows for the completion of work package assignments. The relationship between work packages and the RBS enables the project team to confirm that each member has been appropriately assigned to work packages and that each work package has an owner. ^[5]

• Organizational Breakdown Structure (OBS)

The Organizational Breakdown Structure (OBS) shows the organizational structure and hierarchy, enabling the work packages for the project to be connected to the operational organizational units. The principle that each work package should have a single point of responsibility is reinforced by this tool. While the WBS strictly organizes deliverables, the OBS shows in a clear way the hierarchy of individuals or groups, making it a useful tool for managers. ^[5]

• Project Schedule & Gantt Chart

To guarantee that all components of the project are delivered on time, schedule planning entails the creation of project schedules based on the WBS. These schedules are used to ensure that all project elements are completed within their respective deadlines. Besides, these are essential for coordinating the various tasks and for achieving significant milestones. One of the most common scheduling techniques is the Gantt Chart. ^[10]

A Gantt Chart is "a graphical representation of the duration of tasks against the progression of time" ^[11]. The project manager can use it to estimate how long the plan should take, specify the order in which activities must be completed, and keep track of task dependencies ^[11].

• Risk Breakdown Structure

Figure X:An example of Risk Breakdown Structure. Own figure, created based on [Managing Successful Projects with PRINCE2, 2017 Edition] ^[11]

Annotated bibliography

Recommended bibliography on WBS include:

• “The ABC Basics of the WBS” by Paul Burek, 2013.

The main emphasis of this paper is on the techniques that project stakeholders can employ to develop their project WBS and attain comprehension of all the project outcomes. It aims to distinguish between the project WBS and the project schedule while also demonstrating the connection between these two deliverables. The paper presents the universal attributes of the WBS and gives instances of three distinct types of WBS deliverables ^[2].

• “Practice Standard for Work Breakdown Structures”, Third Edition, 2019

This practice standard aims to achieve several objectives, including establishing a shared understanding of the fundamental concepts and principles of the WBS. Additionally, it provides guidance and recommended practices for creating and utilizing the WBS while encouraging the standardized application of the WBS as a crucial component for ensuring integrated control of various aspects such as program or project schedule, cost, risk, resource, technical, and contractual elements. By promoting consistent use of the WBS, this practice standard enhances the effectiveness and efficiency of program or project planning and control initiatives ^[5].

• ISO 21511:2018, "Work breakdown structures for project and programme management"

This document offers direction on work breakdown structures for organizations involved in project or program management. It is suitable for any organization, regardless of its type, size, or sector, as well as for any project or program in terms of complexity, size, or duration. The document includes definitions, concepts, characteristics, benefits, uses, integration, and relationships relevant to WBS. ^[4]

References

1. ↑ ISO/TR 21506:2018, Project, programme and portfolio management – Vocabulary(Committee: ISO/TC 258)
2. ↑ ^{2.0 2.1} 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. ↑ ^{4.0 4.1} ISO 21511:2018, Work breakdown structures for project and programme management (Committee: ISO/TC 258)
5. ↑ ^{5.00 5.01 5.02 5.03 5.04 5.05 5.06 5.07 5.08 5.09 5.10} Project Management Institute, Inc. (PMI). (2019). Practice Standard for Work Breakdown Structures (3rd Edition). Project Management Institute, Inc. (PMI). Retrieved from https://app.knovel.com/hotlink/toc/id:kpPSWBSE11/practice-standard-work/practice-standard-work
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.
10. ↑ Izanhour, P. L. (1982). How to Determine when Project Management Techniques are Required. Project Management Quarterly, 13(1), 47–49. Retrieved from https://www.pmi.org/learning/library/project-management-techniques-determination-10335
11. ↑ ^{11.0 11.1 11.2} AXELOS. Managing Successful Projects with PRINCE2 2017 Edition, The Stationery Office Ltd, 2017. ProQuest Ebook Central. Retrieved from: https://ebookcentral.proquest.com/lib/DTUDK/detail.action?docID=4863041