The Friendliest Freelancer #13: Estimating client work


Estimates can be very tricky: I’ve done them now and again for twenty years, and I still find it hit-and-miss.

In this week’s article, I’ll describe how I usually approach estimates with clients these days (and I’ll share a Google Sheet template with you at the end).

Have a great week! ☕


“My client just asked me how long this project will take. What do I do?”

If you’re doing fixed-price projects, you need to estimate work upfront to know if it’s worth doing.

But even when you’re charging by the hour (as is typical in long-term contracting/consulting engagements), clients will ask you to provide timelines for features and projects: sometimes to know if something is worth building at all, at other times to assist them with product management and scheduling.

So, you should have some basic techniques in your bag. Let’s look at a simple workflow to find a timeline for your client’s project.

Come up with initial numbers.

Do your research. Make sure you perform enough analysis and design up front. Talk to stakeholders and users. If new and unfamiliar tech is involved, read docs, search Reddit to discover known gotchas, and play with the tech yourself.

Ask questions, lots of questions. More context up front means fewer assumptions and less guesswork.

[…] Who’s the end user? How many people depend on the new tool? How are they working today? What pieces are most important? Are any parts “nice to haves” and possible to drop/postpone? How polished does the UI need to be? Are there restrictions on which technologies and patterns we can use? Is there a hard deadline of any sort? […]

Come up with as many questions as possible!

A little bit of design upfront. Do rough wireframing, flow diagrams, written stories, et cetera. Run them by your client early to help you “sync up” and ensure you agree on scope and constraints.

Even if the client seemingly has a clear picture of what they need, retelling it back to them in your words/diagrams/sketches can uncover serious misunderstandings early on.

Not a solo project? Include the rest of the team early. Estimating other people’s work is risky; people have very different strengths and weaknesses. And they can see and catch things that you may miss. So, if you need to develop a timeline for a team you’re working with, ensure the other team members participate at every step. (Planning Poker is an example of a technique to find team consensus on estimates).

Define the concrete tasks. Try to split tasks into jobs smaller than a day or two; big “buckets” of work are trickier to estimate accurately.

Estimate individual tasks in ideal hours. “How many hours could this task take if I could work without distractions?” Don’t map to actual workdays yet; decouple each task estimate from your day-to-day schedule. (We’ll map to total actual days/weeks in a separate step; keep reading).

Tag the most risky and uncertain tasks. For very unclear features, mark them clearly (I usually make them red and bold in my spreadsheets). Estimate those tasks high to make them stand out, and try to describe what the uncertainty is.

If you can’t resolve all of these upfront through enough research and questions, then make sure you (and your client!) keep them firmly in mind when the project starts: “Remember: these parts can bite us!”

Sum up the tasks. Now, you have the total number of ideal hours you think the project will take.

Multiply the total ideal hours with a safety margin. Adding a % margin on top takes overall risk into account: Murphy’s Law will strike at some point, so you need some slack built into the schedule from the get-go. My absolute minimum is usually a 10% margin (if I’m working with familiar tech for a client I’m very comfortable with and it's a small project).

How many ideal hours do you have available in an average week? Think through your daily life. After subtracting recurring meetings, other projects and obligations, how much focused time do you usually have available each week? Be honest with yourself.

Total number of ideal hours divided by average ideal hours per week = number of weeks the project will take. Now, you have an initial timeline in weeks.

Discuss the timeline with your client

Remind everyone involved that estimates are guesswork. Estimates are often treated as prophecies: “Know, O Client of Mine, that on June 1st, the project shalt be complete!“ In reality, estimates are qualified guesses. As with weather forecasts, many known and unknown variables can nudge the outcome, especially if you make a long forecast. This brings us to the next point...

Should the project be split up into multiple increments or milestones? Estimates are less confident the more extensive the project and the longer the timeline: if you’re looking at months rather than days or weeks, it’s a good idea to split the project into multiple parts.

For extensive projects, fine-grained estimates upfront of the whole thing are unrealistic: concrete dependencies, time available, schedules, and dependencies are unknowable many months in advance (this is why large fixed-cost projects are such a bad idea).

An ideal timeline does not map cleanly to calendar dates! Sit down with your client and discuss external factors affecting the timeline. Are there risky dependencies to external factors, people, and events? What deliverables must your client or third parties supply along the way? Write out any assumptions and requirements that you see together.

It’s now possible to find a rough target in the calendar. Just make sure everyone agrees on the assumptions and caveats above. “This looks like late next month if everything works out like we discussed.”

Track and adjust your estimates during the project

Put your project manager cap on:

Don’t throw away your estimates after you start building. Instead, try to keep your spreadsheet updated throughout the project. If unforeseen tasks show up, add them. If some tasks turn out to be unneeded, remove them. If the original estimates start to look too pessimistic or overly optimistic, adjust them.

Revisit the numbers weekly with your client. Given the adjustments above, let them know if anything has changed in the scope, if the risk has gone up or down, and if the total timeline looks altered. And if everything stays the same from one week to the next: let them know about that, too.

Bonus: a template spreadsheet for estimates

I’ve created a Google Sheet template based on the process above:

You’ll find it here

Feel free to clone it, share it with others, and use it as you see fit.

I may revisit and adjust this template now and then. I’ll increment the version number each time I do so.

Please let me know if this was useful to you; I’d love to hear about any adjustments and improvements you come up with!


Unsubscribe · Preferences

Thomas Kjeldahl Nilsson

Software dev of 20+ years now helping other devs gain autonomy and become calm, independent contractors—new issue every other Sunday

Read more from Thomas Kjeldahl Nilsson

A concern I regularly hear from software developers who want to try contracting/consulting: the marketing and sales bits can feel foreign and scary. One book in particular helped demystify sales so I could relax a bit—more on that below. Until next time, have a great week! ☕ “I'm talking to potential clients and I need to land a contract with one of them soon. Oh no: do I have to learn about sales now?” I’m not a sales expert. Most of my clients have been long-term, and I haven’t had to close...

First, some housekeeping: I’ll make this newsletter bi-weekly for a while. Does bi-weekly actually mean “every other week”, or“two times a week”? 🙂 In this case, it’s the former one: I’m dialing the pace down a bit to keep it sustainable. I’d like to return to a weekly rhythm again later, though! Okay, with that out of the way, on to this week's topic. Many software developers experience impostor syndrome, and it’s extra frustrating when you’re working as an independent contractor/consultant....

How do you get started? This week, we’ll go through the concrete steps you likely need to take after you decide to try contracting/consulting—this is the initial step-by-step guide I wish I had back when I decided I’d had enough of being an employee. As always, I wish you a great week! ☕ “OK, I think freelancing software development is right for me. What steps should I take to get there?” I’ve laid out the most important steps below. Note that some details may change slightly depending on...