PROJECT MANAGEMENT

Project Scope Management

Unit 4

Learning Outcomes
By the end of this unit the learner will be able to:

 Recognize project scope management

 Explain the procedures involved in project scope management.

P a g e 1 | 15
PROJECT MANAGEMENT

Unit 4
Project Scope Management
What is a project scope? Project scope management constitutes “the processes to ensure that the
project includes all of the work required, and only the work required, completing the project
successfully.” Project scope management has several purposes:

 It defines what work is needed to complete the project objectives.

 It serves as a guide to determine what work is not needed to complete the project objectives.
 It determines what is included in the project.
 It serves as a point of reference for what is not included in the project.

In answer to the above question, project scope is a description of the work required to deliver the
product of a project. The project scope defines what work will, and will not, be included in the project
work. A project scope guides the project manager on decisions to add, change, or remove elements of
the work of the project.

Project scope management includes Scope Definition, Scope Verification, Scope Planning, and Scope
Change Control, detailing the requirements of the product of the project and the activities that will
eventually comprise the project plan, controlling changes to these processes, and verifying those details
using measurement techniques.

Project Scope
Management

Initiation Belongs Scope Scope Defination Scope Verification Scope Change

to PlanningBelongs to Belongs to Belongs to Control Belongs to
Initiation Planning Planning Controlling Controlling

Fig: 1.1 Project Scope Management

Project Scope and Product Scope

Project scope and product scope are different entities. A project scope deals with the work required to
create the project deliverables. The scope of the project is specific to the work required to complete the
project objectives.
For instance, a project to create a new barn would focus only on the work required to complete the barn
with the specific attributes, features, and characteristics called for by the project plan.

P a g e 2 | 15
PROJECT MANAGEMENT

On the other hand, a product scope is the attributes and characteristics of the deliverables the project is
creating. As in the preceding barn project, the product scope would define the features and attributes of
the barn. In this instance, the project to create a barn would not include the creation of a flower garden,
the installation of a fence, and the excavation of a wading pool. There would be very specific
requirements regarding the characteristics and features of the barn: the dimensions of the different
rooms and stalls, the materials to be used, electrical requirements, the expected weight to be borne by
the hayloft, and more.
The project scope and the product scope are bound to each other. The product scope constitutes the
characteristics and features of the product that the project creates. The end result of the project is
measured against the requirements for that product. The project scope is the work required to deliver
the product. Throughout the project execution, the work is measured against the project plan to verify
that the project is on track to fulfil the product scope. The product scope is measured against
requirements, while the project scope is measured against the project plan.

Planning the Project Scope

Planning the project scope involves progress elaboration. To create the product of the project, the
project scope is initially broad and through refinement becomes focused on the required work. Like any
process in project management, scope planning has inputs, tools and techniques, and outputs. The
following Table lists the inputs, tools and techniques, and outputs of scope planning.
The first process in the Planning process group is Scope Planning. Like all other processes, it has inputs,
tools and techniques, and outputs. The primary purpose of Scope Planning is twofold: to produce the
scope statement and the scope management plan. The inputs to Scope Planning are items with which
you are already familiar: the project charter, project constraints, product description, and project
assumptions.

Inputs Tools and Techniques Outputs

Constraints Alternatives identification Scope management plan
Assumptions Expert judgement

Using Scope Planning Tools and Techniques

The goal of scope planning is to create a scope statement and the scope management plan, which
together constitute the two outputs of the scope planning process. The project manager and the project
team must have a full understanding of the project requirements, stakeholder expectations, and
business need of the project to successfully create the scope statement and the scope management
plan. Recall that there are two types of scopes:

 Project scopeThe work needed to create the product of the project

 Product scopeFeatures and functions of the product of the project

P a g e 3 | 15
PROJECT MANAGEMENT

Writing the Scope Statement

One of the project manager’s primary goals is to accurately document the deliverables and requirements
of the project; he/she must then manage the project in such a way that they are produced according to
the agreed criteria. Deliverables describe the components of the objectives and goals in a quantifiable
way.

Objectives and deliverables are sometimes called critical success factors. Those elements that must be
completed in order for the project to be considered complete are called critical success factors. For
example, if you are building a bridge, one of the deliverables might be to produce a specific number of
trusses that will be used to help support the bridge. Without the trusses, the bridge cannot be
completed; in fact, the bridge may collapse without them. In this case, the trusses are a critical success
factor. Not all deliverables are necessarily critical success factors, but many of them will fall into this
category and should be documented as such.

