The work breakdown structure (or WBS) is lightly understood, intermittently used, and not widely viewed as an essential step in the project planning process…not even by many in the project management field.
In many corporate adopted methodologies, it does not find a place in the list of required project artifacts. How could this be?
Experience in many workplace environments tells us that in the rush to get a project kicked off and moving (“This should have started in Q1!”), when the go-ahead is given for startup, the race is on to finalize the scope, charter, budget, etc. and dive into Microsoft Project! The time required to incorporate WBS development and application to the overall planning process doesn’t seem available or necessary to a majority of project managers.
Let’s step back and consider the facts and research. Best practice, as defined in the PMBOK Guide Fourth Edition, is creation of a WBS to define in detail the scope components and sub-components of the project. Many things can go wrong in projects regardless of how successfully they are planned and executed.
Project failures, when they do occur, can often be traced to a poorly developed or nonexistent WBS. Lack of a quality WBS, a critical input to downstream planning processes, can result in a range of poor outcomes involving project re-planning and extensions, unclear work assignments, scope creep or frequent scope change requests, budget overruns, missed deadlines and, worst of all, unusable new products or delivered features.
Properly constructed, the WBS should provide a clear statement of the objectives and deliverables of the work to be performed. It represents a detailed description of the project’s scope, deliverables and outcomes—the what of the project. The WBS is not intended to be the how—it should not describe process or tasks to get to outcomes.
In PMBOK, the WBS is presented as a foundational project management component, and is a critical input to other project management processes and deliverables such as activity definitions, project and program schedules, performance reports, risk analysis and response, control tools or project organization. The development and implementation of the WBS, however, remains a difficult undertaking for many in project management.
The upper levels of the WBS should reflect the major deliverable work areas of the project, decomposed into logical groupings of work. The lower WBS elements provide appropriate detail and focus for support of project management processes such as schedule development, cost estimating, resource allocation, and risk assessment.
The lowest-level WBS components are called work packages and contain the definitions of work to be performed and tracked. These can be later used as input to the scheduling process to support the elaboration of tasks, activities, resources and milestones which can be cost-estimated, monitored, and controlled.
Some of the key characteristics of a high-quality WBS (as referenced in Practice Standard for Work Breakdown Structures–Second Edition) are outlined below:
» It is deliverable-oriented, focused on the products, results, or services that must be produced to complete a process, phase or project. In a nutshell—the focus is on deliverables, not task or process.
» It is a hierarchical decomposition of the work, which subdivides the project scope and project deliverables into smaller components that make up the primary deliverables. This decomposition (or subdivision) clearly and comprehensively defines the scope of the project in terms of individual sub-deliverables that the project members (and project managers especially) can easily understand and work with. Think of the ‘How do I eat an elephant’ joke….yes, the goal is to make the effort bite-sized.
» The 100% Rule is a key principle guiding the development, decomposition and evaluation of the WBS. This rule states that the WBS includes 100 percent of the work defined by the project scope and, by doing so, captures ALL deliverables—internal, external and interim—in terms of work to be completed, including project management.
The constructed WBS can be represented in a variety of ways including graphical, textual or tabular views. The form of representation should be chosen based on the needs of the specific project and ease of use for the project manager.
The time expended developing a quality WBS will benefit the project manager and team by providing a better grasp of what the work will entail due to their role in defining it and it will provide other paybacks such as providing a template for bottom-up project estimates, a reference point for evaluating impacts of change requests, and a more defined vision of the scope of work to be communicated to stakeholders.
Content contributed by NouvEON, a management consulting firm. For further insights and success stories, visit www.nouveon.com/insights. For a complete white paper on WBS, visit www.nouveon.com/WBSofProjectManagement.pdf. To contact NouvEON’s project management expert, e-mail him at firstname.lastname@example.org.