Uh-oh, it looks like your Internet Explorer is out of date.
For a better shopping experience, please upgrade now.
- ISBN-10:
- 1567264565
- ISBN-13:
- 9781567264562
- Pub. Date:
- Publisher:
NOOK Book(eBook)
Overview
Related collections and offers
Product Details
| ISBN-13: | 9781567264562 |
|---|---|
| Publisher: | Berrett-Koehler Publishers |
| Publication date: | 10/01/2001 |
| Series: | Project Management Essential Library |
| Sold by: | Barnes & Noble |
| Format: | NOOK Book |
| Pages: | 122 |
| Sales rank: | 342,062 |
| File size: | 7 MB |
About the Author
Read an Excerpt
Effective Work Breakdown Structures
By Gregory T. Haugan
Management Concepts Press
Copyright © 2002 Management Concepts, Inc.All rights reserved.
ISBN: 978-1-56726-456-2
CHAPTER 1
Introduction to the Work Breakdown Structure
This introductory chapter provides information on the work breakdown structure (WBS), the background of the concept, and its place in the project management process.
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 and a plan for the book itself. There are many ways to outline a book, especially one based on research. In general, it is necessary to plan the research or data gathering, and decide what will be discussed in each chapter and the appendices. In addition, it is necessary to take into account drafting chapters, getting critical reviews from other experts, and the actual steps involved in reviewing proofs and publishing the document. A sample outline is included in the form of a WBS in Chapter 5.
A frequently used analogy is the old question: "How do you eat an elephant?" The answer, of course, is: "One bite at a time." So the first step in preparing an outline is to start defining and categorizing the "bites." The bites are important because that is where the useful work is accomplished. For a project, brainstorming can help define the "bites" or activities from the bottom up or a process of "decomposition" can be used starting from the top, and subdividing the project (or the entire elephant) into major sections and working down as shown in Figure 1-1. In either approach, the objective is to develop a structure of the work that needs to be done for the project.
It is obvious that the parts of the elephant can be broken down (or subdivided) further. For example, the head is made up of a face, ears, tusks, and trunk; the four legs can be individually identified; body parts identified, and the tail and tuft separated. A WBS for a project follows the same concept. The WBS is an outline of the work; it is not the work itself. The work is the sum of many activities that make up the project.
A WBS may start either as an informal list of activities or in a very structured way, depending on the project and the constraints, and it can end wherever the planner wants it to. The goal is to have a useful framework to help define and organize the work and then to get started doing it.
In developing an outline for a book, for example, some things happen almost automatically, growing out of the discipline of the process. First, boundaries need to be imposed on the book's contents. Preparing an outline forces the author to define the topics, parts, sections, and chapters. The same thing happens when the project's WBS is developed. Assumptions and constraints are often considered without focusing on them directly.
Developing the WBS is a four-step process:
1. Specifying the project objectives and focusing on the products, services, or results to be provided to the customer
2. Identifying specifically the products, services, or results (deliverables or end items) to be provided to the customer
3. Identifying other work areas in the project to make sure that 100 percent of the work is covered and to identify areas that cut across the deliverables, represent intermediate outputs, or complement the deliverables.
4. Subdividing each of the items in steps 2 and 3 into successive, logical subcategories until the complexity and dollar value of the elements become manageable units for planning and control purposes (work packages).
In the early phases of a project, it may be feasible to develop only a two- to three-level WBS, since the details of the work may yet be undefined. 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. These final subcategories or work packages are the "bites" that we are going to use to "eat the elephant" or to perform the project work. The product of this subcategorization process is the completed WBS.
For example, in a project to build a new garage for our new car, the steps are as follows:
• 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 for water.
• 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, obtaining permits, and awarding subcontracts.
The WBS so far would look like that shown in Figure 1-2. Level 1 is the total project and Level 2 is the subdivision into the final products (a garage and landscaped grounds) plus cross-cutting or complementary work needed for the project (such as project management). The project's total scope is represented by the work as the sum of the three Level 2 elements.
• Step 4. Subdivide the elements until a level is achieved that is suitable for planning and control: The next level subdivision of each Level 2 element is shown in Figure 1-3.
Further breakdown of some of the Level 3 elements can be performed. The complete WBS to the work package level, which is adequate for planning and control, is shown in Figure 1-4. In this figure, the WBS is presented in outline format rather than the space-consuming graphic format used previously. Either format is acceptable. The outline format is generally used when entering WBS data into project management software packages or to save space in documents.
At the next level below the work packages are the individual tasks or activities. These are not normally considered a part of the WBS. In fact (as discussed in Chapter 2), one of the primary uses of the WBS is to provide a framework to assist in defining the activities of the project. When the WBS is complete, it covers the total scope of the project.
This 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-4, there is no heating, ventilating, and air conditioning (HVAC) system shown; therefore, an HVAC system is not part of the project.
Once 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 specific work packages vary from project to project depending upon several considerations:
• Size and complexity of the project
• Structure of the organizations involved
• Phase of the project
• Project manager judgment of work allocations to subcontractors
• Degree of uncertainty and risk involved
• Time available for planning.
The WBS is a marvelous communication tool to present the project's scope in an understandable form and to coordinate this understanding within the project team and between the project team and other stakeholders. 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. At the same time, the WBS is baselined and becomes one of the key mechanisms for change management. Work that is proposed that is not in the WBS needs to be added to the project and to the WBS through formal change control processes.
The following charts show two additional sample WBSs. They focus on the output products or deliverables of the project. Figure 1-5 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 set of work activities labeled "system engineering" that encompasses the work necessary to define the conversion. This is a common type of WBS element.
The second sample, Figure 1-6, is a software development project; the primary deliverable is the software system and the secondary deliverables are the training materials and the user documents. The software system also has a cross-cutting set of work activities labeled "system analyses" that represents work such as project definition and workflow analyses or structured analyses.
The WBS can be used, in whole or in part, to make assignments, issue budgets, and explain the scope and nature of a project. Responsibilities are assigned at the lowest level — the work package level — or the next level — the task or activity level. The WBS serves as a common focal point for presenting the totality of a project.
BACKGROUND OF THE WBS CONCEPT
The WBS is not a new concept in project management and some background will assist in understanding its important role.
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," or PERT. Although the work breakdown structure is not addressed directly, the graphics include a breakdown in illustrating how this concept was evolving (see Figure 1-7).
The PERT and WBS concepts spread widely and swiftly. These management systems and their application, as developed between 1958 and 1965, are the basis for much of the project management body of knowledge used today. By 1961, the term work breakdown structure was in common use. A sample of a WBS was included in an article published within General Electric Corporation. Part of this WBS was for the Fleet Ballistic Missile Maintenance Training Facility, shown in Figure 1-8.
The output products include modification of government-furnished equipment, other equipment, documentation, trainers, and simulators. The other elements of management and installation are cross-cutting or support elements.
In June 1962, the 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. This document included an extensive description of the WBS that is essentially the same as used today.
In October 1962, NASA published another document that expanded on the discussion of the WBS in the NASA DoD Guide to PERT Cost. NASA stresses that a top-down approach is used in the development of the WBS to ensure that the total project is fully planned and the derivative plans contribute directly to end objectives. Also, that in any integrated time/cost management system, it is imperative that both cost and time are planned and controlled from a common framework.
Within the aerospace industry, the various companies were rapidly incorporating the concept of the WBS into their internal project planning operations. The author was using the WBS in his planning in the Baltimore Division and the Orlando Division of Martin Marietta (now Lockheed Martin), and published a document that included the required 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. This document was intended for use by any government agency or private or public institution. In this document, a top-down approach to developing the WBS also is espoused so that "detailed plans will not be developed outside a common framework." The authors stated that plans, schedules, and network plans can be developed without a WBS, but such plans and schedules are likely to be incomplete or inconsistent with project objectives and output products.
The development of a WBS in all government and aerospace industry documents typically follows the same pattern. The planning begins at the highest level of the project with identification of objectives and end items. When developing the WBSs for large military systems such as those that existed in the 1960s, it became apparent that the top two or three levels were very similar for each family of systems; that is, the end items and the next level decomposition of the end items were the same. For example, all aircraft have wings, engines, a fuselage, empennage, landing gear, etc., regardless of whether they are transports, fighters, or bombers.
In 1968, DoD developed a standard for the top-level decomposition of work breakdown structures for DoD systems. This document was made mandatory for application to all defense projects estimated to exceed $10 million using research, development, test, and engineering funds. On January 2, 1998, MIL-HDBK-881 updated and superseded the MIL-STD-881 documents. Because of a change in DoD philosophy, the handbook cannot be cited as a contractual obligation. However, other DoD documents specifically require a WBS.
MIL-HDBK-881 is still directed at defense materiel items. The WBS templates for the same seven DoD systems that were in the original standard are still included in the handbook. The handbook includes the top three levels of the WBS and the associated descriptions (WBS dictionary) for the following systems:
1. Aircraft systems
2. Electronic/automated software systems
3. Missile systems
4. Ordnance systems
5. Ship systems
6. Space systems
7. Surface vehicle systems.
Figure 1-9 presents the ship system WBS as included in the handbook.
The levels below those described in the handbook are usually defined by the contractor and are unique to each project. It is not unusual for five to eight additional levels to be identified in these types of large systems.
The Project Management Institute and the PMBOK® Guide
The lead in monitoring and documenting project management practices transitioned from the public to the private sector with the reductions in the space program, the end of the cold war, and the rapid growth of the Project Management Institute (PMI®).
The Role of the Project Management Institute
PMI®, a professional association of over 70,000 members, through its conferences, chapter meetings, the monthly magazine PM Network, ® and the quarterly Project Management Journal® provides a forum for the growth and development of project management practices. In August 1987, ® published a landmark document entitled The Project Management Body of Knowledge. This document was revised, entitled A Guide to the Project Management Body of Knowledge, republished in 1996, and updated in 2000.
The PMBOK® Guide reflects the 30 years of experience gained in project management since the seminal work of DoD, NASA, other government organizations, and the aerospace industry in the 1960s.
The PMBOK® Guide
The PMBOK® Guide includes widely applied, proven, traditional practices as well as knowledge of innovative and advanced practices that have more limited use but are generally accepted.
The PMBOK® Guide is not intended as a "how to" document, but instead provides a structured overview and basic reference to the concepts of the profession of project management. The PMBOK® Guide focuses on project management processes.
The PMBOK® Guide is not as explicit as is the MIL-HDBK-881 and the other U.S. government documents on the development of the WBS. There are some differences, as might be expected with 30 additional years of experience. The PMBOK® Guide addresses a broader audience than the DoD documents, including all commercial applications and experience since the 1960s. In addition to the discussion of the WBS in the PMBOK® Guide, PMI® is in the process of developing a Practice Standard for Work Breakdown Structures that is intended to be more universal in application than the comparable DoD handbook. The Practice Standard is scheduled for publication in 2001, and will complement this book in the same manner that the PMBOK® Guide complements other books on project management topics.
(Continues...)
Excerpted from Effective Work Breakdown Structures by Gregory T. Haugan. Copyright © 2002 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
Contents
Foreword,Preface,
CHAPTER 1 Introduction to the Work Breakdown Structure,
CHAPTER 2 Work Breakdown Structure Fundamentals,
CHAPTER 3 Lifecycle Planning: Programs and Phases,
CHAPTER 4 The WBS in Project Operations,
CHAPTER 5 WBS Examples and Descriptions,
CHAPTER 6 WBS Principles, Steps, and Checklist,
Bibliography,
Index,
Customer Reviews
