CHAPTER 2
Work Breakdown Structure Fundamentals
The work breakdown structure (WBS) represents a logical decomposition of the work to be performed that focuses on how the product, service, or result is naturally subdivided. It is an outline of the specific work to be performed.
Development of a WBS requires knowledge of how the output or deliverable components will be assembled or integrated to form the final product as well as knowledge of the major areas of work. This knowledge is required for every type of project imaginable—reports, airplanes, buildings, electronic systems, computer programs, weddings, conferences, culture changes, or any other output product from a project. It is necessary to know about the work that is to be done or to have access to subject-matter expertise. This is why the project team and other stakeholders need to be involved in the development of the WBS. These fundamentals apply universally and are independent of the customer, industry, country, culture, or geography.
It may seem daunting at first that there is a requirement to be knowledgeable about the output product before you start the project, but your organization would not have the project if it didn’t know something about the product to begin with. For research projects, where the final product may be very unclear or indeterminate, the WBS is structured around the work to be performed—the process, not the product. For other projects—those where the final product is a service that is being performed, such as putting on a conference or wedding—the requirement is that the planner have a good understanding of the major tasks to be performed. If you are in research, you have a work plan and certain steps to be performed; based on intermediate results, the succeeding work plan may change, but the same is true of most projects.
In all cases, it is possible to find knowledgeable subject-matter experts to assist in the development of the WBS, and such experts frequently can be found within the organization.
In this chapter, different algorithms for breaking down or subdividing project work are discussed. First, however, it is necessary to state an important rule that applies to all levels of all WBSs: the 100 percent rule.
THE 100 PERCENT RULE
The 100 percent rule1 is the most important criterion in developing a WBS and in evaluating the decomposition logic. It is formulated as follows:
The next level decomposition of a WBS element (child level) must represent 100 percent of the work applicable to the next higher (parent) element. The rule can be further explained using Figure 2-1.
FIGURE 2-1 Garage Project Work Breakdown Structure
In Figure 2-1, the 100 percent rule means that the sum of the work involved in “Landscaped Grounds,” “Garage,” and “Project Management” equals 100 percent of the work to be performed in the Garage Project. There is no project activity that does not fit within one of these categories. In a top-down subdivision, most planners would automatically follow the 100 percent rule, at least to Level 2. However, the rule applies at all levels and in all types of WBSs.
At the next level, the 100 percent rule means that the work in the “Garage” element consists of work related to “Materials,” “Foundation,” “Walls,” “Roof,” and “Utilities.” That is, there is no work on the garage itself that does not fit within one of these elements. Turning back to Figure 1-6, the “Walls” element would be represented 100 percent by the “Walls and Siding,” “Windows,” “Garage Door,” “Service Door,” and “Assembly” elements at Level 4. Again, these five elements encompass all the work on the walls. Note that the “Assembly” element is necessary to account for the work of installing or integrating the work of the other independent elements. This is an important element that is frequently forgotten. The person developing the WBS must always ask if all the work is accounted for. Depending on the specific project, there could be a requirement for a “Wall Inspection” that would also be a Level 4 element.
It’s important to note that the primary reason to have a WBS is to ensure that all the work packages and activities that must be accomplished for a successful project are identified. The 100 percent rule also applies at the activity level: The work represented by the activities in each work package must add up to 100 percent of the work necessary to complete the work package. In this manner, the project manager can be reasonably assured that all the work necessary for successful completion of the project has been identified, planned, and scheduled.
The 100 percent rule is an important rule. It helps the person developing the WBS to constantly question himself or herself on the breadth and depth of his or her understanding of the project work. A recommended practice, and one that is common, is collegial development—or at least collegial review—of the WBS. Subject-matter experts will always try to ascertain that their specialty is properly included in the work, and they can contribute to making sure the WBS is complete and as accurate as possible. On manufacturing projects, for example, it is useful to elicit input from manufacturing engineers or tooling engineers for the identification of probable subassemblies. In software projects, it is useful to elicit input from systems analysts, programmers, database specialists, and the like. For our garage example, input from an experienced carpenter or garage-builder would be useful.
Not all WBSs are based on products. The types of WBSs are Product WBS, Service WBS, and Results WBS. The rule still applies: The sum of the work in the child elements must equal 100 percent of the work represented by the parent element—even if the parent element is a general term like “Systems Engineering,” “Research,” or “Meetings.”
The use of bottom-up cost estimating, that is, estimating the costs of every activity or work package and summing the data up the WBS hierarchy into a total project cost, is based on the critical assumption that the WBS is developed by following the 100 percent rule.
One of the common ways to develop a WBS is from the bottom up, and this approach is especially useful if the output product of the project is a service. All the project activities are first listed in a brainstorming session and then grouped into logical work packages or lower-level WBS elements. These are in turn summarized into higher-level elements. The 100 percent rule is followed at each level, and this question is asked at each level: “Does the sum of the work represented by the child elements equal 100 percent of the effort summarized in each parent element?” Or this question is asked: “Is any work missing?” Experience has indicated that asking these questions invariably results in additional activities being added, and several iterations of the WBS may be performed until a sound WBS is developed.
The importance of the 100 percent rule to the proper functioning of the WBS as a framework for planning cannot be overstated. If the decomposition at each level follows the 100 percent rule down to the activities, then 100 percent of the relevant activities will have been identified when it is time to prepare the project schedule. Therefore, 100 percent of the costs or resource requirements will be successfully identified in the planning phase.
ANATOMY OF A WBS
The elements that appear in the three types of WBS (Product, Service, and Results) are covered in this section.
All WBSs have two or more of the five types of Level 2 elements shown in Figure 2-2.
FIGURE 2-2 Types of Level 2 Elements
The first three types of elements are derived from the three types of projects indicated in the definition of a project in the PMBOK® Guide: “A temporary endeavor undertaken to create a unique product, service, or result.”2 For all three types of projects, there are one or more deliverables or outputs corresponding to the types of elements discussed here that are the basis for developing the WBS.
The last two types of elements in Figure 2-2 are supporting elements that are needed for a complete definition of the scope of a project (and to meet the 100 percent rule).
The five types of Level 2 elements are:
1. Product Breakdown Elements: The subdivision based on the physical structure of the product(s) being delivered is the most common basis for a WBS and the easiest WBS to develop. These projects have a tangible output product—software, a building, a dam, an airplane, a user’s manual, and so on—and all have a natural structure. Alternatively, there may be multiple products or systems delivered, which occurs in an airport ground surveillance system, a DoD unmanned aircraft vehicle system, an integrated Coast Guard deepwater ship system, or an orbiting space laboratory system.
2. Service Breakdown Elements: Service projects do not have a tangible, structured deliverable. The output is a defined body of work done for others: conference, party, wedding, vacation trip, and so on. The work breakdown is a logical collection of related work areas.
3. Results Breakdown Elements: Results projects do not have a unique, tangible, structured deliverable that is known in detail at the start of the project. The output is a consequence—a result—of a process that involves a product or an outcome: cancer research, new drug development, smoking reduction, and so on. The work breakdown is a series of accepted steps, stages, or processes. A very common and special case of the Results Breakdown type of WBS occurs in information technology (IT) programs.
4. Cross-Cutting Elements: This is a breakdown of items that cut across the product, such as architectural design, assembly, or system testing, or that are common to more than one WBS element at the same level. These elements are usually technical and supportive in nature. There may be more than one element of this characteristic at Level 2. While there is no restriction, these types of elements are rare in Service or Results projects, except for project management, as discussed later.
5. Project Management Element: This is a breakdown of the managerial responsibilities and managerial activities of the project. It includes such items as reports, plans, project reviews, and other activities of the project manager or his or her staff. (Conceptually, these are the overhead of the project.) There normally is only one of this type of WBS element, but it exists on all projects as a Level 2 element.
Product Breakdown Elements
The product breakdown element in a WBS is the decomposition of the natural, physical structure of the output product being developed. This is apparent in Figures 1-1 and 1-2, which show the elephant breakdown structure. For building a garage, one of the elements on Level 2 (the products) is “Garage,” and Level 3 elements for “Garage” could be Materials, Foundation, Walls, Roof, and Utilities, as shown in Figure 1-6. There may be more than one output product or major deliverable at Level 2. For the garage project, the “Landscaped Grounds” is also an end item or deliverable, and the project is not complete until all the plants have been planted and the ground prepared as described in the contract statement of work (SOW) or drawing. An operator’s manual may be an additional output or deliverable item if the project is a new, high-speed lawn mower. If writing a book, the physical book would be the deliverable. If you were developing software, the documented source code, the manuals, and CD-ROM with the executable program and installation software would be the deliverables.
The product breakdown element usually has more levels than the “Cross-Cutting” or “Project Management” elements. Some parts of the product breakdown element may require decomposition to a greater level than others because of the nature of the product and its components. This can be seen in the WBS for the garage, Figure 1-6. If a major component of the garage is to be subcontracted, such as the walls, it becomes a work package, the lowest level necessary in the WBS. Further decomposition of the WBS would be the responsibility of the subcontractor, and the walls could be considered a subproject. The subcontractor WBS would have the walls as level 1 and the breakdown in Figure 1-6 as the second level. In large projects, such as construction of a new athletic stadium, subcontractor WBSs may have many levels.
In product breakdown elements, work packages can be assigned to either organizations or individuals, but individual resources are assigned only at the activity level.
Service Breakdown Elements
A WBS for a project where there is no tangible product, but where the objective is a service provided for someone or for a group, has a service breakdown element, which requires a different approach to decomposition. The decomposition is based on a logical grouping of similar and related work elements, functions, or skills. For example, all the work related to lodging on a project whose objective was a vacation trip to Asia could be located under the “Lodging” element, which could be further decomposed to the city or cities where the lodging was to occur. Activities may include making reservations, getting confirmations, making deposits, getting maps or instructions, and so on. There is usually a main event or objective for this type of project, such as a wedding, a dinner party, or putting on a conference. In these types of projects, all the WBS elements except “Project Management” represent a type of service provided, performed, or arranged. This is shown in the partial WBS presented in Figure 2-3.
FIGURE 2-3 Service WBS—International Conference Project
These types of WBSs are frequently developed initially from the bottom up, starting with a list of activities and grouping them into logical categories or functions.
The basis for each Level 2 element is that it represents a logical grouping of tasks that can be discretely described. Furthermore, each element at every level lends itself to being assigned to a single person or organization for performing or coordinating the group of work described in the WBS element descriptor.
The decomposition of the Level 2 and lower elements is based on the criteria that the child elements are related to the parent, and the key word is “grouping.” For example, the breakdown of “Transportation” could be “1. Airport; 2. Hotel-Conference Shuttle; 3. Tour Buses” and so on, all of which are related to transportation. Also, note that the breakdown of “Presentations” in Level 3 includes Level 4 elements that all relate to the presentations. This is different from a Product WBS, where the next level breakdown would be parts of the “Presentation,” not just related items.
Adding elements at Level 2 also focuses attention on the function and can improve the planning. For example, in Figure 2-3, if security is a concern, it should be added at Level 2, rather than being spread at Level 3 or lower in other elements. In this manner, all aspects of security would be grouped and focused, and it is more likely that all important security tasks would be identified.
It is important to note that the 100 percent rule applies, and that the WBS needs to be analyzed for completeness at every level by the project team. Every task needs a WBS parent; in the process of brainstorming the task list, additional WBS elements may need to be added. Getting stake-holders involved in developing the WBS for a new class-of-service project is more important in a service project than in a product or results project because there is no natural structure or sequence of elements to provide a hierarchy. However, if you worked for an events management firm, you would have a template or normal hierarchy based on previous projects.
Frequently, a large number of detailed activities need to be performed under each work package, much like a checklist. The planning and scheduling document may be a combination of a network diagram to identify sequential relationships of major tasks and checklists to make sure all the small details are identified and assigned.3
The WBS for a service project works well as a template for future similar projects. All big weddings are similar in the major functions: They need a church (or synagogue, mosque, etc.), attendants, receptions, showers, invitations, and so on. Likewise, the WBSs for all conferences, parties, vacation trips, and so on are similar, at least at Level 2 and perhaps at Level 3.
Results Breakdown Elements—Generic Projects
Similar to a service project, the results type of project does not have a well-structured primary product as a deliverable but may have several products that collectively achieve the desired result. Such a project does, however, have a series of well-defined steps that are planned—it is a process-based project—and will have a results breakdown element.
Figure 2-4 is the WBS for a project whose result is the implementation of a Hazard Analysis Critical Control Point (HACCP) system in a food processing plant. The objective of this project is to convert a traditional food processing line from one where quality is achieved by inspection of the end product to one where quality is planned, through process controls applied at various critical control points.
FIGURE 2-4 Results WBS—HACCP Implementation Project
In this type of project, where the result is the successful implementation of a HACCP system, the same six steps are performed for each processing line or project. It is the same whether it is frozen seafood cakes, packaged chicken parts, or canned soup. There is also a series of steps at Level 3 and below that are prescribed and performed. Because every plant is different and every project is unique, the intermediate outputs from each step, while similar in name, are quite different in content.
For similar “results-type” projects, such as a HACCP system in a chicken processing plant or in food preparation in an institution, the WBS for the top levels are the same or very similar if the same result is to be achieved, that is, a HACCP system for safe processed food.
In another example, the Level 2 and 3 elements (or steps) for a project to develop a new drug to be approved by the Food and Drug Administration would be similar for any new drug development.
Again, the 100 percent rule applies, and the team must carefully review the child elements of each parent at each level to ensure that all the work is identified. People who are familiar with or expert in the process should be used in this analysis. The goal is the same as with any WBS: to ensure that all the work that needs to be performed to meet the project objectives is identified.
Results Breakdown Elements—Information Technology Projects
An IT project is a results project because it does not have a well-structured primary product as a deliverable but has several products that collectively achieve the desired result. IT projects are a special category or type of WBS and are a combination of processes and products that are designed to achieve a result. That result is usually the implementation of an IT system to perform a specified function. Large IT systems fit the definition of a “program” and have a top-level WBS like that shown in Figure 2-5.
FIGURE 2-5 Information Technology Program
See Example 6 in Chapter 10 for the further decomposition and description of the lower levels of this generic IT WBS.
Another example that is also discussed further in Chapter 10 is the WBS for an Enterprise Resource Planning (ERP) implementation, as shown in Figure 2-6.
FIGURE 2-6 ERP Implementation IT Project
In Figures 2-5 and 2-6, the project work moves in stages from left to right, starting with project initiation and analysis. Project management in both figures is cross-cutting and related to all the other stages or WBS elements.
Cross-Cutting Elements
Cross-cutting elements contain work that is shared with peer WBS elements at each level. In a Product WBS, the cross-cutting element represents work that either supports the other WBS elements at the same level or is common to the WBS elements at that level; cross-cutting elements may also be a next step in a process that results in a product. An example of work that supports other elements is an element such as “Architectural Design”; an example of work that is common to the WBS elements at that level is “Project Management”; and an example of a next step in a process that results in a product is “Final Inspections,” “Assembly,” or “System Test.” There may be more than one element of this characteristic at Level 2. As a generality, the more complex the project, the more likely there will be multiple cross-cutting elements. As a rule, all projects have “Project Management” as one of the cross-cutting elements.
Cross-cutting elements often involve secondary or intermediate deliverables such as analytical reports that support the product deliverables. Where data deliverables that support the primary hardware (or software) product deliverable exist, they are frequently identified as a subdivision or work package under a cross-cutting element.
Analysis of many different WBSs identifies four types of cross-cutting elements:
Integrative
Analytical
Process
Project Management
The first three can occur at Level 2 or any lower level of the WBS, but Project Management is normally a Level 2 element. (It is important to note that Level 1 is defined as the top level, as shown in Figure 2-4.)
An Integrative element represents work that integrates two or more peer WBS elements. This is shown graphically in Figure 2-7 in the “Assembly” element.
FIGURE 2-7 Example of WBS with Integrative Element
In the simplified example in Figure 2-7, the product breakdown of the bicycle includes the frame, seat, pedals and gears, and handlebars. The “Assembly” work element is integrative because it represents the work involved in combining the other four elements—it integrates them. The Assembly work element—or its equivalent—is often missed when first developing a WBS or is implicitly assumed to be work that is part of the next higher or parent element. This false assumption violates the 100 percent rule that states the sum of the work of the elements at a child level is 100 percent of the parent.
The work flows from the other WBS peer elements to the integrative element.
Figure 1-6 also includes the integration WBS element Assembly at Level 4 under the Level 3 “Wall” element.
An Analytical Element represents analytical activity that spans the work elements of a common parent. This is shown graphically in Figure 2-8 in the sample WBS for a project that included development of a personal computer.
FIGURE 2-8 Example of WBS with Analytical Element
In the preceding example, “System Analyses” is a cross-cutting analytical element in the WBS. This element cuts across all the work in the other elements at the same level and below in the WBS. The system analyses affect the development and content of the other WBS elements. Information flows from the analytical element to the other elements and impacts their design, development, or content. If the project were for writing a book or preparing a report, a WBS element “Research” at Level 2 would be another analytical-type element, with the information flowing from the research work performed to affect the contents of the other elements of the book.
The next level of decomposition below an analytical element is often a set of work elements that are of a similar type as the parent, such as occurs in a parent element in a service project. For example, the next level below a System Engineering element may be a group of similar engineering functions, such as Reliability Engineering, Maintainability Engineering, Value Engineering, and the like. The outputs of these functions are often data deliverables such as a Reliability Plan or a Reliability Analysis, and they would be specified in the contract SOW or a contract data requirements list.
The Level 2 element may be even more general, such as just “Analyses,” and would include such items as “Needs Analysis,” “Economic Analysis,” and “Demand Analysis,” depending on the nature of the project. This type of element is similar to the elements in a service project and represents a grouping of similar or related work that is necessary for the project.
A Process element represents a next step in a work progression. It is similar to an Integrative element but is more related to the flow of work than the grouping or combination of several elements. This is shown graphically in Figure 2-9.
FIGURE 2-9 Example of WBS with Process Element
The WBS element Test and Evaluation is cross-cutting and is also the next step in a development process. At the level shown in the figure, the work performed in the Test and Evaluation element “cuts across” the other elements at the same level, its peers, and would require manuals, support equipment, the air vehicle (airplane), and maintenance facilities to do the testing work. The work flows into the direction of the process. Note that the other four Level 2 items are product deliverables.
In Figure 2-10, “System Test” is a process element because it is the next step in the process of preparing a PC for delivery to the customer. The work flows along the steps in the process. Also, the shaded work packages of the parent “Circuit Boards” are all process WBS elements leading to the intermediate deliverable of “Circuit Boards.”
FIGURE 2-10 Example of WBS with Process Elements
Project Management Element
While all WBSs have one or more of the first four types of WBS elements (product, service, results, and cross-cutting), all four do not always occur in every WBS. However, “Project Management” is a special category of cross-cutting element that occurs universally and can have characteristics of the integrative, analytical, or process elements within it at lower levels. While all WBSs have one or more of the first four types of WBS elements, they do not always occur in every WBS. The reason is that all projects have project managers, and they perform various types of work in support of the project.
The 100 percent rule requires the sum of the WBS elements at each level to represent 100 percent of the work of the parent. Because the project manager expends resources, work is involved and must be included. The labor cost and other expenses of the project manager and the Project Management Office may or may not be charged to the project as a direct cost, but resources are consumed, and project management activities are performed.
FIGURE 2-11 Project Management WBS Element Decomposition
Figure 2-11 contains a listing of typical Level 3 WBS elements contained in “Project Management.” Level 4 in Figure 2-11 consists mostly of work packages. The exceptions are the two zero-duration activities, Contract Award and Complete Project, which are useful milestones to have in schedules. The advantages of their inclusion in this list and their usage are explained later in this chapter in the section titled “Numbering the WBS.”
Frequently, some of the Level 4 items listed in the figure are routinely furnished by the parent organization and may not appear in the project WBS. In addition, some items may warrant their own Level 3 or Level 2 status if there is a significant amount of work to perform and it is deemed important to focus attention on it through the WBS. In any event, if work and resources are involved in any of the elements, those resources and the work should be reflected in the project plans. In addition, one of the rules of planning is to include the item in a plan if it will not automatically be performed.4
The 100 percent rule applies to all the work at Levels 3 and 4, and all important work packages or activities must be included. The planning and resource allocations must address the large amount of work involved in managing a project.
WBS ELEMENT DESCRIPTIONS
The classical approach to the WBS generally identifies the elements in the WBS as being described by nouns and modifiers. The WBS element descriptors can be thought of as the response to the question: “What has to be accomplished in this piece of the project?”5 The network diagram6 developed from the definition and relationships of activities answers the question, “How will it be accomplished?”; and the schedule resulting from the network calculations7 responds to, “When will it be accomplished?”
Some planners incorporate activity-like descriptions in their WBS, which would then include verbs. However, the basic, traditional approach of noun and adjective only is sound and proven, and it provides a discipline. The use of activity-like descriptions in a WBS should be limited to those cultures in which any other approach is unworkable. Activities, by definition, are action entities and include verbs in their descriptors. The activities more appropriately occur within the work packages, which are the lowest level of the WBS.
This book follows the philosophy that the WBS must be related to the objectives of the project and therefore must produce the unique product, service, or results according to the principles discussed earlier. The WBS must be oriented toward the end items or deliverables, and the WBS is preferably composed of elements that can be described by nouns modified by adjectives as necessary for clarity. This type of description is preferred because it requires the discipline of focusing on the output products, which are usually described by nouns. Using verbs implies action, which is ideally performed at the activity level, below the lowest level of the WBS. For the WBS to be fully understandable to people other than the planner, a separate document defining the content of each element is often needed. Such a document is called a WBS dictionary and is discussed in the next section. However, by using longer phrases that often include verbs in the element descriptors, the work content of the WBS element can sometimes be described sufficiently so as to bypass the need for a formal WBS dictionary.
The project environment and the project itself should determine the nature of the descriptors used for the elements of the WBS. It is necessary to have a set of WBS descriptors that help stakeholders understand the work represented by each element.
One of the primary purposes of the WBS is communication, so it is important to have a format with which the audience can identify. So it is possible for activities—verb statements—to be included in the WBS if that is the way your organization works. It is better to have a poorly described WBS than to not have one at all.
However, it is important that the WBS be based on the deliverables—the output products of the project—regardless of how the elements are described. Work packages and activities, and their relationship, are discussed in detail later in this chapter.
WBS DICTIONARY
A WBS dictionary is a document that defines and describes the work to be performed in each WBS element. The information provided need not be lengthy but should be sufficiently descriptive that the reader understands what the work is that is to be accomplished. Some organizations have found it useful to use a form to facilitate gathering WBS dictionary information. A typical form is presented in Figure 2-12.
FIGURE 2-12 Sample WBS Dictionary Form
The data on the form are all that is needed for the minimum dictionary. In some organizations, however, more data are gathered when applicable, such as budget, schedule, deliverables, earned value management data, and the like, that may be part of a specific WBS element. Such data are useful for work packages but may not be applicable for summary, higher-level elements. A typical WBS dictionary description for a WBS element named “Training,” which might occur at Level 2, follows:
WBS 1.4 Training. This element contains deliverable training services, manuals, accessories and training aids, and equipment used to facilitate instruction through which customer personnel will learn to operate and maintain the system with maximum efficiency. The element includes all effort associated with the design, development, and production of deliverable training equipment and instructor and student guides as defined in the list of deliverables as well as the delivery of training services.
One advantage of a WBS dictionary is the discipline of describing the work in each element in words. Frequently, the brief, summary descriptions of WBS elements are vague or misunderstood, and the dictionary can dispel any miscommunication that might result.
Some planners have found it useful to describe the WBS elements in terms of the activities performed in the element. This has an advantage of clarifying the work in the element without the need for a WBS dictionary. However, the use of activity nomenclature can be confusing and may tend to lose some of the discipline required for a noun-product-based WBS. Another of the drawbacks of using activity-based WBS element descriptors is the difficulty of evaluating whether the 100 percent rule has been violated and differentiating WBS elements from work activities.
A WBS dictionary describing the work in each element can readily be converted into a comprehensive SOW for a project or subproject, and the author can be confident it addresses all the work to be performed. The total project scope is thereby clearly and comprehensively defined.
CONTROL ACCOUNT: EVMS
When Earned Value Management Systems (EVMSs) are implemented, an important WBS element referred to as a Control Account (CA) is identified. The WBS is a key component of EVMSs; in fact, the system cannot be implemented without a WBS.8 Further discussion about this subject is included in Chapters 7 and 8. Control accounts are frequently established at the level above work packages, where specific organizational entities can be identified as responsible for the work to be performed.
EVMSs define the CA as the management control point at which budgets (resource plans) and actual costs are accumulated and compared to earned value for management control.9 A CA is a natural point for planning and control because it represents the work assigned to one responsible organizational element on one WBS element.
The organizational breakdown structure (OBS) reflects the way the project is functionally organized. To assign work responsibility to appropriate organizational elements, the WBS and the organizational structure must be interrelated with each other; that is, organizational responsibility must be established for identified units of work. The assignment of lower-level work segments to responsible lower-level managers provides a key control point for management purposes and cost collection. This is the CA. As we see in Chapter 8, in large construction projects each subcontractor is often identified as a CA and each control account contains many work packages.
The CA is the main action point for planning and controlling effort. All aspects of the system come together at this point, including budgets (resource allocations), schedules, work assignments, cost collection, progress assessment, progress payments, problem identification, estimates at completion, and corrective actions. The proper levels for CAs are not just an arbitrary determination based on an across-the-board single level of the WBS, but should be located at levels consistent with the project’s method of management and natural structure.
The effort within a CA is distributed into work packages, sometimes called planning packages. Planning packages are used for far-term efforts where it may be premature to identify specific work packages but it is necessary to account for all the funds available for baseline planning purposes. Eventually, all work in planning packages will be planned and scheduled to the appropriate level of detail in work packages and identified in the WBS before work commences.10
WORK PACKAGES
The lowest level of the WBS is defined as the work package level, which provides a logical basis for further defining activities or assigning responsibility to a specific person or organization.
The primary purpose of the WBS is to make sure all the work that is to be performed on the project is identified—the project scope is defined. A WBS is decomposed to the work package level; however, beyond the WBS, the work must be subdivided to the point where adequate planning and control can be accomplished. This is ultimately below the work package level, at the activity level where network planning is also performed. Each activity within a work package has a specified and expected duration, resources, cost, performance, and output that are summarized in the work package. This is discussed in more detail in the later section, “Use of the WBS to Develop Activities.” Each work package, like each CA, should have a single person or organization identified and responsible for the performance of the work.
Cost control is often impractical at the activity level because of the difficulty in collecting actual cost data by the accounting system. However, cost control usually can be exercised at some level, and this determines where the work package levels or control accounts are established.
A work package is the collection of activities performed by a specific organization, usually with a specific cost account number for a particular WBS element. This could be a large, subcontracted package of work. A Work Authorization Form or some equivalent document that specifies the budget level, start and completion dates, responsible organization, and brief statement of the work to be performed usually authorizes the work performed in a CA or work package. Figure 2-13 shows the relationship between the WBS, work packages, and activities for Project X. In this figure, “Circuit Board” could be established as a control account.
FIGURE 2-13 WBS, Work Package, and Activity Relationship
APPROPRIATE LEVEL OF DETAIL
How much detail should be included in the WBS? There is no single answer other than “it depends.” Generally, the part of the WBS that focuses on the product breaks down to a lower level than the cross-cutting elements. Because the lowest level of the WBS is the work package, the answer to the level of detail depends on the appropriate level for the work packages.
There is an important consideration about the amount of knowledge currently available about the project when preparing the WBS. For a large project, there may not be enough detail known to structure the WBS to a level appropriate for planning and scheduling, especially when a “rolling wave” concept of planning is being used. Each level of the WBS must meet the 100 percent rule so that all the work is accounted for; it is just not yet decomposed.
Looking at Figure 2-13, it is clear that the work packages need to be at Level 3 or below because more than one functional organization would be expected to be involved in each Level 3 item. Similarly in Figure 2-14, the work packages are identified as the lowest level (in bold) WBS elements. The activities are at the next level. If you use only the criterion that each work package has only one organizational entity responsible, then the level of decomposition tends to take care of itself, especially when the responsible person/organization is a first-level supervisor.
In general, the lowest level should allow for a reasonable definition of tasks or activities using the methodology presented in the next section. The activities should not be so detailed that they become a burden to plan, schedule, and track, nor should they be so broad that responsibility cannot be identified and progress cannot be measured often enough to maintain control of the project. It is recognized that the preceding statement is not much practical assistance, but with a little experience, the appropriate level of detail for a given organizational culture is readily determined.
A further consideration is the type of work package. Those that contain work that is essentially “level-of-effort” do not need to have much detail. These types arise in EVMSs, where it is necessary to account for all resources or dollars. A typical level-of-effort activity is the work of the project manager and any secretarial or administrative support. They may be assigned to a single work package (or activity) that is scheduled to span the duration of the project.
FIGURE 2-14 Example of WBS Elements and Activities
USE OF THE WBS TO DEVELOP ACTIVITIES
An important role of the WBS is to facilitate the identification and development of project activities. The specific mechanism to be used to develop activities is described in this section, as is a set of criteria for defining activities.
The WBS and Activities
After ensuring that the entire scope of the project is addressed, the primary function of the WBS is to facilitate the identification and definition of the activities that need to be performed in the project. The WBS was described previously as noun-based down through the work packages. Activities are verb-based because that is where the action is. This was also shown in Figure 2-13. The WBS provides the outline structure for Gantt charts and network planning. The WBS outlines what work will be performed, and the activities describe the actions necessary to perform that work. This is shown in Figure 2-14 for a hypothetical Hacker Analysis System Project.
In the figure, the WBS elements are in bold and are in adjective/noun form. The activities are in italics in verb/adjective/noun form at the level below the WBS.
This example shows the relationship of the WBS to the activities in the schedule and used in network planning. The individual activities are linked in the project management software into a precedence network and displayed in Gantt format on the screen and when printed out on hard copy.
The manner in which the WBS is arrayed can make schedules easier to read and to use. Put the Project Management element at the top of the WBS and numbered 1.0 as shown in the figure. And if there is any natural process flow at Level 2 of the WBS, have it go from left to right in the graphic version of the WBS or top to bottom in the outline version; then the schedules will be displayed more naturally.
Although the WBS is not a scheduling tool, it would be putting one’s head in the sand to not recognize that some phasing exists in most projects, no matter how simple the project. This is especially the case in “results” projects where standard steps or stages are followed.
A useful device to assist in scheduling is to establish a special work package under “Project Management” for the start and completion events of the project. Included in the work package are the two zero-duration activities that identify the start and completion. These activities have two advantages: one is that you have an anchor from which to link all successor activities in the planning network; the second is that by linking them to one start point, if there is a delay in the start of the project, it can be easily accommodated by changing only the start date of one event.
In Figure 2-15, the data of Figure 2-14 have been entered into Microsoft Project application software to illustrate the use of the WBS as an outline for structuring the schedule.
It should be clear that if we follow the 100 percent rule and input the WBS into the project management software, it is an easy and swift task to identify all the activities in the project and to array them in a logical schedule format. The activities are the basic building blocks of the project, and as has been repeated several time, the goal of the WBS is to make sure all these building blocks are identified.
FIGURE 2-15 Hacker Analysis System (HAS) Project
Activity Definition
Experience has shown that defining activities or tasks is not as easy as it looks. Too many times they are inadequately described, and poor schedules and communication problems result. Activity definition is extremely important because activities are the building blocks for planning and controlling the project.
An activity normally has an expected duration, an expected cost, and expected resource requirements. Also, a single person or organization responsible and accountable for the work performed characterizes an activity.
Although infrequently specified explicitly at the detail level in project planning, activities have performance requirements as well, and most activities also have specified outputs or results. If the activity is vague, it needs to be redefined.
A most important consideration is this: The activity may not be performed if it is not in the plan. In fact, the reason to have a written plan is to make sure the need for the activity is communicated to the appropriate stakeholders, including those people who are responsible for predecessor and successor activities and the person responsible for performing the activity.
Scrutinizing the activities identified in the Hacker Analysis System (HAS) project in Figures 2-14 and 2-15 reveals how the preceding characteristics are present in the WBS.
The HAS requirements specification and the HAS design specification are well-defined documents, and the activities involved are all clear. The outputs are tangible—something is done to the document.
The activities of coding the software are similarly clearly defined. The output would be completed software code, probably in hard copy as well as digital form, depending on the normal practices of the organization. Unit test is usually defined by the completion of a document provided by the quality control organization or someone providing a similar independent verification function that certifies that the test was performed and completed as specified.
INPUTS VERSUS OUTPUTS—RESOURCES VERSUS DELIVERABLES
It is important to understand the differences between the inputs to the project and the output products. The concept of an output- or deliverable-oriented structure can sometimes be difficult to grasp.
Input versus Output Elements
For years, planning has been performed in terms of the organizations and resources doing the work, that is, the “inputs.” The use of a WBS requires a different perspective—a focus on the output. The output is what is going to be produced: the product, service, or result. Project inputs include the labor and cost resources necessary to perform the work. They are essential, of course, but approaching project planning from this perspective risks missing major elements of work. Typical project inputs include cost elements such as those shown in Figure 2-16.
FIGURE 2-16 Typical Project Inputs
These items are not ignored in developing a WBS or in project planning; the assignment of inputs to individual activities is performed. Most current project management software programs have resource tables that contain lists and costs of project inputs. Items are selected from the resource table and assigned to individual activities for cost estimating and resource planning.
In addition, pricing proposals are often required to be structured by categories similar to these and to include overhead rates. However, the primary purpose of the WBS concept is to develop a framework for planning that ensures all the work is identified. After this is accomplished, the assignment of resources and cost elements can be accomplished at the work package or activity level, and the work can be scheduled and sorted by input or organization as necessary to communicate requirements for work performance.
Deliverables versus Intermediate Outputs
Project deliverables, as defined previously, include any measurable, tangible, verifiable outcome of a project. They can be a product, a service, or a result. There may be hundreds of deliverables on a large project, such as the Ship System of Figure 1-12, especially where many data items are required to support the product. Each one of these, and the related work, needs to be identified and included in the WBS.
Deliverables need not only represent the product handed to the customer at the end of the project. Usually, intermediate outputs must be developed. Some examples may further clarify what is meant by the intermediate deliverable or intermediate output.
For the sample project of building a garage, the obvious output or deliverable is a completed garage. The WBS for the garage is shown in Figure 2-17 in outline format. The Level 2 elements, the first level of decomposition, are shown in bold.
There are many intermediate outputs. One category of output includes the items that the Project Management Office must produce to support the project. This includes intermediate outputs such as securing financing and developing and preparing subcontracts and construction plans. A completed piece of paper shows when each activity is finished. Another category of intermediate outputs is the county permits that must be acquired, and each inspection results in a certificate from the inspector or a signed inspection sheet. Actually all the Level 2 items under “Project Management” represent work packages with intermediate outputs.
A sample of the first two levels of another WBS is shown in Figure 2-18.
FIGURE 2-18 Book Project Level 2 WBS
Four Level 2 outputs are identified. One is “Project Management,” which includes the intermediate outputs of such things as meetings, reports, and reviews. A second category, a cross-cutting analytical category, is “Research,” which is necessary for the writing of the various chapters. The third category, “Writing,” includes the book contents. “Research” is not an input resource, but a category of intermediate work output that is delivered to the “Writing” work area. The output of the Writing element is not a completed book but a set of completed chapters and items such as the table of contents and the cover. The fourth output is “Publishing,” which includes the reviews of completed drafts of the book and the actual printing of proofs and the final copies. See Chapter 10 for the complete Book Project WBS.
Neither of these WBSs includes labor or cost elements. As mentioned previously, the labor and cost items are identified with the activities and are input items identified at the work package or activity level.
NUMBERING THE WBS
In developing a WBS, logical coding or numbering of the various elements and levels significantly improves the functionality of the WBS in various related applications. The coding can be done by any method, but it is important to be consistent. Most organizations have standard codes. These codes can be used and modified to contain numeric/alpha elements, which will give a unique identification to every work activity and facilitate sorting for special reports. The resulting identification provides a label for scheduling, budgeting, tracking, replanning, assigning, and in general, for communicating across the project. Many of the project management software packages allow you to enter the WBS codes and to use these codes for sorting data and preparing specialized reports.
EVMSs usually require formally established numbering systems for cost data based on an enterprise-wide table of accounts. The accounting system requires that the project number, control account number, and work package number be identical to the WBS number, or to map to it. In addition, the accounting system needs to be able to accumulate direct costs within work packages for labor, material, travel, subcontracts, and other direct costs (ODC) through the EVMS and general ledger into the enterprise financial statements. Activity numbering also relates to WBS numbering, as shown in Figure 2-15. So it is necessary to have a system that is capable of summarizing cost and schedule data from the activity level through the work packages and control accounts by organization and by WBS level.
Some mature organizations use standard WBSs for classes of products in order to be able to gather cost data by key WBS elements across projects. For these organizations, the definition and numbering of the elements at least at the top levels may be specified and controlled. The purpose is to be able to populate and maintain databases of historical data in order to develop cost-estimating relationships (CERs) and for various analyses.
There are many possible numbering systems for the elements of the WBS. The purpose of all numbering systems is to be able to identify the WBS work element readily and to determine where it fits in the overall project hierarchy. WBS elements frequently have similar names, and the numbering system clearly identifies each discrete element.
A decimal numbering system as shown in Figure 2-19 is commonly used.
FIGURE 2-19 Generic Decimal Outline Numbering
The decimal numbering system is precise and thorough, and it can continue to whatever level is necessary. The numbering system shown in Figure 2-20 is for the Garage Project. If there are several projects in an organization, and similar WBS elements in each, a prefix such as GP1 (Garage Project One) could be added to distinguish projects.
FIGURE 2-20 Garage Project Numbering
This numbering would be extended into all the activities in the schedule or network diagram so that every activity would be discretely identified.
This decimal outline numbering matches typical accounting systems numbering, which facilitates cost accounting, cost roll-up, and EVMSs.
Chapter 3 provides an illustration of how software such as Microsoft Project uses the WBS Code Definition feature to provide flexibility in the type of numbering system used.
Other internal systems using the WBS as an organizing framework are as follows:
Action item tracking—Relating action items from meetings and reviews to WBS numbers.
Bills of material—The WBS number may be included in the part number or vice versa.
Change management—Change proposals include WBS numbers.
Correspondence control—In addition to day files and organization files.
Data management.
Drawing numbers—Part of the drawing number includes the WBS number from the Product WBS elements.
Report numbering.
Risk management—Relating specific risks from the risk identification process to the WBS elements.
Subcontract numbering.
ALTERNATE STRUCTURE CONCEPTS
The concept of a WBS as an outline is stressed in this book. An outline is both an organized description of the project work and a plan for the work to be accomplished. In developing the outline, you may identify work that was not initially contemplated, and you may eliminate work that is not part of the project. The final WBS may go through several stages as the project becomes defined. A normal WBS contains very brief descriptions of the work elements, like a sketchy topical outline. This kind of outline requires that the work be defined during the WBS development process, and the final products may include a SOW structured around the WBS or a WBS dictionary. In some cases, it may be preferable to just identify the work elements with phrases or sentences.
The kind of outline—WBS—you use should be determined by the project work structure itself, the culture of your organization, and your own thought processes. For most people, there is an interaction between defining work elements, thinking, and organizing. As you proceed in the development of a WBS, you will probably revise it more than once, rearranging the order and levels of work elements, adding work, and deleting work.
The preferred approach to the development of the WBS is to make it a team effort. In that manner, the team members become intimately involved in the project and the definition of the work to be performed. Having a team effort also helps ensure all the work is identified, because specialists and experts will make sure the WBS covers their specialty areas. When developing a WBS with a team, there are only two primary rules:
(1) The 100 percent rule.
(2) Project management should be a Level 2 WBS element.
All the other rules, such as those listed in Chapter 4, can be tailored to fit the culture and used as guidelines.
There are differing opinions as to the best structure for a WBS, and these alternative opinions are presented and discussed in this chapter. Translating the concept of the outline structure for writing into WBS, one could say that the best organizing principles are inherent in the project itself and in the way the project is to be implemented.12 For example, a project that is to be implemented in several different cities may be best organized by structuring the work geographically at Level 2 and using one of the other types of structures at Level 3.
A project where one organization will complete all of its work and then pass it on to another organization for the next step may be best organized by process steps at Level 2. This is common in construction projects where the design is completed before the construction begins and in fact may be a requirement where design drawings are needed for the construction bidding process. Another project that involves the tightly integrated design, development, and fabrication of a prototype may be best organized by the structure of the deliverable product. Using the personal computer example, the principal alternate WBS constructs are shown in Figures 2-21 and 2-22.
Both of these WBSs should result in the same work packages and activities being defined, although the Product WBS is more in keeping with the focus being deliverables. The two WBSs present different perspectives of the work content. The choice will depend on the culture and structure of the organization, the managerial style of the project manager, and other factors. If the 100 percent rule is followed, the end result should be the same.
The WBS in Figure 2-22, although having a process flow, is not a “results-type” project. It is a project with a product focus that is structured with processes.
It is necessary to keep an open mind about how to structure a WBS and to allow the project itself to suggest its own organization, but still focusing on outputs.
Other kinds of breakdown structures to present project information are as follows:
Organizational Breakdown Structure (OBS) is a structure that is used to show which work components have been assigned to which organizational units. Preparing an OBS can be very confusing if the intent is to use it to define the work, because it is organization- or input-oriented. The focus in developing a WBS must be on the work, not on organizations of people.
One of the difficulties in developing a WBS is the necessity to move away from the paradigm of structuring work by organization function and instead to focus on the deliverable or output product. When structuring by organization, you are focusing on the inputs to the project, not the outputs. The OBS is useful to develop after the project activities are all defined in order to provide a report or schedule of all the activities that are the responsibility of a specific organization, such as “Engineering Design.” Most project management software systems make it easy to add an organization or responsibility code to identify the organization. In some software packages, these fields are identified as “OBS” fields. Rad categorizes the OBS as “the most readily available structure.”13 He cautions that because companies frequently go through large organizational changes, “care must be taken to use the most recent data and to make updates as changes continue to occur within the organization.”
Resource Breakdown Structure (RBS)14 is described as a variation of the OBS and is typically used when work components are assigned to individuals. Rad has a somewhat different perspective of the RBS than that presented in the PMBOK® Guide.15 He perceives the RBS as a logical and useful classification of the resources needed to accomplish a project’s objectives. He also recommends developing a resource pool that is essentially a catalog of all the resources available to a project. To accomplish cross-project resource planning, the coding or categorization scheme of the resources in the pool needs to be the same for each project. Figure 2-23 is an example developed by Rad.16
FIGURE 2-23 Resource Breakdown Structure
A further discussion of resource pools is incorporated in the author’s book, Project Planning and Scheduling.17
Bills of Material (BOM) present a hierarchical view of the physical assemblies, subassemblies, and components needed to fabricate a manufactured product, according to the PMBOK® Guide. However, a BOM, if available for a deliverable of a project, is useful for structuring the product section of the WBS. In fact, a summary or top-level BOM is essential for developing a WBS for most tangible products. A BOM by itself is not a WBS.
The PMBOK® Guide also makes reference to a Project Breakdown Structure (PBS) and indicates the PBS is fundamentally the same as a properly done WBS. The PBS was the term used in the 1960s, and occasionally since then, by some authors, and it eventually was dropped in favor of the WBS terminology. Archibald describes the PBS as identical to the WBS in his 1976 book.18
OTHER CATEGORIZATIONS
There is no one best categorization or subdivision of the project. It is sometimes desirable to use a different structure because of the situation or culture of the stakeholders. Various commonly used categorization schemes at the top levels are:
Components of the product or service to be delivered: Automobile—Fenders, engine, hood, seats, frame, gas tank, and so on
Subsystems: Airplane—Hydraulic, electronics, structure, pneumatics, power plant, and so on
Projects: Program—Project A, Project B, Project C, and so on
Process Phases: Software—Requirements, Design, Coding, Test, and so on
Time Phases: Life Cycle—Conceptual, Planning, Implementation, and so on
Geographic Areas: New York City—Brooklyn, Queens, Manhattan, and so on
Organizational Units (Phases): Engineering, Construction, and so on
On the surface, it appears that some of these categorizations are inputs, such as organizational units. That is really not the case when used properly. The items represent phases of the project, as discussed later. The WBS under each of the categories is still output- or deliverable-oriented. It is important that there be a logical framework for planning that is internally consistent and represents all the work to be performed on the project. The WBS is output-oriented.
Other ineffective categorizations are sometimes proposed:
Organization: Engineering—Mechanical Design, Structural Design, System Analysis, and so on
People: Small Project—John, Mary, Ozzie, David, Courtney, and so on
Cost Accounts: Labor, Travel, Office Supplies, and so on
The preceding categorizations are all input-oriented and are not appropriate for a WBS. Organization names and codes, cost accounts, people, and other inputs are appropriate for coding work packages and activities so as to be able to provide reports or information sorted by these types of categories.
On occasion, people attempt to link WBS elements or to use the WBS to assist in the sequencing of work. Whether or not the WBS has a process, systems, or product structure focus, the sequence of work is not the objective. The important aspect of the WBS is whether the work required to deliver the project end items and meet the project objectives has been identified in enough detail to identify activities and resources, and assign responsibility. The sequencing is accommodated through the planning and scheduling processes.
NOTES
1. The 100 percent rule is highlighted in the PMI® Practice Standard for Work Breakdown Structures, 2nd ed. (Newtown Square, PA: Project Management Institute, 2006).
2. Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 3rd ed. (Newtown Square, PA: Project Management Institute, 2004), 368.
3. Gregory T. Haugan, Project Planning and Scheduling (Vienna, VA: Management Concepts, 2002), Chapter 3.
4. Haugan, Project Planning and Scheduling, 3.
5. PERT TIME, Document OR 3424, v. 1 (Orlando, FL; Martin Marietta, 1963), 2–3.
6. Haugan, Project Planning and Scheduling, 50.
7. Haugan, Project Planning and Scheduling, 67.
8. American National Standards Institute, The ANSI/EIA-748-A Standard for Earned Value Management Systems (Washington, D.C.: American National Standards Institute, 1998).
9. Ibid., 60.
10. Humphreys & Associates, Pocket Guide to Program Management Using an Earned Value Management System (Orange, CA: Humphreys & Associates, 2002), 11.
11. Harold Kerzner, Project Management: A Systems Approach to Planning, Scheduling and Controlling, 7th ed. (New York: John Wiley & Sons, 2001), 576.
12. Melissa Walker, Writing Research Papers (New York: W.W. Norton & Company, 1984), 90.
13. Parvis F. Rad, “Advocating a Deliverable-Oriented Work Breakdown Structure,” Cost Engineering (December 12, 1999), 35.
14. Note that “RBS” is also used to mean “risk breakdown structure.”
15. Parviz F. Rad, Project Estimating and Cost Management (Vienna, VA: Management Concepts, 2002), 27.
16. Ibid., 86.
17. Haugan, Project Planning and Scheduling, 65.
18. Russell D. Archibald, Managing High-Technology Programs and Projects (New York: John Wiley & Sons, 1976), 141.