The Project Management Body of Knowledge (PMBOK) Guide defines scope creep as the uncontrolled expansion of product or project scope without adjustments to time, cost, and resources. For example, it could be a stakeholder asking for just one more thing to be done in the project that wasn't in the original charter or original project plan. Scope creep adds more requirements or activities for projects than were originally intended. Of course, projects often start with some uncertainty in the scope or delivery requirements. Clarifying that uncertainty is not the same as scope creep; that uncertainty should be accounted for in the project plan through estimate reserves or risks. The project team is aware of that uncertainty, and they can manage it. Scope creep occurs when there are new requirements or deliverables that were never envisioned as part of the project.
Now, let's look at the impact of scope creep on a project. Scope creep inevitably leads to overruns and delays in the project. That's because the new work consumes resources, but those resources were not budgeted for that work. Paying for the increased work creates an overrun. Also, when the project resources are on the scope creep work, their assigned work is normally delayed, leading to a project delay. Scope creep can also lead to confusion over what really should be done on the project. The original charter and project plan had a particular list of deliverables that should be accomplished, but now the team is working on other things that were not in the charter or are on the list of deliverables. The team is no longer certain what they should be doing. Finally, some scope creep near the end of the project gives it a sense of being endless. Whenever the team thinks it's almost done, there is one more thing being added to the project. This is demoralizing.
So, the obvious question is: How to avoid scope creep? First, we need to recognize where scope creep items can come from and guard against them. The common sources for scope creep are customers, stakeholders, and team members. Customers will often think of additional items that they would like to have based upon what they have seen and developed so far. Within the project, it's hard to tell the customers no. However, there is normally a contract with the customers that explicitly lists all the scope and deliverables. If your project is funded by a customer, you need to be prepared for their requests and prepared to respond. Stakeholders are hard to resist when they ask for additional scope because, after all, they are usually senior managers and can influence your career in a good or bad way. However, they also want the project to complete so they can get the business benefits that the project promises. Finally, one of the most insidious sources of scope creep is the team members. Team members will start doing additional work that they think would be great for the project but is not required. It leads to scope creep. You need to be on guard against scope creep from any of these three sources.
But what do we do when someone does identify a need for scope change? They should be able to explain the benefit of the scope change to the project stakeholders. If the benefit is attractive enough, the project scope should be changed. But that is a formal change to the project charter and deliverables that requires a new project baseline plan. It is not scope creep. The best place to have the discussion is in management reviews or tollgate meetings. Normally, all the right stakeholders are present at those meetings to make the decision whether to re-baseline the project. That is, whether the benefit is worth the scope change. Scope changes that are rejected are placed on the scope creep parking lot. That way, the project team can keep track of any of those ideas and possibly use them in the event of a re-baseline of the project at some time in the future.
Let's talk about the scope creep parking lot. The scope creep parking lot is a database of potential changes to the project that have not been approved. Whenever a scope change is proposed and rejected, it's placed in the scope creep parking lot. This list is often the starting point for the next-generation project. If at any time this project is re-baselined because of some mandatory change, the scope creep parking lot is reviewed to determine if there's anything on that list that should be added to the new scope. Since we're already changing the project, this could be a good time to add something that maybe couldn't stand on its own but is still beneficial and appropriate to include. At the end of the project, anything that is still on the scope creep parking lot is handed off to the next team or to whoever is to manage the results of this project for planning the next generation of the project work.
Scope creep is a major problem, but it is one that can be managed. It can be controlled through these techniques that we've just reviewed.
See also: