Scope creep refers to a change in what a project is supposed to deliver, along with the associated deliverables, features, and so forth, after it has been agreed on and the work is underway. The problem is that in the planning stage, the plan (schedule, budget, resources) was agreed to based on specific decisions on the project's scope. If the scope starts to change, what happens to the schedule and budget? Typically, the scope—the deliverables and associated work the project is going to include—expands because someone starts to
"add stuff to the list." New features may be added to an already approved feature list, for example. This type of scope creep often comes about from small, seemingly insignificant change requests that the project team accepts to keep the project sponsor and/or stakeholders happy. Eventually, the change requests become numerous enough that they are
significant, or one of the requests turns out to require much more work than expected. With everyone pushed to get more done with less in a shorter period of time, the drive to do as much as we can as fast as we can easily leads to creep that could actually derail the project.
Scope creep can also happen more subtly. Individuals doing their work see something else they think should be done, and do it. But they may not examine whether it's really called for, or whether adding it could impact the project schedule or cost, or even add a new project risk. Team members, including developers, generally want to please, and are usually interested in finding the best way to get something done. This creates an ideal opportunity for introduction of new features and functions—"nice-to-have" capabilities that were never envisioned at project inception. This adds effort and increases risk to the project, something you want to avoid.
Whatever the source of the creep, the result is a project that may be drifting away from its original timeline and budget, and even from its original purpose.
How do you tell if it's happening on your project? For one thing, listen carefully as the team members discuss their progress. For example, are developers or others discussing features and functions not in the requirements? Do you hear items that make you stop and think, "Why are we doing that? How does that help us meet the goals of the project?" Part of the project manager's role is to be diligent in watching and assessing what is being worked on. When it looks like scope is creeping, the manager's job is to surface the issue and start a discussion. The team and the sponsor must consciously decide whether to proceed with the changes—after acknowledging the cost and/or schedule impacts to the project—or stop the changes and make the important of holding the original scope clear to everyone.
To learn more, read the article "The Balance Between Risk and Scope Creep" and the case study "High-Speed Conflict and Scope Creep: A rapid web services development effort."