When we estimate how long a project will take, we need to start with a fundamental understanding: we will always be wrong. No matter how much experience we have or how carefully we analyse the work, unforeseen factors will influence the outcome. The goal of estimation is not to predict an exact completion date but to provide a reasonable timeframe that allows for flexibility and adaptability.
There is no secret formula for perfect estimates. What I’m sharing here is the best advice I can offer based on my over seventeen years-experience in the industry.
Estimate With Information
Before we estimate a project, we need essential details, like the goal, rough scope, and the work involved. When we’re asked for a date, we’re effectively committing to it, so it’s only fair that we take the time to gather the right information first.
A completion date isn’t just for planning; leadership shares it both internally and externally. In large organisations, finance analysts may even factor these dates into risk assessments, which can influence stock prices. Once a date is out in the open, the pressure to meet it is huge, even if circumstances change. You can read more about this in my previous article The Paradox of Agile Estimation.
That’s why estimates shouldn’t be rushed. Instead, we need to make sense of the available data. If the team is unfamiliar with the tech stack or lacks experience, this step becomes even more critical.
Estimates will never be perfect, but they need enough context to be meaningful. Otherwise, they’re just arbitrary numbers. When I’m asked to provide an estimate without enough information or time to consider them, I decline. If someone is asking me, they want my insight. If I don’t have what I need to form an informed opinion, my estimate is just a random guess, and anyone can do that. If we’re going to base decisions on numbers pulled from thin air, I’d rather not be involved.
A More Effective Approach to Estimation
A common but flawed way to estimate a project is to break down the work into tasks, estimate each one, add them up, and call that the project timeline. If things always went to plan, this might work—but in reality, every project runs into unexpected roadblocks. Overconfidence, unknowns, dependencies, and shifting priorities all throw off initial estimates.
Instead of estimating task-by-task in days or hours, I recommend grouping work into broader units like weeks, fortnights, or months, depending on the level of detail needed, and rounding up as you go. This gives us a buffer and helps avoid underestimating the work.
The first estimate we come up with is really just the minimum time the project could possibly take. We know it won’t be done any faster, but it’s almost certainly going to take longer. If we present this as the final estimate, we leave ourselves no room to deal with the inevitable challenges that will come up.
To get to a more realistic timeframe, we need an upper bound. Some teams use multipliers—1.5x, 2x, or more—while others look at similar past projects to get a sense of what’s reasonable. Either way, this step helps account for delays, changes, and unforeseen complications, giving us a more practical estimate to work with.
The goal isn’t to predict the exact end date, but to make sure that we have enough time to navigate the uncertainties of the project while still delivering something valuable.
To see why this matters, imagine a project where the estimate is so tight that by the time we’ve set up repos, environments, and basic architecture, we’re already out of time. There’s nothing left to cut: trimming features won’t help if we haven’t even built the foundations, even if we rush things at the expense of quality or if we throw more people hoping to speed things up.
This is where the Project Management triangle comes in. If we don’t give ourselves enough time in the first place, we have nothing to manoeuvre with. You can read some insights into this in my article Project Triangle And Software Quality
Good estimates aren’t about guessing the exact finish line—they’re about giving us enough room to deliver something valuable without setting ourselves up to fail. If we rush the process, we end up with random numbers that create pressure for no good reason. Breaking things down into tiny tasks might feel precise, but it doesn’t account for the unexpected. Instead, we should focus on gathering the right information, rounding up to give ourselves breathing room, and setting a realistic range instead of a single number. Estimates will never be perfect, but they can at least be useful.
Cheers,
José Miguel
Share if you find this content useful, and Follow me on LinkedIn to be notified of new articles.