Home Planning Scope Work Breakdown Structure
US FTC Compliance
Yes, all these ads are some kind of affiliate link and I get paid a commission if you click or buy.
Not enough to quit my day job, but it keeps the site alive.
- Jeb Riordan, Editor, PROJECTmagazine
Work Breakdown Structure Print

The building blocks of sound project management

Thesis

The Work Breakdown Structure (WBS) is fundamental to project execution. When we expend insufficient time and develop inadequate detail on the WBS, the project will yield poor results and we can expect to see last minute identification of critical elements. Not only do some essential items occur late in the process, but we can also expect to see cost over-runs, schedule over-runs, poor quality at delivery, and erosion of project tracking ability—where we do not know where we are at any given time because our road map is defective (or missing).

The WBS should not to be confused with other structured lists; for example items such as product material breakdowns and bills of materials. A WBS may resemble a BOM in that it is hierarchical; that is, systems decompose into subsystems and subsystems into components.

 

General description

The first step in generating a WBS is to divide the program/project into cost centers. This ‘cost center’ terminology comes from the U.S. Department of Defense, because a government agency like DoD does not have profit centers per se.

A WBS should be created as early as feasible during program/project development. Each cost center’s delivery will be broken down into manageable portions of work to ease planning and improve control of cost, schedule and technical content as well as quality. The WBS can be developed for each project phase or for the entire project or program. It is more common to build one for the entire project so that costing is consistent across the duration of the project. It identifies the total work to be performed and divides the work into manageable elements, with increasing levels of detail.

work breakdown structure

Figure 1 Work Breakdown Structure

Scope

It can not be overstated, that to generate an adequate level of WBS, the scope of the delivery must be clear. Included in the scope are all activities and products the project is required to deliver. These include documentation, aftermarket support, training and a myriad of other items. Each area has a set of tasks and each task can be broken down to the smallest monitor-able quantum of execution. Without a competent WBS, unaccounted for tasks (but clearly predictable tasks) are lost and usually, to everybody’s surprise, are found at the end of the project, often delaying timely closure of the project.

SCOPE and Statement of Work (SOW)

Scope is often identified or constrained in a SOW. The SOW establishes the boundaries and activities of the project and spells out in substantial detail the work that is to be done, including all required standards listed (including the quality level expected) and work products, which are defined to include process support (for example, configuration management and project management).

WBS and Recyclability

Organizations often deliver similar projects (embedded, software etc) and they can reuse any WBS from previous projects as a starting point for the new project. On the downside, there is a risk of recycling earlier problems and not accounting for changes since the last use of the WBS. If we conducted a good post-mortem on previous WBS documents, then we should have already captured the major issues and recorded permanent corrective actions.

Generating the WBS

We can solicit expert opinion, follow industry practices, or borrow from standards and regulations. In some cases, the enterprise will have established processes. We also want to capture team member perspectives as well as identified risks which may have an impact on the WBS; that is; we will instigate mitigating actions such as outsourcing, parallel, and duplication of activities.  Outsourced activities will require WBS elements from the supplying and customer organizations.

Creating the hierarchy of tasks

Top level tasks represent areas of costing interest (for example, software development). The decomposition of tasks will follow the way in which the tasks are assembled or go together functionally once we have defined the top level cost centers.
Here is a military example (MIL-STD-881B) for electronics development:

  • Prime Mission Product (PMP)
    • Subsystem 1..n
    • PMP Applications Software
    • PMP System Software
    • Integration, Assembly, Test and Checkout
  • Platform Integration
  • Systems Engineering/Program Management
  • System Test and Evaluation
    • Development Test and Evaluation
    • Operational Test and Evaluation
    • Mock-ups
    • Test and Evaluation Support
    • Test Facilities
  • Training
    • Equipment
    • Services
    • Facilities
  • Data
    • Technical Publications
    • Engineering Data
    • Management Data
    • Support Data
    • Data Depository
  • Peculiar Support Equipment (note: customized equipment)
    • Test and Measurement Equipment
    • Support and Handling Equipment
  • Common Support Equipment
    • Test and Measurement Equipment
    • Support and Handling Equipment
  • Operational/Site Activation
    • System Assembly, Installation and Checkout on Site
    • Contractor Technical Support
    • Site Construction
    • Site/Ship/Vehicle Conversion
  • Industrial facilities
    • Construction/Conversion/Expansion
    • Equipment Acquisition or Modernization
    • Maintenance (Industrial Facilities)
  • Initial Spares and Repair Parts

Note how the breakdown is logical and accounts for the complete project. MIL-STD-881 provides templates for major programs/projects to provide a good start to new programs.
The sub-tasks have progressively smaller durations and are the constituent tasks of upper level tasks.

Activity Sequencing

Each of the building blocks may have interactions and dependencies; for example, we must design hardware before we build hardware. The WBS structure allows for manipulation of the tasks to work through dependencies and risk. The WBS provides enough information to define all required tasks—the project manager will still use a network diagram to represent task dependencies.

Duration Estimates

The smallest size WBS elements have a reasonable chance at accurate estimation due to their small size. The status can be binary (complete, incomplete). This approach has the advantage of eliminating the use of percentages to represent completion status, a technique which our experience shows to be overly optimistic. The small-element approach also makes for easier deployment of estimating techniques such as Program Evaluation and Review Technique (PERT) and Monte Carlo simulation.

wbs pert chart
 
Figure 2 PERT

Time phased budget

The time-phase budget will include the schedule and cost (usually in hours). This approach is necessary for Earned Value Management (EVM), which includes the following metrics:
Schedule Performance Index
Cost Performance Index
Cost Variance
Schedule Variance
Estimated budget to complete
As well as estimates at completion

