WBStructorrrrrrrrrrrrrrrrrrrrrrrrrrrrrr.pptx

2.6 WORK BREAKDOWN STRUCTURE
A project team armed with a well-defined project scope document can
proceed to the next most important phase in project planning: development
of the work breakdown structure (WBS). The WBS is a hierarchical
structure in which all of the major phases of project work are organized
in a logical manner. Simply stated, it is a layout of how the work of the
project ought to be performed and managed.
The WBS links together the project scope, the schedule, and the cost
elements, and forms the basis for the entire project information structure.
It provides the framework that captures the project’s work information
flows, as well as the mechanism for tracking the project’s schedule and
progress. It also provides the basis for summarizing and reporting the
project’s cost data.
In essence, the WBS creates a common framework that
• Presents the entire project as a series of logically interrelated elements
• Facilitates project planning
• Provides the basis for estimating and determining project costs and
budgets
• Provides the mechanism for tracking project performance, cost, and
schedule
• Provides the basis for determining the resources needed to accomplish
project objectives
• Provides the mechanism for generating project schedule and status
Reports
• Triggers the development of the project network and control systems
• Facilitates the assignment of responsibilities for each work element
of the project

Graphically, we can imagine aWBS along the lines shown in Figure 2.3.
There are some important features to note here. First, the breakdown
of project activities is hierarchical, moving from the overall project level,
down through specific project deliverables (and sometimes subdeliverables),
and finishing with work packages. According to the Project
Management Institute’s PMBoK, work packages are the elemental tasks
at the lowest level in the WBS and represent basic project activities for
which duration and budget figures can be assigned.
Along with a well-defined project scope document, a WBS with sufficient
levels of detail is an invaluable tool for managing scope change.
Project scope can easily be expanded or diminished by including or
eliminating
the appropriate work packages, and by making the necessary
adjustments in terms of resources and schedules.

Types of Work Breakdown Structures
There are many different types of work breakdown structures. The
product-based WBS is most suitable for projects that have a tangible

outcome, such as the design and construction of a tunnel, or a new fighter
jet prototype. In these kinds of product-based work breakdown structures,
it is relatively easy to break the project into deliverables, subdeliverables,
and ultimately into manageable work packages. A product-based WBS
also facilitates cost estimation of the various product components, which
in turn provides a basis for comparison with the project’s actual cost
performance. An example of a product-based WBS is shown in Figure 2.4.
In an organizational breakdown structure, known as OBS, the
organizational units responsible for completing the work requirements
of the project are integrated into the structure. The clear advantage of
an OBS is that it establishes, in a hierarchical format, accountability,
responsibility, and reporting relationships for the various organizational
units that are involved in completing the work. An example of an OBS is
shown in Figure 2.5.
When a project involves a series of phases or tasks, such as in an
information systems project, a process-oriented WBS is more appropriate.
Unlike a product-based WBS, a process-oriented WBS involves
completion of major tasks in sequence as the project evolves over time. In
general, a process-oriented WBS can be better integrated with the overall
project, because the tasks can be delineated to the lowest level, while
the product-based WBS is most useful for accumulating product cost
information. In addition, hybrid structures that involve a combination of
features from both product- and process-based structures can be used. An
example of a process-oriented WBS is shown in Figure 2.6.

In the present-day project environment, with its proliferation of computerized
project management systems, both types (product and process)
of WBS can be used. However, the choice really depends on the particular
project, its purpose, the organization’s information system and how
it interfaces with the other organizational units, and, ultimately, how
useful it is as a planning aid.

Work Breakdown Structure Development
The construction of the WBS is worthy of special consideration, because it
is critical to the information structure that will be set up to cover most of
the project’s managerial data set. In this section, we review the procedure
for constructing a WBS, as well as some of the practical aspects that
should be considered in developing one.

Constructing a WBS is a group effort. The responsibility for the top
three levels usually lies with the project manager, who typically works
with other managers to develop the major deliverables found there. At
the lower levels, however, input into the details should come from those
responsible for the day-to-day work. In addition to the project team, each
person responsible for a specific work package must be consulted.
There are no universal standards as to the number of levels to use in a
WBS. This is typically dictated by the complexity of the project, and the
number and nature of the activities. Most have three or four levels at a
minimum, although more may be needed if there are significantly more
subdeliverables and work packages.
As a rule, the greater the number of work packages, the greater the
amount of time, effort, and cost incurred in developing the WBS.However,
the increased number of packages also significantly enhances the accuracy
of project status monitoring and reporting. On the other hand, larger but
fewer work packages reduce the cost of WBS development, but the
accuracy of project status monitoring and reporting suffers. In most
practical situations, a compromise on the number and size of work
packages is struck.
The most important levels in the WBS development process are the top
few levels, which represent the project and associated major deliverables,

