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.<\/p>\n\n\n\n
There is no secret formula for perfect estimates. What I\u2019m sharing here is the best advice I can offer based on my over seventeen years-experience in the industry.<\/p>\n\n\n\n
Before we estimate a project, we need essential details, like the goal, rough scope, and the work involved. When we\u2019re asked for a date, we\u2019re effectively committing to it, so it\u2019s only fair that we take the time to gather the right information first.<\/p>\n\n\n\n
A completion date isn\u2019t 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<\/a>.<\/p>\n\n\n\n That\u2019s why estimates shouldn\u2019t 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.<\/p>\n\n\n\n Estimates will never be perfect, but they need enough context to be meaningful. Otherwise, they\u2019re just arbitrary numbers. When I\u2019m 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\u2019t have what I need to form an informed opinion, my estimate is just a random guess, and anyone can do that. If we\u2019re going to base decisions on numbers pulled from thin air, I\u2019d rather not be involved.<\/p>\n\n\n\n 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\u2014but in reality, every project runs into unexpected roadblocks. Overconfidence, unknowns, dependencies, and shifting priorities all throw off initial estimates.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The first estimate we come up with is really just the minimum time the project could possibly take. We know it won\u2019t be done any faster, but it\u2019s 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.<\/p>\n\n\n\n To get to a more realistic timeframe, we need an upper bound. Some teams use multipliers\u20141.5x, 2x, or more\u2014while others look at similar past projects to get a sense of what\u2019s reasonable. Either way, this step helps account for delays, changes, and unforeseen complications, giving us a more practical estimate to work with.<\/p>\n\n\n\n The goal isn\u2019t 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.<\/em><\/p>\n<\/blockquote>\n\n\n\n To see why this matters, imagine a project where the estimate is so tight that by the time we\u2019ve set up repos, environments, and basic architecture, we\u2019re already out of time. There\u2019s nothing left to cut: trimming features won\u2019t help if we haven\u2019t 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.<\/p>\n\n\n\n This is where the Project Management triangle comes in. If we don\u2019t 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<\/a><\/p>\n\n\n\n Good estimates aren\u2019t about guessing the exact finish line\u2014they\u2019re 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\u2019t 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.<\/p>\n\n\n\n Cheers,A More Effective Approach to Estimation<\/h3>\n\n\n\n
\n
\n\n\n\n
Jos\u00e9 Miguel<\/p>\n\n\n\n