Ads
  

Approaches to Building a WBS

Approaches to Building a WBS

A WBS can be organized in many ways, but it is generally best to arrange the activities around major work products and customer deliverables that will satisfy the customer's requirements. We make a distinction here between work products (anything tangible produced by the project, such as the charter, SOW, SPMP, SRS, SDD, code, test suites, etc.) and deliverables (work products that the customer cares about, executable code modules, documentation, etc.). Notice in "What Is a Work Breakdown Structure" Figure (a) that the hierarchical "tree" of information is:

●  the compiler.

●  the basic parts of the compiler.

●  the steps of the development process to build the basic parts of the compiler.

The first of these is the deliverable, the second are the major work product components of the deliverable, and the third are activities that would create the major components. This progression shows how the actions in the WBS branches directly correlate to the deliverable to be produced. Organizing a WBS around deliverables and the actions to produce those deliverables helps keep unnecessary work from being done on the project. Work that does not drive toward a deliverable is called "gold plating" and is not desirable.

Although organizing a WBS around the project's deliverables and work products is a good way to avoid planning extra work into the project, other arrangements are also possible. Sometimes it is more convenient to segment the work by organization at the top level rather than by deliverables or work products. This can provide a measure of control for the project by having the natural organizations that already exist be responsible for portions of the final work product. This improves command and control of the software project. Various possible arrangements for a work breakdown structure are demonstrated in Figure (a) as the basic elements of the project. Other elements could also be used, such as deliverables, skills, responsibilities, or chronology. In Figure (a), all the approaches assume that system-level decomposition has taken place and that only the software items are considered. Under System, the breakdown might have included hardware, software, and business processes.

Several Possible Arrangements for a Work Breakdown Structure

The WBS can be created from the top down or from the bottom up, as demonstrated in Figure (b). The top-down approach involves successive decomposition. The bottom-up approach uses brainstorming and affinity diagramming. Generally, at the beginning of a project when still in the what and how steps, the top-down approach is used. Often the tree view is used to depict the WBS because it doesn't have too many levels yet. This is a convenient representation for the project charter documents, and it helps the project manager identify the big components of work that will need to be done and to make rough order of magnitude (ROM) estimates for the work. These estimates will generally be based on a broad rule of thumb, such as extrapolation from previous similar software development projects or the gross size (large, medium, small) of the project and the type of software development life cycle anticipated. See "Software Size and Reuse Estimating"and "Estimating Duration and Cost" for more information on the detailed estimation of software.

Build a WBS Top-Down or Bottom-Up

The top-down approach is often used when the work has been done before and the project team understands the steps well. The top-down approach involves starting with the topmost item (usually a software deliverable, such as "Completed Software for C Compiler") and breaking it down from there, getting progressively more granular at each level. This continues until chunks of work that can reasonably be done by "one unit of resource" in a "relatively short period of time" have been reached. "One unit of resource" may be one person, one section, one department, or other organizational breakdown that makes sense for the work to be done. "Relatively short period of time" may mean one day, week, fortnight, month, or other unit that is of reasonable granularity for the scale of the project scope to provide good measurement during the execution of the project. Usually, for software development projects, a rule of thumb is to break down the work until the work can be done by one person or group over a one- to two-week period, producing one work product. This provides a good yardstick for preventing the "big bang" approach to managing deliverables.

The bottom-up approach is a good fit for a new type of project, when the project team is not very familiar with the steps that would be carried out. This approach is generally done by brainstorming everything that could be done during the project and then grouping the activities into similar levels of granularity (rough size of the work to be done) and arranging all the activities into ever-higher groupings until the top-level item is reached. This is affinity diagramming.

For either approach, avoid too much detail and granularity because it can make for very fragile plans. Don't plan in any more detail than you can manage. For instance, if it is thought to take about two weeks to design a certain code module, then breaking that down into the detail steps of data element identification, data flow diagram creation, and customer review is too much detail. At some point, the project manager relies on the engineering education of the team. One common fault is to produce too much detail at the initial planning stages. You should stop when you have a sufficient description of the activity to provide clear instruction for the people who will actually do the work and to have a reasonable estimate for the total effort involved. You need the former to allocate (or delegate) the activity; you need the latter to finish the planning.

Use teams and subgroups for chunks of work rather than individuals, trying to divide the work into natural groupings corresponding to organizational units. Arrange the work so that whole organizational units have responsibility to carry out activities at the lowest levels of the WBS. Also, because it is difficult to organize and manage work more than three to four levels deep in a WBS, try to limit the depth of the tree or indented list to something manageable. A very large tree is cumbersome to understand and navigate. Think of it as if it were a phone tree menu for a voicemail box. Too many sublevels frustrate the user and lead to confusion. Keep it as simple as possible, yet still express the structure and hierarchy of the project work. In "Software Size and Reuse Estimating" and "Estimating Duration and Cost", you will see how to use what is known about the desired software product to add more levels of breakdown to the product-oriented WBS as more information becomes known. Known as "progressive elaboration of characteristics", this is a cornerstone of most software development projects.



Tags

deliverables, project charter, life cycle, project scope, affinity diagramming
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2017 SPMInfoBlog.
Designed by TechPlus