WBS

The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project
team to accomplish the project objectives and create the required deliverables. The WBS organizes
and defines the total scope of the project, and represents the work specified in the current approved
project scope statement.

The planned work is contained within the lowest level of WBS components, which are called work
packages. A work package can be used to group the activities where work is scheduled and
estimated, monitored, and controlled. In the context of the WBS, work refers to work products or
deliverables that are the result of activity and not to the activity itself.

5.4.1 create WBS: Inputs

5.4.1.1 Scope Management Plan
Described in Section 5.1.3.1. The scope management plan specifies how to create the WBS from the
detailed project scope statement and how the WBS will be maintained and approved.

5.4.1.2 Project Scope Statement

Described in Section 5.3.3.1. The project scope statement describes the work that will be performed
and the work that is excluded. It also lists and describes the specific internal or external restrictions
or limitations that may affect the execution of the project.

5.4.1.3 requirements documentation

Described in Section 5.2.3.1. Detailed requirements documentation is essential for understanding
what needs to be produced as the result of the project and what needs to be done to deliver the
project and its final products.

5.4.1.4 Enterprise Environmental Factors

Described in Section 2.1.5. Industry-specific WBS standards, relevant to the nature of the project,
may serve as external reference sources for creation of the WBS. For example, engineering projects
may reference ISO/IEC 15288 on Systems Engineering – System Life Cycle Processes [6], to create a
WBS for a new project.

5.4.1.5 organizational Process Assets

Described in Section 2.1.4. The organizational process assets that can influence the Create WBS
process include, but are not limited to:

•Policies, procedures, and templates for the WBS;

•Project files from previous projects; and

•Lessons learned from previous projects.

5.4.2 create WBS: tools and techniques

5.4.2.1 decomposition
Decomposition is a technique used for dividing and subdividing the project scope and project
deliverables into smaller, more manageable parts. The work package is the work defined at the
lowest level of the WBS for which cost and duration can be estimated and managed. The level of
decomposition is often guided by the degree of control needed to effectively manage the project.
The level of detail for work packages will vary with the size and complexity of the project.
Decomposition of the total project work into work packages generally involves the following
activities:

•Identifying and analyzing the deliverables and related work;

•Structuring and organizing the WBS;

•Decomposing the upper WBS levels into lower-level detailed components;

•Developing and assigning identification codes to the WBS components; and

•Verifying that the degree of decomposition of the deliverables is appropriate. A portion of a WBS
with some branches of the WBS decomposed down through the work package level is shown in
Figure 5-11.

5.4.2.2 Expert Judgment

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

Figure 5-11
Figure 5-11. Sample WBS decomposed down through Work Packages
A WBS structure may be created through various approaches. Some of the popular methods include
the topdown approach, the use of organization-specific guidelines, and the use of WBS templates. A
bottom-up approach can be used during the integration of subcomponents. The WBS structure can
be represented in a number of forms, such as:

•Using phases of the project life cycle as the second level of decomposition, with the product and
project deliverables inserted at the third level, as shown in Figure 5-12;

•Using major deliverables as the second level of decomposition, as shown in Figure 5-13; and

•Incorporating subcomponents which may be developed by organizations outside the project team,
such as contracted work. The seller then develops the supporting contract WBS as part of the
contracted work.
Figure 5-12

Figure 5-13

Decomposition of the upper-level WBS components requires subdividing the work for each of the
deliverables or subcomponents into its most fundamental elements, where the WBS components
represent verifiable products, services, or results. The WBS may be structured as an outline, an
organizational chart, or other method that identifies a hierarchical breakdown. Verifying the
correctness of the decomposition requires determining that the lower-level WBS components are
those that are necessary and sufficient for completion of the corresponding higher-level
deliverables. Different deliverables can have different levels of decomposition. To arrive at a work
package, the work for some deliverables needs to be decomposed only to the next level, while
others need additional levels of decomposition. As the work is decomposed to greater levels of
detail, the ability to plan, manage, and control the work is enhanced. However, excessive
decomposition can lead to nonproductive management effort, inefficient use of resources,
decreased efficiency in performing the work, and difficulty aggregating data over different levels of
the WBS.

Decomposition may not be possible for a deliverable or subcomponent that will be accomplished far
into the future. The project management team usually waits until the deliverable or subcomponent
is agreed on, so the details of the WBS can be developed. This technique is sometimes referred to as
rolling wave planning.

The WBS represents all product and project work, including the project management work. The total
of the work at the lowest levels should roll up to the higher levels so that nothing is left out and no
extra work is performed. This is sometimes called the 100 percent rule.

