Like termites that build their invisible kingdoms secretly and slowly, projects have a similar parasite that grows under the surface until it suddenly exposes itself with disastrous consequences. It’s called scope creep, and it has eaten many projects alive.
Scope creep is the unauthorized addition of tasks into a project. If the project manager is not on the lookout, it can cause immeasurable headache to the project manager and the project stakeholders.
Reasons for Scope Creep
There are five primary underlying causes of scope creep:
- Poorly documented scope
When the scope statement does not contain sufficient detail to present a clear, concise project scope to the project team, they will not know what work is and is not included within the project. This makes it easier to add something small here and there, or advance an agenda. Also, external technical managers will help themselves to project resources without having anyone or anything stopping them. - Poor requirements definition
The requirements of the project need to be defined in the project management plan. This document lays out all the requirements the project must conform to and helps avoid the practice of “gold plating,” – spontaneously increasing the quality level higher than originally planned. - Poor communication between stakeholders
Almost all projects have opposing stakeholders with conflicting interests. For example, when building a fence the neighbor wants to have the longest lasting paint but you want to minimize the cost. This inherent conflict requires communication between parties, and the project manager is usually the person responsible for bringing those parties together. This conflict also encourages the spread of the scope creep bug because the project team might see the easy way out of a situation by appeasing a stakeholder, exaggerating something, gold plating the product, or introducing something that wasn’t planned for. - Underestimating project work
At the planning stage the pressures on project estimates are down, because of trying to win the work, appease a client, and so forth. But then during project execution a funny thing happens, the cost pressures go right the opposite way. You want to provide a great product to that client, or look like you’ve covered your bases, or just go above and beyond, and the cost pressures on the project are upward instead of downward. This is one of the fundamental conflicts of project estimating, a human nature condition which leads to budget and schedule overruns if the estimator is not familiar with it and resisting the pressures. It also ensures that scope creep is effectively baked into the project and makes it very difficult to avoid. - External factors
Sometimes the parent organization experiences shifts in business strategy, technology changes, or the like which affect the project’s cost and/or schedule. The project manager cannot control the external factors that influence the project. Major changes to the project which require active management are not considered scope creep, but there are indeed many external situations which might cause small unauthorized work to manifest itself within the project.
It can be tempting, when spotting an incarnation of scope creep, to assume that a future task will come in correspondingly under budget or ahead of schedule. I’ve done this many times. But most of the time this underlying cause affects the other tasks as well. Thus, if you ever succumb to this line of thinking, it is imperative that you actively manage those future tasks to make sure they really do come in under budget (or ahead of schedule).
Theory of Project Scope
A project is defined as a unique endeavor with a defined beginning and end. As such, it must have a project scope, that is, a well defined list of tasks that are part of the project. Project scope is the fence that defines the boundaries of the project.
Scope Management Plan
According to the Project Management Body of Knowledge (PMBOK), a Scope Management Plan is a part of the overall Project Management Plan. It is created during the Plan Scope Management process. It defines the conditions under which the scope will be defined, managed, and controlled.
PMBOK, 5th Edition, Section 5.1.3.1, “Scope Management Plan”
The Scope Management Plan is a component of the project or program management plan that describes how the scope will be defined, developed, monitored, controlled, and verified. The scope management plan is a major input into the Develop Project Management Plan process, and the other scope management processes. The components of a scope management plan include:
- Process for preparing a detailed project scope statement;
- Process that enables the creation of the WBS from the detailed project scope statement;
- Process that establishes how the WBS will be maintained and approved;
- Process that specifies how formal acceptance of the completed project deliverables will be obtained; and
- Process to control how requests for changes to the detailed project scope statement will be processed. The process is directly linked to the Perform Integrated Change Control process (Section 4.5).
The scope management plan can be formal or informal, broadly framed or highly detailed, based on the needs of the project.
Scope Statement
The most important part of the scope management plan is the scope statement. It is developed during the Define Scope process, a part of the planning process group.
PMBOK, 5th Edition, Section 5.3.3.1, “Project Scope Statement”
The project scope statement is the description of the project scope, major deliverables, assumptions, and constraints. The project scope statement documents the entire scope, including project and product scope. It describes, in detail, the project’s deliverables and the work required to create those deliverables.
The purpose of the scope statement is to communicate the project’s scope to all relevant stakeholders. Therefore it is important to make sure that all the bases are covered, including the specific mention of items which might not be obvious (inside or outside the scope). If your project is to build a garage, for example, a scope statement of “To Build a Garage” is obvious and provides no net benefit. The scope statement should attempt to reduce the risk of major project issues by drawing as clear boundaries around the project as possible.
Theoretically you could define the project down to the number of nails and bolts, but this is not usually realistic. Therefore project managers need to decide when the scope definition is specific enough and assume any risk of changes after that (or include contingencies).
Controlling the Scope
Scope control is the key to ensuring the scope creep bugs don’t multiply and eat the project alive. The scope control process takes place within the monitoring & controlling process group and consists of the tasks which aim to keep the project’s scope on track.
PMBOK, 5th Edition, Section 5.6, “Control Scope”
Control Scope is the process of monitoring the status of the project and product scope and managing changes to the project baseline. The key benefit of this process is that it allows the scope baseline to be maintained throughout the project.
The inputs, tools & techniques, and outputs of the process are:
How to Control Scope Creep
Notice in the process diagram for Scope Control above, that the only Tool & Technique is called Variance Analysis. This is a reference to the main parameters of the Earned Value method, the Schedule Variance (SV), and Cost Variance (CV).
These two variables are calculated weekly, or on whatever time period the project manager decides to hold project status updates. They provide the project manager with an up to date project status on two fronts:
- Cost
- Schedule
The actual definitions are:
- Cost variance (CV). The monetary value that represents how far above/below budget the project is. CV = EV – AC.
- Schedule variance (SV). The monetary value that represents how far ahead/behind schedule the project is. SV = EV – PV.
Where:
- 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 earned value method is the industry standard for keeping projects on budget and ahead of schedule, but what does this have to do with scope creep?
The answer is that scope creep shows up in the CV and SV. If Bob has spent 14 hours instead of the budgeted 12 hours, the CV will be negative signalling an over budget situation. If he has spent the right amount of hours but exceeded the completion date of the task, the SV will be negative indicating a behind schedule situation.
The real benefit of the CV and SV is that it gives you fantastic early warning of budget and schedule issues because the analysis is as good as the input data. If you have up-to-the-minute costs and hours for your project (which most people do) you can plug in the numbers and it will tell you where you are.
You really can exterminate that nasty scope creep bug before it becomes an infestation!
Let me know in the comments what your experiences are and how you deal with scope creep!
