Project Scope Management
Last updated: 2022-04-23
Project scope management corresponds to chapter 5 of the PMBoK Guide (A
Guide to the Project Management Body of Knowledge, 2009) of PMI. Based
on our process view of project management, it comprises all management
processes that ensure definition, planning, and implementation of all
the work, and only that work, which is necessary to create the project
results as required.
Here, with project scope management, we refer to managing the project scope in the implementation and closure phase and focus on controlling the implementation of the project scope. In general, an integral part of project controlling in the project implementation phase is making sure that the actual work follows the WBS (Work Breakdown Structure). We make sure that we identify changes and additional work necessary or nice to have as early as possible and quote them in form of a change request before we execute them. These change requests shall be fair for all involved parties. For the preparation of a suitable change process during project planning, please refer to the sub-section Contract Management.
Scope creep is the extension of the originally planned work put down into the WBS. Thus, this term refers to additional, un-planned work, in most cases generating time delays and additional cost. If not covered by a corresponding change order based on our change process, we shall avoid any scope creep. Otherwise, we end up in a claim situation: we implement the change anyway, take and file all available project records of that case, and try to settle compensation for it in terms of extension of time (EOT) and additional cost later.
disputes about scope creep develop as follows. There is a contract
between customer and supplier which contains a chapter covering the
scope of the project. For a certain piece of scope a change or extension
seems to be necessary. Then, a discussion begins about the question if
that change or extension is covered by the contract or not because the
corresponding contractual wording and relevant requirements and
specifications are too vague to begin with. Usually, the customer takes
the position that the change or extension is already inclusive, the
supplier insists it is extra scope, stipulating EOT and / or monetary
compensation. If customer and supplier cannot agree upon an equivalent
change order, and the supplier decides to implement the change anyway we
have scope creep, collect all available project records, and follow the claim management process as outlined in sub-section Contract Management.
a practical tool of project scope management in terms of controlling
the project scope on work package level, we find the WBS itself. It is a
simple, but powerful tool that helps to indicate - not yet solve any
problems with - the current project status in terms of scope.
Using WBS for Project Scope Management
A double strike indicates that the work package is finished, i.e. its results are accomplished (WP1.1, WP2.1.1, WP3.1).
A single strike indicates that work on that work package has been started (WP1.2, WP2.1.2, WP2.2.1, WP3.1, WP3.2).
No strike indicates that work on this work package has not yet begun (WP2.1.3, WP2.2.2).
Milestone Trend Analysis
To support project scope management on project level, we use milestone
trend analysis (MTA) to indicate the project status in terms of scope
(in sub-section Project Management Dashboard we explain how MTA works).
Milestone Trend Analysis (MTA)
In a case like in this picture,
- milestone "Sys. Design" was achieved one month late,
- milestone "Hw complete" is predicted to have one month delay,
- milestone "Sw complete" is predicted to have two weeks delay,
- and milestone "Sys. complete" is predicted to be achieved on time.
For each milestone, we have a number of work packages leading up to it.
Thus, if a milestone is indicated to be late then we need to analyze all
work packages which contribute to that milestone. In a larger project
that consists of hundreds or thousands of work packages, it is mandatory
to summarize groups of work packages, and represent their status via
milestone trends. Should one milestone indicate any delay, we "only"
need to investigate the work packages behind that milestone.
Analysis of work packages behind delayed milestones focuses on two aspects in order to serve project scope management.
Scope: what happened, what went different than
expected, what can we do to correct errors or mistakes, what
consequences does this have on other work packages or parts of the
project, what are our lessons learned?
Schedule: what are the consequences on the time line of
this and other work packages or other parts of the project, and what
can we do to make up for any occurred delays? Please compare sub-section
Project Time Management.
Earned Value Analysis
Combined with MTA, earned value analysis (EVA)
is another convenient tool to support project scope management. To show
the project status in terms of scope, we determine how much work is
done (or results achieved), and express it in terms of its Dollar value.
This we call earned value (EV). Then we compare EV with the amount of
work that should be done already (results that should be achieved
already) which is planned value (PV). We can calculate
Schedule Variance: SV = EV – PV,
Schedule Performance Index: SPI = EV / PV.
SV = 0 or SPI = 1 at a certain point of time indicate that earned and
planned value are in-line. Work progress is as planned, and results are
achieved as planned.
SV < 0 or SPI < 1 at a certain point of time indicate that earned
value is less than it should be. Certain planned work is not yet done,
or certain results are not yet achieved.
SV > 0 or SPI > 1 at a certain point of time indicate that earned
value is more than it should be. We have done more work or achieved more
results than planned.
Both, MTA and EVA, only serve as indicators of missing scope.
In order to cure problems we have to go down to the work packages and
apply problem solving techniques.
Project scope management requires a combination of different tools since one alone usually shows only part of the status:
- Network diagram, in order to identify individual work packages that
have problems with scope, in terms of their logical sequence
chart, in order to identify individual work packages that have problems
with scope, in terms of estimated duration or their reference to the
- MTA, as indicator of missing scope on project level
- EVA, as indicator of missing scope on project level
- Problem solving techniques for affected work packages
Learning Path Navigation