Name a more iconic duo than tech projects and running over the estimated time. You can’t estimate a project perfectly – that’s why it’s called an estimate. But you can become one of those people who is a better estimate-r than others. Today, I’ve got three little tricks to keep in mind when you’re asked to estimate a project, brought to you by years of pushed-back deadlines and grumpy stakeholders.

🧮 The math isn’t mathing.

Most people estimate based on a 40-hour work week, but you don’t actually get to spend all 40 of those hours on your project. If you factor in lunch, standups, retros, bathroom breaks, spontaneous conversations, town halls, 1:1s, and everything else you have going on at work… it’s probably more like 27 hours.

If you’re estimating project timelines in months or more, you need to remember that a week on this project is not your full 40 hours. You don’t need to estimate down to the hour, but just keep this in mind when considering what you can realistically accomplish in a week.

🙃 Double it and give it to the next person?

I always, always add buffer to my estimates before I give them to a project manager. Depending on your confidence (and your experience with your stakeholders) that might be adding an extra day to everything, doubling all your estimates, or just slapping an extra two weeks on the end for coverage. But never give your actual estimate, because you just estimate the “happy path” – what you think it will take if all goes right. But it never covers debugging weird stuff, stakeholders changing their mind, or the new Figma update that breaks your design system.

And a bonus lesson I’ve learnt the hard way… you’re estimating the time it takes you to complete the task, not the time it takes to do the task. I once estimated it would take me 20 minutes to write App Store copy. It did only take me 20 minutes, but I didn’t get to it until the next day because of all the meetings and other urgent work, which means it really took a day. Now if I’m asked to estimate copy I say a day.

🪶 It’s an estimate, not a contract.

(Unless you work at an agency, in which case… maybe it is.)

Estimates are estimates, they’re never going to be perfect. The less you know about something, the less likely you’ll be to reasonably estimate how long it will take. And even if you follow a waterfall approach of breaking the entire project down at the start, you will still discover things along the way that blow out your timeline.

When I have to estimate something I’m really unfamiliar with, I make sure to:

• estimate way more time than I think it needs (complexity = time!), and

• tell the project manager or other stakeholders that I will revise my estimate when I learn more information.

Ideally, you’ll try to demystify these unknown complex components really early in the project to get the best timeline as soon as possible, but that can’t always happen. It’s disappointing when timelines blow out, but it’s more disappointing to have to tell everyone near the end that you’re going to miss the deadline.

I know, I know… we didn’t talk about how estimates shouldn’t equal project timelines. But unfortunately, there’s nothing we can do about that! Projects need timelines and people need to plan, and the estimate’s the best they’ve got, so it’s not going away.

But you can get better at estimating if you practice. Try evaluating your original estimate vs. your actual timeline for a few projects and see how far off you are.