The project manager, at this point, needs to discover and document all the requirements of the project.
Requirements describe the characteristics of the deliverable. Some of the requirements of the
deliverable from our bridge example might include the stipulation that the trusses be constructed of a
specific kind of steel or be a certain height or colour, etc.

Importance of Scope Statement

The Scope statement documents the project goals, deliverables, and requirements in order that they
might be used as a baseline for future project decisions. A lot of work concerning the scope statement
has already been accomplished by producing the project charter. The charter is used as an input to the
scope statement. It already contains the project goals and major project deliverables. It will simply be a
matter of transferring the goals and deliverables information from the charter to the scope statement,
providing that the project charter has been well written.

As mentioned above, the scope statement is the baseline for the project. This means thatshould
questions arise or changes be proposed later in the project, they can be compared to what is
documented in the scope statement. The scope statement establishes a common understanding among
the stakeholders and project team members regarding project requirements and deliverables. The
criteria outlined in the scope statement will also be used to determine whether the project has been
completed successfully.

Components of Scope Statement

An output of scope planning is the scope statement. This is the guide for all future project decisions. It is
the key document that provides an understanding of the project purpose. The scope statement lists the
high-level deliverables, provides justification for the project’s existence, and quantifies the project’s
objectives. The scope statement is a powerful document that the project manager and the project team
P a g e 4 | 15
PROJECT MANAGEMENT

will use as a point of reference for potential changes, added work, and any project decisions. The scope
statement includes or references the following:

Project Justification
This describes the business need of the project. If the business need, or business case, has been written
as part of the project charter, it should be referenced in the scope statement. The cost benefit and cash
flow analysis, used to determine the projected profitability of the project, are also included in the Project
justification.

Project’s Product
The scope statement reiterates the details of the project product.

Project Deliverables
The high-level deliverables of the project should be identified. When predefined metrics are met, these
deliverables signal that the project scope has been completed. When appropriate, the scope statement
should also list what deliverables are excluded from the project deliverables. Items and features not
listed as part of the project deliverables should be assumed to have been excluded.
For example, a project to create a new food product may state that the packaging of the food product is
not included as part of the project.

Project Objectives
Project objectives are specific conditions that determine the success of a project. Conditions are typically
schedule, cost, and quality metrics. Vague metrics, such as customer satisfaction, increase risk for the
project, as the metric “customer satisfaction” is subjective and not quantified. The scope statement
should contain a comprehensive listing of all the project requirements. This is important because this
document forms the basis for the agreement between the stakeholders and project team from this point
onwards.

Implementing the Scope Management Plan

The explanation of how the project scope will be managed and how scope changes will be factored into
the project plan is part of the scope management plan. Based on the conditions of the project, the
project work and the confidence of the project scope, the scope management plan should also define
the likelihood of changes to the scope, to what extent the scope may change, and how often the scope
may change. The scope management plan also details the process of how changes to the project scope
will be documented and classified throughout the project life cycle.

P a g e 5 | 15
PROJECT MANAGEMENT

Creating the Scope Definition

The process of scope definition is all about breaking down the work into manageable chunks. For
example, if you had a desire to create a new house, you probably wouldn’t stop by the lumberyard, pick
up some cement, a truck of lumber and some nails, and set about building your dream house. You would
follow a logical approach to designing, planning, and then creating the house.
The same is true with project management. Scope definition is the process of taking the broad vision for
the project and breaking it down into logical steps to reach the completion. Your organization and
stakeholders may have a general idea of where the project should end up, but a detailed, fully developed
plan is needed to get you there.

Examining the Inputs to Scope Definition

You should be very familiar with the inputs to scope definition; you’ve seen these several times already
throughout the book. Here’s a quick refresher of each one and its role in this process:

 Scope Statement: Guide for all future project decisions. It is the key document for
understanding the project purpose.
 Assumptions: Beliefs, held to be true, under which the project is operating.
 Constraints: These include factors such as cost, time, and scope requirements.
 Historical Information: Past projects might serve as inputs to scope definition. Consider
errors and omissions from past projects against similar issues in the current project.
 Other Planning Outputs: Outputs from the planning processes in other knowledge areas,
such as risk, may influence the scope.

Publishing the Scope Management Plan

This plan is an important supplementary document to the project plan as it describes how changes to the
project scope will be incorporated into the project. It also defines the process of how to go about
requesting a change.

The purpose of the scope management plan, according to the Guide to the PMBOK, is to analyze the
stability and reliability of the project scope. It examines the likelihood that scope change will occur
(meaning changes to goals, deliverables, or requirements). The plan answers the questions, “How
dramatic will the changes be?” and“Are a lot of changes expected?”This is determined by the complexity
of the project on which you are working.

