WBS - Work Breakdown Structure

Latest revision as of 17:51, 8 May 2023

[edit] 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 preparation methods and visualization options for the WBS. 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.

[edit] 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 indispensable tool to consistently track schedule, budget, risk and performance, regardless of discipline" ^[5].

PRINCE2 (Projects in a Controlled Environment), on the other hand, has a "principle to focus on products" ^[6]. Therefore, in the book Managing Successful Projects with PRINCE2 2017 Edition, the difference between a WBS and a Product Breakdown Structure is presented. While the WBS focuses on the decomposition of the work that needs to be completed under a project, the Product Breakdown Structure is a "hierarchy of all the products to be produced during a plan" ^[6].

[edit] History

In this section, the most important milestones of the origin and development of the tool will be briefly presented:

• In 1957, the U.S. Navy’s Fleet Ballistic Missile (Polaris) Program developed the Program Evaluation and Review Technique (PERT). From the early 1960s, organizations and businesses started recognizing the advantages of structuring work around projects, and acknowledging the crucial importance of communicating and coordinating work among various departments and professions. ^[7]

• In 1962, the Department of Defense (DOD) and NASA published the first description of the work breakdown structure process in a document about the PERT/COST system, although they did not reference the WBS by name. ^[8]

• 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. ^[9]

• In 1987, the Project Management Institute, through the Project Management Body of Knowledge (PMBOK), established Work Breakdown Structures as standard practice for a range of nonmilitary applications. ^[10]

• Then, in 2001, the PMI published the first edition of the WBS Practice Standard. The PMBOK guide provides an overview of the WBS, while the "Practice Standard for Work Breakdown Structures" is comparable to the DoD standard in the sense that provides guidance and recommended practices for creating and utilizing the WBS. The most recent revision of the practice standard is the third edition, which was released in 2019.^[5]

[edit] WBS Dictionary

The WBS dictionary is a document that accompanies the WBS and contains important information about the project. Its purpose is to define, elaborate, and clarify the different components of the WBS, ensuring that each part accurately conveys the content to anyone who refers to the WBS. While developing the WBS dictionary, any ambiguity or errors in the WBS are typically identified and corrected.^[5]

The WBS dictionary provides detailed information on every element of the WBS, such as descriptions of the work, deliverables, activities, and milestones associated with each component. Additionally, it may include information about the resources required. Furthermore, the WBS dictionary may contain traceability matrices that link the WBS to other documents, such as statements of work or requirements documents, used for scope control.^[5]

The dictionary is prepared by the project team to ensure that all work scope has been identified and to eliminate duplication and overlap of work assignments. The lower the level of a WBS element, the greater the level of descriptive detail needed. It 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. ^[11]

[edit] 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.

[edit] 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 ^[11].
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 ^[11].
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 ^[12]. 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.^[11].
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 ^[12].
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” ^[12]. 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 ^[11]. 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 ^[12].

[edit] 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? ^[13]
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 ^[12].
3. Is it comprehensive? Are all relevant stakeholders able to understand it?
4. Does the sub-division of WBS elements reflect an accurate, logical, and compatible hierarchy of work scope? ^[11]
5. Do any elements of the WBS overlap? These should be mutually exclusive, meaning that no elements should overlap in scope definition. If an overlap exists, it could duplicate the team’s efforts and/or create confusion around accountability. ^[11]
6. Does the WBS Dictionary provide complete and explicit content descriptions? ^[11]
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?^[11] It should be accurate but not necessarily precise.
8. Are there significant clashes with organisational settings? ^[13]

[edit] Preparation Methods

A WBS can be built using a variety of methods and approaches. The best approach can be chosen based on the individual project objectives, needs, assumptions, and restrictions.^[5] The most common ones are presented below.

[edit] Top-down approach

In the Top-down approach, the first step is to identify the final result that has to be reached to achieve the project's success, it can also be the delivery of a certain product or a service. After the major deliverable has been defined, it must be decomposed to a level of detail that allows for control and management of the project's progress, always following the 100% rule. This approach requires constant attention so that no deliverable is missed.^[5]

[edit] Bottom-up approach

While using the Bottom-up approach, the team first defines all deliverables before working backward into the larger project. Therefore, all deliverables or work packages must be identified before starting the development of the WBS. Furthermore, all identified work packages need to be grouped together logically, to then aggregate these to the next level (“parent” level).^[5]

[edit] Organizational Standards and Templates

Besides, each organization can set its own standards for the construction of the WBS to guarantee that these are consistent, complete, and comprehensive across the whole business. These can define a specific format, numbering scheme, naming format, or mandatory elements to be included. Companies that have a high level of project management often develop these. ^[5]

Last, a company can also develop templates to promote uniformity, consistency, and quality assurance of WBS across the company. Top-down and bottom-up approaches are used to build new work breakdown structures, whereas standards and templates entail the reuse of pre-existing WBS materials.^[5]

[edit] Different visualizations of WBS