The graphic below illustrates the accumulated budget for the project. The WBS elements make up the project budget.  When the time (t) is beyond the WBS element, then the project is in duration overrun.  


wbs phased budget

 
Figure 3 WBS and Time Phased Budget large resolution

The smaller the task, the quicker it is to identify when the project is in this overrun condition. The graphic below illustrates the cumulative project expenditure via WBS with a very high resolution. This only happens when the project has been deconstructed to a sufficient level of detail, and allowing for early detection of schedule and budget slipping.

wbs time phased detail

Figure 4 Time phased budget detailed resolution

Scope control

The WBS helps to simplify and empower scope control for the project manager. The rules are simple:

•    Changes to scope change WBS
•    Changes to product have an impact on the WBS
•    Changes to project have an impact on the WBS
•    Unaccounted for changes (not included in WBS) will not get lost, especially in costing because they require an explicit update of the WBS

These rules imply that any change to the WBS is a reflection of change in the project, which is precisely what must be done in order to make the WBS a living document and a useful tool.

Task Identification

Task identification is accomplished through a format know as the WBS dictionary, which—as dictionaries do—defines the meaning and properties of each element of the WBS. Of course, the task must be known beforehand so we can identify expectations, attributes and quality levels for the task.  We must also identify resources and processes required to generate the specific WBS element.

Quality Assurance

Tasks and descriptions of those tasks are used to generate quality assurance activities such as reviews, tests, and inspections. We can also perform a comparison of actual deliverables to the task quality description as a form of auditing—this action is often performed by some person or entity not delivering the task.

Task Sequencing

To properly identify sequencing, we must understand task dependencies. Additionally, tasks will relate to each other in the form of:
•    Start-Finish
•    Finish-Finish
•    Finish-Start
•    Start-Start
We can sometimes shuffle tasks in order to manage risks and improve on the schedule delivery date. If the shuffling is very complicated, we may need software support in the form of capacity resource planning or critical chain software.

How far do we break it down?

Based on experience, we suggest that hierarchical task sets should be broken down to the ‘atomic’ level which is the point at which breaking the element down any further makes no sense or becomes silly. This approach helps when using binary reporting (complete, incomplete). Project management software can calculate percentages for upper management based on the roll-up of the binary status of each task. More importantly, it is easy to detect when the project is executing outside of the expected rate of task closure.

WBS and Responsibility

We assigned WBS elements (tasks) by identifying the responsibility for each delivery/deliverable. We can do this by using a resource allocation matrix, which represents responsibilities and deliverables graphically by matching work with organization breakdown structure (OBS) shown at right angles to the tree/table that represents the WBS.

Organizational Breakdown Structure (OBS)

An OBS is a similar tree structure to the WBS—effectively an organizational chart of human resources available to the cost centers of the WBS. We use cross-mapping with the WBS to provide a responsibility matrix.

The WBS and Work Packages

Work packages are WBS elements. They can be a sub-task or a collection of related tasks. In some cases, the tool helps us to outsource another company’s internal work group. Since the WBS requires substantial definition of each element, the requirements are unequivocally known.

The WBS and outsourcing

Contract work can be outsourced initially with an SOW. Afterwards, we follow up with identification of the WBS for the outsourced activity; we derive this new WBS from the upper level project WBS. The tool helps to provide points for status updates and control. The WBS fine resolution allows quick determination about when things don’t go according to plan and allows for initiation of previously considered risk mitigation activities (we did consider contingency plans already, right?).

WBS provides a baseline

The WBS gives us a baseline of activities to achieve the project targets. As we noted already changes to project targets or scope additions have an impact on the WBS. Each change can be reviewed for impact by comparing the original WBS to changes required, again providing for a high level of project control.

WBS does / doesn’t

There are some things the WBS can and cannot do. For example, it doesn’t:
Clearly Identify task Dependencies
Substitute for project follow-through
Identify the project organization

The WBS does:

Supports scope identification / clarification
Serves as a baseline for schedule generation
Facilitates duration estimation
Allows Earned Value Management techniques
Facilitates responsibility and accountabilities

Conclusion

Without task details for the project, success is largely luck and often improbable (the use of the ‘hope’ method of project management). Additionally, the WBS prevents ‘falling through the cracks’ by accounting for everything that must be done.

 

About the Authors

project managementKim H Pries APICS: CPIM: ASQ: CQA, CQE, CSSBB, CRE is responsible for all test and evaluation activities and automated test equipment at Stonebridge Electronics-North America. He holds a masters degree and presently teaches the ASQ Six Sigma Black Belt Certification. Kim has written Six Sigma for the Next Millennium A CSSBB Guidebook published by American Society of Quality Publications and co-authored with Jon Quigley the book titled, Project Management of Complex and Embedded Systems: Ensuring Product Integrity and Program Quality, published by Auerbach Publications.

Project Management of Complex and Embedded Systems: Ensuring Product Integrity and Program Quality

 

 

 

project managementJon Quigley MBA, M.Sc.PM, PMP, is Manager of Electrical / Electronic Systems and Verification group for Volvo 3P - Product Development North America. He holds two Masters Degrees and is a certified PMP.
Jon has secured four US patents and in 2005 was part of the team that was awarded the prestigious Volvo-3P Technical Award in 2005 going on to win the 2006 Volvo Technology Award in 2006.

Six Sigma for the Next Millennium: A CSSBB Guidebook

Share/Save/Bookmark
Comments (1)Add Comment
...
written by emun, November 02, 2009
i love you...muahsss

Write comment
bold italicize underline strike url image quote Smile Wink Laugh Grin Angry Sad Shocked Cool Tongue Kiss Cry
smaller | bigger

busy
 
Copyright © PROJECTmagazine (c) 1998 - 2019 for practical project management information. All rights reserved.