Work Breakdown Structure PMI.pdf

Project Management Institute
Practice Standard
for Work
Breakdown Structures
Second Edition
92312$CHFM 09-07-06 11:49:03

92312$CHFM 09-07-06 11:49:03
Practice Standard for Work Breakdown Structures—Second Edition
ISBN 10: 1-933890-13-4
ISBN 13: 978-1-933890-13-5
Published by: Project Management Institute, Inc.
Four Campus Boulevard
Newtown Square, Pennsylvania 19073-3299 USA.
Phone: Ⳮ610-356-4600
Fax: Ⳮ610-356-4647
E-mail: pmihq@pmi.org
Internet: www.pmi.org
©2006 Project Management Institute, Inc. All rights reserved.
‘‘PMI’’, the PMI logo, ‘‘PMP’’, the PMP logo, ‘‘PMBOK’’, ‘‘Project Management Journal’’, ‘‘PM Network’’, and the PMI Today logo are
registered marks of Project Management Institute, Inc. The Quarter Globe Design is a trademark of the Project Management Institute,
Inc. For a comprehensive list of PMI marks, contact the PMI Legal Department.
PMI Publications welcomes corrections and comments on its books. Please feel free to send comments on typographical, formatting, or
other errors. Simply make a copy of the relevant page of the book, mark the error, and send it to: Book Editor, PMI Publications, Four
Campus Boulevard, Newtown Square, PA 19073-3299 USA.
PMI books are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training
programs, as well as other educational programs. For more information, please write to Bookstore Administrator, PMI Publications,
Four Campus Boulevard, Newtown Square, PA 19073-3299 USA, or e-mail: booksonline@pmi.org. Or contact your local bookstore.
Printed in the United States of America. No part of this work may be reproduced or transmitted in any form or by any means,
electronic, manual, photocopying, recording, or by any information storage and retrieval system, without prior written permission of
the publisher.
The paper used in this book complies with the Permanent Paper Standard issued by the National Information Standards Organization
(Z39.48—1984).
10 9 8 7 6 5 4 3 2 1

Notice
The Project Management Institute, Inc. (PMI) standards and guideline publications,
of which the document contained herein is one, are developed through a voluntary
consensus standards development process. This process brings together volunteers
and/or seeks out the views of persons who have an interest in the topic covered by
this publication. While PMI administers the process and establishes rules to promote
fairness in the development of consensus, it does not write the document and it
does not independently test, evaluate, or verify the accuracy or completeness of any
information or the soundness of any judgments contained in its standards and guide-
line publications.
PMI disclaims liability for any personal injury, property or other damages of any
nature whatsoever, whether special, indirect, consequential or compensatory, directly
or indirectly resulting from the publication, use of application, or reliance on this
document. PMI disclaims and makes no guaranty or warranty, expressed or implied,
as to the accuracy or completeness of any information published herein, and disclaims
and makes no warranty that the information in this document will fulfill any of your
particular purposes or needs. PMI does not undertake to guarantee the performance
of any individual manufacturer or seller’s products or services by virtue of this standard
or guide.
In publishing and making this document available, PMI is not undertaking to render
professional or other services for or on behalf of any person or entity, nor is PMI
undertaking to perform any duty owed by any person or entity to someone else.
Anyone using this document should rely on his or her own independent judgment
or, as appropriate, seek the advice of a competent professional in determining the
exercise of reasonable care in any given circumstances. Information and other stan-
dards on the topic covered by this publication may be available from other sources,
which the user may wish to consult for additional views or information not covered
by this publication.
PMI has no power, nor does it undertake to police or enforce compliance with the
contents of this document. PMI does not certify, tests, or inspect products, designs,
or installations for safety or health purposes. Any certification or other statement of
compliance with any health or safety-related information in this document shall not
be attributable to PMI and is solely the responsibility of the certifier or maker of the
statement.
©2006 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA iii
92312$CHFM 09-07-06 11:49:03

Contents
List of Figures ..................................................................................................................... vii
Preface to the Second Edition ...............................................................................................ix
Chapter 1—Introduction to the Practice Standard for Work Breakdown Structures—
Second Edition ....................................................................................................1
1.1 Overview ............................................................................................................1
1.2 Concept .............................................................................................................1
1.3 Objectives ..........................................................................................................2
Chapter 2—Defining the WBS ................................................................................................3
2.1 Overview ............................................................................................................3
2.2 Common Usage of Terms ....................................................................................3
2.3 Concept .............................................................................................................5
2.4 The 100% Rule ...................................................................................................8
2.5 WBS for Construction of a Bicycle ........................................................................8
2.6 Representations of the WBS .............................................................................11
2.7 Summary .........................................................................................................11
Chapter 3—Importance of the WBS .....................................................................................13
3.1 Overview ..........................................................................................................13
3.2 Integration with Project Management Processes .................................................14
3.3 Relationship to Other Tools ...............................................................................15
3.4 WBS Integration and Use by Other Standards .....................................................17
3.5 Summary .........................................................................................................18
Chapter 4—Defining WBS Quality ........................................................................................19
4.1 Overview ..........................................................................................................19
4.2 WBS Quality Principle 1 .....................................................................................19
4.3 WBS Quality Principle 2 .....................................................................................22
4.4 Annotated Example of a High-Quality WBS ..........................................................22
4.5 Problem Diagnostic Checklist ............................................................................24
4.6 Summary .........................................................................................................25
Chapter 5—Considerations While Creating a WBS ................................................................27
5.1 Overview ..........................................................................................................27
5.2 Preparing a WBS ..............................................................................................27
5.3 General Factors to Be Considered .....................................................................32
5.4 Essential Judgments .........................................................................................35
5.5 Evaluating WBS Quality .....................................................................................38
5.6 WBS Usage Continuum .....................................................................................39
5.7 WBS for Program and Portfolio Management ......................................................40
5.8 Summary .........................................................................................................40
Appendix A—Guidelines for a Project Management Institute Practice Standard ....................41
Appendix B—Evolution of the Project Management Institute Practice Standard for
Work Breakdown Structures ............................................................................43
Appendix C—Contributors and Reviewers of the Practice Standard for Work Breakdown
Structures—Second Edition ............................................................................47
Appendix D—Bicycle Work Breakdown Structure (WBS) Example .........................................51
Appendix E—Oil, Gas, and Petrochemical (OGP) Work Breakdown Structure (WBS) Example 65
Appendix F—Environmental Management Work Breakdown Structure (WBS) Example ..........71
©2006 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA v
92312$CTOC 09-08-06 09:41:26

vi ©2006 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
92312$CTOC 09-08-06 09:41:26
Appendix G—Process Improvement Work Breakdown Structure (WBS) Example ...................73
Appendix H—Pharmaceutical Work Breakdown Structure (WBS) Example ............................77
Appendix I—Process Plant Construction Work Breakdown Structure (WBS) Example ............81
Appendix J—Service Industry Outsourcing Work Breakdown Structure (WBS) Example .........85
Appendix K—Web Design Work Breakdown Structure (WBS) Example ..................................87
Appendix L—Telecom WBS Example ....................................................................................91
Appendix M—Refinery TurnAround WBS Example .................................................................95
Appendix N—Government Design-Bid-Build WBS Example .....................................................97
Appendix O—Software Implementation WBS Example ..........................................................99
Appendix P—Horizontal Tree Structure Format WBS Example .............................................101
References ........................................................................................................................103
Glossary ............................................................................................................................107
Index by Keyword ..............................................................................................................111

List of Tables and Figures
Chapters 1–5:
Figure 2-1. WBS Bicycle Example ...............................................................................8
Figure 2-2. Annotated Bicycle Example .......................................................................9
Figure 2-3. WBS Example ........................................................................................10
Figure 2-4. WBS Representations Comparison ..........................................................11
Table 3-1. Project Management Processes ..............................................................14
Figure 4-1. Annotated Example of a High-Quality WBS ...............................................23
Table 5-1. WBS Creation Methods ..........................................................................29
Figure 5-1. WBS Usage Continuum ...........................................................................39
Appendices:
Table D-1. Hierarchical Structure .............................................................................52
Table D-2. Tabular View 1 .......................................................................................53
Table D-3. Tabular View 2 .......................................................................................53
Figure D-1. WBS Tree Structure View 1 .....................................................................54
Figure D-4. WBS Horizontal Tree Structure View ........................................................57
Figure D-5. WBS Centralized Tree Structure View 1 ...................................................58
Figure D-6. WBS Centralized Tree Structure View 2 ...................................................59
Table D-4. WBS Dictionary ......................................................................................60
Figure D-7. WBS Dictonary .......................................................................................62
Figure F-1. Horizontal Tree Structure ........................................................................72
Table G-1. Process Improvement WBS Example .......................................................76
Figure K-1. Horizontal Portrait View ..........................................................................89
Figure K-2. Horizontal Landscape View .....................................................................90
Figure L-1. Top-Down Tree Structure ........................................................................92
Figure O-1. Software Implementation WBS Example ................................................100
Figure P-1. Horizontal Tree Structure Format WBS Example .....................................102
©2006 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA vii
92312$CTOC 09-14-06 10:49:35

Preface to the Second Edition
When the Work Breakdown Structure (WBS) Practice Standard Update Team gathered
in April of 2003, the progression of this standard to its current level of advancement
could not have been anticipated. To begin the work, the team received the charter
for the update process, the original chapters and appendices from the first edition,
as well as approximately 450 comments about the content of the document that had
been received from readers and project management practitioners since the time of
its publication.
While the challenge to update the Practice Standard for Work Breakdown Structures
initially did not appear particularly difficult, the project team spent a great deal of
time planning and developing an appropriate approach. At the time the update was
being initiated, the Practice Standard for Work Breakdown Structures had achieved
widespread popularity across the project management community, and had taken its
place beside the A Guide to the Project Management Body of Knowledge (PMBOK威
Guide)—Third Edition as a frequently requested publication available from PMI. Any
modifications to this document, therefore, had to be weighed carefully.
With this in mind, the Update Team set in motion a series of discussions, presenta-
tions, and interviews designed to surface and accurately illuminate how the WBS is
put into play across a broad array of industries today. The resulting conclusions
regarding WBS application and practice have now been incorporated into this standard
and have been brought together as a ‘‘white paper’’ that accompanies the publication
on the Practice Standard for Work Breakdown Structures—Second Edition CD-ROM.
From the time the first edition of the Practice Standard for Work Breakdown Struc-
tures was being developed a little more than five years ago, there has been a vast
expansion in rapid electronic access to information through the Internet, CD-ROMS,
DVDs, instant messaging, and wireless technology. Knowing that the WBS Practice
Standard will be delivered into this rapidly evolving communications environment,
the Update Team was compelled to consider how this standard would be viewed and
used by current and future project management practitioners.
Considering these factors, the Update Team came to understand that what had at
first seemed readily achievable was, in fact, considerably more complex and difficult.
Team leaders and members alike were convinced the design for the WBS Practice
Standard would need to reflect not only the progressive application of the WBS in
practice today, but must include and incorporate an awareness of the new environment
in which it will be used. To ensure this edition met those requirements, the Practice
Standard for Work Breakdown Structures—Second Edition will now be delivered as a
hard copy document as well as a CD-ROM.
Specifically relating to the content of the standard, many of the comments received
since the first publication focused on the need for more detail and a broader overall
perspective. Many comments included detailed requests for more and varied examples,
checklists, job aids, and reference material. The Update Team has taken particular
©2006 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA ix
92312$CPRE 10-03-06 08:53:26

x ©2006 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
92312$CPRE 10-03-06 08:53:26
care to address these comments, while ensuring that material accurately reflects the
application of standard practice in the industry. Throughout the standard, the reader
will find additional guidance regarding the characteristics that make up a high-
quality WBS, as well as considerably more discussion about the use of the WBS in
real-life practical situations. Additionally, many of the checklists, sets of questions,
and sectional examples have been extracted, reformatted, and placed in the appen-
dices as individual elements that can be used as job aids and guides for developing
a WBS.
The Practice Standard for Work Breakdown Structures—Second Edition provides
guidance in the initial generation, subsequent development, and application of the
WBS. The Practice Standard for Work Breakdown Structures—Second Edition is not,
however, a textbook, and it does not provide specific ‘‘how-to’’ instructions. The target
audience for this standard includes project managers, project team members, contract
personnel, and others who participate or have an interest in any aspect of the manage-
ment of projects or programs. In using this practice standard, it must be recognized
that as projects vary, so can the resulting WBSs. There are, however, certain universal
principles that this practice standard addresses.
The Practice Standard for Work Breakdown Structures—Second Edition is consistent
with the PMBOK威 Guide—Third Edition. The Practice Standard for Work Breakdown
Structures—Second Edition also includes information derived from accepted project
management industry sources. The Project Management Institute’s standards program
will periodically update the Practice Standard for Work Breakdown Structures as part
of the planned evolution of its standards. Your comments are invited.
The Practice Standard for Work Breakdown Structures—Second Edition is organized
as follows:
Chapter 1 Introduction to Introduces the WBS concept.
the Work Break-
down Structure
Chapter 2 Defining the WBS Defines the WBS and its characteristics.
Defines the benefits derived from using
a WBS.
Chapter 3 Importance of the How the WBS fits with other project
WBS management practices.
Chapter 4 Defining WBS Documents the characteristics of a
Quality high-quality WBS. Presents guidelines
for determining if the WBS is sufficient
for subsequent planning and control.
Chapter 5 Considerations Provides guidance and presents
while Creating a questions that can be asked during the
WBS development of a WBS to help ensure
that the finished product meets all the
needs of the project it will serve.
Appendices Provides background information on
A–D the PMI Standards Program and the
Practice Standard for Work Breakdown
Structures—Second Edition project.

Appendices Provides documented industry
E–P examples to aid the reader in further
understanding, creating, and using
WBSs. Each appendix represents an
approach tailored to a specific purpose,
application, or industry. Examples are
in different stages of completion and
represent the evolutionary development
of a WBS. None of the examples should
be taken as the only suitable WBS for
that type of project.
Notes
Glossary Provides clarification of key terms that
exist in the project management
profession, including those that have
subtle or variable meanings depending
on the organization and industry.
©2006 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA xi
92312$CPRE 10-03-06 08:53:26

Chapter 1
Introduction to the Practice
Standard for Work Breakdown
Structures—Second Edition
1.1 Overview
Successful project management relies on thorough planning. This begins by defining
the project objectives with sufficiently detailed information. The Work Breakdown
Structure (WBS) provides the foundation for defining work as it relates to project
objectives. The WBS also establishes the framework for managing the work to its
completion. The remaining sections of this chapter are as follows:
1.2 Concept
1.3 Objectives
1.2 Concept
The WBS is used in projects as follows:
● To define the project’s scope of work in terms of deliverables and to further decom-
pose these deliverables into components. Depending upon the decomposition
method used, the WBS can also define the project’s life cycle as well as the delivera-
bles appropriate to the project, program, or portfolio. This project scope decomposi-
tion balances management’s need for control with representation of an appropriate
level of detail in the WBS.
● To provide the project management team with a framework on which to base
project status and progress reports.
● To facilitate communication between the project manager and stakeholders
throughout the life of the project. The WBS can be used to communicate information
regarding the project scope. In combination with additional data, the WBS is the
framework for communicating information that includes, but is not limited to,
schedule, risk, performance, dependencies, and budget.
● As a key input to other project management processes and deliverables.
The WBS articulates the project scope. It is considered as critical input to other
project management processes and deliverables such as activity definitions, project
©2006 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 1
92312$$CH1 09-07-06 12:17:59

2 ©2006 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
92312$$CH1 09-07-06 12:17:59
schedule network diagrams, project and program schedules, performance reports, risk
analysis and response, control tools, or project organization. Moreover, although the
WBS is a key input to these project management processes and deliverables, the WBS
is not a substitute for any of these on its own.
For the purposes of this Practice Standard for Work Breakdown Structures—Second
Edition, a project can be defined as focused internally, externally, or both. Additionally,
deliverables for these projects can take the form of products, services, achievement
of specific objectives, or attainment of goals.
Internally focused projects can produce deliverables as inputs to other project
phases, other individuals, or other organizations within the organization sponsoring
the project. Externally focused projects typically produce deliverables for people or
organizations outside the organization, such as customers or project sponsors. Many
projects produce both internally and externally focused deliverables. Regardless of the
focus of the project, a WBS should be prepared in all cases.
Developing a WBS is an essential step during the initial project phases; as soon as
the basic scope has been identified, the initial WBS can be created with limited scope
information. As additional scope information is developed or made available by more
complete analysis of the project work to be performed, the WBS can be updated
through the formal change control processes. This updating process is known as
‘‘progressive elaboration.’’
This practice standard provides insight into the WBS, its development and its appli-
cation. It is expected that use of the principles found in this standard will enable the
user to prepare a valuable, high-quality WBS and put it to work in the course of
managing a project, program, or portfolio.
1.3 Objectives
The primary objectives of the Practice Standard for Work Breakdown Structures—
Second Edition are (1) to provide a common ground for understanding the concepts
and benefits of the WBS and (2) to present a standard application of the WBS as a
project management tool. The intent is to encourage consistency in applying this tool
and, as a result, to improve project planning and control. The Practice Standard for
Work Breakdown Structures—Second Edition provides guidance in WBS development,
based on the PMBOK威 Guide—Third Edition, and is used by other PMI standards.
Finally, although the Practice Standard for Work Breakdown Structures—Second
Edition provides guidance in WBS development, it is not intended to be a tutorial on
how to create a WBS.

Chapter 2
Defining the WBS
2.1 Overview
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 project outcomes. It facilitates other project management processes such
as estimating, scheduling, resource allocation, risk analysis, and measurement and
control of the project. The WBS represents a clear description of the project’s delivera-
bles and scope—the ‘‘what’’ of the project. It 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. As
stated in the PMBOK威 Guide—Third Edition, ‘‘The WBS organizes and defines the
total scope of the project. The WBS subdivides the project work into smaller, more
manageable pieces of work, with each descending level of the WBS representing an
increasingly detailed definition of the project work. The planned work contained in
the lowest level WBS components, which are called work packages, can be scheduled,
cost estimated, monitored, and controlled.’’
This chapter will provide more information regarding WBS terms, concepts, the
100% Rule, and an example of a good WBS in action. The remaining sections of this
chapter include:
2.2 Common Usage of Terms
2.3 Concept
2.4 The 100% Rule
2.5 WBS for Construction of a Bicycle
2.6 Representations of the WBS
2.7 Summary
2.2 Common Usage of Terms
A WBS, as defined in the PMBOK威 Guide—Third Edition, is: ‘‘A deliverable-oriented
hierarchical decomposition of the work to be executed by the project team to accom-
plish the project objectives and create the required deliverables. It organizes and
defines the total scope of the project. Each descending level represents an increasingly
92312$$CH2 09-07-06 12:20:18

92312$$CH2 09-07-06 12:20:18
detailed definition of the project work. . . .’’ The following terms help clarify this dic-
tionary definition:
Work. Sustained physical or mental effort, exertion, or exercise of skill to overcome
obstacles and achieve an objective. Commonly used to refer to a specific activity,
duty, function, or assignment often being a part or phase of some larger undertaking;
something produced or accomplished by effort, exertion, or exercise of skill. In this
context, work refers to work products or deliverables that are the result of effort
and not to the effort itself.
Breakdown. Division into parts or categories; separation into simpler substances;
decomposition.
Structure. Something arranged in a definite pattern of organization.
These dictionary definitions imply that a WBS has the following characteristics:
● Supports the definition of all work required to achieve an objective, tangible result.
● Is constructed to illustrate and define the hierarchy of deliverables. This hierarchy
is organized into ‘‘parent-child’’ relationships.
● Has an objective or tangible result that is referred to as a deliverable. In a sense,
the WBS can be thought of as a ‘‘deliverable’’ breakdown structure.
Additionally, as noted above, the WBS is a deliverable-oriented hierarchical decom-
position of the work to be executed by the project team. It can thus be defined in the
following terms:
Deliverable. Any unique and verifiable product, result, or capability to perform a
service that must be produced to complete a process, phase, or project. Often used
more narrowly in reference to an external deliverable, which is a deliverable that
is subject to approval by the project sponsor or customer.
Oriented. Aligned or positioned with respect to a point or frame of reference; focused
toward the concerns and interests of a specific group.
Hierarchical. Classified according to various criteria into successive levels or layers.
Decomposition. A planning technique that subdivides the project scope and project
deliverables into smaller, more manageable components, until the project work
associated with accomplishing the project scope and providing the deliverables
is defined in sufficient detail to support executing, monitoring, and controlling
the work.
These definitions work together to define the overall role of the WBS, that is, to
provide a foundation for the development of project schedules, communications, risk
management plans, as well as other key project elements.
2.2.1 Definition of Terms
The following definitions represent WBS-related terms as defined by the PMBOK威
Guide—Third Edition. These terms and others listed in the Glossary of this standard
facilitate understanding of the integral role the WBS plays in project management
practice. Terms are listed here in alphabetical order.

Activity. A component of work performed during the course of a project.
Apportioned Effort. Effort applied to project work that is not readily divisible into
discrete efforts for that work, but which is related in direct proportion to measurable
discrete work efforts. Contrast with discrete effort.
Control Account. A management control point where scope, budget (resource plans),
actual cost, and schedule are integrated and compared to earned value for perfor-
mance measurement. Control accounts are placed at selected management points
(specific components at selected levels) of the work breakdown structure. Each
control account may include one or more work packages, but each work package
may be associated with only one control account. Each control account is associated
with a specific single organizational component in the organizational breakdown
structure (OBS). Previously called a cost account. See also work package.
Discrete Effort. Work effort that is separate, distinct, and related to the completion
of specific work breakdown structure components and deliverables, and that can
be directly planned and measured. Contrast with apportioned effort.
Level of Effort (LOE). Support-type activity (e.g., seller or customer liaison, project
cost accounting, project management, etc.), which does not produce definitive end
products. It is generally characterized by a uniform rate of work performance over
a period of time determined by the activities supported.
Task. A term for work whose meaning and placement within a structured plan for
project work varies by the application area, industry, and brand of project manage-
ment software.
Work Breakdown Structure Component. An entry in the work breakdown structure
that can be at any level.
Work Package. A deliverable or project work component at the lowest level of each
branch of the work breakdown structure. The work package includes the schedule
activities and schedule milestones required to complete the work package deliver-
able or project work component. See also control account.
The following definition is included to reflect common usage:
WBS Element. Any single work breakdown structure (WBS) component and its associ-
ated WBS attributes contained within an individual work breakdown structure.
2.3 Concept
2.3.1 Overview
The WBS assists project leaders, participants, and stakeholders in the development of
a clear vision of the end products or outcomes produced by the project. To be more
precise, the WBS provides a clear vision of the work of the project. The WBS divides
the project scope into hierarchical, manageable, definable packages of work that bal-
ance the control needs of management with an appropriate and effective level of
detailed project data. The WBS provides the framework for all deliverables across the
project life cycle. The various levels of the WBS also provide support for focusing
92312$$CH2 09-07-06 12:20:18

