I estimated two days, but the task took five. Why did I underestimate it?
Possible planning fallacyThis can reflect planning fallacy: relying on an optimistic internal story rather than comparable actual results. One overrun alone does not prove bias, so also check scope changes, waiting time, and interruptions.
What to do now
- Define what done included
- Compare similar tasks and their actual durations
- Separate effort from waiting and rework
- Use a justified range for the next estimate
When to escalate
Repeated underestimation threatens a committed milestone.
The project manager and relevant commitment owner
Example
A two-day build took five elapsed days because review waited two days and a defect required another day.
Mistake to avoid
Multiplying every estimate by an arbitrary factor without checking causes.
Prevent a repeat
Compare forecast versus actual results for comparable tasks, separating effort, elapsed time, waiting and scope change.
Suggested ApprovedFlow setup
- Tasks
- Timesheets
- Resources
Keep planned dates and assumptions with the affected task, compare recorded actuals, and attach the revised forecast for review. See the platform
Related cases
- The estimate includes coding but not testing or rework. How should we revise it?Incomplete work estimate
- Every task is on time, but the project is late. What are we missing?Missing schedule relationships
- The resource plan is monthly, but tasks change daily. How should they connect?Planning-granularity mismatch
- We communicate changes, but people say they did not know. What is missing?Broadcast without confirmation