The scope management plan should be written and distributed at roughly the same time that the scope
statement is published.

P a g e 6 | 15
PROJECT MANAGEMENT

Creating the Work Breakdown Structure

A work breakdown structure is very similar to a family tree. It maps out the deliverables of the project
with sub-deliverables and activities stemming from each major deliverable in a tree format.

Project Name

Deliverable Deliverable Deliverable

1 2 3

Deliverable Deliverable Deliverable

1.1 2.1 3.1

Deliverable Deliverable Deliverable

1.2 2.2 3.2

Fig: 1.2

A WBS is a deliverable-oriented grouping of project components that organizes and defines the total
scope of the project; work not included in the WBS is outside the scope of the project. Simply put, a WBS
is a deliverables-oriented hierarchy that defines the work of the project.

Fig: 1.3

The WBS is an important part of project planning and will be used throughout many of the remaining
Planning processes. The project charter outlines the project goals and major deliverables. The scope
statement further refines these deliverables into an exhaustive list. This comprehensive list of
deliverables will now be used to build the framework of the WBS.

P a g e 7 | 15
PROJECT MANAGEMENT

The WBS should detail the full scope of work needed to complete the project. This breakdown will
smooth the way for estimating project cost and time, determining quality controls and scheduling
resources later in the Planning process. Project progress will be based on the estimates and
measurements assigned to the WBS segments. Again, completeness and accuracy are required when
composing your WBS.

Since the WBS defines the work that needs to be done, the sequential ordering of those tasks takes place
in a later step, although in practice you will probably combine these steps. The first level of our WBS is
the project name, which appears at the top of the WBS. The next level should describe the major
deliverables for the project. Level three, content, may be the activities that contribute to the deliverable,
or it may be deliverables that are further broken down from the major deliverables of level two. Work
breakdown structures can be constructed using WBS templates or the WBS from a similar completed
project

Defining Work Packages

As mentioned, the project manager is free to determine the number of levels in the WBS based on the
complexity of the project. You need to include enough levels to accurately estimate project time and
costs but not so many levels that it is difficult to distinguish between the activities. Regardless of the
number of levels in a WBS, the lowest level in a WBS is called a work package.

Car

1.0 Engine 2.0 Interior 3.0 Controls 4.0 chassis

1.1 3.1
2.1 Seats
Cylinders Accelerator

1.2 Cam
3.2 Break
Shaft

1.3 3.3
Alternator Steering

1.4 Piston

Fig: 1.4

P a g e 8 | 15
PROJECT MANAGEMENT

Work packages are the tasks that can be easily assigned to one person, or team of people, with clear
accountability and responsibility for completing the assignment. Assignments are easily made at the
work package level; however, assignments can be made at any level in the WBS, as in the Historical
Building scenario. The work package level is where cost estimates, time estimates, and resource
estimates are determined.

Noting Milestones
A milestone is a major accomplishment in a project. Some project managers choose to note milestones
on their WBS. For example, the completion of a deliverable might be a milestone. Milestones are like
checkpoints along the way of the project to help determine progress. In most cases, the higher levels of
the WBS can be flagged as milestones. The higher levels indicate major accomplishments in the project.
For example, Asbestos Abatement in the “Lincoln Street Building Renovation” example is a major
accomplishment that might be considered a milestone. The project would not be considered successful
or complete were this milestone not met.

Scope Statement Updates

You may discover new deliverables that were not considered during the Scope Planning process, as you
work through the decomposition process. These changes should be reflected in the scope statement.
Scope statement updates are the output of the Scope Definition process that allows you to do this.

Communicating with Stakeholders

The Communications Planning process determines the communication needs of the stakeholders, since
you need to know who receives what information and when. The communications management plan,
which is the only output of this process, documents the stakeholders’ types of information needs, how
the information will be delivered, and when the information should be distributed.

The type of information you will typically communicate includes status reports, project baseline
information, status review meetings, scope statements and scope statement updates, project
acceptance, performance measures, and so on.

The communications management plan discusses the timing of the communication and documents how
to collect, store, file, and make corrections or updates to previously published material. The
communications management plan also describes how stakeholders might access project information
between published dates. You might consider setting up an intranet site for your project and posting the
appropriate project documentation for the stakeholders to access whenever they wish.

Decomposing the Project Deliverables

