A project work breakdown structure is an outcome-oriented grouping of project ele- ments that organizes and defines the total scope of the project—work not in the WBS is outside the scope of the project.14When presented in a graphical format, it becomes obvious why the WBS is often described as a project tree diagram, hierarchically dis- playing project outcomes, which are further broken down into more detailed tasks (see Figure 5.3). This same project tree analogy helps to visualize project outcomes at one level as parents to those from the next-lower level, who then become parents to the next-lower level outcomes, and so on.
The project WBS provides the project manager the means to divide a project into manageable increments, helping to ensure the completeness of all work that is required for successful completion of a project. Projects are planned, organized, and controlled around the lowest level of the WBS or work packages that are assigned to a project team member for responsibility for completion.15
THE WORK BREAKDOWN STRUCTURE 127
1000 2000 2000
1100 1200 2100 2200 3100 3200 3300
Hardware Development Project
Concept Stage Design Stage Manufacturing Stage
Design Review
Prototype Approval
Process
Develop 1stArticle Production Release
1110
1120 Project Kickoff
1210
1220 Project
Plan
2110
2120
2130 Design Concept Design Review
DFMEA
2210
2220
2230 UX Design Review Component 1st Article Quality Test
3110
3120
3130
3210 3310
3320
Level 0
Level 1
Level 2
Level 3
Figure 5.3: An Example Hardware Development Project WBS
Don’t confuse the project WBS with an array of intimidating acronyms such as CWBS, BOM, or OBS. These tools are as logical and conceptually simple as the WBS, but they have different purposes. For example, CWBS (contractual WBS), which is less detailed than a WBS, is used to define the level of reporting that the project contractor will provide to the owner in larger, contractual projects. Widely applied in manufac- turing industries, BOM (bill of materials) is a hierarchical representation of the physical assemblies, subassemblies, components, parts, and so forth that are necessary to pro- duce a product. Finally, an OBS (organizational breakdown structure) indicates which organizational units are responsible for which work elements from a WBS (for basic terminology, see “WBS Language”).
WBS Language
Work elements. Any project outcome in the WBS is called a work element, consisting of an item of hardware, software, service, or data. While some elements are the direct outcome of work, others are the aggregation of several logically grouped deliverables.
WBS level. This is the hierarchical location of a work element in the WBS. Work elements at the same stage of structuring are on the same level. There is no universal system for numbering levels. We number the overall project level as 0 and subsequent levels as Level 1, Level 2, and so forth. Using (continued)
level numbers enables you to uniquely code each work element, providing a basis for cost control, for example.
Work package. These are work elements at the lowest level of the WBS. We assign each of them to individuals (often called work package managers), who are responsible for managing tasks such as planning, scheduling, resource planning, budgeting, risk response, and quality assurance.
Cost account. This is a summary work element that is one level higher than the work package. A cost account includes one or several work packages and is often described as a management control point where actual performance data may be accumulated and reported.
Branch. All work elements underneath a Level 1 deliverable constitute a branch.
Branches may vary in length.
WBS dictionary. At a minimum, a WBS may include brief descriptions of work packages, along with entry conditions (what inputs to a work package are necessary) and exit conditions (what outputs of a work package are required to call it complete). Adding more to it—for example, schedule dates, cost budgets, staff assignments for work packages, and descriptions of other work elements—may make sense in large projects.
Constructing a Project WBS: A Top-Down Approach
There are two basic ways of developing a project WBS: top-down and bottom-up. In this section we detail the top-down approach, which is a very convenient approach for project managers and teams with experience in project work, have knowledge of the project deliverables, and are comfortable with a systems approach to organizing the work to be performed on a project.
The development of a WBS is likely to be an easier and more meaningful exercise if you are equipped with information about the following:
■ Project scope
■ Project workflow
■ Project requirements
■ Project situation
The project scope statement provides an understanding of what the project will pro- duce. You first need to know “what you will produce” (scope) before you decide “how you will produce it” and depict it in the WBS. Note the practice of some experienced project teams who prefer to develop the scope statement and WBS in parallel rather than sequentially or actually include the WBS as part of the scope statement.
In constructing a WBS, the knowledge of the project workflow is crucial. For instance, to develop a meaningful WBS for a software development project, you need to under- stand the process of software development. Knowledge of the process will indicate which activities are necessary to produce the required project deliverables.
Finally, specifics of your project situation are known to influence the anatomy of a WBS. Take, for example, the case of an enterprise software development company where each department had its own WBS when working on a project until it was acquired.
THE WORK BREAKDOWN STRUCTURE 129
The new owner immediately ordered all projects to develop an integrated WBS for each project, mandating that a large project’s WBS include a project management branch.
Select WBS Type
After acquiring all necessary information about WBS shaping factors, you have more choices to make before being able to construct a WBS. Which method will you use to structure your WBS? Consider the three major ones: WBS by project life cycle, WBS by system, and WBS by geographic area (see Table 5.2).
The underlying principle of the WBS by project life cycle method is self-explanatory:
You break the overall project into phases of its life cycle on Level 1 of the WBS. This principle of conveniently following the natural sequence of work over time is widely popular in some industries. A good example is a software development project con- sisting of phases such as requirements definition, high-level design, low-level design, coding, testing, and release.
In contrast, users of a WBS structure by geographic area segment the project work by major geographic sites or regions such as in building construction. It is not unusual that literal geographic regions—for example, northwest site, southwest site, southeast site, and northeast site—are used as the element for Level 1 of the WBS.
You have probably noticed that our discussion about the three structuring meth- ods was limited to Level 1 of the WBS. What about Level 2 and other lower levels? Each of the three can continue with the underlying principle of further dividing the work into the lower levels. For instance, WBS by geographic area can have work elements on Levels 2 and 3 that could be composed of work elements that will be performed in a specific geography identified at Level 1. Many practitioners, however, find hybrids more practical, combining two or three methods in the same WBS. For example, they may have a WBS by project life cycle on Level 1, systems on Level 3, and a geographic breakout of work at a lower level.
Which method of WBS structuring is right for you? Before answering this question, you should know that structuring a WBS is not an act of science. It is rather an act heavily influenced by a company’s culture, shaped by top managers with the purpose of deter- mining “how we get things done around here.” If there is no previous history of using a WBS in your company, you should probably follow your industry norm. This does not rule out the use of a different type of WBS structuring, but the bar of resistance to a new WBS structure will be lower if you go with the standard approach. Should you decide to go against the grain, be prepared to engage in some organization transformation discussions with others in the organization.16
Table 5.2: Methods for Structuring the WBS Method of WBS Structuring
WBS Level Life Cycle System Geographic Area
0 Project Project Project
1 Phase System Component Area or region
Establish the WBS Level of Detail
How many levels should a project manager use to structure a WBS (see “Too Many Levels Can Create Turmoil”)? The answer to this question will determine the total number of work packages. Considering that the number of work packages influences the necessary time and cost you need to manage a project, you need this number to align with what your available time and budget can tolerate.
Too Many Levels Can Create Turmoil
“How many WBS levels do we want our projects to have?” This was a question that designers of the PM process in a power distribution organization asked themselves. To prepare a good answer, they first looked at the projects they manage: 10 to 15 projects per year, ranging from $100k to $5m, mostly involving the design and construction of electrical substations. After some benchmarking, the designers made their decision: Each project shall have a five-level WBS.
Soon after the deployment of the PM process began, a silent rebellion in smaller projects began, followed by outright refusal of their project man- agers to use the process. The justification was simple. The amount of work on scheduling, budgeting, and control of 250 work packages in a five-level WBS drove smaller projects to a halt. As a result, project managers went to the old, ad-hoc way of management. The moral of the story: Match the size and structure of WBS with the size and structure of the project. The smaller projects likely could have been adequately organized and managed with three WBS levels.
As explained earlier, the work package is the central point for managing to the WBS, as illustrated in Figure 5.4. Simply said, work packages are discrete tasks, or combination of tasks, that have definable end results—outcomes—that assigned organizational units
“own” and need to create. When using them for the integration of project planning and control in a very detailed WBS, for each work package, you will assign responsibility, develop the schedule, estimate the resource and cost, develop plans for risk response and other planning functions, and measure performance. Obviously, as the number of work packages grows, so does the necessary time (and cost) to perform project planning and execution. Reaching a point when there may be too many work packages renders their management impractical and cost prohibitive. Closely related to the number of work packages is their average size. Clearly, work packages need to be small enough that they are manageable.
In summary, establishing the level of detail of the WBS includes determining the number of levels in the WBS, the number of work packages, and the average size of the work package that are compatible with your tolerance level and the industry practice.
Table 5.3 shows WBS data from some actual projects.
THE WORK BREAKDOWN STRUCTURE 131
ManufacturingEngineeringMarketing
Company Work
Package Work Breakdown Structure
Level 0
Level 1
Level 2
Level 3
Figure 5.4: Work Package, a Critical Link in Managing the WBS
Table 5.3: Examples of the Level of Detail of the WBS
(1) Project
(2) Project Duration
(days)
(3) Project Budget (person-
hours) (4)
# of Levels in WBS
(5)
# of Work Packages
(6) Mean # of Hours/
Work Package
(3) / (5) (7) Mean # of Days/
Work Package∗
(2) / (5)
(8) Mean % of Budget/
Work Package [(6) / (3)]
×100 IT
infrastructure
90 500 3 15 33 6 6.6
Selecting a billing platform
180 1200 4 36 33 5 2.7
S/W development
270 1200 3 25 48 11 4
Hardware development
365 500 4 29 17 13 3.4
∗Assuming all work packages are sequential without any overlapping.
From the table, you can derive the following guidelines for the majority of small and medium projects in the field of information technology, software development, and product development:
■ Three to four levels of WBS.
■ Fifteen to 40 work packages.
■ Twenty to 50 hours per average work package.
■ One to two weeks’ duration of the average work package.
■ Three to 7 percent of the total hours budget per average work package.
For larger projects, however, the level of detail often quoted in literature indicates17:
■ Five and more levels of WBS.
■ Eighty to 200 hours per average work package.
■ Less than two to four weeks per average work package.
■ From 0.5 percent to 2.5 percent of the total project budget per average work package.
Whether you manage a small or large project, these numbers should be adapted for your personal and possibly cultural preferences. For example, some individuals and com- pany cultures favor more detailed planning and control, and accordingly, more detailed WBS, while others have the opposite tendency.18
Structure the WBS
Once you are equipped with necessary information, along with the type of WBS and its level of detail, you are ready to construct a WBS for your project (see “Golden Rules of WBS Structuring”). The steps are outlined as follows:
Step 1: Start by identifying the major construct of structure of the WBS. Depending on the type of WBS you selected, these may be phases, systems, geographic areas, or a combination. One useful approach here is called thescope connection. In partic- ular, when developing the scope statement, you identify major deliverables, which could be borrowed to serve as the major elements of the WBS. This helps integrate the scope statement with the WBS, linking business and project goals—via major deliverables—with lower-level deliverables and work packages.
Step 2: Divide the major WBS elements into smaller, more manageable outcomes, level by level, until a point is reached where the outcomes are tangible, verifiable, and defined to the level of detail that enables them to be used for the integration of project planning and control activities.
Step 3: How will you represent your WBS? In the case of smaller projects, drawing a WBS as a tree diagram is a very visual and preferential way (see the upper part of Figure 5.4). As your number of WBS levels grows, so does the complexity, making it more difficult to stick with the tree format.
An alternative may be in the TOC (table of contents) format. For example, Figure 5.5 shows the TOC format for the WBS from Figure 5.4. To some extent this WBS construction process looks like a random process. Bringing more order to it is possible by following several guidelines (a shortened version appears in the
“Golden Rules” example).19
THE WORK BREAKDOWN STRUCTURE 133
Hardware Development Project Concept Stage 1000
2000 Design Stage 1100
1200
Project Kick-off 1110 1120
1220 1210
Materials Preparation
Project Plan Approval Integrated Plan Preparation Kick-off Meeting
Project Plan
2100 Design Review
2110 Design Concept 2120 Design Review Meeting
2130 DFMEA
2200 Prototype Approval 2210 UX Design Review 2220 Component 1st Article 2230 Quality Test
Figure 5.5: Table of Contents WBS Structure
Step 4: Make sure the WBS is outcome oriented. Since the WBS is about outcomes, activities and tasks should be relegated to the lowest levels of the WBS.
Step 5: Be sure that the WBS includes all project work. What is left out will not be resourced and scheduled, which is a risky proposition.
Step 6: Make each work element relatively independent of others on the same level.
Step 7: Keep breaking the work down into work elements until you reach a level at which there is a method in your organization capable of producing the element. Stop there.
It is an acceptable practice to have WBS branches of unequal length.
Step 8: Produce a WBS that integrates work elements or separate levels to the point that their aggregate is an equivalent of the project completion.
Golden Rules of WBS Structuring
■ Focus on documenting the project outcomes.
■ Show all project work.
■ Make objectives relatively independent.
■ Use symmetrical branches when justified.
■ Build the WBS as an integrated effort.
Evaluate the WBS Structure
Since the WBS development lacks the rigor and discipline of the scientific approach, there is no single correct WBS structure. Rather, there can be many different but equally good WBS structures. To make sure that your WBS is sufficient, you should evaluate it
against the preceding guidelines. If there is a need for some revisions, making them will ensure that you have created a WBS capable of acting as a framework for integration of project planning and control.
Increase Productivity through WBS Templates
Having each project team develop a WBS from scratch can create several problems. First, WBS development consumes resources. Also, when each project uses a different WBS type, the benefit of comparing various projects and drawing synergies is lost. These problems have been successfully cured by the use of WBS templates.
Specifically, this means adopting templates for certain project families. Highway construction projects are an example of a project family. Other families may include software development projects, manufacturing process projects, and hardware devel- opment projects. Generally, a family of projects is a group of projects that share identical or sufficiently similar project assignments. When the templates are developed and adopted, the development of a WBS for a new project is reduced to adapting the tem- plate. This saves time, produces a quality WBS, and enables interproject comparability.
In a nutshell, templates increase productivity.
Constructing a Project WBS: A Bottom-up Approach
Brainstorming all project work that needs to be performed and then organizing it into a WBS hierarchy is at the heart of the bottom-up approach. This approach, essentially an application of the affinity diagramming method, is beneficial to those without much project experience or those who do not prefer to take a systems approach.
Projects developing or deploying novel technologies, typically fraught with high uncertainty and lacking precedents, can benefit from this approach as well, even if the project team is experienced. Despite its brainstorming nature, the bottom-up approach may be preceded by collecting necessary information for the WBS development, selecting the type of WBS, and establishing the level of its detail—in other words, some of the steps taken in the top-down approach. Other steps in the bottom-up approach follow.
Generate a Detailed List of Outcomes
This step includes having each project team member brainstorm what is going to be created and delivered in the project. Each outcome may be recorded on a sticky note and posted in a visible place, with the number of generated outcomes ranging from 40 to 60—a good number for a small or medium-size project. Higher numbers may be required for large projects. In the process, adhering to the brainstorming principle of not critiquing the ideas is crucial.
Sort Deliverables in Related Groupings
The result of this step is the grouping of related outcomes. The aim may be to create groupings of five or so outcomes. Screen them carefully for relationships and group
THE WORK BREAKDOWN STRUCTURE 135
them into new groupings, striving to have three or four levels of groupings for small and medium projects, possibly more for larger projects.
Create Duplicates and Consolidate Outcomes
Project team members may have different and conflicting ideas about grouping out- comes. If that occurs, create duplicates of the outcomes and post them in the groupings suggested by the team members. Develop the discussion to understand the rationale for the conflicting groupings, and try to reach a consensus. If this is not possible, use a pre- ferred type of voting to decide on the final grouping. Also, consolidate similar outcomes and eliminate redundancies. This should give you the preliminary WBS hierarchy.
Create Names for the Groupings
The hierarchy needs names for groupings/outcomes on different levels. As much as pos- sible, the idea here is one of garnering consensus among team members. Spending enough time on naming the groupings/outcomes is useful for a good understanding of what is going to be delivered on the project, as well as for creating buy-in.
Evaluate WBS Structure
Similar to the top-down approach, bottom-up WBS development lacks the rigor and dis- cipline of the scientific approach, leaving room for mistakes. Therefore, this is the time to evaluate the WBS developed against the guidelines for structuring a WBS. Again, useful revisions and corrections are welcome, aiming at the improvement of the WBS to the level it needs to perform as a framework for integration of project planning and control.
The bottom-up approach is a good method for novice project managers and for use on unfamiliar projects. For full evaluation of its potential, we should recognize that it pro- vides an easy start, encourages strong involvement, and downplays vocabulary issues.
Its ease of use may give it an edge over the top-down approach, which requires more time to start and a shared vocabulary, and also limits team participation.
Using the WBS
The WBS was initially used to bring order to the integration of management work faced with large and complex projects in the government domain. Logically, then, most of the
“science” of the WBS was conceived in governmental agencies and is very well reflected and covered in the works of prominent PM books.20What is not well covered is how to adapt the science for what is the dominant stream of projects in today’s business world—dynamic small and medium projects. For these, the WBS is a must-have tool.
Whether you are in software or hardware development, marketing or accounting, man- ufacturing, infrastructure technology, or construction, practically any area and industry, small and medium projects benefit from a WBS to structure the project work. It is possi- ble to run a successful project without using a WBS, but the point is that probability of success is higher when a good WBS is used, as opposed to having an inappropriate WBS or not having one at all (see “Tips for WBS Use”).