The Work Breakdown Structure


WBS is the most important project management tool. With a good WBS, the project manager can develop every other tool needed to successfully manage the project. When done correctly, it is the basis for planning, scheduling, budgeting, and controlling the project.

What Is a Work Breakdown Structure?

A WBS is a structured way of decomposing a project into its various components—software, hardware, communications network, services, documentation, labor, testing, implementation, installation, and maintenance. In short, WBS is a formalized way of reducing the project into successively lower levels of greater detail.

There are two ways to represent a WBS. The first and most popular form is called the indented format. The indented format derives its name from the practice of indenting each successively lower level, as shown in Exhibit 2-3.

Exhibit 2-3: Indented WBS.

start example

WBS Number

Description

WBS Level

  • 1.0 Project or Contract Name

1

    • 1.1 Major Project Subdivision

2

      • 1.1.1 Task

3

        • 1.1.1.1 Subtask

4

          • 1.1.1.1.1 Work Package

5

            • 1.1.1.1.1.1 Components

6

end example

The graphical format, shown in Exhibit 2-4, resembles an organizational chart and is especially helpful for those who prefer visual representations. However, it requires a lot of space to develop, particularly for large, complex projects. Not all project management software supports the graphical format, but all of them support the indented representation.

Exhibit 2-4: Graphical WBS format.

start example

click to expand

end example

The WBS Levels

WBS levels refer to the successively lower tiers of detail beginning with the project name as the first level. Usually, a WBS is developed to the third or fourth level but rarely needs to be developed below the fifth level. There are two key points in WBS development. First, the level of development has nothing to do with the type of project, the industry, or the customer—private or public. It has to do with the complexity of the project. A WBS to the third level can easily describe a simple project of a few tasks. But a project such as building a house, hospital, or airplane requires a detailed WBS to at least the fifth level.

The WBS Levels Described

Each of the WBS levels are described as follows:

  • Level One. The project or contract name is always at this level.

  • Level Two. Entries involving the major subsystems of the project, complete entities, or sections of the project are at this level. For example, the major subsystems of an automobile design project would include the engine, chassis, interior, and body.

  • Level Three. Each level two entry also can consist of one or more major task activities. For example, if the level two subsystem is the engine, tasks might be the fan or carburetor, which are parts of the engine. These are designated as level three activities.

  • Level Four. Each level three activity can be decomposed into several more discrete entities, and so on, until the desired level of detail is achieved. For example, a subtask of the carburetor would be to design and build fuel jets. These level three subtasks are all entered into the WBS at level four.

  • Level Five. Decomposing level four tasks usually brings us to a level where the actual work can be assigned: the work package. The work package is identifiable with a person, a job, or a budget number and is where the actual project work is accomplished. The work package can occur anywhere below the first level, but usually occurs at the fourth or fifth level. The idea is to define the work package at a level where the project manager is comfortable that he can manage the work.

    An example of a fifth-level work package is the subtask of defining a valve for the fuel jets described at level four. This is a discrete work package, which can be given to an individual or group. Now a schedule and budget for the effort can be assigned.

A sample WBS is presented in Exhibit 2-5. Several key points about this example should be noted. First, the name of the project is at the first level. Second, not every major subsystem or subproject is decomposed to the same level. It is only necessary to decompose the elements of the WBS to the level at which it is possible to assign individuals, a budget, and a schedule to the task. Each project manager will have a different view of the required level of WBS decomposition. My level of comfort, relative to managing the project, might require that I decompose all the WBS elements to the fourth level, while you may be comfortable operating at the third level. The third thing to note about the sample WBS is that the lowest levels—that is, work packages—are described by a verb, while nouns describe higher levels. This rule of thumb is helpful in developing a WBS—when the element can be introduced by a verb; for example, develop, build, write, document. Then it probably is a work package and need not be decomposed to a lower level.

Exhibit 2-5: Sample work breakdown structure.

start example

1.0

Management Information Software System

1.1.

Gap Analysis

1.1.1.

Needs assessment

1.1.1.1.

Measure state of current system.

1.1.1.2.

Determine additional capability requirements.

1.1.2.

Develop alternative approaches.

1.2.

Requirements Specifications

1.2.1.

Develop preliminary software specifications.

1.2.2.

Develop detailed software specifications.

1.2.3.

Develop preliminary hardware specifications.

1.3.

Systems Engineering

1.3.1.

Develop alternative software approaches.

1.3.2.

Develop alternative hardware approaches.

1.3.3.

Develop cost estimates for each alternative approach.

1.3.4.

Determine best technical and most cost-effective approach.

1.3.5.

Develop preferred system architecture.

1.4.

System Design

1.4.1.

Develop preliminary system design.

1.4.1.1.

Design software modules.

1.4.1.2.

Design hardware subsystems.

1.4.1.3.

Integrate systems.

1.4.1.4.

Develop detailed system design.

1.5.

System Development

1.5.1.

Write code for system modules.

1.5.2.

Construct hardware subsystems.

1.5.3.

Develop prototype.

1.6.

Testing

1.6.1.

Write test plans.

1.6.2.

Test units.

1.6.2.1.

Test code.

1.6.2.2.

Modify code.

1.6.2.3.

Test hardware.

1.6.2.4.

Modify hardware.

1.6.3.

System testing.

1.6.3.1.

Integrate system.

1.6.3.2.

Test code.

1.6.3.3.

Modify code.

1.6.3.4.

Test hardware.

1.6.3.5.

Modify hardware.

1.6.4.

Prototype tests.

1.6.4.1.

Conduct prototype tests.

1.6.4.2.

Document test results.

1.6.4.3.

Modify module code/hardware.

1.7.

Develop Production Model

1.7.1.

Develop production tests.

1.7.1.1.

Conduct tests.

1.7.1.2.

Document test results.

1.7.2.

Conduct deployment.

1.7.2.1.

Deliver system.

1.7.2.2.

Install system.

1.7.3.

Maintain system.

1.7.3.1.

Detect/correct faults.

1.7.3.2.

Modify/enhance system.

1.8.

Project Management

1.8.1.

Assign project manager.

1.8.2.

Assign project engineer.

1.8.3.

Assign administrative assistant.

1.8.4.

Assign cost analyst.

end example

Note in Exhibit 2-5 that I included the project management functions as a line item entry. Although these functions are not tasks in the context of usual WBS elements, listing them is a good way to collect costs associated with the project management activity. Otherwise, the cost of project management time must be spread across each task in the project, a formidable effort. Therefore, rather than apportioning the project manager's time to every single task, it is much easier to include a separate WBS entry and provide one total cost for the estimated project duration.

The primary objective in developing a WBS is to ensure that every project task is identified. It is not an objective to determine or record the interdependencies of the tasks at this point. In fact, it is better not to think in terms of task dependencies until all tasks are identified. Concentrate on identifying all the tasks first, because if it is not in the WBS, it is not in the project. The network is the tool used to show task relationships.




Managing Information Technology Projects
Managing Information Technology Projects: Applying Project Management Strategies to Software, Hardware, and Integration Initiatives
ISBN: 0814408117
EAN: 2147483647
Year: 2003
Pages: 129
Authors: James Taylor

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net