92312$$CH2 09-07-06 12:20:18
communication with stakeholders and aid in clearly identifying accountability to a
level of detail necessary for effectively managing and controlling the project.
The upper levels of the WBS typically reflect the major deliverable work areas of
the project or major phases in the project’s life cycle. These levels also provide logical
summary points for assessing team and individual performance, communicating
accomplishments, and measuring cost and schedule performance with respect to
individual deliverables as well as the overall project.
The content of the upper levels can vary, depending upon the type of project and
the industry involved. To avoid confusion and rework, it is often prudent to define
the levels of the WBS prior to its construction. The lower WBS elements provide
appropriate focus for project management processes such as scope and schedule
development, cost estimating and resource allocation, and risk assessment.
Whenever work is logically structured, easily identifiable, and clearly within the
capabilities of individuals, project stakeholders can confidently expect that objectives
associated with the work can and will be achieved. The use of a WBS helps ensure
that the project meets these criteria.
2.3.2 Deliverables
The underlying concept of a deliverable is the core of a WBS. 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. Often used more
narrowly in reference to an external deliverable, which is a deliverable that is
subject to approval by the project sponsor or customer.
The WBS provides the foundation for integrating the work package and intermediate
deliverables with all other aspects of project initiation, planning, execution, monitoring
and controlling, and closing.
A deliverable-oriented WBS provides many benefits to the project, including the
following:
● Better communication to project sponsors, stakeholders, and team members
● More accurate estimation of tasks, risks, timelines, and costs
● Increased confidence that 100% of the work is identified and included
● A foundation for the control processes within the project.
The deliverable concept and deliverable orientation of the WBS are integral to
understanding the proper definition and use of the WBS and the benefits it provides
within the larger context of all project management processes.
2.3.3 Design
A well-designed WBS that presents information at the appropriate level of detail and
in formats and structures meaningful to those performing the work is an invaluable
tool in project management. It provides a graphical representation or textual outline
of the project scope. Here are some roles the WBS plays in supporting clarity for
project definition:
● Decomposes (or disassembles) the overall project scope into deliverables and sup-
ports the definition of the work effort required for effective management

● Clearly and comprehensively defines the scope of the project in terms of deliverables
that the project participants and stakeholders can understand
● Supports documentation of the accountability and responsibility for the various
deliverables by having a direct relationship among the WBS elements related to the
Organizational Breakdown Structure (OBS) identified through the Responsibility
Assignment Matrix (RAM)
● Provides a structure for organizing information regarding the project’s progress,
periodic status, and projected performance for which a project manager is respon-
sible
● Supports tracking of risks to assist the project manager in identifying and imple-
menting responses necessary to achieve desired outcomes.
2.3.4 Management
The WBS supports effective project management in several ways during the life of a
project by:
● Separating project deliverables into component parts to ensure the project plan
matches the approved project scope and will fulfill the overall objectives of the
project
● Supporting the decomposition of project scope into simpler components, providing
one of the primary methods for managing complex projects
● Providing a framework for specifying performance objectives
● Providing the basis for integrating and assessing schedule and cost performance
● Supporting the planning and assignment of responsibilities
● Assisting in determining resource requirements such as technical skills, experience
and knowledge
● Facilitating the reporting and analysis of project progress and status data, including
resource allocations, cost estimates, expenditures, and performance.
2.3.5 Organizational Perspective
The WBS provides the foundation for assigning work to the appropriate organizational
units, subcontractors, or individuals. As the work and organizational responsibilities
become more clearly defined, individuals, including subcontractors, are assigned
responsibility for accomplishing specific WBS elements within defined budgets and
schedules.
2.3.6 WBS Levels
The WBS includes all work to be done by the project leaders, stakeholders, and both
internal and external participants, such as team members and subcontractors. The
WBS provides a clear statement of the objectives and deliverables of the work to be
performed. The depth of a WBS is dependent upon the size and complexity of the
project and the level of detail needed to plan and manage it. Most work breakdown
structures consist of a multi-level hierarchy describing the entire scope to be accom-
plished by the performing organization; however, the specific number of levels should
be appropriate for effectively managing the project in question.
92312$$CH2 09-07-06 12:20:18

92312$$CH2 09-07-06 12:20:18
2.4 The 100% Rule
The 100% rule (Haugan, 2002, p 17) is a core characteristic of the WBS. This rule states
that the WBS includes 100% of the work defined by the project scope and captures
ALL deliverables—internal, external, and interim—in terms of work to be completed,
including project management. The 100% rule is one of the most important principles
guiding the development, decomposition and evaluation of the WBS. The rule applies
at all levels within the hierarchy: the sum of the work at the ‘‘child’’ level must equal
100% of the work represented by the ‘‘parent’’ and the WBS should not include any
work that falls outside the actual scope of the project, that is, it cannot include more
than 100% of the work.
It is important to remember that the 100% rule also applies at the activity level.
The work represented by the activities in each work package must add up to 100% of
the work necessary to complete the work package.
2.5 WBS for Construction of a Bicycle
The scope of a project can be decomposed in multiple ways. Regardless of the manner
of decomposition, the sum of the work packages for each different decomposition
should add up to the same scope of work. The following sample WBS illustrates key
concepts that will be discussed throughout the remaining chapters of this standard.
Figure 2-1. WBS Bicycle Example

Figure 2-1 is a sample WBS designed to capture the scope of work required to
construct a custom bicycle. To keep the graphic simple, this particular WBS does not
differentiate among the many types of bicycles that can be built from similar WBS
constructs, for example, a road bicycle, mountain bicycle, racing bicycle, or any other
bicycle, but assumes that detailed requirements for a specific type of bicycle would
be provided as further decompositions of the illustrated WBS elements.
This particular example was selected for its simplicity to enable the reader to focus
on the WBS itself, rather than the multitude of alternatives, options, and components
required to define a complex, unique, and perhaps esoteric product. The bicycle is a
familiar and common product, an example that easily suggests the processes required
to produce the end result.
This illustration shows how concepts and guidance described in later chapters work
together to produce a completed bicycle that meets the quality, timeliness, features, and
functionality requirements of the project sponsor, which in this case is the purchaser.
Specifically, this WBS illustrates the various levels of a WBS, the numbering scheme,
naming convention, relationship of parent and child WBS elements, and the represen-
tation of each of these characteristics and principles working together to form a
complete WBS. This illustration represents one example of the possible decomposition
of the testing elements. It is not intended to be comprehensive or definitive.
The bicycle WBS helps to communicate and reinforce some of the concepts pre-
sented. The annotated illustration (Figure 2-2) immediately following shows that all
Figure 2-2. Annotated Bicycle Example
92312$$CH2 09-07-06 12:20:18

92312$$CH2 09-07-06 12:20:18
WBS elements are not decomposed to the same extent. For example, this hypothetical
bicycle WBS does not decompose each Level 2 WBS component further into subele-
ments. While it can be helpful to decompose the entire WBS to the same level for
some projects, there are no hard and fast rules dictating that each WBS element is
decomposed to the same level. Decomposition is a use-related characteristic that is
defined by the context of the project the WBS is developed to support. This concept
is presented in detail in Chapter 4, Section 4.2.
Additionally, this example communicates WBS concepts that reflect application in
a broad array of industries. The construction of the WBS can remain the same, such
as the relationship of the WBS elements, the decomposition level, and the relationship
to other WBS elements. The content can be modified to reflect the application of the
concept in alternate terms for other industries, projects, or programs. This is illustrated
in the decomposed elements that are identified below the Level 2 WBS element for
Integration (1.6). In Figure 2-2, elements 1.6.4.1–1.6.4.3 are called Component Test,
Product Test and Customer Test, respectively. In the next example, Figure 2-3, these
Figure 2-3. WBS Example
same elements are entitled Unit Test, System Test, and Acceptance Test, showing how
the concept of testing is represented in various ways using basic WBS elements.
Finally, throughout the standard, the bicycle WBS is repeatedly used as a reference
point to clarify and illustrate concepts. To illuminate the concept being discussed,
parts of the WBS are extracted, elements are singled out, or sets of decomposed
elements are highlighted by placing dotted lines around them. For clarity, these WBS
elements are frequently shown in a number of different representations.

2.6 Representations of the WBS
The WBS can be represented in a variety of ways including graphical, textual, or tabular
views. Regardless of the representation used, the WBS enables the project team to
predict and forecast costs, schedules, resource requirements, and allocations more
accurately. Two common methods are the hierarchy diagram and the outline or tabular
view as shown in Figure 2-4.
Figure 2-4. WBS Representations Comparison
2.7 Summary
In summary, the WBS:
● Defines the hierarchy of deliverables
● Supports the definition of all work required to achieve an end objective or deliver-
able(s)
● Provides a graphical representation or textual outline of the project scope
92312$$CH2 09-07-06 12:20:18

92312$$CH2 09-07-06 12:20:18
● Provides the framework for all deliverables across the project life cycle
● Provides a vehicle for integrating and assessing schedule and cost performance
● Facilitates assignment of resources
● Facilitates the reporting and analysis of progress and status data
● Provides a framework for specifying performance objectives.

Chapter 3
Importance of the WBS
3.1 Overview
A WBS can not alone ensure project success, but consider that the WBS does the
following:
● Defines all the work of the project, and only the work of the project, thereby clarifying
the project scope
● Reflects the input from all team members to ensure buy-in
● Provides the baseline for subsequent change control
● Is a primary input to other project management processes—for example, resource
planning, cost estimating, schedule development, and risk identification
● Provides the framework for project control, performance monitoring, and the foun-
dation for communication with all stakeholders
● Ensures the work of the project correlates appropriately with the Responsibility
Assignment Matrix (RAM) and the Organizational Breakdown Structure (OBS)
● Is referenced in other PMI standards, for example, the PMBOK威 Guide—Third
Edition and Practice Standard for Earned Value Management (EVM), as an essential
planning deliverable supporting key project management functions.
Experienced project managers know that there are many things that can go wrong
in projects regardless of how successful the project managers are in the planning and
execution of their work. Project failures, however, can often be traced back to a poorly
developed or nonexistent WBS.
A poorly constructed WBS can result, among other things, in the following project
stumbling blocks and adverse project outcomes:
● Incomplete project definition leading to ongoing project extensions
● Unclear work assignments, goals, objectives, or deliverables
● Scope creep or unmanageable, frequently changing scope
● Budget overrun
● Missed deadlines on scheduled deliverables, or timeline slippage
● Unusable new product or feature
● Failure to deliver on some elements of project scope.
The remainder of this chapter highlights in more detail the important role the WBS
plays in project and program management planning:
92312$$CH3 09-07-06 12:23:31

92312$$CH3 09-07-06 12:23:31
3.2 Integration with Project Management Processes
3.3 Relationship to Other Tools
3.4 WBS Integration and Use by Other Standards
3.5 Summary
3.2 Integration with Project Management Processes
The WBS is created in the Create WBS Planning Process (PMBOK威 Guide—Third
Edition). The WBS also plays an integral role in other project management processes.
Typical (though not exhaustive) examples are shown in Table 3-1. References in Table
3-1 are to sections in the PMBOK威 Guide—Third Edition.
Process Group Importance of WBS in Process
Initiating ● Develop Preliminary Project Scope Statement (Section 4.2)
䡩 Historical WBS elements can contribute in determining the scope and
viability of projects.
Planning ● Scope Planning (Section 5.1)
䡩 The Scope Planning process documents how the WBS will be created
and defined.
● Scope Definition (Section 5.2)
䡩 The WBS further defines the entire scope of the project.
● Activity Definition (Section 6.1)
䡩 The WBS is an input source to this process, and is a key component of
a project plan.
● Cost Estimating (Section 7.1)
䡩 The WBS is an input to this process.
● Cost Budgeting (Section 7.2)
䡩 The WBS identifies project deliverables to which costs will be allocated.
● Human Resource Planning (Section 9.1)
䡩 The WBS is an input source to this process, and is a key component of
a project plan.
● Risk Identification (Section 11.2)
䡩 The WBS identifies project deliverables that must be evaluated for risk
events.
● Risk Response Planning (Section 11.4)
䡩 The WBS might be updated to include work and deliverables required for
risk management.
● Plan Purchases and Acquisitions (Section 12.1)
Executing ● Information Distribution (Section 10.2)
䡩 The WBS provides the basis for developing the communications plan and
the level of granularity at which project information can be distributed.
䡩 The WBS helps determine what level of project detail is appropriate to
communicate to different stakeholder groups.
Monitoring and Controlling ● Scope Verification (Section 5.4)
䡩 The WBS facilitates the process of formally accepting completed
deliverables.
● Scope Control (Section 5.5)
䡩 The WBS is an input source to this process, which is a key component
of a project plan.
䡩 It is important to adjust the WBS if project scope is changed so that
future changes will be based on an updated, agreed-upon project baseline.
䡩 A WBS enhances the project manager’s ability to assess the impact of
scope changes.
● Cost Control (Section 7.3)
䡩 The creation of the WBS reveals the best point in the hierarchy of
deliverables at which to implement cost control.
Table 3-1. Project Management Processes

3.3 Relationship to Other Tools
3.3.1 Project Management Tools
The purpose of the WBS, as a project management tool, is to organize the scope of a
project. WBS definition for programs and portfolios can use similar techniques to
organize scope. There are many project management tools that use the WBS or its
components as input (see Section 5.3 of PMBOK威 Guide—Third Edition).
.1 Project Charter.
The WBS takes the project charter as its starting point. The highest level element
in the WBS should represent the project’s overall end-point product(s), ser-
vice(s), or outcomes as described in the project charter. If the project’s major
products cannot be described during the creation of the WBS, then the project
management team should examine the charter to determine if it has been
sufficiently defined.
.2 Project Scope Statement.
The scope statement for the project is intended to clearly and succinctly describe
what the project is and is not intended to accomplish. The high-level elements
in the WBS should match, word-for-word, the nouns used to describe the out-
comes of the project in the scope statement. If the project management team
has difficulty identifying the objects in the scope statement and applying them
to the high-level WBS elements, the team should carefully examine the scope
statement to determine if it sufficiently captures all project outcomes and deliv-
erables. The WBS Dictionary can also be used to further document and clarify
each deliverable (see 3.3.1.6).
.3 Program and Portfolio WBS.
The WBS can be used to define scope for projects, programs, and portfolios.
For example, program offices are typically established to share tools, techniques,
methodologies, and resources in managing one or more collections of related
projects as program(s). The project WBS must illustrate a clear understanding
of the relationship among highly decomposed work packages within individual
projects and program (or higher order) scope definitions. If strategic changes are
made, the impact on projects, resources, and budgets can be easily calculated,
assuming the project WBS has been constructed correctly in consideration of
these higher order factors.
.4 RBS.
The Resource Breakdown Structure (RBS) describes the project’s resource orga-
nization and can be used in conjunction with the WBS to define work package
assignments. The link between work packages and the RBS can be used to verify
that all members of the project team have been appropriately assigned work
packages, and that all work packages have owners.
.5 OBS.
The Organizational Breakdown Structure (OBS) is loosely related to the WBS.
The OBS depicts the organization hierarchy, allowing the project’s work packages
to be related to the performing organizational units. This tool reinforces the
guideline that each work package should have a single point of responsibility.
92312$$CH3 09-07-06 12:23:31

92312$$CH3 09-07-06 12:23:31
The OBS can be a useful tool for project managers in that it clearly demonstrates
the hierarchy of people or groups, whereas the WBS is strictly organized by
deliverables.
.6 WBS Dictionary:
The WBS dictionary is a key document that accompanies the WBS and carries
critical project information. The WBS dictionary defines, details, and clarifies
the various elements of the WBS to ensure that each component of the WBS is
accurately articulated and can be communicated to anyone referencing the
WBS. The development of the WBS dictionary often uncovers ambiguity or other
errors in the WBS itself, and results in revisions to the WBS. The WBS dictionary
contains information about each element of the WBS, including a detailed
description of the work, deliverables, activities, and milestones associated with
each element. The WBS dictionary might also include an indication of the type
and number of resources required and contract control information, such as
a charge number or other similar data. Often, a WBS dictionary will include
traceability matrices linking the WBS to other scope control documents such
as statements of work or requirements documents.
.7 Project Schedule Network Diagram:
The network diagram is a sequential arrangement of the work defined by the
WBS, and is essential to uncovering project dependencies and risks. The activities
within the WBS work packages are arranged to show precedence and order.
Developing the network diagram often uncovers problems in the WBS, such as
incomplete decomposition, the assignment of too much work in an element,
or the assignment of more than one person for an individual WBS element, thus
resulting in needed revisions.
.8 Project Schedule:
The various elements of the WBS are used as starting points for defining the
activities included in the project schedule. Implied dependencies can be
recorded in the WBS Dictionary, and the activities as described in the WBS
Dictionary are then included as detail in the schedule.
3.3.2 Interrelationships Among Project Management Tools
Because of interrelationships among the WBS and other project management tools,
it is important to note that any change in the WBS requires an associated change in
the related tools.
Such interrelationships among the WBS and other Project Management processes
are described throughout the PMBOK威 Guide—Third Edition. As an example of these
interdependencies, consider the relationship between the WBS and the activity list
used for the project schedule as described in Section 6.1.2 of the PMBOK威 Guide—
Third Edition (Activity Definition: Tools and Techniques). Specifically, item 6.1.2.1
(Decomposition) reads:
‘‘The technique of decomposition, as it is applied to activity definition, involves
subdividing the project work packages into smaller, more manageable compo-
nents called schedule activities. The Activity Definition process defines the final
outputs as schedule activities rather than as deliverables, as is done in the Create
WBS process (Section 5.3).’’

‘‘The activity list, WBS, and WBS dictionary can be developed either sequentially
or concurrently, with the WBS and WBS dictionary being the basis for develop-
ment of the final activity list. Each work package within the WBS is decomposed
into the schedule activities required to produce the work package deliverables.
This activity definition is often performed by the project team members responsi-
ble for the work package.’’
Section 6.2 of the PMBOK威 Guide (Activity Sequencing) further states:
‘‘Activity sequencing involves identifying and documenting the logical prece-
dence relationships among schedule activities. Schedule activities can be logi-
cally sequenced with proper precedence relationships, as well as leads and lags
to support later development of a realistic and achievable schedule.’’
This discussion briefly describes how many project management tools are interre-
lated, all based upon the foundation of the WBS. The Work Breakdown Structure plays
a pivotal role in project and program management in each of the process groups:
Initiating, Planning, Executing, Monitoring & Controlling and Closing for which it
ensures a consistent definition of the scope of the work to be undertaken.
3.3.3 WBS Development Tools
There are a number of project management tools that can be used to assist a project
manager with the development of a WBS. These tools include outlines and organization
charts, fishbone and brainstorming techniques, and top down and bottom up develop-
ment strategies. There are many WBS templates available, and corporate standards
can be referenced or copied for quick-starting WBS development. When using generic
or corporate WBS templates, it will be important to ensure that the template chosen
for the project closely matches the project type (such as a Construction WBS template,
an IT Software Development WBS template, a commercial product WBS template,
etc.) and is used as a guide or basic structure that is then customized to fit the needs
of the specific project being planned. (More information about these tools can be
found in Chapter 5 of this standard.)
There are many benefits to using tools to develop a WBS. For example, tools often
promote consistency and repeatability in the development of a WBS, especially enter-
prise productivity tools. WBS tools can also promote and enforce the principles of the
WBS standard and can significantly reduce the development effort, simplifying the
WBS process, and even promoting reusable WBS products.
3.4 WBS Integration and Use by Other Standards
Scope management is integral to other PMI standards. These include but are not
limited to: the PMBOK威 Guide—Third Edition; Practice Standard for Earned Value
Management (EVM), and Organizational Project Management Maturity Model
(OPM3威). The development of a quality WBS is critical to the successful execution of
project management processes, as described in the PMBOK威 Guide—Third Edition,
as well as in the other aforementioned standards.
Standards that take advantage of the WBS typically fall into one of two categories.
The first category focuses on using the content output of the WBS as an input. PMI’s
Practice Standard for Earned Value Management (EVM) and upcoming Practice Stan-
dard for Scheduling fall into this category. Since the content output from a WBS is
92312$$CH3 09-07-06 12:23:31

92312$$CH3 09-08-06 09:42:54
predictable and well understood, such standards can build upon or leverage the Prac-
tice Standard for Work Breakdown Structures—Second Edition.
Other standards incorporate the WBS (as defined by this practice standard) as the
preferred tool to develop the scope definition for their role. For example, the PMBOK威
Guide—Third Edition uses the Practice Standard for Work Breakdown Structures—
Second Edition to develop the project scope, and OPM3威 identifies the WBS as a tool
that can be used to develop a program WBS. These standards recognize the Practice
Standard for Work Breakdown Structures—Second Edition as representing good
practice.
The WBS is developed to define carefully what is in the project scope and, by
implication, what is out of scope. The Practice Standard for Scheduling (currently in
development) is based, in part, on an assumption that a high-quality WBS has been
developed using good practice, correctly defining project scope. When the project
schedule is developed, each high-level (summary) task must correspond to a WBS
element. If an activity or task does not have a relationship to a work package within
the WBS, then either the WBS does not fully encompass the project scope, or the
activity or task is unnecessary.
EVM is a management methodology for integrating scope, schedule, and resources,
and for objectively measuring project performance and progress. The data used in
EVM are dependent upon WBS elements having been developed using good practice.
If WBS elements are not well defined, are too large in scope, are too lengthy in duration,
or are in some other manner not appropriately decomposed or developed, it will be
difficult to measure the project’s earned value. The Practice Standard for Earned Value
Management relies upon a high-quality WBS as a key input.
The PMBOK威 Guide—Third Edition, PMI’s project management standard, discusses
project management practice as a whole. A core element of project management is
scope management, and the PMBOK威 Guide discusses the benefits of using the WBS
as a technique to manage and control a project’s scope.
The Standard for Program Management describes how collections of related projects
are best managed. This standard assumes that the WBS for each relevant project is
developed according to good practice and accurately describes the scope for the
project.
The Standard for Portfolio Management describes how collections of projects or
programs are best managed. This standard assumes that the WBS for each relevant
project/program is developed according to good practice and accurately describes the
scope for the project.
PMI’s OPM3威 is an example of a maturity model that can be used to measure and
detail an organization’s maturity level, as well as provide a clear path to higher levels
of maturity. The WBS is important to OPM3威, since OPM3威 relies on the benefits of
processes aimed at scope management. This standard relies on the development of
a quality WBS as a foundation for effective project management.
3.5 Summary
The WBS is an important tool used in the planning and execution of a successful
project. Many project cost, schedule, and quality failures can be traced directly to
flaws in the development of the project’s WBS. It is less likely that a project will be
successful without the existence of a quality WBS. In contrast, developing and applying
a high quality WBS will significantly increase the likelihood of successful project com-
pletion. Chapter 4 will provide insight into the characteristics and components that
make up a high-quality WBS.

