Building a WBS for Software

Building a WBS for Software

The WBS is the key work product needed to do software project estimating. In many projects, what hurts you the most are not the things that you estimate poorly, but the things that you forget to include at all. In preparation for sizing the work to be done (see "Software Size and Reuse Estimating" and "Estimating Duration and Cost"), follow the process in this section as a framework for estimating. As stated earlier, there is a top-down and a bottom-up approach to building any WBS. In planning any project, follow the simple rule: If an item is too complicated to manage, it becomes a list of simpler items. Here are five steps to creating a WBS for a software project:

1.  Identify the work concerning the software product (separate from hardware and work processes).
2.  Find any higher system WBS (separate the software from other systems and components).
3.  Determine the software WBS architecture (how to organize this software product and project).
4.  Populate the software WBS architecture (identify all the parts and activities to produce them).
5.  Determine cost categories for software (prepare for estimation activities).

Identify the Work Concerning Software

Go through the available documentation (that is, whatever is available to you at this point in the project) and make a complete list of all items that might impact the cost of building the software. Many possible source documents might be available:

●  SOW (usually the best item to start with);

●  Specifications, concept of operation;

●  Requirements documents of many kinds;

●  Design documents;

●  Standards (internal and external);

●  Customer conversations;

●  Test criteria or expectations.

The list should contain the what and where of each item, for trace reasons, as shown in Figure (a). This helps ensure that nothing is overlooked.

Example List of Items Affecting Software Work

Find Any Higher System WBS

Find out whether there is a WBS for any higher system (higher project or program) and how the software fits in. Many organizations have a standard WBS architecture that describes where the software will appear. Many project managers for systems development projects will establish a WBS that has requirements applicable to software broken out separately. Figure (b) illustrates two such possible breakouts. It is important to discover where the software fits relative to higher-level activities because this may affect how the software project portions are structured and run. For instance, the systems project manager may have a particular approach to the ordering of WBS items, the number of levels to show, where to show certain kinds of costs, and so on.

Example Higher Level WBS Showing Where Software Might Be Placed

The approach on the left in Figure (b) shows software as an embedded item under hardware in a systems project. The right side shows software as a separate but equal item with the hardware. Separate but equal may tend to separate software planning from the rest of the system, resulting in inconsistent interpretations of requirements.

Determine the Software WBS Architecture

Determine a logical structure (architecture) for the software portion(s) of the WBS. As explained earlier and shown in "Approaches to Building a WBS" Figure (a), there are many possible architectures for a software WBS. Some organizations have a standard software WBS architecture to ensure consistency and make it easier to track costs. Different software products and different software development life cycles followed may need different WBS structures. Figure (c) shows possible software architectures using approaches A and C from "Approaches to Building a WBS" Figure (a).

Example WBS Architectures for Software

Populate the Software WBS

Populate the chosen WBS structure with activities that address the work identified in the available documentation (SOW, etc., from Step 1). Derived from the information in Figures (a) and (c), the cross-reference matrix in Figure (d) shows standard WBS items for the software on the right. On the left are the corresponding source documents, paragraph numbers, and descriptions that caused creation of the WBS items on the right. This enables you to be sure that all work is accounted for, and it reduces the chances that something will be omitted from the WBS. If a single SOW paragraph is reflected in various WBS elements (or vice versa), you can make various separate entries in the cross-reference matrix. This is where the WBS can become a requirements trace tool, or can be supplemented by one. Sometimes the standard WBS is more detailed than what the source documents state. In such cases, always trace to the highest level that makes sense, to avoid excessive detail.

Example Cross-Reference Matrix for Software

Determine Cost Categories for Software

Determine the cost-estimating category for each element in the WBS. This final step is not always necessary for every project, but it will be important for those that track unit-level costs in a WBS (see "What Is a Work Breakdown Structure" Figure (a)). If this step is not done here, it needs to be done later, during the cost estimating process. Some projects use only one category of costs for simplicity. Normally, only hours are estimated. More complex projects may require more categories because different units are required. The cost-estimating category decides how the cost for each item will be estimated as shown in Figure (e). Things such as capital equipment are generally estimated in currency, whereas effort is usually estimated in hours, weeks, or months of labor, which can readily be translated into units of currency. Overhead items such as project management, change control, and configuration management are estimated by using a proportional add-on to the basic software effort (a percentage).

Example Cost Categories

Applying the Five WBS-Building Steps

Some items from Step 1 will be scattered throughout many WBS elements. An example is the need to use a particular standard or a particular programming language for the project. Some items from Step 1 will not seem to fit anywhere because some items in the organization's standard WBS may not be explicitly stated in source documents for this project. Examples of such items are training, project management, facilities needs, and development tools.

These project-supporting functions are generally shown as a separate branch on the WBS tree. After the WBS is constructed and validated, with its accompanying and supporting items such as the cross-reference matrix, it can serve as a framework for all the activities that will be done on the software development project. It is the software project's table of contents.


software project, wbs, life cycle, software planning, software architectures
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