You are on page 1of 31

The Work Breakdown Structure:

A Brief Synopsis
Note to reader
The discussion of history and practice in this White Paper is based on readily available documents and
references obtained through a reasonably diligent search of relevant archives and public domain
information sources. This White Paper should not be construed as an exhaustive, academic-quality,
professional research paper. The information provided here is intended for use in establishing context
and background for the development of the concept of the Work Breakdown Structure.
Opinions or conclusions expressed in this White Paper reflect the views of the authors and do not
necessarily reflect the opinions or position of the Project Management Institute.

Authors:
Shelly A. Brotherton, PMP
Robert T. Fried, PMP
George A. Ksander, PMP
Eric S. Norman, PMP
April, 2006

The History of the Work Breakdown Structure


The WBS has been at the core of project management practice since the beginning of the
professionalization of project management.
The Work Breakdown Structure (WBS) began to come into use in the late 1950s and early 1960s.
Creation of a WBS was evident in the DoD and NASA Guide PERT COST Systems Design June 1962
(Chapter II, pages 23 35), which was, in turn, based on the original PERT system developed by the US
Navy (NASA PERT and Companion Cost System Handbook. October 30, 1962, p. II-1). The concept of
the WBS and the practices around its use were initially developed by the US Department of Defense
(DoD) and National Aeronautics and Space Administration (NASA) for the purpose of planning and
controlling large acquisition projects whose objective was development and delivery of weapons or space
systems (Cleland, Air University Review, 1964, p14). These projects often involved many industrial
contractors each with responsibility for separate components of the system and were managed by a
central administrative office, either within a governmental agency or within one of the contracting firms
which served as prime contractor. In this environment, the WBS was used to ensure that the total
project is fully planned and that all derivative plans contribute directly to the desired objectives (NASA
PERT and Companion Cost System Handbook, 1962). As described by the DOD and NASA Guide.
PERT Cost Systems Design (June 1962, p. 26), the development of the work breakdown structure:

Defines the project tasks to be performed and establishes their relationship to the project end
item(s) and project objectives;
Establishes the framework for integrated cost and schedule planning and control;

Establishes a framework for summarizing the cost and schedule status of the project for
progressively higher levels of management.

During this early period and into the 1970s, sophisticated techniques and information systems for
managing and controlling the project schedule and budget, such as PERT, CPM, C/SCSC and others,
were also developed (Kloppenborg and Opfer, 2002). The WBS was the foundation for all of these
systems (DoD MIL-STD881A, 1975). The use of these systems, including the WBS, was mandatory for
projects above a certain size and was recommended for all projects (DOD MIL-STD881A, 1975). To
support this requirement, a series of guidelines, handbooks and manuals was promulgated to provide
uniformity of procedure and documentation among the many administrative offices and contractors
working on a single project. These documents have been periodically updated and continue in effect to
the present day by both US and other governments. (MIL-STD881A 1998, Australian Defence Standard
Draft Def(Aust)5664 Issue A, Jun 2004).
Government requirements for the use of project control techniques, including the WBS, facilitated the
diffusion of knowledge of these techniques and appreciation of their value throughout those industries
doing business with the government. As the value of project management thinking and methods spread
beyond large military industrial projects, so too did appreciation of the value of the WBS. In part this
spread was facilitated by practitioners who moved from the government into private sector industries. In
part it was stimulated through the teaching and consulting of academics in business and engineering
schools and a number of instructional papers and texts (for example: Globerson, 1994, Pritchard 1998,
Haugan 2002).
Development of the WBS was one component of the evolution and codification of the broader collection
of organizational theory and practices that have become known as Project Management (Cleland, 1964,
Stewart, 1965, Kerzner, 1996, Webster 1999). Another manifestation of the increasing professionalization
of project management was the formation of the Project Management Institute (PMI) in 1969 in order
To promote a unifying influence in the advancement of the field of Project Management with emphasis
on the tools and methods for the planning, scheduling and control of project oriented tasks (Project
Management Institute, Articles of Incorporation, 1969). One significant effort of the Project Management
Institute, among others, was the evolution of a set of standards which described and codified The
content and structure of the professions body of knowledge (standards) (PMBOK Guide Third Edition,
2004, p. 309). This most recent result of this effort is the PMBOK Guide Third Edition, the purpose of
which is to identify that subset of the Project Management Body of Knowledge that is generally
recognized as good practice (PMBOK Guide Third Edition, 2004, p.3) as well as a series of Application
Area Extensions (Program and Portfolio Management Standards, Earned Value Practice Standard,
Government Extension, DOD Extension, Construction Extension) which describe generally accepted
knowledge and practices that are specific to those areas (PMBOK Guide Third Edition, 2004, p 329).
Throughout the growth and expansion of these standards, the WBS has played a central role as a tool
and technique for organizing and managing the project scope and supporting other processes. The WBS
has received progressively more attention in successive versions of the PMBOK Guide, and in the Third
Edition a new Project Management Process was included, i.e., 5.3 Create WBS.
PMI recognized the unique importance of the WBS when it published, in 2001, a Practice Standard
devoted exclusively to the WBS. The Practice Standard for Work Breakdown Structures was
intended to provide guidance in the initial generation, subsequent development, and application of the
Work Breakdown Structure (WBS) (Project Management Institute, 2001, p. xi). This document was the
first practice standard, i.e., it focused on providing guidelines on the mechanics (e.g., nuts and bolts,
basics, fundamentals, step-by-step usage guide, how it operates, how to do it) for the WBS (Project
Management Institute, 2001, p. 29). A Practice Standard is intended to be more prescriptive than the
PMBOK Guide (Project Management Institute, 2001, p. 30). Increasing sophistication in the use of the
WBS has stimulated production of this updated and revised edition - Practice Standard for Work
Breakdown StructuresSecond Edition.

