USING THE WORK BREAKDOWN STRUCTURE TO PLAN A PROJECT

Planning answers the questions, “What must be done?,” “How long will it take?,” and “How much will it
cost?” Planning the what is vital; projects frequently fail because a significant part of the work is
forgotten. In addition, once tasks have been identified, the time and resource requirements must be
determined. This is called estimating.

A major problem in project planning is determining how long tasks will take and what it will cost to do
them. Inaccurate estimates are a leading cause of project failures, and missed cost targets are a
common cause of stress and recrimination in project management.

The most useful tool for accomplishing all of these tasks is the work breakdown structure (WBS). The
idea behind the WBS is simple: You can subdivide a complicated task into smaller tasks until you reach a
level that cannot be further subdivided. At that point, it is usually easier to estimate how long the small
task will take and how much it will cost to perform than it would have been to estimate these factors at
the higher levels.

Creating WBS : The key benefit of this process is that it provides a framework of what has to be
delivered. This process is performed once or at predefined points in the project.

Nevertheless, it is still not easy to estimate task durations for activities that have never been performed
before. Because this is the typical situation in engineering hardware and software development projects,
we might expect many of these estimates to be in error, and this seems to be demonstrated by
experience. Still, the work breakdown structure makes it easier to estimate knowledge tasks than any
other tool we have.

Key components of a work breakdown structure

Each component of a WBS serves a different purpose. They have specific roles and levels of detail. The
highest level depicts the ultimate goal, and the lowest level defines specific details.

 Phases: Phases represent the major stages of the project life cycle. Each phase groups relevant
activities and tasks.

 Tasks: Tasks are individual activities within each phase of a project.

 Subtasks: Each task splits into subtasks, allowing for precise planning and execution.

 Deliverables: Deliverables are tangible or intangible outputs resulting from the completion of
tasks.

 Sub-deliverables: Sub-deliverables are smaller outputs that contribute to completing larger

deliverables.

 Work packages: Work packages are the smallest units of work in a WBS. They are detailed tasks
or groups of tasks with specific deliverables.

 Dependencies: Dependencies indicate the relationships between tasks. They display which tasks
to complete before others can begin.

 Estimates: Estimates approximate the resources, time, and costs required, helping with
budgeting and scheduling.

 Milestones: Milestones mark the completion of key phases, deliverables, or other

important project goals.

The WBS organizes the project into manageable components by breaking the scope into detailed,
smaller parts. Clearly defined components make assigning responsibilities, estimating costs, scheduling
timelines, and monitoring project progress easier.

Comparing WBS types: Deliverable vs phase based

`
Deliverable-based WBS

A deliverable-based WBS focuses on the project's output. It breaks the project into major deliverables
instead of phases. This is more useful for projects where the end product or the output is clear and
distinct.

Phase-based WBS

Unlike deliverable-oriented WBSs, a phase-based WBS divides the project according to its phases or
stages. Each phase represents a major section of the project timeline, and all the phases break down
into further tasks and activities.

WBS levels

A work breakdown structure organizes deliverables into a hierarchy of levels.

 Level 1 - Final deliverable or project goal: The project goal is the ultimate deliverable, and all
other deliverables stem from it. This level either appears at the top of your WBS or in the first
column, depending on the format you use.

 Level 2 - Major deliverables or phases: This level summarizes all major categories of
deliverables. If any sub-deliverables fall outside these categories, adjust your categories to
ensure Level 2 captures 100% of the deliverables.

 Level 3 - Sub-deliverables or phases: At this level, major deliverables are broken down into
smaller groups of deliverables or even individual deliverables, if possible. Each item in Level 3
should still be a deliverable, not a task.

 Level 4 - Work packages: One more pass of decomposition yields individual deliverables, or
work packages. A work package is a deliverable that can only be broken down into tasks and
subtasks. These live on the bottom level of the WBS.

Guidelines for Developing the WBS

One important question in constructing a WBS is, “When do you stop breaking down the work?” The
general guideline is that you stop when you reach a point where either you can estimate time and cost
to the desired degree of accuracy or the work will take an amount of time equal to the smallest units
you want to schedule. If, for instance, you want to schedule to the nearest day, you break down the
work to the point where tasks take about a day to perform. If you are going to schedule to the nearest
hour, then you stop when task durations are in that range.

`
 - Stop breaking down work when you reach a low enough level to do an estimate of the desired
accuracy

One important point: The WBS should be developed before the schedule.

The WBS is the device that ties the entire project together. It allows the manager to assign resources
and to estimate time and cost and shows the scope of the job in graphic form. Later, as the project is
tracked, the work can be identified as falling in a particular box in the WBS.

Uses of the WBS

The WBS is a good way to show the scope of a job. If you have ever given someone an estimate for a
project cost or time and have seen her horrified look, you know she is seeing the project in her mind as
much simpler than it is. When you show a project in WBS form, it is clear to most individuals why the job
costs so much. In fact, I have had the experience of finding the planning group members themselves
overwhelmed by the complexity and magnitude of the WBS. If it impresses them, think of its impact on
an outsider.

Assigning responsibility for tasks is another important use of the WBS. Each task to be performed should
be assigned to a particular person who will be responsible for its completion. These assignments can
then be listed on a separate form, often called a responsibility chart.

How to create a work breakdown structure: Steps involved in creating a WBS:

Define project scope and objectives

Clearly define the overall project scope and specific objectives. This involves understanding the project's
goals, constraints, and requirements. A well-defined scope provides the foundation for the entire WBS.
The stronger the foundation, the greater your chances of success.

Identify major deliverables

Next, identify the main outputs or the project deliverables. List the key results that the project aims to
achieve. For example, the major deliverables for a mobile application project could include UI design,
backend development, database setup, etc.

Break down deliverables into sub-deliverables

Once you identify the major project deliverables, divide them into smaller, more manageable sub-
deliverables. For example, sub-deliverables could include wireframes, mockups, and design reviews for a
user interface deliverable.

Identify work packages

After breaking down the deliverables, divide the sub-deliverables into specific work packages. List all the
work packages needed to achieve the sub-deliverables. For example, work packages for wireframe sub-
deliverables could include initial sketches, reviewing samples, and finalizing the wireframe.

Define activities within each work package

Identify and describe the detailed activities required to complete each work package. List all
management tasks, resources, and dependencies necessary to achieve the work package's goals. .

Create the WBS chart

Finally, organize the WBS components into a visual chart or diagram. This chart represents the hierarchy
of the project scope, from the overall project to individual management tasks. Use the Gantt chart
model for this step.

A gantt chart allows you to map out deliverables with due dates, milestones, and dependencies from the
work packages identified in your work breakdown structure.

`
 - Common WBS format

- The flowchart—also known as a tree diagram—is the original WBS format. This classic example
shows the entire project scope in a visual hierarchy, with lower-level child deliverables nested
under higher-level parent deliverables.

- A flowchart clearly defines the larger project goals, as well as the smaller deliverables needed to
achieve each one. You can use boxes and colors to distinguish different phases or deliverable
groups to make it easier for some team members to understand.

Estimating Time, Costs, and Resources

Once a project is broken down into tasks using a Work Breakdown Structure (WBS), the next step is to
estimate how long each task will take, how much it will cost, and what resources are needed. These
estimates are essential for:

 Scheduling: Ensuring tasks are completed on time.

 Budgeting: Allocating financial resources appropriately.

 Resource Management: Assigning the right people and tools.

Consider the example of sorting a shuffled deck of playing cards into numerical order by suit. If asked to
estimate the time, people might give different answers based on their experience or perception of the
task. The average estimate might be three minutes for an adult. However, several factors influence this
estimate.

Factors Affecting Estimates

Estimates depend on who performs the task and how it is done.

 Skill Level: A child unfamiliar with card ordering would take much longer than an experienced
adult.

 Historical Data vs. Mental Models:

o Historical data (previous records) provide the most reliable estimates.

o If no historical data exist, we rely on mental models or best guesses.

These factors highlight why estimates cannot be generalized without considering who is doing the work
and under what conditions.

`
  Skill Level: A child unfamiliar with card ordering would take much longer than an experienced
