4 Ways To Avoid Scope Creep And Still Please Your Clients

Landing a mobile development deal is a tough task and a rewarding accomplishment. But, as anyone who has created an app knows, landing the deal is just the beginning. As the production process begins, designers and developers need to be aware of a very tricky problem called scope creep.

Sometimes, clients feel that — since they have awarded you the deal and money has been exchanged — they have the right to request features and changes that are beyond the original scope of the project. This is rarely done of our malice or bad intentions, but it still puts designers and developers in a difficult position, since we have to figure out how to say “no” without jeopardizing the relationship.

So, how do we avoid scope creep? Here are four tips that have worked for us.

Define the Scope

This tip may seem obvious, but defining the scope in clear, precise written terms is surprisingly difficult. As we begin to sense that the client is leaning towards signing the deal, we often feel the need to rush, skip important details, and complete the agreement as soon as possible. The problem with rushing is that the scope will not be as clear and comprehensive as it needs to be, which in turn can very likely lead to scope creep. Any areas of work that weren’t explicitly defined will be interpreted two different ways by the client and the developer, respectively. The client will see vague, undefined, areas of work as a wide open canvas with lots of possibilities. The developer, however, will probably consider those same areas of work as unmentioned, unspecified, and thus not a part of the agreement.

Because of this all-too-common difference in perception, it’s important to define all of the moving parts of a project with painstaking clarity. You might even want to state explicitly what work isn’t part of the project; this will help define the boundaries very clearly, which will in turn keep scope creep to a minimum.

Set a High Rate for Out-of-Scope Work

Add a simple (but important) line in the contract stating that all out-of-scope work (changes, additions, etc.) will be charged at an “X” hourly rate and will extend the timeline of the project. If your client’s extra requests are reasonable, mention this rate and ask them if they want to be invoiced. This approach gives your client good options options and decision-making control without damaging the relationship or causing you to take on unexpected, unpaid work. If accepted by the client, considering amending the original contract to expand the scope to the newly agreed standard and rate.

Be Courageous and Say “No.” Use the Sandwich Technique

Are you familiar with the sandwich technique? If not, it works like the following:

1. Start out with a positive statement. It could be appreciation for the client’s care for the project, or the value of the (unplanned) idea/feature that they want to add to the project.
2. State the negatives in the middle. Be honest, direct, and objective. Talk about how adding another feature is not a good idea, and how they would cost more money, take more time, or they may not even be possible.

3. Then, close the sandwich with another layer of positivity. This could be a statement like “the project is going well,” “we’re very excited for the project,” “thanks for bring this idea to us,” or “that sounds like a great idea for the next version of this project.”

Turn Scope Creep into the Feature Set for the Next Version of the App

Most scope creep includes tweaks, changes, and additions that have the potential to improve the project, and are thus are easily justified by the client. The important questions to ask are not whether the project should include these additions, but rather what version should include these new additions. Talk to your client about a minimal feature set for Version 1 and make a list of additions for the next versions. To help clients understand, we have explained versioning like this: “We all have ideas that can make the app better but at this point they are educated guesses, let’s wait until we launch the app and users ask for these changes/features. This way, it’s no longer an assumption but a defined need.”

Hopefully these tips can help you protect the integrity of the project, your time, and your profit margins. If you’re honest with your client and constantly talk things through, you can turn the scope creep problem into an opportunity to create a better app.

Have you had any trouble with scope creep? How have you handled surprise additions to your mobile projects?