The publication of updated and revised editions of the PMBOK Guide and WBS Practice Standard
recognizes the growth and increased sophistication of project management thought and practice in
general, and of the WBS in particular. In some cases this evolution reflects revised thinking and
reformulation of earlier concepts, and in other cases it represents progressive elaboration and
formalization of concepts that were previously only implicit.
With respect to the WBS, an example of revised thinking is the concept of the WBS as Deliverableoriented. In the 1987 PMBOK Guide, the WBS was defined as a Task-oriented family tree of
activities. In the 1996 and 2000 editions of PMBOK Guide, the WBS was defined as a deliverableoriented grouping of project elements. In the PMBOK Guide Third Edition, it had become a
deliverable-oriented decomposition of the work to be executed. Throughout this development, however,
the WBS was consistently seen as a tool to organize and define the total work, the scope, of the project.
(Project Management Institute, PMI Today, April 2003, (Project Management Institute, PMBOK Guide
Third Edition, p. 379). The evolution from a task orientation to a deliverable orientation reflects the
realization that decomposition of project deliverables, expressed as nouns, is necessary for complete
scope definition and control, and that the lowest level of the WBS may be connected to activities and
work packages defined in terms of actions, expressed as verbs (Berg and Colenso, 2000, p 69; Project
Management Institute, 2001; PMI Today, April 2003.)
An example of increasing formalization of implied concepts is the explicit statement in the Practice
Standard for Work Breakdown StructuresSecond Edition of the WBS Quality Principle #1 which
states that a WBS is characterized by 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 and a
set of Use-related Characteristics that may vary from one WBS to another because they 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. (Work Breakdown Structure Practice Standard - Second Edition,
p. 21). These concepts had been implicit in descriptions of the WBS from the earliest days but only
became explicit in the latest edition of the Practice Standard. (Core Characteristics: Office of the
Secretary of Defense. DoD and NASA Guide PERT COST Systems Design, June 1962, pp.28, 33, 144;
Rad, 1999, p. 35; Use-related Characteristics: Office of the Secretary of Defense. DoD and NASA Guide
PERT COST Systems Design, June 1962, pp. 33; NASA PERT and Companion Cost System, 1962, p IV1, Globerson, 1994; p. 3; Berg and Colenso, 2000, p. 69,).
For example, DoD and NASA Guide PERT COST Systems Design, June 1962 states the Core
Characteristic:
The work breakdown structure establishes the framework for defining the work to be
accomplished (p. 26).
The same document provides an early expression of the concept of Use-related Characteristics :
..the level of detail should be determined by the program or project manager and
should be a function of such factors as: the size and complexity of the project, the
degree of uncertainty in the work, the familiarity with the work to be performed, and
the time available for planning., (p.33).
The idea has also been expressed by Berg and Colenso:
The WBS is project management tool that can be used in different ways, depending
on the needs pf the project (Berg and Colenso, 2000, p 69).
The WBS has become a powerful and flexible tool that can be designed to meet the needs of many
disparate types of projects, including projects managed with a Rolling Wave approach (Githens, 2001),
enterprise projects (Dinsmore, 2000), projects characterized by repetitive subprojects (Shtub, 1997),
complex projects that require parallel WBSs to manage different aspects of the project (Grove, Hallowell,

and Smith, 1999), and projects where the ability to repackage work on a daily basis is important (Luby,
Peel and Swahl, 1995).
We turn now to a look at how the evolved understanding of the WBS is being used in current practice.

Work Breakdown Structures Present Use


Today, Project Managers are more frequently finding high value in the creation of Work Breakdown
Structures (WBS) as they begin the process of project management. Project success may be attributed
specifically to use of a WBS (Halli, 1993).
As an essential element of the Planning Process Group outlined in the PMBOK Guide - Third Edition,
everyday practice is revealing with increasing regularity that creation of a WBS to define the scope of the
project will help ensure delivery of the projects scope, objectives and outcomes.
Moreover, the more clearly the scope of the project is articulated before the actual work begins, the more
likely the success of the project the intelligent structure of work breakdowns is a precursor to
effective project management. (Gunn and Homer, 1995, p. 1). Specifically, the Planning Process
Group begins with three essential steps Scope Planning (3.2.2.2), Scope Definition (3.2.2.3) and Work
Breakdown Structure Development (3.2.2.4). (PMBOK Guide - Third Edition). The following discussion
will examine the current trends and practice in regards to Work Breakdown Structures.
It is widely written that Work Breakdown Structures are fundamental building blocks for project
management practice. There are many writings on the subject, here are a but a few key examples:
Harold Kerzner writes: The WBS provides the framework on which costs, time, and
schedule/performance can be compared against the budget for each level of the WBS
(Kerzner, p. 791).
From The PMBOK Guide - Third Edition: The WBS is a deliverable-oriented
hierarchical decomposition of the work to be executed by the project team, to
accomplish the project objectives and create the required deliverables The WBS
represents the work specified in the current approved project scope statement.
Components comprising the WBS assist the stakeholders in viewing the deliverables of
the project (p. 112).
Dr. Gregory T. Haugan: The WBS is the key tool used to assist the project manager in
defining the work to be performed to meet the objectives of a project (Haughan, 2002,
p. 15).
Carl L. Pritchard: the WBS serves as the framework for project plan development.
Much like the frame of a house, it supports all basic components as they are developed
and built (Pritchard 1998, p. 2).

Work Breakdown Structure Usage Trends


As we have discussed earlier in this paper, project managers in certain industries including Defense,
Aerospace, Pharmaceuticals, Construction, Financial Services, and others, regularly rely on standard and
elaborate Work Breakdown Structures to plan and manage their work. (DoD Military Standard Work
Breakdown Structures for Defense Material Items MIL-STD-881A; Mansuy, p18; Figure 3, PMBOK
Guide - Third Edition, etc.) This practice is less established in other industries such as Consumer Retail
and some information technology (IT) functions, though as evidenced by the recent survey found in
Appendix A of this document, that trend is changing (see survey results, attached).
More and more frequently, project managers across a broad array of technologies and industries are
using Work Breakdown Structures to articulate and define the work of their projects before developing

other project tools such as resource matrices, network diagrams and schedules. Additionally, leaders are
finding that project difficulties including scope creep, budget shortfalls, poor project performance and
missed deliverables can be traced directly to the absence of a logical WBS or the completeness and
quality of the WBS if it exists - and to the amount of effort spent developing and maintaining the WBS.
By the same token, from anecdotal evidence gathered during the update of the Practice Standard for
Work Breakdown Structures, there remains a contingent of project managers who find little value in the
scope planning and control functions offered by the WBS. For many in this group, creating a WBS is
often seen as an unnecessary task that can be skipped with little or no consequence - or the WBS
becomes simply a representation of the projects schedule in outline form, little more.

Conflicting and Confusing Messages for the Project Manager


If it is clear the WBS is the starting point in the planning process for many other essential project
management processes such as Estimating, Scheduling and Controlling, then why do some project
managers find the WBS a difficult component to create, or a redundant and potentially unnecessary step
in the project planning process? There are likely many reasons why a decreasing number of project
managers give little time or energy to WBS creation. Here are some considerations:
First, in the highly volatile and competitive environment that characterizes the information technology,
financial services and software development industries, there is ever increasing pressure on the project
manager to deliver quickly, using a fluid, flexible and light weight project planning process. It is not
unusual for project mangers in these industries to find themselves encouraged to fast track the planning
phase - or skip from the inception of a project to development of the projects schedule. Speed to market
is of the highest importance and any step that might appear to be expendable becomes a target for
exclusion and is eliminated many times with unintended results. Without a scope statement and an
effective WBS, the project may eventually encounter difficulty and may result in poor performance or
outcomes.
Beyond this, over the past five years, process management and scheduling tools for project management
have evolved to become sophisticated and robust product suites. These tools now offer an array of
automated functions including what many claim as work breakdown structure outputs (see Exhibit 1).
Naturally, it is quite easy for Project Managers to rely on these tools to produce what at first glance
appears to be the WBS they require for their projects. Unfortunately, these tools do not help the project
manager define and decompose the scope of the project in terms of its deliverables (the true
foundational role of the WBS) (PMBOK Guide - Third Edition) but rather enable the project manager to
enter a listing of schedule tasks, push a button and produce what appears to be a WBS.

Figure 1. Project schedule example.


Additional factors including the above stated need for fast track project delivery and a broadly held
assumption that smaller projects do not require Work Breakdown Structures tend to weaken the
importance of the WBS. At the same time - for complex projects, broad or long-running projects, costly
projects and projects of critical importance to an organization or agency, the necessity to carefully detail
project scope has evolved to an imperative.
Compounding this issue is the array of conflicting guidance regarding the proper approach to structuring
the creation of a WBS. As discussed above, the PMBOK Guide - Third Edition defines the WBS as a
deliverable-oriented, hierarchical grouping of the work to be executed by the project team to accomplish
the project objectives and create the required deliverables. It organizes and defines the total scope of the
project. Each descending level represents an increasingly detailed definition of the projects work
(PMBOK Guide - Third Edition, p. 394). This definition of the WBS is grounded in decades of
experience, a vast array of empirical evidence and analysis of practical application. Additionally, this
perspective is also generally recognized as good practice, most projects, most of the time. (PMBOK
Guide - Third Edition, p. 18)
As described earlier, the concept of deliverable-oriented development of Work Breakdown Structures is
also reinforced by writings from the Department of Defense (MIL-HDBK-881 1998) and the standard
established for development of the WBS, viz, PMIs current Practice Standard for Work Breakdown
Structures . None-the-less, many authors recommend creating PROCESS-oriented Work Breakdown
Structures (Chapman, 2004, p. 2), while others suggest the best approach is an ACTION-oriented
approach (Pritchard, 1998, p. 9). Further clouding the path to development of effective Work Breakdown
Structures, Systems Development Lifecycle practices such as agile methodologies or Rationals RUP
(Rational Unified Process) are built on the principle of process-orientation and dont easily translate or
lend themselves to the creation of deliverable-orientated Work Breakdown Structures to support them. In
these cases where a process-orientation is an effective method used during project planning, the
development and use of a separate, deliverable-oriented WBS to define the project scope may be a
valuable complement.

Finding Answers Evaluating Alternatives for WBS Creation


Lets examine these approaches to WBS orientation more carefully. We will discuss process-oriented,
task-oriented and deliverable-oriented approaches in order, below.
Process-oriented WBS construction does not articulate project outcomes
Carefully developing process-oriented Work Breakdown Structures may ensure that each project process
is clearly articulated and that each of these processes is detailed to the appropriate work package level.
Following standard WBS development practices, when creating a process-oriented WBS, will guide the
project manager to develop an associated WBS Dictionary to carefully explain the content of each
element in the WBS. Developing a process-oriented WBS will not, however, aid the project manager in
defining the outcomes, results or deliverables from the project effort.
Though a process-oriented WBS may be constructed using best in class practice, the resulting WBS
does not necessarily document and communicate outcomes, but rather details the processes employed
to deliver the intended outcomes. In this case, it would be quite possible to successfully execute WBS
elements or entire WBS constructs, ensuring the processes are being executed with a high degree of
quality while overlooking or omitting key products from one or more of the WBS elements. As an
example, in a process-oriented WBS, one of the level 2 elements may be Testing Processes; and within
this element, Unit Testing, Integration Testing and System Testing at level 3. In a process-oriented
approach, with focus on the quality of the process it would be possible to perform any and all of these
testing processes without error - and do so repeatedly without delivering the intended product.
Action-oriented WBS construction does not provide clear direction for delivering project
deliverables
As in the process-oriented WBS construction described above, it is also possible to perform project tasks
and activities with a high degree of quality, without delivering desired project outcomes. The example
here is similar to the process-oriented discussion. The WBS can be defined in terms of broad Tasks or
Activities at level 2 that include narrower and smaller elements at levels 3 and beyond (decomposition of
the work).
To use an example, a level 2 task may be described as Design the Product, while level 3 elements
include Design Internal Components, Design External Components, Design Common Components
and Design Integration Components level 4: Design sub-components 1 n. In a hierarchical-outline
format we would represent this in a WBS as follows (Exhibit 2)
2.1 Design the Product
2.1.1 Design Internal Components
2.1.1.1 Design internal sub-component 1
2.1.1.2 Design internal sub-component 2
2.1.1.3 Design internal sub-component n
2.1.2 Design External Components
2.1.2.1 Design external sub-component 1
2.1.2.2 Design external sub-component 2
2.1.2.3 Design external sub-component n
2.1.3 Design Common Components
2.1.3.1 Design common sub-component 1
2.1.3.2 Design common sub-component 2
2.1.3.3 Design common sub-component n
2.1.4 Design Integration Components
2.1.4.1 Design integration component 1
2.1.4.2 Design integration component 2
2.1.4.3 Design integration component n
Figure 2. Sample action-oriented WBS.

Here, the WBS is again defined in terms of the activities and tasks (actions) that must occur. Further,
these actions may be described within the associated WBS Dictionary in enough detail to recommend or
imply a particular order (which, as reviewed above is more oriented toward a scheduling exercise than
scope definition). Whatever the case, once again, while it may be possible to perform design
activities/tasks precisely, the intended outcomes products of these efforts are not particularly calledout by the WBS construction or associated dictionary (implied herein, but not presented). The most
important deliverables specifically the Product Design and its associated External, Internal and
Integration components are not defined.
In action-oriented WBS examples (Pritchard, 1998, p. 9, p. 20) there may be great detail describing the
task or activity to be performed, including specific tools, responsible persons, task duration and the like,
with little clarification of the outcome of the action or criteria by which it would be deemed complete and
acceptable by the receiver(s).
Deliverable-oriented WBS construction focuses on project outcomes
Creating deliverable-oriented Work Breakdown Structures focuses the project manager, project team,
stakeholders and sponsors on the outcomes or products of the project. As discussed earlier, the
deliverable-orientation and progressive decomposition will facilitate the process by which the project
manager and team describe, detail, communicate and measure progress toward project results.
To provide an example, describing WBS levels as deliverable-oriented groupings, levels 2, 3 and beyond
would contain nouns and adjectives to describe their content. For instance, Figure 3 illustrates a
deliverable-oriented breakdown of the same work illustrated in Figure as an action-oriented breakdown.
2.1 Product Design
2.1.1 Internal Components Design
2.1.1.1 Design of internal sub-component 1
2.1.1.2 Design of internal sub-component 2
2.1.1.3 Design of internal sub-component n
2.1.2 External Components Design
2.1.2.1 Design of external sub-component 1
2.1.2.2 Design of external sub-component 2
2.1.2.3 Design of external sub-component n
2.1.3 Common Components Design
2.1.3.1 Design of common sub-component 1
2.1.3.2 Design of common sub-component 2
2.1.3.3 Design of common sub-component n
2.1.4 Integration Components Design
2.1.4.1 Design of integration component 1
2.1.4.2 Design of integration component 2
2.1.4.3 Design of integration component n
Figure 3. Sample deliverable-oriented WBS.
The WBS dictionary for these elements would carefully describe the subject elements in great detail
and may include (though not limited to) the WBS element owner, resource pool, tools, requirements,
dependencies, and would specifically include a definition of the finished product including criteria
detailing how the completeness of the element would be defined as well as the process by which it
would be measured to the point of including the metrics used for its evaluation.
With this process as a foundation, each WBS element articulates and drives toward a specific
measurable outcome or product, whether that outcome is an internal deliverable (internal to the project)
or an external deliverable (a project outcome intended for receivers or stakeholders outside the project
team or organization). Moreover, the WBS constructed in this manner provides a detailed definition of the
project scope as well as its limits, and provides the project manager with a foundation composed of a

group of unique building blocks on which to construct the project schedule, resource matrix, risk plan,
change control process and more.

Benefit to the Project or Program


Practical evidence has revealed that Work Breakdown Structures provide a foundation for other project
related elements and activities. By decomposing the work into meaningful, clearly articulated elements
that relate to one another as well as the overall product of the effort, the project manager provides a basis
for budget and resource forecasting, network diagram and schedule development, change and risk
management

Benefit to Stakeholders
The WBS also provides a clear articulation of the projects scope to stakeholders. The WBS can be used
as a basis for communicating with stakeholders about the outcomes of the project and can be the
primary vehicle for negotiating scope change requests. In this way, the WBS becomes a cornerstone of
the project or program effort.

100% Rule
One of if not the most important guiding principle in the development, decomposition and evaluation of
the WBS is the 100% Rule. The rule states:
The next level decomposition of a WBS element (child level) must represent 100 percent of the work
applicable to the next higher (parent) element. (Haugan, 2002, p 17).
If the 100% Rule is followed from the highest level to the lowest levels of WBS decomposition, then it
follows that 100% of the project scope will have been defined. The application of this rule to WBS
development is a crucial element to ensuring that the project scope captures ALL project deliverables
internal, external and interim in terms of the work to be completed, including project management.
(Practice Standard for Work Breakdown Structures Second Edition, 2006) Beyond the creation of the
WBS, if the rule is applied down to the activity level of the project schedule, then 100% of the relevant
activities will have been identified. (Haugan, 2002, p 17)
No matter which approach one takes for WBS development, the end result should always represent the
full scope of the project. By effectively utilizing the 100% Rule, project managers can ensure that the
desired result is consistently achieved.

Related Tools and Documents for building the WBS


To supplement the importance of the WBS as a foundational scope definition step developed during
project planning, the authors will provide contextual linkage to related project management
documentation and will clarify these documents as the starting point for WBS development.
The primary building blocks for the WBS are the documents the parties engaged in project inception and
planning use and share to describe the boundaries of the project. These are documents that discuss the
outcomes or objectives to be accomplished, the resources that will be made available for use, the
expected performance objectives of the final product, end-product acceptance criteria, etc. Often these
data and key informational elements are found in project chartering documents, Statements of Work
(SOW), Requests for Proposal/Quote (RFP/RFQ), Contracts and Letters of Intent (LOI).
In these documents the project manager will find words that describe outcomes in very specific terms.
Most importantly, the project manager must be on the lookout for words that solidify commitment and
articulate boundaries words such as shall, must, will; will not, must not, and shall be delivered
on or before xx/xx/xxxx (a particular date). These are examples of contract and agreement wording that
describe the specific outcomes of the project and product to be delivered. These words help the project
manager, the customer and the provider organization agree on what a complete, acceptable solution will
be. Once understood, these types of documents, and the words contained in them, help the project
manager frame the WBS for the remainder of the project. Brief examples follow:

Contracts, Statement of Work (SOW) or Statement of Objectives (SOO)


The project contract, Statement of Work or Statement of Objectives often contain the three key
boundaries for the project the triple constraint, for these documents often succinctly describe what
the customer will be purchasing from the supplier, described as end products. In these documents the
project manager will frequently find statements that describe the final deliverables of the project and
may contain words such as: Project A will have 5 features, each performing one of the five following
functions, (numbered and briefly detailed), will be available in production for end-users by January, 1,
2099, and will be delivered at a cost of no more than $99M.
This key information is often contained in larger documents that also describe a variety of standard
contractual features and functions (frequently referred to as boilerplate) that control activities between
the parties and can be easily overlooked. The project manager should attempt to locate copies of the
contract agreements, SOW and SOO whenever possible these are fundamental inputs to WBS
creation.
Project Scope Statement
The projects scope statement is often the single paragraph, page or documented statement that
describes, in as few words as possible, the complete objective(s) of the project its purpose, its
characteristics, its attributes, its form and function. This statement is frequently the single description that
accompanies or details the project title that appears in the topmost box or element in the WBS and is
included in the WBS Dictionary. The project scope statement is often the customer's only description of
what he/she perceives is the reason for funding the effort and frequently describes the customers
vision of the project outcome in terms of deliverables. The project manager should not begin creating the
WBS without first understanding the scope of the project. If the project scope statement isnt written, the
project manager should work to create the scope statement with assistance and approval from both the
sponsor and provider organization leadership before creating the WBS. The project scope statement is
one of the most important inputs to WBS development.
Project Charter
The project charter represents the authorizing document provided jointly by the sponsoring and provider
organizations for project initiation. The project charter frequently describes the project team in great
detail, the commitments being made by the contracted parties and the spirit as well as the letter of the
agreement between them. In this document the project manger will often find the project Mission, Vision
and Objectives, stated in terms of the sponsoring company/organizations overall strategy.
This is a high-value and important building block, along with the project scope statement, of the WBS for
the project manager - as these statements describe in a few words, how the project is placed in the
overall corporate/organizational strategy and imply the relative importance of the effort to the leadership
of the organization.
In addition to containing statements regarding commitment to the project by both organizations, the
project charter may also describe performance incentive plans that articulate bonus payments for early
delivery or penalties for missed requirements, cost overruns or delivery date slippage. It may also
describe the minimum criteria for acceptance of a component of the project that is of particular interest or the entire project as a whole. Finally, the project charter may describe what elements will be measured
to validate achievement of objectives and how those measurements will be conducted.
At the very least, the Project Charter is a key compendium of information for the project manager and is
used as an input for the development of the WBS.
Because statements of scope in these documents are very concise and are often expressed in general
terms as high level customer requirements, they need to be re-stated in greater detail in order to enable
project planning. The WBS is the tool that enables this detailing and elaboration of the work of the
project. It thereby provides visible traceability of project work to the customers high level specification of

10

the product or result to be delivered by the project. And thus the WBS is the pivotal tool for translating the
customers expressed needs, wants and expectations into the project that will deliver them.
Following the creation of the WBS, the project manager will be challenged to apply and integrate the
WBS into other project processes and Knowledge Areas (PMBOK Guide - Third Edition). To enable
this, a number of tools are available to the project manager. We will discuss a few of these below,
however, the authors would like to point out that the examples provided are not intended to be an
exhaustive or complete list of tools, but rather examples of how other information available to the project
manager can enhance the value of the WBS.
WBS Dictionary
The WBS Dictionary is an accompanying document for the Work Breakdown Structure and is used to
further detail and define the scope elements described in the WBS itself. While the WBS is limited and
contains brief titles and hierarchical indications, the WBS Dictionary explains the content of each WBS
element and can describe in great detail the scope outlined in each parent or child element listed. The
WBS Dictionary is linked to the WBS by its hierarchical indicator and can contain (not limited to):

A scope statement that details and articulates the content of the WBS element
Budget and accounting levels
Resources assigned
Specific outcomes or direction regarding the WBS element
Dates, milestones, sub-milestones
Risks and contingency plans
Decision analysis points
Escalation processes
Approval hierarchy

The WBS Dictionary is used by the project manager to reinforce the content of the WBS and to clearly
describe the scope outlined in the WBS for the project. The WBS Dictionary is maintained and versioned
under formal Change Management processes, as is the WBS.
Organizational Breakdown Structure (OBS)
A natural accompaniment or outcome of the WBS, the Organizational Breakdown Structure is developed
by the project manager to further explain how the projects work, once defined by the WBS, will be
accomplished by the Project Team or the existing organization from which the projects resources will be
taken. Regardless of the actual organization structure, the OBS articulates, for the stakeholders as well
as the project manager, who will be performing the work of the project and how those involved with the
various deliverables described in the WBS are, or will be organized. This document speaks to project
organizational alignment rather than resource and task assignment, and together with the Network
Diagram, aids the project manager in bridging the span between project scope definition and project
schedule. The OBS also clearly shows project financial oversight responsibility at the work package level
by indicating the hierarchical relationship among the personnel responsible for each of the cost accounts
found in the project.
Just as the WBS decomposes the work of the project into deliverables, the OBS decomposes the
organization of the resources producing the deliverables to clearly show the relationship between the
work and the organization that will direct the activities of the resources.
Resource Breakdown Structure (RBS)
The Resource Breakdown Structure extends the OBS and describes specifically which human resources
possess which skills, and often which specific individuals will be performing specific tasks. While the OBS
is an organizational representation of the team, the RBS is a skill/competency/attribute list and an
association of those skills/competencies/attributes to individual tasks and events. The RBS is additionally
important to the project in that it is not restricted to human resource definition. The RBS can reflect non-

11

human resources including (but not limited to) budget, systems and facilities. By detailing the projects
resources in this way, the project manager can forecast resource consumption, cost, duration and
delivery.
Responsibility Assignment Matrix (RAM)
The Responsibility Assignment Matrix helps the project manager link the WBS and the OBS. By defining
responsibility, accountability and authority, this document shows which of the projects resources will be
responsible and accountable for delivering particular components or WBS elements. The RAM
additionally assigns cost to appropriate resources and provides a foundation for resource utilization with
associated cost tracking. Provided as a table, this document depicts an easily-explained relationship
between project outcomes and the project team members who will be overseeing delivery as well as
those responsible for delivering project outcomes.
SUMMARY
The concept of the WBS has evolved to meet the evolving requirements of the project management
profession. This is an evolution which has elaborated the core concept of the WBS: a tool to enable the
definition, development, communication and execution of project scope. And thus the WBS is the pivotal
tool for translating the customers expressed needs, wants and expectations into the project that will
deliver them.
LOOKING AHEAD:
Present practice and trends suggest that WBS evolution will continue into the future. Initial research
indicates a growing reliance on the WBS to document project scope and broader acceptance of the WBS
as a foundational building lock for project planning and delivery.
From a survey focused on WBS usage by project management professionals from around the globe
conducted by the Practice Standard for Work Breakdown StructuresSecond Edition Core Team
between February of 2005 and February 2006, results have shown that:

Today, 87% of survey respondents say that they use the WBS as a planning tool for project
management activities at least half of the time - while 37% use the WBS all of the time

99% of respondents stated that they will use the WBS at least as much as they do today and over
60% will use it more often.

Of those who use the WBS frequently, their main objectives are to support the following:
o Activity definition
o Resource Planning
o Scope Planning and Definition
o Cost Estimating
o Risk Planning

91% of the respondents stated they were either satisfied or very satisfied with the ability of the
WBS to meet the objectives

Three fourths of all respondents who use WBSs employ them for projects of less than one year in
duration.

It is the opinion of the authors, that the WBS is central to the practice of Project Management. The
survey results illustrate the broad acceptance and use of the WBS in project management practice today.
Surprisingly, the results also indicate that a great number of project managers employ the WBS for what
could be considered short-duration projects.

12

While the Practice Standard for Work Breakdown Structures (First Edition) is in active use today, a
number of respondents to the survey have recommended improvements many of which have been
incorporated into the second edition.
In conclusion, as suggested by this paper, the WBS has evolved as a useful Project Management tool
significantly since its inception. It is clear from current trends that this evolution will continue into the
future and is supported by the latest release of the practice standard. The practice standard will also
continue to evolve in parallel with generally accepted project management practice.
(Note: for additional detail regarding survey results, please see the completed survey attached)

13

BIBLIOGRAPHY
Author?. 2002. Independent Verification and Validation White Paper. December. Macdonald Bradley,
Inc., retrieved 2/20/2005, Website:

http://www.mcdonaldbradley.com/comps/white%20papers/IVV%20white%20paper.pdf
Berg, Cindy and Colenso, Kim. 2000, Work Breakdown Structure Practice Standard Project WBS vs.
Activities, PMI Network, April. P.
Chapman, James R. 2004. Work Breakdown Structures, Version 2.01, (November, 2004) retrieved
2/22/05, Website http://www.hyperthot.com/pm_wbs.htm
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 Items,
(MIL-STD-881A), Washington DC, 1 November 1975
Department of Defense, 1998. Department Of Defense Handbook. Work Breakdown Structure MILHDBK-881 Washington DC. 2 January 1998
Department of Energy. 2001. Performance Based Contracting: Development of a Work Statement.
August, retrieved 1/18/2005, Website: http://www1.pr.doe.gov/acqguide/AGChapter37.htm
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 conceptualization.
International Journal of Project Management. 12 (3), p. 165.
Grove, Cornelius, Hallowell, Willa and Smith, Cynthia J. A Parallel WBS for International Projects. PM
Network. March. P. 37.
Halli, Wayne. 1993. PM Network. May. p. 12.
Haugan, Gregory T. 2002, Effective Work Breakdown Structures, Management Concepts: Vienna, VA.
Homer, John L and Gunn, Paul D. 1995. Work Structuring for Effective Project Management. Project
Management Institute 26th Annual Seminar/Symposium. New Orleans LA, October, 1995, p. 84.
Kast, Fremont and Rosenzweig, James. 1961. Weapon System Management and Organizational
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

14

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 Management Journal. V. 33, No. 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
Vol. 33/No. 12, December.
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
Pritchard, Carl. 1998. How to Build a Work Breakdown Structure, The Cornerstone of Project
Management. Arlington, Virginia: ESI International.
Project Management Institute Standards Committee. 1987.???? A Guide to the Project Management
Body of Knowledge (PMBOK Guide). Darby PA: Project Management Institute.1987.
Project Management Institute Standards Committee. 1996. A Guide to the Project Management Body of
Knowledge. Darby PA: Project Management Institute.
Project Management Institute. 1969. Articles of Incorporation
Project Management Institute. 2000. Practice Standard for Work Breakdown Structures (PMBOK Guide
2000 Edition). Newton Square, PA: Project Management Institute.
Project Management Institute. 2004. Project Management Body of Knowledge (PMBOK Guide - Third
Edition.). Newtown Square, Pennsylvania: Project Management Institute Inc.
Project Management Institute. PMI Today, April 2003.
Rad, Parviz F. Advocating a Deliverable-oriented Work Breakdown Structure. Cost Engineering, Vol 41,
No 12, Dec 1999, 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. International Journal of
Project Management vol 15, No. 1. p. 15.
Stewart, John M. 1965. Making Project Management Work. Business Horizons. Fall. 1965.
Ward, Gregory F. 2001. The WBS Dictionary Extending the Work Breakdown Structure, Proceedings of
the Project Management Institute Annual Seminars & Symposium. 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.

15

Current WBS Standard as a Tool


1. How often do you use a Work Breakdown Structure
Number of
Response
(WBS) as a planning tool for project management activities
Responses
Ratio
you lead or participate in?
100% of the time (SKIP TO Question 5)
90
37%
75%-99% of the time (SKIP TO Question 5)
79
32%
50%-74% of the time (SKIP TO Question 5)
45
18%
25%-49% of the time (SKIP TO Question 5)
13
5%
1%-24% of the time (SKIP TO Question 5)
12
5%
Never
5
2%
Total
244
100%
2. If you have answered never, Is it corporate policy not to Number of
Response
use a WBS?
Responses
Ratio
Yes
1
5%
No
18
95%
19
100%
Total
3. If you have answered never, Do you use other tools
Number of
Response
instead of a WBS for planning project management
Responses
Ratio
activities?
Yes
3
16%
No
16
84%
Total
19
100%
# Responses
1
Excel
2
Product Based Planning
3
PBS & OBS as well as wbs
4. If you have answered never, Why do you prefer to use other tools besides the WBS
for planning project management activities?
# Responses
1
due to the size (small) and complexity (low) of projects I manage
2
not instead but as well - wbs is only part of the scope and responsibility modeling
5. What are your objectives when using a WBS please
Number of
Response
check all that apply.
Responses
Ratio
Activity definition
207
86%
Resource planning
171
71%
Cost estimating
127
53%
Cost budgeting
84
35%
Risk management planning
106
44%
Scope planning
160
67%
Scope definition
165
69%
Other, Please Specify
37
15%
1
Sanity check
2
Earned Value Performance Measurement
3
Communication planning, Quality planning
4
Earned Value Performance Management
5
Communication tool
6
Quality Planning
7
Team building
8
Contract/SOW approvals
9
Communication
10
Buy in from team and customer
11
matching product/project assembly structure

16

12
Schedule preparation
13
Procurement Planning
14
Logical Org/Structure of doc/software/equipment
15
dependencies, timeline
16
Scope baseline defining project deliverables
17
forecast completion date and look at dependencies
18
Progress reporting
19
Critical Path Analysis
20
The team builds and agrees on WBS and estimates
21
Confirmation of scope
22
Stakeholder Directory
23
Visualize the entire project globally logically
24
Monitoring, progress, schedule
25
Assumption and Uncertainty Definition, Gap Analysis
26
Dependencies, Critical path
27
quality planning
28
objective presentation of project to stakeholders
29
Scope control integrated with effort reporting
30
schedule planning, status monitoring
31
Requirements Management, Specification Tree Development
32
Time estimation and progress measurement
33
Grouping Phases of Work
34
Communication to team and stakeholders
35
Documentation
36
all the others flow from good scope
37
Actual Cost Tracking
6. How satisfied are you with the ability of the WBS to meet
Number of
this objective?
Responses
Very satisfied
95
Satisfied
122
Neither satisfied nor dissatisfied
16
Dissatisfied
6
Very dissatisfied
0
Total
239
7. What is the size of project for which you use a WBS?
Number of
Please check all that apply.
Responses
Projects which are large compared to others in my company
184
Projects which are medium compared to others in my company
189
Projects which are small compared to others in my company
103
8. What is the complexity of the projects for which you use
Number of
the WBS? Please check all that apply
Responses
Projects that are highly complex
186
Projects with some complexity
204
Project that are not complex
90
9. What is the longevity of the projects for which you use the Number of
WBS? Please check all that apply.
Responses
Less than one year
175
1-2 years
180
3-5 years
71
6 or more years
52
10. In your opinion, will you use the WBS more often or less
Number of
often in the next 3-5 years?
Responses
More often
147

17

Response
Ratio
40%
51%
7%
3%
0%
100%
Response
Ratio
77%
79%
43%
Response
Ratio
78%
85%
38%
Response
Ratio
74%
76%
30%
22%
Response
Ratio
62%

As often
Less often

88
37%
4
2%
Total
239
100%
11. What component(s) of the WBS has changed the most over the last 5 years?
1
The use of the WBS as a cost accounting tool.
2
As clients & co-workers in the US begin to understand what "management by
deliverables", they are better able to comprehend making the WBS deliverable based.
3
WBS by Phase
4
equipment and hardware human resourcing
5
definition and guidance
6
Greater Number of levels
7
The relation Work Package versus Activity
8
This has become more extensive and better defined
9
Standards for usage
10
The focus has really shifted from activity-based to deliverables-based. I think there's
more acceptance for the need for the WBS to be more fluid so that it can adapt to the
needs of the project, rather than rigidly structured to force the project into a specific
structure.
11
level of detail
12
Definition of work packages for vendors is now far more detailed.
13
When we first started using WBS, it was merely to map out and monitor schedules and
some scope; now we use it as an integrated tool to monitor cost, schedule, and scope.
This year we have begun to use the WBS for planning risk.
14
Contractor WBS going down two more levels
15
1) WBS Dictionary 2) Work Packages
16
Level of detail, reflecting the whole complexity
17
Availability of more "standard" WBS's for specific project lifecycles has increased
18
None as far as I know
19
Inclusion of "soft" activities such as public consultation
20
For myself, none. I may be considered "old school," but I still use a WBS as I learned to
use the WBS 20+ years ago and have not read or been introduced to anything that
indicates a "better" usage that what I learned.
21
Our company adapted the WBS usage policy in 2004 as our corporate standard for
project initiation so we don't have much to compare to.
22
no significant change
23
I have just started using this concept.
24
More awareness by participants More templates and standards
25
Level of decomposition
26
Linkages with other systems
27
shifted more from action's to milestones
28
Less focus on risk around deliverables, but more focus on what the actual deliverable
should be.
29
Introduction of activities, to which I totally disagree. WBS should be defined as in the
MIL-HDBK-881A standard
30
level of detail of the work package
31
Constant battle between functional, organizational, & product partitioning - multi-view
environments are now more effective in sophisticated activity network tools.
32
Alignment to Product Breakdown Structures
33
Definition about what should be included/excluded...accounting for 100% of the work
34
WBS has become more integral to overall schedule / cost planning of projects.
35
Level of detail has increased. Importance of WBS throughout entire planning and
execution of project.
36
Scope - inclusions, activity definitions - modifications
37
Cost estimation

