Work breakdown structure

Last updated
Example from MIL-HDBK-881, which illustrates the first three levels of a typical aircraft system Work Breakdown Structure of Aircraft System.jpg
Example from MIL-HDBK-881, which illustrates the first three levels of a typical aircraft system
Working on a project WBS Project-wbs.jpg
Working on a project WBS

A work-breakdown structure (WBS) [2] in project management and systems engineering, is a deliverable-oriented breakdown of a project into smaller components. A work breakdown structure is a key project deliverable that organizes the team's work into manageable sections. The Project Management Body of Knowledge (PMBOK 5) defines the work-breakdown structure as 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."


A work-breakdown structure element may be a product, data, service, or any combination thereof. A WBS also provides the necessary framework for detailed cost estimating and control along with providing guidance for schedule development and control. [3]


WBS is a hierarchical and incremental decomposition of the project into phases, deliverables and work packages. It is a tree structure, which shows a subdivision of effort required to achieve an objective; for example a program, project, and contract. [4] In a project or contract, the WBS is developed by starting with the end objective and successively subdividing it into manageable components in terms of size, duration, and responsibility (e.g., systems, subsystems, components, tasks, subtasks, and work packages) which include all steps necessary to achieve the objective.

Example of work breakdown structure applied in a NASA reporting structure NASA NF 533 reporting structure.jpg
Example of work breakdown structure applied in a NASA reporting structure

The work breakdown structure provides a common framework for the natural development of the overall planning and control of a contract and is the basis for dividing work into definable increments from which the statement of work can be developed and technical, schedule, cost, and labor hour reporting can be established. [4]

A work breakdown structure permits summing of subordinate costs for tasks, materials, etc., into their successively higher level "parent" tasks, materials, etc. For each element of the work breakdown structure, a description of the task to be performed is generated. [5] This technique (sometimes called a system breakdown structure [6] ) is used to define and organize the total scope of a project.

The WBS is organized around the primary products of the project (or planned outcomes) instead of the work needed to produce the products (planned actions). Since the planned outcomes are the desired ends of the project, they form a relatively stable set of categories in which the costs of the planned actions needed to achieve them can be collected. A well-designed WBS makes it easy to assign each project activity to one and only one terminal element of the WBS. In addition to its function in cost accounting, the WBS also helps map requirements from one level of system specification to another, for example, a cross reference matrix mapping functional requirements to high level or low level design documents. The WBS may be displayed horizontally in outline form, or vertically as a tree structure (like an organization chart).

The development of the WBS normally occurs at the start of a project and precedes detailed project and task planning.


The concept of work breakdown structure developed with the Program Evaluation and Review Technique (PERT) by the United States Department of Defense (DoD). PERT was introduced by the U.S. Navy in 1957 to support the development of its Polaris missile program. [7] While the term "work breakdown structure" was not used, this first implementation of PERT did organize the tasks into product-oriented categories. [8]

By June 1962, DoD, NASA and the aerospace industry published a document for the PERT/COST system which described the WBS approach. [9] This guide was endorsed by the Secretary of Defense for adoption by all services. [10] In 1968, the DoD issued "Work Breakdown Structures for Defense Materiel Items" (MIL-STD-881), a military standard requiring the use of work breakdown structures across the DoD. [11]

The document has been revised several times, most recently in 2018. The current version of this document can be found in "Work Breakdown Structures for Defense Material Items" (MIL-STD-881D). [12] It includes WBS definitions for specific defense materiel commodity systems, and addresses WBS elements that are common to all systems.

Defense Materiel Item categories from MIL-STD-881D are:

The common elements identified in MIL-STD-881D, Appendix K are: Integration, assembly, test, and checkout; Systems engineering; Program management; System test and evaluation; Data; Peculiar support equipment; Common support equipment; Operational/Site activation; Contractor Logistics Support; Industrial facilities; Initial spares and repair parts. The standard also includes additional common elements unique to Space Systems, Launch Vehicle Systems, and Strategic Missile Systems.

In 1987, the Project Management Institute (PMI) documented the expansion of these techniques across non-defense organizations. The Project Management Body of Knowledge (PMBOK) Guide provides an overview of the WBS concept, while the "Practice Standard for Work Breakdown Structures" is comparable to the DoD standard, but is intended for more general application. [13]

Design principles

100% rule

An important design principle for work breakdown structures is called the 100% rule. [14] It has been defined as follows:

