Work breakdown structure

A work breakdown structure or "WBS" is a tree structure, that permits summing of subordinate costs for tasks, materials, etc., into their successively higher level “parent” tasks, materials, etc. It is a fundamental tool commonly used in project management and systems engineering.

Overview

A work breakdown structure is a tree-like structure that 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. [Electronic Industries Alliance Standard "Systems Engineering Capability Model" EIA-731.1 ] This technique (sometimes called a System Breakdown Structure [Institute of Electrical and Electronics Engineers "Standard for Application and Management of the Systems Engineering Process" IEEE Std 1220-2005] ) is used to define and organize the total scope of a project.

A well-designed WBS forms a product-oriented family tree composed of hardware, software, services, data, andfacilities. This means that 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 requirements cross reference matrix mapping functional requirements to high level or low level design documents.

History

The concept of the WBS developed with the Program Evaluation and Review Technique (PERT) in 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. [http://www.stsc.hill.af.mil/crosstalk/1998/07/value.asp] While the term "work breakdown structure" was not used, this first implementation of PERT did organize the tasks into product oriented categories. [Haugan, Gregory T., Effective Work Breakdown Structures, pp7-8]

By June of 1962, DoD, NASA and the aerospace industry published a guidance document for the PERT Cost system which included an extensive description of the WBS approach. [DOD and NASA Guide, PERT/COST System Design, June 1962] This guide was endorsed by the Secretary of Defense for adoption by all services. [Hamilton, R. L., "Study of Methods for Evaluation of the PERT/Cost Management System", MITRE Corp., June 1964 http://handle.dtic.mil/100.2/AD603425] In 1968, the DoD issued "Work Breakdown Structures for Defense Materiel Items" (MIL-STD-881), a military standard mandating the use of work breakdown structures across the DoD. [MIL-STD-881, 1 November 1968] This standard established top-level templates for common defense materiel items along with associated descriptions (WBS dictionary) for their elements.

The document has been revised several times, most recently in 2005. The current version of this guidance can be found in "Work Breakdown Structures for Defense Materiel Items" (MIL-HDBK-881A). [MIL-HDBK-881A, http://assist.daps.dla.mil/quicksearch/basic_profile.cfm?ident_number=202687]

It includes guidance for preparing work breakdown structures, templates for the top three levels of typical systems (Appendices A through H), and a set of "common elements" that are applicable to all major systems and subsystems (Appendix I)

Defense Material Item categories from MIL-HDBK-881A:
* Aircraft Systems
* Electronic/Automated Software Systems
* Missile Systems
* Ordnance Systems
* Sea Systems
* Space Systems
* Surface Vehicle Systems
* Unmanned Air Vehicle Systems
* Common Elements

The common Elements identified in MIL-HDBK-881A, Appendix I are: Integration, assembly, test, and checkout; Systems engineering; Program management; Training; Data; System test and evaluation; Peculiar support equipment; Common support equipment; Operational and site activation; Industrial facilities; and Initial spares and repair parts

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 handbook, but is intended for more general application. [Haugan, Gregory T., The Work Breakdown Structure in Government Contracting, Management Concepts, 2003 ISBN 978-1567261202]

WBS design principles

The 100% Rule

One of the most important WBS design principles is called the 100% Rule. [Haugan, Gregory T., Effective Work Breakdown Structures, p.17] The "Practice Standard for Work Breakdown Structures (Second Edition)", published by the Project Management Institute (PMI) defines the 100% Rule 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." (p. 8)

Planned outcomes, not planned actions

If the WBS designer attempts to capture any action-oriented details in the WBS, he/she 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. 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. 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 Design Review document, or an approved Critical Design Review document).

Mutually exclusive elements

In addition to the 100% Rule, it is important that there is no overlap in scope definition between two elements of a WBS. This ambiguity could result in duplicated work or miscommunications about responsibility and authority. Likewise, such overlap is likely to 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, etc.

Level of detail

A question to be answered in the design of any WBS is when to stop dividing work into smaller elements.

A common way of deciding the detailing level is the time between status reports/meetings. If the team reports bi-weekly the largest work package should be 80 hours. Then at reporting time a package is either not started, in progress, finished or late. This way makes it easy catching delays.

A work package is a piece that:
* can be realistically and confidently estimated;
* cannot be logically subdivided further;
* can be completed quickly;
* has a meaningful conclusion and is deliverable;
* can be completed without interruption (without the need for more information); and
* will be outsourced or contracted out.

There is a general ‘8/80 Rule’ that states that all and any Work Package should be more than 8 and less than 80 hours in duration.

Decomposition Considerations (Breadth vs. Depth)

A WBS will tend to be most useful for project management when its breadth and depth are thoughtfully balanced. A common pitfall is to inadequately group related elements, resulting in one or more nodes of the WBS becoming "too wide" to support effective management. This can make it difficult for management to find risk-relevant roll-up points within the WBS, requiring manual subtotaling of nodes or eventual restructuring of the WBS in order to make useful cost data more readily accessible. While no concrete standard exists for optimal depth or breadth, a common rule-of-thumb is to avoid having more than 7 immediate sub-elements below any given node of the WBS. This rule-of-thumb appears to be derived from psychological studies indicating that an average human brain is only capable of processing about 7 to 9 considerations simultaneously. The relevance of that psychological consideration to any particular WBS elaboration is left to the discretion of the WBS designer. At a minimum, the existence of more than 7 sister-nodes at any point in the WBS should prompt the designer to carefully consider whether those sub-elements might not best be expressed (and tracked) in more logical sub-groupings.

WBS coding scheme

It is common for WBS elements to be numbered sequentially to reveal the hierarchical structure. For example 1.3.2 Rear Wheel identifies this item as a Level 3 WBS element, since there are three numbers separated by a decimal point. A coding scheme also helps WBS elements to be recognized in any written context.

Terminal element

A terminal element is the lowest element (activity or deliverable) in a work breakdown structure; it is not further subdivided.

Terminal elements are the items that are estimated in terms of resource requirements, budget and duration, linked by dependencies and scheduled.

A terminal element is sometimes called a work package, although the two terms are not synonymous.

WBS construction example

Figure 1 shows a WBS construction technique that demonstrates the 100% Rule quantitatively. At the beginning of the design process, the project manager has assigned 100 points to the total scope of this project, which is designing and building a custom bicycle. At WBS Level 2, the 100 total points are subdivided into seven comprehensive elements. The number of points allocated to each is a judgment based on the relative effort involved; it is NOT an estimate of duration. The three largest elements of WBS Level 2 are further subdivided at Level 3, and so forth. The largest terminal elements at Level 3 represent only 17% of the total scope of work. These larger elements may be further subdivided using the "progressive elaboration" technique described above. In this example, the WBS coding scheme includes a trailing "underscore" character ("_") to identify terminal elements. This is a useful coding scheme because planned activities (e.g. "Install inner tube and tire") will be assigned to terminal elements instead of parent elements. Incidentally, this quantitative method is related to the Earned Value Management technique.

It is recommended that WBS design be initiated with interactive software (i.e. a spreadsheet) that allows automatic rolling up of point values. Another recommended practice is to discuss the point estimations with 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 project.

Common pitfalls and misconceptions

A WBS is not an exhaustive list of work. It is instead a comprehensive classification of project scope.

A WBS is not a project plan or a project schedule and it is not a chronological listing. It is considered poor practice to construct a project schedule (e.g. using project management software) before designing a proper WBS. This would be similar to scheduling the activities of home construction before completing the house design. Without concentrating on planned outcomes, it is very difficult to follow the 100% Rule at all levels of the WBS hierarchy.

A WBS is not an organizational hierarchy. Some practitioners make the mistake of creating a WBS that shadows the organizational chart. While it is common for responsibility to be "assigned" to organizational elements, a WBS that shadows the organizational structure is not descriptive of the project scope and is not outcome-oriented. See also: responsibility assignment matrix (also called a "Staffing Matrix").

WBS updates, other than progressive elaboration of details, require formal change control. This is another reason why a WBS should be outcome-oriented and not be prescriptive of methods. Methods can, and do, change frequently, but changes in planned outcomes require a higher degree of formality. If outcomes and actions are blended, change control may be too rigid for actions and too informal for outcomes.

A WBS is not a logic model. Nor is it a strategy map.

ee also

* list of project management topics
* project planning
* product breakdown structure
* project management software

References

Further reading

* Carl L. Pritchard. Nuts and Bolts Series 1: How to Build a Work Breakdown Structure. ISBN 1-890367-12-5
* Project Management Institute. Project Management Institute Practice Standard for Work Breakdown Structures, Second Edition (2006). ISBN 1-933890-13-4 (Note: The Second Edition is an extensive re-write of the Practice Standard.)
* Gregory T. Haugan. Effective Work Breakdown Structures (The Project Management Essential Library Series). ISBN 1-56726-135-3
* Dennis P. Miller, PMP, "Building Your Project Work Breakdown Structure -- Visualizing Your Objectives, Deliverables, Activities and Schedule". ISBN-10: 1-42006969-1 (Note: This new book is essentially a facilitator's guide for planning a project based on the WBS.)