Work Breakdown Structure
WBS is a hierarchical list of the work activities required to complete a project. It will include managerial,
administrative, integral, or developmental activities for:
• Doing the software development;
• Managing the project;
• Providing support for all of the project's activities; Any other activities required to meet the objectives of
the project and the customer requirements, such as the creation of documents, training programs, tools for
development, acquisitions, travel, and so on.
A product-oriented WBS contains process steps to build the product, organized around the product
components.
t drives the planning for the what and how steps, and provides the foundation for tracking of work activities,
cost, and schedule in the do it step by giving the engineer or manager a global view.
It is the "table of contents" for the work of the project. As such, it is an indispensable tool for the project
manager
Cost estimating
• To make sure that all activities get estimated;
• To make sure that each element of the estimate corresponds to a necessary activity;
• To "roll up" costs of individual elements into total costs for subelements and for the system as a whole
Work Breakdown Structure
Cost accounting
• To assign work and "charge it" to appropriate cost centers based on specific WBS elements;
• To determine the actual cost of each elementSchedule performance To monitor which activities are
complete; To measure project progress
Schedule performance
• To monitor which activities are complete;
• To measure project progress
WBS Relationship to Cost Control
Work Breakdown Structure
The tree view is most useful for high-level breakdowns of the work in the why and what steps of the project
process framework. Sample Work Breakdown Structure Shown as an Indented List
Work Breakdown Structure
A WBS may be created for the two most common views of the project:
• A product view depicting hierarchical relationships among product elements (routines, modules,
subsystems, etc.). But don't confuse this with a bill of materials.
• A project view depicting hierarchical relationships among work activities (process elements). This is often
divided along organizational lines.
Approaches to Building a WBS
A WBS can be organized in many ways, but it is usually best to arrange the activities around major work
products and customer deliverables that will satisfy the customer's requirements. We make a distinction
here between work products (anything tangible produced by the project, such as the charter, SOW, SPMP,
SRS, SDD, code, test suites, etc.) and deliverables (work products that the customer cares about, executable
code modules, documentation, etc.)divided along organizational lines
The hierarchical "tree" of information is:
• the compiler.
• the basic parts of the compiler.
• he steps of the development process to build the basic parts of the compiler
Approaches to Building a WBS
Build a WBS Top-Down or Bottom-Up
Building a WBS for Software
Building a WBS for Software
The WBS is the key work product needed to do software project estimating. In many projects, what hurts you
the most are not the things that you estimate poorly,
but the things that you forget to include at all. In preparation for sizing the work to be done follow the process
in this section as a framework for estimating. As stated earlier, there is a top-down and a bottom-up approach
to building any WBS. In planning any project, follow
the simple rule:
• If an item is too complicated to manage,
• it becomes a list of simpler items.
There are five steps to constructing a WBS for a software
project:
1. Identify the work concerning the software product (separate from
hardware and work processes).
Find any higher system WBS (separate the software from other systems and
components).
Building a WBS for Software
Determine the software WBS architecture (how to organize this software
product and project).
Populate the software WBS architecture (identify all the parts and activities
to produce them).
Determine cost categories for software (prepare for estimation activities)
Identify the Work Concerning Software
Many possible source documents
might be available:
SOW (usually the best item to start with);
Specifications, concept of operation;
Requirements documents of many kinds;
Design documents;
Standards (internal and external);
Customer conversations;
Test criteria or expectations.
Building a WBS for Software
Example Higher Level WBS Showing Where Software Might Be Placed
