The proposal says 60 hours because the last proposal said 60 hours. Nobody checks that the last project took 94.
It is an easy habit to establish. The old estimate is sitting in the proposal template. The actual hours are somewhere else, divided across people and tasks. Copying the number takes seconds; investigating it takes a deliberate pause.
To estimate project hours from past work, choose comparable completed projects, group their actual hours into delivery phases, and adjust for the new scope, team, and risks. Record the assumptions alongside the total. When the project finishes, compare the estimate with what happened and update the baseline.
Choose comparisons you can explain
Start with a few recent projects whose work resembles the new brief. Three is a manageable starting point, although a small sample is a reference rather than a statistical guarantee.
“Website” is too broad a comparison. A brochure site with supplied copy differs from a site that needs content development, a product catalog, and a booking integration. Look at deliverables, technical dependencies, review rounds, stakeholder count, and who supplied the inputs.
Check the records before using them. A completed project with missing timesheets will make the next job appear easier than it was. Include project coordination, internal review, testing, and work your agency absorbed. Those activities consumed delivery capacity even when they did not appear on an invoice.
Compare phases before copying totals
Imagine three completed landing-page projects with similar requirements. These figures are illustrative:
| Delivery phase | Project A | Project B | Project C | Median hours |
|---|---|---|---|---|
| Discovery | 8 | 10 | 9 | 9 |
| Design | 18 | 22 | 20 | 20 |
| Development | 30 | 36 | 33 | 33 |
| Testing and revisions | 10 | 16 | 13 | 13 |
| Project coordination | 8 | 10 | 9 | 9 |
| Total | 74 | 94 | 84 | 84 |
Using the median for each phase gives this example an 84-hour starting point. It is a convenient reference, not proof that the next project will take 84 hours. With other data, the sum of phase medians may differ from the median of project totals.
The phase breakdown makes the estimate easier to challenge. If the new brief needs less design but considerably more testing, adjust those parts directly. A single project total hides that judgment.
Investigate unusual projects before excluding them. A one-off migration failure may deserve separate treatment. Repeated extra review rounds may belong in your ordinary delivery assumptions.
Make the adjustments visible
Suppose the new project resembles the historical baseline but introduces another stakeholder group and a CRM connection the team has not implemented before.
You might build the estimate this way:
| Component | Hours | Assumption |
|---|---|---|
| Historical delivery baseline | 84 | Comparable scope and staffing |
| Additional review and coordination | 6 | One additional stakeholder review cycle |
| CRM connection | 8–16 | Access and documentation supplied before implementation |
| Planning range | 98–106 | Subject to confirming the integration requirements |
The range follows from the assumptions: 84 + 6 + 8 at the lower end, and 84 + 6 + 16 at the upper end. It is not a confidence interval or a guarantee.
Name what would invalidate it. Missing API capabilities, unreliable test data, or a requirement for custom middleware could change the integration work substantially. If those questions dominate the estimate, scope a discovery task before committing to the implementation fee.
Routine work belongs in the baseline. Any contingency should cover identified uncertainty without counting the same risk twice.
Separate hours, schedule, and price
A 100-hour estimate does not establish a delivery date. Work may depend on one specialist, client feedback, or tasks that must happen sequentially. Check the proposed work against available team capacity before promising the calendar.
It does not establish the price either. Apply the expected staffing mix and cost of delivery hours, then account for direct project expenses and the margin your business needs. Keep the cost assumptions consistent so you do not count overhead twice.
If the client's budget is below what the scope requires, revise the scope, staffing, or commercial terms explicitly. Lowering the estimated hours without changing the delivery plan leaves the same work to be done.
Keep learning while the project is running
During delivery, update the forecast using hours already worked plus the current estimate to finish. That exposes a developing overrun while there is still time to respond.
At close, compare estimated and actual hours by phase. Record why they differed: missing scope, additional revisions, unexpected technical work, a different staffing mix, or an improvement in how the team delivered.
Distinguish extra deliverables from an inaccurate estimate of the original work. Both affect the project, but they require different changes to the next proposal.
Time Trakkr provides budget-versus-actual reporting and CSV exports to support that review. Add a short explanation of the variance while the team still remembers it. The next person preparing a quote should inherit both the hours and the reason behind them.
