Work Breakdown Structure (WBS)

Introduction to the WBS

A Work Breakdown Structure is a results-oriented family tree that captures all the work of a project in an
organized way. It is often portrayed graphically as a hierarchical tree, however, it can also be a tabular list
of "element" categories and tasks or the indented task list that appears in your Gantt chart schedule. As a
very simple example, Figure 1 shows a WBS for a hypothetical banquet.

Figure 1

Large, complex projects are organized and comprehended by breaking them into progressively smaller
pieces until they are a collection of defined "work packages" that may include a number of tasks. A
$1,000,000,000 project is simply a lot of $50,000 projects joined together. The Work Breakdown Structure
(WBS) is used to provide the framework for organizing and managing the work.

In planning a project, it is normal to find oneself momentarily overwhelmed and confused, when one
begins to grasp the details and scope of even a modest size project. This results from one person trying to
understand the details of work that will be performed by a number of people over a period of time. The
way to get beyond being overwhelmed and confused is to to break the project into pieces, organize the
pieces in a logical way using a WBS, and then get help from the rest of your project team.
The psychologists say our brains can normally comprehend around 7-9 items simultaneously. A project
with thousands or even dozens of tasks goes way over our ability to grasp all at once. The solution is to
divide and conquer. The WBS helps break thousands of tasks into chunks that we can understand and
assimilate. Preparing and understanding a WBS for your project is a big step towards managing and
mastering its inherent complexity.
The WBS is commonly used at the beginning of a project for defining project scope, organizing Gantt
schedules and estimating costs. It lives on, throughout the project, in the project schedule and often is the
main path for reporting project costs. On larger projects, the WBS may be used throughout the project to
identify and track work packages, to organize data for Earned Value Management (EVM) reporting, for
tracking deliverables, etc.

History of the WBS

The WBS was initially developed by the U.S. defense establishment, and it is described in Military
Standard (MIL-STD) 881B (25 Mar 93) as follows: "A work breakdown structure is a product-oriented
family tree composed of hardware, software, services, data and facilities .... [it] displays and defines the
product(s) to be developed and/or produced and relates the elements of work to be accomplished to each
other and to the end product(s)."
It requires some mental discipline to develop a product-oriented or deliverable-oriented grouping of project
elements adding up to comprise the entire project scope. Intuitively, we tend to start out with a taskoriented approach. This is OK for very small projects where extensive project management controls will
not be used. The task-oriented approach is easy to understand, because we can easily think of projects as
collection of tasks. A task-oriented WBS can be developed by beginning with a simple "to-do" list and then
clustering the items in a logical way. The logical theme could be project phases, functional areas, or major
end-products.
If your organization will be collecting historical data to form a cost database, you should try to select a
standard approach consistent with the organizations long term data collection needs.
A sample WBS is shown in the figure below:

WBS Format for System Development Projects

Additional level 2 elements not shown here might include development environment support, logistics and
training, and installation and startup. See a skeleton sample WBS for a software and hardware system
development project at end of this document.
A WBS for a large project will have multiple levels of detail, and the lowest WBS element will be linked to
functional area cost accounts that are made up of individual work packages. Whether you need three levels
or seven, work packages should add up through each WBS level to form the project total.

Product or Process Oriented?

The WBS was initially defined as a product oriented family tree, however subsequent definitions have
introduced more flexibility -- so a WBS can also be deliverable or process oriented. Your WBS can be built
on nouns or verbs. If the results of your project are primarily verbs, then a verb based or process based
WBS may make more sense. If your WBS is to be product or deliverable oriented, then you can start by
thinking of the WBS as a parts list for the ultimate end-items of your project. See below for a simple
illustration of a product or process based WBS orientation. These differences are not shown to tell you
what is the right way for your project, but just to familiarize you with the distinctions, so you can think
about them and choose what's best for your project.

WBS Numbering
WBS elements are usually numbered, and the numbering system may be arranged any way you choose.
The conventional numbering system is shown in the figure. The shaded box shown in the above slide could
be numbered 1.2.2.3, which would tell you it was in the second box in level 2, the second box in level 3,
and the third box in level 4.

WBS Dictionary
If a WBS is extensive and if the category content is not obvious to the project team members, it may be
useful to write a WBS dictionary. The WBS dictionary describes what is in each WBS element, and it may
also say what is not in an element, if that is unclear. Here is a sample of a WBS dictionary description:
WBS Element 1.5.4.5. - Systems Integration Test Equipment Planning - This element includes the effort to
identify requirements and specify types and quantities of test equipment needed to support the System
Integration and Test process. It does not include the design or procurement of such equipment, which is
covered in Element 1.5.4.6.

Mapping WBS for Cost Management