What is a manageable component? It is a unit of the project deliverable that can be assigned resources,
measured, executed, and controlled. Decomposition is the process of breaking down the major project
P a g e 9 | 15
PROJECT MANAGEMENT

deliverables into smaller, manageable components. Hence, how does one decompose the project
deliverables? It is done in this way:
1. The major deliverables of the project are identified, including the project management activities. A
logical approach includes identifying the phases of the project life cycle or the major deliverables of
the project.
2. Determine whether adequate cost and time estimates can be applied to the lowest level of the
decomposed work. The definition of ‘adequate’ is subject to the demands of the project work.
Deliverables that will not be realized until later portions of the project are achieved may be difficult
to decompose since there are many variables between the present and when the deliverable will be
created. The smallest component of the WBS is the work package. A simple heuristic of
decomposition is the 8/80 rule: no work package smaller than eight hours or larger than 80.
3. Identify the deliverable’s constituent components. This means asking whether the project deliverable
can be measured at this particular point of decomposition. For example, a decomposition of a user
manual may have the constituent components of assembling the book, confirming that the book is
complete, shrink-wrapping the book, and shipping it to the customer. Each component of the work
can be measured and may take varying amounts of time to complete, but it must all be done to
complete the requirement.
4. Verify the decomposition. The lower-level items must be evaluated to ensure they are complete and
accurate. Each item within the decomposition must be clearly defined and deliverable-orientated.
Finally, each item should be decomposed to the point where it can be scheduled, budgeted, and
assigned to a resource.
5. Other approaches include breaking it down by geography or functional area, or even breaking the
work down by in-house and contracted work.

Working through a WBS

The WBS is a deliverables-orientated collection of project components. Work that doesnot fit into the
WBS does not fit within the project. The WBS is a visual representation of the high-level deliverables
broken down into manageable components. A WBS is not a chart of the activities required to complete
the work; rather, it is a breakdown of the deliverables. The smallest element in the WBS is called the
work package.

P a g e 10 | 15
PROJECT MANAGEMENT

An Example of WBS

mountain bike

wheel Systems Gearing Frame Systems

Seat System Brake System
Systems

Fork System Frame Cover & Calipers

Huubs Gear & Chains Padding
Structure

Derailluers & Bearing

Rims & Spokes Seat Structure
Shifters Systems Levers & Cables
Joining Systems

Tubing
Structure
Tubing

Fig. 1.5

Here are some essential elements of the WBS:

Serves as the project scope baseline
Work not included in the WBS is not part of the project
Builds team consensus and buy-in to the project
One of the most important project management tools
Serves as a control mechanism to keep the project on track
Serves as the foundation for planning, estimating, and project control
Visualizes the entire project
Serves as a deterrent to scope change
Allows for accurate cost and time estimates

Updating the Scope Statement

The second output of scope definition is scope updates. During the decomposition of the project
deliverables, the project manager and the project team may discover elements that were mistakenly
omitted from the scope statement. The project manager and the team may also discover superfluous
activities in the scope statement that should be removed. When updating the scope statement, the
appropriate stakeholders must be notified of the change and the justification of why the change is being
made.

P a g e 11 | 15
PROJECT MANAGEMENT

Verifying the Project Scope

Imagine a project to create a full-colour, glossy catalogue for an electronics manufacturer. The project
manager has completed the initiation processes, moved through planning, and is now executing the
project work. The only problem is that the project manager and the experts on the project team arenot
sharing the work progress with the customer. The work they are completing is not in alignment with the
product description or the customer requirements.
The project team has created a trendy 1950s-style catalogue with funky green and orange colours, horn-
rimmed glasses, tongue-in-cheek jokes about “the future” of electronics, and lots of beehive hairdo
models. The manufacturer wants to demonstrate a professional, accessible, current look for its
publications. What do you think will happen if the project manager presents the catalogue with his ‘spin’
rather than following the request of the customer?
Scope verification is the process by which the project customer accepts the project deliverables. Scope
verification means ensuring that the deliverables the project creates are in alignment with the project
scope. Scope verification occurs at the end of each project phase, or as the major deliverables are
created. It is concerned with the acceptance of the work. A related activity, quality control, is concerned
with the correctness of the work. Quality control and scope verification may occur in tandem as the
quality of the work contributes to scope verification. Poor quality will typically result in scope verification
failure. Should a project be cancelled before it has completed the scope, scope verification is measured
against the deliverables to the point of the project’s cancellation. In other words, scope verification
measures the completeness of the work up to the cancellation, rather than the work that was to have
been completed after project termination.

