In this lecture,
we will focus on the language,
the tools and techniques,
and the best practices of Project Scope Management.
Scope management focuses on the work that needs to be done to
satisfy the needs and expectations of the project's stakeholders,
who are parties interested in the project success or failure,
parties who may be impacted by either the problem or the solution.
Examples are customers, users, employees,
authorities, neighbors, competitors, and subcontractors.
Their objective is to do all the work needed to create value,
by satisfying the stakeholders needs and expectations,
but to avoid any waste in the form of doing unnecessary work.
Projects have two types of scope, the product scope,
also known as the product configuration,
is a description of the product,
service or system to be delivered by the project.
This description includes all features and functions required.
The description of the product scope may start with a requirement document,
and is developed into detail specifications or specs.
The project scope is a description of the work that needs to be done by the project team,
the way it should be done,
and the results or deliverables that are expected.
The project scope is presented in a document known as scope of work,
or Statement of Work, SOW.
The SOW defines the work that has to be done,
how it should be done,
and the expected results or deliverables,
typically consisting of some combination of hardware,
software, data and services.
The description of project work frequently includes
applicable documents such as standouts or regulations,
according to which the work must be
performed and the project deliverables must be designed.
The project's scope is decomposed into
smaller components like the Work Breakdown Structure or WBS.
The work breakdown structure organizes the team's work
into a manageable sub projects called work packages.
Each work package, has its scope of work and its deliverables,
and it is managed by a work package manager,
an expert in the type of work performed within the work package,
and the deliverables the work package is expected to produce.
The work breakdown structure is a multi-level hierarchy.
The number of levels depend on the size of the project.
In the lowest level, there are always work packages that are broken down into activities.
This is where detailed planning is performed.
The product scope is presented in the form of requirements and specifications.
For example, consider a radar system for
air traffic control that has a required range of 12 miles.
Any range below 10 miles is not acceptable,
while a range of about 12 miles is fine.
This requirement is translated by using the laws of
physics into an equation known as the radar equation,
showing that the radar range is a function of the transmitted power or TP,
the receiver sensitivity or RS,
and the antenna gain or AG.
Other requirements for the air traffic control radar are its quality and reliability.
Each requirement is ranked,
based on its importance to the stakeholders,
it is given a relative weight,
say on a scale from 1 to 10.
A weight of 1 represents a requirement that has
the lowest priority to stakeholders who have low power and low involvement,
while, a weight of 10 presents
a high priority to stakeholders with high power and high involvement.
The relationship between the product scope,
and the project scope should be carefully analyzed,
as the project scope describes the work that
needs to be done to develop the product scope.
For example, to develop a radar system,
work to design and build each of the radar components,
the receiver, the transmitter,
and the antenna is required.
Additional work is required early in the form of
system engineering and at the end to integrate the different components.
The relationship between product scope and project scope
is presented in the form of a table or matrix.
For example, the work on the transmitter design is part of the project scope.
And the design of the transmitter affect the transmitter power or TP,
which in turn, impacts the range of the radar.
The entry in each cell of the table is a parameter used
in the equation for the corresponding column requirement,
also known as worth,
or the stakeholders worth.
The parameter is determined by the word described in the relevant role.
Task TP in this example,
is the transmitter power determined by the transmitter design,
and it impacts the range of the radar system.
At the end of the project initiation phase,
the first scope baseline is created,
composed of the project scope and the product scope.
So on the project life cycle,
change requests are quite common as new information is made available.
Change requests are the result of many types of new information such as,
new information from stakeholders who add requirements,
change requirements or change the priority of requirements,
new information on safety issues,
technical problems or resource availability problems,
new information and possible ways to reduce the project cost,
to reduce the project duration or to improve quality.
Change requests are evaluated by the change control board or CCB of the project,
and approved changes trigger change orders that result in change to the scope baseline.
A project is finished when all the work in
the updated project scope baseline is completed,
and all the deliverables in
the updated product scope baselines are finished successfully,
and pass the required acceptance test.