CHAPTER 4
Creating a Work Breakdown Structure
THE WORK BREAKDOWN STRUCTURE (WBS) describes the work needed to create the project deliverables that will meet the previously determined requirements. The WBS defines and organizes the total scope of a project in a hierarchical breakdown of activities and end products. It is an essential tool for effective project planning, scheduling, and controlling. If defining the project’s goal is the heart of project management, then the WBS is the skeleton, musculature, connective tissue, and central nervous system. The WBS provides both structure (for stability) and articulation (for movement) to the project plan.
Creating the WBS is simple, but not always easy. The underlying concept is clear. A WBS describes, in outline form, the work needed to meet project objectives. The outline is logical and hierarchical, but not necessarily sequential. At its highest level, the WBS conveys an approach, a strategy, a methodology, a template, or a best practice routinely used in your type of project. At its lowest level of detail are unique work packages, or activities that must be performed.
The WBS is ordinarily displayed in a top-down manner. In actual development, a WBS may have some pieces developed top-down or bottom-up. In either case, as the WBS becomes increasingly detailed, work packages appear. These work packages will then be used to sequence the work into network diagrams, schedule work, assign resources and costs, and establish the definitions of appropriate quality for each deliverable that emerges from the project work.
Later on, in the execution and control processes, the WBS becomes a tool for monitoring, reporting, communicating, motivating, and establishing accountability. If the WBS is incomplete, then the project manager has little hope of success. Specifically, if there is work that must be done but it is not in the WBS, the project will likely be late, be over budget, exceed its resource usage, or be of diminished quality. The anticipated benefits will not be delivered, and the end result will be an upset sponsor or client.
The Work Breakdown Structure Is an Outline
Work breakdown structures are traditionally created in outline form. The highest level of description embraces and includes all subordinate levels. The outline itself is logical and hierarchical, but not necessarily sequential. Here is a simple example of a WBS for a term paper:
1. Title
1.1. Section
1.1.1. Paragraph
1.1.1.1. Sentence
Writing the report does not have to be done in section sequence. Nonetheless, each section has the same logical and hierarchical structure. The WBS is a template or guideline and works independently of whatever report is being produced.
Work breakdown structures may be displayed either as lists or as graphical decomposition diagrams (which typically resemble organization charts), such as the one shown in Figure 4-1. Each level in the WBS is oriented toward groups of deliverables. Each level is complete only when all of its subordinate work items are completed.
Considerations in Creating Work Breakdown Structures
In preparing a work breakdown structure, keep the following in mind:
Use any category that makes sense for your project. This might include components of the product, functions, organizational units, geographical areas, cost accounts, time phases, or activities.
Do not be constrained by sequence. The diagram does not need to represent a logical or time sequence of events.
The diagram does not have to be symmetrical. The number of levels might vary from one branch to the next. Break each branch down to the number of levels necessary to adequately define the project.
Each box is a summary of the boxes in the levels below it.
The final box in each branch must end in a product or deliverable. These must be measurable and definable in terms of an end result.
Figure 4-1 Work Breakdown Structure of an Order-Processing System.
The number of levels of detail that should be included in the WBS may differ for each project, depending on the size, complexity, and risk of the project.
The boxes in the lowest level are called work packages. They represent the lowest level of detail you want to estimate, schedule, monitor, and control. They should represent eight to eighty hours of work. Each work package can be divided into specific activities. For each work package, describe the completion condition. Ask yourself what must be delivered to consider the activity finished.
The entire project team should be involved in developing the work breakdown structure.
The sum total of boxes must represent the complete project. You can leave nothing out. When all these deliverables are completed, will the project be done?
When completed, you should review the work breakdown with the client and customers. This is to ensure that it is complete and that it addresses their specific concerns.
The Work Breakdown Structure is a Validation Tool
At its higher levels—usually levels one and two—the WBS describes and validates your project’s approach or methodology. At these levels, the WBS is often broken into phases or stages. These are often viewed as pieces of work delineated by milestones, deliverables, or management decisions that authorize future work. In other words, the WBS summarizes all subdivided elements in your work plan.
The WBS is an example of a functional decomposition diagram. It is milestone (or deliverable or product) driven until its lowest level of work packages is reached. Thus, a top-down development approach yields progressively better-defined work products. A bottom-up approach is used to develop estimates. In other words, planning is done from a global level down to work packages. Estimating is done using work packages as units of analysis that are then aggregated to form project totals.
At lower levels, where subactivities and work packages emerge, the WBS serves several purposes:
The work package (or lowest level of decomposition) is used to later define the logical sequence in which the activities could be performed in a network diagram. (Note: This is explained in detail in Chapter 5.)
Members of the planning team use each work package as a basis for estimating. Each discrete piece of work will have estimates for duration, assets, resources, and costs.
Work packages can be used to capture technical and performance objectives. Each work package must produce some kind of deliverable or product that will be accepted by the next sequential activity. Therefore, when you create a customized WBS for your project, you automatically create an index of deliverables—a master list of documentation items that flow from each piece of work. Each deliverable, in turn, has quality standards associated with it.
The WBS can also be used to assign accountability and develop a responsibility assignment matrix for each work package and work product. This is a spreadsheet where work packages are in rows and organizational units are the columns. The resulting cells can then be used to describe the relationship between work and performing organizational units. Figure 4-2 shows a simplified example. Include in the matrix who is responsible, who is accountable, who should consult or review, and who should be informed.
Figure 4-2 Responsibility Assignment Matrix.
The WBS is a foundation for project risk analysis. As the planning team develops the detailed WBS, members can isolate those packages where uncertainty abounds. This will, in turn, affect estimating the work because team members must factor in the probability of occurrence and the likely impact of each occurrence.
Not only is the WBS the foundation for detailed planning, it is also the centerpiece of controlling work in process, management reporting, change control (or configuration management), and closure. Simply put, the structure you use to plan the work in the WBS becomes the basis for tracking work performed, variance analysis, and corrective action.
Work Breakdown Structures Are Flexible
The WBS is a flexible and adaptive tool. There is no single scheme that can be applied to all projects. In fact, even within a specific industry or for a repetitive application, the WBS may need to be customized to meet the particular needs of a project. The WBS may be tailored to account for geography, culture, language, social convention, or the names of particular components. A WBS may be shown in graphical format or in a numbered list.
It is helpful to look at WBS examples from various industries or businesses so that you can adapt them to your particular requirements or organization. Included here are several examples, each at a fairly high level, to indicate both the commonality of approach and the distinctiveness of specific project types.
The example in Figure 4-3 comes from projects involving construction projects, plant expansions, or design-bid-build projects. In this example, the highest level of the WBS drawing represents project phases. This six-phase project may be adequate for senior management, but it lacks any real appreciation of specific work that needs to be accomplished.
Figure 4-3 Sample WBS for an Engineering Project (Strategic Level Only).
Figure 4-4 shows the expansion of phase two to illustrate how that phase could be shown in four levels of detail. This plan is obviously incomplete. Where, for example, would you insert nuclear engineering or instrumentation and control subsystems in this example? Your project team would use this template to validate the project’s technical objectives. It would expand the WBS to ensure that all technical objectives and requirements were properly addressed in this early version of the WBS.
Figure 4-4 Sample WBS for an Engineering Project (to Four Levels of Detail).
In some technical projects, the WBS may be developed in terms of piece parts or components. Each component then has work packages for design, building a prototype, testing, revising and refining, and building a production model.
When projects are to be done at multiple locations, the first level of decomposition could be geographic. A country manager or site manager then becomes responsible for all the work packages performed under his or her direction.
Figure 4-5 illustrates a project that will develop and deploy an assembling machine. It assumes that proof of concept and proof of principal have been demonstrated. This figure shows a WBS in a list format rather than a graphical format.
The two preceding WBS examples presume a well-developed and familiar methodology. If, however, your project involves significant unknowns or is a research and development project, then your WBS model may resemble Figure 4-6.
Figure 4-5 Sample WBS for Product Design.
If we expand the first part of this example, then the WBS might look like Figure 4-7 (in list format) or Figure 4-8 (as a graphical decomposition diagram).
Techniques in Creating Work Breakdown Structures
The following are tools that may help your team create a WBS that addresses unique requirements of a project. These tools help project teams address scope ambiguities, overlaps and duplication, unrealistic expectations of one or more stakeholders, conflicting objectives, and differential priorities associated with requirements.
Figure 4-7 WBS in List Format.
Figure 4-8 WBS in Graphical Format.
Preexisting templates or checklists. These may include industry-specific or government-furnished checklists, best practices, guidelines, specifications, or standards. Industry-specific templates may be found on the Internet.
Brainstorming (or another idea-generating tool). Use these when a problem resists traditional analysis.
Mind mapping and affinity diagrams. These are powerful tools that reflect the mind’s ability to use associative, rather than purely serial, reasoning.
Index cards or sticky notes. Use these to organize ideas, goals, roles, and responsibilities.
Verifying Scope
Verifying scope is where the project manager achieves formal acceptance of the scope by the customer or sponsor. Sometimes it is difficult to know when you have planned enough and when it is time to move on with the project. There are two countertendencies in defining project scope. One impulse is to insist on near-total definition and documentation before moving from planning to project execution. Some projects never escape from this planning limbo, even though market forces may make the project increasingly irrelevant. At the other extreme, the tendency is to “hit the ground running,” feeling there is no time to plan. This school of thought fails to understand the role of planning. The purpose of planning is not to produce a perfect plan; it is to guide thoughtful implementation and execution in order to achieve the desired outcome.
Controlling Scope
Controlling scope is the process of monitoring the status of the project scope and managing changes to the scope baseline. It ensures that all requested changes and recommended corrective or preventive actions are processed through the established change control system. Uncontrolled changes are often referred to as project scope creep. Change is inevitable, and not all changes are bad. But all changes should be controlled through a system whereby they may be evaluated and approved or rejected. Approved changes can then be implemented in an orderly way, with full understanding of their effect on the schedule and budget.