Start with work content, not a guessed finish time
A useful estimate begins by describing the work that must happen. Instead of asking only “Can this be done by Friday?”, break the job into meaningful pieces: preparation, the main work, review, handoff and cleanup. Estimating those pieces separately exposes hidden time that a single round-number guess tends to miss.
For unfamiliar work, use a range rather than pretending to know an exact answer. A best-case, expected and difficult-but-plausible case can be more useful than one false-precision number. The range is especially important when approvals, supplier responses, access windows or other people control part of the elapsed time.
Separate active time from elapsed time
Active time is the effort someone spends working. Elapsed time is how long the calendar advances before the work is truly complete. A task can require two hours of hands-on effort but take two days to finish because it includes a one-day waiting period or depends on someone else’s response.
This distinction also helps with staffing. Adding people may reduce active work on some tasks, but it does not necessarily shorten a fixed wait or an external approval. Use the Task Duration Calculator for straightforward work and the Project Duration Calculator when tasks can run in parallel.
Add the pieces people routinely forget
Include setup, locating materials or information, access, travel within a facility, system login, file preparation, cleanup, documentation and the transition to the next task. Small pieces can dominate short jobs. A 20-minute job that needs 15 minutes of preparation and 10 minutes of cleanup is not a 20-minute commitment.
Use a buffer for normal uncertainty, not as a substitute for thinking. If the task is new, variable or dependent on others, a larger buffer can be reasonable. If it is stable and measured repeatedly, historical results should eventually replace generic buffer percentages.
Improve the estimate after the work
Record the original estimate and the actual outcome. The goal is not to prove that an estimate was right; it is to learn why it differed. Was the task itself slower, was setup missing, did waiting time dominate, or was the scope different? Over several repetitions, those notes become a useful local dataset.
Good estimating is therefore a feedback loop: define the work, estimate it, perform it, compare the result and adjust the model. That is more reliable than chasing universal “how long” answers for work that depends heavily on local conditions.