Work Breakdown Structure

1)What is WBS
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.

Work breakdown structure (WBS) is a technique to decompose the project for the
purpose of management and control. It provides the framework for organizing and
managing the work.

A project may be divided into subprojects. Subprojects are subdivided into smaller, more
manageable work components (work packages) at the lowest level. The work packages
may be further decomposed to project activities. It provides the framework for organizing
and managing the work.

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. WBS includes
activities like management, procurement, installation, software
development etc. Many of the WBS development tasks are derived from the development
method that will be used, and from the design and architecture of the system.

WBS is related to planning and scheduling a project. It is a functional decomposition of

the tasks of the project.

It starts with the end objective required and successively subdividing it into manageable
components in terms of size and complexity of:
– Program,
– Project,
– System,
– Subsystem,
– Components,
– tasks, subtasks, and
– work elements

The WBS is first and foremost a technical data gathering structure, developed so that the
achievement in technical progress can be measured and analyzed against a formal
baseline plan.
The WBS aids the customer in understanding the status of the project as time elapses.
The WBS aids the customer's customer in understanding the status of the project. All
managers, internal and external need to use the planning and status information within the
WBS.

WBS is a definition of a project in terms of its work or a deliverable-oriented grouping of

project elements that organizes and defines the total scope of the project.

Each descending level represents an increasingly detailed definition of the project’s work.
It’s an outline of the work of the project, not the work itself, created by those doing the
work – that may include all functional stakeholders.

The WBS is produced following the development of the scope statement, before the
schedule. It is a “bridging” document between the Scope and Schedule. (what and when)

– Defines 100% of the scope and can communicate the scope of the project without the
presence of the scope statement or document.
– Communicates effectively to all stakeholders
– Defines and clarifies
– Boundaries (Life cycle of the project – not the product)
– Deliverables
– Refines Scope

Defines scope in project management language (perhaps down to work package level
which may lead to development of project schedule)

It’s not a single document that can be mistaken for the project plan, schedule or scope
statement

2)WBS as a Project Management Tool

A WBS is a valuable management tool that is used throughout all life-cycle phases to:

a. Manage Risk
It helps in managing risk by providing insight into technical aspects of program
management.

b. Manage Costs
A WBS can be used to help make program management decisions.
For example, if the costs of an element in the WBS are too high, the WBS can be used to
identify possible tradeoffs. Identifying and analyzing tradeoffs can help the manager
decide how best to stay within budget.

c. Assign Work
The WBS is also useful for determining an acquisition strategy and/or assigning work.
The information contained in the WBS can help a Program Manager to develop a
statement of work that describes what products or services are to be delivered.

d. Schedule and Track activities

A schedule of key events can be developed for each element in the WBS. Completion of
these key events is then tracked.
– Schedule and Track activities
– The work breakdown structure defines all tasks to be performed during the
development of the project. This will include tasks from such project categories as:
Software development, Installation, Maintenance, Management, Training, Procurement,
Documentation
e. Align with Terms of Reference and scope of project
– At all times, any, work being performed by a member of the software project team must
be part of a WBS task: No member of the team should ever perform any task that does
not appear in the WBS list of tasks.
– The WBS is essentially a management tool that provides the ability to assign well-
define tasks to members of the development team.
– It is through the WBS that progress is monitored as tasks are completed and potential
problems are discovered.
– New tasks that were overlooked are identified, and estimates are revised based on the
actual resources used for completed tasks.

f. Report Expense
– The WBS is also a budgetary tool that provides a means of charging each development
activity to the appropriate section in the project budget.
– This is one of the basic methods for planning and monitoring project expenditure.
– There are mainly computerized utilities available to support the maintenance of the
WBS.
– These utilities run both on small PC type computers and large mainframes.
– WBS utilities are often available as part of a manager's general planning utility, and
provide other scheduling and monitoring features, such as PERT analysis and report
generation.

g) Mapping WBS for Cost Management.

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.

h) Characteristics of a High-Quality WBS

a) Review and signoff from top to bottom
b) Includes logical flow and is hierarchical in nature
c) Clear and concise
d) Provides ability to roll-up information to higher levels
f) Should have at least 2 levels: Level 1 defines 100% of the service/product/result; Level
2 defines the deliverables in terms of work (groupings)
g) Project Management (and sub-contract management) at Level 2.
h) The deliverables in the WBS must match the scope or contract (WBS should not
contain work that is not defined in the scope – Scope should not describe work not
contained in the WBS)
i) All deliverables should be accounted for regardless of responsibility
j) Every WBS element should be clearly defined – or should be clarified in the WBS
Dictionary
k) Features
– The WBS should contains 100% of the work defined by the scope or contract
– Development of WBS should involve the entire project team
– Should be deliverable-oriented
– Should captures all deliverables (Internal, External, Interim) in terms of work to be
completed
l) Usefulness
– Should define the context of the project and clarifies the work
– Should communicates project scope to all stakeholders in terms of the work to be
completed
– Implies and allows for continual improvement/update of the WBS to maintain current-
ness and “vitality” within the project
m) WBS Is Not
– A single document that substitutes for the project schedule or project plan
– The project schedule

