Project Scope Management

Published: 2009-03-30
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.

Typically, 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 part 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 included, 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.

As 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 diagram,

• 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,
or
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.

Summary

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
• Gantt chart, in order to identify individual work packages that have problems with scope, in terms of estimated duration or their reference to the time line
• 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