For specific information regarding the WBS, refer to the Practice Standard for Work Breakdown
Structures – Second Edition [7]. This standard contains industry-specific examples of WBS templates
that can be tailored to specific projects in a particular application area.

5.4.3 create WBS: outputs

5.4.3.1 Scope Baseline
The scope baseline is the approved version of a scope statement, work breakdown structure (WBS),
and its associated WBS dictionary, that can be changed only through formal change control
procedures and is used as a basis for comparison. It is a component of the project management plan.
Components of the scope baseline include:

•Project scope statement. The project scope statement includes the description of the project
scope, major deliverables, assumptions, and constraints.

• WBS. The WBS is a hierarchical decomposition of the total scope of work to be carried out
by the project team to accomplish the project objectives and create the required deliverables. Each
descending level of the WBS represents an increasingly detailed definition of the project work. The
WBS is finalized by assigning each work package to a control account and establishing a unique
identifier for that work package from a code of accounts. These identifiers provide a structure for
hierarchical summation of costs, schedule, and resource information. A control account is a
management control point where scope, budget, actual cost, and schedule are integrated and
compared to the earned value for performance measurement. Control accounts are placed at
selected management points in the WBS. Each control account may include one or more work
packages, but each of the work packages should be associated with only one control account. A
control account may include one or more planning packages. A planning package is a work
breakdown structure component below the control account with known work content but without
detailed schedule activities.

• WBS dictionary. The WBS dictionary is a document that provides detailed deliverable, activity,
and scheduling information about each component in the WBS. The WBS dictionary is a document
that supports the WBS. Information in the WBS dictionary may include, but is not limited to:

○ Code of account identifier,

○ Description of work,

○ Assumptions and constraints,

○ Responsible organization,

○ Schedule milestones,

○ Associated schedule activities,

○ Resources required,

○ Cost estimates,

○ Quality requirements,

○ Acceptance criteria,

○ Technical references, and

○ Agreement information.

5.4.3.2 Project documents updates

Project documents that may be updated include, but are not limited to, requirements
documentation, which may need to be updated to include approved changes. If approved change
requests result from the Create WBS process, then the requirements documentation may need to be
updated to include approved changes.

2.1.3 organizational Structures

Organizational structure is an enterprise environmental factor, which can affect the availability of
resources and influence how projects are conducted (see also Section 2.1.5). Organizational
structures range from functional to projectized, with a variety of matrix structures in between. Table
2-1 shows key project-related characteristics of the major types of organizational structures.

Matrix organizations, as shown in Figures 2-2 through 2-4, reflect a blend of functional and
projectized characteristics. Matrix organizations can be classified as weak, balanced, or strong
depending on the relative level of power and influence between functional and project managers.
Weak matrix organizations maintain many of the characteristics of a functional organization, and the
role of the project manager is more of a coordinator or expediter. A project expediter works as staff
assistant and communications coordinator. The expediter cannot personally make or enforce
decisions. Project coordinators have power to make some decisions, have some authority, and
report to a higher-level manager. Strong matrix organizations have many of the characteristics of the
projectized organization, and have full-time project managers with considerable authority and full-
time project administrative staff. While the balanced matrix organization recognizes the need for a
project manager, it does not provide the project manager with the full authority over the project
and project funding. Table 2-1 provides additional details of the various matrix organizational
structures.
At the opposite end of the spectrum to the functional organization is the projectized organization,
shown in Figure 2-5. In a projectized organization, team members are often colocated. Most of the
organization’s resources are involved in project work, and project managers have a great deal of
independence and authority. Virtual collaboration techniques are often used to accomplish the
benefits of colocated teams. Projectized organizations often have organizational units called
departments, but they can either report directly to the project manager or provide support services
to the various projects.
Many organizations involve all these structures at various levels, often referred to as a composite
organization, as shown in Figure 2-6. For example, even a fundamentally functional organization may
create a special project team to handle a critical project. Such a team may have many of the
characteristics of a project team in a projectized organization. The team may include full-time staff
from different functional departments, may develop its own set of operating procedures, and may
even operate outside of the standard, formalized reporting structure during the project. Also, an
organization may manage most of its projects in a strong matrix, but allow small projects to be
managed by functional departments.

Many organizational structures include strategic, middle management, and operational levels. The
project manager may interact with all three levels depending on factors such as:

•Strategic importance of the project,

•Capacity of stakeholders to exert influence on the project,

•Degree of project management maturity,

•Project management systems, and

•Organizational communications. This interaction determines project characteristics such as:

•Project manager’s level of authority,

•Resource availability and management,

•Entity controlling the project budget,

•Project manager’s role, and

•Project team composition.