Most project managers use average times to plan. For example, if sorting a deck takes an
average of three minutes, we use that as the estimated duration. However, in reality:

 Some tasks take more time, while others take less.

 The goal is to balance these variations over the project timeline.

But this method has a challenge—Parkinson’s Law.

Parkinson said that work always expands to fill the time allowed. That means that tasks may take longer
than the estimated time, but they almost never take less.

- If people have extra time, they refine or expand their work instead of finishing early.
- Employees may fear that completing tasks early will lead to higher expectations or more
workload in the future.
- If people are penalized for performing better than the target, they will quit doing so.

The Hazards of Estimating

Estimating project costs, time, and resources is crucial, but it comes with significant risks if not handled
properly.

KAREN CASE

One day, her boss stopped by her desk at about one o’clock. “Need for you to do an estimate for me,”
he told her. “Promised the Big Guy I’d have it for him by four o’clock. You with me?” Karen nodded and
gave him a thin smile. The boss described the job for her. “Just need a ballpark number,” he assured her
and drifted off.

Given so little time, Karen could compare the project her boss described only to one she had done about
a year before. She added a little for this and took a little off for that, put in some contingency to cover
her lack of information, and gave the estimate to the boss.

After that, she forgot all about the job. Two months passed. Then the bomb was dropped. Her boss
appeared, all smiles. “Remember that estimate you did for me on the XYZ job?” She had to think hard to
remember, but, as her boss droned on, it came back to her. He piled a big stack of specifications on her
desk. “It’s your job now,” he told her and drifted off again into manager dreamland.

As she studied the pile of paper, Karen felt herself growing more concerned. There were significant
differences between this set of specs and what her boss had told her when she did the estimate. “Oh,
well, I’m sure he knows that,” she told herself.

Finally, she managed to work up a new estimate for the job on the basis of the real specs. It was almost
50 percent higher than the ballpark figure. She checked her figures carefully, assured herself that they
were correct, and went to see her boss.

He took one look at the numbers and went ballistic. “What are you trying to do to me?” he yelled. “I
already told the old man we would do it for the original figure. I can’t tell him it’s this much more. He’ll
kill me.” “But you told me it was just a ballpark number you needed,” Karen argued. “That’s what I gave
you. This is nothing like the job I quoted. It’s a lot bigger.” “I can’t help that,” her boss argued. “I already
gave him the figures. You’ll have to find a way to do it for the original bid.

Naturally, you know the rest of the story. The job cost even more than Karen’s new estimate. There was
a lot of moaning and groaning, but, in the end, Karen survived.

Karen’s story highlights a common issue in project management: ballpark estimates turning into firm
commitments before sufficient details are available.

Suggestions for Effective Estimating

The American Management Association highlights several approaches for project managers to develop
good, solid estimates

