Contents
Status
This is a Working Draft.
Introduction
The Work breakdown structure (WBS) is a widely used tool for describing projects. While other sections of this Primer have described the interactions between EMS 1.0 service consumers and providers within a single phase of the estimation lifecycle, this section describes on the interactions involving WBS across several phases.
A WBS is a decomposition of the total work to be performed on a project into smaller units that can be estimated, assigned, measured, and tracked. A WBS should describe all the work and only the work that is to be performed on the project. The WBS therefore defines the project’s scope of work.
The decomposition of work forms a tree that may have any number of levels. Each node in the tree is called a WBS element. The root node of the tree presents the project itself. Each leaf of the tree is called a terminal WBS element or work package. The work performed in any non-terminal WBS element is the sum of the work performed in all its children. The total amount of work performed in a project is the sum of that performed in all the ternimal WBS elements.
In addition to the parent-child relations in the WBS that define the work decomposition tree, the WBS may also describe the dependencies between WBS element. The most common dependency is when one WBS produces a deliverable that is required by another WBS element. This relation between the producer and the consumer of the deliverable is expressed by saying that the consumer depends on the producer. Dependencies may exist for many other reasons.
The project schedule depends on the WBS and resource availability. Teams must be assigned to projects, and within a project, team members must be assigned to the terminal WBS elements.
At the start of a project the WBS tree may have only a few levels, perhaps only three. The terminal WBS elements may get decomposed further as the project progresses. In practice, the decomposition stops when the WBS element produces a measureable result that can be assigned to one or a small team of people and can be completed in a few weeks or less. The WBS should focus on measureable results produced by the work and not on how the result is achieved.
Many metrics may be associated with WBS elements. These include start and finish dates, duration, effort (optionally broken down by time period and role), cost, size of result (e.g. code size measured in ESLOC), and quality (e.g. defects found and fixed). These metrics should be estimated and measured.
In software and systems development projects, it is the norm for some WBS elements to be tracked in a Change Management (CM) system. A WBS element in a CM are refered to as work items, features, defects, etc.
Overview
In this scenario we will follow the interchange of WBS estimates and measurements across several lifecycle stages.
Project Selection
Let us assume that Tsunami 1.0 has shipped and that we are now in the initial planning stages for the follow-on release, Tsunami 2.0. After Tsunami 1.0 went public on the BrainTwistors Corp. website, requirements for new features started to arrive. These requirements came from users, advertisers, puzzle developers, as well as the BrainTwistors Corp. development team and product manager. The requirements were entered into a Requirements Management (RM) system. Pedro, the Tsunami product manager, has prioritized these requirements and has selected the most valuable ones for inclusion in Tsunami 2.0. Pedro has done this prioritization and selection in the portfolio management tool, PfGenius. Pedro now needs an estimate for Tsunami 2.0 so he invokes the Request Estimate function.
PfGenius creates a new ems:Project in MetricServer for Tsunami 2.0. However, this time PfGenius includes the list of requirements in the ems:Project resource. These requirements define the scope of the project. After creating the ems:Project resource, PfGenius notifies Syd, the software estimate, that an estimate is needed for Tsunami 2.0.
Syd receives the notification and launches Guestimator 101, his software estimation tool. Syd creates an initial WBS based on the requirements. Syd works with the development team to get size estimates for each requirement, decomposing the requirements until they can be confidently estimated. Syd then produces an effort and duration estimate based on the size estimates and the historical team productivity. Recall that when the Tsunami 1.0 projected completed, its metrics were added to the Guestimator 101 historical database and used to recalibrate its models, so Syd has some recent objective data that should apply well to the Tsunami 2.0 project.
The Tsunami 2.0 estimate includes a WBS with duration and effort estimates, broken down by month and role. Syd invokes the Save command and Guestimator 101 sends the estimate to MetricServer. Syd returns to PfGenius and marks the estimate request as Ready for Review. PfGenius then notifies Pedro that the estimate is ready. Recall that we are not assuming any direct integration between Guestimator 101 and PfGenius since that is outside the scope of EMS 1.0.
Pedro receives the notification and opens the estimate. As usual, the estimate provides the total cost and risk which become part of the business case. The estimate als o includes the WBS which provides several additional benefils.
First, the WBS provides the decomposition of the work so that Pedro can understand what each requirement costs. Pedro is more confident about the estimate since instead of being only a rolled-up estimate for the whole project, it includes the estimates for each part of the project, and Pedro can sanity check the estimate for each part. Pedro can verify that the estimate contains all the requirements he priortized and none others. If the total cost is too high, Pedro can guage the effect of reducing the scope by eliminating some requirements.
The second main benefit of the WBS is that it includes the effort by month and role. Pedro can use this information to determine when resources will be available to work on the project. For example, part of the Tsunami 1.0 development team is working on a maintenance release, Tsunami 1.0.0.1, which contains several import defect fixes. PfGenius includes information about all proposed and approved projects, their resource needs, and the resource availability of all BrainTwistors Corp. development staff. This information lets Pedro determine when new projects can start, and this might have an impact on the business value of the project. For example, the value of a project that produces Christmas-themed content depends critically on it being released immediately after Thanksgiving. Releasing such a project in January would have little value.
Pedro approves the estimate and determines the start date for the project. PfGenius sends a notification to Priyanka, the development manager selected for Tsunami 2.0.
Project Setup
Priyanka recieves the PfGenius notification that the Tsunami 2.0 project has been approved. She launches TaskPhocus, her project management tool, and invokes the Create Project command. The URL of the ems:Project resource for Tsunami 2.0 is included in the notification. Priyanka provides this URL to TaskPhocus. TaskPhocus accesses MetricServer and retrieves the baselines information for Tsunami 2.0, which includes the approved WBS estimate. TaskPhocus then creates a new work item for each WBS element, including the duration and effort estimates.
Using the approved WBS estimate to set up the project in TaskPhocus gave Priyanka a jump start. The WBS provided by Guestimator 101 was based on best practices adopted by BrainTwistors Corp. Priyanka can now decompose the WBS further and assign the work to her team.
Project Control
Compare the rolled-up values from the project to the estimates. Note that the dev team may update the estimates in the CM system. We can therefore compare both the dev actuals to the baselined estimates and the dev estimates to baselines estimates
Project Reestimation
Now take into account the actual effort, schedule, etc. and the rolled-up dev team estimates.
Category:EMS Primer
