Scope Creep is defined as the scope of a project (the original design, concept, or plan) begins to change without managed control. This can lead to a project going over budget, taking more time, and not being what the customer agreed to or agreed to pay for.
We’ve all seen it. A customer comes to you and asks for a relatively simple project to be done. “It will only take a few hours, at most.” You reply, “Great, let’s scope this out.” You get out your handy-dandy notebook and you conceptualize the following:
The project is moving along nicely, your team members are following all the best practices in the industry, SDLC, IEEE, ISO etc., etc. Then you hear one of the scariest phrases in the industry:
“Hey, I just have a few small changes; won’t even add any time to the plan.”
Here you have two choices: the correct one and the wrong one. Let me demonstrate the difference visually:
The correct choice:
The wrong choice:
The example above was taken from a real-world experience of mine. A friend’s wife asked for a switch in the basement to control the light on the fan. After he had acquired the parts, run the wire, installed the gang box and switch, she asked how to turn on the fan. This was a change in scope as she only asked for “a switch to control the light.” Well, two hours later, additional wire was run, he had a few extra supplies on hand and he had to “make do” at the end with a slightly modified switch plate cover, mismatched switches. Now, he had a project that took a bit longer than planned, and both parties were generally dissatisfied with the outcome.
Changes in projects are as old as the invention of the wheel. Grog made it square initially and it didn’t work, so Oog made it round. The someone put a hole in the middle for an axle. Next thing you know, we’ve built a Ford Escort.
The best way to handle change, any change, is to follow my four-step plan.
Step 1 Define the Scope
Okay, this is obvious, but it needs to be said again and again. If you start out with clear, definitive plans, 80% of the creep goes away. Don’t skip or rush on this phase of the project, even if your client has not signed off on the deal. What ends up happening, is poor design requires changes during the project to accommodate the missteps made during the planning phase. Another risk here is that vague designs lead a customer to believe there is a significant amount of flexibility in the design. One of the things I specifically try to write in the planning document is items defined as within the boundaries of the project.
Step 2 Be Expensive
Simply by adding a line to the contract stating that items considered out of scope (changes, additions, etc.) are charged at a rate 10-20% higher than your hourly rate, may help stop creep. At the first mention of change, bring this additional charge up and ask how they want this invoiced. This is a bit on the severe side, but if your industry or clients tend to push the edges of the project this may be the difference between significant loss and project success.
Step 3 Saying “No” is Sometimes Just as Good as Saying “Yes”
I always like to offer the spoonful of sugar to help with the medicine. In this case, make it two spoonfuls of sugar, one before the “no” and one after.
- Start off with a positive comment about the project. Indicate the successes as they have been happening. If these successes are due to client involvement, point this out.
- Now say “No.” Tell the client why it’s not a good idea to make the change. Discuss the impact to the schedule and costs, especially if either of those are a hot topic.
- Give them that last spoonful of sugar by telling them that their idea is great and should/could be used in the next release or version. This is a soft letdown that allows for a future window for making the change.
Step 4 Add the Creep to the Next Release
It has been my experience that most changes have the potential to add value to a project when properly planned and documented. Just like giving the client that last spoonful of sugar, make sure these changes are put on record in the project documents. Don’t make statements regarding if these should be included, ask them in what release it should be added.
Baseline the project and then begin the dialog of a product roadmap. This gives your client the reassurance that you are in this for the long term. Start making lists of functions and features for future releases, but don’t let this derail the current project. Just make sure you continue to document these requests.
Final Thoughts
Scope Creep tends to be upwards in my experience. It always happens in small bits and bites. When looked at individually, a developer, customer, or product owner will see these as insignificant. Pretty soon, these have added up and your project is way off course, and budget. It is our job as project managers to control the direction of the project according to the plan.
If we make change logically and consciously, and be aware of project impact or consequences, scope doesn’t creep. It simply changes.
JEFF L. CHAMBERLAIN | Project Manager
Jeff comes to KTL Solutions with an extensive background in healthcare IT, technical consulting, and telecommunications. He has been a project manager for almost 20 years holding certifications from the Project Management Institute as a Project
Management Professional, from the Management and Strategy Institute as a Six Sigma Lean Professional, and he holds a Scrum Master Certification from the Scrum Alliance. He has managed both hardware and software implementations for both the government and private sectors, in industries such as healthcare, insurance, telecommunications, staff augmentation, supply chain and shipping.
Jeff has provided training for clients globally, working in Europe, Russia, North and South America on various topics from system optimization to wireless theory and design. He possesses a bachelor’s degree in technical writing from the University of Baltimore.