3)WBS- Major Steps

a) Project Decomposition
Many complex objects can be viewed as a collection of numerous simpler objects. An
appropriate example would be a complex chemical compound that is formed by various
molecules, each of which is formed by combining various atoms. The atom, though itself
divisible, can be regarded as the smallest particle of a chemical substance.

In a similar way, a complex project can be divided into simpler components. While the
full project may be difficult to manage, each component will be easier to handle.
Software projects can be decomposed into smaller components in order to provide better
estimates of the amount of work involved, or in order to monitor the activities of the
various development teams.
The decomposition of a software project is one of the software project manager's first
tasks. However, the method of decomposition may differ, depending on the project
manager's actual objective. A functional decomposition of a project may not be the same
as design decomposition.
A functional decomposition divides the project into its basic components from a user's
perspective, while design decomposition divides a project into its basic programming
components or modules.

Intuitively, it would not appear reasonable to attempt to identify all project components in
a single step. Clearly, an iterative procedure that would gradually provide more detail
would be easier to use. Iterative methods of this kind are called stepwise refinement, as
the decomposition is further refined in each succeeding step.

Figure 1 presents a general illustration of stepwise refinement. The system is initially

divided into three top level components. In turn each top level component is further
divided into lower level components, and so forth, until the lowest decomposition level is
reached.
In a stepwise decomposition of a project, each component decomposes into the
components directly below it, so that each step of the decomposition describes the full
system, but at a different level of detail.

A stepwise refinement diagram looks similar to a hierarchical system chart. However, it

is important to understand that stepwise refinement is basically different because the
diagram's building blocks are different A hierarchical system diagram describes the
hierarchical relationship between components, so that each component in the diagram
actually corresponds to a real component in the system. However, in a stepwise
refinement diagram, a higher level component is only a name conveniently given to a
group of real components that appear below it.

Controlled access system software has five low level software components:
Visitor identification, Door lock-control, Access file-manager, Illegal access
identification and Alarm activation. Each of these five modules may correspond to an
actual software module1. The two high level components, Access control and Alarm
system, do not exist as actual software modules, and only appear as names given to the
two groups of lower level components.
the same Controlled access system software, but this time it is represented as a
hierarchical chart. Here, each component in the diagram represents a real software
component.

The System executive main Loop component calls three other components:
Visitor identification, Door lock control and Alarm activation: The Visitor identification
component calls two components: Illegal access identification and Access file manager.

Just like any other large complex task, the development of a software project is more
easily managed with the divide and conquer approach.

Stepwise refinement, when applied to a software project, produces all the low level work
tasks and includes
– development tasks
– managerial tasks
– support tasks and
administrative tasks

The WBS list of project tasks is derived from the project's statement of work (the SOW)
that defines the scope of the project. The SOW is usually prepared before the official
launching of the project, and is often part of the project contract between the customer
and the developer.

For internal projects, when an organization is funding its own development work, the
SOW becomes synonymous with the Project definition specification or a similar
document that defines the scope of work for the software project manager.

b) Functional Decomposition

The functional decomposition of a software project is a division of the system into its
operational components as they are seen by the user. Functional decomposition is part of
the requirements phase of a project. The objective of this phase is to define air the
characteristics of the system from the user's perspective. Let us consider an automatic
bank teller system. The ability to communicate online
between the remote automatic tellers and the bank's central computer in order to provide
updated account information is a functional characteristic or the system. This will usually
be defined during the requirements phase of the development cycle. However, the method
of transmission between the automatic teller and the central computer is not a functional
characteristic of the system, as this is internal to the design and implementation of the
system and is not apparent to the user.
The method of transmission, including the communications protocol, will usually be
defined during the design phase of the development of the system.
an example of the functional decomposition of an automatic bank teller system into lower
levels of functional components. we have determined that there will be a customer data
base, which could be viewed as a design decision. This is unavoidable. The functional
decomposition is rarely completely devoid of all design considerations. As we will see,
the functional decomposition is often a starting point for the initial design of the system.

Automatic teller system - functional decomposition diagram

Just as the requirements phase precedes the design phase, so the functional
decomposition of a software system will usually precede the design decomposition.
The functional decomposition will often provide much of the information necessary for
the subsequent division of the system into the implementation components.

