Software Development
Project Estimation: A Comprehensive Guide to Getting It Right
Software estimates are almost always wrong for structural reasons. Here is the estimation framework that reduces overruns and sets honest expectations.
Project estimation is one of the most consistently misjudged activities in software development. The consequences of poor estimation are familiar: projects that run twice over budget, timelines that slip by months, and relationships between clients and agencies that deteriorate from early optimism to mutual frustration. Better estimation practices prevent all of this.
Why project estimates are almost always wrong
- The planning fallacy: humans systematically underestimate time required for tasks they have performed before, let alone novel ones
- Unknown unknowns: the parts of a project that cause the most slippage are the ones nobody knew to estimate
- Scope ambiguity: estimates based on loosely defined requirements will be wrong because the requirements themselves are wrong
- Optimism bias: all humans — and particularly confident developers — underweight the probability of negative events
- External dependencies: third-party APIs, client content delivery, and approvals are outside the project team’s control
Estimation approaches
Bottom-up estimation
Decompose the project into individual tasks, estimate each independently, and sum the results. Most accurate for well-understood work where tasks can be clearly defined.
Analogical estimation
Estimate based on similar projects completed previously. Accurate when the comparison project is genuinely similar. Best used alongside bottom-up, not instead of it.
Three-point estimation (PERT)
For each task, estimate optimistic (best case), pessimistic (worst case), and most likely. The PERT formula (O + 4M + P) / 6 produces a weighted average accounting for uncertainty. More statistically sound than single-point estimates.
Story points (agile)
Relative sizing using abstract units (Fibonacci sequence: 1, 2, 3, 5, 8, 13) based on complexity relative to reference tasks. Combined with a team’s measured velocity, produces reasonably accurate sprint-level predictions.
The estimation process that works
Never estimate against vague requirements. The scope must be specific enough that two different developers would make the same assumptions about what is included.
Break work down to tasks of 4-16 hours. Anything estimated at more than 16 hours contains hidden complexity. Decomposing forces discovery of unknowns before they become surprises.
Have team members estimate individually, then compare. Differences reveal disagreement about complexity or assumptions — these discussions are where estimation is most valuable.
Report the 80th percentile (the estimate you are 80% confident will not be exceeded) rather than the 50th percentile.
Add 20-30% to the bottom-up estimate for known-unknowns. Add more if requirements are poorly defined or technology is new to the team.
Compare estimated vs actual hours at task level after every sprint. This builds calibration data that makes future estimates more accurate.
Estimation anti-patterns
- The single-point estimate: ‘This will take 3 weeks’ stated with false confidence. Always express uncertainty as a range.
- Estimating without reading the requirements: numbers given without reading the spec mean nothing and should not be treated as commitments.
- The best case as baseline: the best case is the baseline in optimistic teams. Add probability-weighted buffers.
- Never revisiting estimates: estimates should be living documents, updated as new information arrives.
- Not accounting for overhead: developers are productive for 5-6 hours per 8-hour day. Estimate for this reality.
Communicating estimates to clients
- State ranges, not single points: ‘8-12 weeks’ is more honest and more useful than ’10 weeks’
- Explain what the estimate is based on: ‘This estimate assumes the requirements as documented on [date].’
- Distinguish between phases: provide more confident estimates for the next phase; express uncertainty for later phases
- Create a risk register: document assumptions and risks that, if they materialise, would change the estimate
Working on a digital project and need a realistic estimate?
Simple Automation Solutions provides detailed project estimates after a discovery phase — with clear scope documentation and honest uncertainty ranges.
Frequently asked questions
Why do software projects always go over budget and time?+
The core reasons: scope creep without corresponding estimate adjustment, poor initial estimation due to optimism bias, unknown technical dependencies discovered mid-project, and inadequate communication about estimate uncertainty. The most impactful intervention is enforcing scope documentation before estimation begins.
How do I hold an agency accountable to their estimate?+
An estimate is not a contract. A fixed-price quote is a contract. If you want accountability to a specific number, negotiate a fixed-price contract with a defined scope, a change control process, and acceptance criteria.
What is a reasonable contingency to add?+
Well-defined work on familiar technology: 10-15%. Moderate ambiguity: 20-30%. High ambiguity (novel technology, complex integrations): 30-50%. R&D-type work where the approach is genuinely unknown: time-box it rather than estimate.
