Nobody likes revisions. Clients don’t like having to ask for them, web developers don’t like having to do them, and end-users don’t like having to wait for them to get done.
But nevertheless, revisions are a fact of life for most web developers. Even the most professional developers often find themselves in the position of having to revise things they thought were finished.
Sometimes, these requests take the form of small changes and additions that are easy to take care of. It’s hard to complain when a client asks for a 5-minute change to a website or application that involved 50-60 hours of work.
The problem occurs when clients ask for one 5-minute change, then another. Then, after the first two are done, there’s one small thing that needs to be taken care of. And then the client says, “While you’re at it, can you…”
This is the situation that leads to scope creep. Whenever a project’s goals seem to expand beyond its original scope while the project is in progress, you are probably a victim of scope creep.
But how can you stop it? How many tiny fixes add up to a major revision you should charge for? Read on to find out how to deal with scope creep effectively.
The Origins of Scope Creep
Scope creep is not new. We can trace it all the way back to Ancient Greece, where the first pupils of Socrates grappled with the Sorites Problem, which goes like this:
A million grains of sand is certainly a heap. But one grain of sand is not. If one grain of sand is not a heap, then two grains is not a heap, either. If two grains is not a heap, then three could not possibly be…
…and so on until…
If 999,999 grains of sand don’t make a heap, then 1 million grains shouldn’t.
So when did the grains of sand become a heap?
Back then, philosophers believed that words were concrete things that referred to ideas that exist in a real way. It took several thousand years for people to discover (thanks to Ludwig Wittgenstein) that words carry meaning only insofar as the people using them agree on that meaning and actually use it.
But for the web developer, the problem is not grains of sand, but development requests. How many tiny requests make up a full revision?
But just like we now know that words need to be agreed upon to carry meaning, project revisions need to be agreed upon in order for a clear division to exist.
That means that as a web developer if you don’t spend time defining project scope early on, you run the risk of letting them believe the scope is one thing while you believe it is something else.
Prevent Scope Creep By Getting Everyone On the Same Page
The only way to adequately protect yourself against scope creep is by establishing exactly how requests relate to revisions. You won’t be able to get rid of revisions entirely, but you can limit your clients’ ability to make request after request with impunity.
There are two places where you can do this. During the Project Discovery phase, or when making your proposal. In both cases, there are some clear steps you need to take in order to prevent scope creep from biting into your profits.
- Write Down Client Objectives. Every project needs to meet some objectives. If you have these objectives written down, you can clearly tell when a revision request falls into the pre-established set of objectives or refers to a capability or functionality that is totally new.
- Put Client Objectives In the Contract. A basic web development contract won’t help you against scope creep unless it clearly defines your responsibilities. That means it has to cover the client’s objectives with precise language.
- Track Request Time. If you want your client to respect your time, you have to measure it. Track how long it takes you complete small requests. You’ll quickly see how many grains of sand it takes to make a heap.
- Charge for Revisions in Blocks. From the outset, you can tell your client that you charge a half-hour minimum for revisions – but they earn the whole half-hour in the process. So if your client identifies six different five-minute fixes they want to be performed, your time is covered.
- Sell Revisions Through a Retainer Agreement. Most clients know that websites are not one-time, set-and-forget products. They will eventually need maintenance and updates. Use this to your advantage and upsell revisions as part of your website retainer agreement so that you earn a fair price for your work and improve cash flow.
A Little Bit of Flexibility Doesn’t Hurt
Many clients will expect a certain degree of flexibility when it comes to revisions. As a result, there is a balance between preventing scope creep and delivering great experiences to customers.
One way you can do this is by further clarifying the difference between “on-scope” revision time and “off-scope” revision time, as defined by the client’s stated objectives.
You can include one or two hours of “on-scope” revision time free of charge, and charge your clients for revisions beyond that. The same rate would apply for “off-scope” revisions that don’t fall into any of the categories defined during project discovery as “objectives”.
Just like with the Sorites problem, clear language and communication is the key to distinguishing between subtle differences in meaning. Take charge of your client negotiations and define terms early so that you have the best chance of keeping your projects free from scope creep.
Sometimes the best way to handle expanding a project needs it to put more hands on deck. Our white label web development services can help you finish big projects with ease.