In fact, the functional decomposition is often a good place to start when designing a
software system, as the major functional components of a system will often correspond to
the initial division of the system into subsystems or high level components.
c) Design Decomposition
The design decomposition of a software system is a division of the system into lower
level components that coincide with the actual software components of the system. In a
full design decomposition of a software system, the lowest components correspond to
programming modules (usually procedures, subroutines or program functions).
The work breakdown structure (WBS) is the decomposition of a software project into low
level work tasks.
An important point to remember is that in design decomposition, only the lower level
components are actually implemented. Higher level components represent a group of
lower level components.
Design decomposition basically produces two types of system component:
• high level components and
• low level modules
Different software development standards use different terminology to identify the
various levels of decomposition.
Figure 4 presents an example of the design decomposition of an automatic bank teller
system into lower levels of design components. On the third level, the Automatic teller
component decomposes into the Hardware interfaces, and the
Teller logic. The next level may then decompose the Hardware interfaces into the
Keyboard driver, the Display driver, the Printer, driver and the Beeper. At this level,
these drivers may represent actual software modules.

Figure 4: Automatic teller system -design decomposition diagram

A fully decomposed system, with all its low level components, is not always easy to
grasp. This is especially true during the presentation of the system at a project review,
when the system needs to be quickly understood by people who have not
been involved in its design.

On such occasions, the stepwise refinement technique is a convenient method for

gradually presenting progressive detail by initially showing the first decomposition level,
and then slowly revealing subsequent levels. This is demonstrated in figure 5.

At a convenient intermediate decomposition step we can divide the design in two: the
upper levels and the lower levels. This is used particularly when the design phase is
implemented in two distinct stages: top level design and detailed design.
Initial top level decomposition
Intermediate level decomposition – top level design
Low level decomposition – detailed design
d) Develop Project Tasks
WBS tasks are developed by asking, “What tasks need to be done to accomplish the
project objective?” The choice of WBS structure is subjective and reflects the preferences
and judgment of the project manager.

As levels of the WBS become lower, the scope, complexity, and cost of each subtask
become smaller. The lowest level tasks, or work packages, are independent, manageable
units that are planned, budgeted, scheduled, and controlled on their own.
As efforts of similar scope and type are planned, the basic WBS tasks remain fairly
similar, but each project requires a specific set of tasks that address the uniqueness of the
project's requirements. Certain top level elements, such as project management, are
included in the WBS of every project, regardless of its type, size, or complexity. Other
items, like installation, may not apply to every project. The initially developed WBS
evolves over the course of the planning. It is highly probable that it will look quite
different as the scheduling, estimation, and resource allocation portions of the plan are
completed.
One of the difficult parts of talking about IT projects generically is the wide range of such
projects. Typically, in a small project, there is a single project development phase.
In large or complex systems, however, there are often multiple development phases,
where different functional requirements are met.
Sometimes these phases are driven by the need to achieve certain levels of functionality
prior to the availability of the complete system. Other times, the phases are defined to
partition the development effort and to reduce the risks associated with larger project
efforts.

e) Define Project Development Phases

For large systems, the decomposition of the system into smaller components needs to be
done early in the planning cycle.
The rationale for the decomposition must be known, otherwise, different results derived
from different reasons for the system decomposition may occur.
For example, if a phase is defined to accommodate user needs, the phase may cross
multiple functional areas of the system. If, on the other hand, a system is divided into
phases simply to reduce risk, a functional division might occur where the phases
represent completion of entire functional areas of the system. The way in which the
phases are handled, differs with each application. Often, phases are handled as top level
WBS elements, with tasks associated with each phase defined.

f) Define Task Relationships

If a project is broken down into phases, be sure that the WBS reflects this. The WBS
structure denotes a hierarchy of task relationship. Subtask completion eventually rolls up
into task completion, which ultimately results in project completion.

There can, however, also be relationships between tasks that are not within the outlined
hierarchy. These relationships need to be noted, and the ultimate structuring of the tasks
optimized to favor a minimum of horizontal dependencies and relationships. If the tasks
are not organized efficiently, it becomes difficult to schedule and allocate resources to the
tasks.
The project scope of work is an iterative process that is generally done by the project
team with the use of a Work Breakdown Structure (WBS), allowing the team to capture
and then decompose all of the work of the project.

A WBS is a deliverable-oriented grouping of project components that organizes and

defines the total scope of the project; work not in the WBS is outside the
scope of the project. As with the scope statement, the WBS is often used to develop or
confirm a common understanding of project scope. Each descending level represents an
increasingly detailed description of the project deliverables.
A WBS is normally presented in chart form, however, the WBS should not be confused
with the method of presentation—drawing an unstructured activity list
in chart form does not make it a WBS.

