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.

FIGURE 1-1 Elephant Breakdown Structure

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).

KEY DEFINITIONS

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.

FIGURE 1-2 Top-Level Work Breakdown Structure

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.

FIGURE 1-3 WBS to Level 3

FIGURE 1-4 Garage Project Work Breakdown Structure

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.

FIGURE 1-5 Sample WBS—Aircraft Conversion Project

FIGURE 1-6 Sample WBS—Software Project

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.

FIGURE 1-7 Early Polaris Project Work Subsystems

FIGURE 1-8 Work Breakdown Structure—1961

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^®).

FIGURE 1-9 Ship System WBS

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, ^®16 and the quarterly Project Management Journal^®17 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.

The PMBOK^® Guide follows early government experience in the area of decomposition, which is described as: “subdividing the major project deliverables or subdeliverables into smaller, more manageable components until the deliverables are defined in sufficient detail to support development of project activities (planning, executing, controlling, and closing).”¹⁹

The PMBOK^® Guide versus DoD

On the surface, the primary difference between the PMBOK^® Guide and the DoD handbook appears to be the philosophy of how decomposition may be accomplished. The PMBOK^® Guide states: “… the major elements should always be defined in terms of how the project will actually be organized.” ²⁰ The DoD handbook states: “A WBS should not influence or in any way affect the contractor’s program organization.”²¹ One of the universal principles of developing a WBS is that it is not an organizational chart. The wording in the PMBOK^® Guide should be interpreted in terms of how the work is organized, not the human resources organization structure.

The PMBOK^® Guide also uses the example of the phases of the project lifecycle as the first level of decomposition. On the other hand, the DoD handbook states: “Program phases … are inappropriate as elements in a work breakdown structure.”²² Also, while the DoD handbook does not permit lifecycle phases to be elements of the WBS, this is a DoD-peculiar restriction and relates to the DoD definition and use of a program WBS. Chapter 3 discusses the use of phases as the program’s top level WBS and the differences are reconciled between the PMBOK^® Guide and the DoD approach.

WBS Element Descriptions

The classical approach to the WBS generally identifies the elements in the WBS as being described by nouns and modifiers. Further, the WBS can be thought of as the response to the question: “What has to be accomplished in the project?”²³ The network diagram developed from the definition and relationships of activities answers the question: “How will it be accomplished?” and the schedule resulting from the network calculations responds to: “When will it be accomplished?”

There have been some recommendations that PMI^® accept activity-like descriptions in the WBS that would include verbs. However, the basic traditional approach is sound and proven, and the use of activities—like descriptions in a WBS—should be limited to those cultures where any other approach is unworkable. Activities, by definition, are action entities and include verbs in their descriptors.

This book follows the philosophy that the WBS structure must be related to the objectives of the project and therefore produces the unique product, service, or results as PMI^® defines a project. The WBS must be an end-item or deliverable-oriented, and the WBS is preferably composed of elements that can be described by nouns modified by adjectives as necessary for clarity. The reason to prefer this type of description is the discipline of focusing on the output products, which are usually things that are described by nouns. Using verbs implies action, which is ideally performed at the activity level below the lowest level of the WBS.

For the WBS to be fully understandable to persons other than the developer, a separate document defining the content of each element is often needed. (This is called a WBS dictionary and is discussed in Chapter 2). However, by using longer phrases, often including verbs in the element descriptors, the work content of the WBS element can sometimes be described sufficiently to eliminate the need for a WBS dictionary. The project environment and the project itself should determine the nature of the descriptors used for the elements of the WBS. It is necessary to have a set of WBS descriptors that help stakeholders understand the work represented by each element.

One of the primary purposes of the WBS is communication. It is therefore necessary to have a format with which the audience can identify. It is then possible for activities—verb statements—to be included in the WBS. However, it is important that the WBS be based on the deliverables—the output products of the project—regardless of how the elements are described. (See Chapter 2 for the relation of WBS elements to work packages and activities.)