The 100% rule states that the WBS includes 100% of the work defined by the project scope and captures all deliverables – internal, external, interim – in terms of the work to be completed, including project management. The 100% rule is one of the most important principles guiding the development, decomposition and evaluation of the WBS. The rule applies at all levels within the hierarchy: the sum of the work at the "child" level must equal 100% of the work represented by the "parent" and the WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work… It is important to remember that the 100% rule also applies to the activity level. The work represented by the activities in each work package must add up to 100% of the work necessary to complete the work package. [15]

Mutually exclusive elements

Mutually exclusive: In addition to the 100% rule, it is important that there is no overlap in scope definition between different elements of a work breakdown structure. This ambiguity could result in duplicated work or miscommunications about responsibility and authority. Such overlap could also cause confusion regarding project cost accounting. If the WBS element names are ambiguous, a WBS dictionary can help clarify the distinctions between WBS elements. The WBS Dictionary describes each component of the WBS with milestones, deliverables, activities, scope, and sometimes dates, resources, costs, quality.

Plan outcomes, not actions

If the work breakdown structure designer attempts to capture any action-oriented details in the WBS, the designer will likely include either too many actions or too few actions. Too many actions will exceed 100% of the parent's scope and too few will fall short of 100% of the parent's scope. The best way to adhere to the 100% rule is to define WBS elements in terms of outcomes or results, not actions. This also ensures that the WBS is not overly prescriptive of methods, allowing for greater ingenuity and creative thinking on the part of the project participants. For new product development projects, the most common technique to ensure an outcome-oriented WBS is to use a product breakdown structure. Feature-driven software projects may use a similar technique which is to employ a feature breakdown structure. When a project provides professional services, a common technique is to capture all planned deliverables to create a deliverable-oriented WBS. [16] Work breakdown structures that subdivide work by project phases (e.g. preliminary design phase, critical design phase) must ensure that phases are clearly separated by a deliverable also used in defining entry and exit criteria (e.g. an approved preliminary or critical design review).

Level of detail

One must decide when to stop dividing work into smaller elements. For most projects a hierarchy of two to four levels will suffice. [17] This will assist in determining the duration of activities necessary to produce a deliverable defined by the WBS. There are several heuristics or "rules of thumb" used when determining the appropriate duration of an activity or group of activities necessary to produce a specific deliverable defined by the WBS.

A work package at the activity level is a task that:

Coding scheme

It is common for work breakdown structure elements to be numbered sequentially to reveal the hierarchical structure. The purpose for the numbering is to provide a consistent approach to identifying and managing the WBS across like systems regardless of vendor or service. [18] For example, 1.1.2 Propulsion (in the example below) identifies this item as a Level 3 WBS element, since there are three numbers separated by two decimal points. A coding scheme also helps WBS elements to be recognized in any written context and allows for mapping to the WBS Dictionary. [19]

A practical example of the WBS coding scheme is [20]

1.0 Aircraft System

1.1 Air Vehicle
1.1.1 Airframe Airframe Integration, Assembly, Test and Checkout Fuselage Wing Empennage Nacelle Other Airframe Components 1..n (Specify)
1.1.2 Propulsion
1.1.3 Vehicle Subsystems
1.1.4 Avionics
1.2 System Engineering
1.3 Program Management
1.4 System Test and Evaluation
1.5 Training
1.6 Data
1.7 Peculiar Support Equipment
1.8 Common Support Equipment
1.9 Operational/Site Activation
1.10 Industrial Facilities
1.11 Initial Spares and Repair Parts

Terminal element

The lowest element in a tree structure, a terminal element is one that is not further subdivided. In a Work Breakdown Structure such elements (activity or deliverable), also known as work packages, are the items that are estimated in terms of resource requirements, budget and duration; linked by dependencies; and scheduled. At the juncture of the WBS element and organization unit, control accounts and work packages are established and performance is planned, measured, recorded and controlled. [21] A WBS can be expressed down to any level of interest. Three levels are the minimum recommended, with additional levels for and only for items of high cost or high risk, [22] and two levels of detail at cases such as systems engineering or program management, [23] with the standard showing examples of WBS with varying depth such as software development at points going to 5 levels [24] or fire-control system to 7 levels. [25]

Consistent to norms

The higher WBS structure should be consistent to whatever norms or template mandates exist within the organization or domain. For example, shipbuilding for the U.S. Navy must respect that the nautical terms and their hierarchy structure put into MIL-STD [26] are embedded in Naval Architecture [27] and that matching Navy offices and procedures have been built to match this naval architecture structure, so any significant change of WBS element numbering or naming in the hierarchy would be unacceptable.


