CHAPTER 6: DEVELOPING THE WORK BREAKDOWN STRUCTURE

In this Chapter

 Clarify what a work breakdown structure (WBS) is and is not

 Understand why the WBS is considered the most important tool of the project manager

 Learn what makes an effective WBS

 Learn how to avoid the common mistakes when developing a WBS

 Understand why a WBS is essential for an agile project too

If you were to ask anyone off the street what they think of when they hear “project management,” you are
likely to hear “planning.” And if you further ask them what they mean by “planning,” you are likely to hear
“schedule” or “work plan.” Yes, even to the uninitiated, people know that project managers plan and develop
work schedules, if they do nothing else.

Yet, the process of understanding all the work that needs to be done and building a realistic project schedule
continues to be the Achilles’ heel of project management.

In this chapter, we begin our close review of the schedule development process by exploring the power and
the purpose of the work breakdown structure (WBS). By performing this step correctly, we will do a much
better job at the other detail project planning activities, such as identifying resources, identifying risks,
getting better estimates, building a realistic schedule, and developing an accurate project budget. In addition,
a solid WBS enables us to better manage stakeholder expectations and the critical success factors throughout
the project life cycle.

As part of this review, we clarify exactly what a WBS is (and is not); we examine why the WBS is crucial to our
other project management activities; we identify how to develop an effective WBS and how to avoid the
common miscues in this arena; and we discuss why these WBS development principles are still applicable for
an agile project.

What Exactly Is a WBS?

As I mentioned in Chapter 1, “Project Management Overview,” project management is not brain surgery and
does not require advanced logic and reasoning skills to achieve winning results (I’m a great example of this).
In most cases, the disciplines and terms used in project management are very common sense and obvious in
nature. A WBS is a classic case. As the terms defining the acronym indicate, a WBS is a logical breakdown
(decomposition) and representation (hierarchical structure) of the work required by the project.

A WBS can take one of two forms: graphical or outline. See Figures 6.1 and 6.2 for examples of each.
FIGURE 6.1

Partial graphical WBS for a software selection project.

Software selection branches into 1.0 planning, 2.0 define requirements, 3.0 develop vendor short list, 4.0
determine vendor finalists, 5.0 evaluate finalists, and 6.0 project management. 2.0 define requirements
branches into 2.1 develop technical requirements, 2.2 develop vendor requirements, 2.3 develop future state
business requirements, 2.4 prioritize requirements, 2.5 determine vendor knockout criteria, 2.6 determine
vendor long list, and 2.7 finalize requirements document. 3.0 develop vendor short list branches into 3.1
research long list vendors, 3.2 determine short list vendors, and 3.3 review vendor short list. 4.0 determine
vendor finalists branches into 4.1 develop request for proposal, 4.2 process r f p responses, 4.3 preliminary fit
analysis, 4.4 determine vendor demo list, and 4.5 schedule vendor demonstrations. 5.0 evaluate finalists
branches into 5.1 develop demo test scripts, 5.2 assess performance, and 5.3 develop final fit analysis.
FIGURE 6.2

Partial outline WBS for a software selection project.

The software selection process is listed as follows. 1 planning, 1.1 determine selection strategies, 1.2
determine the final schedule. 2 define requirements, 2.1 develop vendor requirements, 2.2 develop future
state business requirements, 2.4 prioritize requirements, 2.5 identify vendor knockout criteria, 2.6 determine
vendor long list, 2.7 finalize requirements document. 3 develop vendor shortlist, 3.1 research vendors on
long list, 3.2 Determine vendor shortlist, and 3.3 Review vendor shortlist. 4 develop vendor finalist list, 4.1
develop request for proposal (R F P). 4.2 process r f p responses, 4.3 develop preliminary fit analysis, 4.4
determine vendor demonstration list. 4.5 schedule demonstrations. 5 evaluate finalists, 5.1 develop demo
test scripts. 5.2 assess performance. 5.2.1 Assess package performance. 5.2.2 Assess vendor performance.
5.3 develop final fit analysis, 5.4 review final fit analysis, 5.5 make final recommendation. 6. Project
management.

