What is a Work Breakdown Structure?

Breaking work into smaller tasks is a common productivity technique used to make
the work more manageable and approachable. For projects, the Work Breakdown
Structure (WBS) is the tool that utilizes this technique and is one of the most
important project management documents. It singlehandedly integrates scope, cost
and schedule baselines ensuring that project plans are in alignment.

The Project Management Institute (PMI) Project Management Book of Knowledge

(PMBOK) defines the Work Breakdown Structure as a “deliverable oriented
hierarchical decomposition of the work to be executed by the project team.” There
are two types of WBS: 1) Deliverable-Based and 2) Phase-Based. The most common
and preferred approach is the Deliverable-Based approach. The main difference
between the two approaches are the Elementsidentified in the first Level of the WBS.

Deliverable-Based Work Breakdown Structure

A Deliverable-Based Work Breakdown Structure clearly demonstrates the relationship
between the project deliverables (i.e., products, services or results) and the scope (i.e.,
work to be executed). Figure 1 is an example of a Deliverable-Based WBS for building
a house. Figure 2 is an example of a Phase-Based WBS for the same project.

FIGURE 1 – DELIVERABLE BASED WORK BREAKDOWN STRUCTURE

In Figure 1, the Level 1 Elements are summary deliverable descriptions. The Level 2
Elements in each Leg of the WBS are all the unique deliverables required to create
the respective Level 1 deliverable.

Phase-Based Work Breakdown Structure

In Figure 2, a Phase-Based WBS, the Level 1 has five Elements. Each of these Elements
are typical phases of a project. The Level 2 Elements are the unique deliverables in
each phase. Regardless of the type of WBS, the lower Level Elements are all
deliverables. Notice that Elements in different Legs have the same name. A Phase-
Based WBS requires work associated with multiple elements be divided into the work
unique to each Level 1 Element. A WBS Dictionary is created to describe the work in
each Element.

FIGURE 2 - PHASE BASED WORK BREAKDOWN STRUCTURE

A good WBS is simply one that makes the project more manageable. Every project is
different; every project manager is different and every WBS is different. So, the right
WBS is the one that best answers the question, “What structure makes the project
more manageable?”.

How to Make a Work Breakdown Structure

A good Work Breakdown Structure is created using an iterative process by following
these steps and meeting these guidelines:

1. GATHER CRITICAL DOCUMENTS

a. Gather critical project documents.
b. Identify content containing project deliverables, such as the Project
Charter, Scope Statement and Project Management Plan (PMP)
subsidiary plans.
2. IDENTIFY KEY TEAM MEMBERS
a. Identify the appropriate project team members.
b. Analyze the documents and identify the deliverables.
3. DEFINE LEVEL 1 ELEMENTS
a. Define the Level 1 Elements. Level 1 Elements are summary deliverable
descriptions that must capture 100% of the project scope.
b. Verify 100% of scope is captured. This requirement is commonly
referred to as the 100% Rule.
4. DECOMPOSE (BREAKDOWN) ELEMENTS
a. Begin the process of breaking the Level 1 deliverables into unique
lower Level deliverables. This “breaking down” technique is called
Decomposition.
b. Continue breaking down the work until the work covered in each
Element is managed by a single individual or organization. Ensure that
all Elements are mutually exclusive.
c. Ask the question, would any additional decomposition make the
project more manageable? If the answer is “no”, the WBS is done.
5. CREATE WBS DICTIONARY
a. Define the content of the WBS Dictionary. The WBS Dictionary is a
narrative description of the work covered in each Element in the WBS.
The lowest Level Elements in the WBS are called Work Packages.
b. Create the WBS Dictionary descriptions at the Work Package Level with
detail enough to ensure that 100% of the project scope is covered. The
descriptions should include information such as, boundaries,
milestones, risks, owner, costs, etc.
6. CREATE GANTT CHART SCHEDULE
a. Decompose the Work Packages to activities as appropriate.
 b. Export or enter the Work Breakdown Structure into a Gantt chart for
further scheduling and project tracking.

Caution: It is possible to break the work down too much. How much is too much?
Since cost and schedule data collection, analysis and reporting are connected to the
WBS, a very detailed WBS could require a significant amount of unnecessary effort to
manage.

There are many WBS software tools available. Some of them are based on mind
mapping and others are drawing tools. You can read about these tools in this WBS
software review.

Here is an example of how to make a WBS with MindView:

How to Use a Work Breakdown Structure

The Work Breakdown Structure is used for many different things. Initially, it serves as
a planning tool to help the project team plan, define and organize scope with
deliverables. The WBS is also used as the primary source of schedule and cost
estimate activities. But, its biggest contributions to a project are is use as a
description all of the work and as a monitoring and controlling tool.

