WBS product oriented or the return to WBS

We come back to the creation of the WBS as a master concept and tool large project. This return is motivated by a recent work experience where its development was based on a process control of extension achievement rather than focus on what is really important the products built.

The hierarchical nature of the WBS ensures that the entire statement of work accounts for the detailed technical activities and, when completed, facilitates communication between the customer and supplier on cost, schedule, resource requirements, technical information, and the progress of the work.

It is important that the WBS is comprehensive enough to represent the entire program to a level of detail sufficient to manage the size, complexity, and risk associated with the program. There should be only one WBS for each program, and it should match the WBS used for the cost estimate and schedule so that actual costs can be fed back into the estimate with a correlation between the cost estimate and schedule. A well-developed WBS is essential to the success of all acquisition programs.

Establishing a product oriented WBS is a best practice because it allows a program to track cost and schedule by defined deliverables, such as a hardware or software component. This allows a program manager to more precisely identify which components are causing cost or schedule overruns and to more effectively mitigate the root cause of the overruns.

A WBS breaks down product-oriented elements into a hierarchical structure that shows how elements relate to one another as well as to the overall end product. A 100 percent rule is followed that states that “the next level of decomposition of a WBS element (child level) must represent 100 percent of the work applicable to the next higher (parent) element.”

This is considered a best practice by many experts in cost estimating, because a product-oriented WBS following the 100 percent rule ensures that all costs for all deliverables are identified. Failing to include all work for all deliverables can lead to schedule delays and subsequent cost increases. It can also result in confusion among team members.

Since best practice is for the WBS prime mission elements to be product-oriented, the WBS should not be structured or organized at a second or third level according to any element not a product or not being in or itself a deliverable.

While functional activities are necessary for supporting a product’s development, the WBS should not be organized around them. Only products should drive the WBS, not common support activities. Moreover, the WBS dictionary should state where the functional elements fall within the products and how the statement of work elements come together to make specific products.

A WBS should be developed early to provide for a conceptual idea of program size and scope. As the program matures, so should the WBS. Like the technical baseline, the WBS should be considered a living document. Therefore, as the technical baseline becomes further defined with time, the WBS will also reflect more detail.

Standardizing the WBS is considered a best practice because it enables an organization to collect and share data among programs. Standardizing work breakdown structures results in more consistent cost estimates, allows data to be shared across organizations, and leads to more efficient program execution. WBS standardization also facilitates cost estimating relationship development and allows for common cost measures across multiple contractors and programs. Not standardizing WBSs causes extreme difficulty in comparing costs from one contractor or program to another, resulting in substantial expense to government estimating agencies when collecting and reconciling contractor cost and technical data in consistent format.

Note:

1 - GAO Cost Estimating and Assessment Guide - Best Practices for Developing and Managing Capital Program Costs, 2009 - GAO-09-3SP

2 - GAO Schedule Assessment Guide - Best Practices for project schedules, 2012 - GAO-12-12OG