In a product-oriented WBS, functional categories of work may form "cost accounts" within a WBS
element. Cost account managers are responsible for a functional areas contribution to a WBS element.
Cost accounts from several departments or functions may combine into one WBS element.
Internal department planning for a cost account will be made up of individual work packages. A work
package will typically have its own budget and schedule. Work packages should be small enough to be
executed by individuals or small groups in a single department, and they should be of relatively short
schedule duration. A small project might define a maximum work package size as two weeks of effort.
Larger projects will assemble larger work packages that can be appropriately managed and controlled.
The project manager will have to decide to what degree employment of various details of WBS
implementation will benefit the efficient management of the project. On a very small project, a formal
WBS may serve no useful purpose, but it can become valuable if project size or complexity start to
increase.
As an organizations project management environment matures, or as larger size and complexity are
encountered, application of the WBS concept can evolve from an ad hoc list of tasks, to time-phased
activity lists, task lists clustered by project deliverables and services, or an end-product focused WBS fed
by cost accounts and work packages.

If you are using MS-Project or a similar project management software application, you may encounter the
WBS as a vertical list with indents to show structure. This will be compatible with the Gantt View data
entry screens. While some software packages provide a separate WBS view, you could prepare your WBS
in the vertical format using a word processor, and then cut and paste your WBS into your project
management software package.

Program and Contract WBSs

A top-level WBS for a large program is sometimes called a Program WBS (PWBS) or Program Summary
WBS (PSWBS). If a project involves several organizational participants or contractors, guidance for one
contractor can be provided in a Contract WBS (CWBS). The project manager may provide a high-level
CWBS for each developer, perhaps to level 2 or level 3. The developer will then fill in the details of lower
WBS levels to reflect the work to be accomplished and the data flow in that organization.

Organizational Standards
Your organization may want to decide on a standard WBS format or group of formats, use these across all
projects, and communicate definitions widely so everyone will be speaking the same language. This can
save re-learning project lessons and can lay the groundwork for successful data gathering to aid future cost
estimates.

WBS Implementation
When you set up a project WBS, think about how you will be using it later in the project. Try to consider
how you will organize the WBS, schedule format, manager assignments, and charge numbers, in your early
project planning. These days, the WBS in smaller projects ends up automatically being the indent structure
in your Gantt schedule, so pay attention to those indents, and make sure that is the WBS you want for
rolling up costs in your project, especially if you will be using EVM. It will be helpful if you can map the
charge numbers, managers, and task groups to each other. This will help you track costs and progress for
each manager. If your project schedule will on MS-Project, you may want to insert "text" columns into your
schedule (Gantt View) for project charge numbers and manager names.
If your project charge numbers cannot be linked to groups of tasks assigned to specific managers, you will
have no way to provide performance measurement feedback to managers.
Some project management environments have definite conventions for grouping items in a WBS. The best
method is to have a WBS that works for your particular project environment. The WBS should be designed
with consideration for its eventual uses. Your WBS design should try to achieve certain goals:

Be compatible with how the work will be done and how costs and schedules will be managed,
Give visibility to important or risky work efforts,

Allow mapping of requirements, plans, testing, and deliverables,

Foster clear ownership by managers and task leaders,

Provide data for performance measurement and historical databases, and

Make sense to the workers and accountants.

There are usually many ways to design a WBS for a particular project, and there are sometimes as many
views as people in the process. Experience teaches that everyone takes a slightly different slice of the
apple, so make sure WBS arguments seeking metaphysical certainty are quickly brought to closure. Simple
practicality combined with enlightened trial and error usually is the best approach.

Generating a WBS from Microsoft Project

There is a third-party add-on software application for MS-Project called WBS Chart Pro that will convert
your Gantt chart task list with indents into a standard WBS graphic in a few clicks. You can also use this
application to create a WBS and transfer it back MSP. I have found this software very valuable in
organizing project work into a WBS, reviewing the scope of proposed projects, and helping managers
visualize the WBS implicit in their MS-Project schedules.

PMI Practice Guide for WBS

The Project Management Institute (PMI) has a document, Project Management Institute Practice Standard
for Work Breakdown Structures, that provides examples of WBS formats commonly used in several
different project areas, construction, defense, etc. From the PMI Web site, upper right corner, click on
Publications & Information Resources, then on Bookstore. Key word search for Work Breakdown
Structure will bring up this standard and other references.

Copyright 1997, 2004 James R. Chapman, All rights reserved.

Document Version 2.01 last updated November 2, 2004

Work Breakdown Structure (WBS)

These two graphics illustrate approaching the WBS as a parts list or as a process list.

Last updated November 2, 2004

Work Breakdown Structure (WBS)

Sample Skeleton WBS for Software/Hardware System Development

Last updated November 2, 2004