Creating the Work Breakdown Structure

Creating the Work Breakdown Structure

If you have obtained a project charter and an excited customer, why go to the trouble to build a work breakdown structure? After all, aren't you a software engineering professional? The work breakdown structure (WBS) is the heart of a project plan, as most of the other parts of a project are built from it. The WBS is the tool used to document all the work that must be done to develop and deliver the software in a satisfactory manner. Although it may seem that the information that it contains is redundant with some of the other various documents that a software development project generates (scope of work, software requirements specification, design document, etc.), it serves to merge information from many sources into one place and into an organized format, convenient for planning, estimating, and tracking.

A WBS serves as a framework around which to build the project schedule. It helps you move from the top-level activity of the project (the do it activity) down through a set of simpler, smaller activities designed to build the software product deliverable, until the activities become small enough to manage well. It helps everyone understand the relationships of tasks and activities to each other in an illustrated way. It helps make sure that all the work is represented and that no work steps have been excluded. It also helps the project team divide the work to be done into small, well-defined tasks and activities. Of course, the WBS also helps planning, estimating, and scheduling, and it is a basis for monitoring the project and for historical data collection. (You will see "Getting Started with Software Sizing: Estimating Begins with Planning" Figure (a) for an illustration of how building the WBS is part of the big picture for software estimating.) It allows us to dismiss, "We're 90% done", and replace it with, "We've completed 97 of 234 planned activities". Weighted tasks and activities become meaningful and can be associated with a cost estimate.

Where We Are in the Product Development Life Cycle

Where are we in the product development life cycle model that serves as our map? As shown in Figure (a), we are still near the beginning, in fact preconcept exploration. As discussed in "Defining the Goal and Scope of the Software Project", we are in the why, what, and how planning steps of the project process framework for a given project instance (shown in Figure (b). In the why step, we need to know which software development life cycle model will likely be used, and we need to have it broken down into enough detail to make a rough order of magnitude estimate of the work. This is necessary to develop a reasonable return on investment (ROI) for the project work. In the what step, we use it to predict the expected work product outputs from the software development life cycle selected. In the how step, we need the WBS to make budgetary and detailed estimates of the work to be done, and to develop a practical schedule. There will be more on how to use what is known at this point in the project's life to do software product sizing and estimating ("Software Size and Reuse Estimating" and "Estimating Duration and Cost"), and then to prepare a realistic schedule for the work to be done ("Considering Dependencies" and "Scheduling the Work").
Product Development Life Cycle

Project Process Framework

"Creating the Work Breakdown Structure" Relation to the 34 Competencies

This section is relevant to the competencies shown next. Creating the work breakdown structure (WBS) is one of the most important parts of any project because it creates the centerpiece of any project plan around which all activities derive. After the project goal and scope are defined at a high level and proper approvals are acquired, then fleshing out and customizing the work according to the defined life cycle model chosen begins. This process is directly related to the competencies of product definition and process tailoring, and to building the WBS. It is indirectly related to documenting plans and estimates, and it uses the people skills of interaction and communication, leadership, negotiation, and sometimes presentation.

Product Development Techniques

3. Defining the product - Identifying customer environment and product requirements
9. Tailoring processes - Modifying standard processes to suit a project

Project Management Skills

12. Building a work breakdown structure - Building a WBS for a project
13. Documenting plans - Identifying key components
14. Estimating cost - Estimating cost to complete a project
15. Estimating effort - Estimating effort required to complete a project

People Management Skills

26. Interaction and communication - Dealing with developers, upper management, and other teams
27. Leadership - Coaching project teams for optimal results
29. Negotiating successfully - Resolving conflicts and negotiating successfully
31. Presenting effectively - Using effective written and oral skills

Learning Objectives for "Creating the Work Breakdown Structure"

Upon completion of this section, the reader should be able to:

●  Explain various different WBS architectures;
●  Explain the major approaches to constructing a WBS;
●  Describe why a software WBS is required;
●  Describe how a software WBS is used in a software development project;
●  Describe what a WBS is and what milestones are;
●  List and describe the steps to build a software WBS.


project charter, project plan, software product, life cycle, competencies
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 2018 SPMInfoBlog.
Designed by TechPlus