One often-overlooked but key activity in project management is the work breakdown structure (WBS). To be able to deliver the goals or objectives of a project, it is imperative to have knowledge of what it takes to meet those goals. That's what the WBS does. Insufficient time spent performing this activity - or omission of it altogether - can doom a project.
Any project whose end game includes "last-minute activities" is a project in which the WBS has likely been ignored or not completed. These forgotten items will probably result in cost overruns as well as late deliveries and poor quality, because without a well-constructed WBS, tracking the project's duration, costs, and actual progress becomes a guessing game.
The WBS is sometimes confused with a Bill of Materials (BOM). The BOM describes the raw materials, subassemblies, components, and so on that are required to complete a project. Like a WBS, a BOM is hierarchical, with upper levels (systems) decomposing into subsystems and components. But that is where the similarities stop. A WBS is a hierarchical list of the activities involved as well as the deliverables that need to be produced in order to deliver a project to successful fruition.
A WBS can further be defined as the following:

• A product-oriented hierarchy composed of hardware, software, services, data, and facilities.
   
• A description of the product, or products, to be developed and/or produced; in so doing, it relates the elements of work to one another and to the end product.
   
• An expression of an "organic" hierarchy down to any level of concern.

The Department of Defense recommends three levels for this hierarchical decomposition; we recommend significantly more detail, because the result of our effort allows day-to-day management of our various products and development deliverables. Additionally, breaking down to a detail level facilitates the identification of risks associated with the project deliverables and task dependencies. (See Table 1.)
As a template, MIL-HDBK-881 is not exact for our purposes (we might, for example, add simulation activities that our organization or customer may deem necessary to ensure product quality), but it is a good place to begin. It gives us a running start and provides a checklist that will make it easier to remember all of the essential cost centers. Recognizing cost centers facilitates the identification and tracking of work not directly within the project manager's control - such as outsourced work packages.
Direct Reflection of Requirements
The WBS approach installs the voice of the customer as the driving mechanism for the scope of the work, which, in turn, drives the requirements. It does not matter if the requirements come from external sources or if they are internally derived. When requirements change, the WBS must also change, because of its nature as a functional decomposition of top-level deliverable elements. Once we have a structure that is visible, updating, re-planning, re-estimating costs, and task duration are simplified, because all of the elements are visible as well.
The WBS is important to project management styles and line management because the cost centers are derived from deliverable elements of the project (so much so that it is easy to develop templates for the WBS). The WBS concept works because products are composed of systems, which in turn are composed of subsystems and then components and so on. If we start with a top-level assembly as the first or second level, we can easily break the product down into "atomic"-level tasks.
The same approach will apply if we are dealing with other deliverables, such as internal specifications, models, failure mode and effects analyses, and the whole round of documents required by any formal quality system.
Tracking updates to the project scope or changing deliverables to meet requirements is where many projects go astray. Lack of change management or incompetent configuration control makes it difficult to compare what we have with what we expected or needed. With scrum, we derive the product backlog directly from the WBS. And the WBS is not simply an action item list; it's a formal document designed to support cost and schedule reporting as part of a contract. From the WBS, we can derive our action item lists, schedule, and budgets.
How Deep the WBS Should Go
The WBS will deconstruct as far as we need to go, so that we can put items into our planning documents - formal project management tool, spreadsheets, or action item lists. If we have an especially short planning horizon, as is used in scrum project management, then we have to have tasks that can be accomplished during that period. We call this highly detailed analysis "atomic" decomposition, because we are decomposing the higher-level tasks until further decomposition no longer adds value. When we complete this task, we will have a list of "atoms" that become part of our other planning documents.
In some cases, the "atoms" will be small enough that we can complete them within minutes. In our experience with a production testing group, this approach removed the excuse that "we didn't have time to do this work." By putting these small tasks into a management-supported list, we can drive some level of accomplishment through their completion.
Task Decomposition to "Atomic" Level
As we have indicated, "atomic" decomposition occurs when we take a WBS down to the level where task completion becomes binary - either it is done or it isn't done, eliminating the estimation of "percent complete." If we are really astute, we may even break our tasks down to the point where they have roughly equivalent durations, which allows for easy planning. The reasons for doing this are manifold:

