The old adage that ‘time is money’ has rarely been more appropriate than it is for freelancers today.
More specifically, being able to accurately estimate your time is an essential skill for any WordPress developer. However, the ability to accurately judge how long a project will take to complete – and therefore how much you should charge a client – is a difficult task for many reasons.
It’s a tough balancing act: you run the risk of scaring off a client by overestimating your time (and consequently your fee), but you also don’t want to sell yourself short, which would result in an unnaturally low hourly rate.
With the above in mind, in this article we’ll outline four actionable steps – Debate, Evaluate, Estimate and Calculate – to get you on the path to estimating your time more efficiently and effectively.
Step 1: Fully Understand the Scope of the Project [Debate]
We’ve all had a project that started off as one thing and somehow morphed into a completely different animal.
This is known as the dreaded ‘scope creep’, which happens when the expectations of the client don’t match the understanding of the developer. The most troubling aspect of scope creep is that the longer you spend on a project than anticipated, the more it puts you out of pocket.
What is Scope Creep?
Scope creep is the unplanned ‘bloating’ of a project through uncontrolled changes, usually caused by one of two things:
- The most common issue is a lack of definition in the project’s parameters, which is something that you can eliminate at the contract stage if you employ the necessary savvy.
- Changing market conditions can also take their toll, which is more difficult to deal with, as a client might continually revise the brief of the project.
Scope creep can be extremely harmful to projects if not identified immediately, usually resulting in major increases in cost, time and resources.
Having said that, you are entirely in control of whether scope creep becomes an issue in your work.
How Do I Eliminate Scope Creep?
The easiest way to avoid scope creep is to be direct with your client from the offset as to the limitations of your service.
This is best done with a brief containing only tangible (and if possible, quantifiable) actions that you are responsible for, rather than nebulous tasks.
In order to produce this kind of proposal, you’ll need to to ask some key questions. Here are my favorites for narrowing down your brief to tangible tasks:
Have you ever worked on similar projects and/or with a WordPress developer before?
This separates out the more seasoned clients from the less experienced ones. If a client has never worked with a freelance developer before, you may have to do more handholding and explaining throughout the project.
Will I have access to […]?
Knowing what aspects of your client’s business you will have access to enables you to plan ahead in terms of how much you’ll have to research. It also gives you a good idea of how much control you’ll have over the final product.
How often will you want updates?
How often a client wants updating will often depend on how experienced they are. Some will be happy with a brief update once a week, while others will be more demanding. It may seem a small use of your time, but the aggregated time requirement of keeping clients updated can add up.
May I outsource parts of this project?
Depending on the size of the project or your skill set in relation to what’s needed, you may be inclined to outsource some aspects to other freelancers. This will heavily affect your time estimates – especially if you need to learn new skills or refresh old ones. You absolutely need your client’s permission before you do this, so ask.
Do you have any examples?
If you can get an idea of what the client expects the finished product to look and function like, you have a far greater chance of eliminating scope creep.
You will also need to ensure that your client understands the difference between the work needed to complete the project, and work needed afterwards to maintain the product. This is a key distinction for all freelancers, but especially for WordPress developers, where ongoing support is a likelihood, if not a foregone conclusion. If the client is expecting you to offer ongoing support, you should have a separate agreement and payment schedule in place for that service.
An essential step whenever you embark on a new project with a client is to get an ironclad contract in place, which outlines all of the expectations and limitations of the project. It is imperative that you cover yourself with a written contract. While you may not have been burned yet, if you’re in the business long enough without contractual protection, you will eventually.
If you feel that scope creep is showing its ugly face, you need to take action immediately by talking with your client and referring to the contract you have in place. If the project is brought back under control early enough, you should avoid most of the negative effects.
Step 2: Define the Complexity of the Project [Evaluate]
Once you have a complete brief, you’ll be able to assess the complexity of each stage of the project in terms of your own skill set. Each stage should fall into one of three categories:
- I know this and can easily complete it,
- I know this but need to brush up on it, or
- I don’t know this and either need to learn it (or outsource it).
Each of these categories will take a different amount of time, with the third obviously taking a lot longer in terms of time (or more in terms of money) than the first or second. If all of the stages of your project fall into category one then you’re golden – you’ll be able to begin estimating how long the project as a whole will take you with relative accuracy.
If you have a mixture of all three, you need to split each stage into two parts: studying and doing. From there you’ll be able to list estimated costs for each discrete element of the project, then a total cost for the whole project.
I strongly recommend that you take the time to evaluate individual costs relating to both studying and doing. In my experience, the most common reason for undercharging a client is ignoring the amount of time it’ll take you to learn relevant skills. Don’t underestimate this element of the project.
Step 3: Draw From Past Experiences [Estimate]
Even if you haven’t completed a project exactly like the one you’re pricing, you should still be able to draw on past projects to better inform your time estimates on individual elements of the project.
Once you’re at this stage – having done some legwork on estimating project costs – look again at the stages of your project and try to remember how long similar steps took you during other projects. Try to break down your project into discrete elements that represent similar actions you have taken in the past.
Even if you don’t have an exact hourly timesheet of past actions, you may have a relatively accurate idea of how much a common task takes you. And if you do start using a timesheet (or time tracking tool), you’ll have begun building an invaluable resource for drawing from in the future.
At this point you should have a relatively good idea of how long this project will take you. Now add on the extra contingency percentages. This covers everything from unexpected outsourcing costs to simply underestimating the amount of time that a task would take. I recommend contingencies (as a percentage of cost) between 10% and 25%, depending on how amorphous the task is.
Bear in mind that this contingency is not to allow for scope creep.
Step 4: Bring It All Together [Calculate]
At this point should now have a list of discrete tasks, separated by complexity and based on past experiences, with a time estimate for each. To these numbers you have added contingency percentages – more for tasks that you aren’t particularly confident in estimating.
With all this information, create a spreadsheet that sets out out the following:
- Task description
- Time estimate (minutes)
- Contingency percentage
- Total estimated time
Columns one through three are your own manual estimates. Column four is calculated by multiplying column three by column four.
You now have not only an overall estimate for the entire project, but also timings for each individual stage. This spreadsheet also gives you a wonderful opportunity to apply actual timings against your estimates in order to ascertain how accurate your estimates were.
I recommend that you sleep on any proposal (or at least take a break from it) before taking a close look just one last time. It may well be that you have a fresh perspective after having let the proposal ‘rest’.
The above four steps may seem relatively straightforward (and they are), but completing them will give you a far greater understanding how you spend your time and how you should be charging clients for that time.
Here’s a quick recap:
- Debate: Communicate with the client to gain an accurate understanding of their desired outcomes. Avoid scope creep at all costs!
- Evaluate: Consider how complex each step is and break it up into studying and doing.
- Estimate: Draw on past experiences and make informed estimates of time cost.
- Calculate: Bring it all together for an accurate estimate, then let it ‘breathe’ before final evaluation.
With every project you complete, your ability to estimate time will only improve, giving you an even better idea of what you should be charging a client.
That’s all for this post! But I’d love to get your thoughts on this topic. How do you deal with scope creep as a freelancer? Do you have any tips for estimating your project times and costs? Let us know in the comments!
Image by BoBaa22 / shutterstock.com
We use a basic fomula for task/projects that we do not already have a strong idea of how long it will take. Similarly we use this wherein we anticipate lots of variables.
(a + 4M + b ) / 6
a= minimum amount of time
b= maximum amount of time
M= Median of a and b.
In a spreadsheet it would look like this using (keeping things simple so I can do it in my head.
a=6 hours and b=12 hours.
(a + 4M + b ) / 6
So…9 is the Median
54/6 = 9 hours.
You will notice that using whole even numbers will often result in the Median actually being the answer. Also the closer the spread between min and max the Median will often be the answer.
However when using odd numbers and fractions (decimals) is when the formula comes in handy. Also when tallying a bunch of tasks to arrive at the overall project bid this is super handy.
Business Development Concierge
Great set of recommendations, will be sharing this post with freelance friends and colleagues.
About charging for “study” time, I include “research” when I don’t know exactly how a particular piece of functionality will be accomplished (and this is usually plugin or theme framework research, I don’t write my own).
But if it’s learning time for something I’ve never done before, I pick a small job and am upfront about not having a background in it, and then charge a discounted rate for that part of the project.
The reasoning is, I’m getting an opportunity to expand my toolkit and increase my income going forward. So the client (or agency) is doing me a favor by taking me on without direct experience. Since am getting paid for my own training, I don’t ask for my full rate, especially since it’s going to take more hours and I get a direct benefit.
This post came at the nick of time. After working for a web agency that don’t give proper timelines to big
application site without understanding scope creep and that developers need to sleep over the project to get insight, deadlines were not met and most of the app sites didn’t fly. Now a freelancer, I’m gaining amazing tips on how to reduce scoop creep and plan a clearer project relationship with my clients. Thank you very much Tom, this is truly elegant tips!
This is a very good article. It explains various approach in calculating and scheduling the task.
People often underestimate the amount of time needed to implement, particularly when they’re not familiar with the work that needs to be done.
Great article with a lot of insights – thanks for sharing your knowledge, Tom Ewer 🙂
Great Article !
I remember my first project with freelancing. I only care about money and accepted a project beyond my knowledge. I didn’t know what to do when I suddenly was stuck and I had to Google the problem to find the solution.
I barely finished a project in time but after some months of different projects, I understand that I should only accept projects that I am 100% sure I will finish at the required time.
My advice to all new developers is to accept small projects in the beginning. With time, you will gain experience and will learn to manage Time and Knowledge even better.
Coming from the Agile world, I would suggest breaking down any project into slices (working website from front to back, with selected features/pages) – with a rough estimate for a timetable to have a review (sit with the customer to ensure that things are on the right path, solicit feedback for changes, etc.)
I’m wondering what everyone uses as their Contingency percentage?
For most standard sites we work on I usually try for 15% but when we get to building eCommerce sites or custom functionality we’ll go all the way up to 50%.
Burning post sir, much appreciated.
LOL, my first thought was that this was some sort of subliminal mea culpa… but I doubt it was intended that way!