“It seems like every project I do ends up taking way more time than I initially expected it to.”
β You?
Do you keep running into the issue of either going over budget on hourly billing projects, or calculating your effective hourly rate on fixed-rate projects and realizing it’s atrocious?
If either of those feel familiar, this post is for you.
π― What you’ll leave this post with…
Β» A process you can follow for more accurately estimating how long projects will take
Β» A time tracking approach that will help you improve your estimating skills over time
The “problem behind the problem”
Before we move into process to follow, it’s wise to identify the core issue that’s driving your inaccurate estimates.
- Is it that you’re a new freelancer and you’re still getting your bearings on how long things take?
- Are all your projects totally different and it’s tough to draw from past experience for guessing how long something new will take?
- Are you thinking only about the “deep work” and not about all the client conversation time, revisions, and other “fundamental project time costs?”
- Are you a “time optimist” in general?
- Are you trying to be aggressively optimistic about how quickly you can finish in order to hit the client’s desired budget?
- Are you not interviewing the client thoroughly enough in advance?
- Do you always seem to run into scope creep?
- Some other reason you can think of that I can’t?
For me personally, I’m #4 blended with #5.
Part of it is driven by my ADHD; in general I’m very bad at accurately estimating how long things will take. (It frustrates the shit out of my girlfriend)
But the other problem I’ve run into in the past is that if I can sense that someone wants my price to be lower, I have the impulse to lower it and try to “just make the site faster,” regardless of how realistic that actually is.
(Hint: it almost never works out. Because ultimately, if there’s no reduction in scope, and I’m already executing my build process efficiently, there really aren’t many ways to shave off time.)
Before you move on to the next section, I’d encourage you to take a minute to reflect on what you think the “problem behind the problem” is for you, so that you can contextualize the upcoming steps and know where you need to improve.
The process for estimating more accurately
1 β Interview the client and determine the scope
For website design + build projects, I like to get a bulleted list of all the site’s pages, with each one containing a sub-bulleted list of panels (for pages that will have complex layouts), and any “special / fancy features” like a contact form, booking system, slider, etc. (Basically anything more complicated than a box with text in it.)
I’ve found it’s most effective to flesh this out live with the client on Zoom vs. doing it asynchronously. (Type the bulleted list yourself and really try to tease out the details for each page.)
If you’ve got an especially website-savvy client, you miiiight be able to get everything you need from them in an email, but in my experience, they usually send something incomplete, which is a recipe for scope creep later.
The end result should look something like this…
- Home
- Page panels layout:
- Headline panel w/ background video
- Our services – 3 boxes with different images or icons
- Testimonials slider
- Contact
- Page panels layout:
- About
- Simple text block at the top
- Our team grid with bios and photos
- Our services
- 3 subpages; one for each service. Each one will have…
- Checkmark list of what’s included
- Pricing table
- A bit about the service
- Testimonials
- 3 subpages; one for each service. Each one will have…
- Contact
- Contact form
- Embedded calendly
- Blog
- Infinite scroll
- Masonry layout
- FacetWP for filtering by post attributes
π Bonus points: For complex layouts, I find it really helpful to also flesh out a wireframe live with the client for any pages / templates that need it. I personally love using InVision‘s “freehand” tool for this. Here’s an example I laid out for a dog shelter I donate my time to (I wanted to build a dog profile portal for their existing site), and here’s the live built-out end result. (It’s not my design or normal layout builder plugin stack, so don’t judge my skills too much from this π )
2 β Review the scope and tease out details
I then review the entire bulleted list scope (pages, features, etc.) with the client and ask them if there’s anything missing, even something “super small and obvious-seeming.”
The “super small and obvious-seeming” part is key.
I’ve learned over the years that features that seem complicated to clients are often easy to build…
…And features that seem simple to clients are often extremely complex and time consuming to build.
(I literally have this comic bookmarked and have cause to pull it up / share it every month or so, because it’s just so damned true.)
3 β Get final scope approval
Once all the details are teased out, get approval on the final, totally-fleshed-out scope from them.
This should happen live on that same initial discovery / sales call that you were on for step 1 & 2.
4 β Get super loose budget approval
While still on the phone, give them a super-duper-loose quote (delivered as a price range, not a single number), get budget approval on it, and tell them you’ll need to get back to them with a more firm quote later.
You can try to give a firm quote live on the call if you really want to, but if you’re like me and doing bespoke websites where each one’s different, the estimating process is probably going to be a bit too intricate to do live on the phone.
For me, based on my personal sales process of…
- Asking for a loose scope via email when they first reach out to me…
- Giving them a very rough estimate of price over email, to make sure they can afford me before we talk…
- Jumping on the initial sales call, getting more details, and telling them I’ll get back to them later with a more firm quote…
- Emailing them later with the firm quote and a link to pay their deposit if they want to get going…
…I’m not too worried about “losing the sale” if I don’t get them to actually close the deal live on the sales call. (And thus, I don’t mind leaving the call with the expectation of me sending them the price later.)
But if you don’t do any pre-filtering first to ensure they can afford you, it’s especially important to come up with that reeeeaalllly rough ballpark estimate on the phone (with the promise of a more firm quote later) to see if they balk at the price.
(In my experience, the top reasons sales don’t close are either because the price was too high for their budget, or because they found someone else who seemed like a better fit.)
To get that loose budget approval, you can say something like…
“I’ll need to take some time to go through the spec later to give you a really firm quote, but based on everything we talked about today, I suspect the price will fall somewhere between $5,000 and $8,000. Does that work for your budget, or should we try to cut some scope to make it cheaper?”
The reason for this wording is to get a feel for what their budget is, while also setting the expectation that if they want a cheaper price, we’ll need to remove features (vs. me just giving a discount for no reason.)
If they say something like, “Your rough estimate works, but I want it to be on the lower end,” it’d be smart for you to get a list from them of the features they don’t care as much about, so that you know which ones to cut if the next steps in this process show you that you’re likely to be over budget.
5 β Make your estimates
After the call, go through your scope that you fleshed out with the client and make estimates line-by-line for how long you think each thing will take.
I recommend that you estimate in ranges, and be quite generous with the upper range.
Be sure to add some new lines for baseline project time requirements, like…
- Fundamental website design
- Design for complex pages that require a standalone design (vs. designing them as you build in a layout builder or something)
- Phone calls with the client
- Emails
- Project management in Slack or whatever
- Training the client at the end of the project
- Responsive testing
- Cross-browser testing
- Revisions / changed mind about things
- Misc. requests
- Any other stuff you could see cropping up that’s not specifically in-scope but that would take your time
Your final estimates for yourself might look something like this…
- Fundamental website design (3 – 7 hrs)
- Phone calls with the client (2 – 4)
- Emails (1 – 3)
- Project management in Slack or whatever (1 – 3)
- Training the client at the end of the project (0.5 – 2)
- Responsive testing (1 – 4)
- Cross-browser testing (1 – 3)
- Revisions / changed mind about things (1 – 3)
- Misc. requests (2 – 3)
- Home
- Custom design: (2 – 5)
- Page panels layout:
- Headline panel w/ background video β (0.5 – 1)
- Our services – 3 boxes with different images or icons (0.25 – 0.5)
- Testimonials slider (1 – 3)
- Contact (0.5 – 1)
- About
- Simple text block at the top (0.25)
- Our team grid with bios and photos (0.5 – 2)
- Our services
- 3 subpages; one for each service. Each one will have…
- Checkmark list of what’s included (0.25 – 0.5)
- Pricing table (0.5 – 1.5)
- A bit about the service (0.25 – 0.75)
- Testimonials (0.5 – 0.75)
- Time to build out the other two pages with the same template as the first (1.5 – 2.5)
- 3 subpages; one for each service. Each one will have…
- Contact (0.5)
- Contact form
- Embedded calendly
- Blog
- Infinite scroll (0.25 – 1.5)
- Masonry layout (0.5 – 2)
- FacetWP for filtering by post attributes (1 – 3)
6 β Tally up & multiply
Now that you have your line-by-line estimates, AND your estimates for the “baseline project requirements,” you can total them all up to get your “total range estimate.”
In the example above, it would be 22.75 – 55.75 hrs.
For anything in the list that you haven’t done a bunch of times before, multiply the relevant ranges by 1.5 or 2.
So if, for example, you’ve never built an infinite scroll masonry blog with filtering before, you should probably multiply all those line items by 1.5 or 2 (for both the upper AND lower ranges), because you’re likely underestimating bugs and edge-cases that’ll come up as you build.
If this is a “bread and butter” type project that you’ve done a million times before, no need to multiply anything.
Buuuuut if you get the sense that this client is going to be really nit-picky, or otherwise high-maintenance, add another 0.25 or 0.5 to your total multiple.
So for example, if this is a “bread and butter” project but the client seems kinda high-maintenance, you’d wind up with 28.4 – 68.75 hrs. (22.75 * 1.25) to (55.75 * 1.25)
7 (Optional) β Ignore step 6 and go on to regret it, with a promise to follow it next time
Often once I’m at step 6 and I see how. freaking. huge. the upper-end estimates are when multiplied by 2, I quickly proceed to haggle myself down on the multiple.
“I know what I’m doing,” I say. “I can just be sure to keep it under that upper range.”
β Silly Zach
“It is an upper range, after all. How could it possibly take longer?”
β Silly, silly, naΓ―ve, silly Zach
I then do the project…
…And am super duper surprised (π) when it’s over budget.
And then I promise myself I’ll follow my own rules next time.
The challenge when the estimates feel uncomfortably high
“But Zach, what if I add up all these hours and it becomes clear that there’s no way I can do the site for the client’s budget if it really ends up taking all this time!!??!??11!!1one!!?
If you tally up your hourly estimates and multiply them by your desired effective hourly rate and there’s a huge misalignment between that number and your client’s target budget, it’s a sign that something needs to change.
Either you’re targeting too high of an effective hourly rate for what’s currently feasible at this stage of your business, or you need to cut some scope.
(Price reductions should ideally *only* come as a result of cutting scope, vs. you just arbitrarily deciding you’ll charge less for the same scope.)
“But what if I’d have to cut so much scope that the site would kinda suck and I’d lose the client?”
This is the ultimate “between a rock and a hard place” situation.
It sucks to feel like you have to either deliver a severely crippled site or not be able to meet the client’s budget. It’s usually at this stage that numbers 4 & 5 from the “problem behind the problem” list start to come into play for me.
If you’re starved for work and don’t want to lose the client by cutting all the scope that would be necessary in order to meet their budget, you’re welcome to give them a price reduction without cutting scope.
Just know going into it that your targeted effective hourly rate is almost definitely going to take a hit.
The exercise coming up in this post will help you to know how big of a hit you took, and help you determine how accurate your initial estimates were. (Which is very valuable info.)
With time, and as you work with more β and better β clients, you can aim to optimize and increase your effective hourly rate to get it where you want it to be.
8 β Send the quote & start the project
For me, since I bill by the hour at a sliding rate scale, I usually deliver my proposal more or less like this…
“Hey Clientname, I went through our scope in detail, and after evaluating all of it, I expect that the project will take between 23 – 56 hrs. Based on my hourly rates {{ LINK TO YOUR RATES PAGE }}, that comes out to $3,795 – $8400.”
If that range is higher than they wanted (like, let’s say on that initial sales call they said they wanted it to be around the $5k mark), I might add something like this in the next paragraph…
“I remember you mentioning on the call that you wanted to try to keep the price around $5k. The upper end of my estimate accounts for a lot of revisions and changes throughout the process of building.
To ensure we hit that $5k target, it’ll be important that we aim to be low-maintenance and efficient with design revisions, and be really good with up-front strategy and planning to make sure we nail the content on the first try without having to back-track and re-lay-out pages.
Another idea I have is waiting to tackle the masonry blog with infinite scrolling until we see how we’re doing on budget for the rest of the project. If necessary, we can build out a more ‘typical’ WordPress blog layout like this one {{ link }}, and chop 2-7 hours off the total bill.”
So basically, letting them know that their nit-pickiness and lack of planning will result in more fees, and pointing to a non-critical piece of scope we can cut/defer as a “low hanging fruit backup plan” to make sure we hit the budget.
What about for per-project billing?
If you bill by the project, it’s easy enough to mimic the deferral of the infinite scrolling masonry blog and charge a fixed fee just for that component, but it’s a lot more difficult to account for nit-pickiness and offer discounts on the “promise of being low maintenance.” (Generally, high-maintenance clients can’t actually *keep* promises like this.)
I don’t really have a good solution for the latter, and it’s a big part of why I moved to billing by the hour instead of by the project.
The best advice I can give for that situation is to include a specific number of revisions in your packages, and keep an eye out as you work on the project for where high-maintenance-ness eats into your margins. Then, next time around, build limits in those areas into your per-package pricing.
One other note for putting together your estimate if you bill by the project…
Selling websites as “all inclusive” is a recipe for scope creep without getting paid for the increased time.
Instead, I recommend that your estimate be made up of multiple “sub packages,” to make it clear that there’s a direct relationship between website features and the amount that the client has to pay.
(It’s also a helpful way for them to prioritize/deprioritize features based on price.)
9 β Track ALL your time
The core goal of this step is to track all your time in a specific-enough way that you can compare your final result to your estimates once the project is complete.
I have tags set up in Toggl not just for predictable deep work type stuff (coding, designing, etc.) but also for “shallow work” stuff, like…
- Chatting on Slack with the client
- Doing Zoom calls
- Invoicing
- Answering emails
- Planning the project scope
Even though many of these tasks aren’t (and shouldn’t be) billable, they still affect how long a project takes, and thus affect my effective hourly rate.
Here are all the tags I have set up in toggl; maybe some will give you ideas.
(Some are hyper-specific to individual projects I’ve worked on, so don’t just blindly replicate them all π)
When you’re tracking your time, be sure to note in the time entry which specific task from your original bulleted scope list you’re working on, so that you can later go back through and compare.
10 β Finish the project, then compare
Once the project’s done, go through your initial bulleted scope list that you made and write in what each thing actually took next to your original estimate.
For any new emergent scope items, or any new fundamental baseline project requirements that popped up, be sure to create a new line for them (and log the time taken) so that you can remember next time to factor them in.
Next, look at the big picture and ask yourself things like…
- Where were your estimates too low?
- Where were they too high?
- What should you do differently when estimating next time?
- Are there any fundamental things you should change about your pricing to account for what you learned here?
11 β Tighten up your ranges in future estimates with repeated experience
As you get better, and especially if you productize or niche down, you’ll be able to tighten up your ranges for how long you estimate things will take.
If you repeat this process for 3-5 projects, you’ll be amazed at much more clarity you have on your pricing and estimating process.
π Action Steps
This post is inherently action-oriented, so the main thing you need to do here is *give the process a try!*
Feel free to make the process your own β if, for example, you don’t feel comfortable making such high estimates or doing the multiples, then don’t do it! Simply bid your project like you normally would (but still with the scope broken out into a bulleted list with line-by-line estimates), track where your time goes, and compare at the end.
This “expectations vs. reality” time tracking exercise is where the big value comes from here. This exercise alone has been hugely impactful for my own business, and I believe it will be for yours too.
After you’ve done the exercise and drawn your conclusions from Step 10, file it away somewhere that you’ll see next time you’re bidding a new project. Before making your estimate, factor in your learning experiences from last time, and you’ll find that with each project you do, you get better and better at estimating.
Alrighty, now get out there and execute the process!
If you found this post helpful, I’d be super-grateful for you sharing it with friends or on social media, and I’d love for you to join the email list so that I can send you future posts you’ll enjoy and keep you leveling up consistently in your freelancing business.
Leave a Reply