• We provide immediate gratification, and thus reinforcement to our project team.
   
• We can roll up completed tasks into a standard project management program and get a "percentage complete" result, suitable for passing on to management.
   
• For agile project management methods, we can easily insert these low-level tasks into even the shortest sprint backlog.

We use this approach to WBS decomposition to ensure completion of all tasks. The cost center decomposition ensures that we identify dependencies and include them in our planning documents. Our goal is to remain flexible and lightweight, rather than burdening ourselves with a lumbering, uninspired approach to our task list.
Activity Sequencing
Each of the building blocks may have interactions and dependencies; for example, we must design hardware before we build hardware. The WBS provides enough information to define all required tasks - the project manager will still use a network diagram to represent task dependencies. The WBS does not put the dependencies together for you as part of the work.
However, breaking down the tasks to a sufficient level makes it possible for you to work through the dependencies more efficiently - since all of the tasks are identified in the WBS. This manipulation of the tasks happens after the WBS is produced and the activities are sequenced.
This approach has the advantage of eliminating the use of percentages to represent completion status, a technique that 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.
Time-Phased Budget
The time-phased 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 Estimates at completion
The WBS elements make up the accumulated project budget. (See Fig. 1.) When the time is beyond the WBS element, then the project is in duration overrun. The smaller the task, the quicker it is to identify when the project is in this overrun condition.
When a project has been deconstructed to a sufficient level of detail, and allows for early detection of schedule and budget slipping, it results in the cumulative project expenditure via WBS with a very high resolution. (See Fig. 2.)
WBS Does/Doesn't
There are some things a WBS does not do. For example, it doesn't:

• Clearly identify task dependencies
• Substitute for project follow-through
• Identify the project organization

The WBS does:

• Support scope identification/clarification
• Serve as a baseline for schedule generation
• Facilitate duration estimation
• Allow EVM techniques
• Facilitate responsibility and accountabilities

WBS and Recyclability
Organizations often deliver a series of similar projects (embedded, software, and so on), and they can reuse WBSs 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 the organization has conducted a good post-mortem on previous WBS documents, then it should have captured the major issues already and recorded permanent corrective actions.
A project conducted without task details runs the risk of basing its success largely on luck (the use of the "hope" method of project management). A WBS prevents these details from falling through the cracks by accounting for everything that must be done. Our next article will detail how a WBS can be used in scrum project management.

MIL-HDBK-881 recommends the following items for a WBS: Integration, assembly, test, and checkout efforts Systems engineering and program management Training: Equipment Services Facilities Data: Technical publications Engineering data Management data Support data Data depository System test and evaluation: Development test and evaluation Operational test and evaluation Mockups Test and evaluation support Test facilities Peculiar support equipment (items not currently in inventory that must be developed): Test and measurement equipment Support and handling equipment Common support equipment (items currently in inventory): Test and measurement equipment Support and handling equipment Operational and site activation: System assembly, installation, and activation Checkout on site Contractor technical support Site construction Site/ship/vehicle conversion (obviously military and defined as what must be done to accommodate the product; on the civilian side, we would look for opportunities for reuse) Industrial facilities: Construction/conversion/expansion Equipment acquisition or modernization Maintenance (industrial facilities) Initial spares and repair parts

Kim Pries and Jon Quigley are principals with Value Transformation, LLC, a product development training and cost improvement firm. They have written two books for Taylor and Francis (www.taylorandfrancis.com) to be published in 2010 - one on scrum project management and the other on product testing. Contact them at kim.pries@valuetransform.com and jon.quigley@valuetransform.com, respectively.