18

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

Scope. Resource allocation.


Work Package
we focus on the WBS being deliverable-oriented
The components haven't changed, but the level of detail for each activity has increased.
Development of WBS templates to support a product development methodology
For me, not much. But I've notice more people using quality gates or entrance and exit
criteria before going from one phase to another
Managing organizational change and stakeholder communication
I find that the company I work for defines much of how the WBS is used.
Components have not changed as much as our approach/application/use of the WBS.
Previously viewed more as an activity list.
I am not aware as I have recently become a PMP
I am not aware of changes to the WBS definition. I am becoming more skilled in creating
and using the WBS.
Estimating time (Duration vs. Effort).
Introduction of a generic project life cycle on top of the traditional PBS (product
breakdown structure)
The team builds and agrees on WBS and estimates before the Plan is finalized. And as
life changes, sometimes WBS needs to change so the WBS and the Plan most be
evolutionary to the Times. The Team must agree and be part of the evolution.
The injection of time phasing
The project scope management plan
did not start using it until 2005
Project Management
On entry level: deliverables acceptance and its breakdown. On level 2-5: various
elements in cost/finance, HR, procurement, quality, risk, value, and communication
aspect.
level of detail is increasing
Not sure but I know that WBS needs to be explained in more simple terms using
examples. People tend to do a detailed WBS down to the individual tasks and it is not
meant for this. I was once faced with WBS elements of less than 5 hours!!!! Yes, it was
a MASSSIVE WBS. I trimmed it generously.
level of detail required in WBS...now going down to 7+ levels
Cost account
Resource Leveling
Degree of complexity
split task
The Structure of WBS.
attempts to use WBS for risk management planning and cost estimation, rather than
only resources and task planning
The standard to use the WBS
Usability of software tools.
Calculating float and earned value
level of details, input to scheduling and project control tools
down time
Using the WBS as a basis of estimates
The development and integration of a distinct WBS for "project management
deliverables" and one for "product lifecycle deliverables"
The number of levels used. Currently use more levels now than in the past.
Deliverables
None, it's only been around a year or two.
Don't see
planning concepts
Management reviewing and understanding them has increased