and the lowest levels, which represent the work activities that are to
be scheduled and resourced. Typically, the intermediate levels are an
aggregation of the lower-level activities, and serve as the mechanism
for reporting. The intermediate levels can also be used to set up cost
accounts through which cost and budgetary information can be gathered
and monitored.
A WBS should be constructed by separating the total work, in a
hierarchical framework, into discrete and logical subelements that reflect
completeness, compatibility, and linkage to the project’s end item. This
hierarchical structure facilitates the aggregation of budget and actual
costs incurred into larger cost accounts. In this way, the total value
of the work at one level is an aggregation of all the work completed
one level below, which enables project work and cost performance to be
monitored. The WBS should also reflect all of the project requisites, as
well as functional requirements, and should incorporate both recurring
and nonrecurring costs.
In a WBS, the lowest level consists of tasks of short duration that have
a discrete start and end point. Because they consume resources, costs are
often reported at this work package level. Work packages serve as control
point mechanisms for monitoring and reporting performance, in terms
of whether associated tasks were completed according to specifications,
on time, and within budget. The responsibility for completing work
packages should be assigned to the appropriate organizational units
and individuals, and the resulting WBS should reflect the reporting
requirements of the organization.
We can develop a WBS by one of two methods: top-down or bottom-up.

The top-down approach begins with the total work required to
produce the project’s end product. This is successively broken down,
first into majorwork blocks and then into more detailed work package
levels until a required level of detail has been achieved.
• The bottom-up approach begins with a comprehensive list of all
the activities or tasks required to complete the project. Then it moves
up, in a hierarchical format, first to work packages, then to cost
accounts, and so on, until the top level represents the total work to
be performed.
It is highly unlikely that the first version of the WBS will be the
last. More often than not, it will undergo frequent revisions in response to feedback that work must be broken intomore
detailed tasks. Clearly, only individuals who have a thorough knowledge of the work to be performedcan conduct the
appropriate level of detailed breakdown. In addition, it is
impossible to establish estimates of task duration, resource requirements, and the network of precedence relationships
among activities without complete agreement on details at the lowest level. One final caveat: while the WBS is very much
a part of the overall project planning process, the two data sets for project planning and the work breakdown structure
are distinct entities and should be kept separate.

Coding of Work Breakdown Structures
Correctly coding a WBS facilitates the identification and definition of its
various levels and elements. Coding schemes also enable consolidation of
reports at any level of the WBS, which makes them useful for tracking
budgetary and cost information. While a variety of schemes can be used,
the most common method is numeric indention.
For example, in the product-based WBS shown in Table 2.4, code 1040
indicates the step of seeking and hiring an IT consultant, while one of
the work packages for this deliverable, 1041, requires that the company
form a search committee. This kind of coding process is repeated for each
WBS element.
Just as the hierarchical levels become more specific as we move down,
project coding typically follows a similar degree of specificity. For example,
in the task-based WBS for a hypothetical MIS installation project shown
in Table 2.4, code 1000 designates the final deliverable, while code 11200
represents the lowest manageable subdeliverable. Other features that
can be incorporated in a WBS include the use of alpha characters and
additional numeric characters to indicate the type of work, geographical
location, vendor type, and so on.

Coding of Work Breakdown Structures

Integrating the WBS and the Organization
The final phase of WBS development is integrating it with the various
organizational units. This is done to identify the organizational
units responsible for performing the work, to provide a framework for summarizing
performance, and to provide a link between the organizational
unit and cost control accounts. The end result of this process
is the aforementioned organizational breakdown structure (OBS),
which shows how the firm has organized to discharge work responsibility.
The intersection of work packages and organizational units
generates cost accounts that will be used later for project control
purposes.
An example of how WBS levels and tasks can be linked with budget
and personnel is shown in Table 2.5.

Guidelines for Developing a Work Breakdown Structure
At this point, it should be clear that there are no universal standards or rules that can be applied to
developing a WBS—which can make it a challenging and daunting task. However, the following guidelines
may be useful in many situations12:
1. Each element of a WBS, at any level, should be tied to the deliverables at that level. In this way, there will be no ambiguity
about whether an activity has been completed (product delivered) or whether it is still ongoing (product not yet delivered).
2. Each element of a WBS at a higher level should be broken down into more than one element at the immediate lower level.
If this does not happen, then one of the levels is redundant. The only exception is when upper levels are mandated by
procedural requirements.
3. Each element of a WBS at the lowest level must be assignable as an integral unit to a single department, vendor, or
individual. This is the first part of the answer to the question, ‘‘What level of detail should exist within the WBS?’’ If no one
department, vendor, or individual is responsible for an activity, then not only may there be accounting and scheduling
problems, but no one is likely to assume responsibility for it.
4. The riskier elements of the WBS should be broken down into greater details to enable the risks to be identified and dealt with. This is the
second part of the answer to the question, ‘‘What level of detail should exist within the WBS?’’
5. In developing the WBS, it is important to distinguish between it and the project plan. As both the work breakdown structure and the cost
structure feed information into the overall project plan, these three entities are interrelated—and any changes to any one of them may have
an impact on the others.
In closing, the project management concepts discussed in this chapter are of paramount importance to effective cost and value management.
Without a precise definition of project needs, a well-defined SOW and project scope documents, and an accurate and well thought-out WBS,
neither value optimization nor efficient management of costs in projects is possibl

WBStructorrrrrrrrrrrrrrrrrrrrrrrrrrrrrr.pptx

More Related Content

Similar to WBStructorrrrrrrrrrrrrrrrrrrrrrrrrrrrrr.pptx

More from RedhaElhuni

Recently uploaded

WBStructorrrrrrrrrrrrrrrrrrrrrrrrrrrrrr.pptx