Inspecting the Project Work

The work must be inspected to complete the scope verification. Inspection may require the project to be
measured, examined and tested to prove that it meets the customer requirements. Inspection usually
requires the project manager and the customer to inspect the project work for verification, which in turn
results in acceptance.
Depending on the industry, inspections may also be known as:
Reviews
Audits
Product Reviews
Walk-throughs

P a g e 12 | 15
PROJECT MANAGEMENT

Walk-
Reviews
throughs

Product
Audits
reviews

Fig. 1.6

Protecting the Scope from Change

Change is the one constant element wherever project management is concerned. Changes occur, or try
to take place, all the time in projects. The project manager must have a reliable system to track, monitor,
manage, and review changes to the project scope.

Change control focuses on three things:

Determines whether a scope change has occurred.
Facilitates scope changes to determine that changes are agreed upon.
Manages the scope changes when, and if, they occur.

Examining the Inputs to Scope Change Control

Throughout a project’s life, the need and desire for change will come from project team members,
management, customers, the sponsor, and other stakeholders. All of these change requests must be
coupled with supporting evidence to determine the need for the change, the change’s impact on the
project, and the required planning, schedule, and budget to account for the changes.

Using the WBS

The WBS serves as an input to the scope change control. It characterizes the project scope baseline and
represents the sum of the components, and ultimately the project work, that make up the project scope.
The change requests may be for additional components in the project deliverables, changes to product
attributes, or changes to different procedures to create the product. The WBS is referenced to determine
which work packages would be affected by the change, and which may be added or removed as a result
of the change.

P a g e 13 | 15
PROJECT MANAGEMENT

Evaluating Performance Reports

Performance reports indicate how the project is proceeding - well or poorly. Performance reports can
lead to change requests. When a project is proceeding poorly, operating beyond its budget, or
laggingbehind schedule, changes may be made to reduce the project scope, add corrective actions, or
add quality activities to ensure that the product is correct.

Considering Change Requests

Some project managers despise change requests. Change requests can mean additional work,a reduction
in scope, or adjustments to the project. They mean additional planning for the project manager and
require time for consideration; they can be seen as a distraction from the project execution and control.
However, change requests are a very real and expected part of project management. They can appear in
several modalities:

Oral or written

Internal or external

Legally mandated or optional

Direct or indirect

Why do change requests occur? And which ones are most likely to be approved? Most change requests
are a result of the following:

External events:These might be things such as new laws or industry requirements.

Value-added:The change will reduce costs (this is often due to technological advances since
the time when the project scope was created).
Risk response:A risk has been identified and changes to scope are needed to mitigate the risk.
 Errors or omissions:You may have heard this one before: “Oops! We forgot to include this
feature in the product description and WBS!” Errors and omissions can affect both the project
scope, which is the work needed to complete the project, and the product scope, and they
typically constitute an overlooked feature or requirement.

Updating the Project Scope

The documented project scope must be updated to reflect any new changes. When changes to the
project scope have been approved, the stakeholders affected by the scope changes must be notified. The
WBS must also be updated to reflect the components added to or removed from the project. Scope
changes can include schedule updates, quality updates, cost updates, or changes to the project
P a g e 14 | 15
PROJECT MANAGEMENT

deliverables. When the project scope is to be changed, the new requirements must pass through the
planning processes. The changes must be evaluated for cost and time estimates, product specification,
risk, work considerations, and technical specifications.

Correcting the Project

Corrective actions are activities that will seek to bring the project back into alignment with the project
plan. Often, changes are due to quality problems, faulty deliverables, or poor performance of the project
deliverables. Errors and omissions in the product specifications are scope changes rather than corrective
action changes.

Recording the Lessons Learned

The documentation on the lessons learned should be updated as an output of scope change control. The
project manager should document the reasons why changes were approved, components were added or
removed from the scope, and corrective actions were taken. The reasoning behind these decisions must
also be added. Lessons learned will serve as future historical information and help guide other project
managers.

Adjusting the Project Baselines

The project baselines will need to be adjusted to reflect any changes made. Such changes can affect
time, schedule, cost, and scope. The changes that affect the appropriate baseline should be updated to
reflect the new project scope. The new baselines serve as a point of reference for the remainder of the
project (assuming there are no additional changes). If other changes occur, the baseline should be
updated. This enables the project to continue.

Further Reading:

 ShyamkumarNarayana, (2008), Practical Guide to Project Scope

Management

 Michael J. Williams, (2008), Quick Start with Project Management:

The Fundamentals

P a g e 15 | 15