Work Breakdown Structure

From apppm
Revision as of 21:03, 17 February 2018 by Giannis (Talk | contribs)

Jump to: navigation, search

It is beyond any reasonable doubt that the Work Breakdown Structure (WBS) is the foundation of planning, estimating, scheduling, and monitoring any kind of activities. With its contribution an outline of common reference for all schedules and better estimates is ensured.[1] A Work Breakdown Structure (WBS) is the process of subdividing project deliverables and project work into smaller, more manageable components. More specifically, it is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.[2]

The purpose of this wiki-article is not only to thoroughly describe the capabilities and restrains of this method but also to provide guidance concerning the techniques that can be used for the effective implementation of project Work Breakdown Structures.

Contents

Introduction

Historical Retrospection

The first forms of Work Breakdown Structure (WBS) were developed by the U.S. Department of Defense with a view to improving their missile systems at mid-1960s. The fundamental concept of the WBS and the practices around its use were initially established by the U.S. Department of Defense (DoD) and National Aeronautics and Space Administration (NASA) for the purpose of planning and regulating broad procurement projects whose primary objective was the development and delivery of weapons and space systems respectively. These projects generally involved a lot of industrial contractors each with responsibility for independent segments of the system and were also managed by a central administrative office. In this environment, the WBS was used to “…ensure that the total project is fully planned and that all derivative plans contribute directly to the desired objectives” (NASA, 1962).[3]

Work Breakdown Structure Definition

A project is made more manageable by breaking it down into individual components that together are known as a Work Breakdown Structure or WBS. Such a structure defines unique work elements that can be arranged and completed in the order defined by the network diagram: sequentially, in parallel, or in the specific order necessary to accomplish the project outcomes. Furthermore, it facilitates other project management processes such as estimating, scheduling, resource allocation, risk analysis, and measurement and control of the project. This tool is a representation of a clear description of the project’s deliverables and scope. In addition, the WBS method is not a description of a process or schedule that defines how or when the deliverables will be produced, but rather is specifically limited to describing and detailing the project’s outcome or scope.[4] Moreover, it organizes and defines the total scope of the project, and represents the work specified in the current approved project scope statement. The planned work is contained within the lowest level of WBS components, which are called work packages. A work package can be used to group the activities where work is scheduled and estimated, monitored, and controlled. In the context of the WBS, work refers to work products or deliverables that are the result of activity and not to the activity itself.[2]

Big Idea

The upper levels of the Work Breakdown Structure (WBS) consistently reflect the major deliverable work areas of the project, disintegrating into logical groupings of work. The content of the upper levels can vary, depending on the type of project and industry involved. The lower WBS elements provide appropriate detail and focus for support of project management processes, such as schedule development, cost estimating, resource allocation, and rik assessment. The lowest-level WBS components are the Work Packages. The glossary definition for Work Package is, “A deliverable or project work component at the lowest level of the Work Breakdown Structur. The work package includes the schedule activities and schedule milestones required to complete the work package deliverable or project work component” (PMBOK® Guide-Third Edition). The WBS is finalized by assigning each work package to a control account and etablishing a unique identifier for that work package from a code of accounts. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information. A control account is a management control point where scope, budget, actual cost, and schedule are integrated and compared to the earned value for performance measurement. Control accounts are placed at selected management points in the WBS. Each control account may include one or more work packages, but each of the work packages should be associated with only one control account. A control account may include one or more planning packages planning package is a work breakdown structure component below the control account with known work content but without detailed schedule activities.[2]

Here are some of the key features of a high-quality Work Breadown Structure:

  • A central attribute of the WBS is that is “deliverable oriented” (Berg and Colenso (2000)). The PMBOK® Guide-Third Edition defines a deliverable as “Any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase or project.” In this context, oriented means aligned or positioned with respect to deliverables.
  • An additional key attribute of the WBS is taht it is a “...hierarchical decomposition of the work...” Decomposition is “a planning technique that subdivides the project scope and project deliverables into smaller more manageable component, until the project work associated with accomplishing the project scope and deliverables is defined in sufficient detail to support executing, monitoring, and controlling the work” (PMBOK® Guide-Third Edition). This decomposition clearly and comprehensively defines the scope of the project in terms of individual subdeliverables that the project participants can easily understand. The specific number of levels defined and elaborated for a specific project should appropriate for effectively managing the work in question.[3]
  • It is able to define the scope of the project and clarify the work and communicates project scope to all stakeholders.
  • Contains work packages that clearly support the identification of the tasks that must be performed in order to deliver the work package.
  • It is constructed with technical input from knowledgable subject matter experts (SMEs) and other project stakeholders, such as financial and business managers.
  • Iteratively evolves along with the progressive elaboration of project scope, up to the point the scope has been baselined.
  • It is updated in accordance with the project change control, thereby allowing for continual improvement, after the project scope has been baselined.[4]

