Appearance
Estimating
An estimate is a considered best guess, not a commitment.
This page provides guidelines on producing estimates and, just as importantly, what to do when they turn out to be wrong.
Why estimate
If estimates are nearly always inaccurate, why bother?
Fixed-price projects, while not ideal, are often mandated by commercial realities. A good estimate provides a reasonable basis for negotiating the final price with the customer.
For time and materials (TAM) projects, estimates are about informing decisions. Project managers can use forecasted times and costs to prioritise work with the customer and schedule resource accordingly.
Producing an estimate
Don't necessarily assume you will be the developer assigned the work:
- Estimate based on a competent developer who is already familiar with the codebase – not the fastest or slowest person on the team, and not assuming ramp-up time on an unfamiliar project.
- If the assigned developer is known ahead of time and is likely to be notably faster or slower than that baseline, then adjust the estimate accordingly. Flag any such adjustment so a PM reviewing the estimate understands why it differs from what they might expect.
Allow for the work required to complete the task beyond the initial development effort. Include iterating on the solution, testing, bug fixing, and any specific deployment steps.
Add a balanced amount of contingency to the estimate. Don't pad it arbitrarily, but also don't assume nothing will go wrong.
Use whatever unit suits the size of the work: hours for a small task, days or weeks for larger tasks. For large fixed-price projects, break the estimate into smaller pieces rather than one large figure.
If applicable, make a record of any specific solutions you have in mind. Avoid granular detail, but provide enough information to guide another developer (or future you).
When an estimate turns out to be wrong
Estimates can turn out to be wrong for several reasons, including:
- Changing customer requirements
- Unexpected complexity
- Incomplete information at the time of estimating
- An estimate that was simply inaccurate
As soon as it becomes clear an estimate will be exceeded, flag it – before finishing the work, not after.
The decision on what happens next goes to the PM or account manager. Don't unilaterally decide to eat the extra time or keep going silently.
TIP
Flagging early gives the PM options. Flagging after the work is already done leaves them with none.
For TAM projects, this protects the customer relationship. The total time taken may end up the same regardless, but customers will be happier having been involved in the decision than simply being handed a bill that's larger than expected.
Options are more limited for fixed-price projects, but the earlier issues are flagged, the more likely it is that a change in price or scope can be negotiated with the customer.