Work Breakdown Structures for Projects, Programs, and Enterprises
382
Work Breakdown Structures for Projects, Programs, and Enterprises
382Paperback(New Edition)
-
SHIP THIS ITEMIn stock. Ships in 6-10 days.PICK UP IN STORE
Your local store may have stock of this item.
Available within 2 business hours
Related collections and offers
Overview
Product Details
| ISBN-13: | 9781567262285 |
|---|---|
| Publisher: | Berrett-Koehler Publishers |
| Publication date: | 08/01/2008 |
| Edition description: | New Edition |
| Pages: | 382 |
| Product dimensions: | 6.00(w) x 8.90(h) x 1.00(d) |
About the Author
Read an Excerpt
CHAPTER 1
Introduction to the Work Breakdown Structure
This chapter provides basic information about the work breakdown structure (WBS), including the background of the concept and its place and role in the project management process. Specifically, the chapter first discusses project management terms and definitions and explains why — on a very basic level — a work breakdown is needed. The chapter next illustrates where the WBS fits in the overall project management process and gives a history of the evolution of the WBS concept. Finally, the chapter briefly describes the role of the WBS in the private and public sectors.
PROJECT MANAGEMENT TERMS AND DEFINITIONS
Project management as a field of study has a set of acknowledged terms and definitions. The following segment presents key project management terms used frequently in this book. Although these terms are in common usage in the project management field, they are presented for reference and establish a terminology baseline.
THE PROJECT PROBLEM AND SOLUTION
Starting a new project is like starting to write a book — you have an idea of what you want to do but are not sure how to start. Many writers, like many project planners and managers, find that outlining is frequently the most effective way to start writing.
An outline is both a method for organizing material as well as a plan for the book itself. But when you start outlining a book, especially a book based on research, you realize there are many ways to do it. In general, you need to plan your research or data gathering; decide what goes in each chapter, including appendices; and take into account drafting chapters, getting reviews, and the other steps involved in reviewing proofs and publishing the document. A sample outline for a book is included in the form of a WBS in Chapter 10.
A frequently used analogy for any large project is the old question, "How do you eat an elephant?" The answer is, "One bite at a time." So the first step in preparing an outline or planning a project is to start defining and categorizing the "bites" (activities). The bites are important because they are where the useful work is accomplished. For a project, brainstorming can help define the bites from the bottom up, or a process of decomposition can be used, starting from the top, that subdivides the elephant into major sections working downward, as shown in Figure 1-2. In either approach, the objective is to develop a structure of the work that needs to be done for your project. This structure is the topic of this book.
The parts of the elephant can clearly be broken down (or subdivided) further. For example, the head is made up of a face, ears, tusks, and trunk; the four legs could be individually identified; other body parts could also be identified, as could the tail and tuft. A WBS for a project follows the concept just shown. The WBS is an outline of the work; it is not the work itself. The work itself is the sum of the many activities that make up the project.
A WBS may be started either as an informal list of activities or in a very structured way, depending on the project and the constraints, and can end wherever the planner wants it to end. The goal is to have a useful framework that helps define and organize the work.
In developing an outline for a book, some things happen almost automatically, growing out of the discipline of the process. The first is that you limit the contents of the book. Preparing an outline forces you to define the topics, sections, chapters, and parts of the book. The same thing happens when you develop a WBS of the project. You consider assumptions and constraints often without focusing on them directly.
When you complete the outline of a book, you have also defined the scope of the book, especially when the outline is annotated. The same thing happens in a project. An annotated WBS becomes an initial scope description. This is logical and elementary: If the outline (WBS) addresses all the work, then all the items described in the outline delineate all the work or the scope of the project.
Developing the WBS is a four-step process:
Step 1. Specify the project objectives, focusing on the products, services, or results that are to be provided to the customer.
Step 2. Identify specifically the products, services, or results (deliverables or end items) to be provided to the customer to meet the project objectives.
Step 3. Identify other work that needs to be performed in the project, to make sure that 100 percent of the work is covered; identify work that (a) either cuts across deliverables or is common to the deliverables (crosscutting elements), (b) represents intermediate outputs, or (c) complements the deliverables.
Step 4. Subdivide each of the work elements identified in the previous steps into successive logical subcategories until the complexity and dollar value of the elements become manageable units (work packages) for planning and control purposes.
A typical WBS is shown in Figure 1-3.
In the early phases of a project, it may be feasible to develop only a two-to three-level WBS because the details of the work may not yet be defined. However, as the project progresses into the project definition phase or planning phase, the planning becomes more detailed. The subdivisions of the WBS can be developed to successively lower levels at that time.
The final subcategories or work packages created in step 4 are the bites that we are going to use to "eat the elephant one bite at a time" — that is, to perform the project work. The product of this subcategorization process is the completed WBS. This book provides more complete explanations of steps 2, 3, and 4 in later sections.
The following example demonstrates how to begin developing a WBS using the four-step process in a project to build a garage for a new car:
Step 1. Specify the project objectives: Build a one-car garage with landscaping on the existing lot; the garage should have internal and external lighting and plumbing.
Step 2. Identify specifically the products, services, or results (deliverables or end items): The garage and the landscaped grounds.
Step 3. Identify other work areas to make sure that 100 percent of the work is identified: A project management function is needed to do such things as construction planning, get permits, and award subcontracts.
The WBS so far would look like that shown in Figure 1-4.
Level 1 is the total project, and Level 2 is the subdivision into the final products (a garage and landscaped grounds) plus "cross-cutting" work elements (work elements whose products apply to several work elements) needed for the project, such as the project management function. The total scope, 100 percent of the project, is represented by the sum of the work in the three Level 2 elements.
Step 4. Subdivide the elements until a level is achieved that is suitable for planning and control. The subdivision of each Level 2 element shown in Figure 1-4 is shown in Level 3 of Figure 1-5.
A further breakdown of some of the Level 3 elements could be performed. The complete WBS to the work package level (which is adequate for planning and control) is shown in Figure 1-6. The work package level is defined as the lowest level of each branch of the WBS; therefore, a work package may be at the overall Level 3 or 4 depending on the decomposition of the specific branch. The next level below the work packages is where the activities or tasks are performed.
In Figure 1-6, the WBS is presented in outline format rather than the space-consuming graphic format usually used. Either format is acceptable; this author prefers the graphic format, but the outline format is used when entering WBS data into project management software packages or to save space in documents.
The individual tasks or activities are located at the first level below the work packages and are not normally considered a part of the WBS. In fact, as discussed later, one of the primary purposes of the WBS is to provide a framework that helps you to define the activities of the project. When the WBS is complete, it covers the total scope of the project.
This mention of scope brings up a very important project management principle: Work not included in the WBS is outside the scope of the project. For example, in Figure 1-6, there is no heating, ventilation, and air-conditioning (HVAC) system shown; therefore, an HVAC is not part of the project.
After the WBS is established, it must be maintained and updated to reflect changes in the project. The configuration and content of the WBS and the level of detail of the work packages vary from project to project depending upon several considerations, including the following:
* Size and complexity of the project
* Culture of the enterprise
* Structure of the organizations involved
* Phase of the project
* Natural physical structure of the deliverable items
* Project manager's judgment of work allocations to subcontractors
* Degree of uncertainty and risk involved
* Time available for planning
The WBS is an excellent tool to use for communicating the scope of a project in an understandable form to the project team and other stake holders. At the end of the planning phase, the plans and schedules are frozen or "baselined" and become the basis for executing the work of the project in stages. At the same time, the WBS is baselined and becomes one of the key mechanisms for change management. Proposed work that is not in the WBS needs to be added to the project and to the WBS through formal change control processes.
Figures 1-7 and 1-8 show additional sample WBSs that focus on the output products or deliverables of the project.
Figure 1-7 is a sample WBS for a civilian aircraft project in which a passenger aircraft is to be converted into a freighter. The output products are a certified airworthy converted aircraft, technical manuals, and a list of spare part requirements.
This WBS contains a cross-cutting work element labeled "System Engineering" that encompasses the work necessary to define the conversion. It is called cross-cutting because the work performed applies to all or most of the other WBS elements at the same WBS level; therefore, it cuts across other WBS elements. The WBS element "System Engineering" is present in all WBSs. "Project Management" is also a common crosscutting WBS element.
Figure 1-8 presents a WBS for a software development project. The primary deliverable is the software itself, and secondary deliverables are the training materials and the user documents. The software system also has a cross-cutting work element labeled "System Analysis" that represents work such as project definition, workflow analyses, and structured analyses.
The WBS can be used, in whole or in part, to make assignments, issue budgets, authorize work, provide the basis for other data organization schemes, and explain the scope and nature of a project. Projecting the WBS on a screen at a meeting greatly facilitates explanation of many aspects of the project and helps people who are newly assigned to the project to understand the major work elements.
Responsibilities are assigned at the lowest WBS level, such as "coding" and "test" in Figure 1-8. The WBS serves as a common focal point for presenting the totality of a project. Note that the WBS is not an organization chart, even though its hierarchical structure is similar to that of an organization chart.
THE WBS IN THE PROJECT MANAGEMENT PROCESS
Managing projects is a continuous process. Figure 1-9 shows the 10 steps in the basic project management process. That process focuses on achieving the project objectives within the project management triad of time-cost-quality (performance) constraints and goals.
Each of the steps in the basic project management process has a specific output that is defined and documented. The steps are frequently iterative; circumstances that arise during specific steps may require revision of earlier steps and then repetition of all or part of the steps that follow the revised step. This constant iteration and replanning characterizes the day-to-day activities of the project manager and the project team.
Figure 1-9 shows the categorization of the basic project management process into five types of actions — initiation, planning, executing, controlling, and closing. The process of project management emphasizes the importance of planning before extensive project work begins and the importance of bringing the project to closure after all the work is done.
The WBS is the key tool in the planning phase, where the scope of work is defined, and at the completion of the planning phase, when the plan — including the WBS — is baselined. The WBS is omnipresent in virtually every aspect of managing the project. Therefore, it is very important to prepare the WBS early and correctly.
BACKGROUND OF THE WBS CONCEPT
The WBS is not a new concept in project management. This section provides some background that will assist in understanding the important role played by the WBS in managing projects effectively. This section also provides the basis for a later discussion of more complex aspects of the WBS.
Early U.S. Government Activities
In 1959, Malcolm, Roseboom, Clark, and Fazar published a classic paper describing the successful implementation of a technique called Program Evaluation and Review Technique (PERT). Although the WBS is not addressed directly in the paper, the graphics include a breakdown (Figure 1-10) that shows how the concept for a WBS was evolving.
By 1961, the term work breakdown structure was in common use. At that time a sample WBS was included in an article published within General Electric Corporation that explained the importance of a WBS in developing effective management control systems. Part of this WBS for the Fleet Ballistic Missile Maintenance Training Facility is shown in Figure 1-11.
The PERT and WBS concepts spread widely and swiftly. These management tools and their application, as developed between 1958 and 1965, are the basis for much of the project management body of knowledge used today.
The deliverables include equipment and equipment modification, documentation, trainers, and simulators. The WBS elements of management and installation are cross-cutting or support elements.
In June 1962, the U.S. Department of Defense (DoD), in cooperation with the National Aeronautics and Space Administration (NASA) and the aerospace industry, published a document intended to guide the systems design of the PERT COST system. That document included an extensive description of the WBS that is essentially the same description used today.
In October 1962, NASA published another document that expanded on its earlier discussion of the WBS. NASA stressed at that time that a top-down approach should be used in the development of the WBS to ensure that the total project was fully planned and that the derivative plans contributed directly to end objectives. It also stated that, in any integrated time/cost management system, both cost and time must be planned and controlled from a common framework.
Within the aerospace industry in the early 1960s, several companies were rapidly incorporating the concept of the WBS into their internal project planning operations. The author was using the WBS in his project planning in the Baltimore division, and the Orlando division of Martin Marietta (now Lockheed Martin) published a document that required the development of a WBS in its project planning when using PERT.
In August 1964, the U.S. government published the PERT Implementation Manual, which included a discussion of the WBS. That document was intended for use by government agencies as well as private and public institutions. That document also recommended a top-down approach to developing the WBS so that "detailed plans will not be developed outside a common framework." The authors stated that while it is apparent that plans, schedules, and network plans can be developed without a WBS, such plans and schedules are likely to be incomplete or inconsistent with project objectives and output products.
The development of a WBS in all the government and aerospace industry documents during this early period typically follows the same pattern. The planning begins at the highest level of the project with the identification of objectives and end items, and those are then broken down into logical elements.
(Continues…)
Excerpted from "Work Breakdown Structures for Projects, Programs, and Enterprises"
by .
Copyright © 2008 Management Concepts, Inc..
Excerpted by permission of Management Concepts Press.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Preface, xv,
Acknowledgments, xix,
Part I WBS Fundamentals, 1,
Chapter 1 Introduction to the Work Breakdown Structure, 3,
Chapter 2 Work Breakdown Structure Fundamentals, 33,
Chapter 3 WBS Software and the WBS in Software, 87,
Chapter 4 WBS Principles, Steps, and Checklist, 117,
Part II WBS Applications,
Chapter 5 Project Management Methodology and Operations, 127,
Chapter 6 Life Cycle Planning: Programs and Phases, 167,
Chapter 7 Portfolio Management and a Standard WBS, 187,
Chapter 8 Government Performance Management and the WBS, 203,
Chapter 9 The WBS in Construction Management, 217,
Part III WBS Examples and Descriptions,
Chapter 10 WBS Examples and Descriptions, 249,
Appendix A FAA Standard Work Breakdown Structure, 311,
Appendix B CSI Division List — 1995 Version, 317,
Appendix C The OmniClass(tm) Development Committee, 327,
Appendix D OmniClass(tm) Tables Edition 1.0, 331,
Appendix E OmniClass(tm) 2004 and 1995 Divisions, 343,
Appendix F Sample Page OmniClass(tm) Table 22, 349,
Appendix G Caltrans WBS, 351,
Appendix H The International Infrastructure Project Work Breakdown Structure (WBS), 357,
Bibliography, 367,
Index., 373,