The WBS provides a common framework for planning and controlling the work to be performed. It provides a common, ordered framework for summarizing information and for quantitative and narrative reporting to customers and management. The WBS uses a hierarchical breakdown of project deliverables. This breakdown is intended to provide more
manageable pieces of work and a framework for overall operation and control of the project.
Critical chain project management texts suggest using a TOC tool, the PRT (see Figure 11.5 for an example), to create the WBS [3]. The idea is to start with the end item or an intermediate objective and ask the team,
“What obstacles prevent us from achieving this objective?” Once you have the list of obstacles, ask the team to state conditions that would overcome the obstacles. Then link those conditions in a logical sequence.
This method ensures a coherent strategy and synchronized tactics to overcome the obstacles identified by the team. For very large projects, you could create layers of PRTs, corresponding to layers in the WBS.
Unfortunately, the simplified method for creating the PRT described by Goldratt in It’s Not Luck [3] is not appropriate to generate a project WBS.
The reason is that the PRT only ensures that certain necessary conditions are met, those necessary to overcome the obstacles that the team identi- fies. The method does not ensure inclusion of all deliverables sufficient to deliver the project result. Dettmer describes a modified method to ensure both necessity and sufficiency [4].
Kerzner provides the following criteria for a WBS: “The project man- ager must structure the work into small elements that are manageable, in that specific authority and responsibility can be assigned; independent or with minimum interfacing with and dependence on other ongoing elements; integratable, so the total package can be seen; and measurable, in terms of progress” [5].
A properly prepared WBS should facilitate the following:
◗ Ensuring better understanding of the work;
◗ Planning of all work;
◗ Identifying end products and deliverables;
◗ Defining work in successively greater detail;
◗ Relating end items to objectives;
◗ Assigning responsibility for all work;
◗ Estimating costs and schedules;
◗ Planning and allocating company resources;
◗ Integration of scope, schedule, and cost;
◗ Monitoring cost, schedule, and technical performance;
◗ Summarizing information for management and reporting provid- ing traceability to lower levels of detail;
◗ Controlling changes.
The WBS usually has levels assigned, for example:
Level 1: Total program
Level 2: Summary cost accounts A
Level n – l: Work package Level n: Activity
In some cases, these terms have different meanings. In particular, in many cases the work package is the lowest level of work assignment, restricted to one resource provider per work package.
The WBS also has a numbering system that provides a unique number to every piece of work defined. The numbers usually follow the hierarchy of the levels, with the lowest level corresponding to a charge number for collection of cost.
Project managers use different approaches to subdivide a total project into a WBS. The most preferred is a product-oriented WBS (as shown later, in Table 5.1), in which each work package produces a definable, measurable output. The collection upward then may follow functional lines or, for major pieces of hardware (including facilities), subsystems and systems.
The most important aspect of the WBS is that it be comprehensive.
Because it is the basis for all planning and cost estimating, nothing should be left out. Also, if the project funding decision is going to be based on cost, it is imperative that the WBS not be redundant. That is, each activity should appear in only one work package.
Many companies use templates to create WBSs for similar projects, which can be a useful resource to get started. However, templates share a major shortcoming with other checklists in that they tend to provide a degree of comfort and sometimes stifle thinking beyond the items in the checklist. The project manager has to be vigilant not to allow templates to
constrain the thinking to ensure that all required work is covered in the WBS.
Sometimes clients (especially government clients) will dictate a WBS structure, usually because they have a need to compare across projects by different contractors or for different types of purchases. That is a legiti- mate client need and must be honored. The project manager still must ensure that all project work is covered, that there are no redundancies, and that responsibility assignments are unique and appropriate.
Do not confuse the WBS with the project or company organization structure. Although work may align with the organization, it does not have to. The only requirement is that at the lowest level, one individual has clear responsibility and authority for the work performed. More important, the WBS must define the deliverables for the project, not the functions necessary to deliver the scope.
There are many opinions on how to organize a company for project management. Because most project managers do not have the luxury to redesign the company for their project, we will not address the overall company organization. Project managers usually do have the flexibility and authority to design their WBS, select their project management team, and assign responsibility and authority.
Following Dr. Deming’s idea to use the overall process flow for a company as an organizing principle, an alternative we recommend is that the project team be organized around the WBS. Another alternative is to place someone responsible for the critical chain and for each of the CCFBs. Since it is unlikely that the WBS was organized that way, the project management team may cross-cut the responsibilities of the work package managers. That places the project management team responsi- bility on the connections between work packages and activities, the most vulnerable part of a project.