A good work breakdown structure and its synchronization with the process framework are critical factors in software project success. Although the concept and practice of using a WBS are well established, this topic is largely avoided in the published literature. This is primarily because the development of a work breakdown structure is dependent on the project management style, organizational culture, customer preference, financial constraints, and several other hard-to-define, project-specific parameters. Software Engineering Economics [Boehm, 1981] contains background material on software-oriented work breakdown structures.
A WBS is simply a hierarchy of elements that decomposes the project plan into the discrete work tasks. A WBS provides the following information structure:
• A delineation of all significant work
• A clear task decomposition for assignment of responsibilities
• A framework for scheduling, budgeting, and expenditure tracking
Many parameters can drive the decomposition of work into discrete tasks: product subsystems, components, functions, organizational units, life-cycle phases, even geographies. Most systems have a first-level decomposition by subsystem. Subsystems are then decomposed into their components, one of which is typically the software. This section focuses on software WBS elements, whether the software is the whole project or simply one component of a larger system.
10.1.1 Conventional WB S Issues
Conventional work breakdown structures frequently suffer from three fundamental flaws.
1. They are prematurely structured around the product design.
2. They are prematurely decomposed, planned, and budgeted in either too much or too little detail.
3. They are project-specific, and cross-project comparisons are usually difficult or impossible.
Conventional work breakdown structures are prematurely structured around the product design. Figure 10-1 shows a typical conventional WBS that has been structured primarily around the subsystems of its product architecture, then further decomposed into the components of each subsystem. Once this structure is ingrained in the WBS and then allocated to responsible managers with budgets, schedules, and expected deliverables, a concrete planning foundation has been set that is difficult and expensive to change. A WBS is the architecture for the financial plan. Just as software architectures need to encapsulate components that are likely to change, so must planning architectures. To couple the plan tightly to the product structure may make sense if both are reasonably mature. However, a looser coupling is desirable if either the plan or the architecture is subject to change.
System requirements and design Subsystem 1 Component 11 Requirements Design Code Test
Documentation ... (similar structures for other components) Component 1N Requirements Design Code Test
Documentation ... (similar structures for other subsystems) Subsystem M Component M1 Requirements Design Code Test
Documentation ... (similar structures for other components) Component MN Requirements Design Code Test
Documentation Integration and test Test planning
Test procedure preparation Testing Test reports Other support areas Configuration control Quality assurance System administration
Figure 10-1. Conventional work breakdown structure, following the product hierarchy
Conventional work breakdown structures are prematurely decomposed, planned, and budgeted in either too little or too much detail. Large software projects tend to be overplanned, and small projects tend to be underplanned. The WBS shown in Figure 10-1 is overly simplistic for most large-scale systems, where six or more levels of WBS elements are commonplace. The management team plans out each element completely and creates a baseline budget and schedule for every task at the same level of detail. On the other hand, most small-scale or in-house developments elaborate their WBSs to a single level only, with no supporting detail. The management team plans and conducts the project with coarse tasking and cost and schedule accountability. Both approaches are out of balance. In general, a WBS elaborated to at least two or three levels makes sense. For large-scale systems, additional levels may be necessary in later phases of the life cycle. The basic problem with planning too much detail at the outset is that the detail does not evolve with the level of fidelity in the plan. For example, it is impossible to lay out accurately in month 1—when the plan is being baselined, and before the architecture and test scenarios have been engineered— details of the test activities that are scheduled 18 months later.
Conventional work breakdown structures are project-specific, and cross-project comparisons are usually difficult or impossible. Most organizations allow individual projects to define their own project-specific structure tailored to the project manager's style, the customer's demands, or other project-specific preferences. With no standard WBS structure, it is extremely difficult to compare plans, financial data, schedule data, organizational efficiencies, cost trends, productivity trends, or quality trends across multiple projects. Each project organizes the work differently and uses different units of measure. Some of the following simple questions, which are critical to any organizational process improvement program, cannot be answered by most project teams that use conventional work breakdown structures.
• What is the ratio of productive activities (requirements, design, implementation, assessment, deployment) to overhead activities (management, environment)?
• What is the percentage of effort expended in rework activities?
• What is the percentage of cost expended in software capital equipment (the environment expenditures)?
• What is the ratio of productive testing versus (unproductive) integration?
• What is the cost of release N (as a basis for planning release N+l)?
An evolutionary WBS should organize the planning elements around the process framework rather than the product framework. This approach better accommodates the expected changes in the evolving plan and allows the level of planning fidelity to evolve in a straightforward way. The basic recommendation for the WBS is to organize the hierarchy as follows:
• First-level WBS elements are the workflows (management, environment, requirements, design, implementation, assessment, and deployment). These elements are usually allocated to a single team (as discussed in Chapter 11) and constitute the anatomy of a project for the purposes of planning and comparison with other projects.
• Second-level elements are defined for each phase of the life cycle (inception, elaboration, construction, and transition). These elements allow the fidelity of the plan to evolve more naturally with the level of understanding of the requirements and architecture, and the risks therein.
• Third-level elements are defined for the focus of activities that produce the artifacts of each phase. These elements may be the lowest level in the hierarchy that collects the cost of a discrete artifact for a given phase, or they may be decomposed further into several lower level activities that, taken together, produce a single artifact.
A default WBS consistent with the process framework (phases, workflows, and artifacts) is shown in Figure 10-2. This recommended structure provides one example of how the elements of the process framework can be integrated into a plan. It provides a framework for estimating the costs and schedules of each element, allocating them across a project organization, and tracking expenditures.
The structure shown is intended to be merely a starting point. It needs to be tailored to the specifics of a project in many ways.
• Scale. Larger projects will have more levels and substructures.
• Organizational structure. Projects that include subcontractors or span multiple organizational entities may introduce constraints that necessitate different WBS allocations.
• Degree of custom development. Depending on the character of the project, there can be very different emphases in the requirements, design, and implementation workflows. A business process re-engineering project based primarily on existing components would have much more depth in the requirements element and a fairly shallow design and implementation element. A fully custom development of a one-of-a-kind technical application may require fairly deep design and implementation elements to manage the risks associated with the custom, first-generation components.
AA Inception phase management
AAA Business case development AAB Elaboration phase release specifications AAC Elaboration phase WBS baselining AAD Software development plan
AAE Inception phase project control and status assessments AB Elaboration phase management
ABA Construction phase release specifications ABB Construction phase WBS baselining ABC Elaboration phase project control and status assessments AC Construction phase management ACA Deployment phase planning ACB Deployment phase WBS baselining ACC Construction phase project control and status assessments AD Transition phase management ADA Next generation planning
ADB Transition phase project control and status assessments Environment
BA Inception phase environment specification BB Elaboration phase environment baselining
BBA Development environment installation and administration BBB Development environment integration and custom toolsmithing BBC SCO database formulation BC Construction phase environment maintenance
BCA Development environment installation and administration BCB SCO database maintenance BD Transition phase environment maintenance
BDA Development environment maintenance and administration BDB SCO database maintenance BDC Maintenance environment packaging and transition Requirements
CA Inception phase requirements development CAA Vision specification CAB Use case modeling CB Elaboration phase requirements baselining CBA Vision baselining CBB Use case model baselining CC Construction phase requirements maintenance CD Transition phase requirements maintenance
DA Inception phase architecture prototyping DB Elaboration phase architecture baselining DBA Architecture design modeling DBB Design demonstration planning and conduct DBC Software architecture description DC Construction phase design modeling
DCA Architecture design model maintenance DCB Component design modeling DD Transition phase design maintenance E Implementation
EA Inception phase component prototyping EB Elaboration phase component implementation
EBA Critical component coding demonstration integration EC Construction phase component implementation
ECA Initial release(s) component coding and stand-alone testing ECB Alpha release component coding and stand-alone testing ECC Beta release component coding and stand-alone testing ECD Component maintenance ED Transition phase component maintenance F Assessment
FA Inception phase assessment planning FB Elaboration phase assessment FBA Test modeling
FBB Architecture test scenario implementation FBC Demonstration assessment and release descriptions FC Construction phase assessment
FCA Initial release assessment and release description FCB Alpha release assessment and release description FCC Beta release assessment and release description FD Transition phase assessment
FDA Product release assessment and release descriptions G Deployment
GA Inception phase deployment planning GB Elaboration phase deployment planning GC Construction phase deployment GCA User manual baselining GD Transition phase deployment GDA Product transition to user
• Business context. Contractual projects require much more elaborate management and assessment elements. Projects developing commercial products for delivery to a broad customer base may require much more elaborate substructures for the deployment element. An application deployed to a single site may have a trivial deployment element (such as an internally developed business application) or an elaborate one (such as transitioning from a mission-critical legacy system with parallel operation, to achieve zero downtime).
• Precedent experience. Very few projects start with a clean slate. Most of them are developed as new generations of a legacy system (with a mature WBS) or in the context of existing organizational standards (with preordained WBS expectations). It is important to accommodate these constraints to ensure that new projects exploit the existing experience base and benchmarks of project performance.
The WBS decomposes the character of the project and maps it to the life cycle, the budget, and the personnel. Reviewing a WBS provides insight into the important attributes, priorities, and structure of the project plan. In performing project assessments and software management audits over the past several years, I have found the WBS to be the most valuable source of objective information about the project plan. While the software development plan and the business case provide a context for review, the WBS and the relative budgets allocated among the elements provide the most meaningful indicators of the management approach, priorities, and concerns.
Another important attribute of a good WBS is that the planning fidelity inherent in each element is commensurate with the current life-cycle phase and project state. Figure 10-3 illustrates this idea. One of the primary reasons for organizing the default WBS the way I have is to allow for planning elements that range from planning packages (rough budgets that are maintained as an estimate for future elaboration rather than being decomposed into detail) through fully planned activity networks (with a well-defined budget and continuous assessment of actual versus planned expenditures).
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.