19

79

Work Package assignment and modification. Email notification to management when


Work Package SLAs are not in compliance.
80
Define Scope as clear as possible and as detail as possible
81
Definition of deliverables vs. standard activities on the project. It has been difficult to
separate PM/Product Development process activities (methodology) from actual project
deliverables sometimes.
82
Using a product breakdown structure orthogonal to the WBS.
83
WBS should be tailored to suit every project - not be an organization standard
84
I usually do a matrix type WBS and then add columns for cost, duration, personnel
resources assigned, tools required etc. This way I get a complete matrix of all the
needed information for the specific task.
85
less waterfall and more overlapping
86
I don't think the WBS has changed at all, but if you mean our understanding of it, then
I'd say "inclusion of project management deliverables and tasks."
87
Definition at level 6
88
Concept of work packages
89
Peoples knowledge and ability to use the wbs but there hasnt been much
improvement. in general people are ignorant of how and why to use any BS
90
focus on deliverables vs. tasks
91
WBS Level
92
The standard has helped clarify it is deliverables oriented.
93
Lack of detail necessary to plan properly.
94
The WBS dictionary, this has become vital in "What is in Scope" vs. "Out of Scope".
Without the dictionary, projects with longer periods of performance become problematic.
95
Scope Definitions have become more details to increase understand of task & during
shorter (i.e. a day or less)
96
the focus on the activities - work elements - and less on schedule time and duration
12. Which component(s) should be updated in the next 5 years?
1
Quality standards for the WBS; Better integration between the WBS & related PM
components (scheduling, risk management, EVM, etc.)
2
equipment and hardware human resourcing
3
assessment ability
4
The interrelation between Work Package and Quality, Communication and Risk
Management
5
Methods defined in WBS can be refined
6
creation of a standard WBS for our company so that cross-project activities can be
reported
7
Cost, and risk identification and mitigation. How to use the WBS as a tool as a
communications tool and how to report on performance of WBS.
8
the Macro vision
9
1) Control Accounts
10
More clarity in the relationship of the "deliverable" to the activities.
Refinement/documentation of the processes to 1) identify all deliverables and 2) to drive
down to the activity level from the deliverable. Best practice for incorporating PM
lifecycle in to the project lifecycle and representing PM deliverables in the WBS
11
I'm not sure, I think its emphasis in deliverables and then in activities should be stressed
12
Better tools to incorporate into other elements integrated with cost and schedules etc...
13
Client awareness
14
template availability
15
Cost/effort reporting tools using the WBS entries as key accounts
16
Integration of WBS components, phase versus product WBS alignment. Importance of
WBS as a comprehensive planning tool.
17
The WBS should be based on tangible products and services as defined by the MILHDBK-881A standard. Please keep activities out of WBS.