g) Defining Deliverables
Deliverables associated with each task are shown in the WBS and are reflected in the
Deliverables portion of the Project Plan. A sample of a Deliverables template is shown
next. All deliverables are listed as they are identified.
As the schedule is completed, the due date is filled in, and responsibility for the
deliverable is assigned as it is known (typically when the organization chart is defined).
The date delivered is a field that is filled in as deliveries are made.
Over the course of the project, a comparison of the due date and the date delivered
provides a metric for how well deliverable dates are met by the project team.
While the deliverables list is a compilation of information identified in the WBS and the
project schedule, it is useful to maintain a separate list since deliverable completion can
be a key metric of project progress. Separate tracking of deliverables can help keep a
project on track. It also serves as a useful communication tool with both stakeholders and
the project team.
Product Name
Due Date
Date Delivered
Author/ POC
Requirement Specification 4/1/96 4/1/96 ABC
Design Specification 8/1/96 XYZ
Test Plan 8/1/96 DEF
Implementation Plan 11/1/96 …
Source Code 12/1/96 …
Test Report 1/30/97 …

h) Creating a Work Breakdown Structure

A project can be compared to a large system. A large system consists of multiple,
independent subsystems that achieve a common goal. Similarly, a project consists of
small, independent tasks. Each task can be subdivided into sub tasks. For example, in a
general software project, a task is to perform project analysis. You may also consider
studying the organizational objectives and preparing a project proposal to present to the
client.
Therefore, in a project analysis task, there are three subtasks. A subtask is also known as
a work package. A work package is a unit-level entity in a project system.
You can create a WBS by following the three steps listed below. These are general steps,
and they can vary in relation to an individual or an organization.
a) Brainstorm to arrive at board tasks for a project
b) Refine the board tasks
c) Categorize tasks into logical task headers

a) Brainstorming to Arrive at Broad Tasks

The first step in creating a WBS is to organize a meeting of all senior managers, system
analysts, and prospective developers. The objective of the meeting is to brainstorm and
come up with a set of broad tasks that need to be performed in a project. During the
brainstorming session, you can make a note of all possible tasks.
Subsequently, the feasibility of each task is assessed. In addition, any conflict of common
tasks can be eliminated. To enable you to perform this activity better, you can arrange
tasks as and when they are brainstormed.
For example, XYZ Inc. conducts a brainstorming session to divide the tasks into multiple
subtasks that are performed during the analysis phase of a project.
During the session the project managers and the analysts come up with tasks on the basis
of prior project experience. These include tasks such as determining the scope of a
project, drafting the software specifications, and securing resources for the project.
Some additional tasks are also determined based on client requirements. Preparing the
initial project budget and estimating the approximate project timeline are examples of
such tasks. In addition, personnel responsible to complete each task are also determined.
The subtasks are subsequently arranged in the order in which they are executed.
Figure 6 depicts the subtasks in the analysis phase. Note that after a questionnaire is
prepared, you can either arrange to meet the client or document the feedback collected by
the questionnaire. It is clear from the figure that preparation of the SRS document can
begin only after the preceding three tasks are complete.

Figure 6: WBS Activity

Dividing a main task into multiple subtasks also enables you to estimate the duration and
the effort required for individual tasks.
Subsequently, at the end of the phase, you can evaluate the actual effort and duration.
This helps you compare the estimated values with the actual values and prepare a
schedule for the subsequent phases.
The duration of each task affects the total duration of a phase. This, in turn, affects the
schedule of the subsequent phases. You can make similar deductions while comparing
the estimated costs with the actual costs of a task.
b) Refining Broad Tasks
Prepare a Client questionnaire.
Arrange for meetings with list
Document client feedback
Prepare a Software Requirements Specification (SRS) document.

In the second step of creating a WBS, you refine the list of tasks that was compiled
during brainstorming. Refining the tasks may include adding more tasks or combining the
existing ones. During this step, you may also change the arrangement of tasks. A change
in the arrangement of tasks can occur on the basis of two theories of WBS.

• Deliverable-based theory
• Project life-cycle-based theory
You use the deliverable-based theory when the deliverables of a project are more
important than its phases. This normally happens when the deliverables are decided
before the project begins.
However, if the phases of a project are completely defined, you use the project life-cycle-
based theory. You can use the project life-cycle-based theory to arrange the tasks in a
project.
c) Categorizing Tasks into Logical Headers
Finally, after defining tasks and arranging them, you categorize each task into a logical
task header.
For example, preparing test plans and test cases and drawing up the test plans can be
categorized as Testing.
This activity provides another chance to ensure that you have not missed any task during
brainstorming.
In addition, you can also consult an expert such as a senior manager to review and
validate the tasks identified.