THE PROJECT PROBLEM AND SOLUTION

Starting a new project is like starting to write a report—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 the most effective first step in writing.

An outline is a method for organizing material as well as a plan for the report itself. But when you start outlining a report, especially an extensive report (e.g. based on doing research by collecting data on the subject), 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 the time it will take to draft chapters, get reviews, and carry out the other steps involved in reviewing proofs and publishing the document. In the government, a significant amount of time needs to be scheduled for internal reviews and rewrites. Of course, many projects are much more complex than writing a report.

So where do you start? 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.” Let’s look a project where we “eat” an elephant. 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. Alternatively, a process of decomposition can be used, subdividing the project (in this case, the elephant) into major sections starting from the top and working down, 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.

FIGURE 1-2
Elephant Breakdown Structure—Top Level

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 can be individually identified; other body parts can also be identified, as can the tail and tuft. A WBS for a project 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 can be started as an informal list of activities, or it can be highly structured, depending on the project and its constraints as well as the planner’s skills. It can end at whatever level of detail 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 report, for example, some things happen almost automatically, growing out of the discipline of the process. The first is that you limit the contents of the report; there is a beginning and an end, with the contents in between. Preparing an outline of the contents forces you to define the topics, sections, chapters, and parts of the report. The same thing happens when you develop a WBS of a project. You consider assumptions and constraints, often without focusing on them directly.

Once you complete the detailed outline of a report, you have also defined the scope of the project to prepare the report, especially when the outline is annotated (as it should be). 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 an easy 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 all the products, services, or results (deliverables or end items) to be provided to the customer to meet the project objectives and organize them in a hierarchical framework.

Step 3. Identify other work that needs to be performed in the project, making sure that 100 percent of the work is covered. Specifically, identify work that (a) cuts across deliverables or is common to the deliverables (cross-cutting 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 for our simple project with report is shown in Figure 1-3.

In the early phases of a project, it may be feasible to develop only a two- or three-level WBS because the details of the work may not yet be defined. This is typical when the work is to be contracted out or outsourced. As the work on the project progresses into the project definition phase, the planning becomes more detailed and the WBS also becomes more detailed. The subdivisions of the WBS can be developed to successively lower levels at that time. Or the government may want to specify only the first two or three levels and then let the contractor specify the lower levels in a contract WBS (CWBS).

The final subcategories or work packages created in step 4 are the detail elements. These are the bites 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 decomposition or breakdown process is the completed WBS.

The following example demonstrates how to begin developing a WBS using the four-step process in a project to build a garage:

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) and agree on a hierarchical framework: The final products are 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 perform tasks like planning construction, obtaining permits, and awarding subcontracts.

FIGURE 1-3
Typical WBS: Project with Report

The WBS so far would look like that shown in Figure 1-4.

FIGURE 1-4
Top-Level Garage WBS

Level 1 is the total project and Level 2 is the first subdivision of the work 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 work, 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.

FIGURE 1-5
Garage WBS to Level 3

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; 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 part of the WBS. In fact, one of the primary purposes of the WBS is to provide a framework that helps you define the activities of the project. When the WBS is complete, it covers the total scope of the project.

FIGURE 1-6
Complete Garage Project WBS

Figure 1-7 is the same WBS in an alternate depiction of the “organization chart format.” It was prepared using WBS Chart Pro, a software package designed to help develop a WBS and then seamlessly transfer it to MSProject® software to develop the schedule.

For this display, the WBS numbers were added automatically by the software.

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, no heating, ventilation, and air conditioning (HVAC) system is shown; therefore, HVAC is not part of the project.

FIGURE 1-7
Complete Garage Project WBS in WBS ChartPro Format

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 on several considerations, including the following:

•  Size and complexity of the project

•  Culture of the enterprise

•  Structure of the organizations involved

•  Phase of the project (conceptual, planning, implementation, operations)

•  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 or proposed scope in an understandable form to 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. 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-8 and 1-9 show examples of WBSs that focus on the output products or deliverables of the project.

Figure 1-8 is a WBS for an aircraft project in which a passenger aircraft was converted into a freighter (by a government contractor). 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 considered cross-cutting because the work performed applies to or affects all or most of the other WBS elements at the same WBS level; thus, it “cuts across” other WBS elements. The WBS element system engineering is present in most WBSs involving engineering development. “Project management” is a common cross-cutting WBS element in all WBSs.

FIGURE 1-8
Example WBS for an Aircraft Conversion Project

FIGURE 1-9
Example WBS for a Software Project

Figure 1-9 presents a WBS for a generic government software development project where the goals and objectives are specified. The primary deliverable is the software itself; the secondary deliverables are the training materials and the user documents. The software system also has a cross-cutting work element labeled “system analysis,” which represents work such as project definition, workflow analyses, and structured analyses.

The WBS can be used, in whole or in part, to make work 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 the explanation of many aspects of the project and helps people who are newly assigned to the project understand the major work elements.

Responsibilities are normally assigned at the lowest WBS level, such as “coding” and “test” in Figure 1-9. 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.