Both types have their place in your toolbox. The graphical form is best for communicating the top three to
five levels of work activity to senior management or customer stakeholders. The outline form is best for
capturing the details needed for cost and schedule development.
Note

A WBS is a logical, hierarchical, and organized task list developed with the team.

A WBS shows the work and any interim deliverables that are required to produce the major project
deliverables identified in the project definition process. In most cases, the WBS reflects the components that
make up the final deliverables and the approach (methodology) used to develop, integrate, and validate
them. In short, the WBS is an organized task list.

By simply doing this, we create an organized picture that allows us to see—and more importantly, allows our
stakeholders to see—all the work required to accomplish the project objectives. You can begin to see the
power of the WBS in managing expectations.

Also, by doing this, we employ the primary secret weapon of managing large, complex projects, which is “You
don’t!” You break the work into chunks and manage many smaller components.

I’m not going to spend a great deal of time on explaining how to create a WBS and how to break down the
higher-level work of a project because I think most analytical people do this naturally, and the details of the
work decomposition depend on the specifics associated with your organization and industry. In fact, many
organizations leverage standard WBS templates to ensure any new project includes the recommended work
items.

Tip

Always clarify terms with your project team and project stakeholders in any communication.

For an official repository of project terms, the use of a project glossary document can be helpful.

However, what I will spend time on is making sure you are clear on terminology, making sure you understand
how this step fits into the overall schedule development process, and reviewing the best practices of WBS
development.
Isn’t WBS Just Another Name for the Project Schedule?

Many industries and organizations routinely use the following terms in an interchangeable fashion: WBS,
project plan, project schedule, and work plan. As you know by now, these terms do represent different
project management elements and should not be used interchangeably. However, as with all less-than-ideal
practices, there are reasons they develop. Understanding the reasons is always helpful and, in this case, can
provide additional insights as to why projects can get into a troubled state.

When you think about the process for developing a schedule (see Figure 6.3), determining the work (detail
tasks) that is required is the first step.

FIGURE 6.3

The role of the WBS in the development of the project schedule.

An arrow from project definition document points at develop W B S. Two arrows labeled W B S points at
determine resource needs and sequence the work respectively. An arrow from W B S, initial resource
requirements from determine resource needs points at estimate the work packages. An arrow labeled
network diagram from sequence the work points at develop schedule. An arrow labeled duration estimates
from estimate the work packages points at develop schedule. An arrow labeled resource requirements from
estimate the work packages points at acquire resources. An arrow from resources requirements, duration
estimates points at develop budget. An arrow labeled initial schedule from develop schedule points at
finalize schedule. An arrow labeled actual resources from acquire resources points at finalize schedule. An
arrow labeled cast estimates, initial budget from develop budget points at finalize budget. An arrow labeled
approved schedule from finalize schedule points at finalize budget. An arrow labeled approved schedule,
approved budget from finalize budget points at project plan.

After you have identified the work tasks, you can determine what resources are required for each task, how
much effort each task will take (process details discussed in Chapter 7, “Estimating the Work”), and what
logical dependencies exist between the tasks (details covered in Chapter 8, “Developing the Project
Schedule”). At this point, you can begin to construct the first of several iterations of a project schedule.

Sounds logical enough—so, where’s the problem?

In general, the problems lie with the use and application of project scheduling software such as Microsoft
(MS) Project. Here’s a common scenario:

 Joe Manager is told to build a work plan for the project.

 Joe goes to his desk and opens up MS Project and starts entering and organizing the tasks that need
to be performed.

 Joe enters estimated durations and start and end dates for some of the key or most visible tasks.

 Joe presents results to his supervisor for review.

Note

Avoid judging a current work practice or process or the people involved before you understand why it is done
this way or how it evolved to the current point.

This approach keeps you results-focused, improves your ability to develop solution alternatives, increases
your effectiveness in leading change, and enhances your relationships with all stakeholders.