Chapter 4
Defining WBS Quality
4.1 Overview
What is a quality WBS? The PMBOK威 Guide—Third Edition (Chapter 8) considers
quality to involve the ‘‘the degree to which a set of inherent characteristics fulfills
requirements.’’ This includes the ideas of conformance to requirements and fitness
for use; that is, the ability to satisfy the purpose for which the item (in this case, a
WBS) was intended. (See Chapter 3 of this WBS Practice Standard for the uses, purpose,
and importance of the WBS.) To state that a particular WBS is of high quality, one
must agree that the WBS has been created so that it satisfies the purpose for which
it was created.
There are two basic principles that govern the quality of a WBS. This chapter will
describe these principles and identify the characteristics of a high-quality WBS that
flows from each principle. It will illustrate the negative effects of a poorly constructed
WBS and it will provide tools for project managers to use in evaluating any specific
WBS that is being developed. The remaining sections of this chapter are as follows:
4.2 WBS Quality Principle 1
4.4 Annotated Example of a High-Quality WBS
4.5 Problem Diagnostic Checklist
4.6 Summary
A quality WBS is a WBS constructed in such a way that it satisfies all of the requirements
for its use in a project.
There are two sub-principles that pertain to satisfying requirements for use of a
WBS. These describe core characteristics of every WBS and use-related characteristics
that describe a particular WBS based on its individual setting and use.
4.2.1 WBS Quality Sub-Principle 1—Core Characteristics
There is a set of core characteristics that must be present in every WBS, as these
characteristics enable the WBS to satisfy project needs that are present in every project.
92312$$CH4 09-07-06 12:25:47

92312$$CH4 09-07-06 12:25:47
With respect to core characteristics, a WBS either has them or it does not, and, as
such, these characteristics represent the minimum set of specific attributes a WBS
must contain. When evaluating or developing a WBS, the absence or presence of these
core characteristics will dictate whether or not it is a quality WBS. A WBS with the
following core quality characteristics can be said to have core quality:
● Is a deliverable-oriented grouping of project elements
● Defines the scope of the project
● Clarifies the work and communicates project scope to all stakeholders
● Contains 100% of the work defined by the scope
● Captures internal, external, and interim deliverables in terms of work to be com-
pleted, including project management
● Is constructed so that each level of decomposition contains 100% of the work in
the parent level
● Contains work packages that clearly support the identification of the tasks that
must be performed in order to deliver the work package
● Provides a graphical, textual, or tabular breakdown of the project scope
● Contains elements that are defined using nouns and adjectives—not verbs
● Arranges all major and minor deliverables in a hierarchical structure
● Employs a coding scheme for each element that clearly identifies its hierarchical
nature when viewed in any format such as a chart or outline
● Has at least two levels with at least one level of decomposition
● Is created by those who will be performing the work
● Is constructed with technical input from knowledgeable 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
● Is updated in accordance with project change control, thereby allowing for continual
improvement, after the project scope has been baselined.
4.2.2 WBS Quality Sub-Principle 2—Use-Related Characteristics
There is an additional set of use-related characteristics that may vary from one WBS
to another. These characteristics enable the WBS to be used for purposes that are
unique to a specific project, industry or environment, or are applied in a particular
way to individual projects.
With respect to use-related characteristics, the quality of a WBS depends on how
well the specific content and type of WBS elements meet all the needs for which the
WBS has been developed. This statement implies that the more project needs are met
by the WBS, the higher its quality. A high-quality WBS is constructed so that it can
be used to meet all project requirements, even if a given project does not take advantage
of all of the characteristics present.
Use-related characteristics support the application of WBS practice in situational
contexts. These can include, and are not limited to the following:
● Achieves a sufficient level of decomposition. A WBS is broken down to a level of
detail sufficient for managing the work. The appropriate level of detail to enable
effective management can differ from organization to organization or project to
project.
䡩 The depth of the WBS correlates with the size and complexity of the project and
the level of detail needed to plan and manage it.
䡩 All deliverables are limited in size and definition for effective control. However,
they should neither be so small that the cost of control is excessive, nor should

they be so large that the item is unmanageable or the associated risks cannot
be identified.
● Provides sufficient detail for communicating all work. A WBS facilitates conceptual-
ization and definition of the product, service, or result (deliverable) details. But the
degree of WBS detail necessary for conceptualization of project detail can vary. For
example, existing modules can be satisfactorily described by a product number,
while to-be-designed components might need to be described in greater detail. To
ensure clarity of communication regarding the intent of any WBS element, an entry
detailing specific information about the WBS element should be placed in the WBS
Dictionary. This will minimize misunderstanding of the WBS and, in turn, the
project scope.
● Is appropriate for tracking, as required by the specific project or organization.
Some projects or organizations can require highly detailed performance reporting
at the work package level, while others might require only summary level reporting
at a WBS rollup level.
䡩 The WBS has logical summary points that assist in tracking the evaluation of
performance accomplishments, resource allocations, costs, and schedule perfor-
mance.
䡩 Suitable management control points are identified in the WBS that can be used to
facilitate communication and to control scope, quality, and technical soundness.
䡩 In summary, the WBS provides a feasible mechanism to assess performance
and progress.
● Is appropriate for control activities. A WBS balances the control needs of manage-
ment with an effective level of project detail. It provides a good balance between
complexity, risk, and the project manager’s need for control.
䡩 Shorter, less complex projects may require only a few performance assessments
at higher WBS levels, whereas larger, more complex projects may require many
intermediate reviews at the work package level.
䡩 Elements are detailed enough to meet performance measurements and account-
ability objectives, thereby facilitating effective planning, monitoring, and control.
● Can contain specific kinds of WBS elements, as needed for each project. Some
projects might need to include a majority of the following types of WBS elements,
while other projects need only one or two:
䡩 Some project WBSs can include elements for integration, procurement, supply
chain management, information/communication, administration, documenta-
tion, training, and software development.
䡩 WBS elements representing subcontracted or externally committed deliverables
should directly correspond to matching elements in the subcontractor’s WBS.
䡩 A WBS might include level-of-effort WBS elements.
䡩 Deliverables from the development life cycle stages, such as planning, analysis,
design, assembly, testing, and implementation, can be reflected in the WBS,
where appropriate.
䡩 WBS elements can reflect the deliverables within the product development life
cycle, where appropriate, such as in the IT industry.
● Enables assignment of accountability at the appropriate level. Some projects or
organizations can require assignment of accountability at a very detailed, work
package level, while others might be satisfied with accountability assigned at a
summary rollup level.
䡩 Each WBS element can be assigned to an accountable individual, subcontractor,
or organizational unit.
92312$$CH4 09-07-06 12:25:47

92312$$CH4 09-07-06 12:25:47
䡩 The WBS can serve as the mechanism for documenting the accountability and
responsibility for the various deliverables by having a direct relationship among
the WBS elements related to the Organizational Breakdown Structure (OBS) iden-
tified through the Responsibility Assignment Matrix (RAM).
䡩 WBS elements clearly identify accountability to the level of detail required for
managing and controlling the project.
● Has a succinct, clear, and logically organized structure to meet project manage-
ment and oversight requirements. The logic of the hierarchical decomposition of
a project can vary in response to a variety of project and organizational factors.
䡩 The WBS decomposition level balances the project definition with data collecting
and reporting requirements.
䡩 WBS elements are compatible with relevant organizational and accounting
structures.
WBS quality characteristics apply at all levels of scope definition.
There is no conceptual difference between a project WBS, a program WBS, and a
portfolio WBS. A high-quality WBS developed at any of these broader levels possess
precisely the same characteristics and attributes as a high-quality WBS developed at
the individual project level. These differ only in the breadth of the content and scope.
4.4 Annotated Example of a High-Quality WBS
This WBS example is based on a hypothetical organization that builds bicycles to an
individual customer’s specifications. The annotations refer to specific characteristics
of a high-quality WBS. Figure 4-1 illustrates a simplified WBS as it pertains to a sample
project. The project is the design and building of a bicycle and is an example of a
WBS to encompass the work for this sample project.
4.4.1 Level 1
This level comprises the full scope of work necessary to produce the bicycle. It includes
all direct and indirect work. Level 1 is the overall product, always a single WBS element.
In this example, the top level is represented by both a name and a WBS identifier to
differentiate it from other WBSs in a program or portfolio of which it is a member.
This may not always be the case. If the project stands alone, the top level or Level 1
identifier may not be required. When the top level identifier is not included, numbering
for the remaining WBS levels will also change accordingly.
4.4.2 Level 2
This is the first level of decomposition. This level is the high-level breakdown of the
major areas in the scope of work. It holds the basic components of the product, along
with integration and project management. The frame set is basically the parts you sit
on, steer with, and to which you attach wheels and other parts. The crank set includes
the pedals, bearings, crank arms, and sprocket. The braking system includes the brake
pads and related mechanisms for the wheels, cables, and levers. The shifting system

Figure 4-1. Annotated Example of a High-Quality WBS
includes the front and rear shift mechanism, cables, and levers. This level is numbered
as #.#—for example, frame set is 1.1.
4.4.3 Level 3
This level decomposes each major area from Level 2 into its constituent parts. It is
important to note that the 100% Rule is always adhered to in the development of a
WBS. This level would tend to start targeting specific, tangible deliverables of the
project effort. Here, integration is decomposed into interim deliverables based on the
project life cycle chosen for this project. This level is numbered as #.#.#—for example,
rear wheel is 1.3.2.
4.4.4 Level 4
In the same manner, each exclusive area in Level 3 would be decomposed further, if
applicable. Again, the complexity of the work will drive the depth and number of
levels of the WBS decomposition. Note that testing is further decomposed into three
elements: component test is pre-assembly testing; product test is quality control and
92312$$CH4 09-07-06 12:25:47

92312$$CH4 09-07-06 12:25:47
pre-customer test; and customer test is customer delivery, final adjustments, and cus-
tomer acceptance. This level is numbered as #.#.#.#—for example, Product Test is
1.6.4.2.
4.5 Problem Diagnostic Checklist
The following are representative examples of major project problems resulting from
key WBS defects.
● There are frequently missed deadlines and an extended schedule
䡩 Have all major and minor deliverables been included? Failure to include all
deliverables within the initial WBS can increase project schedules when missed
deliverables are identified.
䡩 Have deliverables been defined specifically enough to allow for appropriate work
packages to be developed?
䡩 Does the WBS facilitate the use of earned value management techniques?
● Project is over budget
䡩 Does the WBS provide logical summary points for assessing accomplishments,
as well as for measuring costs and schedule performance?
䡩 Does the WBS facilitate the use of Earned Value Management techniques?
● Individuals are unable to use the new product or feature
䡩 Are deliverables decomposed into smaller, more specific deliverables? For exam-
ple, a deliverable of training might not be decomposed thoroughly enough to
cover all of the people who need training to use the new product, process,
or service.
䡩 Are the WBS elements deliverable-focused?
䡩 Were appropriate assembly or integration deliverables and testing activities
present?
䡩 Were training and implementation deliverables defined?
● The project scope has changed and is unmanageable
䡩 Has a WBS been created for the project?
䡩 Does the WBS decompose the overall project scope into deliverables?
䡩 Does the WBS provide a level of flexibility for change?
䡩 Has the WBS been updated when necessary changes are approved by the change
control process?
䡩 Has the WBS been placed under change control?
● The project has become an ongoing project with no end in sight
䡩 Has a maintenance plan been developed for post implementation if needed?
䡩 Does the project have a specific end point?
䡩 Does the WBS include a closeout phase or plan?
䡩 Is the endeavor actually a project or is it an ongoing operation?
● Project team members are confused about their individual responsibilities
䡩 Do the WBS elements define overlapping responsibilities for the creation of a
deliverable?
䡩 Is the information within the WBS at the appropriate level of detail, and in
formats and structures meaningful to those performing the work? If so, were clear
communication processes and decision authorities agreed upon beforehand?
䡩 Do the WBS elements reflect work with specific, tangible deliverables?
䡩 Have all key stakeholders, including subject matter experts, contributed to the
creation and validation of the WBS?

● Some planned work does not get done
䡩 Has all required work been included in the WBS?
䡩 Are the WBS elements deliverable-focused?
䡩 Has the WBS organized around deliverables rather than process steps?
䡩 Was decomposition completed before dependencies and durations were defined?
4.6 Summary
There are several characteristics that need to be present to produce a quality WBS
deliverable. For a WBS to be considered as high quality, it should conform to its
original requirements and be fit for use by the project. More simply stated, it should
satisfy the purpose for which it was originally intended.
In summary, a high-quality WBS:
● Is constructed in a consistent fashion, varying only in its level of focus based upon
its intended use
● Satisfies the needs of the project
● Contains all of the key elements necessary to represent the full scope of work
● Is usable by project managers with a broad base of experience to manage the varying
degrees of scope, budget, schedule, and risk
● Avoids the common pitfalls associated with WBS construction.
92312$$CH4 09-07-06 12:25:47

Chapter 5
Considerations While Creating
a WBS
5.1 Overview
There are many ways to create a Work Breakdown Structure (WBS). It can be developed
entirely as a new document, can reuse components from existing WBSs, can be based
on a template, or can follow pre-defined WBS standards. When reusing existing compo-
nents, WBS elements can be drawn from similar projects or from standard project
templates that the organization has determined support accepted good practices.
This chapter discusses the methods used to create a WBS, as well as some considera-
tions that should be taken into account during WBS development. The sections of
this chapter are presented as guides for use during the WBS development process,
while some sections can be used as checklists for the development and refinement of
the WBS. The remaining sections of this chapter are as follows:
5.2 Preparing a WBS
5.3 General Factors to be Considered
5.4 Essential Judgments
5.5 Evaluating WBS Quality
5.6 WBS Usage Continuum
5.7 WBS for Program and Portfolio Management
5.8 Summary
All project, program, or portfolio requirements need to be considered during devel-
opment of the WBS. A critical factor for success at any level is the creation of a high-
quality Work Breakdown Structure.
5.2 Preparing a WBS
The WBS evolves through an iterative consideration of the project’s purpose and
objectives (both business and technical), functional and performance design criteria,
project scope, technical performance requirements, and other technical attributes. A
high-level WBS can often be developed early in the conceptual stage of the project.
Once the project is defined and specifications are prepared, a more detailed WBS can
then be developed. It should be customized to the specific needs and requirements
92312$$CH5 09-07-06 12:27:12

92312$$CH5 09-07-06 12:27:12
of the project. All non-required work and deliverables should be listed and removed
so the WBS represents only the project’s scope. The end result is a WBS that represents
the complete list of deliverables for the project. A number of authors have provided
useful guidance on preparing a WBS (Haugan, 2002; Pritchard, 1998; Uyttewaal, 2005).
The WBS can assist the project manager and stakeholders in communicating a clear
vision of the end product(s) of the project, and of the overall process by which those
products will be created. It helps communicate the work to be accomplished as well
as the interim and end-point deliverables to be completed. With this in mind, the
following list of questions should stimulate thought when developing a WBS to manage
a project:
● Is the project charter defined and issued?
● Is the project scope statement defined and issued?
● Have the project manager and the team formulated a vision of the final product(s),
services, or results?
● Have personnel who will do the work been assigned to develop the WBS?
● What are the project’s component parts?
● How do the pieces work together?
● What needs to be done?
● Have the project’s intended business objectives been defined? What is required to
achieve the business value?
● Has the entire project been thought through? Have the high-level deliverables been
progressively decomposed?
● Have all deliverables, both interim and final, been identified? What is to be provided?
What is required?
● Has the relationship of each component to the end product been defined? How
will this component contribute to the finished deliverables?
● Has the process for production of the deliverables been defined? What methods
will be employed? What special processes will be needed? What are the quality
requirements? What kinds of inspections need to be done?
● Have the activities that are needed to support the deliverables been identified,
including those that directly or indirectly facilitate their creation?
● Has technical input from knowledgeable Subject Matter Experts (SMEs) been
obtained, and is that technical input communicated to and validated by other key
SMEs assigned to the project?
● Does the project require any external sources to contribute to the project and have
they been identified?
● Has all work associated with risk management been identified? Have risks associated
with project assumptions been identified?
These thoughts and questions are intended to help the project manager develop a
clear statement of what the product(s) of the project are. They should be iteratively
reviewed until all questions have been completely addressed and all information is
known—to the extent possible. Once completed, all of the work packages (i.e., the
lowest-level WBS elements) should together comprise the complete list of deliverables
for the project. They depict the project’s scope.
5.2.1 Preparation Methods
A number of methods and tools can be employed to create a WBS including outlines,
organization charts, fishbone diagrams, brainstorming techniques, and top-down and

bottom-up development strategies. WBS templates, as well as corporate guidelines or
standards can be referenced or copied for quick-starting WBS development.
There are many benefits to using tools to develop a WBS. For example, tools often
promote consistency and repeatability in the development of a WBS, especially if it
is an enterprise productivity tool. WBS tools can also promote and enforce the princi-
ples of the organization’s WBS guidelines or standards, and can significantly reduce
the development effort, simplify the WBS process, and even promote reuse of WBS
elements.
Some of the more popular methods employed to create a WBS include a top-down
approach, a bottom-up approach, the use of organization-specific WBS guidelines or
standards, and the use of WBS templates. The choice of appropriate method should
be based on the specific project objectives, requirements, assumptions, and con-
straints. Table 5-1 highlights some advantages and challenges of the aforemen-
tioned methods.
WBS Creation
Method Advantages Challenges
Top-Down ● Structures project conveniently for ● Requires constant attention that no
status reporting work packages are overlooked
● Helps ensure projects are logically ● WBS needs to be elaborated to
structured sufficiently detailed level to permit
● Is valuable when brainstorming/ management oversight and control
discovering project deliverables
● Can accommodate additional
deliverables as they are uncovered
Bottom-Up ● Starts with all deliverables and works ● Identifying all deliverables before
backwards into a project producing the WBS
● Confirms that all work packages are ● Making sure work packages are
included logically grouped
● Can lose focus on big picture
WBS Standards ● Formats are predefined ● Making a project fit the standard
● Enhances cross-project WBS ● Can lead to inclusion of unnecessary
consistency deliverables or failure to include
project-specific deliverables
● Not all projects fit into a highly
structured set of WBS standards
WBS Templates ● Provides a starting point for WBS ● Requires a project fit the standard
creation ● Can lead to inclusion of unnecessary
● May help determine appropriate level deliverables or failure to include
of detail required project-specific deliverables
● Enhances cross-project WBS ● Not all projects fit into a highly
consistency structured set of WBS templates
Table 5-1. WBS Creation Methods
.1 Top-Down
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 deliver-
ables necessary for the project, but which in themselves do not satisfy a
business need (such as a design specification).
92312$$CH5 09-07-06 12:27:12

92312$$CH5 09-07-06 12:27:12
● 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, as noted in the 100% Rule. Each work package of the WBS
should contain only one deliverable.
● Step 4. Review and refine the WBS until project stakeholders agree that project
planning can be successfully completed, and that execution and control will
successfully produce the desired deliverables and results.
.2 Bottom-Up
The following steps describe the general bottom-up process for developing
a WBS:
● Step 1. Identify all of the deliverables (or work packages) involved in the
project. If participants propose activities, then the associated deliverables,
but not the activities, should be included (i.e., translate suggested activities
into associated deliverables). This will encompass the entire output of the
effort. Each work package should contain only one deliverable.
● Step 2. Logically group related work packages (or deliverables) together.
● Step 3. Aggregate deliverables to the next level, for instance, the parent level.
The sum of the elements at each level should represent 100% of the work
below it, as noted in the 100% Rule.
● Step 4. Once a given group of related tasks has been aggregated to a parent,
analyze the subset again to ensure that all of the work has been encompassed.
● Step 5. Repeat until all subelements have been aggregated to a single parent
representing the project. Ensure that the completed structure includes all of
the project scope.
● Step 6. Review and refine the WBS until project stakeholders agree that project
planning can be successfully completed, and that execution and control will
successfully produce the desired deliverables and results.
.3 WBS (Organizational) Standards
An organizational WBS standard is a set of principles for constructing a WBS
and might include a format, numbering scheme, naming convention, or required
elements. WBS standards are common in many organizations with a high level
of project management maturity. These standards help ensure consistency and
completeness in WBSs throughout the organization. Examples of WBS standards
include the following:
● Project management must be a Level 2 WBS element
● Graphical and textual WBS views must be developed and maintained.
.4 WBS Templates
A WBS template is a sample WBS, with hierarchical elements filled in to some
level of detail, or a generic WBS ‘‘container’’ that is customized (i.e., filled) with
project-specific information. An organization can have templates for different
types of projects and different life cycles.
The use of WBS standards and WBS templates helps promote consistency
through reuse of WBSs or WBS components. When reusing existing components,
be sure to customize the WBS to the specific needs and requirements of the
project. Any non-required work or deliverables should be removed so that the
WBS is aligned with the project scope. In addition, the questions defined in

