Organizing and defining the project scope of work seems a natural enough step and a required
prerequisite to all analytical estimates concerning projects. Though constructing the logical relationships among the deliverables of the project scope appears straightforward, in point of fact developing the scope structure is often more vexing than first imagined because two purposes are to be served at the same time: (1) provide a capture vessel for all the scope of the project and (2) provide quantitative data for analysis and reporting to project managers and sponsors.
Work Definition and Scoping Process
The general process (input, methods, output) for scope or work definition and organization is given in Figure 3-1. Inputs to the process are assembled from all the ideas and prerequisite information from the business side of the project balance sheet that describe the desired outcomes of the project, including constraints, assumptions, and external dependencies. Methods are the steps employed in the scope definition process to organize this information, decompose the given material into a finer granularity of functional and technical scope, and relate various elements of the project deliverables to each other. The outcome of the work definition and scoping process is an "organization of the deliverables" of the project, often in hierarchical list or chart form, or in relational form that supports multiple views.
Figure 3-1: Work Definition and Scoping Process.
We should note that the "organization of the deliverables" is not an organization chart of the project in the sense of responsibility assignments, reporting, and administration among project members. The
"organization" we speak of is the logical relationship among, and definition of, the deliverables for which the project manager makes quantitative estimates for resources needs, risks, and schedule requirements on the project side of the project balance sheet. The name given to the organization of project deliverables is work breakdown structure (WBS). Suffice to say: all the scope of the project is contained in the WBS.
The process includes loops to validate and verify the completeness of the WBS. Validation refers to
determining that everything on the WBS is there for a reason and is not inappropriate to the project scope. Validation also determines the proper hierarchical level for all deliverables and ensures
hierarchical integrity. Verification is closely aligned with validation. Verification extends the concept back to the business owner or project sponsor to ensure that all scope has been accounted for and is on the WBS.
Multiple Views in Scope Organization
One purpose of the WBS organization is to serve the informational needs of those who will use the WBS in the course of managing and overseeing the project. Thus, the WBS should be organized to most effectively serve the management team. There are many possible ways to organize the information provided by the business, project team, project vendors, and others. Consider, for instance, these possibilities as illustrated in Figure 3-2: [2]
l Deliverables view: Because there are many points of view regarding project scope, more than one version of the WBS of the same project is possible as shown in Table 3-1. The preferred view is that of product or deliverables, focusing the WBS on the accomplishments of the project insofar as the sponsor or business is concerned. Unless otherwise noted, in this book the product or deliverable view will always be the view under discussion.
Figure 3-2: Project Views on the WBS.
l Organizational view: Some project scopes are organized according to the departments that will deliver the work. Organizational project scope may be appropriate if there are facility, technology, or vendor boundaries that must be factored into the scope structure. For instance, in the
semiconductor industry, there are usually quite significant boundaries between design, wafer fabrication, and end-device assembly and test.
l Methodology view: The methodology used to execute the project often influences scope, either temporally or in terms of scope content. Projects in different domains, for instance software development, building construction, and new consumer products, generally follow differing methodologies from planning to rollout and project completion, thereby generating many different deliverables along the way. These deliverables are often organized into methodology phases, or builds, on the WBS.
l Phases view: Scope phases that respond to the business needs or business capacity add a temporal dimension to the WBS organization. Ordinarily, the WBS is blind to time. In fact, a useful way to think of the WBS is that the WBS is the schedule collapsed to present time; in effect, the WBS is the "present value" of the schedule. Of course, the corollary is that the schedule is merely the WBS laid out on a calendar.
The Work Breakdown Structure
The WBS has been a fixture of project management for many years. [3] The WBS is simply the
organizing structure of the entire scope of the project. There is one organizing rule that governs overall:
if an item is on the WBS, then that item is within the scope of the project; if an item is not on the WBS, then that item is out of scope of the project. The WBS identifies the deliverables and activities that are within the scope of the project.
The WBS is most typically shown as an ordered hierarchical list, or equivalent chart or diagram, of project deliverables. By their nature, hierarchies have levels. A higher level is an abstract of all the levels below it and connected to it. For emphasis, let us term this concept the "completeness rule" for WBSs: to wit, an element at a higher level is defined by all of, but only all of, the lower level elements that connect to it. For example, "bicycle" is an abstract of lower level items such as frame, handlebar, seat, wheels, etc. all related to and connected to "bicycle," but on the other hand "bicycle" consists of
Table 3-1: Views of the Project Scope
View Scope Organization
Business owner or project sponsor
Organize by deliverables to the business required to make good on the business case
Business financial manager Organize by types or uses of money, such as R&D funds, capital funds, expense funds, O&M funds
Project manager Organize by methodological steps, such as design, develop, test and evaluation, training, and rollout
Project developer Organize by phases such as the baseline phase, upgrade phase, pilot phase, production phase
Manufacturing, operations, and maintenance provider
Organize by life cycle steps, such as plan, implement, manufacture, rollout, maintain
Customer or user Organize by deliverables to the user, such as the training and operational deliverables only available to the user
only lower level items such as frame, handlebar, seat, wheels, etc. all related to and connected to
"bicycle."
At the highest level of the WBS is simply "Project," an abstract of everything in the project. Typically,
"Project" is called level 1. At the next level is the first identification of distinct deliverables, and subsequent levels reveal even more detail. The next level is called level 2. Of course alpha characters could also be used, or alpha and numeric characters could be combined to distinctly identify levels and elements of the WBS. A couple of schemes are given in Figure 3-3.
Figure 3-3: WBS Numbering Schemes.
Deliverables are typically tangible, measurable, or otherwise recognizable results of project activity. In short, deliverables are the project "nouns." The project nouns are what are left when the project is complete and the team has gone on to other things. Of course, materiel items that make up an item, like nuts and bolts, are typically not identified as deliverables themselves. Following this line of thinking, project activities (for example, design, construction, coding, painting, assembling, and so forth) are transitory and not themselves deliverables. However, the project activities required to obtain the
deliverables are identified and organized by the scoping process. Activities are the actions of the project process; activities are the project "verbs. " The syntax of the WBS is then straightforward: associate with the "nouns" the necessary "verbs" required to satisfy the project scope.
Apart from showing major phases or rolling waves, the WBS is blind to time. [5] In fact, a useful way to think of the WBS is that it is the deliverables on the schedule all viewed in present time. It follows that all nouns and verbs on the WBS must be found in the project schedule, arranged in the same hierarchy, but with all the time-dependent durations and dependencies shown.
Work Breakdown Structure Standards
There are standards that describe the WBS. [6] Perhaps the most well known is the Department of Defense handbook, "MIL-HDBK-881." [8] As defined therein (with emphasis from the original), the WBS is:
l "A product-oriented family tree composed of hardware, software, services, data, and facilities.
The family tree results from...efforts during the acquisition of a...materiel item.
l A WBS displays and defines the product, or products, to be developed and/or produced. It relates the elements of work to be accomplished to each other and to the end product.
l A WBS can be expressed down to any level of interest. However (if)...items identified are high cost or high risk...(then)...is it important to take the work breakdown structure to a lower level of definition."
As a standard, MIL-HDBK-881 makes definitive statements about certain "do's and don'ts" that make the WBS more useful to managers. Table 3-2 summarizes the advice from MIL-HDBK-881.
Table 3-2: WBS Do's and Don'ts Scope Organization
Do not include elements that are not products. A signal processor, for example, is clearly a product, as are mock-ups and Computer Software Configuration Items (CSCIs). On the other hand, things like design engineering, requirements analysis, test engineering, aluminum stock, and direct costs are not products. Design engineering, test engineering, and requirements analysis are all engineering
functional efforts; aluminum is a material resource; and direct cost is an accounting classification.
Thus, none of these elements are appropriate WBS elements.
Program phases (e.g., design, development, production, and types of funds, or research, development, test, and evaluation) are inappropriate as elements in a WBS.
Rework, retesting, and refurbishing are not separate elements in a WBS. They should be treated as part of the appropriate WBS element affected.
Nonrecurring and recurring classifications are not WBS elements. The reporting requirements of the CCDR will segregate each element into its recurring and nonrecurring parts.
Cost-saving efforts such as total quality management initiatives, should-cost estimates, and warranty are not part of the WBS. These efforts should be included in the cost of the item they affect, not captured separately.
Do not use the structure of the program office or the contractor's organization as the basis of a WBS.
Do not treat costs for meetings, travel, computer support, etc. as separate WBS elements. They are to be included with the WBS elements with which they are associated.
Use actual system names and nomenclature. Generic terms are inappropriate in a WBS. The WBS elements should clearly indicate the character of the product to avoid semantic confusion. For example, if the Level 1 system is Fire Control, then the Level 2 item (prime mission product) is Fire Control Radar.
Treat tooling as a functional cost, not a WBS element. Tooling (e.g., special test equipment and factory support equipment like assembly tools, dies, jigs, fixtures, master forms, and handling equipment) should be included in the cost of the equipment being produced. If the tooling cannot be assigned to an identified subsystem or component, it should be included in the cost of integration,
Adding Organizational Breakdown Structure and Resource Assignment Matrix to the Work Breakdown Structure
In fact, the WBS is not one entity, but actually three:
l The WBS itself is the hierarchical structure of deliverables (nouns), and when applying the WBS in the context of contractor-subcontractor, the prime WBS is often referred to as the project or program WBS (PWBS) and the subcontractor's WBS is referred to as the contract or contractor WBS (CWBS).
l A structure similar to the WBS can be made for the organizations that participate in the project.
Such a structure is called the organizational breakdown structure (OBS).
l The OBS and the WBS are cross-referenced with the resource assignment matrix (RAM).
Figure 3-4 shows the three component parts working together.
assembly, test, and checkout.
Include software costs in the cost of the equipment. For example, when a software development facility is created to support the development of software, the effort associated with this element is considered part of the CSCI it supports or, if more than one CSCI is involved, the software effort should be included under integration, assembly, test, and checkout. Software developed to reside on specific equipment must be identified as a subset of that equipment.
Do's and don'ts are excerpted from MIL-HDBK-881.
Figure 3-4: WBS Components.
The RAM is where the analytical aspects of the WBS come into play. At each node of the RAM where there is an intersection of the OBS and WBS, the resource commitment of the organizations is allocated to the WBS. From the RAM, the resources can be added vertically into the WBS hierarchy and
horizontally into the OBS hierarchy. Such an addition is shown in Figure 3-5. Note that the following equation holds:
∑ (All WBS resources) = ∑ (All OBS resources) = Project resources
Figure 3-5: Adding Up the RAM.
Budgeting with the Work Breakdown Structure
From Figure 3-5, we see that OBS department budgets and WBS project budgets intersect. Eventually, these budgeted items must find their way to the chart of accounts of the business. Let us introduce additional nomenclature to go with the chart of accounts:
l The WBS itself is often numbered hierarchically for each work element identified. The WBS numbering scheme is sometimes called the "code of accounts." [9]
l At the lowest level of the WBS where cost is assigned, the WBS element is called a "work
package." The project manager assigns responsibility to someone on the project team for the work package.
l Work packages need not all be at the same level on the WBS. However, to make the WBS
uniform in level for data collection and reporting, "pull downs" of "dummy" levels are employed.
As an example, let us say that "bicycle" is decomposed down to level 3 with work packages 1.1.1 (stationary parts) and 1.1.2 (moving parts). Let us say that there is also a "wagon" on the WBS, and that "wagon" ends at level 4 with work package 1.2.1.1 (wheels) and 1.2.1.2 (axles). To create uniform metric reporting at the fourth level of the WBS we would create a "level 4 pull down" of
"bicycle" with dummy elements 1.1.1.1 (stationary parts) and 1.1.2.1 (moving parts) that have the
exact same content as their third-level parents. Similarly, there would be a fourth-level pull down for "wagon" for element 1.2.2. Our example WBS is illustrated in Figure 3-6.
Figure 3-6: Bicycle and Wagon.
l Cost accounts are roll ups of work packages and any in-between levels of the WBS. The project manager assigns responsibility for performance of a cost account to someone on the team, and, by extension, that person is responsible for the work packages that roll into the cost account.
Cost Accounts and Work Packages
Returning to Figure 3-5, we see that there are four work packages: A, B, C, and D. What, then, are the cost accounts? Typically, cost accounts are either one or more work packages rolled up vertically (project view) or horizontally (organizational view). Depending on the project management approach regarding "matrix management" and project responsibilities, either roll up could be possible. [10] So, there are either three cost accounts corresponding to "depart- ments 1, 2, and 3" or three cost accounts corresponding to "deliverables a, b, and c." We know from prior discussion that the total project expense is not dependent on whether the cost accounts are rolled up vertically or horizontally. Therefore, the choice is left to the business to decide how responsibility is to be assigned for project performance.
Now, let us consider the chart of accounts of the business. The chart might well be shown as in Figure 3-7. We see that Organization has expense and Project has expense. We would not want to count expenses in both categories since that would be counting the same expense twice. If both were fed to the chart of accounts, an accounting process known as "expense elimination" would be required to reconcile the total expenses reported. To avoid the accounting overhead to eliminate redundant expenses, the solution, of course, is not to connect one or the other roll up to the chart of accounts. That is, if the project is going to have an account on the chart of accounts, then the project expenses would not roll up under
department and organization; instead, project-specific, or direct, expenses would roll up under the project itself.
Figure 3-7: Chart of Accounts and the WBS.
We see also on the chart of accounts a place for capital accounts. From Chapter 1, we know that capital accounts represent asset values that have not yet been "expensed" into the business expense accounts.
Capital purchases made on behalf of projects are usually not recorded as project expenditures at the time the purchases are made. Rather, the practice is to depreciate the capital expenditure over time and assign to the project only the depreciation expense as depreciation is recorded as an expense in the chart of accounts. As capital is depreciated from the capital accounts, depreciation becomes expense in the expense accounts, flowing downward through the WBS to the RAM where depreciation expense is assigned to a work package.
In the foregoing discussion we established an important idea: the WBS is an extension of the chart of accounts. Just as a WBS element can describe a small scope of work, so also can a WBS element account for a small element of cost or resource consumption (hours, facilities usage, etc.).
Of course, not only is the budget distributed among the work packages on the RAM, but so also are the actual performance figures gathered and measured during project execution. Thus, work package actuals can be added across the OBS and up the WBS hierarchy all the way to the level 1 of the WBS or
Organization of the OBS. The variance to budget is also additive across and up the WBS. In subsequent chapters, we will discuss earned value as a performance measurement and forecasting methodology.
Within the earned value methodology is a concept of performance indexes, said indexes computed as ratios of important performance metrics. Indexes per se are not additive across and up the WBS. Indexes must be recomputed from summary data at each summarization level of the WBS or the OBS.
Work Breakdown Structure Dictionary
We add to our discussion of the WBS with a word about the WBS dictionary. It is common practice to define the scope content, in effect the statement of work, for each element of the WBS in a WBS dictionary. We see that this is an obvious prerequisite to estimating any specific element of the WBS.
Typically, the WBS dictionary is not unlike any written dictionary. A dictionary entry is a narrative of
Typically, the WBS dictionary is not unlike any written dictionary. A dictionary entry is a narrative of