So, what did Joe present to his boss? A WBS? It does have work tasks listed. A project schedule? It was
created in MS Project. A work plan? That’s what his boss asked for. Well, what you probably have here is a
high-level WBS and an initial milestone schedule summary, at best. This example illustrates how an
inadequate project planning and schedule development process combined with inadequate training on the
project scheduling software can lead to terminology confusion. Table 6.1 summarizes these terms and the
factors that lead to their interchangeable use.
TABLE 6.1

Terms Used for Planning Project Work

Term Description Key Factors Notes

Project Plan All-encompassing Often incorrectly Common tendency to
planning document used to describe think of project
used as basis for project schedule or “scheduling”
execution and work plan. software as project
control. “management”
software.

Project Schedule Shows when the Many “schedules” are Inadequate training
work will be done more like task lists on project scheduling
and by whom. Drives (WBS) because the software; inadequate
project execution. task dependencies schedule
and resource development and
assignments are not review process.
properly captured.

Work Plan A generic term used Usually refers to Need to clarify terms
to refer to either of project schedule. upfront.
the other three.

WBS WBS hierarchical WBS often created Use of project

representation of with project scheduling software
work to be scheduling software is acceptable as long
performed. (MS Project); WBS as the proper process
templates often is followed. For agile,
created and saved a product
with project management tool can
scheduling software be used (e.g., Jira).
(MS Project).For
agile projects, WBS
can be captured as the
Product Roadmap
with breakdown of
epics, stories,
enablers, and tasks.

Key Differences Between the WBS and the Project Schedule

The key differences between the WBS and the project schedule include the following:

 Task dependencies—WBS does not show them; a project schedule does.

 Scheduled tasks—WBS does not show when tasks occur; a project schedule shows start and end
dates for each task.

 Task assignments—WBS does not show who is assigned to an individual task; a project schedule
does.

Different Types of Breakdown Structures

Another factor that can impact understanding of the WBS term and concept is that many industries utilize
other breakdown structures and related acronyms that can confuse this subject. Therefore, to better
understand what is meant by a WBS, you should be familiar with these other types of breakdown structures,
as listed in Table 6.2, and how they are different from a WBS.

Caution

Any work not defined in the WBS is considered to be outside the project scope.

TABLE 6.2

Different Types of Breakdown Structures

Acronym Description Notes

CWBS Contractual WBS Defines the level of reporting
between the seller and buyer.
The CWBS is not as detailed
as the WBS used to manage
the actual work.

OBS Organizational Breakdown Maps work components to

Structure organizational units.

RBS Resource Breakdown Maps work components to

Structure individuals.

BOM Bill of Materials Describes the physical

components needed for the
project.

PBS Project Breakdown Structure The PBS is actually the same

as the WBS. This term is only
used in areas where the term
WBS is incorrectly used to
refer to a BOM.
Why Is the WBS Important?

The Project Management Institute (PMI) considers the WBS the most important tool of the project manager.
Why?

More than any other project management tool, the WBS provides the foundation for defining and organizing
the work needed to fulfill the project objectives. Through the WBS, the work to produce the targeted
deliverables is structured, assigned, scheduled, tracked, and reported. Through the WBS, the work of the
project is effectively represented and communicated to all stakeholders. A well-done WBS accomplishes the
following objectives for the project manager:

Tip

A well-done WBS can become a template for similar, future projects.

 Manage the pieces—It provides a mechanism to manage any project size or complexity. Through
decomposition, you can manage the pieces (work packages) rather than the whole project.
 Better work definition, fewer changes—It enables identification of all necessary work for the project
and only the necessary work. It also reduces the number of items that slip through the cracks as well
as the “Oh, I didn’t think of that!” moments.
 Better estimates, better planning—It improves the accuracy of cost, duration, and resource
estimates.
 Better control—It defines a baseline for performance measurement and control.
 Clear responsibilities—It facilitates clear responsibility assignments at both an individual and an
organizational level.

Note

Major deliverables should come from the project definition document and are likely second-level WBS
elements.

There is no one way to organize a WBS. It should be organized in a manner that emphasizes the most
important aspects and that best communicates the entire scope of the project to your stakeholders.

 Stakeholder buy-in on scope work effort—It facilitates understanding and buy-in of the project
scope, the project approach, the work effort involved, and alignment between scope and work from
each stakeholder.
 Tighter management integration—It provides a mechanism to relate the work directly to schedule,
budget, and resource allocation plans.
 Better team performance—It enables team members to easily understand how their work fits into
the overall project, how it affects the work of other team members, and to stay focused on
deliverables.
 Risk factors identified early—Through decomposition of the work, a more complete and effective
risk analysis can be performed during project planning.
 Confidence increases—When people see that the work of the project is structured, definable, and
doable, their confidence level in the project increases.

The Process of Building a WBS

Now that you understand what a WBS is and the importance it plays in your project, let’s review the key
techniques, guidelines, and principles in building an effective WBS.
In general, the process of breaking down work is something we do frequently and is a straightforward logical
endeavor. However, there are frequently two common challenges in the WBS development process:

 Where do I start?

 Where do I stop?

Getting Started

To start the work decomposition process, think about the following:

 Does a template WBS exist as part of your methodology or from a past project that you can use?

 What are the major deliverables?

 What is the project approach? The project life cycle? The major project phases?

 Think through the entire project. What does the end look like?

To continue the work decomposition process, think about these questions:

 Can you break down this WBS element (deliverable) into subcomponents?

 How exactly will the deliverables be produced? What processes and methods will be used?

 How do you ensure acceptable quality in deliverables and in the process?

 Can you make adequate costs and duration estimates from this level of detail?

Guidelines for Effective WBS

Here are a few guidelines regarding the development of the project WBS that you want to keep in mind:

Note

The WBS should always be defined at least one level lower than what is required for management reporting
purposes. This enables you to better identify the source of any issues or variances.

In general, the more detail in the WBS, the more accurate the work estimates and the better level of control.
However, there is a balance. Too much detail and you will incur excessive costs performing data collection,
tracking, and reporting. Too little detail and you incur higher risks and are unable to effectively manage.
  All the work of the project is included in the WBS.
 The WBS should be deliverable focused.
 All deliverables are explicit in the WBS.
 The WBS should be developed with the team.
 The WBS is refined as the project progresses.
 The WBS is a top-down decomposition and is logical—the summary tasks go with lower-level tasks.
 The WBS should be organized in a manner that emphasizes the most important aspects of the
project and that best communicates the entire scope of the project to your stakeholders.
 The lowest level of the WBS is the work package or activity level and is used for schedule and cost
development. This is the level where effort and cost can be reliably estimated.

Caution

Most troubled projects have WBS elements that are too large. If each lower-level element should be
completed within the standard reporting period (every week or every two weeks), it is much easier to track
actual progress and to take any corrective actions.

 Unique identifiers are assigned to each item in the WBS to allow for better management reporting of
costs and resources.
 WBS elements should be consistent with organizational and accounting structures.
 The coding scheme should clearly represent a hierarchical structure.
 Review and refine the WBS until all key project stakeholders are satisfied.
 Each WBS element represents a single deliverable and should be an aggregation of lower-level WBS
elements.
 Each WBS element has only one parent.
 Upper levels of the WBS represent major deliverables or project phases.
 The WBS should include project management tasks and activities.
 The WBS should include and isolate any work needed to integrate components and deliverables.
 The WBS should account for any subcontracted or externally committed deliverable.
 The WBS should represent all work needed to ensure completeness, correctness, and acceptance of
deliverables.
 The depth of WBS depends on three key factors:

 Amount of project risk

 Reporting requirements

 Balance of control versus costs

Note

These are solid guidelines—not rules.

The most important thing to remember is to size the work package to the level you need for effective
management and control. Again, setting the maximum size to correspond to your reporting period is an
excellent idea.

The level of depth (granularity) for the work package level in a WBS (lowest levels) will vary. It depends on
what level of detail the project manager needs for effective management and control of the project.

In a program, or on large projects, the work package level might represent efforts in the hundreds of hours.
In these cases, it is expected that the teams assigned to these work packages (or subprojects) will define the
detail activities and tasks needed to complete the work package. From a practical standpoint, these teams
should develop their own WBS that can then be rolled up into the master WBS.