Section 5.2 should again be iteratively reviewed for these two methods. The use
of standards and templates in the creation of WBSs helps promote quality
assurance through the application of successfully applied WBS good practices.
The use of WBS standards and WBS templates differs from top-down and
bottom-up methodology in that top-down and bottom-up are methods of creat-
ing new WBSs, while standards and templates involve the reuse of existing
WBS materials.
5.2.2 Guidance in Choosing a Method for Preparing a WBS
In developing a WBS, the project management team needs to decide first which
development method to use. The choice between a top-down or a bottom-up approach
is somewhat personal, and can depend on the habits and thinking styles of the project
team, as well as on organizational practices. Aside from those considerations, some
guidelines and explanations for which approach might be more appropriate are as
follows:
.1 Top-Down
Use the top-down approach in these situations:
● The project manager and project management team have little to no experi-
ence in developing Work Breakdown Structures. Top-down development
allows for progressive understanding and elaboration of the WBS.
● The nature of the project’s products or services is not well understood. The
development of a WBS jointly with all stakeholders using the top-down
approach is useful in gaining understanding and consensus when the scope
and nature of the project is unclear.
● The nature of the project life cycle is not familiar or well known. Top-down
development of the WBS more easily uncovers life cycle issues and characteris-
tics.
● No appropriate WBS templates are available. When developing a WBS from
scratch, it is far easier to start with the overall project deliverable, such as
building a bicycle, and then iteratively determine subelements.
.2 Bottom-Up
Use the bottom-up approach in these situations:
● The nature of the project’s products or services is well understood. For exam-
ple, if the organization has developed very similar products or services on
previous projects, the project team might already have a very good under-
standing of all interim deliverables required for the new project.
● The nature of the project life cycle is well known. If the organization always
uses the same project life cycle, the interim deliverables for that life cycle are
well known and can be used to begin bottom-up WBS development.
● Appropriate WBS templates are available. If the organization has WBSs from
projects with similar products or services, and these can be reused, a bottom-
up approach enhances the team’s ability to customize the WBS template.
.3 WBS Standards and Templates
In general, if WBS standards or WBS templates are available, they should be
used, with the caveats expressed in Figure 5-1. There are plenty of sample WBSs
available in the literature, but the choice to use sample WBSs as templates must
be made carefully. The organization can have WBS templates for very similar
92312$$CH5 09-07-06 12:27:12

92312$$CH5 09-07-06 12:27:12
projects, and the use of these templates is highly encouraged. However, if the
project significantly differs from other projects in the organization, and no
template seems to apply, develop the WBS from scratch with a top-down
approach.
.4 Iterations
Construction of the WBS is an iterative process and may rely on more than one
method to produce the final high quality WBS. For example, a WBS template
and the top-down approach may be used initially to determine the overall
structure of the WBS, while it might be more appropriate to use the bottom-
up method to verify that all the elements are present to achieve a particular
deliverable.
Regardless of what method is chosen to prepare the WBS, the resulting WBS must
have all the core characteristics of a high-quality WBS. The WBS must describe 100%
of the work on the project, must be oriented toward deliverables rather than activities,
and must be hierarchically arranged. For additional details on WBS quality principles,
please see Chapter 4, and specifically Section 4.2 for a discussion of WBS core quality
characteristics.
5.3 General Factors to Be Considered
In developing a WBS, the following basic tenets should be considered:
● Each WBS element represents a single tangible or intangible deliverable.
● Deliverables include both final and interim deliverables that are required to create
the final results.
● Deliverables include intangible items, such as information/communication, integra-
tion, administration, training, process management, and procurement.
● All deliverables are explicitly included in the WBS.
● Deliverables are unique and distinct.
● All significant reporting mechanisms, such as review meetings, monthly reports
and test reports are included and identified in the WBS.
● Clearly defining the project deliverables, so that each is unique, ensures there will
be no duplication in the outcomes of the project or of the work performed to
produce the end-products.
● Accountability for each work package can be assigned to a single project team
member or subcontractor. If this is not possible, then reconsider whether or not
the work package can be further decomposed.
● Each element in the WBS representing subcontracted or externally committed deliv-
erables directly corresponds to matching elements in the subcontractor’s WBS.
● The deliverables are logically decomposed to the level that represents how they will
be produced and managed (e.g., designed, purchased, subcontracted, or fabricated).
● All WBS elements are compatible with organizational and accounting structures.
The following basic guidelines should be considered when organizing WBS elements
into the WBS hierarchy:
● Each WBS element belongs to only one parent WBS element.
● The set of child elements into which a parent element is decomposed includes all
of the work contained in the parent, such that the 100% Rule applies.

● A coding scheme is used for WBS elements that clearly represents the hierarchical
structure when viewed in text format.
● All ‘‘legs’’ of the WBS need not be to the same depth. Some areas of the WBS will
need to show more detail than others.
● There is no need to have all work packages at the same level.
The WBS development process should:
● Be iterative
● Be reviewed and revised as the rest of the project planning process progresses
● Provide a vehicle for flexibility, particularly when the scope of the project effort
might change.
A well-managed project, however, will incorporate a rigorous change control process
to document and manage scope changes. When work scope changes do take place,
the WBS must be updated. Any change in the WBS requires an associated change in
related project management tools, such as the WBS Dictionary, network diagram,
and schedule.
5.3.1 Project Management Knowledge Area Considerations
In the iterative WBS development process, the following guidelines and questions
should be considered as they relate to each Project Management Knowledge Area in
the PMBOK威 Guide—Third Edition:
.1 Project Integration Management
● Include work in the WBS for the integration of components. Place the WBS
element for component integration at the same level as the components being
integrated.
● Include work in the WBS for the necessary communications and meetings
required for effective integration management.
● Is the work defined by the WBS grouped in a logical manner? Have all reporting
and control mechanisms been addressed?
.2 Project Scope Management
● WBS development is critical to scope management. Revisit the WBS often
and expect to iterate WBS development.
● Are requirements defined and approved?
● Is there a statement of work, a set of contract requirements, or other docu-
mented requirements? Be sure that each WBS element can be traced to these
requirements. Include only those activities that are considered in scope and
can be traced to contractual or other requirements.
● As the WBS is defined, keep a list of activities and efforts that are considered
to be out of scope. Confirm scope with stakeholders often by reviewing the
WBS and the out of scope list.
● Are all deliverables explicitly identified in the WBS?
● Will horizon or rolling wave planning be applied to develop or further decom-
pose the scope progressively over time?
● Have historical data, risk registries, checklists, and lessons learned been con-
sulted to ensure identification of all work?
92312$$CH5 09-07-06 12:27:12

92312$$CH5 09-07-06 12:27:12
.3 Project Time Management
● Deliverables should be decomposed to the level of detail needed to estimate
the effort required to obtain or create them.
● How will the status of work in progress be determined?
.4 Project Cost Management
● Deliverables should be limited in size and definition for effective control—
not so small as to make cost of control excessive, and not so large as to make
the item unmanageable or the risk unacceptable.
● How will budgets be established?
● Will it be possible to relate the budget to the proposed work assignments?
● Is the level of detail in the WBS appropriate for effective planning and control?
.5 Project Quality Management
● Will the quality of the work be evaluated through efforts such as testing and
inspection?
● Are there quality requirements for the project? If so, be sure to include WBS
elements to document the periodic review of quality requirements, quality
management activities, quality audits, and quality reviews.
● Are there requirements to show compliance with ANSI, ISO or other standards?
If so, include WBS elements for outside auditing of the project for compliance.
● Are there quality requirements defined for the deliverables outlined in the
WBS?
● Have metrics been defined for how the deliverables will be measured?
.6 Project Human Resource Management
● Ensure that each WBS element has a single point of accountability. If a WBS
element might involve more than one accountable person, consider decom-
posing the WBS element.
● Is all the work planned to a degree of detail necessary to make and keep
commitments?
● Ensure that the reporting structure indicated by this WBS supports establish-
ing and managing individual work assignments.
● Can work assignments be established from a progressive expansion of the
WBS?
● How will work generally be assigned and controlled?
● Will it be possible to reconcile individual work assignments to the formal
scheduling system?
● Is more than one organization involved, requiring validation of the WBS with
others before doing detailed resource planning?
.7 Project Communications Management
● Have all communication needs been accounted for?
● Are there long distance, Regional, National and International communica-
tions required?
● Are there any special deliverables required for international communications,
such as translations and other country-specific requirements?
● Are there special communication needs for any deliverables outlined in the
WBS?

.8 Project Risk Management
● For areas of the WBS that are considered high-risk, consider decomposing
the WBS to a more detailed level. This will allow better definition of assump-
tions and expectations, and will allow for more accurate planning, thus reduc-
ing risk.
● Are the deliverables completely and clearly defined?
● What is the likelihood of change?
● Is the technology changing faster than the project can be accomplished?
● Have manpower, facilities capability, availability of internal resources, and
potential suppliers been checked?
● Has a formal change process been defined and implemented?
● Have metrics been defined for how the deliverables will be measured?
● Have resource requirements been identified for development of the project
deliverables?
● Have other risks been identified, including stakeholder buy-in, public rela-
tions, management approval, team understanding, and project opposition?
● Has both an internal and external communication plan been defined and
implemented?
● Are third-party dependencies understood and monitored for change?
● Have alternate suppliers of required products, supplies, or expertise been
identified?
● Have historical data, risk registries, checklists, and lessons learned been con-
sulted to ensure identification of all risks?
● Has risk management and contingency work been included?
.9 Project Procurement Management
● Is extensive subcontracting expected?
● Is there a WBS element for each procured deliverable?
● Are intangible deliverables required for managing the procurement process?
● Will procurement be managed by the project team or by an existing procure-
ment organization?
5.4 Essential Judgments
Effective application of use-related characteristics relies on experience and judgment.
This section examines that concept in a bit more detail. Factors that can vary from
one project or application to another, depending upon the purpose for which the
WBS is intended, include, but are not limited to, the level of detail needed in the
decomposition of the deliverables, the selection of the type of WBS element to be
included, and structuring the logic of the decomposition.
5.4.1 Determining Appropriate WBS Level of Detail
The WBS development process has been described as proceeding to successive levels
of increasing detail, culminating in a level of detail that captures all elements of the
scope of the project. This process also provides needed insight for clear communica-
tions and effective project management. The level of detail in a WBS is a function of
the size of the project, and reflects a balance between complexity, risk, and the project
manager’s need for control. The level of detail can also vary during the evolution of
a project. A top-down and bottom-up analysis of the WBS can clarify whether the
WBS is both complete and defined at the proper level of detail.
92312$$CH5 09-07-06 12:27:12

92312$$CH5 09-07-06 12:27:12
Short-duration projects can lend themselves to decomposition to a high degree
(extensive level) of detail at the outset, while projects of longer duration and higher
complexity can preclude decomposition of all deliverables until more is known about
the project. Again, this means that on any given project, some portions of the WBS
can have different levels of decomposition. This is especially true when doing rolling
wave planning, where the plan is detailed only for the immediately upcoming work,
and work far in the future is defined at a high level until later in the project life cycle.
When proceeding to successive levels of increasing detail, the 100% rule must still
apply. This rule states that the children nodes of a parental node must make up 100%
of the work of that parental node. Additionally, not all legs of the WBS must be
symmetrical in terms of the number of levels developed. There is no need to decompose
all legs of the WBS if the need is only present in one area.
Should the WBS be decomposed further? The following questions provide guidance
for determining the need for further decomposition of the WBS. If the answer to any
of these questions is yes, then further decomposition should be considered. The greater
the number of positive answers, the stronger the justification for further division of
some or all of the WBS.
.1 Scope and Work Package Detail
● Are clear, objective criteria missing for measuring the progress for the WBS
element?
● Does the WBS element contain more than one deliverable?
● Do prerequisites differ among internal deliverables within the WBS element?
● Can a portion of the work to be performed within the WBS element be sched-
uled as a unit?
● Are there acceptance criteria applicable before completion of the entire
WBS element?
● Is the WBS element clearly and completely understood to the satisfaction
of the project manager, project team members, and other stakeholders—
including the customer?
● Are there relationships between internal WBS element deliverables and other
external WBS elements?
● Is there a stakeholder interested in analyzing status and performance of only
a portion of the work covered by the WBS element?
● Can progress of the work be assessed as needed?
.2 Resources and Risks
● Can the work element be assigned to a single accountable individual? While
there might be a variety of resources assigned to a given WBS element, there
should ultimately be only one individual accountable for delivery of the
work package.
● Are there specific risks that require focused attention to a portion of the
WBS element?
● Can actionable risks be identified for each WBS element?
.3 Costs and Timing
● Are there significant time gaps in the execution of the work processes internal
to the WBS element?
● Is there a need to improve the accuracy of the cost and duration estimates
of the WBS element?
● Is there a need to separately define the cost of work processes or deliverables
internal to the WBS element?
● Is there a need to precisely know and report the timing of deliverables internal
to the WBS element?

5.4.2 Selection of the Type of WBS Element to be Included
A WBS organizes and defines the total work scope of the project. Not every WBS,
however, needs to include all types of work. Rather, the kinds of work included in a
WBS should be dictated by the scope and nature of the project for which the WBS is
being developed. Some examples of this are presented here.
● Some projects require certain types of WBS elements that are not necessary for
other projects. For example, in a project that involves production of several different
components that need to be assembled into a finished product, it would be necessary
to include an integration or assembly WBS element so that the assembly work can
be identified, resourced, tracked, and reported. In contrast, a project to develop a
business process might not require such an assembly element.
● All projects require a project management WBS element at Level 2, in order to
ensure that the work of planning, tracking, and reporting is adequately captured
and managed. A particular organization, however, might require use of a standard-
ized WBS template that does not include certain kinds of project management
WBS elements (for example, administration, documentation, or reporting elements)
because the need for these is adequately addressed by other business processes
established by that organization. In such cases, these elements would not be
required.
● Quality assurance is applicable to all projects. Some organizations could have
requirements for compliance with specific quality standards. In such cases, the
WBS must include elements, such as documentation and audits, to account for
compliance with the specified procedures.
5.4.3 Structuring the Logic of the Decomposition
An essential feature of a WBS is that it clearly and comprehensively defines the scope
of the project work through decomposition of deliverables into a hierarchy of simpler
components, thereby providing one of the primary methods for managing complex
projects. The way that the project manager decomposes the project (i.e., the logic
used for decomposing the work) can vary depending on the needs and requirements
of the performing organization and the use to which the WBS will be put. This is
illustrated by the following examples:
● One organization might be structured along very strict functional lines, with few
business processes that facilitate communication among the separate subunits. In
such a case, it can make sense to structure the decomposition in terms of the work
and sub-deliverables that each function independently contributes. In contrast, in
a projectized organization without functional divisions, the same deliverable might
more effectively be decomposed into a hierarchy of subassemblies.
● Where new product development proceeds in sequential stage-like phases with
later work contingent on the outcome of earlier work, it would make sense to
organize the WBS in terms of the product development life cycle, rather than in
terms of physical components of the product.
● A food-service enterprise with regional offices might find it particularly valuable to
structure the WBS for a program to create a new chain of restaurants as a series
of geographic subprojects, while a centralized enterprise that sub-contracts, for
instance, building development, food sourcing, or marketing, would find it more
useful to decompose the new restaurant program in terms of sub-systems.
In all cases, it is important that the WBS remain deliverable-oriented, rather than
process-oriented, and explicitly contain all intermediate deliverables.
92312$$CH5 09-07-06 12:27:12

92312$$CH5 09-07-06 12:27:12
5.5 Evaluating WBS Quality
There are several points that are considered essential when creating a WBS. As detailed
in Chapter 4, there is a set of core characteristics that every WBS must have, which
enable it to satisfy project needs. Failure to address these considerations can lead to
failure of the project, because there would be a high risk of not identifying all of the
required work.
5.5.1 Core Characteristics
● The WBS structure is not based on timing or sequence dependencies among compo-
nents. Timing, sequencing, and dependencies are project schedule concerns.
● The WBS is not structured strictly by process or organization.
● The WBS defines the logical relationships among all the components of the project.
● All WBS elements are deliverable-oriented.
● Project activities are not listed, as these are components of the project schedule,
not the WBS.
● All element names are nouns. Verbs are not used to identify WBS elements.
● The WBS includes only sufficient and necessary deliverables. All deliverables are
necessary components of the project’s product, service, or end result, and are
defined in the project’s scope.
● All project deliverables including regulatory permits, packaging, distribution, or
marketing, as well as preliminary, interim, internal, external, or final deliverables,
are identified and detailed.
● There are no WBS elements with overlapping responsibilities. Each WBS element
must have one person who is clearly accountable for its completion.
Also, as discussed in Chapter 4, there is an additional set of use-related characteris-
tics that might vary from one WBS to another. These characteristics enable the use
of the WBS for purposes that can be unique to a specific project, industry, or environ-
ment, or are applied in a particular way on individual projects. With respect to use-
related characteristics, the quality of the WBS depends on how well the specific content
and type of WBS elements meet the use for which the WBS was intended.
5.5.2 Use-Related Characteristics
● Identify key project management (non product) work such as:
䡩 Initiating, planning, executing, monitoring and controlling, and closing
䡩 Process management
䡩 Services and provisioning
䡩 Information/communication
䡩 Administrative documentation, training, and software.
These should be defined as level-of-effort WBS elements in those cases where they
can be interim deliverables, do not themselves generate discrete deliverables, and
might not be included in the delivery of the final product.
● Include cross-project WBS elements, such as those representing opening and closing
stages, for example, planning, assembly, integration, and testing.
● Balance the project definition aspects of the WBS with the data collecting and
reporting requirements. The primary purpose of the WBS is to define the project’s
scope through the decomposition of deliverables.
● Decompose the WBS to the appropriate level of detail by achieving a balance
between project complexity, risk, and the project manager’s need for monitoring
and control.
● Do not decompose the WBS too far. Each WBS is a tool designed to assist the project
manager with decomposition of the project only to the levels necessary to meet

the needs of the project, the nature of the work, and the confidence of the team.
Excessive WBS levels can require unrealistic levels of maintenance and reporting.
● Do not omit WBS development, such as Gantt chart, CPM schedule or precedence
diagram before proceeding to the network diagram. Omitting the development and
refinement of the WBS can lead to unforeseen and unexpected difficulty, including
project delays, cost over-runs, or outright project failure.
5.6 WBS Usage Continuum
The ability of a WBS to meet the needs of a project is directly related to the level of
project management competency available within the project management team.
An experienced project management team will be able to identify a greater range
of stated and implied project needs that the WBS can address. A more experienced
project management team will ensure the WBS is employed in a greater variety of
project roles, and will use the WBS in more efficient and sophisticated ways than will
a novice or inexperienced project management team. A WBS can be of high quality
even if it is not being used to its full capacity by the project management team.
The project management team’s development and use of the WBS as an effective
planning and control tool represents its position on the WBS usage continuum. In
other words, once the project management team begins using a WBS within the project
context, their ability to make the WBS play an important defining and controlling role
for scope, budget, and risk follows a growth continuum similar to that of any other
project management methodology or tool. The following is an experience continuum
for WBS development and use:
Figure 5-1. WBS Usage Continuum
92312$$CH5 09-07-06 12:27:12

92312$$CH5 09-07-06 12:27:12
5.7 WBS for Program and Portfolio Management
According to the PMBOK威 Guide—Third Edition, projects, programs and portfolios
are defined as follows:
Project. A temporary endeavor undertaken to create a unique product, service, or
result.
Program. A group of related projects managed in a coordinated way to obtain benefits
and control not available from managing them individually. Programs may include
elements of related work outside of the scope of the discrete projects in the program.
Portfolio. A collection of projects or programs and other work that are grouped together
to facilitate effective management of that work to meet strategic business objectives.
The projects or programs of the portfolio may not necessarily be interdependent
or directly related.
Work Breakdown Structures are useful not only for projects, but for programs and
portfolios as well. Use of the WBS at these levels is a growing practice. There is no
conceptual difference among a project WBS, a program WBS, or a portfolio WBS. A
high-quality WBS developed at any of these broader levels possesses precisely the
same characteristics and attributes as a high-quality WBS developed at the individual
project level. These differ only in the breadth of the content (scope).
All of the principals defined in Section 4 that apply to a project WBS also apply to
a program or portfolio WBS. Great care should be taken, however, when working with
WBSs beyond the program level. The difficulty in verifying that all work and deliverables
are defined increases significantly as the scope increases.
5.8 Summary
This chapter has shown that there are many ways in which a WBS can be created. It
can be developed as an entirely new document, can reuse components from existing
WBSs, can be based on a template, or can follow predefined WBS standards. Regardless
of the method used to construct it, the WBS evolves through an iterative consideration
of the project’s scope, including the project’s purpose and objectives (both business
and technical), functional and performance design criteria, technical performance
requirements, and other technical attributes.
This chapter has presented several guidelines and checklists to assist in the prepara-
tion of a WBS. All other Project Management Knowledge Areas (such as Project Time
Management, Project Cost Management, and Project Quality Management) are highly
dependent upon the resulting WBS. In the end, a high-quality WBS provides a strong
foundation upon which to build a successful project.

Appendix A
Guidelines for a Project
Management Institute Practice
Standard
● Each practice standard provides guidelines on the mechanics (e.g., nuts and bolts,
basics, fundamentals, step-by-step usage guide, how it operates, how to do it) of
some significant process (input, tool, technique, or output) that is relevant to a
project manager.
● A practice standard does not necessarily mirror the life-cycle phases of many proj-
ects. But, an individual practice standard may be applicable to the completion of
one or more phases within a project.
● A practice standard does not necessarily mirror the knowledge areas within A Guide
to the Project Management Body of Knowledge/Third Edition (PMBOK威 Guide),
although an individual practice standard will provide sufficient detail and back-
ground for one or more of the inputs, tools and techniques, and/or outputs. There-
fore, practice standards are not required to use the name of any knowledge area.
● Each practice standard should include information on what the significant process
is and does, why it is significant, how to perform it, when it should be performed
and, if necessary for further clarification, who should perform it.
● Each practice standard should include information that is accepted and applicable
for most projects most of the time within the project management community.
Processes that are generally restricted or applicable to one industry, country, or
companion profession (i.e., an application area) may be included as an appendix
for informational purpose, rather than part of the practice standard. With strong
support and evidence, an application area-specific process may be considered as
an extension practice standard, in the same manner as extensions to the PMBOK威
Guide—Third Edition are considered.
● Each practice standard will benefit from the inclusion of examples and templates.
It is best when an example or template includes a discussion of its strengths and
weaknesses. A background description may be necessary to put this discussion in
the appropriate context. The examples should be aligned with the relevant informa-
tion in the standard or its appendix and placed in proximity to that information.
● All practice standards will be written in the same general style and format.
92312$$CH6 09-08-06 04:30:35

92312$$CH6 09-08-06 04:30:35
● Each practice standard project will assess the need to align with or reference other
practice standards.
● Each practice standard will be consistent with the PMBOK威 Guide—Third Edition.
● Each practice standard is intended to be more prescriptive than the PMBOK威
Guide—Third Edition.

Appendix B
Evolution of the Project
Management Institute Practice
Standard for Work Breakdown
Structures
B.1 Initial Development: 1999–2001
During the development and subsequent publication by the Project Management
Institute (PMI威) of A Guide to the Project Management Body of Knowledge (PMBOK威
Guide), it was recognized that project management practitioners and other stakehold-
ers would be aided by more in-depth treatment of the listed inputs, tools and tech-
niques, and outputs. Consequently, in early 1998, PMI asked for volunteers to develop
the first such practice standard, specifically on the Work Breakdown Structure (WBS).
A volunteer team was assembled and during the year worked through a number of
drafts and revision cycles.
In early 1999, PMI Project Management Standards Program Team reviewed the
draft and recommended the completion of the Practice Standard. In late spring 1999,
Kim Colenso was approved as the new project manager for the Practice Standard. He
was tasked to form a new team to make minor modifications to the current draft, and
add example WBSs. The plan was to publish the Practice Standard for Work Breakdown
Structures in an Exposure Draft to the PMI membership and other affected parties by
the summer of 2000, and a final document would be published as a PMI Standard
in 2001.
A team was assembled during the summer and fall of 1999 through solicitation of
participation from the PMI Specific Interest Groups and other volunteer sources.
During this period, a controversy developed within the project team as to whether or
not an activity was or should be part of the WBS. Through further discussion among
the project team and among the PMI Project Management Standards Program Member
Advisory Group, the issue was resolved, and an article describing the outcome was
published in the PM Network in April 2000 (see References).
The project team implemented a formal change-control procedure to guide and
control the evolution of the practice standard. This procedure required all proposed
92312$$CH7 09-08-06 04:33:22

92312$$CH7 09-08-06 04:33:22
changes to be documented and approved by the project team. As a result of this
process, the following events occurred:
● The team judged the structure of the specific working draft supplied by the PMI
Project Management Standards Program Team to be unsatisfactory. With the
approval of the PMI Project Management Standards Program Team, that draft
was replaced with the earlier November 1998 draft, to which all further changes
were applied.
● Over forty formal change requests were submitted and approved by the team
between October 1999 and April 2000. Another six were disapproved, as the argu-
ments were deemed unpersuasive.
● Twelve WBS examples were approved and incorporated as Appendices D through
N of this practice standard.
The revised draft was submitted to the PMI Project Management Standards Program
Team in May 2000 for consideration as the exposure draft to be circulated among
PMI membership and other affected parties. Following approval by the PMI Project
Management Standards Program Team, the proposed exposure draft was submitted
for formal review to six other knowledge experts. The team evaluated the comments
from these six reviewers and the PMI Project Management Standards Program Team.
A final draft was then submitted to the PMI Project Management Standards Program
Team and approved for the exposure draft.
The exposure draft was submitted for public review on 29 September 2000, with
an exposure closure on 30 November 2000. During this period, 488 comments were
received. All comments that the project team accepted for the current version have
been incorporated.
When we look at the PMBOK威 Guide—Third Edition, it is a remarkable achievement.
It has gone through an evolutionary process for fourteen years. Each edition has
improved upon the previous version. After several editions, the result is an extremely
refined and powerful document. The same will be true for the Practice Standard for
Work Breakdown Structures. It has gone through its initial development. Now it is
ready to begin its journey through the refinement process.
B.2 Second Edition: 2003–2006
In April of 2003, the Practice Standard for Work Breakdown Structures update team
received its charter from the PMI Standards MAG (Membership Advisory Group) and
began the update to the first practice standard published by PMI. Following guidance
received from the Standards Manager and MAG regarding approach, strategy, objec-
tives, content, size, and structure, the team examined the existing practice standard
as well as comments and recommendations received during the previous review and
publication cycles. The update team also conducted surveys of project managers from
a cross section of industries.
This analysis, which spanned a number of months, revealed the need for significant
change to the practice standard to clarify the guidance it provides and improve its
relevance. To summarize, the update team found there was a need to:
● Ensure the practice standard provides a consistent approach to WBS development
throughout the body of the document
● Update the content to bring guidance in line with current practice and WBS applica-
tion
● Use examples and figures throughout to clarify guidance provided

● Provide new material within the practice standard to clearly explain differences
between poorly and well-constructed work breakdown structures
● Ensure the appendices reflect the guidance provided in the practice standard and
provide a greater number of varied examples
● Provide a breakdown (WBS example) of the project management work defined by
the PMBOK威 Guide—Third Edition
● Add templates (WBS examples) that can be extracted and modified by practitioners
who purchase the practice standard
● Provide a detailed perspective of the historic evolution of the concepts relating to
work breakdown structures
● Synchronize the WBS practice standard with the latest release of the PMBOK威
Guide—Third Edition
● Limit the content to WBS-related topics only, removing content related to schedul-
ing, Earned Value Management and other non-WBS items.
With these items as an outline for the ‘‘desired outcome’’ and the analysis described
above as the starting point, the update team began framing the second edition of the
practice standard. By using an iterative development process, internal team comment
review cycles, as well as SME (Subject Matter Expert) reviews and interviews, the team
developed the latest updates to the practice standard content. The team additionally
worked closely with PMI’s standards organization to design the appropriate context
for publication of the new standard—reflecting latest technology and the needs of the
project management community at large.
As a result, the updated standard, Practice Standard for Work Breakdown Struc-
tures—Second Edition, now contains the following changes and improvements:
● Material in each of the original chapters has been rewritten for clarity
● A new chapter on WBS Quality was added
● The original appendices were revised to reflect current practice and quality attributes
● Appendices have been added to illuminate various methods for representing the
WBS
● A CD-ROM is included with the practice standard and will contain the body of the
practice standard, the appendices, and the white paper
● All of the examples found in the appendices will be extractable from the CD-Rom
as templates for use in WBS development
Most importantly, the update team worked to ensure synchronization among the
latest release of the Practice Standard for Work Breakdown Structures, the PMBOK威
Guide—Third Edition, the current Earned Value Management Practice Standard, and
the latest release of PMI’s Lexicon for Project Management, while at the same time
partnering with the Practice Standard for Scheduling Team and anticipating the release
of a new Practice Standard for Scheduling.
To support the needs of project managers in today’s environment, this updated
practice standard provides the reader with new guidance regarding WBS construction
and quality attributes. Beyond this, the update to the practice standard will be pub-
lished as a hardcopy document—and will include a CD-ROM to provide the reader
with the ability to scan and search the entire document for specific words or content.
The CD-ROM will also carry copies of each of the appendices found in the practice
standard. The electronic versions of the appendices will be presented as templates
that can be, extracted, copied and modified by project managers for use in their own
projects and programs.
92312$$CH7 09-14-06 11:03:17

92312$$CH7 09-08-06 04:33:22
We believe the latest release of the Practice Standard for Work Breakdown Structures
reflects the outstanding achievement of the team that created the first edition and
continues the tradition of extending and enhancing the document while setting the
stage for the continued evolution of the practice standard.

Appendix C
Contributors and Reviewers of
the Practice Standard for Work
Breakdown Structures—Second
Edition
This appendix lists, alphabetically within groupings, those individuals who have con-
tributed to the development and production of the Practice Standard for Work Break-
down Structures—Second Edition. No simple list or even multiple lists can adequately
portray all the contributions of those who have volunteered to develop the Practice
Standard for Work Breakdown Structures—Second Edition. Appendix B describes spe-
cific contributions of many of the individuals listed below and should be consulted
for further information about individual contributions to the project.
The Project Management Institute is grateful to all of these individuals for their
support and acknowledges their contributions to the project management profession.
C.1 Practice Standard for Work Breakdown Structures—Second
Edition Project Core Team
The following individuals served as members, were contributors of text or concepts,
and served as leaders within the Project Core Team (PCT):
Eric S. Norman, PMP, Project Manager Robert T. Fried, PMP
Shelly A. Brotherton, PMP, MPM, Maggie Godbold, PMP, CQM
Deputy Project Manager George A. Ksander, PMP
Jim Christie, PMP Giuseppe A. Sarrica, PMP
C.2 Significant Contributors
Significant contributors supported key activities for the update to the Practice Standard
including editing and sub-team participation in project efforts such as Content, Author-
92312$$CH8 09-22-06 10:36:50

92312$$CH8 09-22-06 10:36:50
ing, Quality, Communications and Research sub-teams. The update project’s signifi-
cant contributors offered depth of knowledge and insight as Subject Matter Experts
(SME) in their fields of practice. In addition to the members of the Project Core Team,
the following individuals provided significant support, input or concepts:
Thomas L. Barnett, PMP Roy D. Pollack, PMP
Andrea Macias Hans (Ron) Ronhovde, PMP
Tom Malicki Eric Uyttewaal, PMP
Linda H. Nelms, PMP Julizvar Wu, MM, PMP
C.3 Practice Standard for Work Breakdown Structures—Second
Edition Project Team Members
In addition to those listed above, the following Practice Standard for Work Breakdown
Structures—Second Edition Team Members provided input to and recommendations
on drafts of the Practice Standard for Work Breakdown Structures—Second Edition:
Syama Adhibhatta, PMP Priumvada Agarwal, PMP
Vivek Agarwal Nagy V. Andras Peter
Arch Alejandro Arellano Suman Batra
Bonita A. Best, MBA, TM Gayathri Bhashyam
Rajat Bhatnagar, PMP Subbarao Boppana, PMP
Thomas S. Brinks, PMP Paul R. Buckthal, PMP
Dino Butorac, PMP Sangeeta Carter
Lloyd A. Case Mark Cassorla
Naga Sankar Chinnakotla Ashwini Chouthai, PMP
Bhaskar Chowdhury, PMP Ken Christiansen, PMP
Billy Cottone Fabienne Coutard
Richard D. Curtin, PMP Doaa K. Darwish, PMP, CCT
Satish Dave, PMP Pramod Dhumal, PMP
Raphael M. Dua, FAICD, MACS Lisa L. Doyle
Robert C. Enderle, PMP Bill Engel, PMP
Felix Kayode Eretan Adrian Alberto Fajardo-Brou
Olatunji Fatona, PMP John H. Glander
Scott Graffius, PMP Huiping Guo, PMP
Mahnaz Hajireza Matthew Handi, PMP
Holly Hickman Kent A. Hopkins, MBA, PMP
Edmund N. Hudon, PMP Patrick F. Infante, PMP
Khalid Ishaque Ko Ito, PMP
Shally Iyer Valerie A. Jachimowicz Esq., PMP
M. Aamir Jelani Ramprasad Jillala, PMP
Praveen Jonnalagadda, Ph.D., PMP Atul Joshi
William J. Kanfield, PMP Saminia Karim, PMP
Sharon Kinney-Romeo, PMP Maria Kontoyianni, Ph.D.
Abhilash Kuzhikat, PMP, ITIL Johnson Liu
Mushuang Liu Hrvoje Lorencin
Levi Ma Krishna Mohan Malladi, PMP
Adil Marsamane Tracey Alina Martin
Lito O. Matados, PE David McKenna, MSc., PMP
Daniel H. Miralles, PMP Anna Mlynski, PMP
Bogdan Moldoveanu, PMP Marion Montgomery, PMP

Michael Morton Kerry Mulloy, PMP
Pia Nielsen Wagner Irene Norman
David Oleski Cagla Oz
Ramesh Palaniyandi, Msc, ISP Kenneth Pao, PMP
Kathryn H. Perito, MBA, PMP Earl Vincent Pineda, MSC
Elena Popova Catherine Prochaska
Deepesh Rastogi Kasturirangan Rajagopalan
Jennifer Read, PMP Vedhavalli Reddy, PMP
James Clayton Redmond William Rini, PMP
Donald G. Ritchie, MBA, PMP Colin Roberts, PMP
Vinay R. Shah, PMP, P.Eng. Ankur Sharma
Timothy Sheridan, PMP Elizabeth Smith
Patricia Smith Antonio Jose Soares, PMP
John E. Spaeth, PMP James C. Steele
Elfreda Strydom Mariko Sugi, PMP
Nagla Toma Unmesh L. Trivedi
Margaret Tumminia Brenda Verno
Eduardo Newton O. Viera Claude A. Walz, PMP
Kevin R. Wegryn, PMP, CPM Lance Williams, MS/MIS, PMP
Mari Williams Marc Lee Winnig
Doug Winters, PMP, SSBB Ying Kai Wong
Kashif Zubair
C.4 Final Exposure Draft reviewers and contributors
In addition to team members, the following individuals provided recommendations
for improving the Practice Standard for Work Breakdown Structures—Second Edition:
Randall P. Ash, PMP Kenneth P. Katz, PMP
Hussain Ali Al-Ansari, Eur Ing, C Eng. Thomas M. Kurihara
Mohammed Abdulla Al-Kuwari, PMP, C Eng. Edward Logan, CBM, MSPM
Mohammed Safi Batley, MIM Glen Maxfield, PMP
Alex S. Brown, PMP Timothy A. MacFadyen, MPM, PMP
Lorri Cline, MBA, PMP Kazuhiko Okubo, PMP, PE
John E. Cormier, PMP Hans (Ron) Ronhovde, PMP
Julia A. Cunningham, PMP Larry Sieck
Wanda Curlee, PMP Carol Steuer, PMP
Roy C. Greenia, PMP Ed Thomson, PMP
C.5 PMI Project Management Standards Program Member Advisory
Group
The following individuals served as members of the PMI Standards Program Member
Advisory Group during development of the Practice Standard for Work Breakdown
Structures—Second Edition:
Julia M. Bednar, PMP Asbjorn Rolstadas, Ph.D.
Carol Holliday, PMP Cyndi Stackpole, PMP
Thomas Kurihara Bobbye Underwood, PMP
Debbie O’Bray Dave Violette, MPM, PMP
92312$$CH8 09-22-06 10:36:50

92312$$CH8 09-22-06 10:36:50
C.6 Production Staff
Special mention is due to the following employees of PMI:
Ruth Anne Guerrero,
PMP, Standards Manager
Kristin L. Vitello,
Standards Project Specialist
Nan Wolfslayer,
Standards Project Specialist
Donn Greenberg,
Manager, Publications
Dan Goldfischer,
Editor-in-Chief
Barbara Walsh, CAPM,
Publications Planner

Appendix D
Bicycle Work Breakdown
Structure (WBS) Example
D.1 Overview
In Chapter 3, Work Breakdown Structure (WBS) ‘‘use-related characteristics’’ were
described. These are WBS characteristics that vary from one project to another so that
the WBS better satisfies the requirements of a specific project, industry or environment.
Consistent with this principle, a WBS can be represented in a variety of ways in
order to achieve a specific purpose in a specific situation. A single WBS may also be
represented in more than one way in various situations on a given project. This
appendix illustrates a number of formats that are found in common practice today.
All of these representations, as well as others not included here, may be used to detail
the scope of a specific project. To allow the reader to focus on the differences among
the various representations, a single WBS will be used to illustrate each format.
To help simplify the comparison of these WBS formats, we have chosen the bicycle
project example described in the text of the practice standard.
D.2 Outline View
A very common representation of the WBS is the Outline View in which each level of
the WBS is shown by the level of indentation and is accompanied by an alphanumeric
outline code, or numbering scheme. Outline views are readily developed using a
number of common tools, including word processors and spreadsheets
1 Bicycle
1.1 Frame Set
1.1.1 Frame
1.1.2 Handlebar
1.1.3 Fork
1.1.4 Seat
1.2 Crank Set
1.3 Wheels
1.3.1 Front Wheel
1.3.2 Rear Wheel
1.4 Braking System
92312$$CH9 09-22-06 10:39:17

92312$$CH9 09-22-06 10:39:17
1.5 Shifting System
1.6 Integration
1.6.1 Concept
1.6.2 Design
1.6.3 Assembly
1.6.4 Testing
1.6.4.1 Component Test
1.6.4.2 Product Test
1.6.4.3 Customer Test
1.7 Project Management
For some purposes, the outline view might not use indentation, but simply show the hierar-
chical structure through the numbering scheme:
WBS
Level Code Element Name
1 1 Bicycle WBS
2 1.1 Frame Set
3 1.1.1 Frame
3 1.1.2 Handlebar
3 1.1.3 Fork
3 1.1.4 Seat
2 1.2 Crank Set
2 1.3 Wheels
3 1.3.1 Front Wheel
3 1.3.2 Rear Wheel
2 1.4 Braking System
2 1.5 Shifting System
2 1.6 Integration
3 1.6.1 Concept
3 1.6.2 Design
3 1.6.3 Assembly
3 1.6.4 Testing
4 1.6.4.1 Component Test
4 1.6.4.2 Product Test
4 1.6.4.3 Customer Test
2 1.7 Project Management
Table D-1. Hierarchical Structure
Eliminating indentation may make the WBS less intuitive for the reader, but may save
space in certain documents.
D.3 Tabular View
Another common representation of a WBS is the Tabular View in which the hierarchical
structure is represented through columns in a table. Tabular views are common in

situations where it may be difficult to use a more graphical format, such as text
document with limited formatting capability.
Level 1 Level 2 Level 3 Level 4
1 Bicycle WBS
1.1 Frame Set
1.1.1 Frame
1.1.2 Handlebar
1.1.3 Fork
1.1.4 Seat
1.2 Crank Set
1.3 Wheels
1.3.1 Front Wheel
1.3.2 Rear Wheel
1.4 Braking System
1.5 Shifting System
1.6 Integration
1.6.1 Concept
1.6.2 Design
1.6.3 Assembly
1.6.4 Testing
Table D-2. Tabular View 1
A different type of tabular structure is sometimes encountered in government publi-
cations. Such displays often include additional information such as cost accounting
codes, organizational elements responsible for the WBS element, etc. It may be difficult
to display more than a few levels of a WBS using this format.
Bicycle WBS 1
1.1 Frame Set
1.1.1 Frame 1.1.3 Fork
1.1.2 Handlebar 1.1.4 Seat
1.2 Crank Set
1.3 Wheels
1.3.1 Front Wheel
1.3.2 Rear Wheel
1.4 Braking System
1.5 Shifting System
1.6 Integration
1.6.1 Concept 1.6.3 Assembly
1.6.2 Design 1.6.4 Testing
---------------------------------------------------
Table D-3. Tabular View 2
92312$$CH9 09-22-06 10:39:17

92312$$CH9 09-22-06 10:39:17
D.4 Tree Structure View
One of the most common ways to represent a WBS is the graphic Tree Structure, or
‘‘Organizational Chart’’ structure in which each ‘‘child’’ element is shown as a box
with a line connecting it to the ‘‘parent’’ element of which it is a component. This
representation makes very explicit the way in which the project and the subordinate
components are hierarchically decomposed into smaller and smaller elements. The
most common version of the tree structure places the project at the top level with
successive levels of decomposition below.
Figure D-1. WBS Tree Structure View 1

Alternatively, the orientation of the WBS Tree Structure view may be modified. In
these cases, the project may be placed on the left with lower levels of decomposition
moving to the right. For some purposes a landscape orientation may be useful. Below
are two similar examples of this.
92312$$CH9 09-22-06 10:39:17

92312$$CH9 09-22-06 10:39:17

Or in other cases, a horizontal portrait orientation may be more useful.
Figure D-4. WBS Horizontal Tree Structure View
92312$$CH9 09-22-06 10:39:17

92312$$CH9 09-22-06 10:39:17
An increasingly popular format is the Centralized Tree Structure. This type of format
is produced by software that is used for facilitating development of the WBS through
real time group interactions. Below are two examples of the centralized tree struc-
ture WBS.
Figure D-5. WBS Centralized Tree Structure View 1

Figure D-6. WBS Centralized Tree Structure View 2
92312$$CH9 09-22-06 10:39:17

92312$$CH9 09-22-06 10:39:17
D.5 Enhanced Uses of the WBS
By including information in the WBS in addition to the core WBS Element Name and
WBS Code, the WBS can become the explicit means for integrating other project
management processes with scope.
One example of such enhanced use is the WBS Dictionary which adds a detailed
definition of each WBS Element. The WBS Dictionary may also include key cost control
and resource assignment information, as in the following example. Note that the cost
control number column is left blank, which can be a placeholder for the information
once it is made available when the order is taken.
Cost
WBS Element Control Responsible
Level Code Name Definition Number Organization
1 1 Bicycle WBS All components and subassemblies Customer Sales and
required to specify design, assembly Support
and testing of a custom bicycle.
2 1.1 Frame Set The individual components that Customer Sales and
together constitute the frame once Support
assembled
3 1.1.1 Frame The unit tubular steel structure to Customer Sales and
which other components are attached. Support
Provides basic design and strength.
3 1.1.2 Handlebar Used by rider to steer bicycle. Also Customer Sales and
serves as point of attachment for Support
hand brakes, lights, and other
accessories. Style to be selected by
customer.
3 1.1.3 Fork Attaches wheel(s) to frame. Must be Customer Sales and
selected to match frame. Support
3 1.1.4 Seat Padded saddle attached to frame for Customer Sales and
rider to sit on. Style to be selected Support
by customer.
2 1.2 Crank Set Mechanical linkage for converting Customer Sales and
rider’s pedaling action into rotation Support
of rear wheel to provide propulsion.
Part selection is determined by
customer’s performance
specifications and compatibility with
other mechanical components.
2 1.3 Wheels Interface with ground. Customer may Customer Sales and
select among several options with Support
respect to materials, weight, and
aerodynamic styling.
3 1.3.1 Front Wheel Front wheel is specialized for steering Customer Sales and
through attachment of handlebars. Support
3 1.3.2 Rear Wheel Rear wheel is specialized for Customer Sales and
propulsion. Support
2 1.4 Braking Mechanical system for converting Customer Sales and
System hand pressure into friction on the Support
wheel rim to control speed.

Cost
WBS Element Control Responsible
Level Code Name Definition Number Organization
2 1.5 Shifting Mechanical linkage system for changing Customer Sales and
System position of chain on rear wheel Support
sprocket to adjust leverage and gear
ratio to match riding conditions.
2 1.6 Integration The complete design, assembly and Customer Sales and
testing of the bicycle. Support
3 1.6.1 Concept High level vision of finished bicycle Customer
desired by customer. Usually
communicated to sales to serve as the
basis for the bicycle design.
3 1.6.2 Design The complete set of specifications that Engineering Dept.
defines the finished bicycle. Developed
by engineering department to satisfy
customer’s concept of the bicycle.
3 1.6.3 Assembly The series of sub-assemblies that Manufacturing Shop
together result in creation of the
finished bicycle.
3 1.6.4 Testing The series of inspection and Quality Control
measurements performed to determine Organization
whether the individual components and
finished bicycle meet the design
specifications and customer’s vision of
the finished bicycle appearance and
performance.
4 1.6.4.1 Component The series of inspection and Quality Control
Test measurements performed to determine Organization
whether the individual components
meet the design specifications.
4 1.6.4.2 Product Test The series of inspection and Quality Control
measurements performed to determine Organization
whether the sub-assemblies and
finished bicycle meet the design
specifications.
4 1.6.4.3 Customer The series of inspection and Customer
Test measurements performed by the
customer to determine if the finished
bicycle matches the expectations of the
finished bicycle appearance and
performance.
2 1.7 Project The skills and processes used to Project Management
Management ensure that the bicycle is designed, Organization
built, and delivered in accordance with
quality, cost, and schedule that were
agreed upon by the customer.
Table D-4. WBS Dictionary
There may also be occasions when a WBS may contain less information than is
standard usage. For example, for communication of the WBS to a non-technical audi-
ence such as the customer or senior management, it may enhance the communication
if the code numbers that normally accompany the WBS elements are suppressed. This
is acceptable because it addresses the needs of a specific situation.
92312$$CH9 09-22-06 10:39:17

92312$$CH9 09-22-06 10:39:17
Figure D-7. WBS Dictionary
D.6 WBS Code Numbers
In the examples above, the WBS code uses a numbering scheme consisting of Arabic
numbers separated by periods. This allows for easy and systematic expansion of the
WBS as additional elements are added. In other cases, the WBS code might use a
different alphanumeric system, for example, a combination of Roman numerals, letters
and Arabic numbers. This particular system does not lend itself to systematic expansion
as a purely numeric code. In some cases, the numbering scheme may be defined by
the organization in such away as to permit coordination across projects and enable
program level cost control. The WBS Code serves as a unique identification number.
I Bicycle
I.A Frame Set
I.A.1 Frame
I.A.2 Handlebar
I.A.3 Fork
I.A.4 Seat
I.B Crank Set
I.C Wheel
I.C.1 Front Wheel
I.C.2 Rear Wheel
I.D Braking System
I.E Shifting System
I.F Integration

I.F.1 Concept
I.F.2 Design
I.F.3 Assembly
I.F.4 Testing
I.F.4.1 Component Test
I.F.4.2 Product Test
I.F.4.3 Customer Test
I.G Project Management
The WBS examples in this appendix are illustrative only and are intended to provide guidance to the
reader. No claim of completeness is made. All examples reflect the quality principles expressed in this
Practice Standard. As expressed in the PMBOK威 Guide—Third Edition ‘‘the project management team is
responsible for determining what is appropriate for any given project’’ (Project Management Institute 2004).
92312$$CH9 09-22-06 10:39:17

Appendix E
Oil, Gas, and Petrochemical
(OGP) Work Breakdown Structure
(WBS) Example
This is an example of a Work Breakdown Structure (WBS), from the owner’s point of
view, for the detailed design, fabrication, and installation of an offshore production
platform. As the detailed engineering, fabrication, and installation are distinct phases
of the work, these are placed at Level 2 of the WBS. This fits with the progression of
the work, but also with the contracting strategy; that is, different contractors for
engineering, for fabrication, and so on may be employed or used. The logic of decompo-
sition at the next level varies with the deliverable. Not all branches of the WBS are
decomposed to the same level of detail. The WBS is generic and as such serves as a
WBS template which would be customized for specific projects. Perhaps certain WBS
elements will be decomposed to a greater level of detail as those details for a specific
project become known (for example, 1.3.4.3 All Other Contractor Supplied Equipment).
It is also possible that certain WBS elements will be decomposed by a sub-contractor.
1 WBS for Production Platform Project
1.2 Engineering
1.2.1 General
1.2.1.1 Preliminary Engineering Acceptance
1.2.1.2 Preliminary Engineering Acceptance
1.2.1.3 Design Basis and Specifications
1.2.1.4 Calculations and Engineering Data Books
1.2.1.5 Summary Reports
1.2.1.6 Platform Equipment Manuals
1.2.2 Jacket
1.2.2.1 Structural Engineering and Drafting
1.2.2.1.1 Jacket In-Service Analyses
1.2.2.1.2 Jacket Pre-Service Analyses
1.2.2.1.3 Jacket Design Details
1.2.2.1.4 Jacket Cathodic Protection
92312$CH10 09-08-06 04:45:28

92312$CH10 09-08-06 04:45:28
1.2.2.1.5 Jacket Weights and Material Takeoffs
1.2.2.1.6 Jacket Approved for Construction (AFC) Drawings
1.2.2.1.7 Jacket Detailed Engineering and Design Report
1.2.2.2 Mechanical Engineering & Drafting
1.2.2.2.1 Flood and Vent System
1.2.2.2.2 Grouting System
1.2.3 Piling—Structural Engineering and Drafting
1.2.3.1 Piling In-Service Analyses
1.2.3.2 Piling Pre-Service Analyses
1.2.3.3 Piling Design Details
1.2.3.4 Piling Weights and Material Takeoffs
1.2.3.5 Piling AFC Drawings
1.2.3.6 Piling Detailed Engineering and Design Report
1.2.4 Topsides
1.2.4.1 Structural Engineering and Drafting
1.2.4.1.1 Deck In-Service Analyses
1.2.4.1.2 Deck Pre-Service Analyses
1.2.4.1.3 Deck Design Details
1.2.4.1.4 Deck Weights and Material Takeoffs
1.2.4.1.5 Deck AFC Drawings
1.2.4.1.6 Deck Detailed Engineering and Design Report
1.2.4.2 Mechanical/Process Engineering and Drafting
1.2.4.2.1 Process Simulation/Calculations
1.2.4.2.2 Equipment Design/Sizing
1.2.4.2.3 Pipe Stress Analysis
1.2.4.2.4 Hazard Analysis
1.2.4.2.5 Specifications, Data Sheets, and Request for Quota-
tions
1.2.4.2.6 Vendor Data Reviews
1.2.4.2.7 Weight, Material Takeoffs, Bill of Materials
1.2.4.2.8 AFC Drawings for:
1.2.4.2.8.1 Process Flow Diagrams/Utility Flow
Diagrams
1.2.4.2.8.2 Mechanical Flow Diagrams/Piping and
Instrument Drawings
1.2.4.2.8.3 Equipment Layouts/Arrangements/
Skid Layouts
1.2.4.2.8.4 Piping Supports
1.2.4.2.8.5 Piping General Arrangements, Eleva-
tions, and Isometrics
1.2.4.2.8.6 Other AFC Drawings
1.2.4.2.9 Data Books, Equipment Manuals, Engineering and
Design Report
1.2.4.3 Electrical Engineering & Drafting
1.2.4.3.1 Electrical Engineering and Design
1.2.4.3.2 Electrical Specifications, Data Sheets, and Request
for Quotations
1.2.4.3.3 Electrical Load Study/List
1.2.4.3.5 Weight, Material Takeoffs, Bill of Materials
1.2.4.3.6 AFC Drawings for:

1.2.4.3.6.1 Area Classifications
1.2.4.3.6.2 Electrical Symbol Legend
1.2.4.3.6.3 Electrical One-Line Drawings
1.2.4.3.6.4 Schematics/Schedule/Plans
1.2.4.3.6.5 Buildings and Equipment Layouts
1.2.4.3.6.6 Electrical Arrangement and Cable Tray
Routing
1.2.4.3.6.7 Electrical Installation Details
1.2.4.3.6.8 Other AFC Drawings
1.2.4.3.7 Data Books, Equipment Manuals, Engineering and
Design Report
1.2.4.4 Instrument Engineering & Drafting
1.2.4.4.1 Instrument Engineering & Design
1.2.4.4.2 Fire & Safety Engineering & Design
1.2.4.4.3 Relief Systems Sizing Calculations
1.2.4.4.4 Instrument Specification, Data Sheets, and Request
for Quotations
1.2.4.4.5 Instrument Index
1.2.4.5 Weight, Material Takeoffs, Bill of Materials
1.2.4.6 AFC Drawings for:
1.2.4.6.1 SAFE Charts/PSFDs
1.2.4.6.2 Control Panels
1.2.4.6.3 PLC System
1.2.4.6.4 Tubing Tray Routing
1.2.4.6.5 Loop Diagrams
1.2.4.6.6 Instrument Installation Details
1.2.4.6.7 Fire and Safety
1.2.4.6.8 Pressure Relief Systems
1.2.4.6.9 Other AFC Drawings
1.2.4.7 Data Books, Equipment Manuals, Engineering and Design
Reports
1.3 Procurement
1.3.1 General
1.3.1.1 Procurement Procedures
1.3.1.2 Expediting and Inspection Procedures
1.3.2 Jacket
1.3.2.1 Owner Furnished Equipment (OFE)
1.3.2.2 Contractor Furnished Reimbursable Equipment (CFRE)
1.3.2.3 All Other Contractor Supplied Equipment
1.3.2.4 Bulk Materials—Contractor Supplied
1.3.2.4.1 Structural
1.3.2.4.2 Anodes
1.3.3 Piling
1.3.4 Topsides
1.3.4.1 Owner Furnished Equipment (OFE)
1.3.4.1.1 Rotating Equipment
1.3.4.1.2 Pressure Vessels
1.3.4.1.3 Electrical Generation
92312$CH10 09-08-06 04:45:28

92312$CH10 09-08-06 04:45:28
1.3.4.2 Contractor Furnished Reimbursable Equipment (CFRE)
1.3.4.2.1 Rotating Equipment
1.3.4.2.2 Pressure Vessels
1.3.4.2.3 Other CFRE
1.3.4.3 All Other Contractor Supplied Equipment
1.3.4.4.2 Piping, Valves, and Fittings
1.3.4.4.3 Electrical
1.3.4.4.4 Instrument
1.4 Fabrication
1.4.1 General
1.4.1.1 Safety Manual and Plan
1.4.1.2 Yard and Work-Force Mobilization
1.4.1.3 Qualification of Welding Procedures and Welders
1.4.1.3.2 Piping
1.4.1.4 Shop Drawings
1.4.1.4.2 Piping Isometrics
1.4.1.4.3 Piping Spools
1.4.1.5 Receipt of Materials
1.4.1.6 QA/QC, NDT, and Dimensional Control
1.4.1.7 Weight Control Reports
1.4.1.8 As-Built Drawings and Certification Dossier
1.4.2 Jacket
1.4.2.1 Frames
1.4.2.1.1 Frame 1
1.4.2.1.2 Frame 2
1.4.2.1.3 Frame A
1.4.2.1.4 Frame B
1.4.2.2 Horizontal Levels
1.4.2.2.1 Level 1
1.4.2.2.2 Level 2
1.4.2.2.3 Level 3
1.4.2.2.4 Level 4
1.4.2.3 Appurtenances
1.4.2.3.1 Disposal Pile
1.4.2.3.2 Caissons
1.4.2.3.3 Risers
1.4.2.3.4 Boat Landing
1.4.2.3.5 Corrosion Protection
1.4.2.3.6 Stairs, Walkways, and Landings
1.4.2.4 Installation Aids
1.4.2.5 Loadout and Seafasten
1.4.3 Piling
1.4.3.1 Pile A1
1.4.3.2 Pile A2
1.4.3.3 Pile B1
1.4.3.4 Pile B2

1.4.4 Topsides
1.4.4.1 Main Deck
1.4.4.1.1 Plate Girders
1.4.4.1.2 Deck Panels
1.4.4.1.3 Tertiary Steel
1.4.4.2 Cellar Deck
1.4.4.2.1 Plate Girders
1.4.4.2.2 Deck Panels
1.4.4.2.3 Tertiary Steel
1.4.4.3 Sub-Cellar Deck
1.4.4.4 Legs
1.4.4.5 Bracing
1.4.4.6 Equipment Installation
1.4.4.7 Interconnect Piping
1.4.4.8 Electrical
1.4.4.9 Instrumentation
1.4.4.10 Precommissioning
1.4.4.11 Appurtenances
1.4.4.11.1 Flare Boom
1.4.4.11.2 Stairs, Walkways, & Landings
1.4.4.11.3 Installation Aids
1.5 Transportation
1.5.1 General
1.5.1.2 Seafastening Drawings
1.5.1.3 Marine Warranty Surveyor Review and Approval
1.5.2 Jacket
1.5.3 Piling
1.5.4 Topsides
1.6 Installation, Hookup, and Commissioning
1.6.1 General
1.6.1.2 Installation Procedures and Drawings
1.6.1.3 Qualification of Welding Procedures and Welders
1.6.1.3.2 Piping
1.6.1.4 As-Installed Drawings
1.6.1.5 Mobilization
1.6.1.6 Demobilization
1.6.2 Jacket
1.6.3 Piling
1.6.4 Topsides
1.6.4.1 Hookup
1.6.4.2 Commissioning
1.6.4.3 Startup
This WBS example is illustrative only and is intended to provide guidance to the reader. No claim of
completeness is made—for any specific project, the example may be complete or incomplete. All examples
reflect the quality principles expressed in this Practice Standard. As expressed in the PMBOK威 Guide—
Third Edition ‘‘the project management team is responsible for determining what is appropriate for any
given project’’ (Project Management Institute 2004).
92312$CH10 09-08-06 04:45:28

Appendix F
Environmental Management Work
Breakdown Structure (WBS)
Example
This Work Breakdown Structure (WBS) is organized according to the project lifecycle
at Level 2 while specific deliverables within each stage of the lifecycle are included at
Level 3. This is a high level WBS template which can be customized at lower levels to
apply to a variety of specific projects.
1 WBS for Environmental Management Project to Conduct a Bio-Venting Test for
the Remediation of Hydrocarbon Impacted Soils
1.1 System Design
1.1.1 Initial Design
1.1.2 Client Meeting
1.1.3 Draft Design
1.1.4 Client and Regulatory Agency Meeting
1.1.5 Final Design
1.2 System Installation
1.2.1 Facility Planning Meeting
1.2.2 Well Installation
1.2.3 Electrical Power Drop Installation
1.2.4 Blower and Piping Installation
1.3 Soil Permeability Test
1.3.1 System Operation Check
1.3.2 Soil Permeability Test
1.3.3 Test Report
1.4 Initial In Situ Respiration Test
1.4.1 In Situ Respiration Test
1.4.2 Test Report
1.5 Long-Term Bio-Venting Test
1.5.1 Ambient Air Monitoring
1.5.2 Operation, Maintenance, and Monitoring
1.5.3 Three-Month In Situ Respiration Test
1.5.4 Test Report
92312$CH11 09-08-06 04:46:19

92312$CH11 09-08-06 04:46:19
1.5.5 Six-month In Situ Respiration Test
1.5.6 Test Report
1.6 Confirmation Sampling
1.6.1 Soil Boring and Sampling
1.6.2 Data Validation
1.7 Report Preparation
1.7.1 Pre-Draft Report
1.7.2 Client Meeting
1.7.3 Draft Report
1.7.4 Client and Regulatory Agency Meeting
1.7.5 Final Report
A landscape tree structure view of this WBS is depicted in Figure F1.. This view of
the WBS shows the top of the tree at the left, with lower levels of decomposition
moving to the right. Like the outline view above, the project life cycle elements are
at level 2 while specific deliverables within each stage of the lifecycle are included at
level 3.
Figure F-1. Horizontal Tree Structure

Appendix G
Process Improvement Work
Example
This Work Breakdown Structure (WBS) example is used with permission of the Califor-
nia Department of Transportation. This is an example of a WBS for a process improve-
ment project. It is divided into three phases:
1. Research to determine the best solution to the problem. This research includes the
recommendation of a solution, or solutions, to the sponsor.
2. Implementation of the approved solution(s). If there were more than one approved
solution, then the ‘‘Phase 2’’ WBS would be repeated for each solution.
3. Evaluation to determine if the solution works. This leads back to further research
and continuous process improvement.
Note that not all branches of the WBS are decomposed to the same level of detail.
Also some WBS elements, e.g., 1.1.2 and 1.2, are modular templates which are repeated
as often as needed.
1 WBS for Process Improvement Project
1.1 Phase 1: Research and recommendations
1.1.1 Phase 1 Charter
1.1.2 Project Management Plans for Phase 1
1.1.3 Research
1.1.3.1 Documentation of the ‘‘State of the Art’’
1.1.3.1.1 Document Search
1.1.3.1.2 Consultation with Experts
1.1.3.1.3 Benchmarking
1.1.3.1.4 Product and Software Review
1.1.3.2 Documentation of the Current State in the Subject Organization
1.1.3.2.1 Interviews
1.1.3.2.2 Surveys
92312$CH12 09-08-06 04:50:55

92312$CH12 09-08-06 04:50:55
1.1.3.2.3 Statistical Analysis
1.1.3.2.4 Flow Charts of Current Processes
1.1.4 Identification of Improvement Needs
1.1.4.1 Determination of Desired State (Vision Statement)
1.1.4.2 Gap Analysis
1.1.4.3 Most Likely Solutions
1.1.4.3.1 Brainstorming
1.1.4.3.2 Statistical Analysis
1.1.4.3.3 Flow Charts of Desired Processes
1.1.5 Recommendations
1.1.5.1 Recommendation 1
1.1.5.1.1 Draft Charter
1.1.5.1.2 Estimated Cost
1.1.5.3 Recommendation n
1.2 Phase 2: Implementation of Approved Recommendation x
(This portion of the WBS is repeated for each approved recommendation)
1.2.1 Recommendation x Charter (approved and amended version of the draft
from 1.1.5)
1.2.2 Project Management Plans for Phase 2 (seven plans, as for Phase 1)
1.2.3 Process Documentation
1.2.3.1 Draft process (policy, handbook, manual chapter, etc.)
1.2.3.2 Review
1.2.3.3 Revision (1.2.3.2 and 1.2.3.3 are iterative—repeat until there is
consensus)
1.2.3.4 Publication
1.2.3.4.1 Hardcopy
1.2.3.4.2 Internet or Intranet
1.2.3.4.3 Other
1.2.4 Tools (software, etc.)
1.2.4.1 Design
1.2.4.2 Build
1.2.4.3 Test
1.2.4.4 Revision (1.2.4.3 and 1.2.4.4 are iterative—repeat until the prod-
uct meets its goals)
1.2.4.5 Implementation
1.2.5 Training
1.2.5.1 Instructors
1.2.5.1.1 Hiring
1.2.5.1.2 Training (‘‘Train the Trainers’’)
1.2.5.2 Development
1.2.5.2.1 Draft Training Materials
1.2.5.2.2 Review and Pilot
1.2.5.2.3 Revision (1.2.5.2.2 and 1.2.5.2.3 are iterative—repeat
until the class meets its goals)
1.2.5.3 Delivery

1.3 Phase 3: Evaluation
1.3.2 Documentation of the New State in the Subject Organization
1.3.2.1 Interviews
1.3.2.2 Surveys
1.3.2.3 Statistical Analysis
1.3.2.4 Flow Charts of New Processes
1.3.3 Identification of Deficiencies
1.3.3.1 Flow Charts of Desired Processes (from 1.4.3.3)
1.3.3.2 Gap Analysis
1.3.4 Recommendations for New Projects
1.3.4.3 Recommendation n
92312$CH12 09-08-06 04:50:55

92312$CH12 09-08-06 04:50:55
The following table is another representation of Phase 1 of this same WBS . . . an
outline view developed with a spreadsheet application. Though the entire WBS can
be represented in this manner, only Phase 1 of this WBS example is shown as an
illustration.
WBS Level WBS Code WBS Element
1 1 WBS for Process Improvement Project
2 1.1 Phase 1: Research and Recommendations
3 1.1.1 Phase 1 Charter
3 1.1.2 Project Management Plans for Phase 1
3 1.1.3 Research
4 1.1.3.1 Documentation of the ‘‘State of the Art’’
5 1.1.3.1.1 Document Search
5 1.1.3.1.2 Consultation with Experts
5 1.1.3.1.3 Benchmarking
5 1.1.3.1.4 Product and Software Review
4 1.1.3.2 Documentation of the Current State in the Subject Organization
5 1.1.3.2.1 Interviews
5 1.1.3.2.2 Surveys
5 1.1.3.2.3 Statistical Analysis
5 1.1.3.2.4 Flow Charts of Current Processes
3 1.1.4 Identification of Improvement Needs
4 1.1.4.1 Determination of Desired State (Vision Statement)
4 1.1.4.2 Gap Analysis
4 1.1.4.3 Most Likely Solutions
5 1.1.4.3.1 Brainstorming
5 1.1.4.3.2 Statistical Analysis
5 1.1.4.3.3 Flow Charts of Desired Processes
3 1.1.5 Recommendations
4 1.1.5.1 Recommendation 1
5 1.1.5.1.1 Draft Charter
5 1.1.5.1.2 Estimated Cost
2 1.2 Phase 2: Implementation of Approved Recommendation
Table G-1. Process Improvement WBS Example

Appendix H
Pharmaceutical Work Breakdown
Pharmaceutical Project WBS
The following represents an example of a WBS for a pharmaceutical development
project. It is not intended to represent the only feasible WBS for this type of project.
There are numerous variations and approaches that a project manager can take to
develop the WBS for the project.
In this example, a WBS is presented for a new compound. A development program
containing more than one compound would consist of a similar WBS structure for
each compound. Some Level 2 WBS elements describe deliverables that fall within
the area of expertise of specific technical specialties and occur at different points over
the course of the product development lifecycle. These are structured to reflect the
organizations making up the enterprise, such as Marketing, Regulatory Affairs, Pharma-
ceutical Development, etc. Other Level 2 elements are organized according to the
product development lifecycle itself, thus: Phase 1 Clinical Program, Phase 2 Clinical
Program, etc., because this organization reflects the way that the business manages
the overall development program. The WBS is not intended to illustrate the sequence
by which the deliverables will be created. When the Network Diagram and Schedule
for this project are created they would reflect the sequence of the activities that produce
the deliverables within both the functionally organized elements and those organized
by product lifecycle.
Note that this WBS describes a generic product, not a project to develop a specific
compound. As such, it is a ‘‘WBS Standard’’ that can be customized using specific
terms to describe different development projects. Some elements are modular and
may be repeated as often as necessary in a given project. For example, the elements
listed as components of 1.7.3 would be repeated for each multiple dose safety clinical
trial to be conducted. Depending on the particular project, the project manager would
include some but not all of the possible elements included in the standard WBS. For
example, if the objective of the project were to develop a line extension of an existing
product, it is likely that the project manager would choose not to include any aspect
of lead identification in the WBS. In other cases, the project manager might want to
illustrate geographic components in the WBS that would necessitate a modification
to that depicted here. This might be the case if some clinical trials were to be performed
outside the US. Similarly, if some of deliverables are to be developed by a different
92312$CH13 09-08-06 04:55:26

92312$CH13 09-08-06 04:55:26
organization as part of a collaborative program, the project manager might organize
the WBS to show the deliverables for each organization in separate branches.
The Level 2 WBS elements are not all decomposed to the same level of detail. In
part this reflects the need to provide more detail for some but not others. In practice,
the level of detail would also reflect the amount of information available for certain
deliverables. Thus, the specific clinical trials to be conducted in Phase 3 are not usually
known until after Phase 2 has been completed. Thus, early in development, these
might be described with a single high-level WBS element called ‘‘Phase 3 Clinical Trial
Program,’’ while the Phase 1 trials would be described in much more detail. It is
recommended that the project manager develop the WBS to a level of detail that is
appropriate to enable management of the specific project.
1 WBS for New Compound Development Project
1.1 Project Initiation
1.1.1 Decision to Develop Business Case
1.1.2 Business Case
1.1.3 Project Initiation Decision
1.2 Marketing/Sales Support
1.2.1 Market Research Program
1.2.2 Branding Program
1.2.3 Pricing Program
1.2.4 Sales Development Program
1.2.5 Other Marketing/Sales Support
1.3 Regulatory Support
1.3.1 IND Submission
1.3.1.1 Pre-IND Meeting
1.3.1.2 IND Preparation
1.3.1.2.1 Preclinical Package
1.3.1.2.2 Clinical Package
1.3.1.2.3 Clinical Pharmacology Package
1.3.1.2.4 CM&C Package
1.3.1.3 IND Submission
1.3.2 End of Phase 2 Meeting
1.3.2.1 Pre-Meeting Package
1.3.2.2 End of Phase 2 Meeting
1.3.3 BLA/NDA Submission
1.3.3.1 Pre-BLA/NDA Meeting
1.3.3.2 BLA/NDA Preparation
1.3.3.2.1 Preclinical Package
1.3.3.2.2 Clinical Package
1.3.3.2.3 Clinical Pharmacology Package
1.3.3.2.4 CM&C Package
1.3.3.3 BLA/NDA Submission
1.3.3.4 Advisory Committee Meeting
1.3.3.5 FDA review support
1.3.3.6 Pre-Approval Inspection
1.3.3.7 Approval
1.3.4 Post-approval Regulatory Support Program
1.3.4.1 Annual Reports
1.3.4.2 Adverse Event Reporting
1.3.4.3 Post-market Commitment Administration

1.4 Lead Identification Program
1.4.1 Hypothesis Generation
1.4.2 Assay Screening
1.4.3 Lead Optimization
1.4.4 Other Discovery Support
1.5 Clinical Pharmacology Support
1.5.1 Pharmacokinetic Study(ies)
1.5.2 Drug Interaction Study(ies)
1.5.3 Renal Effect Study(ies)
1.5.4 Hepatic Effect Study(ies)
1.5.5 Bioequivalency Study(ies)
1.5.6 Other Clinical Pharmacology Study(ies)
1.6 Preclinical Program
1.6.1 Tox/ADME Support
1.6.1.1 Non-GLP Animal Studies
1.6.1.2 Bioanalytical Assay Development
1.6.1.3 ADME Evaluations
1.6.1.4 Acute Toxicological Studies
1.6.1.5 Sub-Chronic Toxicological Studies
1.6.1.6 Chronic Toxicological Studies
1.6.1.7 Other Tox/ADME Support
1.6.2 Clinical Pharmacology Support
1.6.2.1 Pharmacokinetic Study(ies)
1.6.2.2 Drug Interaction Study(ies)
1.6.2.3 Renal Effect Study(ies)
1.6.2.4 Hepatic Effect Study(ies)
1.6.2.5 Bioequivalency Study(ies)
1.6.2.6 Other Clinical Pharmacology Study(ies)
1.7 Phase I Clinical Study Program
1.7.1 Pharmacokinetic/Pharmacodynamic Study(ies)
1.7.2 Dose Ranging Study(ies)
1.7.3 Multiple Dose Safety Study(ies)
1.7.3.1 Pre-Enrollment Activities
1.7.3.2 Enrollment
1.7.3.3 Treatment
1.7.3.4 Follow-up
1.7.3.5 Data Management
1.7.3.6 Data analysis
1.7.3.7 Study Report1.10
1.8 Phase II Clinical Study Program
1.8.1 Multiple Dose Efficacy Study(ies)
1.8.2 Other Clinical Study(ies)
1.9 Phase III Clinical Study Program
1.9.1 Pivotal Registration Study(ies)
1.9.2 Other Clinical Study(ies)
1.10 Submission/Launch Phase
1.10.1 Pre-Launch preparation
1.10.2 Launch
1.10.3 Post-Launch Support
1.11 Phase IV/Commercialization Clinical Study Program
1.11.1 Investigator-Sponsored Studies
92312$CH13 09-08-06 04:55:26

92312$CH13 09-08-06 04:55:26
1.11.2 Registry Studies
1.12 Legal Support
1.12.1 Publications
1.12.2 Patents/Intellectual Property
1.12.3 Trademarks
1.12.4 Other Legal Support
1.13 Program Management Support
1.13.1 Program-Level Project Management
1.13.2 Preclinical Project Management
1.13.3 Clinical Project Management
1.13.4 CM&C Project Management
1.13.5 Other Project Management Support

Appendix I
Process Plant Construction Work
Example
Process Plant Construction Project WBS
This is an example of an engineering-oriented WBS, rather than a contractor-oriented
WBS, as the orientation is on the design of systems rather than on the startup and
commissioning of systems. Communication between the engineering team and the
construction/commissioning team needs to be very good to minimize problems during
construction. In practice there can be problems when engineers design based on
‘‘Systems,’’ while the Crafts/Trades (Contractors) do their work by location and
sequence.
It should be noted, however, that whether the WBS has a systems focus, a structure
focus, or deliverable focus, the sequence of work is not the purpose of the WBS. The
objective of the WBS is to ensure that the work required to complete the desired
outcome and meet the project objectives has been captured completely and in enough
detail to identify resources, assign responsibility, and set sequence.
Note that all branches of the WBS are not decomposed to the same level of detail.
This could be due to a variety of factors. For example, a subcontractor might have
responsibility for detailing one WBS element, or another WBS element might be
detailed at a later point in the planning process.
1 WBS for Process Plant Construction Project
1.1 Plant System Design
1.1.1 Business requirements
1.1.1.1 System Engineering
1.1.1.2 Site Development
1.1.1.3 Civil Structures
1.1.1.4 Thermal Systems
1.1.1.5 Flow Systems
1.1.1.6 Storage Systems
1.1.1.7 Electrical Systems
1.1.1.8 Mechanical Systems
92312$CH14 09-08-06 04:56:18

92312$CH14 09-08-06 04:56:18
1.1.1.9 Environmental Systems
1.1.1.10 Instrumentation and Control Systems
1.1.1.11 Auxiliary Systems
1.1.1.12 Security Systems
1.1.2 Process Models
1.1.2.1 System Engineering
1.1.2.2 Site Development
1.1.2.3 Civil Structures
1.1.2.4 Thermal Systems
1.1.2.5 Flow Systems
1.1.2.6 Storage Systems
1.1.2.7 Electrical Systems
1.1.2.8 Mechanical Systems
1.1.2.9 Environmental Systems
1.1.2.10 Instrumentation and Control Systems
1.1.2.11 Auxiliary Systems
1.1.2.12 Safety systems
1.2 Construction
1.2.1 Site Development
1.2.2 Civil Structures
1.2.3 Thermal Systems
1.2.4 Flow Systems
1.2.5 Storage Systems
1.2.6 Electrical Systems
1.2.7 Mechanical Systems
1.2.8 Instrument and Control Systems
1.2.9 Environmental Systems
1.2.10 Temporary Structure
1.2.11 Auxiliary Systems
1.2.12 Safety Systems
1.3 Legal and Regulatory
1.3.1 Licensing (Non-Government)/Permitting (government)
1.3.1.1 Licensing (Non-Government)
1.3.1.1.1 Roofing, Gutters, Insulation
1.3.1.1.2 Electric
1.3.1.1.3 Plumbing
1.3.1.1.4 Commercial Signs
1.3.1.1.5 Elevators
1.3.1.1.6 Steam/Hot Water Boilers
1.3.1.1.7 Air Conditioning
1.3.1.1.8 Commercial Fire Suppression Systems
1.3.1.1.9 Forced Air Furnaces/Ventilation
1.3.1.1.10 Water Heaters and Gas Lines
1.3.1.2 Permitting (Government)
1.3.1.2.1 Application
1.3.1.2.2 Acceptance Criteria
1.3.1.2.3 Issuance of License
1.3.2 Environmental Impact
1.3.2.1 Preliminary Assessment
1.3.2.2 Impact Review
1.3.2.3 Magnitude Assessment

1.3.2.4 Mitigation Plan
1.3.3 Labor Agreements
1.3.3.1 Agreement
1.3.3.2 Collective Bargaining
1.3.3.3 Agreement Finalization
1.3.4 Land Acquisition
1.3.4.1 Available Property
1.3.4.2 Local Government Zoning Rights/Restrictions
1.3.4.3 Price Comparisons
1.3.4.4 Professional Survey
1.3.4.5 Financing
1.3.5 Other Legal/Regulatory Requirements
1.4 Testing
1.4.1 System Test
1.4.1.1 System Test Plans and Procedures
1.4.1.2 System Testing
1.4.2 Acceptance Test
1.4.2.1 Acceptance Test Plans
1.4.2.2 Acceptance Testing
1.4.2.3 Formal Acceptance
1.5 Startup
Note: PMI Project Management Standards Open Working Session volunteers at
PMI’s ’99 Seminars & Symposium originally created this WBS example. It has been
subsequently updated as part of the development of this release of the Practice
Standard.
92312$CH14 09-08-06 04:56:18

Appendix J
Service Industry Outsourcing
Work Breakdown Structure
(WBS) Example
Service Industry Outsourcing Project WBS
The unique aspect of this WBS is its inclusion of an RFP (Request for Proposal) process.
This WBS is generic and could be made more specific for use in a particular project.
It therefore serves as a WBS template. Not all branches of the WBS are decomposed
to the same level of detail. For example Project Management (1.7) is not decomposed
at all.
1 WBS for Outsourcing Project
1.1. Needs Analysis
1.1.1 Needs Analysis
1.1.1.1 Feasibility Study
1.1.1.2 Historical Information
1.1.2 Definition and Baseline Requirements
1.1.2.1 Project Approach Strategy
1.1.2.2 High-Level Project Plan
1.1.2.3 Cost Estimates
1.1.2.4 Scope Statement
1.1.3 Specifications
1.1.4 High-Level Statement of Work
1.2 Market Analysis
1.2.1 Internal Capability Plus Cost
1.2.2 Qualified Vendors
1.2.3 RFI (Information)
1.2.4 RFI Submissions
1.2.5 Decision Analysis (Includes Make/Buy)
1.3 Request for Proposal (RFP)
1.3.1 RFP Development
1.3.1.1 Solution Criteria
1.3.1.2 Background and General Scope of Work
1.3.1.3 Priorities/Requirements
1.3.1.4 Type of Solution Sought
1.3.1.5 Maintenance and Support; Warranty; Training
92312$CH15 09-08-06 04:58:03

92312$CH15 09-08-06 04:58:03
1.3.2 Acceptance Requirements
1.3.3 Schedule
1.3.4 Budget
1.3.5 RFP Package
1.3.5.1 Instructions for Preparation/Delivery of Submissions
1.3.5.2 Evaluation Criteria
1.3.5.3 Site Inspection Requirements
1.3.5.4 Withdrawal or Modifications of Proposals
1.3.5.5 Responsibility for Proposal Costs
1.4 Solicitation
1.4.1 RFP Issuance
1.4.2 Bids
1.4.3 Bidder Conference
1.4.4 RFP submissions/Receipt
1.4.5 Response Evaluation
1.4.6 Vendor Criteria Matrix
1.4.7 Scorecard
1.4.8 Vendor Qualification
1.4.8.1 Prior Experience
1.4.8.2 Available Vendor Resources/Available Time
1.4.8.3 Quality references
1.4.9 Vendor Award
1.4.9.1 Management Approvals
1.4.9.2 Legal Review and Approvals
1.4.10 Letter of Intent (LOI)
1.5 Contract
1.5.1 Master Agreement
1.5.1.1 Contract Negotiation
1.5.1.2 Finalized Terms and Conditions (Use Boiler Plate)
1.5.1.3 Finalized Scope/Schedule/Cost
1.5.2 Contract Orders/Task Orders/CSOWs
1.5.2.1 Specific Deliverables
1.5.2.2 Identified Resources
1.5.2.3 Defined SLAs
1.5.2.4 Defined Acceptance Criteria
1.5.2.5 Defined Performance Measures
1.5.2.6 Issued PO/Task Order
1.5.3 Executed Agreement/Signed Contract
1.6 Task Order/Contract Order SOW
subsequently been updated as part of the development of this release of the Prac-
tice Standard.

Appendix K
Web Design Work Breakdown
Web Design Project WBS
This example is of a WBS to design, build and deploy a commercial Internet Web site
that sells the organization’s own products within one country. The high-level phases
of the development lifecycle are placed at Level 1 of the WBS. Major work within that
phase is further elaborated within each area. As with all WBS examples, different
branches of a WBS can be decomposed to different levels of detail. This WBS is generic
and as such serves as a WBS template which would be customized for specific project
instance. Additionally, both outline and tree-structure views of this WBS are provided
for comparison.
1 WBS for Web Design Project
1.1 Planning
1.1.1 Product Definition
1.1.2 Stakeholder Approval
1.2 Definition
1.2.1 Requirements Development
1.2.1.1 Business Requirements Development
1.2.1.2 System Requirements Development
1.2.2 Conceptual Design Development
1.2.2.1 Conceptual Data Design
1.2.2.2 Conceptual Process Design
1.2.3 Architectural Design Development
1.2.3.1 Web Design Methods Evaluation
1.2.3.2 Web Design Method Selection
1.2.4 Bill of Materials (BoM) Creation
1.2.5 Resource Procurement
1.2.5.1 Human Resources Procurement
1.2.5.2 Hardware Procurement
1.2.5.3 Software Procurement
1.2.5.4 Telecommunications Procurement
1.3 Construction
1.3.1 Detailed Design Development
92312$CH16 09-08-06 05:49:24

92312$CH16 09-08-06 05:49:24
1.3.1.1 Data Design
1.3.1.2 Business Logic Design
1.3.1.3 User Interface Design
1.3.1.4 Internal Design Standards Consultation
1.3.1.5 Industry Design Standards Consultation
1.3.2 High-Level Test Plan Development
1.3.3 System Components—Code, Unit Test
1.3.3.1 Database Components
1.3.3.2 Code/Logic Components
1.3.3.3 Web GUI Interface Components
1.3.4 System Installation (Configure)
1.4 Testing
1.4.1 Testing Execution
1.4.1.1 System Test
1.4.1.2 User Acceptance Test
1.4.1.3 Performance Test
1.4.2 Analyze Defects/Correct
1.4.3 Production Readiness Verification
1.5 Deployment
1.5.1 Transition
1.5.1.1 Support Personnel Training
1.5.1.2 Support Procedures Documentation
1.5.1.3 Software
1.5.1.4 Hardware
1.5.2 Legacy System Decommissioning
Tree Structure View
One of the most common ways to represent a WBS is the graphic Tree Structure, or
Organizational Chart structure in which each ‘‘child’’ element is shown as a box
with a line connecting it to the ‘‘parent’’ element of which it is a component. This
representation makes very explicit the way in which the project and the subordinate
components are hierarchically decomposed into smaller and smaller elements. The
example illustrates horizontal distribution for WBS levels. The phases are placed verti-
cally in top down sequence. This approach works well for WBS with variable decompo-
sition of each phase. Two techniques are illustrated in Figures K1 and K2 to show how
paper position (landscape or vertical) can change the WBS. In the horizontal landscape
the boxes for Level 3 had been omitted for additional clarity to the graph.

Figure K-1. Horizontal Portrait View
92312$CH16 09-08-06 05:49:24

92312$CH16 09-14-06 11:21:09
Figure
K-2.
Horizontal
Landscape
View
tice Standard.

Appendix L
Telecom WBS Example
The WBS example below is displayed in a standard outline format. At level 2, this WBS
is organized according to the project lifecycle, from creation of the concept through
product development, customer acceptance and ongoing support and maintenance.
Within each level 2 WBS Element are included lower level deliverables that are specific
to that stage and include, among others, reviews and decisions, analyses, tangible
deliverables, and services. The Project Management WBS Element is not decomposed
to the same level of detail as the others. Both an outline and vertical tree-structure
view are provided for comparison.
1 WBS for Telecom Project
1.1 Concept/Feasibility
1.1.1 Concept
1.1.2 Marketing Analysis
1.1.3 Market Plan
1.1.4 Technical Analysis
1.1.5 Product Scope Definition
1.1.6 Prototype
1.2 Requirements
1.2.1 End-User Requirements
1.2.2 Application Requirements
1.2.3 Infrastructure (Systems) Requirements
1.2.4 Operations/Maintenance Requirements
1.2.5 Service Requirements
1.3 Go/No Go Decision
1.3.1 Prototype Review
1.3.2 Financial Review
1.3.3 Schedule Review
1.3.4 Technical Capabilities Review
1.3.5 Financial Commitment Review
1.3.6 Go/No-Go Decision
1.4 Development
1.4.1 End-User Systems
1.4.2 Application
92312$CH17 09-08-06 05:53:34

92312$CH17 09-08-06 05:53:34
1.4.3 Infrastructure Systems
1.4.4 Network
1.4.5 Operations/Maintenance Systems
1.4.6 Service Plan
1.5 Testing
1.5.1 Test Plans
1.5.2 Tests
1.5.3 Results
1.5.4 Corrective Actions
1.5.5 Retests
1.5.6 Retest Results
1.6 Deployment
1.6.1 Trial in a Non-Penalty Environment
1.6.2 First Action Site
1.6.3 Deployment
1.7 Life-cycle Support
1.7.1 Customer Training & Education
1.7.2 Turnover to Customer
1.7.3 Customer Acceptance
1.7.4 Support & Maintenance
The information shown in the above outline format can be displayed in many
other views. For example, a top-down tree structure is frequently used. This view is
depicted below.
Figure L-1. Top-Down Tree Structure

tice Standard.
92312$CH17 09-08-06 05:53:34

Appendix M
Refinery TurnAround WBS
Example
Refinery TurnAround Project WBS
This is an example of a WBS for the TurnAround (T/A) of equipment for a refinery.
Work orders are rolled up under the Equipment ID 1.2.1.3 (WBS Level 4). In this
example, the Level 3 deliverable (Coolant) is decomposed to the work level in alignment
with how the work will be performed. Not all branches of the WBS are decomposed
to the same level of detail. This WBS is generic and as such serves as a WBS template
which would be customized for specific projects. Certain WBS elements will be decom-
posed to a greater level of detail as those details for a specific project become known.
This example is shown in two formats, as an indented tabular outline and as a
graphic tree structure. Any format is acceptable as long as it is consistent with the
Quality principles described in this Standard.
1 WBS for Refinery Turn Around Project
1.1 Pre-Turn Around
1.2 Shutdown
1.2.1 Coolant
1.2.1.1 Main Coolant System(s) Shut Down
1.2.1.2 Radiator CDWEST02
1.2.1.2.1 Work Order #1
1.2.1.2.2 Work Order #2
1.2.1.2.3 Work Order #3
1.2.1.3 Radiator CDWEST03
1.2.1.4 Auxiliary Coolant System(s) Shut Down
1.2.2 Hydraulic
1.2.3 Electrical
1.2.3.1 Transformer ELECTNWDC05
1.2.3.1.1 Work Order #1
1.2.3.1.2 Work Order #2
1.2.3.1.3 Work Order #3
1.2.3.2 Transformer ELECTNWDC07
92312$CH18 09-08-06 05:54:44

92312$CH18 09-08-06 05:54:44
1.3 Main Turn Around
1.4 Commissioning
1.5 Post-Turn Around
1.6 Engineering

Appendix N
Government Design-Bid-Build
WBS Example
Government Design-Bid-Build Project WBS
This is an example of a WBS for a Government Design-Bid-Build Construction project,
depicted from the government’s point of view.
This is a very high level WBS and would be decomposed to a greater level of detail
in specific cases. Because this is a Design-Bid-Build Project, each phase is treated
almost as a separate project because each may be planned and executed by a different
organization. For this reason it makes sense to include certain service deliverable WBS
elements separately within each phase, e.g., Project Management. These are modular
WBS Elements.
1 WBS for Government-sponsored Design-Bid-Build Project
1.1 Phase 1: Prospectus
1.1.1 Project Management Plans for Phase 1
1.1.1.1 Scope Management Plan
1.1.1.2 Cost and Schedule Management Plan
1.1.1.3 Quality Management Plan
1.1.1.4 Human Resources Management Plan
1.1.1.5 Communication Management Plan
1.1.1.6 Risk Management Plan
1.1.1.7 Procurement Management Plan
1.1.2 Description of Customer Needs
1.1.3 Preliminary Plans of Alternatives
1.1.4 Estimates for Alternatives
1.1.5 Cost/Benefit Analysis
1.1.6 Report
1.2 Phase 2: Selected Alternative (may be combined with Phase 1, depending on
the requirements set by the legislative branch)
1.2.2 Environmental Studies
1.2.2.1 Biological
1.2.2.2 Archaeological
1.2.2.3 Air Quality
92312$CH19 09-08-06 05:55:42

92312$CH19 09-08-06 05:55:42
1.2.2.4 Water Quality
1.2.2.5 Social and Economic
1.2.3 More Detailed Plans of Alternatives
1.2.4 Estimates for Alternatives
1.2.5 Draft Report
1.2.6 Final Report
1.3 Phase 3: Real Property
1.3.2 Appraisal
1.3.3 Acquisition
1.3.4 Relocation of Occupants
1.3.5 Demolition
1.3.6 Relocation of Utilities
1.3.7 Hazardous Waste Removal
1.3.8 Environmental Mitigation
1.4 Phase 4: Contract Award Documents
1.4.2 Detailed Plans of Selected Alternative
1.4.2.1 Civil Plans
1.4.2.2 Water Supply and Removal Plans
1.4.2.3 Structural Plans
1.4.2.4 Furnishing Plans
1.4.3 Specifications
1.4.3.1 General Provisions
1.4.3.2 Special Provisions
1.4.4 Estimate
1.4.5 Bid Documents
1.4.6 Signed Contract
1.5 Phase 5: Physical Improvement (construction)
1.5.2 Civil Work
1.5.2.1 Earthwork
1.5.2.2 Pavement
1.5.3 Water Supply, Drainage, and Sanitation
1.5.3.1 Drainage
1.5.3.2 Water Supply
1.5.3.3 Sanitary Sewers and Purification
1.5.4 Structural Work
1.5.4.1 Structures
1.5.4.2 Electrical
1.5.4.3 Mechanical
1.5.5 Furnishings

Appendix O
Software Implementation WBS
Example
This example illustrates a generic WBS that could be applied to range of different
software development projects by suitable customization, especially at the lower levels.
As such it is a WBS Template. The deliverables include overhead work, such as ‘‘Admin-
istration’’, intermediate deliverables, such as ‘‘requirements approvals’’, tangible end
products, such as ‘‘configured software’’ and services such as ‘‘training’’. Not all WBS
Elements are decomposed to the same level of detail, for example, ‘‘Go Live’’. These
could be decomposed further in the context of a specific project. This WBS example
is shown below in two formats. The first is the standard outline format, the second
top-down tree structure view is provided for comparison.
1 WBS for Software Implementation Project
1.2 Product Requirements
1.2.1 Software Requirements
1.2.1.1 Draft Software Requirements
1.2.1.2 Final Software Requirements
1.2.1.3 Software Requirements Approval
1.2.2 User Documentation
1.2.2.1 Draft User Documentation
1.2.2.2 Final User Documentation
1.2.2.3 User Documentation Approval
1.2.3 Training Program Materials
1.2.3.1 Initial Training Requirements
1.2.3.2 Initial Training Materials
1.2.3.3 Trial Course Delivery
1.2.4 Hardware
1.2.4.1 Draft Hardware Requirements
1.2.4.2 Final Hardware Requirements
1.2.4.3 Hardware Requirements Approval
1.2.5 Implementation & Future Support
1.3 Detail Software Design
1.3.1 Initial Software Design
1.3.2 Final Software Design
1.3.3 Software Design Approval
1.4 System Construction
1.4.1 Configured Software
1.4.2 Customized User Documentation
1.4.3 Customized Training Program Materials
1.4.4 Installed Hardware
1.4.5 Implementation & Future Support
92312$CH20 09-08-06 05:59:28

92312$CH20 09-08-06 05:59:28
1.5 Test
1.5.1 System Test Plan
1.5.2 System Test Cases
1.5.3 System Test Results
1.5.4 Acceptance Test Plan
1.5.5 Acceptance Test Cases
1.5.6 Acceptance Test Results
1.5.7 Approved User Documentation
1.6 Go Live
1.7 Support
1.7.1 Training
1.7.2 End User Support
1.7.3 Product Support
Figure O-1. Software Implementation WBS Example
tice Standard.

Appendix P
Horizontal Tree Structure Format
WBS Example
This horizontal tree display of a high level Work Breakdown Structure (WBS) contains
all basic work associated with the concrete canoe design, construction, and documen-
tation. It clearly defines the work to be performed, identifies the needed expertise,
assists in selection of the project team and establishes a base for project scheduling
and control. Each of the items listed can continue to be broken down (as indicated
by the arrows) until there is a specific task that can be assigned to members of the
concrete canoe team. For example, under ‘‘Canoe Display Stands’’, the specific tasks
would include procuring materials, constructing the stands, painting the stands, and
applying any decals. These are work tasks that can be given specifically to a group or
individual. An issue with this WBS is the fact that some WBS elements are stated as
activities using verb phrases. Ideally, all WBS elements should be stated as nouns that
describe decomposed elements of the work.
92312$CH21 09-08-06 06:01:00

92312$CH21 09-08-06 06:01:00
Figure P-1. Horizontal Tree Structure Format WBS Example
Source: Modified from: Concrete Canoe Design Guide—Scott Rutledge & Ryan McKaskle, http://
members.cox.net/concretecanoe/wbs.htm

References
Haugan, Gregory T. (2002). Effective Work Breakdown Structures. Vienna, VA Manage-
mentConcepts.
Pritchard, Carl L. (1998). How to Build a Work Breakdown Structure: The Cornerstone
of Project Management. Arlington VA. ESI International.
Project Management Institute. (2003). Organizational Project Management Maturity
Model (OPM3威): Knowledge Foundation. Newtown Square, PA: Project Manage-
ment Institute.
Project Management Institute. (2004). Practice Standard for Earned Value Management
(EVM). Newtown Square, PA: Project Management Institute.
Project Management Institute. (2001) Practice Standard for Work Breakdown Struc-
tures. Newtown Square, PA: Project Management Institute.
Project Management Institute. (2004). A Guide to the Project Management Body of
Knowledge (PMBOK威 Guide)—Third Edition. Newtown Square, PA: Project Manage-
ment Institute.
Project Management Institute. (in development). The Practice Standard for Scheduling.
Newtown Square, PA: Project Management Institute.
Project Management Institute. (Available May 2006). The Standard for Portfolio Man-
agement. Newtown Square, PA: Project Management Institute.
Project Management Institute. (Available May 2006). The Standard for Program Man-
Uyttewaal, Eric (2005). Dynamic Scheduling with Microsoft Office Project 2003: The
Book by and for Professionals. Boca Raton, FL: J. Ross Publishing, Inc.
McDonald Bradley, Inc. 2002. Independent Verification and Validation (IV and V) White
Paper. December 2002, available from http://www.mcdonaldbradley.com/comps/
white%20papers/IVV%20white%20paper.pdf; accessed 20 February 2005.
Berg, Cindy and Colenso, Kim. 2000. ‘‘Work Breakdown Structure Practice Standard
Project—WBS vs. Activities,’’ PM Network, April 14(4): 69–71. Project Management
Institute, 2000. (Journal article) CID 1253
Chapman, James R. 2004. Work Breakdown Structures, Version 2.01, November, 2004.
available from http://www.hyperthot.com/pm wbs.htm; accessed 22 February
2005.
Cleland, David I. 1964A. Air University Review. November–December. p. 13.
Cleland, David I. 1964B. Why Project Management? Business Horizons. Winter. p. 81.
Department of Defence. 1995. Work Breakdown Structures for Defence Materiel Projects.
Commonwealth of Australia, Australian Defence Standard Draft Def(Aust)5664
Issue A.
Department of Defense. 1975. Military Standard Work Breakdown Structures for
Defense Materiel Item., (MIL-STD-881A). Washington DC. 1 November 1975.
Department of Defense, 1998. Department of Defense Handbook. Work Breakdown
Structure MIL-HDBK-881. Washington DC. 2 January 1998.
92312$CH22 09-08-06 06:02:03

92312$CH22 09-08-06 06:02:03
Department of Energy. 2001. Performance Based Contracting: Development of a
Work Statement. August.. available from http://www1.pr.doe.gov/acqguide/
AGChapter37.htm; accessed 18 January 2005.
Dinsmore, Paul C. 2000. ‘‘Enterprise Project Management: A Road Map for Getting off
to the Right Start,—PM Network. June. p. 27.
Githens, Gregory D. 2001. ‘‘Manage Innovation Programs with a Rolling Wave.— PM
Network. May. p. 35.
Globerson, S. 1994. ‘‘Impact of Various Work-Breakdown Structures on Project Concep-
tualization.’’ International Journal of Project Management. 12 (3) p. 165.
Grove, Cornelius, Hallowell, Willa and Smith, Cynthia J. ‘‘A Parallel WBS for Interna-
tional Projects.’’ PM Network. March. p. 37.
Halli, Wayne. 1993. PM Network. May. p. 12.
Haugan, Gregory T. 2002. Effective Work Breakdown Structures. Vienna, VA Manage-
ment Concepts.
Homer, John L and Gunn, Paul D. 1995. Work Structuring for Effective Project Manage-
ment. Project Management Institute 26th Annual Seminar/Symposium. New Orleans
LA, October, 1995. p. 84.
Kast, Fremont and Rosenzweig, James. 1961. ‘‘Weapon System Management and Orga-
nizational Concepts.’’ Journal of American Military. December.
Kerzner H. 1997. Project Management: A Systems Approach to Planning, Scheduling,
and Controlling (6th ed.). New York: John Wiley & Sons.
Kerzner H. 1996. The Growth and Maturity of Modern Project Management. 27th Annual
Seminar/Symposium October 1996. Boston MA: Project Management Institute.
Kloppenborg, Timothy J and Opfer, Warren A. 2002. ‘‘The Current State of Project
Management Research: Trends, Interpretations, and Predictions.’’ Project Manage-
ment Journal. 33 (2).
Luby, Robert E., Peel, Douglas, and Swahl, William. 1995. ‘‘Component-Based Work
Breakdown Structure (CBWDS).’’ Project Management Journal. December. p. 38.
Mansuy, John. 1991. ‘‘Work Breakdown Structure: A Simple Tool for Complex Jobs.’’
Cost Engineering. 33(12). December.
McDonald Bradley, Inc.. 2002. Independent Verification and Validation White Paper.
December 2002., retrieved 2/20/2005, Website: http://www.mcdonaldbradley.com/
comps/white%20papers/IVV%20white%20paper.pdf
National Aeronautics and Space Administration. 1962. DOD and NASA Guide. PERT
Cost Systems Design. June 1962. Washington DC: Office of the Secretary of Defense.
National Aeronautics and Space Administration. NASA PERT and Companion Cost
System Handbook. Washington, DC. October 30, 1962.
National Aeronautics and Space Administration. (1994) Work Breakdown Structure.
May, 1994.
Pritchard, Carl L. 1998. How to Build a Work Breakdown Structure: The Cornerstone
of Project Management. Arlington VA. ESI International.
Project Management Institute. 1969. Articles of Incorporation.
Project Management Institute. PMI Today. April 2003.
Project Management Institute. 2003. Organizational Project Management Maturity
Model (OPM3威): Knowledge Foundation. Newtown Square, PA: Project Manage-
ment Institute.
Project Management Institute. 2004. Practice Standard for Earned Value Management
(EVM). Newtown Square, PA: Project Management Institute.
Project Management Institute. 2001. Practice Standard for Work Breakdown Structures.

Project Management Institute. 2004. A Guide to the Project Management Body of Knowl-
edge (PMBOK威 Guide—Third Edition). Newtown Square, PA: Project Management
Institute.
Project Management Institute. (currently in development). The Practice Standard for
Scheduling. Newtown Square, PA: Project Management Institute.
Project Management Institute. (Available May 2006). The Standard for Portfolio Man-
Project Management Institute. (Available May 2006). The Standard for Program Man-
Project Management Institute. 2000. Practice Standard for Work Breakdown Structures .
Project Management Institute Standards Committee. 1987. A Guide to the Project
Management Body of Knowledge (PMBOK Guide威). Newtown Square, PA: Project
Management Institute.
Project Management Institute Standards Committee. 1996. A Guide to the Project
Management Body of Knowledge. Darby PA: Project Management Institute.
Rad, Parviz F. 1999 ‘‘Advocating a Deliverable-Oriented Work Breakdown Structure.’’
Cost Engineering. 41(12). December, p 35.
Raz, T. and Globerson, S. 1998. ‘‘Effective Sizing and Content Definition of Work
Packages.’’ Project Management Journal. December.
Shtub, Avraham. 1997. ‘‘Project Segmentation—A Tool for Project Management.’’ Inter-
national Journal of Project Management. 15(1). p. 15.
Stewart, John M. 1965. ‘‘Making Project Management Work.’’ Business Horizons.
Fall. 1965.
Uyttewaal, Eric. 2005. Dynamic Scheduling with Microsoft Office Project 2003: The Book
by and for Professionals. Boca Raton, FL. J. Ross Publishing, Inc.
Ward, Gregory F. 2001. ‘‘The WBS Dictionary—Extending the Work Breakdown Struc-
ture,’’ Proceedings of the Project Management Institute Annual Seminars & Sympo-
sium. November. Nashville TN: Project Management Institute.
Webster, Francis M. Jr. 1999. ‘‘They Wrote the Book. The Early Literature of Modern
Project Management.’’ PM Network. August.
Youker, Robert. 1999. ‘‘A New Look at the WBS: Project Breakdown Structure. PM
Network. November. p. 33.
92312$CH22 09-08-06 06:02:03

Glossary
Many of the words defined here have broader, and in some cases, different dictionary
definitions.
The definitions use the following conventions:
● Terms used as part of the definitions and that are defined in the glossary are shown
in italics.
䡲 When the same glossary term appears more than once in a given definition, only
the first occurrence is italicized.
䡲 In some cases, a single glossary term consists of multiple words (e.g., risk
response planning).
● When synonyms are included, no definition is given and the reader is directed to
the preferred term (i.e., see preferred term).
● Related terms that are not synonyms are cross-referenced at the end of the definition
(i.e., see also related term).
Activity. A component of work performed during the course of a project.
Apportioned Effort (AE). Effort applied to project work that is not readily divisible
into discrete efforts for that work, but which is related in direct proportion
to measurable discrete work efforts. Contrast with discrete effort.
Control Account (CA). A management control point where scope, budget (resource
plans), actual cost, and schedule are integrated and compared to earned
value for performance measurement. Control accounts are placed at selected
management points (specific components at selected levels) of the work break-
down structure. Each control account may include one or more work packages,
but each work package may be associated with only one control account.
Each control account is associated with a specific single organizational compo-
nent in the organizational breakdown structure (OBS). Previously called a cost
account. See also work package.
Customer. The person or organization that will use the project’s product or service
or result. (See also user).
Decomposition. A planning technique that subdivides the project scope and project
deliverables into smaller, more manageable components, until the project
work associated with accomplishing the project scope and providing the deliv-
erables is defined in sufficient detail to support executing, monitoring, and
controlling the work.
Deliverable. Any unique and verifiable product, result, or capability to perform a
service that must be produced to complete a process, phase, or project. Often
used more narrowly in reference to an external deliverable, which is a delivera-
ble that is subject to approval by the project sponsor or customer.
Level of Effort (LOE). Support-type activity (e.g., seller or customer liaison, project
cost accounting, project management, etc.) which does not produce definitive
92312$CH23 09-08-06 06:02:59

92312$CH23 09-08-06 06:02:59
end products. It is generally characterized by a uniform rate of work perfor-
mance over a period of time determined by the activities supported.
Organizational Breakdown Structure (OBS). A hierarchically organized depiction
of the project organization arranged so as to relate the work packages to the
performing organizational units.
Phase. See project phase.
Portfolio. A collection of projects or programs and other work that are grouped
together to facilitate effective management of that work to meet strategic
business objectives. The projects or programs of the portfolio may not neces-
sarily be interdependent or directly related.
Portfolio Management. The centralized management of one or more portfolios,
which includes identifying, prioritizing, authorizing, managing, and control-
ling projects, programs, and other related work, to achieve specific strategic
business objectives.
Product Scope. The features and functions that characterize a product, service,
or result.
Program. A group of related projects managed in a coordinated way to obtain
benefits and control not available from managing them individually. Programs
may include elements of related work outside of the scope of the discrete
projects in the program.
Program Management. The centralized coordinated management of a program to
achieve the program’s strategic objectives and benefits.
Progressive Elaboration. Continuously improving and detailing a plan as more
detailed and specific information and more accurate estimates become avail-
able as the project progresses, and thereby producing more accurate and
complete plans that result from the successive iterations of the planning
process.
Project. A temporary endeavor undertaken to create a unique product, service,
or result.
Project Phase. A collection of logically related project activities, usually culminating
in the completion of a major deliverable. Project phases (also called phases)
are mainly completed sequentially, but can overlap in some project situations.
Phases can be subdivided into subphases and then components; this hierar-
chy, if the project or portions of the project are divided into phases, is con-
tained in the work breakdown structure. A project phase is a component of a
project life cycle. A project phase is not a project management process group.
Project Scope. The work that must be performed to deliver a product, service, or
result with the specified features and functions.
Resource Breakdown Structure (RBS). A hierarchical structure of resources by
resource category and resource type used in resource leveling schedules and
to develop resource-limited schedules, and which may be used to identify
and analyze project human resource assignments.
Responsibility Assignment Matrix (RAM). A structure that relates the project organi-
zational breakdown structure to the work breakdown structure to help ensure
that each component of the project’s scope of work is assigned to a responsible
person/team.
Risk. An uncertain event or condition that, if it occurs, has a positive or negative
effect on a project’s objectives.

Scope. The sum of the products, services, and results to be provided as a project.
(See also project scope and product scope.)
Scope Change. Any change to the project scope. A scope change almost always
requires an adjustment to the project cost or schedule.
Stakeholder. Person or organization (e.g., customer, sponsor, performing organiza-
tion, or the public) that is actively involved in the project, or whose interests
may be positively or negatively affected by execution or completion of the
project. A stakeholder may also exert influence over the project and its deliver-
ables.
Standard. A document established by consensus and approved by a recognized
body that provides, for common and repeated use, rules, guidelines, or charac-
teristics for activities or their results, aimed at the achievements of the opti-
mum degree of order in a given context.
Statement of Work (SOW). A narrative description of products, services, or results
to be supplied.
Task. A term for work whose meaning and placement within a structured plan for
project work varies by the application area, industry, and brand of project
management software.
User. The person or organization that will use the project’s product or service. (See
also customer.)
Work Breakdown Structure (WBS). A deliverable-oriented hierarchical decomposi-
tion 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 work. The WBS is decomposed into work
packages. The deliverable orientation of the hierarchy includes both internal
and external deliverables. (See also work package and control account.)
Work Breakdown Structure Component. An entry in the work breakdown structure
that can be at any level.
Work Breakdown Structure Dictionary. A document that describes each component
in the work breakdown structure (WBS). For each WBS component, the WBS
dictionary includes a brief definition of the scope or statement of work, defined
deliverable(s), a list of associated activities, and a list of milestones. Other
information may include: responsible organization, start and end dates,
resources required, an estimate of cost, charge number, contract information,
quality requirements, and technical references to facilitate performance of
the work.
Work Breakdown Structure Element. Any single work breakdown structure (WBS)
element or component and its associated WBS attributes contained within
an individual work breakdown structure.
Work Package. A deliverable or project work component at the lowest level of
each branch of the work breakdown structure. The work package includes the
schedule activities and schedule milestones required to complete the work
package deliverable or project work component. (See also control account.)
92312$CH23 09-08-06 06:02:59

Index by Keyword
Activity .......................................................................................1, 4-5, 8, 14, 16-18, 43, 107
Apportioned Effort (AE) ......................................................................................................107
Control Account (CA) ........................................................................................................107
Customer ...................................... 4-6, 10, 22, 24, 36, 52-53, 60-61, 63, 91-92, 97, 107, 109
Decomposition .................. 1, 3-4, 7-10, 16, 20, 22-23, 25, 35-38, 54-55, 65, 72, 88, 107, 109
Deliverable ...................3-6, 13, 15, 20-21, 24-25, 30-32, 35-38, 65, 81, 95, 97, 105, 107-109
Level of Effort (LOE) .......................................................................................................5, 107
Organizational Breakdown Structure (OBS) ........................................5, 7, 13, 15, 22, 107-108
Phase .......................................................................... 4, 6, 24, 73-79, 87-88, 97-98, 107-108
Portfolio .............................................................................................1-2, 15, 22, 27, 40, 108
Portfolio Management ......................................................................18, 27, 40, 103, 105, 108
Product Scope ......................................................................................................91, 108-109
Program ..................................... x, 1-2, 15, 18, 22, 27, 37, 40, 43-44, 49, 62, 77-80, 99, 108
Program Management .................................................................13, 17-18, 80, 103, 105, 108
Progressive Elaboration ...........................................................................................2, 20, 108
Project ................ix-xi, 1-25, 27-45, 47-55, 60-61, 63, 65, 69, 71-78, 80-81, 83, 85-88, 90-93,
95-105, 107-109
Project Phase ....................................................................................................................108
Project Scope ......................................... 1, 4-8, 11, 13-15, 18, 20-21, 24, 27-30, 33, 107-109
Resource Breakdown Structure (RBS) ..........................................................................15, 108
Responsibility Assignment Matrix (RAM) ...........................................................7, 13, 22, 108
Risk ....................................................... 1-4, 6, 13-14, 21, 25, 28, 33-35, 38-39, 97, 107-108
Scope ......................1-3, 5-9, 13-18, 20-22, 25, 28, 31, 33, 35-40, 51, 60, 85-86, 97, 107-109
Scope Change ...................................................................................................................109
Stakeholder ................................................................................................14, 35-36, 87, 109
Standard .... ix-x, 1-2, 4, 8, 10, 13, 17-19, 27, 29-30, 41-49, 51, 61, 63, 69, 72, 76-77, 80, 83,
86, 90-91, 93, 95-96, 98-100, 102-105, 109
Statement of Work (SOW) .................................................................................................109
Task ..........................................................................................................5, 18, 86, 101, 109
User .............................................................................................2, 88, 91, 99-100, 107, 109
Work Breakdown Structure (WBS) ....ix, 1, 5, 27, 43, 51, 65, 71, 73, 77, 81, 85, 87, 101, 109
Work Breakdown Structure Component ..........................................................................5, 109
Work Breakdown Structure Dictionary ................................................................................109
Work Breakdown Structure Element ...................................................................................109
Work Package .................................................. 5-6, 8, 15, 17-18, 20-21, 30, 32, 36, 107, 109
92312$CIND 09-15-06 08:59:05

Work Breakdown Structure PMI.pdf

More Related Content

What's hot (20)

Similar to Work Breakdown Structure PMI.pdf (20)

Recently uploaded (20)

Work Breakdown Structure PMI.pdf