How to Control Project Scope

If your scope is pointed the wrong way, you’re not going to hit the target!

In fact, ineffective project control is one of the biggest sources of project distress.  For this reason, one of the most important aspects of a project manager’s job is controlling the boundaries of the project, that is, the tasks that are and aren’t part of the project.

If you want to have any hope of hitting the target at the end of the project you need to make sure the scope is pointing right at the target, not off to the side, or too high or low.

In the Project Management Body of Knowledge (PMBOK), scope control is a major part of the Monitoring and Controlling process group.

The inputs, tools & techniques, and outputs are:

Simply put, the scope of the project should not change.

Often there are external forces pushing and pulling on the project that result in changes to the project’s scope, and these can be legitimate.  But the project itself needs to be planned well enough that changes in scope don’t result from normal project work.

The exception to this might be with an agile project, a technique which is used primarily in software development where pieces of software are developed, tested, and released in parts.  This process is required when you can’t define the final product well enough to accurately estimate the work required at the outset.  But in conventional project management the scope needs to be defined as well as possible when the project is initially planned, and scope changes avoided whenever possible.

The Scope Statement

A strong scope statement is part of a good project management plan.  The creation of a scope statement is covered in the Define Scope process within the planning process group in the PMBOK.

Scope control can only be as good as the scope statement because it’s the target that you aim for.  When you are aiming at the wrong target the best shot in the world is not going to help.  The scope statement should be a good indicator of what work is involved in the project, and touch on the main things the project does not include as well.  A good project scope statement avoids scope creep.

Scope Creep

When tasks get added to the project in an ad hoc fashion without the proper adjustments to schedule, cost, or resources, the result is called scope creep.  To project team members it often seems like small tasks can be absorbed by a large project, but collectively they become one of the biggest reasons for project failure, and project managers identify this as one of their biggest project management challenges.  Over time scope creep grows like a cancer that, if unchecked, can consume the project and doom it to failure.

Scope creep can result from:

1. Poorly documented scope
   If the scope statement is insufficiently detailed, it will not be clear to the project team (or outside individuals) what work is or is not included within the project.  Worse, other individuals that are not stakeholders in the project decide to use the people or resources, or other projects that have budget/schedule issues feed off the project through time sheet and expense exaggerations.
2. Poor requirements definition
   If the project’s requirements are not sufficiently defined the project team can be susceptible to “gold plating,” i.e. increasing the quality level above that envisioned by the project plan and adding the corresponding cost and time to the project.
3. Poor communication between stakeholders
   A common problem is that stakeholder’s requirements are in conflict with one another and the project manager does not actively manage each stakeholder’s expectations.  For example, the project sponsor for a hydroelectric dam prefers to keep the project cost finite but the environmental regulators require more mitigation than expected.  Most (if not all) projects have “opposing” stakeholders that, if not actively managed, will result in scope creep.
4. Underestimating project work
   Most projects err on the low side when estimating schedule, cost, and resources during the planning phase (due to competing for the work, etc.), but then err on the high side during project execution when making decisions regarding the completion of deliverables (to create the highest quality product, etc.).  Not allocating enough time, cost, or resources can result in scope creep.  If the error is large there will be a clear need to deal with the consequences, but often small variances are not addressed.  It is very easy to assume another task will be completed early and cover the variance, but this is very seldom the case.  If this strategy is adopted, it needs to be actively managed to ensure another task actually does finish ahead of schedule.
5. External factors
   The organization perfoming the project can experience minor shifts in business strategy.  The project acceptance criteria can be tweeked in ways that seem insignificant to an external party.  Technology can change the project techniques and processes.  These and many more issues can affect projects negatively and produce scope creep.

Scope Change

In general, changes in scope during project execution should be avoided.  However, in the real world scope change is a reality that is difficult to eliminate altogether.  For complex engineering projects it is impossible to predict every design issue at the outset.  Inevitably many different things come up in which a small additional upfront cost can reduce the project budget later on, and it would be shortsighted to avoid the investigation of those issues.

For these reasons, scope change is a fact of life on megaprojects.  The project sponsor / funding authority must recognize and be sympathetic to the many issues involved.  In this case it is advisable for the project team to ensure a sufficient contingency within each task (or the entire project) which is dependent on the level of estimating that has been done.

For small projects, however, it is desirable to eliminate, or at least minimize, scope changes during project execution.

How to Control Scope Change

It can be prudent to establish acceptable parameters for scope changes with the project sponsor at the project planning stage.  Once this is established, the scope statement should be inspected and verified weekly by the project manager.

The PMBOK advises the use of variance analysis as a Tool and Technique of Scope Control.  This means that a technique called the Earned Value Method is employed which allows the project manager to calculate the following two variables:

• Schedule variance (SV).  The monetary value that represents how far ahead/behind schedule the project is.  SV = EV – PV.
• Cost variance (CV).  The monetary value that represents how far above/below budget the project is.  CV = EV – AC.

The three variables in these equations are:

• EV = Earned Value.  The relative completion of each task (EV = % complete x Task budget)
• PV = Planned Value.  The planned completion of each task (PV = expected % complete based on task start and end dates x Task budget)
• AC = Actual Cost.  The actual cost of each task.

The two variances can be expressed in percentages, which give you a better idea of how big the variance is relative to the overall size of the project.

• Schedule Performance Index (SPI):    The ratio of how much has been completed versus how much should have been completed by now.  SPI = SV / EV.
• Cost Performance Index (CPI):  The ratio of how much the project should have cost versus how much it actually has.  CPI = EV / PV.

Each of these factors need to be calculated on a task by task basis and summed to determine the overall project variances.  Please see our earned value example if you want to learn how to use this method further.

The accepted practice which is endorsed by the PMBOK involves the selection of regular “status points” after which some sort of status updates are produced.  They can be formal status updates that are submitted to executives or informal meetings with project team members.  But whatever form they take, the Schedule Variance and Cost Variance is calculated on regular intervals and shared with the appropriate parties.

During these status meetings the scope statement is also inspected to see if any changes have taken place or need to take place based on the current project status.

It is advisable that the project team knows the variances as well, since they tend to be in the best position to make up any differences.

The Business Case for Scope Change

In the undesirable event that a scope change is necessary, it is important to adequately document the business case for the change, since the project sponsor and organization will be scrutinizing the expenditure of additional funds to achieve the same perceived outcome.

The following checklist can be used to develop a business case for a scope change:

1. Added value.  The scope change produces added value that wasn’t there before.  Even better, the proportional value relative to the expenditure is greater than the original project.
2. Market needs.  The market was not adequately defined or market needs have changed, and the additional expenditure will be necessary to remain competitive.
3. Return on Investment.  The project has identified a potential opportunity which will result in a return on investment that wasn’t anticipated before.
4. Impact on Schedule/Cost.  The project has identified potential cost and/or schedule savings within other areas of the organization or future projects.
5. Product Liability or Risks.  Additional risks and/or product liability have appeared, requiring more in-depth analysis and/or mitigation to save the organization money down the road.

In the area of project scope, many of the participants in the process have incentives to underestimate costs, overestimate revenues, undervalue environmental impact, and overvalue economic development effect.  This results in a tendency for project scope to expand and cause problems for the project manager.  The Scope Control process is all about ensuring scope does not expand except where necessary, and that the project stakeholders are aware of the changes in an appropriate fashion.