The WBS construction technique employing the 100% rule during WBS construction WbsConstruction.png
The WBS construction technique employing the 100% rule during WBS construction

The adjacent figure shows a work breakdown structure construction technique that demonstrates the 100% rule and the "progressive elaboration" technique. At WBS Level 1 it shows 100 units of work as the total scope of a project to design and build a custom bicycle. At WBS Level 2, the 100 units are divided into seven elements. The number of units allocated to each element of work can be based on effort or cost; it is not an estimate of task duration.

The three largest elements of WBS Level 2 are further subdivided at Level 3. The two largest elements at Level 3 each represent only 17% of the total scope of the project. These larger elements could be further subdivided using the progressive elaboration technique described above.

WBS design can be supported by software (e.g. a spreadsheet) to allow automatic rolling up of point values. Estimates of effort or cost can be developed through discussions among project team members. This collaborative technique builds greater insight into scope definitions, underlying assumptions, and consensus regarding the level of granularity required to manage the projects.

See also

Related Research Articles

Earned value management (EVM), earned value project management, or earned value performance management (EVPM) is a project management technique for measuring project performance and progress in an objective manner.

Project management is the process of leading the work of a team to achieve goals and meet success criteria at a specified time. The primary challenge of project management is to achieve all of the project goals within the given constraints. This information is usually described in project documentation, created at the beginning of the development process. The primary constraints are scope, time, quality and budget. The secondary challenge is to optimize the allocation of necessary inputs and apply them to meet pre-defined objectives.

Configuration management process for maintaining consistency of a product attributes with its design

Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. The CM process is widely used by military engineering organizations to manage changes throughout the system lifecycle of complex systems, such as weapon systems, military vehicles, and information systems. Outside the military, the CM process is also used with IT service management as defined by ITIL, and with other domain models in the civil engineering and other industrial engineering segments such as roads, bridges, canals, dams, and buildings.

Project management software (PMS) has the capacity to help plan, organize, and manage resource tools and develop resource estimates. Depending on the sophistication of the software, it can manage estimation and planning, scheduling, cost control and budget management, resource allocation, collaboration software, communication, decision-making, quality management, time management and documentation or administration systems. Today, numerous PC and browser-based project management software and contract management software solutions exist, and are finding applications in almost every type of business.

Program evaluation and review technique statistical tool, used in project management

The program (or project) evaluation and review technique (PERT) is a statistical tool used in project management, which was designed to analyze and represent the tasks involved in completing a given project.

Product breakdown structure Tool for analysing, documenting and communicating the outcomes of a project

In project management under the PRINCE2 methodology, a product breakdown structure (PBS) is a tool for analysing, documenting and communicating the outcomes of a project, and forms part of the product based planning technique.

In project management, a schedule is a listing of a project's milestones, activities, and deliverables, usually with intended start and finish dates. Those items are often estimated by other information included in the project schedule of resource allocation, budget, task duration, and linkages of dependencies and scheduled events. A schedule is commonly used in the project planning and project portfolio management parts of project management. Elements on a schedule may be closely related to the work breakdown structure (WBS) terminal elements, the Statement of work, or a Contract Data Requirements List.

Systems development life cycle Systems engineering term

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life-cycle, is a process for planning, creating, testing, and deploying an information system. The systems development life cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

A statement of work (SOW) is a document routinely employed in the field of project management. It is the narrative description of a project's work requirement. It defines project-specific activities, deliverables and timelines for a vendor providing services to the client. The SOW typically also includes detailed requirements and pricing, with standard regulatory and governance terms and conditions. It is often an important accompaniment to a master service agreement or request for proposal (RFP).

Department of Defense Architecture Framework

The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views. These views are artifacts for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal, graphical, probabilistic, or alternative conceptual means. The current release is DoDAF 2.02.

A United States defense standard, often called a military standard, "MIL-STD", "MIL-SPEC", or (informally) "MilSpecs", is used to help achieve standardization objectives by the U.S. Department of Defense.

Integrated logistic support (ILS) is a technology in the system engineering to lower a product life cycle cost and decrease demand for logistics by the maintenance system optimization to ease the product support. Although originally developed for military purposes, it is also widely used in commercial customer service organisations.

MIL-STD-810 United States military equipment standard

MIL-STD-810, Environmental Engineering Considerations and Laboratory Tests, is a United States Military Standard that emphasizes tailoring an equipment's environmental design and test limits to the conditions that it will experience throughout its service life, and establishing chamber test methods that replicate the effects of environments on the equipment rather than imitating the environments themselves. Although prepared specifically for military applications, the standard is often used for commercial products as well.