The WBS can be represented in many different ways, including Outline, Hierarchical, or Tabular styles ^[5].

[edit] 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 1: Illustration of Outline Structure. (Own figure, based on Project Management Institute example ^[5]).

[edit] Hierarchical Structure

The hierarchical 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 2: Illustration of Hierarchical Structure. (Own figure, based on Project Management Institute example ^[5]).

[edit] 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]).

[edit] Limitations

While the Work Breakdown Structure (WBS) offers many advantages, it is important for the project team to also consider its potential limitations. First, creating the WBS can be a time-consuming process, especially for larger projects. The larger the scope of the project is, the bigger the WBS will be and the longer it will take.

Additionally, as mentioned before, all relevant stakeholders should participate in the brainstorming session. It can be difficult to achieve this and besides, differences of opinion may arise. It is crucial that everyone involved understands and supports the WBS for it to be effective. Achieving this can be challenging, particularly if people are reluctant to change. ^[11]

Furthermore, the WBS is also expected to change throughout the project's life cycle, so it is recommended to have a change revision history of the document to track changes. Another important consideration is applying the 100% rule, which means that the WBS should not include more than 100% of the project's scope. Including more than 100% of the scope can result in "scope creep", which can put the project's success at risk. ^[5]

Moreover, it is important to note that the WBS should only contain all deliverables, not activities ^[5]. The work may be completed in various ways (activities), but deliverables should remain consistent unless a formal change request is made, hence activities should not be included.

As mentioned before, the WBS does not include the project schedule. Its contents are not required to be followed in any type of order or sequence. Therefore, it is recommended to complement the WBS with other tools, such as the Gantt chart.

Finally, the WBS 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. For these reasons, in order to use the WBS effectively, other tools should be used in conjunction with it.

[edit] 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]

Figure 4: Example of Risk Breakdown Structure. (Own figure, based on Project Management Institute Example ^[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]

Figure 5: Example of Organizational Breakdown Structure. (Own figure, based on Project Management Institute Example ^[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. ^[14]

A Gantt Chart is "a graphical representation of the duration of tasks against the progression of time" ^[6]. 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 ^[6].

• Risk Breakdown Structure

The Risk Breakdown Structure offers a hierarchical representation of potential sources of risk to the project. As the levels descend, these provide a more detailed definition of these sources of risk. It is designed to guide and assist the project management team in identifying potential risks to the project objectives. There are various approaches for breaking down risks, and it may be helpful to create multiple lists with different approaches. For instance, one structure could be based on the PESTLE framework, which includes political, economic, social, technological, legal, and environmental factors. ^[6]

Figure 6: Example of Risk Breakdown Structure. (Own figure, based on Managing Successful Projects with PRINCE2, 2017 Edition ^[6]).

[edit] 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 its standardized application. It presents the WBS as a crucial component for ensuring integrated control of 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]

• “NASA Work Breakdown Structure (WBS) Handbook“, October 2016

This document aims to offer program and project teams with essential directions and recommendations on the most effective methods for creating and utilizing a WBS and a WBS dictionary. It is a comprehensive guide that can be applied to all types of NASA projects and activities, such as research, development, construction, testing, evaluation, and operations. ^[11]

Although this document was built by NASA and is dedicated to its projects, it includes generic recommendations and guidelines regarding the WBS that can be applied to any project no matter the field.

[edit] 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 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22 5.23} 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 6.2 6.3 6.4 6.5} 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
7. ↑ Shenhar, A. & Dvir, D. (2004). Project management evolution: past history and future research directions Paper presented at PMI® Research Conference: Innovations, London, England. Newtown Square, PA: Project Management Institute. Retrieved from: https://www.pmi.org/learning/library/project-management-evolution-research-directions-8348
8. ↑ DOD and NASA Guide, PERT/COST System Design, June 1962
9. ↑ MIL-STD-881, 1 November 1968
10. ↑ Project Management Institute, Inc. (PMI). (2021). A Guide to the Project Management Body of Knowledge (PMBOK ® Guide) – 7th Edition and The Standard for Project Management - The Standard for Project Management. Project Management Institute, Inc. (PMI). Retrieved from: https://app.knovel.com/hotlink/pdf/id:kt012LZEEB/guide-project-management/standard-project-management
11. ↑ ^{11.00 11.01 11.02 11.03 11.04 11.05 11.06 11.07 11.08 11.09 11.10} NASA Work Breakdown Structure (WBS) Handbook, October 2016, NASA/SP-2016-3404/REV1. Retrieved from: https://ntrs.nasa.gov/citations/20160014629
12. ↑ ^{12.0 12.1 12.2 12.3 12.4} Webster, F. M. (1994).The WBS. PM Network, 8(12), 40–46.
13. ↑ ^{13.0 13.1} Oehmen, Josef & Thuesen, Christian, Content of the course 42429/30 Project Management at DTU, 42430 - Week 2 - Part 3 - Complexity slides.
14. ↑ 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