Introduction
Work Breakdown Structures (WBS) are recognized as fundamental building blocks for project management practice. There are many writings on the subject, here are a but a few key examples:
Harold Kerzner writes: “The WBS provides the framework on which costs, time, and schedule/performance can be compared against the budget for each level of the WBS” (1997, p. 791)
From A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Third Edition: “The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables… The WBS represents the work specified in the current approved project scope statement. Components comprising the WBS assist the stakeholders in viewing the deliverables of the project” (2004, p. 112)
Dr. Gregory T. Haugan: “The WBS is the key tool used to assist the project manager in defining the work to be performed to meet the objectives of a project” (2002, p. 15)
Carl L. Pritchard: “… the WBS serves as the framework for project plan development. Much like the frame of a house, it supports all basic components as they are developed and built” (1998, p. 2)
It is clear the WBS is the starting point in the planning process for many other essential project management processes such as Estimating, Scheduling and Controlling, yet project managers regularly have difficulty creating effective WBSs and may spend little time developing or maintaining them. For many, creating a WBS is often seen as an unnecessary task that can be skipped with little consequence - or the WBS becomes simply a representation of the project's schedule in outline form, little more.
With alarming consistency, however, leaders are finding that project difficulties including scope creep, budget shortfall, poor project performance and missed deliverables can be traced directly to the completeness and quality of the WBS - and to the amount of effort spent developing and maintaining it.
If it is broadly accepted that a quality WBS is essential for project success, why then do we see so few examples of effective WBS construction or their applied use in everyday Project Management practice? What circumstances are contributing to this reduced capability for quality WBS development?
To answer that question, Project Management Institute's (PMI®) Practice Standard for Work Breakdown Structures 2nd Edition (2001) project team discussed project success and failure with practitioners from a collection of industries including construction, automotive, pharmaceutical and IT.
Root Cause Analysis
As part of the PS-WBS analysis phase, the project team examined reasons why project managers did not prepare “quality” WBSs for their projects. The exercise revealed that while some PMs attempted to create effective Work Breakdown Structures for their projects, they often lacked the written guidance they needed to do so. Verbatim responses to a survey conducted by the PS-WBS Project Team suggest there simply isn't an easily accessible library of relevant literature that provides sufficient guidance for developing Work Breakdown Structures. Conversely, the team also learned that many PMs believe they had created quality WBSs for their projects when, upon closer examination it was revealed they had simply created a listing of project activities.
These two conditions appear to be rooted in an interesting development:
Over the past five years, PM process management and scheduling tools have evolved to become sophisticated and robust product “suites”. These tools now offer an array of automated functions – including what many claim as “work breakdown structure” outputs. (Exhibit 1) Naturally, it is quite easy for PMs to rely on these tools to produce the WBSs they require for their projects. Unfortunately, these tools to do not help the PM define and decompose the scope of the project in terms of it's deliverables (the true foundational role of the WBS), but rather enable the PM to enter a listing of schedule tasks, push a button and produce what appears to be a WBS.
Exhibit 1 – Auto-generated WBS
Moreover, anecdotal evidence suggests that project management practice at many institutions and corporations encourage project managers to ignore or skip the development of a deliverable-oriented WBS in the rush to “get the project scheduled and started”. This dangerous practice can easily result in missed deliverables and unsatisfactory project outcomes. Additional factors, including the above stated need for “fast track” project delivery and a broadly held assumption that “smaller” projects do not require Work Breakdown Structures, have driven the practice, knowledge and skill required for creating effective Work Breakdown Structure into neglect and disuse
Compounding this issue is the array of conflicting guidance regarding the proper approach to structuring the creation of a WBS. As discussed above, the PMBOK® Guide, Third Edition defines the WBS as “a deliverable-oriented, hierarchical grouping of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project's work” (PMI, 2004, p 394). This definition of the WBS is grounded in decades of experience, a vast array of empirical evidence and analysis of practical application. Additionally, this perspective is also “generally recognized as good practice, most projects, most of the time.” (PMI, 2004, p18)
The concept of deliverable-oriented development of Work Breakdown Structures is also reinforced by writings from the Department of Energy, Department of Defense and the standard established for development of the WBS, PMI's Practice Standard for Work Breakdown Structures. None-the-less, many authors recommend creating PROCESS-oriented Work Breakdown Structures (Chapman, 2004, p2), while others suggest the best approach is an ACTION-oriented approach (Pritchard, 1998, p9). Further clouding the path to development of effective Work Breakdown Structures, Systems Development Lifecycle practices such as Rational Rose's RUP (Rational Unified Process), are built on the principle of process-orientation and don't easily lend themselves to the creation of deliverable-orientated Work Breakdown Structures to support them.
Finding Answers
Process-oriented WBS construction does not articulate project outcomes
Carefully developing process-oriented Work Breakdown Structures may ensure that each project process is clearly articulated and that each of these processes are detailed to the appropriate work package level. Following standard WBS development practices when creating a process-oriented WBS will also guide the project manager to develop an associated WBS Dictionary to carefully explain the content of each element in the WBS. Developing a process-oriented WBS will not, however, aid the project manager in defining the outcomes, results or “deliverables” from the project effort.
Though a process-oriented WBS may be constructed using “best in class” practice, the resulting WBS does not document and communicate outcomes, but rather details the processes employed to deliver the intended outcomes.
In this case, it would be quite possible to successfully execute elements or entire WBS constructs, while missing key products from one or more of the WBS elements. As an example, in a process-oriented WBS, one of the level 2 elements may be “Testing Processes”, and, within this element, “Unit Testing”, “Integration Testing”, and “System Testing” at level 3.
As a process-oriented construct, it would be possible to perform any and all of these testing processes with a high degree of “process quality” - and do so endlessly without delivering the intended product quality. Without clear definition and broad agreement between stakeholders of the outcomes of the testing processes… and accompanying precision regarding the conditions by which all testing will be deemed “successful”, including criteria by which completeness is defined, project outcomes may remain elusive while the processes by which the project is controlled are executed flawlessly.
Action-oriented WBS construction does not provide clear direction for delivering project deliverables
As in the process-oriented WBS construction described above, it is also possible to perform project tasks and activities with a high degree of quality without delivering desired project outcomes. The example here is similar to the process-oriented discussion. The WBS can be defined in terms of broad Tasks or Activities at level 2 that include narrower and smaller elements at levels 3 and beyond (decomposition of the work).
To use an example, a level 2 task can be described as “Design the Product”, while level 3 elements include “Design Internal Components”, “Design External Components”, “Design Common Components” and Design Integration Components”. Here, the WBS and its associated WBS Dictionary are again defined in terms of the activities and tasks (actions) that must occur. Further, these actions may be described in enough detail to recommend or imply a particular order (which, as reviewed above is more oriented toward scheduling than scope definition). Whatever the case, once again, while it may be possible to perform design activities/tasks quite efficiently and precisely, the intended outcomes – or products – of these efforts are not particularly called-out by the WBS construction or associated dictionary. Typically in these WBS examples, there is great detail describing the task or activity to be performed… including specific tools, responsible persons, task duration, and the like, with little clarification of the outcome of the action or criteria by which it would be deemed complete and acceptable by the receiver(s).
Deliverable-oriented WBS construction focuses on project outcomes
Creating deliverable-oriented Work Breakdown Structures focuses the project manager, project team, stakeholders, and sponsors on the outcomes or products of the project. As discussed earlier, the deliverable-orientation and progressive decomposition will facilitate the process by which the project manager and team describe, detail, communicate and measure progress toward project results.
To provide an example, describing WBS levels as deliverable-oriented groupings, levels 2, 3, and beyond would contain nouns and adjectives to describe their content. For instance, at level 2: Component A; and at level 3, subcomponents A1, A2, A3, and perhaps “A4 Blue”, “A5 Red”, and “A6 Green”.
The WBS dictionary for these elements would carefully describe the subject elements in great detail – and would include (though not limited to) the WBS element “owner”, resource pool, tools, requirements, dependencies, and would specifically include a definition of the “finished product” including criteria detailing how the “completeness” of the element would be defined as well as the process by which it would be measured – to the point of including the metrics used for its evaluation.
With this process as a foundation, each WBS element articulates and drives toward a specific measurable outcome or “product”, whether that outcome is an internal deliverable (internal to the project) or an external deliverable (a project outcome intended for receivers or stakeholders outside the project team or organization). Moreover, the WBS constructed in this manner provides a detailed definition of the project scope as well as its limits, and provides the project manager with a foundation – composed of a group of unique building blocks on which to construct the project schedule, resource matrix, risk plan, change control process, and more.
Defining effective Work Breakdown Structures
In the detail above we have briefly discussed a few common approaches to WBS construction and suggest a number of factors that have contributed to the confusion related to the development of effective Work Breakdown Structures. To bring closure to this process and provide guidance for developing truly effective WBS examples, it is recommended that project managers consider the following as “Core Characteristics” of effective Work Breakdown Structures:
An Effective Work Breakdown Structure:
- Is a deliverable-oriented grouping of project elements
- Is created by those doing the work
- Contains 100% of the work defined by the scope or contract and captures all deliverables (Internal, External, Interim) in terms of work to be completed, including Project Management
- Defines the context of the project, clarifies the work and communicates project scope to all stakeholders
- Is expressed as a chart or outline, providing a graphical or textual breakdown
- Arranges all major and minor deliverables in a hierarchical structure - and is constructed so that each level of decomposition contains 100% of the work in the parent level
- Should contain at least 2 levels
- Uses nouns and adjectives – not verbs
- Evolves along with the progressive elaboration of project scope, up to the point of scope baseline, and thereafter in accordance with project change control - allowing for continual improvement
- Employs a coding scheme for each WBS element that clearly identifies the hierarchical nature of the WBS when viewed in any format
Gaining an understanding of the core characteristics of effective Work Breakdown Structures will not be sufficient for the project manager, however. Putting these and other attributes into action effectively will also help contribute to project success and the outcomes, results or “deliverables” produced.
To develop Work Breakdown Structures, the project manager should take the guidance provided here and apply WBS construction activities independent of the project schedule or scheduling tools. To do this, the project manager will reference a set of key documents to begin the development of the WBS. These include (and may not be limited to):
- The project charter
- The project problem statement or scope definition
- Applicable contract or agreement documentation
- Existing project management practice
Armed with these documents as the basis for WBS development, the project manager will guide the project team through the development of a deliverable-oriented WBS, carefully relating all WBS elements to these foundational documents and associating work described by the WBS to specific scope boundaries defined by them. These activities are typically performed by engaging the entire project team in “brainstorming” or “idea-generation” sessions, using affinity diagramming techniques and iterative decomposition to define the WBS elements… all independent of the project scheduling tool.
Once complete, the WBS is placed under “Change Control” and will be managed in accordance with the Change Management processes defined for the project - allowing for the expected and inevitable change that will impact the scope of the project. When these changes occur, they are reflected not only in the project schedule, but are documented as addendum or changes to the Scope Statement, Charter, contract, agreements and of course, the WBS.
In this way, the project manger will have constructed a Work Breakdown Structure that directly links to sponsoring documents, provides a basis for project schedule and process management, yet is designed to grow and flex with the changes that impact the project in a controlled and controllable manner.
Summary
Given the conditions described above, including openly conflicting guidance, how can an interested project manager create a WBS that will serve his or her project well – or determine if a WBS that appears in a project schedule is derived from a quality WBS creation process or not? The simple answer is - one cannot without new tools.
To create effective Work Breakdown Structures or determine if the WBS represented in a given project schedule has been derived from an effective WBS development process, the project manager must first understand the attributes and characteristics found in effective Work Breakdown Structure construction and become familiar with the process that leads to the development of effective WBSs. The project manager will then apply this understanding to uncover evidence that these characteristics exist independently of – and in fact drove the creation of the project schedule being evaluated.