The material in this book follows the PMBOK^® Guide, or more correctly, the PMBOK^® Guide reflects the body of knowledge of WBS use addressed herein.

THE WBS IN THE PROJECT MANAGEMENT PROCESS

Managing projects is a continuous process. Figure 1-10 illustrates the basic project management process. It focuses on achieving the project objectives within the project management triad of time-cost-quality (performance) constraints and goals.

Each of the ten steps has a specific output that is defined and documented. The steps are frequently iterative; that is, circumstances arising in accomplishing later steps may require revision of an earlier step and subsequent repetition of all or part of the succeeding steps. This constant iteration and replanning characterize the day-to-day activities of the project manager and the project team.

The basic project management process has five types of activities: initiation, planning, execution, controlling, and closing (see Figure 1-10). This categorization emphasizes the importance of planning before extensive project work begins and the importance of bringing the project to closure once all the work is done.

FIGURE 1-10 Basic Project Management Process

The WBS is the key tool in the planning phase, where the work is defined, and, at the completion of the planning phase, when the plan—including the WBS—is baselined. Chapter 4 discusses the WBS being omnipresent in virtually every aspect of managing the project. Therefore, it is very important to prepare the WBS early and correctly.

NOTES

1. M.L. Keene, Effective Professional Writing (Lexington, MA: D.C. Heath and Company, 1987), p. 32.

2. Project Management Institute Standards Committee, A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) (Upper Darby, PA: Project Management Institute, 2000).

3. PMBOK^® Guide, p. 97.

4. DoD and NASA Guide, PERT/Cost Systems Design (Washington, D.C.: Office of the Secretary of Defense, National Aeronautics and Space Administration, June 1962), p. 3.

5. D.G. Malcolm, J.H. Roseboom, C.E.Clark, and W. Fazar, “Application of a Technique for Research and Development Program Evaluation,” Operations Research, The Journal of the Operations Research Society of America, 7, No. 5 (September–October 1959): 646–669.

6. W. F. Munson, “A Controlled Experiment in PERTing Costs,” Polaris Projection, GE Ordnance Department, November 1961.

7. DoD and NASA Guide, PERT/Cost Systems Design (Washington, D.C.: Office of the Secretary of Defense, National Aeronautics and Space Administration, June 1962).

8. Ibid., pp. 26 –34.

9. National Aeronautics and Space Administration, NASA PERT and Companion Cost System Handbook (Washington, D.C.: Director of Management Reports, National Aeronautics and Space Administration, October 30, 1962).

10. Central PERT Department, Product Programming, Orlando Division, PERT Time, Martin Marietta, Document OR 3424, Volume I, September 1963, pp. 2-3.

11. U.S. Government Coordinating Group, PERT Implementation Manual, Draft Copy, August 1964.

12. Ibid., p. VI.4.

13. Department of Defense, MIL-STD-881, Work Breakdown Structures for Defense Materiel Items (Washington D.C.: Headquarters, Air Force Systems Command, Directorate of Cost Analysis, 1 November 1968).

14. DoD Regulation 5000.2-R.

15. Department of Defense, MIL-STD-881, Appendix E.

16. “PM Network^®“ is a trademark of the Project Management Institute, Inc., which is registered in the United States and other nations.

17. “Project Management Journal^®“ is a trademark of the Project Management Institute, Inc., which is registered in the United States and other nations.

18. PMI^® Standards Committee, PMI^® Practice Standard for Work Breakdown Structures, Exposure Draft Version (Newtown Square, PA: Project Management Institute, October 2000).

19. Project Management Institute Standards Committee, A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) (Upper Darby, PA: Project Management Institute, 2000), p. 58.

20. PMBOK^® Guide, p. 58.

21. MIL-HDBK-881, paragraph 3.1.3.

22. Ibid., paragraph 2.2.5.

23. U.S. Government PERT Coordinating Group, p. VI.3.