Integrated master plan important program management tool

In the United States Department of Defense, the Integrated Master Plan (IMP) and the Integrated Master Schedule (IMS) are important program management tools that provide significant assistance in the planning and scheduling of work efforts in large and complex materiel acquisitions. The IMP is an event-driven plan that documents the significant accomplishments necessary to complete the work and ties each accomplishment to a key program event. The IMP is expanded to a time-based IMS to produce a networked and multi-layered schedule showing all detailed tasks required to accomplish the work effort contained in the IMP. The IMS flows directly from the IMP and supplements it with additional levels of detail——both then form the foundations to implement an Earned Value Management System.

A glossary of terms relating to project management and consulting.

The following outline is provided as an overview of and topical guide to project management:

A United States data item description (DID) is a completed document defining the data deliverables required of a United States Department of Defense contractor. A DID specifically defines the data content, format, and intended use of the data with a primary objective of achieving standardization objectives by the U.S. Department of Defense. The content and format requirements for DIDs are defined within MIL-STD-963C, Data Item Descriptions (2014).

The Goals breakdown structure (GBS) is a hierarchical structure linking high-level objectives or goals to more detailed goals. The GBS was originally developed for project management, but applies to product development and the organization as a whole. The concept is based on the Work Breakdown Structure (WBS) popular in the project management discipline. Like the WBS, project goals exhibit a hierarchical structure. The highest-level defines the overall goal or mission for the project. The next level down sets the goals the organization intends to achieve from the project. These might include such items as profit, market share, etc. The next layer down defines the features the products must exhibit to achieve the organization's goals. The next layer down defines the specifications each product or component of the product must have to meet the products features.

A value breakdown structure (VBS) is a project management technique introduced by Stephen Devaux as part of the total project control (TPC) approach to project and program value analysis.


  1. Systems Engineering Fundamentals. Archived 2006-02-11 at the Wayback Machine Defense Acquisition University Press, 2001
  2. "Glossary of Defense Acquisition Acronyms and Terms: Contract Work Breakdown Structure (CWBS)". Defense Acquisition University. Retrieved 19 September 2017.
  3. Booz, Allen & Hamilton Earned Value Management Tutorial Module 2: Work Breakdown Structure, Office of Science, Tools & Resources for Project Management, Accessed 27. Dec 2011.
  4. 1 2 3 NASA (2001). NASA NPR 9501.2D. May 23, 2001.
  5. Electronic Industries Alliance Standard Systems Engineering Capability Model EIA-731.1
  6. Institute of Electrical and Electronics Engineers Standard for Application and Management of the Systems Engineering Process IEEE Std 1220-2005
  7. Fleming, Quentin W., Joel M. Koppelman "Earned Value Project Management" CROSSTALK: The Journal of Defense Software Engineering July 1998, p 20
  8. Haugan, Gregory T., Effective Work Breakdown Structures, pp7-8
  9. DOD and NASA Guide, PERT/COST System Design, June 1962
  10. Hamilton, R. L., Study of Methods for Evaluation of the PERT/Cost Management System , MITRE Corporation, June 1964
  11. MIL-STD-881, 1 November 1968
  12. MIL-STD-881D, Work Breakdown Structures for Defense Materiel Items , 9 April 2018
  13. Haugan, Gregory T., The Work Breakdown Structure in Government Contracting, Management Concepts, 2003 ISBN   978-1567261202
  14. Effective Work Breakdown Structures By Gregory T. Haugan, Published by Management Concepts, 2001, ISBN   1567261353, p.17
  15. Practice Standard for Work Breakdown Structures (Second Edition), published by the Project Management Institute, ISBN   1933890134, page 8
  16. Swiderski, Mark A., PMP, PMBOK-Work Breakdown Structures. Accessed 16. June 2013.
  17. Levy, Lacie, Your Quick Start Guide to Work Breakdown Structure. Accessed 21. November 2019.
  18. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶4.3
  19. Ashe, Kenneth, Work Breakdown Structure, Accessed 23. May 2016.
  20. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011 Appendix A, ¶A.3
  21. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶3.1.4
  22. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶1.4.1
  23. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶
  24. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶Fig.3-6
  25. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶Fig.3-1
  26. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶Appendix E
  27. Gilmer, Thomas (1982-08-04). Introduction to Naval Architecture. pp. pg98. ISBN   9780870213182.

Further reading