20

18
19
20
21
22
23
24
25
26
27
28
29
30
31

32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

48
49

Emphasis on levels of integration and how they play across the project lifecycle;
formalizing a multi-view partitioning at third(?) level of WBS to minimize complexity of
artificially creating lower levels to satisfy different management views.
Costing
Using WBS more consistently. Establishing schedule based on WBS, as Primavara
software requires.
As indicated in 11
Risk management
Activity and Scope.
WBS Dictionary
More examples. Incorporate information from "Effective Work Breakdown Structures" -best book I know on the topic.
improved integration with project schedule development and risk management
1) Benefit realization planning 2)External dependencies/inputs
PMI needs to recognize how the business (non-PMP's and non-PM's) affects the WBS
and what they expect from it. It's not just a tool for the PM, but can also serve as a tool
for the business owners, if presented in the proper manner.
Tying the WBS for projects to WBS for programs and portfolios. How to tie an
organizations portfolios/programs/projects together through the use of the WBS
Measurement
Integration of how to integrate (dovetail) the PBS into the Project life cycle (phased) in
order to become a WBS that comprises ail deliverables to be done. This means
deliverables from the product oriented processes as well as the deliverables from the
project management processes
The team builds and agrees on WBS and estimates before the Plan is finalized. And as
life changes, sometimes WBS needs to change so the WBS and the Plan most be
evolutionary to the Times. The Team must agree and be part of the evolution.
The injection of time phasing. The WBS is used too much as a "scheduling" tool. We
need to go back to basics and use it only for the breakdown of work. The WBS is not
well suited for phasing (scheduling) work.
WBS dictionary
Risk Management
Depends on the applicable solution and customer requirements.
WBS dictionary components and linkage to WBS
WBS is not well understood. Use modern terms? Use more graphics? Use various types
of examples to explain? Sell the usefulness of it? Simple is better.
Dictionary information to accompany the WBS, it is difficult by a 'title' to understand what
was the intended scope of that item - different people interpret the WBS title differently
Numbering of the Project itself. 1.0 is a non-sense. It should read "1". In a series of
books, the first one is "Volume 1", not "Volume 1.0"...
Concurrent tracking
Need models for varying types of standard projects.
The Structure of WBS.
perhaps an inclusion of its practical use for small projects ("simple WBS") rather than
the current complex, large project focus only
development
Standards for WBS development.
Break down of time. What I mean specifically, when assigning a resource the
assumption is that anyone assigned a task that takes a total of 10 days, is 100%
committed to the task. What needs to be investigated further is that the same task may
take 10 days, but the resource only needs to be committed to a 20% time commitment
due to other projects' demands.
setting time
Standardize across industry or specific function (i.e.) software development