Application

A number of methods and tools can be employed to create a WBS including outlines, organizational charts, fishbone diagrams, brainstorming techniques, and top-down and bottom-up development strategies. Moreover, WBS templates, as well as corporate quidelines or standards can be referenced or copied for quick-starting WBS development.[4]

Creating WBS: Tools and Techniques

Decomposition

Decomposition is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts, the work packages. The level of decomposition is often guided by the degree of control needed to effectively manage the project. The level of detail for work packages will vary with the size and complexity of the project. Decomposition of the total project work into work packages generally involves the following activities:

  • Identifying and analyzing the deliverables and related work.
  • Structuring and analyzing the WBS.
  • Decomposing the upper WBS levels into lower-level detailed components.
  • Developing and assigning identification codes to the WBS components.
  • Verifying that the degree of decomposition of the deliverables is appropriate.

Expert Judgment

Expert judgement is often used to analyze the information needed to decompose the project deliverables down into smaller component parts in order to create an effective WBS. Such judgment and expertise is applied to technical details of the project's scope and used to reconcile differences in opinion on how to best break down the overall scope of the project. This level of expertise is provided by any group or individual with relevant training, knowledge, or experience with similar projects or business areas. Expert judgment can also come in the form of predefined templates that provide guidance on how to effectively break down common deliverables. Such templates may be industry or discipline specific or may come from experience gained in similar projects. The project manager, in collaboration with the project team, then determines the final decomposition of the project scope into the discrete work packages that wil be used to effectively mnage the work of the project.[2]

Top-Down Method

The following steps describe the general top-down process for developing a WBS:

  • Step 1. Identify the final products of the project-what must be delivered to achieve project success. A thorough review of high-level project scope documents (such as Statement of Work and Technical Requirements) is recommended to ensure consistency between the WBS and the project requirements.
  • Step 2. Define the project’s major deliverables, which are often interim deliverables necessary for the project, but which in themselves do not satisfy a business need (such as a design specification).
  • Step 3. Decompose major deliverables to a level of detail appropriate for management and integrated control. These WBS elements are normally tied to clear and discrete identification of stand-alone deliverable products. The sum of the elements at each level should represent 100% of the work in the element above it. Each work package of the WBS should contain only one deliverable.
  • Step 4. Review and refine the WBS until project stakeholders agree that project can be successfully completed, and the execution and control will successfully produce the desired deliverables and results.[4]

Limitations

References

  1. Dr. Parviz F. Rad, PE CCE. “Advocating a Deliverable-Oriented Work Breakdown Structure”, Cost Engineering - December 31, 1999.
  2. 2.0 2.1 2.2 2.3 Project Management Institute. “A Guide to the Project Management Body of Knowledge (PMBOK® Guide)”- Fifth Edition, 2013.
  3. 3.0 3.1 Eric S. Norman, Shelly A. Brotherton, Robert T. Fried. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008.
  4. 4.0 4.1 4.2 4.3 Project Management Institute. “Practice Standard for Work Breakdown Structures”- Second Edition, 2011.

Annotated Bibliography

Dr. Parviz F. Rad, PE CCE. “Advocating a Deliverable-Oriented Work Breakdown Structure”, Cost Engineering - December 31, 1999.

Annotation: This article presents the rationale and methods for modifying the traditional breakdown structure philosophy in order to obtain a WBS that is focused on deliverables.

Project Management Institute. “A Guide to the Project Management Body of Knowledge (PMBOK® Guide)”- Fifth Edition, 2013.

Annotation: This book provides guidelines for managing individual projects and defines project management related concepts. It also describes the project management life cycle and its related processes, as well as the project life cycle.

Eric S. Norman, Shelly A. Brotherton, Robert T. Fried. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008.

Annotation: This book is intended to be a beginning step in filling the information gap that exists between what is currently written about Work Breakdown Structures and what the authors have learned is needed by program and project managers today.

Project Management Institute. “Practice Standard for Work Breakdown Structures”- Second Edition, 2011.

Annotation: This book provides guidance in the initial generation, subsequent development, and application of the WBS. It also includes information derived from accepted project management industry sources.

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox