Scope creep – also called “creeping functionality” -- occurs when incremental new tasks, functions, or features are constantly being added to a project after it’s under way. Each addition by itself is seemingly inconsequential, but their combined effect can increase a project’s cost by 10%, 20%, or much more, effectively wiping out any hoped-for profit. Scope creep is frequently described as “death by a thousand cuts.”
Although the syndrome can apply to internal and ad hoc projects, this discussion focuses on projects performed under contract for a client.
How It Occurs
If you haven’t experienced scope creep, you may wonder how a project’s definition in a written contract can change so drastically without triggering a change order to cover the added costs.
The reason is precisely because each individual change seems so negligibly minor at the time. Given everything else needed to keep the project on track, the prospect of writing a $20 change order seems hardly worth the effort.
Much later in the project when the full impact of the combined changes becomes apparent, the prospect of writing hundreds of such change orders well after the fact becomes nearly infeasible.
Why It Occurs
One of the factors influencing scope creep is not scoping the project accurately to begin with. If the full extent of the client’s requirements were not clearly realized when the project was estimated, those necessary features and functions are going to try to find their way back in.
Another factor is pride. The client’s representatives want as much as they can get for their money and will press for small extras increasing the perceived value of the finished product. Members of your own project team will also come up with “cool” little features elevating their pride in their work. Sometimes, someone in management (theirs or yours) just wants to see his or her own stamp on the project.
Many of these incremental changes can happen without the project manager’s awareness until the project starts going over budget or schedule and the questioning begins.
How to Control It
The first defense against scope creep is a detailed project specification. Of course, when detailed specs are easy, scope creep is rarely a problem. It’s where detail is not easy that you need to use alternate ways of building a fence around the job.
The best defense when requirements are murky is to divide the job into a Design Contract and a Development Contract. Ideally, the majority of unforeseen features will be captured in the design phase and accurately priced for the development phase. Most clients will want a cap on the price of both phases, which creates the perfect environment for negotiating on features during design and before the work actually gets under way.
If a two-part contract is not feasible, you have to dig for each possible measurement of project scope and attach a number to it, even if it’s arbitrary. Your cost estimates have to be based on something, so quantify your assumptions and put them in an appendix to the contract. When the scope of the project begins mushrooming beyond your projections, you at least have documented legs to stand on for negotiating a change order.
The next best defense is awareness and record keeping. Everyone on the team has to understand scope creep and its impact on company financial health. Team members should be enrolled as guardians of the coffers instead of leaving them to become unwitting accomplices in raids on the budget. Make them aware that it’s not just the cost of the feature, but ancillary costs of testing and documentation that can contribute to busting the budget.
When customers suggest something that seems an add-on, teach team members to say “Let me look into that and I’ll get right back to you,” instead of “Sure, that wouldn’t be difficult to add.” Instead of “We can do that,” saying “It’s certainly possible. What can we take out to keep the project on budget and schedule?” lets the client know that not everything comes free.
When everyone is aware of the potential impact of scope creep, they can be more proactive in keeping notes on client requests, so that when it comes time to document how the project swelled, you’ll have details to back up a change order. They will also be less inclined to include their own unbudgeted features
In project meetings, project scope should be a regular agenda item. Whatever widgets you originally counted and wrote in the contract appendix should be recounted before each meeting and compared. Team notes on items that may qualify as potential add-ons should also be discussed.
Regular scope reviews can be an early warning system, letting you take action before creeping functionality overtakes you. A subsequent discussion with the client can forewarn of upcoming change orders if the trend continues.
With good documentation, team participation, regular vigilance, and a pre-emptive response, you should be able to minimize the ultimate impact of scope creep and finish your project in the black.
Related Articles:
Recognizing Earnings Accurately