21

50

51
52
53
54

55
56

57
58

59
60
61
62
63
64
65
66
67

The sections that address sequencing deliverables, especially when one deliverable
serves as input to deliverables in more than one later phases of the project. For
example. One deliverable might be a "technical requirements" document. It is the input
to a deliverable called "technical design" in the design phase and to the "Test Plan"
deliverable in testing phase AND to the "Deployment Plan" in the Deployment phase. In
this example, the Requirements acts as input to Planning deliverables, possible to the
sub WBS for Testing and Deployment and the critical path of the Design deliverable.
Although this may vary by discipline, it creates several issues with traceability, change
management, resource leveling, and in what phase to place the planning deliverable for
a specific phase (Do you wait to the testing phase to create the Test Plan?, not without
creating artificial slack).
Rolled out to more of the organization, make versions specific to different organizations.
Resource
operation results
Team utilization. I find that as the PM, I am the primary creator and user. Having
technically competent team members creating a WBS can be difficult. Often times, I
lead them through the exercise by either creating the WBS and having them review it
and update it or step them through the creation process by "white boarding" the
activities necessary to complete the overall task
Visual display of the WBS. Report and query generation for upper management.
Lack of understanding as a general business planning and reporting tool Management
stipulations that Reports be made at particular WBS level - showing a lack of knowledge
of what the WBS is for Integration of Code of accounts into cost accounts The most
important thing that can come out of the new WBS is a common standardization of
terms for work, activity, task, work package, process, etc. And the Hierarchy order of
how these terms interact - the definition of the Taxonomy. Scheduling Tools use Task
and Activity interchangeably and this is confusing to general business managers
include cost estimating and resource planning while doing the WBS
A more simple way to input/organize WBS elements into a computer format without
going to the detail of MS Project tasks. A simple way to identify "typical" deliverables as
a form of checklist to ensure the creation of the WBS addresses all the relevant
concerns of a particular industry or project type.
As above - WBS is an individualized tool for individual projects. It can only be templated
for those projects that are becoming processes where the tasks are standardized
I don't really have an opinion. I modify it as I need to to meet my needs.
We have to admit that technology has an impact on how we manage. Thus, we should
not be afraid to let concepts, stemming from the use of project management scheduling
software, impact the development of the standard.
All strategic levels after maturation
Work packages terminology should be deleted and the lowest level of the WBS be
called Activities.
education on how to use the BS
Clarify the last, lowest level, work package.
The integration of the WBS within the project management framework of the company.
There should be something in the WBS that reflects the negotiation process. In other
words sometimes during negotiations the Program Manager will have to make a
concession or take something for less than estimated. This should be reflected in the
WBS rather than just the cost negotiated. Just because you negotiate work it doesn't
mean the work goes away, it just becomes more of a risk. This is the area we are the
least effective in putting in the WBS, those areas of risk that we create ourselves based
on negotiations.

