THE PROJECT MANAGEMENT KNOWLEDGE AREAS
12. Project Procurement Management
5.3 SCOPE DEFINITION
Scope definition involves subdividing the major project deliverables (as identi- fied in the scope statement as defined in Section 5.2.3.1) into smaller, more man- ageable components to:
■ Improve the accuracy of cost, duration, and resource estimates.
■ Define a baseline for performance measurement and control.
■ Facilitate clear responsibility assignments.
Proper scope definition is critical to project success. “When there is poor scope definition, final project costs can be expected to be higher because of the inevitable changes which disrupt project rhythm, cause rework, increase project time, and lower the productivity and morale of the workforce” (3).
5.3.1 Inputs to Scope Definition
.1 Scope statement. The scope statement is described in Section 5.2.3.1.
.2 Constraints. Constraints are described in Section 5.1.3.3. When a project is done under contract, the constraints defined by contractual provisions are often impor- tant considerations during scope definition.
.3 Assumptions. Assumptions are described in Section 4.1.1.5.
.4 Other planning outputs. The outputs of the processes in other knowledge areas should be reviewed for possible impact on project scope definition.
.5 Historical information. Historical information about previous projects should be considered during scope definition. Information about errors and omissions on previous projects should be especially useful.
5.3.2 Tools and Techniques for Scope Definition
.1 Work breakdown structure templates. A WBS (described in Section 5.3.3.1) from a previous project can often be used as a template for a new project. Although each project is unique, WBSs can often be “reused” since most projects will resemble another project to some extent. For example, most projects within a given organization will have the same or similar project life cycles, and will thus have the same or similar deliverables required from each phase.
.1.2 .3.4 .5
Scope statement Constraints Assumptions Other planning outputs Historical information
.1 .2
Work breakdown structure templates
Decomposition
.1.2 Work breakdown structure Scope statement updates
Inputs Tools & Techniques Outputs
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
Many application areas or performing organizations have standard or semi- standard WBSs that can be used as templates. For example, the U.S. Department of Defense has recommended standards WBSs for Defense Material Items (MIL- HDBK-881). A portion of one of these templates is shown as Figure 5-2.
.2 Decomposition. Decomposition involves subdividing the major project deliver- ables or subdeliverables into smaller, more manageable components until the deliverables are defined in sufficient detail to support development of project activities (planning, executing, controlling, and closing). Decomposition involves the following major steps:
(1) Identify the major deliverables of the project, including project manage- ment. The major deliverables should always be defined in terms of how the project will actually be organized. For example:
■ The phases of the project life cycle may be used as the first level of decompo- sition with the project deliverables repeated at the second level, as illustrated in Figure 5-3.
■ The organizing principle within each branch of the WBS may vary, as illus- trated in Figure 5-4.
(2) Decide if adequate cost and duration estimates can be developed at this level of detail for each deliverable. The meaning of adequatemay change over the course of the project—decomposition of a deliverable that will be produced far in the future may not be possible. For each deliverable, proceed to Step 4 if there is adequate detail, to Step 3 if there is not—this means that different deliverables Figure 5–2. Sample Work Breakdown Structure for Defense Material Items
Airframe Engine Communication
System Navigation
System Fire Control System
Test Services
Training Management
Data Depot
Level SE Developmental
Test Supporting
PM Activities Facilities
Training Engineering
Data Intermediate
Level SE Maintenance
Facility Operational Test Systems
Engineering Management
Equipment
Training Technical
Orders Organizational
Level SE Base Buildings Mock-ups Project
Management Training Data
Aircraft System
Support
Equipment Facilities Test and Evaluation Air
Vehicle
This WBS is illustrative only. It is not intended to represent the full project scope of any specific project, nor to imply that this is the only way to organize a WBS on this type of project.
Figure 5–2|5.3.3.1
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
(3) Identify constituent components of the deliverable. Constituent components should be described in terms of tangible, verifiable results to facilitate performance measurement. As with the major components, the constituent components should be defined in terms of how the work of the project will actually be organized and the work of the project accomplished. Tangible, verifiable results can include ser- vices as well as products (e.g., status reportingcould be described as weekly status reports; for a manufactured item, constituent components might include several individual components plus final assembly). Repeat Step 2 on each constituent component.
(4) Verify the correctness of the decomposition:
■ Are the lower-level items both necessary and sufficient for completion of the decomposed item? If not, the constituent components must be modified (added to, deleted from, or redefined).
■ Is each item clearly and completely defined? If not, the descriptions must be revised or expanded.
■ Can each item be appropriately scheduled? Budgeted? Assigned to a specific organizational unit (e.g., department, team, or person) who will accept responsibility for satisfactory completion of the item? If not, revisions are needed to provide adequate management control.
5.3.3 Outputs from Scope Definition
.1 Work breakdown structure. A WBS is a deliverable-oriented grouping of project components that organizes and defines the total scope of the project; work not Figure 5–3. Sample Work Breakdown Structure Organized by Phase
Administration Meetings Planning
Training Program Materials DocumentationUser
Software
Training Program Materials DocumentationUser
Software
Training Program Materials DocumentationUser
Software
Training Program Materials DocumentationUser
Software Project
Management
Product Requirements
Software Product Release 5.0
Construct Integration and Test Detail
Design
This WBS is illustrative only. It is not intended to represent the full project scope of any specific project, nor to imply that this is the only way to organize a WBS on this type of project.
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
in the WBS is outside the scope of the project. As with the scope statement, the WBS is often used to develop or confirm a common understanding of project scope. Each descending level represents an increasingly detailed description of the project deliverables. Section 5.3.2.2 describes the most common approach for developing a WBS. A WBS is normally presented in chart form, as illustrated in Figures 5-2, 5-3, and 5-4; however, the WBS should not be confused with the method of presentation—drawing an unstructured activity list in chart form does not make it a WBS.
Each item in the WBS is generally assigned a unique identifier; these identifiers can provide a structure for a hierarchical summation of costs and resources. The items at the lowest level of the WBS may be referred to as work packages, espe- cially in organizations that follow earned value management practices. These work packages may in turn be further decomposed in a subproject work break- Figure 5–4. Sample Work Breakdown Structure for Wastewater Treatment Plant
Wastewater Treatment Plan
This WBS is illustrative only. It is not intended to represent the full project scope of any specific project, nor to imply that this is the only way to organize a WBS on this type of project.
Civil Drawings Architectural Drawings
Structural Drawings Mechanical Drawings
HVAC Drawings Plumbing Drawings Instrumentation Drawings
Electrical Drawings Design
Headworks Aeration Basin Effluent Pumping Station
Air-Handling Building Sludge Building Construction Earlier
Phases Later
Phases
Fgiure 5–4|5.4
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
must plan and manage the scope of work at a more detailed level than the project manager in the main project. These work packages may be further decomposed in the project plan and schedule, as described in Sections 5.3.2.2 and 6.1.2.1.
Work component descriptions are often collected in a WBS dictionary. A WBS dictionary will typically include work package descriptions, as well as other plan- ning information such as schedule dates, cost budgets, and staff assignments.
The WBS should not be confused with other kinds of “breakdown” structures used to present project information. Other structures commonly used in some application areas include:
■ Contractual WBS (CWBS), which is used to define the level of reporting that the seller will provide the buyer. The CWBS generally includes less detail than the WBS used by the seller to manage the seller’s work.
■ Organizational breakdown structure (OBS), which is used to show which work components have been assigned to which organizational units.
■ Resource breakdown structure (RBS), which is a variation of the OBS and is typically used when work components are assigned to individuals.
■ Bill of materials (BOM), which presents a hierarchical view of the physical assemblies, subassemblies, and components needed to fabricate a manufac- tured product.
■ Project breakdown structure (PBS), which is fundamentally the same as a properly done WBS. The term PBSis widely used in application areas where the term WBSis incorrectly used to refer to a BOM.
.2 Scope statement updates. Include any modification of the contents of the scope statement (described in Section 5.2.3.1). Appropriate stakeholders must be noti- fied as needed.