WORK PACKAGES
Figure 3 shows the House Project Work Breakdown Structure expanded to Level 1, 2,
and 3 Elements. The lowest Levels of each Leg and Branch of the WBS are
called Work Packages. Work Packages cover information related to the deliverable,
such as owner, milestones, durations, resources, risks, etc. This information is
described in the WBS Dictionary.

PLANNING PACKAGES
There is another type of Work Package called a Planning Package. When the project
management plan is approved, scope is known, but not necessarily all of the details.
In order to apply the 100% Rule and capture all of the scope, Planning Packages are
created. It is understood that as details are defined, the Planning Packages eventually
evolve to Work Packages. In the House Project, the project manager knows that the
house will have fixtures, but at the time construction begins, there is only a fixture
allowance and no fixtures identified. Once the fixtures are determined, the associated
Planning Package becomes a Work Package. This planning process is call Rolling
Wave Planning and is a from of Progressive Elaboration.

FIGURE 3 – WBS WORK PACKAGES AND CONTROL ACCOUNTS

CONTROL ACCOUNTS
The other application of the WBS is as a monitoring and controlling tool. This is
accomplished by defining Control Accounts. Control Accounts are WBS Elements at
which the project plans to monitor and report performance. The Control Accounts
can be any Element in the WBS. In the House Project, the project manager decides
that the project risks associated with using subcontractors can be better managed if
the project reports performance for each subcontractor. To monitor their
performance, Elements 3.1, 3.2 and 3.3 have been identified as Control Accounts.
However, the remaining work in Elements 1.0 and 2.0 will be performed by company
resources with less risk and the project does not feel like monitoring and controlling
is needed at lower Levels. To assist with the monitoring and reporting, project
management information tools are used to collect, analyze and report information at
any Element within the WBS.

WORK BREAKDOWN STRUCTURE (WBS)

PURPOSE, PROCESS AND PITFALLS
~ By Micah Mathis

In this article we are going to look at what many project managers and
project management professionals refer to as the "foundation" of the
project, or at least the foundation of project planning. The Work
Breakdown Structure (WBS) is defined by A Guide to the Project
Management Body of Knowledge 3rd Edition (PMBOK Guide) as:
A deliverable-oriented hierarchical decomposition of the work to be executed by the
project team to accomplish the project objectives and create the required deliverables.

Project Management Institute (PMI)

Wow! That is a lot of buzz words and jargon, but do not worry. It is not
nearly as daunting as it sounds. Creating a quality WBS will require a
substantial amount of energy, time, and people, but in the end is not rocket
science. However, before we get too deep into how to actually create a WBS
let's first look at its purpose.

Purpose
Why do we need to create a WBS for our projects? What purpose does it
serve? Why should I waste my time writing on post-it notes and drawing
charts when I could be getting my team started on the actual work of the
project? Now, I know everyone reading this is a great project manager or
team member, so I am sure none of you have ever said comments such as
these, but I am sure you have heard them from those "other" project
managers who will remain nameless.

So to answer these questions, let's take a look at what purpose the WBS
serves to our project and our project team. There are three reasons to use a
WBS in your projects. The first is that is helps more accurately and
specifically define and organise the scope of the total project. The most
common way this is done is by using a hierarchical tree structure. Each level
of this structure breaks the project deliverables or objectives down to more
specific and measurable chunks. The second reason for using a WBS in your
projects is to help with assigning responsibilities, resource allocation,
monitoring the project, and controlling the project. The WBS makes the
deliverables more precise and concrete so that the project team knows exactly
what has to be accomplished within each deliverable. This also allows for
better estimating of cost, risk, and time because you can work from the
smaller tasks back up to the level of the entire project. Finally, it allows you
double check all the deliverables' specifics with the stakeholders and make
sure there is nothing missing or overlapping.

Process
Now that we have agreed that creating a WBS will be help to our project's
efficiency and effectiveness, how do we go about it? First, let's look at what
all we need to get started. There are several inputs you will need to get you
off on the right foot:

 The Project Scope Statement

 The Project Scope Management Plan
 Organisational Process Assets
  Approved Change Requests - (PMBOK Guide)

These inputs should give you all the information you and your team needs to
create your WBS. Along with these inputs, you will use certain tools as well:

 Work Breakdown Structure Templates

 Decomposition - (PMBOK Guide)

Finally, using these inputs and tools you will create the following outputs:

 Work Breakdown Structure

 WBS Dictionary
 Scope Baseline
 Project Scope Statement (updates)
 Project Scope Management Plan (updates)
 Requested Changes - (PMBOK Guide)

The first step to creating your WBS is to get all your team, and possibly key
stakeholders, together in one room. Although your team is not listed as an
input or tool in the above sections, they are probably your most vital asset to
this process. Your team possesses all the expertise, experience, and creative
thinking that will be needed to get down to the specifics of each deliverable.
Next, we have to get the first two levels setup. The first level is the project
title, and the second level is made up of all the deliverables for the project. At
this stage it is important to function under the 100% Rule. This rule basically
states that the WBS (specifically the first two levels) includes 100% of all the
work defined in the project scope statement and management plan. Also, it
must capture 100% of all the deliverables for the project including internal,
external, and interim. In reality the WBS usually only captures between 90-
95%, and 100% is our goal.