22

PMI's Practice Standard for Work Breakdown Structures


13. Have you read the PMI's Practice Standard for Work
Breakdown Structures?
Yes
No
Not sure

Number of
Response
Responses
Ratio
141
59%
88
37%
10
4%
Total
239
100%
14. Have you used the PMI's Practice Standard for Work
Number of
Response
Breakdown Structures?
Responses
Ratio
Yes
45%
107
No
107
45%
Not sure
26
11%
Total
240
100%
15. Please rate your level of agreement with the following statements regarding PMI's
Practice Standard for Work Breakdown Structures:
The top percentage indicates total
respondent ratio; the bottom
number represents actual number
of respondents selecting the option

1
Strongly
Agree

2
Somewhat
Agree

3
Neither
agree nor
disagree

4
Disagree

1. I find the framework of the


21%
38%
34%
5%
Practice Standard for Work
40
72
64
10
Breakdown structures easy to
follow.
2. I find the framework of the
21%
36%
34%
8%
Practice Standard for Work
39
66
63
14
Breakdown structures to be very
useful.
16. Please rate the usefulness of each of the following content areas/features.
The top percentage indicates total
respondent ratio; the bottom
number represents actual number
of respondents selecting the option

1
Very useful

2
Somewhat useful

5
Strongly
disagree

1%
2
2%
3

3
Not at all useful

58%
41%
1%
95
68
2
52%
45%
3%
2. Terminology
86
75
5
38%
54%
7%
3. Level of details
63
89
12
39%
50%
11%
4. Resource planning
64
82
18
34%
56%
10%
5. Cost estimating, cost budgeting
57
93
16
36%
50%
14%
6. Risk management
59
81
23
7. Scope planning and scope
57%
39%
5%
definition
95
65
8
17. What in the current Practice Standard is unclear and should be clarified or explained
further in the next edition?
1
Need more examples of high-quality WBS construction
2
Items not related to the WBS (e.g. scheduling issues, activity planning); WBS Quality
3
Level of Effort elements. Relation between WBS elements (nouns) and project
activities (verbs).
4
Risk Management
5
The issue hasn't been clarity in my experience so much as the individual nuances of a
given client site.
1. Framework

23

6
7
8
9
10

11
12

13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
35
36
37
38
39
40

That there must be at least two children to a parent


The level of classification for the cost estimating.
Provide charts showing the hierarchies of the examples in appendices.
The WBS examples should be progressively done, by steps (as PM phases).
Off hand, cannot say. It should be printable from the web-site. I just ordered the bound
copy, but I suspect most people will not take the time to order it and will not want to
continuously have to pull up the .PDF off the website to refer to it. If you want it to be
widely adopted and used, you need to make it more accessible to practitioners. I didn't
even know it existed until I got this survey.
The entire treatment is too verbose for the high level of information covered. Should
be able to trim it down to something more manageable, say 30-35 pages.
Level of detail - provides examples of how to decompose and to what level. Resource
Planning - how to level resources Cost estimating and cost budgeting - the difference
between estimating and budgeting should be made clearer Risk management - this
remains a new area for many of us and the example does not provide sufficient
clarification Scope planning and scope definition - many persons in my field
(international development) need a clearer understanding of scope definition
Information technology projects should needs more attention.
Examples are not necessarily consistent with the practice standard. Better examples
could be found.
Relationship with other standards such as PMBOK(r) Guide, OPM3(r), etc...
What components must be apart of a WBS, i.e. resource skills, risk magnitude,
deliverable description, level of detail required to properly management project
That the scope can be decomposed into work packages in many different ways (by
function, by project phase, by deliverable, etc.) and that whatever method is chosen,
the work packages should be the identical.
There should be a direct comparison to Mil-Std-881 (maybe reserved for a DoD
appendix, like with the PMBOK Guide?). Necessary levels and recommendations on
multi-view partitioning at some level.
I like to see examples.
Procedures to structure tasks and activities, project process-wise or product processwise?
Risk Management
Terminology and its derivatives could be more lucid.
Level of details
Everything. I found it almost completely useless. Look at "Effective WBS" by Haugan
for an example of what this document should have been.
Please Please Please clearly distinguish between a WBS and a project work plan.
Many project managers are using the terms interchangeably.
A period of exposure and use is needed to determine this answer
building a WBS and standardizing the levels
A clear delineation between projects' life cycles and/or products/deliverables.
PBS versus PLC versus total WBS (the dovetailing process)
Take it from a standard to How to guide.
Using the WBS, the resource planning seems to be more clarified
If the WBS should contain verbs or substantives
1. Applicable input & follow up after WBS (benchmark to PMBOK 3rd Edition where
flow chart is provided to understand the whole picture).
Rules of thumb for decomposing.
Resource planning
downtime
estimating resources and costs, scope
Risk management
Clarify the use of the terms activities, deliverables, tasks and phases

24

41

Personally, I do not like the fact that control account (CA) is above the WBS element. I
work with a CA under the lowest level element (not a work package) and have them
intersect with the OBS.
42
I THOUGHT THE STANDARD NEED MORE DETAIL TO EXPLAIN CONCEPTS AND
BE USEFUL DIAGRAMS.
43
Resource planning and cost estimating & budgeting
44
Too often, the PM framework and the actual WBS are interwoven in the WBS OR the
PM framework is not included at all.
45
Defining the relationship between Project Risk and the WBS.
46
The relation of the WBS with other knowledge areas and EVM.
47
the Hierarchy of terms Taxonomy of terms
48
Cost estimating
49
The scope of wbs: deliverables, tasks or both.
50
WBS is the ultimate scope definition tool and is central to all aspects and functions of
managing a project. The standard should address structure and format of WBS not
content
51
PMBOK 2000 presented the project management processes within a phase; some
people think that phases can only happen one after the other; some think only big
projects, like sending a man to the moon, has phases; some complain that using
initiation, planning, monitoring & controlling, and executing PM documentation,
through every phase would just be too cumbersome. Somehow, maybe some case
studies could show how some managers might be more informal than others,
requiring less structured, but equally important, communication to convey that tasks
and minor deliverables are getting done.
52
The definition of work packages
53
The whole volume is extremely poor.
18. In your opinion, what enhancements should be made to the Practice Standard for
Work Breakdown Structures?
1
Job-aids, templates, cases need to be added and more guidance about how to
construct quality WBSs
2
Definition of WBS Quality Better focus on WBS specific elements
3
More graphics. How to customize WBS to particular projects or applications that may
have special needs.
4
Less terminology
5
Since my experience is limited to IT systems, my opinion would tend to be slanted. My
suggestion would be to develop enhancements that could be applied as generically as
would be practical.
6
Indicate that indenting is NOT WBS, i.e. the format as used by Microsoft Project. The
WBS is not
7
PMI has to give more attention to the PM part of WBS. Product is very simple. The
problem and the important thing is just the PM side of WBS activities. It should also be
pointed that Quality, Risk and Communication Activities has to be put straight into the
WBS map. With examples
8
This should cover to take care of various changes from the Customer end and how to
tackle it
9
Industry examples, templates. For instance, IT, construction, manufacturing, etc. The
bicycle example is great for getting general concepts across to all learners, but you
also need to target ways to use WBS in the various disciplines so they feel more
comfortable with applying it.
10
more examples from outside of the traditional engineering, IT type industries
11
Ensuring people understand that Outlining is not WBS
12
An Arabic Version with simple and easy terminology
13
Explanation of working examples of projects in WBS standard will certainly help.

25

14

15
16
17
18
19

20
21
22
23
24
25
26
27
28

29
30
31
32
33
34

35
36
37
38
39
40
41
42
43

Describe the development of a WBS with a team. Recommend standard labeling of


