Define the deliverable before estimating the hours
You cannot produce a defensible estimate for a vague noun such as website, campaign, integration or redesign. First describe the observable result: pages, states, formats, integrations, devices, supplied content, approval process and acceptance criteria.
Write a short definition of done for every deliverable. If two reasonable people could disagree about whether the work is complete, the scope is not yet specific enough to estimate. Clarifying it now is cheaper than debating it after the budget is gone.
- What will be delivered and in which format
- What the client must provide, and by when
- Which devices, browsers or platforms must be supported
- How many concepts, variants and revision rounds are included
- What is explicitly excluded from the estimate
Break the work into chunks small enough to challenge
Split the deliverable into tasks that usually take between one and eight hours. A task called build the application for 60 hours hides too many assumptions. Authentication, account states, form validation, responsive layout, analytics and deployment can each be estimated and reviewed separately.
Separate repeatable work from uncertain work. A page built from an existing component library is not the same risk as an undocumented third-party integration. Combining them into one number makes the familiar work subsidize the unknown work.
Use three-point estimates for uncertain tasks
For a task with meaningful uncertainty, record an optimistic, most likely and pessimistic duration. A practical weighted estimate is: expected hours = (optimistic + 4 × most likely + pessimistic) ÷ 6.
Suppose an integration could take 4 hours if the documentation and access are correct, 8 hours in the most likely case and 20 hours if the API behaves badly. The weighted estimate is 9.3 hours. The formula does not make uncertainty disappear; it stops the optimistic case from quietly becoming the official plan.
If the pessimistic result would break the project, do not hide it inside a percentage. Offer paid discovery, an hourly phase or a decision checkpoint before committing to a fixed total.
Count hidden work and client dependencies
Production time is only part of delivery. Discovery, meetings, status updates, preparing files, reviewing feedback, testing, accessibility checks, handover and deployment all consume capacity. If they are required by the project, they belong in the estimate.
Dependencies need an owner and a deadline. Waiting for access or content may not create billable hours, but it can move the delivery date and force costly context switching. State what happens when an input arrives late instead of pretending the schedule is immune to physics.
- Discovery, research and requirements clarification
- Project management and consolidated client communication
- Content preparation, migration or data cleanup
- Quality assurance, accessibility and device testing
- Included revisions, deployment and handover
- Direct expenses and specialist subcontractors
Worked example: a small website update
A five-page website refresh needs 4 hours for discovery and structure, 10 for design, 22 for implementation, 8 for content entry and quality checks, 5 for communication and handover, and 5 for the included revision round. The defined work totals 54 hours.
A CRM integration is still uncertain. Its three-point estimate is 4, 8 and 20 hours, producing 9.3 expected hours. Add a small 20% fixed-price allowance only to that uncertain task: 1.9 hours. The planning total is about 65 hours, not 54 and not a random 70.
Internally, keep the task-level estimate. In the client proposal, present the deliverables, assumptions, included revisions, price and schedule. Hours are evidence for your decision; they do not have to become a courtroom transcript attached to every quote.
Turn every completed project into estimation data
Track actual time against the same task categories used in the estimate. After delivery, record where the difference came from: unclear requirements, client delay, technical surprise, rework, or simply an estimate that was too optimistic.
After several projects, replace generic buffers with your own ranges. You may learn that implementation is predictable while content preparation and approvals are not. That is useful operational data—and considerably more valuable than asking the internet how long a website should take.
- Compare estimated and actual hours by task, not only by project total
- Keep notes on the cause of every material variance
- Update reusable task templates after delivery
- Review large estimates with another professional before committing
Put the method into a real estimate
Break the work into tasks, apply time and rates, add discount or tax, and create a clean client-ready PDF without registration.
Open the free calculatorFrequently asked questions
How much buffer should I add to a project estimate?
There is no universal percentage. Name the uncertain tasks and add time or cost for those risks. When uncertainty dominates the project, use paid discovery or hourly billing instead of disguising it with a large buffer.
What if I have no historical project data?
Start with a detailed task breakdown, use three-point estimates for unknown work, ask a peer to challenge the assumptions, and separate discovery from delivery when the range is too wide.
Should I show the client every estimated hour?
Not necessarily. Keep detailed estimates internally and show the client clear deliverables, assumptions, boundaries, milestones, price and the process for changes.