Once we have gotten the first two levels set, it is time to launch into our
decomposition. Decomposition is the act of breaking down deliverables in to
successively smaller chunks of work to be completed in order to achieve a
level of work that can be both realistically managed by the project manager
and completed within a given time frame by one or more team members.
This level of breakdown and detail is called the work package. Work
packages are the lowest level of the WBS and are pieces of work that are
specifically assigned to one person or one team of people to be completed.
This is also the level at which the project manager has to monitor all project
work. Now the million dollar question is how specific and small does a
chunk of work need to be to still be considered a work package? Well
PMBOK does not seem to give a definitive answer on that. Most project
managers concur that this varies by project, but can usually be measured
using the 8/80 Rule. The 8/80 Rule says that no work package should be less
than 8 hours or greater than 80 hours. Notice we said that the work package
is the lowest level of the WBS. Activities and tasks are not included in the
WBS. They will be planned from the work packages once they are assigned.

Now you are ready to start your team on the work of decomposition, but do
not get too far ahead of yourself quite yet. As grandpa always said There is
no reason to reinvent the wheel. Occasionally, you will run into a project that
is a "first of its kind," but that is not usually the case. Most of the time, you,
your team, or your organisation has done a project like this one in the past.
That means that there should be a WBS from the previous project that you
can use as a template. This will save you a lot time and effort. Even if you
have not done a project like this one before, most Project Management
Offices (PMOs) have basic WBS templates that can get you started. Another
great technique to make your life easier is the Post-It Note Technique. I know
it sounds a little cheesy, but it actually works very well. In this technique you
simply write each deliverable on a post-it note and stick them at the top of a
wall. Then you and your team start to break down each deliverable into
components and write each component on its own post-it note. This way, as
you place them on the wall and start to create your tree structure, everyone
can easily see what has been accomplished and where you are headed. Also
this technique allows for easy movement of components around within the
WBS.

Now the conference room wall is covered in post-it notes and Sally is
frantically wanting to write everything down before they start to fall, but wait
one more step before you put it into an official (or semi-official) document.
You can use your newly created WBS to look for missing or overlapping
pieces of each deliverable. This will help eliminate change requests and
double work down the road. Once that is completed, put your WBS on paper
and log it into your project.

Many projects will also find it necessary to create a WBS Dictionary to

accompany their WBS. The WBS Dictionary is simply a document that
describes each component in the WBS. This helps clarify any specifics later
on when team members completing the work or stakeholders viewing the
deliverables have questions. Also, when creating the WBS for very large,
lengthy, or complex projects, all the deliverables' specifics might not be
known up front and, therefore, it is difficult to create a full WBS. In cases
such as these many people use what is called Rolling Wave Planning. This is
when you plan down to the level of detail currently known and go back to
plan deeper once more information is acquired. Usually rolling wave
planning needs to stay as least two to three months ahead of the actual work
being done, but of course this varies slightly by industry.

Pitfalls
Lastly, let's look at five common pitfalls to creating a WBS. If you can keep
these few possible issues in mind when you are creating your WBS, you and
your team will be much more successful at creating a useful and accurate
Work Breakdown Structure:

1. Level of Work Package Detail

When deciding how specific and detailed to make your work packages, you
must be careful to not get too detailed. This will lead to the project manager
to have to micromanage the project and eventually slow down project
progress. On the other hand, work packages whose details are too broad or
large become impossible for the project manager to manage as a whole.

2. Deliverables Not Activities or Tasks

The WBS should contain a list of broken down deliverables. In other words,
what the customer/stakeholder will get when the project is complete. It is
NOT a list of specific activities and tasks used to accomplish the
deliverables. How the work is completed (tasks and activities) can vary and
change throughout the project, but deliverables cannot without a change
request, so you do not want to list activities and tasks in the WBS.

3. WBS Is Not a Plan or Schedule

The WBS cannot be used as a replacement for the project plan or schedule. A
WBS is not required to be created in any type of order or sequence. It is
simply a visual breakdown of deliverables.
4. WBS Updates Require Change Control
The WBS is a formal project document, and any changes to it require the use
of the project change control process. Any changes to the WBS change the
deliverables and, therefore, the scope of the project. This is an important
point to help control scope creep.

5. WBS Is Not an Organisational Hierarchy

The WBS and Organisational Hierarchy chart are never the same thing.
Although often similar in appearance, these two documents are very
different. The Organisational Hierarchy shows things like chain of command
and lines of communication, but the WBS is restricted simply to a project and
shows only the deliverables and scope of that project.