Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

5.4 Create WBS: Figure 5-9 Figure 5-10

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 9

5.

4 Create WBS
Create WBS is the process of subdividing project deliverables and project
work into smaller, more manageable components. The key benefit of this
process is that it provides a structured vision of what has to be delivered.
The inputs, tools and techniques, and outputs of this process are depicted
in Figure 5-9. Figure 5-10 depicts the data flow diagram of the process.
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.

A WBS structure may be created through various approaches. Some of the


popular methods include the top-down 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.
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:
o Code of account identifier,
o Description of work,
o Assumptions and constraints,
o Responsible organization,
o Schedule milestones,
o Associated schedule activities,
o Resources required,
o Cost estimates,
o Quality requirements,
o Acceptance criteria,
o Technical references, and
o 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.

You might also like