Complex projects consist of numerous smaller, interrelated tasks and work elements. As the rhyme at the beginning of the chapter alludes, the goal or end-item of a project is a system that can be broken down into subsystems, which themselves can be bro- ken down, and so on. The procedure for dividing the overall project into subelements is called the work breakdown structure or WBS. The purpose of a WBS is to divide the total project into small pieces, sometimes called work packages. Dividing the project into work packages makes it possible to prepare project schedules and cost estimates and to assign management and task responsibility.
The first step in creating a WBS is to divide the total project into major work cate- gories. These major categories then are divided into subcategories which, in turn, are subdivided, and so on. This level-by-level breakdown continues so that the scope and complexity of work elements is reduced with each level of breakdown. The resulting WBS is analogous to a product structure diagram.
The objective of the analysis is to reduce the project into work elements that are so clearly defined that they, individually, can be thoroughly and accurately defined, budgeted, scheduled, and controlled. The WBS approach helps ensure that, for all ele- ments, even minor ones, an accounting is made.
A typical WBS might consist of the following five levels (in actuality the number of levels varies; the name of the element description at each level is arbitrary):
Level Element Description
1 Project 2 Category 3 Subcategory 4 Sub-subcategory 5 Work package
Level 1 represents the total project. At Level 2 the project is broken down into sev- eral (usually between 4 and 10) major categories of work. These categories usually conform to the work areas specified in the scope statement. All of the categories’ ef- forts, when taken together, must make up the total project effort. Each category, in turn, is broken down into subcategories, the sum of which must comprise the effort of the category. At the lowest level, whatever numbered level that might be, is a work pack- age. Figure 6-1 shows the typical hierarchical structure of a WBS.
01 Project 1 01-02 Category 01-01 Category 2 01-01-100 Task 3 01-01-101 Subtask 4 etc. 5 Work package 01-01-102 Work package Work package 01-06-7011 01-06-7012 . . . 01-06-701 Subtask 01-06-200 Task Work package 01-06-100 etc. etc. 01-06 Category 01-06-700 Task Level etc. Figure 6-1
Elements of a work breakdown structure.
Figure 6-2 illustrates the WBS for building a house. The top part of Figure 6-2 shows the project objective (Level 1) and the major categories of items (Level 2) nec- essary to accomplish it. Notice that, for the most part, the items in the breakdown are hardware- or product-oriented. This makes it easier to assign specific responsibilities and to hold people accountable for specific units of work with expected performance, cost, and schedule requirements. As will be demonstrated later, use of a thorough, product- oriented WBS facilitates project scheduling and budgeting.
In contrast to the top WBS in Figure 6-2, the WBS in the middle is less desirable, be- cause it is functionally-oriented. Thus, associated with each function (e.g., carpentry), are numerous products (such as cabinets, walls, floors, trim, doors, stairs, and win- dows), all of which require work that must eventually be scheduled at various times in the project. Therefore, planning for the project would necessitate the eventual breakdown of these functions into products anyway.
There are, however, a few places in the WBS where a task-oriented breakdown might be necessary or desirable. This is the case for tasks such as “design,” “engi- neering,” or “management,” that are common to more than one element in the WBS or involve integrating elements in the WBS into the total system.
Continuing with the example in Figure 6-2, Level 2 items would be further elabo- rated into a work breakdown at Level 3 (shown at the bottom of Figure 6-2), and each of these items would be further broken down as necessary at Level 4, and so on. Con- current with the development of the WBS is the process of work definition. As each ele- ment of the WBS is identified and broken down, project work is further elaborated and more clearly specified. By the time the WBS is completed, all work on the project has been completely defined.
During the WBS process, the questions “What else is needed?” and “What’s next?” are constantly being asked. The WBS is reviewed again and again to make sure everything is there. Supplementary or missed items are identified and added to the structure at appropriate levels. For example, nowhere in the WBS in Figure 6-2 are blueprints, budgets, and work schedules indicated, even though construction cannot begin without them. These are items associated with the planning phase of the proj-
Figure 6-2
Example of WBS for building a house.
ect which must be completed prior to construction. They could be included in the WBS by expanding Level 2 and inserting categories for “design” and “administration and management,” then by putting “architectural and engineering blueprints” at Level 3 under “design” and “budget and work schedules” at Level 3 under “admin- istration and management.” It might also be necessary to expand Level 2 so that other considerations like site location and building maintenance could be included.
Another example is shown in Figure 6-3. This breakdown subdivides the project according to categories of major system assemblies, then divides the assemblies into subassemblies. Each subassembly would be assigned to a functional work group which would then do a work breakdown to elaborate the items and tasks to produce that subassembly.
The WBS should be checked by the various project participants to ensure that nothing was missed. In cases such as building a house where the work is pretty stan- dardized, the likelihood of overlooking something is remote. However, the larger and less standardized the project, the easier it is to miss something and the more valuable
Figure 6-3
Typical WBS based upon primary hardware. [Courtesy, Metier Management Systems.]
the WBS becomes. Nothing must be overlooked. Training, documentation, and pro- ject management activities should all be included.
Example 2: Process of Developing the WBS for the LOGON Project.
The project manager and project staff meet in a brainstorming session to create the WBS for LOGON. Initially they “rough out” the major categories of work ac- cording to the scope statement (Example 1) and identify the responsible functional areas. This is the Level 2 breakdown. The project manager then meets with mana- gers from the functional areas identified for approval of the Level 2 breakdown. The functional managers then work with planners and supervisors in their areas to prepare a Level 3 breakdown. Supervisors then prepare a Level 4 breakdown.
The result is shown in Figure 6-4. Level 2 divides the project into the major work elements of basic design, Hardware Part A, fabrication, and so on. At Level 3, Hardware Part A is subdivided into design and drawings. These become the work packages for Hardware Part A because they are the lowest elements in that part of the structure. The resulting WBS is reviewed for final approval by the proj- ect manager, functional managers, and supervisors.
To help keep track of project activities, each category, task, and so on should be coded with a unique number. Usually the number at each level is based on the next higher level. For example in Figure 6-1, the six categories in Project “01” were numbered 01–01 through 01–06. Then, for example, in the last category, 01–06, the seven tasks were numbered 01–06–100 through 01–06–700, and so on. The coding scheme is established by managers during development of the WBS. The scheme must be accepted by every- one as being neither “too broad” nor “too detailed.” The kind of numbering system varies depending on the control scheme used. It should be emphasized, however, that of paramount importance is the correct partitioning of WBS elements, not the number- ing scheme. The numbering scheme shown in Figure 6-3 is another example.
As mentioned, the WBS should be product-, hardware-, or task-, but not functionally-oriented. This means that elements on the WBS should correspond to sub- systems or components (hardware or software) of the end-item system, or to work tasks (assembly, test, delivery, etc.), but not to functional departments such as person- nel, finance, engineering, and so forth. Generally there is little or no correspondence between divisions and levels in the WBS and the functional hierarchy of organizations.
LOGON Contract 1 Fabrication 2 Procurement Hardware Part B Basic design (H) Site operations Project management Project management Software specifications (L) Part A Part B Final installation (Y) Drawings (P) Test (Z) Part A Software Assembly (V) Test (X) Purchase (Q) Delivery (T) Assembly (U) Test (W) Purchase (M) Delivery (R) Purchase (N) Delivery (S) Design (I) Design (J) Drawings (O) Hardware Part A 3 4 Level Drawings (K) Part B Figure 6-4
Work breakdown structure for the LOGON project. Work packages are lettered H through Z.
How far down does the breakdown structure go? As far as is needed to com- pletely define a work task. Sometimes a Level 2 breakdown will be adequate, though usually a Level 3 or higher level breakdown will be necessary. For a task to be well- defined it must have the following properties:
1. Clear, comprehensive statement of work: The task is well-enough defined so the performing parties know exactly what must be done.
2. Resource requirements: The labor, skills, equipment, facilities, and materials for the task are identified.
3. Time: The time necessary to perform the task is estimated.
4. Cost: The costs for the required resources, management, and related expenses for the task are estimated.
5. Responsibility: The parties, individuals, or job titles responsible for performing the task and approving it are identified.
6. Outcomes: The deliverables, end-items, or results and associated requirements and specifications for the task are identified.
7. Inputs: The preconditions or predecessors necessary to begin the task are identified. 8. Quality Assurance: The entry, process, and exit conditions to which the task must
conform are identified; these are specified in the quality plan (see Chapter 5). 9. Other: Additional information is specified as necessary.
If any of the properties listed cannot be defined, then the task is too broad and must be broken down further. In most cases, all of the properties can be eventually determined by breaking tasks down into small-enough pieces. A well-defined piece, which, by definition includes the previously listed features, constitutes a work pack- age. The features are summarized in Figure 6-5.
On the other hand, the breakdown must not continue so far that it unnecessar- ily encumbers the system. Too much breakdown will actually increase the amount of time needed to do the project. A large number of individual tasks require greater time and cost to manage than a few tasks. Each work package is the focal point of man- agement planning and control and, as such, requires paperwork, time, and cost to monitor. Notice that different “branches” on the WBS do not necessarily have the same number of levels; this is because each branch is developed separately.
Companies that specialize in and routinely perform projects that are similar will have roughly the same Level 2 or Level 3 breakdown for every project. In such cases, they can create a work-breakdown “template,” which is a standardized WBS for par- ticular kinds of projects. The template is created from experience acquired with many projects, where areas of work common among all of them are recognized. A template simplifies the work-breakdown process and serves as a checklist for the important ar- eas of work. Nonetheless, at some level every project becomes unique, and a WBS for a new project should never be a mere copy of the WBS nor a template for a previous project. No matter how similar projects might seem, adequate care and scrutiny should go into preparing each WBS to identify important differences. Even with a template, uniquely defining the work packages at Levels 3, 4, or greater will be necessary. To re- duce oversights, two or more WBSs can be prepared independently, then combined.