Managing Scope Creep: Why, When, and How
Requirements will change and grow over the course of any project. This is a natural aspect of software development. The project manager must anticipate and plan for growth, such as by incorporating contingency buffers into plans when making commitments. Scope creep (also known as feature creep and requirements creep), however, refers to the uncontrolled growth of features that the team attempts to stuff into an already-full project box. It doesn’t all fit.
Ongoing requirements churn and expansion make it difficult to deliver the top-priority functionality on schedule. This demand for ever-increasing functionality leads to delays, quality problems, and misdirected energy. Scope creep is one of the most pervasive problems in software development.
Defining Scope
The first step in controlling scope creep is to document a clearly stated — and agreed to — scope for the project. Without such a scope definition, how can you even tell you’re experiencing scope creep? The techniques described in my article “Defining Project Scope” provide several techniques for defining a project’s scope. Agile projects should write a brief scope statement for every iteration to make sure everyone understands what will and will not be implemented during that iteration. Alternatively, give each iteration a concise name that conveys the goal of the iteration.
The Vision and Scope Document template that I recommend includes a section called Limitations and Exclusions. Here you could list any product capabilities or characteristics a stakeholder might expect but which deliberately are not planned for inclusion in the product or in a specific release. You might also list items that were cut from the scope, so the scope decision is not forgotten. Itemizing known limitations like this helps the team to make quick decisions if a change request comes in for some capability that’s on the exclusion list.
Does It Belong?
The second step for managing scope creep is to ask “Is this in scope?” whenever someone proposes some additional product capability, such as a use case, user story, functional requirement, feature, or output. Note that the project scope could encompass activities and deliverables besides the delivered software products. Perhaps your customers request an on-line tutorial to help their users learn the new system. This doesn’t change the software product itself, but it certainly expands the scope of the overall project work that must be done.
In one situation, a customer had contracted for a packaged-solution vendor to migrate three sets of historical data into the new package. Partway through the project, the customer concluded that six additional data conversions were required. The customer believed this additional work lay within the agreed-upon scope; the vendor maintained that it was out of scope and demanded additional payment.
This was one factor that led to a cancelled project, a lawsuit, and a consulting engagement in which I helped to determine the cause of the project failure. More clearly defined scope boundaries up front, along with an agreement on how and by whom the cost of scope changes would be covered, could have avoided this unfortunate outcome.
Adjusting the Scope
There are three possible answers to the question “Is this in scope?” If the new capability is clearly in scope, the team needs to address it. If it’s clearly out of scope, the team does not need to address it, at least not now. They might schedule the new capability for a later release or iteration.
Sometimes, though, the requested functionality lies outside the project scope as it’s currently defined, but it’s such a good idea that the scope should be expanded to accommodate it. Electing to increase project scope is a business decision. The key decision makers must consider the cost, risk, schedule, and market implications. This requires that the project manager, management sponsor, and key customers negotiate to determine how best to handle the scope change. The owner of the business requirements — the management sponsor — must decide whether proposed changes in user or functional requirements will become the project manager’s responsibility through a scope expansion (Figure 1).
Coping with Scope Creep
Following are some possible strategies for coping with unexpected requirements growth:
- Defer or eliminate some other, lower-priority functionality that was planned for the current release.
- Obtain additional development staff to handle the additional work.
- Obtain additional funding, perhaps to pay overtime (okay, this is just a little joke), outsource some work, or purchase productivity-enhancing tools.
- Extend the schedule for the current release to accommodate the extra functionality (this is not a joke).
- Compromise on quality by doing a hasty job that you’ll need to repair later on (not your best option).
Increasing scope always has a price. The people who are paying for the project must make a considered decision as to which scope-management strategy is most appropriate in each situation. The objective is always to deliver the maximum customer value, aligned with achieving the defined business objectives and project success criteria, within the existing constraints.
There’s no point in pretending the project team can implement an ever-increasing quantity of functionality without paying a price. In addition, it’s always prudent to anticipate a certain amount of scope growth over the course of the project. The savvy project manager will incorporate contingency buffers into project plans so the team can accommodate some reasonable scope growth without demolishing its schedule commitments.
Sensible scope management requires several conditions:
- The requirements must be prioritized, so the decision makers can select the capabilities to include in the next release or iteration and can evaluate change requests against the priorities of requirements in the current baseline. This is the purpose of the backlog on an agile project (really, on any project!)
- The size of the requirements must be estimated, so the team has an approximate idea of how much effort it will take to implement them. This is what story points are for.
- The team must know its average productivity (velocity on an agile project), so it can judge how many requirements, measured in some size units, it can implement and verify per unit time.
- Change requests need to undergo impact analysis, so the team has a good understanding of what it will cost to implement each one and what the implications are likely to be for the project.
- The project’s decision makers need to be identified and their decision-making process established, so they can efficiently decide to modify the scope when appropriate.
Communication is another essential element for managing scope creep. You’ll need to educate your stakeholders so they understand the importance of channeling all change requests through your defined (and effective!) change control process. The change control process is not a barrier but rather a gate, a mechanism by which the right people can make the right decisions to incorporate the right changes at the right time. Communicate decisions about approved change request to all relevant stakeholders, so they know how the project is evolving and how it affects them.
Don’t be victimized by the specter of creeping scope or try in vain to suppress change. Instead, establish a clear scope definition early in the project, and then follow a practical change control process to cope with the inevitable requirements evolution. See “How to Prevent & Manage Scope Creep” for more ideas about how to deal with this ubiquitous project challenge.
Change happens: deal with it.
========================================
This article is adapted from More About Software Requirements by Karl Wiegers. If you’re interested in software requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources.