WBS levels - show how different labels can describe the same deliverable conveying
different levels of understanding. For example - "Environmental Impact" vs.
"Environmental Impact Report for Tower siting".
It should include a How to section, with practical recommendations of use.
Produce real examples from projects and show level of breakdown required for a
deliverable.
The link (roll wave planning) between Scope, Time, cost, risk and quality.
Which is the best practice, phase alignment or product alignment of top level WBS
There is some controversy in the field as to whether the elements of a WBS ought to
have a standard format of verb-noun ("Test Software") or noun ("Software Test").
Whether there ought to be a standard at all ought to be addressed, as well as my
belief that whatever method is chosen, it ought to be consistent across the WBS at a
given tier.
Please leave out the idea of using project phases for the second level.
There should be a direct comparison to Mil-Std-881 (maybe reserved for a DoD
appendix, like with the PMBOK Guide?). Necessary levels and recommendations on
multi-view partitioning at some level.
Please put in examples
Level-wise procedures to structure tasks, activities, work package. Definition of tasks,
activities and work packages.
Standard templates
More information on Cost budgeting.
Should have more models
Practical tips for how to work with teams to develop the WBS. Examples of WBS docs
as they take shape. Lots of examples of real WBS documents.
Distinguish between a WBS and a project work plan. The level of detail required to
fully estimate a project (6 or more levels) vs. the level of detail to track a project (3 or
4 levels). Develop a WBS structure or template that complies with the Project
Management Lifecycle: Initiating, Planning, Executing, Controlling, Closing.
A period of exposure and use is needed to determine this answer
More realism based on actual large scale complex projects
providing a 6 level standard
A position on WBS as either a life cycle of the project OR a product/deliverable
oriented breakdown of a project
Reporting and Resources
The Project Team builds and agrees on WBS and estimates before the Plan is
finalized or brought to management for time & $$. And as life changes, sometimes
WBS needs to change so the WBS and the Plan most be evolutionary to the rimes.
The Team must agree and be part of the evolution.
Examples are great!
I believe the use of the WBS for things other than scope planning and definition is not
good.
Create and develop more levels of SOW and Work Package
More examples
More WBS templates in Telecommunication, On-shore/offshore oil & gas projects,
Process/System Development Projects
Make sure it is simple and not full of jargon that a world-wide audience from various
industries will not necessarily interpret the same way. It is really useful. It just needs to
be sold as such.
Benchmarking for different industries and different types of projects.
I was unaware that PMI had published a separate practice standard for WBS. My
WBS usage has been based on the PMBOK and various PM publications, other than
PMI.
implement robots

26

44
45

46
47
48
49
50
51
52
53

54
55
56
57

more specific examples by industry or functional area include more about estimating
Developing a structure to plan and sequence more effectively. The use of network
diagrams, etc. not realistic. Maybe product specific list of minimum set of deliverables
with sequence. i.e. business application software, web product, pharmaceutical,
building. Also, by sub discipline Requirements, Design, construction, testing,
deployment.
THE WBS IS A BASIC TOOL FOR PLANNING AND CONTROL
Should include more examples related to IT development projects
I would like to see the standard include the SDLC and PM frameworks interwoven and
identified as such.
Providing many examples of "real world" WBS in varied industries.
Include the EVM practice to WBS practice.
the Hierarchy of terms Taxonomy of terms
Relate to scope change control
Stop trying to portray WBS as a process description tool. It needs to be shown as the
ultimate scoping tool which describes the work of the project and is almost always
unique to a given project. The skill in WBS formulation is in the prediction at a detail
level of the work required to achieve a prescribed result. Efficiency and effectiveness
in work and job design are key knowledge elements
Again, how do the PM processes work in the background to get the scope done?
Identify lowest level of the WBS as Activities.
re-write it using someone who actually gets good mileage out of scope definition from
product breakdown to organization/ cost/ risk/ phase/ breakdowns and is competent to
actually describe how they do it
Make it clear that the verbiage should be for Deliverables and the WBS should have a
dictionary.

Background Information
19. In which country/state do you currently Reside (Country/State):

Africa

Camaroon

Victoria (2)
South Australia

Ontario (7)
British Columbia
New Brunswick
Quebec

Latvian Republic

Argentina
Australia (2)
Belgium
Brazil (3)
Parana
Minas Gerais
Sao Paulo (2)
Canada (4)

Eastern Europe
England
Egypt
France (4)
Germany (2)

27

India (7)

Bangalore (2)

Mexico City (2)

Nuevo Len

Wellington

Islamabad

Costa Rica

Barcelona

Sharjah

Leicestershire

Alabama (2)
Arizona (3)
Arkansas
California (12)
Colorado (3)
Connecticut (3)
Florida (4)
Georgia (4)
Idaho (2)
Illinois (6)
Iowa
Kansas
Kentucky (2)
Maryland (2)
Massachusetts (5)
Michigan (9)
Minnesota (4)

Gujarat (2)
Maharastra (4)
Mumbai (2)
New Delhi
Tamil Nadu (3)

Indonesia
Jakarta
Italy
Japan
Kuwait (2)
Mexico (2)
Monterrey
Nepal
Netherlands
New Mexico
Albuquerque
New Zealand (3)
Nigeria
Pakistan
Puerto Rico
Saint Lucia
San Jose
Scotland
Singapore (2)
Spain (1)
United Arab Emirates (1)
United Kingdom (5)
Hampshire

USA (3)

28

Nebraska (2)
New Hampshire (3)
New Jersey (6)
Nevada (2)
New York (5)
North Carolina (2)
Ohio (3)
Oklahoma
Oregon (2)
Pennsylvania (6)
South Carolina (2)
Tennessee
Texas (11)
Utah
Virginia (8)
Washington
Wisconsin (2)

Anzoategui

**US-II
Venezuela (1)
20. What is the primary industry focus of the company you
work for?
I am currently unemployed or retired
Aerospace
Business services (advertising, marketing, staffing, etc.)
Construction
Consulting
Engineering
Financial Services
Food and Beverage
Government
Healthcare
Information Technology
Insurance
Legal
Manufacturing
Pharmaceuticals
Real Estate
Resources (Agriculture, Mining, Coal, Gas, Oil)
Telecommunications
Training/education
Transportation
Utility
Other (Please specify):
Biotechnology
Project Management
PMI Chapter
International Development
I am a Project Director and work in all industries
Retail
PMI Chapter
Defense Contractor
Manufacturer of Printing and Packaging
Supply Chains & 3rd party logistics
Internet Services
Rail Signaling

29

Number of
Responses
2
11
3
12
48
22
24
1
21
12
75
9
0
12
6
2
2
15
12
8
4

25

Response
Ratio
1%
5%
1%
5%
20%
9%
10%
0%
9%
5%
32%
4%
0%
5%
3%
1%
1%
6%
5%
3%
2%

11%

Publishing
Retail/Wholesale
Energy
Defense
Marketing
Non-Profit Political Think-tank
Power Researching
Utility
Media Advertising
ERP Development
Home Entertainment Media Provider
Oil & Gas Exploration
Education
21. Please select the title/position that best describes your
role within your company:
CEO/President
CIO/Chief Technology Officer
Vice-President
Director, Project/Program Management
Director of Project Management Office (PMO)
Portfolio Manager
Program Manager
Senior Project Manager
Project Manager
Project Team Leader
Project Management Consultant/Advisor
Professor/ Educator
Researcher
Trainer
Other, Please specify:
Programmer
Sr. Business Analyst
IT Manager
Marketing Manager
Principle
Cost Schedule Manager
PMI Manager
Business Analyst
Program Planning & Controls Specialist
Manager, Project Management Office
Project Control Analyst/EVMS
Project Admin
Project Controls Manager
Engineering Planner
Planner
Business Financial Manager
Admissions Director, MBA Program
Sales
22. Are you a PMP?
Yes
No
Total

30

Number of
Responses
12
3
4
19
14
4
36
51
51
26
25
4
5
5

18

Number of
Responses
152
80
232

Response
Ratio
5%
1%
2%
8%
6%
2%
15%
22%
22%
11%
11%
2%
2%
2%

8%

Response
Ratio
66%
34%
100%

23. How many years in total have you worked in project


management? Please round up to the nearest year.
3 years or less
4-5 years
6-10 years
11-15 years
16-20 years
21 years or more
24. Does your organization have a Project Management
Office (PMO)?
Yes
No
Total
25. Annual revenue of your organization:
Less $50 million (US)
$50 to $250 million (US)
$250 million to $1 billion (US)
$1 billion + (US)
Total

31

Number of
Responses
17
37
80
50
27
26
Number of
Responses

Response
Ratio
7%
16%
34%
21%
11%
11%
Response
Ratio

123
112
235
Number of
Responses
75
42
36
75
228

52%
48%
100%
Response
Ratio
33%
18%
16%
33%
100%