Book Review: Work Breakdown Structures: The Foundation for Project Management Excellence

    By: PDMA Headquarters on Oct 04, 2013

    Book Review: Work Breakdown Structures: The Foundation for Project Management Excellence       

    By: Eric S.Norman, Shelly A. Brotherton, and Robert T. Fried, Hobson, NJ : John Wiley & Sons , 2008 . 286+xvi pages. 
    Review by: Gerald Mulenburg

    Book ImageThis book is written for everyone responsible for project management or product development work. The topic of the book, the Work Breakdown Structure (WBS), is a critically useful and important technique for describing and understanding any new product, or project development. The authors say, “The WBS can be thought of as the backbone of the project” (p. 149), making it the “cornerstone” (p. 141) that helps transition the project work from “passive to action” (p. 137). The product development community readers not familiar with the term work breakdown structure may recognize the WBS as a product, or system hierarchy diagram, describing a product's architecture. According to Cutherell (1996, p. 226), “A product development project work breakdown structure can be based on the architectural hierarchy of the product's chunks.” Despite its usefulness and widespread use, however, there is little information about work breakdown structures in the literature that is truly useful to practitioners: “If you were to stack all of the publications and writings about Work Breakdown Structures on a table, the pile would be a scant 5 to 6 inches tall” (p. vii). This scarcity of available information in print about work breakdown structures may make this book an initial classic in its field. A somewhat folksy style of language makes the book readable by all levels of product and project managers and relevant to anyone wanting to create a work breakdown structure for their product or project.

    Written by three of the team members for revising the Project Management Institute's (PMI, 2006Practice Standard for the WBS—2nd Edition, the book's layout addresses the five PMI key process groups and nine knowledge areas, including the value of creating a WBS dictionary to provide detailed information about each of the project deliverables in the WBS. As stated by the authors, “The book is designed to function as a text, but also as a desk reference” (p. viii). Its purpose is to fill the gap between what is available in print and what the authors know from their experience. It does a good job of accomplishing this through a high level of detail, multiple exhibits, tables, and simple exercises that make the book appropriate for use in a classroom teaching environment and for product and project managers to use with their projects.

    The book introduces the need for and how best to use work breakdown structures for project success. The authors begin by defining the concept of work breakdown structure that “applies at all levels of scope definition” (p. 30), including projects, programs, portfolios, and the enterprise. They trace the initial development of the WBS from the 1960s in the National Aeronautics and Space Administration (NASA) and the Department of Defense for “planning and controlling large acquisition projects” (p. 4). It quotes NASA as saying that a WBS is used to “ensure that the total project is fully planned, and all derivative plans contribute directly to the desired objectives” (p. 5). To show the development process for a WBS, the authors provide a useful, multilevel pyramid graphic that begins with the project charter at the lowest level and moves up the pyramid through an increasing level of WBS definition, culminating with defining the acceptance criteria of the project deliverables at the pyramid apex. The pyramid helps clarify the author's objective of a WBS that is “an unambiguous statement of the objectives and deliverables of the work performed” (p. 12). Each of the book's chapters begins with an overview of the material and ends with a chapter summary, a reference list, and a short quiz of the material covered. Four appendices provide a sample project charter, two examples of developing a WBS, and answers to the end of chapter quiz questions.

    Development of the WBS early in projects is a way to quickly identify and document the scope of work involved. Unfortunately, once created the WBS is often ignored as the project begins and the day-to-day activities of executing the work involved consume the time available. Using the metaphor of constructing a house as a basic project, the authors provide some new concepts for use of the WBS that they describe as transition activities. These show how the WBS functions differently across different phases of a project. Recognizing that this structure may not be relevant to all types of projects and all industries, they ask the reader to bear with them in any shortcomings of the house metaphor. Its use is only to show the basic relevance of the WBS to the many facets of project management, and for the most part it does just that.

    In decomposing a project into its discrete parts to create a WBS, the authors list four possible forms to use: function, role, method, and deliverables. To define the universal core characteristics of the WBS that apply to any project, they address the deliverables to be produced by the project (the components of the work involved). Too numerous to mention here, these core characteristics are a “minimum set of specific attributes that must be present in every WBS” (p. 20; emphasis in original). The core WBS characteristics make a simple checklist for project or product managers to ensure they have not omitted anything important. The authors do recognize, however, that one type of WBS cannot fit every situation and further define use-related characteristics for the WBS that vary depending on the requirements of a particular project and of the industry involved. Together, the core and use-related characteristics result in a quality WBS construct that “satisfies all of the requirements” (p. 20). The quality measure of a WBS is based on two quality principles: (1) to satisfy all of the requirements of the project; and (2) that the quality characteristics apply at all levels of scope definition, both for the product of the project and for the work required to create that product. In developing a WBS, the lack of availability of mature tools to create a WBS limits the flexibility of the project manager. However, the authors point out, the use of low-tech sticky notes for identifying each deliverable and then organizing these notes into a WBS hierarchy at the start of a project remains one of the most used and most flexible methods for creating a WBS.

    Some concerns with the book, but not with its content, include numerous exhibits, figures, and tables with duplicate numbers, and this can be confusing when going from a reference noted in the text to finding it on a page. There are also numerous graphics of the pyramid depicting the development stages of the WBS and its related components that the authors use, yet these pyramids are not identified by any reference numbers at all. Although a valiant effort by the authors in progressing through the steps of the pyramid, they were not successful in showing the value of linkage to the WBS for all of the knowledge areas identified in the PMI (2004)PMBOK Guide. By trying to find a link for every PMI knowledge area to the WBS, more information than is needed about some knowledge areas is provided, and other information is not discussed at sufficient depth to show a clear connection of the knowledge area to the WBS. In addition, although the house metaphor works fairly well throughout, it would have been useful to show some additional examples of WBS construction for other industry areas of project and product management.

    This book does have much to offer the project and product manager, and I applaud the effort of the authors in showing not just the relevance of a WBS and WBS dictionary to planning a project but also to its execution. A significant contribution of this book is the prominent highlighting the scope of the project management function itself as one of the deliverables in the WBS. As an experienced project manager, and as an instructor to project managers across disciplines and industries, I find this to be one of the most ignored arenas in project management. Despite the consumption of considerable time and resources, project management itself is often overlooked in defining the scope, schedule, and budget of many projects. The authors identify the difficulty of including project management as part of the scope due to the preponderance of level-of-effort work involved in project management that is undeterminable at the beginning of a project and therefore difficult to estimate at the outset. The final chapter of the book addresses the difficulty of including project management in the WBS and offers different ways of accomplishing this. The inclusion of project management as part of project scope should be a wakeup call for practicing project and product managers that will improve their practice of project management and product development.

    Released: October 4, 2013, 10:58 am | Updated: November 20, 2013, 10:24 am
    Keywords: PDMA Blog

    You must create an account or login with your existing account to provide comments or article ratings.

    About this Blog

    PDMA Blog

    Welcome to the PDMA Blog! This blog features industry insights for product developers and product managers from a variety of contributors.
    My Store Downloads

    No purchased files.

    Copyright © 2018 PDMA - Product Development and Management Association. All Rights Reserved

    PDMA 1000 Westgate Drive, #252 St. Paul, MN 55114 USA   |   Phone: 651-290-6280   |   Fax: 651-290-2266

    Contact PDMA   |   Legal Policies & Agreements