Learning to work with remote developers is a valuable skill that will have a positive impact on your business and your wallet. In previous articles in our working with developers series we’ve covered:
- Everything you need to do while hiring a WordPress contractor
- How to write a WordPress project brief: The Blueprint
- How to work effectively with WordPress Experts
Now we’re going to cover a rather sticky topic – but super important topic. Getting this right will give you an ongoing relationship with your expert that can even benefit your bank balance. We’re going to talk about scope creep.
You may think that getting more from your money is a good thing, right? Nope.
Stick with me, I’ll explain why actually scope creep is a bad thing not only for the expert but the client too. Then I’ll give you some tips on how to avoid scope creep from happening.
What’s scope creep?
The project scope is the work that the expert has agreed to do for you. This is not always the same as your project brief. The brief is the important first step, but after discussion with your expert what work that get’s agreed upon may have changed. This agreed work will be put in writing, here on Codeable, it’s usually listed in the workroom.
Scope creep is when the scope of the project gets bigger without any changes to the budget. The “creep” part is because work isn’t usually added in obvious ways like “While you are fixing that bug, please redesign my website”. It’s usually in smaller less obvious ways these extra things “creep” into a project.
At least from the client’s view, these things are easy quick things that for an expert, such as a WordPress developer or designer, are just a few clicks. Here 3 pretty common examples:
Scope creep – Example 1
You’ve asked an expert to set you up a website. You listed all the things you want the website to have. When you look at the result, you say: “I need another page, just a really basic text page”.
Scope creep – Example 2
You look some more and say: “Oh the form needs a couple of extra fields”.
Scope creep – Example 3
You take another look, and say: “Can we add that contact form to the bottom of the new page?”.
If none of these items were agreed to upfront, then this is scope creep: you are asking for things that you never communicated to your developer. They are usually very small things but they mount up. Sometimes to hours more work – work that has not been paid for.
Sometimes the requested changes aren’t even small. Sometimes the request itself is an hour or hours of work, even days. For example, you ask your expert to make a plugin. The expert meets all your requirements, but it’s not exactly what you wanted. So you ask your expert to change how the plugin works.
Drawing a line: is it actually scope creep?
It’s important to note what scope creep is not. If extra work is requested and the budget is adjusted then this is not scope creep. New feature requests, although part of the same problem are not really creeping in, perhaps we should call this “scope stuffing”. It’s bad too, but scope creep is much more complex.
Need help with your WordPress theme? Hire Zackary Allnutt for your next project!
Why does scope creep happen?
A common way of working is that the client pays X and the expert will complete the project, and then the client will tell the expert what needs changing.
One of the main problems I’m seeing is both clients and expert are not used to fixed quote projects. Let me explain.
If you’re working as an employee, or to an hourly rate, then there isn’t anything wrong with this per se, the expert or employee is getting paid for the hours they work. If you change your mind or think of something else to add then it’s no problem.
When I was an employee I didn’t care my employer was “wasting my time” by getting me to do work then changing half of it. They were wasting their own resources, I was getting paid none the less.
But here on Codeable, we work for fixed quote, so we have to work differently. This is why we must be strict on the scope. If the client is willing to pay extra for those change, then great! But when the client expects those changes as part the original quote then here lies the problem.
Why is scope creep bad for the client
Now you may be wondering, as the client, why it should matter to you, right? It’s natural for anyone to want more for their money. But this is different than getting 20% off your shopping.
The difference is you’re attempting to get your expert to work for free! Why? Because your expert never factored this work into their quote. So anything that was not written down in your agreement would be work done for free.
In whatever work you do, would you appreciate anyone asking you to work for free? No, right?. Then, nor does your expert. And that’s the first reason why you as the client should care about scope creep. It hurts your relationship with your expert and there are huge cost-saving benefits to working with the same expert. Currently, I am working on a custom plugin, that took me time to get to know. I’m now able to reduce my quote for subsequent work because I know it so well now. If my client takes the work to another expert they will have to pay for that expert to get to know the plugin as I already do.
If the project starts to run over time due to scope creep, a 30-hour job would be now a 40-hour job. What’s very likely to happen is that work gets rushed. You may get those changes to wanted but quite possibly at the expense of other important jobs. The time set aside for code cleanup and testing is now gone and your expert at this point is probably feeling less than enthusiastic about your project.
I can assure you that this is not what you want. The quality control phase is a vitally important part of the project and should not be sacrificed for more features.
The key role of project briefs
So what can be done to prevent project creep from happening? Clients and experts used to the former way of working need to learn a different way of working for fixed quotes to be successful for both parties. In my experience, clarity is the secret sauce to a happy client and a happy expert. That happy dynamic is a key part of the Codeable ethos.
For the best success, that clarity comes from both parties.
How to write better project agreements
The rule of thumb is that if it isn’t written down, it’s not part of the agreement and thusly the expert has not accounted for the time to include it.
- Be as clear as possible up front with your brief, what your goals are and what you are expecting. Try to make sure you have covered everything you need, even small things.
- Ask questions if you’re not sure. As an expert, I’m really happy when asked questions about the agreement: it means the client is paying attention to it off the bat and I can predict a great working relationship. If you don’t know at this point everything you need, consider asking your expert for a consultation or discovery project. These pre-work projects are a great way to work with a developer to write a great brief and make sure you get everything you need from the project.
- Never assume that a work will be done if it is not written in your agreement – even if you think it’s obvious. This is a mistake because every client and expert have a different idea of “obvious”. You may assume that styling will be included but other clients are expecting to do it themselves.
- Remember that the agreement is the scope, not your brief. This is because there are times when things on the brief won’t be done for whatever reason. They are split between tasks, not everything can be done with the budget or not everything on the list is doable. So when we talk about scope, it’s what been agreed to by both parties.
- If you make a request that is outside the scope, please preface it with “Can I add X as an additional task?” knowing the client is aware that this additional work, is really helpful to the expert – we now know we don’t have to have a conversation about scope.
The key role of revisions in your project brief
The work is done and you take a look at your project. You’re pretty stoked (I hope!) with the results, but there are a few tweaks here and there you would like to change. This, in my experience, is where the problem begins.
You should know that, at this point, the expert considers the project complete and is not expecting the list of changes to come. On the other end, the client might have two/three small requests like “can you increase that font a little?”. That’s no big deal.
But let me tell you this: revisions and scope creep are best of friends. Why? Well, because there’s no common answer to what counts as a revision and how many revisions are reasonable to request. And, believe me, all sort of things get requested under the guise of “revisions”. The list of revisions can double or even triple the developer’s workload sometimes.
Don’t you – the client- think this is affecting your pocket as well?
Revisions seem to be a given in our industry and, to prevent themselves working for free, experts might add huge amounts to a project quote to cover this almost inevitable flow of change requests after the work has been completed. The common workflow that clients and experts are used to (and part of the problem) is that the project is completed, presented and then the client lists everything they want to be changed. This is very bad for everyone involved.
I’ve heard of developers doubling their quote to cope with revision requests. And that’s where clients are being overcharged for the idea they might want to change things.
As Aristotle said, the truth lies somewhere in the middle. In fact, developers are not doing due diligence before starting the project and clients are doing a bad job of describing what they want. It’s important that both parties are on the same page here.
So are revisions included (or not)?
Things almost always come up during a project, things you forgot to mention or things that you didn’t realize you needed in the first place. The classic mistake here is not to have budgeted for these things. If you put aside money for them and expect them to arise, then you won’t be shocked when they do, and you won’t try to push the scope to account for these surprises.
The key concept you should not forget is: if revisions are not mentioned in your agreement, you must assume they are not included. Despite popular opinion, there is no reason why revisions have to be part of the original funding.
Personally, I’m not a fan of revisions being part of the original project as they really variable and hard to account for. They are also really hard to define, resulting in pages worth of definitions in a contract. Also, I don’t want to charge clients for revisions they may not ask for.
A big danger (at least with unlimited revisions) is it encourages carelessness at the project planning stage because the client is aware that they can just change the work after it’s done if it’s not what they wanted. I hope I don’t need to explain why poor planning is not good for your business.
Instead, consider leaving a buffer to your budget of maybe 30% to account for changes you may want to make. If you would like to include revisions in your original funding ask your expert about them. Here’s some type of revision agreements you might see:
- “Revisions are not included in the quote and are quoted for if they are requested”
- “2 Rounds of revisions are included in the quote – this does not include extras outside of scope and is limited to small design and functionality changes”
- “20 small single action revisions are included in the quote – this does not include extras outside of scope and is limited to small design and functionality changes”
Wrapping it up
Scope creep isn’t something that experts only should be worried about. Clients too have to learn how not to fall for it because it can directly affect their overall budget by ending up with higher quotes from experts. When you hire a developer, designer, security expert or any other professional, you’re building a business relationship. No matter how long it lasts.
So if you want to avoid scope creep, I’d suggest to starting with some good planning on your side, leaving a buffer in your budget (~30% as useful reference) in case you think of things you might need to add later. Then, move onto translating all of that information into an amazing project brief and keep your communication clear throughout the whole project.
And never forget: be fair to your expert by not asking them to do things that you didn’t before they quoted. How happy would you be to work for someone doing that to you? Well, that’s how happy your expert is working on your project. Do you think they will want to work for you again?
Need help with WordPress? Hire Zackary Allnutt and have him work his magic for you!
