What Is a Work Breakdown Structure

In simple words, a WBS is a hierarchical list of the work activities required to complete a project. It will contain managerial, administrative, integral, or developmental activities for:

● Doing the software development;

● Managing the project;

● Providing support for all of the project's activities;

● Any other activities required to meet the objectives of the project and the customer requirements, such as the creation of documents, training programs, tools for development, acquisitions, travel, and so on.

The WBS is a description of the work to be carried out, broken down into its key components, to the lowest level. By partitioning the project into manageable pieces this way, each component can be sized (see "Software Size and Reuse Estimating") and its effort can be estimated (see "Estimating Duration and Cost"). For software projects, most of the development effort is directly related to the size and complexity of the desired software product. "Getting Started with Software Sizing: Estimating Begins with Planning" Figure (a) is a description of the what and how implementation steps for a software development project. In this framework, the product-oriented WBS identifies activities at a level useful in locating available staff with the proper skills (see "Selecting a Project Team"). When the number of staff members and the skills of each are determined, the effort estimates (see "Software Size and Reuse Estimating") can then be applied to a calendar to determine the duration of the project and when project milestones are due (see "Scheduling the Work"). The resulting project schedule is normally shown as a Gantt chart (see "Scheduling the Work"). This completes the how planning step, and the project can be carried out. In carrying out, each WBS activity can be tracked throughout the project.

A product-oriented WBS includes process steps to build the product, organized around the product components. It drives the planning for the what and how steps, and provides the foundation for tracking of work activities, cost, and schedule in the do it step by giving the engineer or manager a global view. It is the "table of contents" for the work of the project. As such, it is an essential tool for the project manager.

Keep in mind that the triple constraint for projects is composed of scope, schedule, and cost. They relate directly to the software size, calendar due date, and resource effort that make software project managers lose sleep at night. The starting point, how to identify the goal and scope, was explained in "Defining the Goal and Scope of the Software Project". Now let's consider cost and schedule. As stated earlier, we require a product-oriented WBS to make budgetary and detailed estimates of the work to be done and to develop a realistic schedule. Particularly, we require the WBS for the following three project activities:

Cost estimating

● To make sure that all activities get estimated;

● To make sure that each element of the estimate corresponds to a necessary activity;

● To "roll up" costs of individual elements into total costs for subelements and for the system as a whole.

Cost accounting

● To assign work and "charge it" to appropriate cost centers based on specific WBS elements;

● To determine the actual cost of each element.

Schedule performance

● To monitor which activities are complete;

● To measure project progress.

As illustrated in Figure (a), the WBS can be related to cost accounts created for a project to control costs, and to the organizational breakdown structure created (or perhaps inherited from a parent organization) to manage the work. The WBS can map these together with a particular scheduled work item after the schedule has been built (see "Scheduling the Work"). On a large software project, this provides a cost basis for how much each piece of the final software system will cost to build, which is an important factor to pass on to future estimators of similar software products (see "Estimating Duration and Cost").

Work breakdowns can be explained in a number of different ways. An example of a common WBS viewed as a tree is shown in Figure (b). The tree view is most useful for high-level breakdowns of the work in the why and what steps of the project process framework.

Another representation for a WBS generally seen when the project planning gets detailed in the how step is as an indented list, illustrated in Figure (c). The indentations indicate the hierarchy as the levels do in a tree view. This is an excellent way to view the hierarchical structure of the work, when the work involves a lot of activities. Most people can readily relate to an outline format. Large indented lists are easily managed with a simple spreadsheet, permitting sorting in a variety of ways (by WBS code, responsibility, start date, etc.). Most project management scheduling tools can show the WBS as an indented list, but few show it as a tree. This is perhaps because the graphical tree can get extremely large and messy-looking on a project with many activities. However, plugs-ins can sometimes add this functionality to scheduling software tools.

Note in Figure (c) the use of a numbering scheme to label the items in the WBS. This is very helpful in distinguishing such generic activities as design, code, test, and document among various software components. In the example, 1.1.1.3 is the activity for coding the user interface, whereas 1.4 contains the activity for coding the installer script. It helps to be specific when labeling activities in a project. The numbering scheme removes ambiguity from the labeling. Most project scheduling software can automatically provide indenting and WBS or outline numbering. Notice also that similar work can be done at different levels of the WBS.

A WBS may be created for the two most common views of the project:

● A product view depicting hierarchical relationships among product elements (routines, modules, subsystems, etc.). But don't confuse this with a bill of materials.

● A project view depicting hierarchical relationships among work activities (process elements). This is often divided along organizational lines.

Both sets of elements and activities need to be considered in sizing and estimating the software to be built (see "Software Size and Reuse Estimating" and "Estimating Duration and Cost").

Usually, there is a unique work breakdown for each different life cycle that might be used by the organization. Even though most software development life cycles share many common activities such as decomposing system requirements, performing architectural design, creating test data, and managing the project, the ordering of these activities in each life cycle may be different. Some activities may be omitted under certain circumstances, such as prototype development, or for very small projects. Many organizations create WBSs to match these predefined life cycles of processes and activities (from a template such as IEEE 1074) that fit the typical kinds of projects that they do, such as completely new Web-based system applications, major enhancements to an existing system, or ad hoc special database projects. Many times, these are defined according to the size of the project: large, medium, or small. This concept was illustrated in "How to Use 1074 Figure 5". Some sample activity lists for seven predefined life cycles are presented in "Identifying the Tasks and Activities".

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.