Scope is one of the main sources of project issues. Improper definition and control of what work is, and is not, part of the project can result in huge project management headaches later on. In the Project Management Body of Knowledge, scope control is a major part of the Monitoring and Controlling process group.
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. 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:
- 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. - 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. - 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. - Underestimating project work
Most projects err on the low side when estimating schedule, cost, and resources (due to competing for the work or satisfying a client, etc.), but then err on the high side when making decisions regarding the completion of deliverables (to create the highest quality product). 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. - 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 at any given time, the project manager should know two things:
- 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 other 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 result.
It is advisable that the project team knows these values 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 situation 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:
- 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.
- Market needs. The market was not adequately defined or market needs have changed, and the additional expenditure will be necessary to remain competitive.
- Return on Investment. The project has identified a potential opportunity which will result in a return on investment that wasn’t anticipated before.
- Impact on Schedule/Cost. The project has identified potential cost and/or schedule savings within other areas of the organization or future projects.
- 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.