Knowing When to Stop

The other aspect of WBS development that creates frequent uncertainty is knowing when to stop. To
determine whether you have enough detail in your WBS, review these questions for each lower-level item:

 Can each lower-level item be estimated, scheduled, budgeted, and assigned to a responsible party?

 Do you need more detail to make it easier to estimate effort, assign work, track costs, or measure
progress?

 You will read about common rules of thumb for the proper size of work packages. The most common
rules are 8/80 and 4/40, which means no task should be less than 8 hours or more than 80 hours, or
in the case of 4/40, it would be less than 4 hours or more than 40 hours.

 In addition, consider further decomposition of the lower-level item, if any of the following are true:

o The work cannot be completed within the standard reporting period for the project.
o There are specific risks associated with a smaller portion of the work element.
o More than one individual or group is responsible.
o More than one deliverable is included.
o More than one work process is included.
o There is a time gap involved.
o The resource requirements for the work element are not consistent.

The importance of the WBS cannot be overemphasized. Because the correctness and completeness of the
WBS has a direct impact on how well we determine our resource needs, estimate the work efforts, and
properly sequence the work, it is the foundation that drives our schedule and most of our planning efforts.

Do I Need a WBS for an Agile Project?

You might be wondering if this WBS development process applies to you if your organization is using agile
project management. Let me assure you…it does. The main difference is when this work breakdown occurs.
For an agile project, the targeted work items are prioritized and details refined on an iterative basis rather
than attempting to do it all upfront. In addition, the tool that manages the Product Backlog (the work items
yet to be completed) would capture all of the WBS work packages. But in the end, the quality of your
schedule and your ability to manage expectations are dependent on the degree that all of the work required
was accounted for in the plan. Missing work items are a common reason why all the planned work for an
agile iteration or sprint was not completed within the designated time box. Of course, this is one of the
advantages of the agile development approach. The inherent feedback loops and iterative planning processes
for each work iteration help identify these gaps sooner and allow you to adjust plans accordingly.

The Absolute Minimum

At this point, you should have a solid understanding of the following:

 A WBS is a logical breakdown of all the work to be performed by the project.

 A WBS is neither the project schedule nor the project plan.

 The WBS should be developed with the project team.

 The WBS is a vital tool to the project manager.

 Avoid judging a current work process or the people involved before you understand why it is done
this way or how it evolved to the current point.

 You learned how to evaluate a WBS.

 You learned how to avoid the common challenges and issues with WBS development.

 The WBS is the foundation for developing a realistic schedule, determining project resource needs,
and figuring an accurate project budget.

 The work packages included in the WBS should be detailed enough to support effective management
and control.

 The maximum size of a WBS work package should correspond to the standard reporting period for
the project.

 For an agile project, the WBS is essential, corresponds to the Product Backlog, and is continuously
refined.
The map in Figure 6.4 summarizes the main points reviewed in this chapter.

FIGURE 6.4

Developing a work breakdown structure overview.

The developing work breakdown structure branches into definition, difference with schedule, importance,
guidelines, key principles, decomposition factors, and further decompose if ellipsis. Definition branches into
graphical or outline form and organized, and hierarchical representation top-down decomposition of work.
Difference with schedule branches into no dependencies, no resource assignments, and not scheduled.
Importance branches into the following. better management of the pieces, better work definition, fewer
changes, better estimates, better mates planning, better control, clearer responsibilities, facilitates buy-in on
work scope, tighter management integration, better team performance, serve as template for future
projects, early identification of risk factors, and increased stakeholder confidence. guidelines branches into
develop “with the team,” explicitly list all deliverables, refine as the project progresses, estimate effort and
costs at work package level, use unique identifiers, upper levels of the W B S represent major deliverables or
project phases, each W B S element represents a single deliverable and should be an aggregation of lower-
level W B S elements, each W B S element has only one parent, the W B S should include project
management, the W B S should include and isolate any work needed to integrate components or
deliverables, the W B S should account for any subcontracted or externally committed deliverable, and the W
B S should represent all work needed to ensure completeness, correctness, and acceptance of deliverables.