“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 help 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 see what the known Gotchas are, 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 work 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 days/weeks in a separate step; keep reading).
Tag the most risky and uncertain estimates. For very unclear features, mark them clearly (I usually make them red and bold in my spreadsheets). Estimate those tasks higher 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: “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).
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 completed“! 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: is the overall scope too big?
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 a timeframe of months rather than weeks, it’s a good idea to split the project into multiple parts. Deliver an initial milestone first, learn from it, then regroup and adjust the estimates/timeline for the remaining work: build the next increment. Rinse and repeat until done.
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 over the following weeks or months. 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 February if everything works out like we discussed.”
Track and adjust your estimates during the project
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: https://docs.google.com/spreadsheets/d/19Dnk4g_5xwS_J5I5GA9byaQow6welA5nFK27UXTCW1o
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!