`
Historical Data

Learn from the past. Historical data can be considered the best source for project estimates. How long
did this task take to complete last time? How much did this subassembly cost?

Level of Detail

Determine the required level of detail for your estimates. If you are in the Initiation phase of your
project, high-level estimates should suffice. If you have completed your Work Breakdown Structure and
are deep into planning, you will typically take a more detailed approach. The smaller the unit of the
work, the more accurate your estimate is likely to be.

Ownership of the Estimate

If the individual supplying the estimate owns it, it is likely to be more accurate. Consider the team
member estimating the duration to complete a task, knowing that because her name will be associated
with the estimate, she will be held accountable. The team member now owns the estimate and will
invest more time and effort to produce a more accurate number. If no ownership exists, the team
member may try to “wing it.”

Human Productivity

Project managers, team members, and others supporting the project cannot be expected to be 100
percent productive during the course of a working day. This would not be realistic. People are
distracted, call in sick, move in and out of the project, and so on

In Figure 7-5, you can see that the standard 40-hour, five-day week must be adjusted to take into
account project loss (15 percent), reworks/debugs (10 percent), and labor overhead (15 percent). As the
figure shows, the estimated total required hours is 56, not 40, and the estimated required number of
days is seven, not five.

Project managers must work in the

real world. We accomplish work
within the triple constraints triangle of
scope, time, and cost (see Figure 11-1
on page 149). Consequently, the
realities of human productivity must
be considered whenever estimates
are calculate

Time/Cost/Resource Trade off

When estimating in the project environment, don’t forget the human dynamic. Team members are not
robots, yet.

Figure demonstrates what typically results

when an individual is working on multiple
tasks. The stops and starts create
inefficiencies. She must stop one task and
ramp up to begin another, reducing
productivity. Conversely, if a task will be
shared by more than one individual,
inefficiencies appear in the form of additional
communication requirements, possible
conflict, and the need to identify logical break
points between workers.

Distribution of Estimates.

Distribution adds knowledge and common sense to the estimating process. Using only worst-case
assumptions will generate arbitrarily high estimates. Using only best-case assumptions will likely set

`
your project up for failure, as everything must go right to achieve the estimate. The most likely estimate
should rely on experience and account for reality. It is here that the project manager takes the
temperature of the project. She takes into account project constraints and variables and determines
what should be considered most likely today

Using these concepts, the project manager can apply simple formulas to improve estimation accuracy.
The three-point estimates technique is used to identify the level of uncertainty in an estimate.

Three sets of estimates are produced for a project activity using three different sets of assumptions. The
first is the optimistic, or best-case, estimate; the second is the pessimistic, or worst-case, estimate; and
the third is the most likely estimate. This allows you to calculate the standard average, you add the
three points and then divide by three. The result is a number that considers all possibilities and gives you
a working estimate.

The Program Evaluation and Review Technique (PERT) is a variation on three-points estimating.

Many projects are unique efforts that include tasks that have not been done before. Consequently, no
historical data are available.

PERT has proved a very useful tool when estimating in this type of project environment. It works
especially well when there is this high degree of uncertainty, as the pessimistic estimate can be
extremely high. This approach also allows the project manager to apply weight to the most likely
estimate based on experience and the current situation.

The difference between it and the standard average approach is that PERT contains a weighting factor,
so it is a weighted average.

You are adding weight to the most likely estimate (ML) because, based on experience and the current
situation, you think that will be the most probable outcome. The most likely estimate in Figure is
weighted by a factor of 4 (4ML). ML is counted four times and optimistic and pessimistic estimates one
time each, yielding a total of six values. This is why you divide by six when determining the PERT
weighted average.

PERT Example

Within a large city, some factors

influence how long it takes to drive from
home to the office. The weather, the
time of day, and any vehicle accidents
on the road can impact the duration to
get from home to the office on those
roads.

`
 Most Likely 60 clear weather, clear roads, normal volume of drivers on some of the
(M) minutes roads

30
Optimistic (O) clear weather, clear roads, no other drivers on any road
minutes

Pessimistic 120 thunderstorm with rain, road blocked from multiple vehicle accidents,
(P) minutes the highest volume of drivers

The weighted average of the three estimates is used in the PERT formula:

 PERT = (30 + [4 x 60] + 120) / 6

 PERT = 390 / 6

 PERT = 65 minutes

Many project managers think that the final estimate will always be close to the most likely value (ML)
because of the weighting factor. While that is often true and appropriate, the uncertainty of the project
environment often drives the pessimistic value higher, resulting in a better overall estimate. Remember,
estimates are predictions. They are projections into the future that are inherently uncertain. Use your
subject matter experts! Nobody knows the work and can estimate more accurately than they can. As
your project matures and you become smarter, you can adjust and update your estimates.