A Guide to Accurate Time Estimation

A partner scopes a discovery engagement at 400 hours. The proposal goes out, the client signs, and the team starts work. Nine weeks later, the project closes at 560 hours. Nobody did anything wrong, nobody flagged anything, the work got delivered, the client is happy, and the firm still lost money on it.

That is what a bad time estimate looks like inside a billable business. It never announces itself as a failure. It shows up a quarter later as a margin number nobody can explain, and by then the engagement is closed, and there is nothing left to reprice.

This guide covers how to estimate project time properly: what the established techniques actually do, when to use each one, how much buffer is defensible, and the step most firms skip, which is closing the loop between what you estimated and what the work actually took.

What Is Time Estimation in Project Management?

Time estimation in project management is the process of forecasting how long a piece of work will take, at task, phase, or whole-project level. It is usually expressed in two related but different units.

Effort is how many person-hours the work consumes. A task might take 24 hours of effort.

Duration is how much calendar time passes before it is done. Those same 24 hours, split across a consultant who is only 60 percent available, spread over five working days.

Confusing the two is one of the most common estimating errors in project firms. You estimate effort, then quote duration as though your team is available full time on one project, which almost never happens. Industry-wide billable utilization sits well below full availability. SPI Research’s 2025 Professional Services Maturity Benchmark treats 75 percent as the optimal threshold, and most firms are running below it. If you plan durations at 100 percent availability, your schedule is wrong before the work starts.

Accurate estimation feeds three things at once: the delivery schedule, the price you quote, and the capacity plan that decides who can take on the next piece of work.

Why Estimates Miss So Consistently

The scale of the problem is worth stating plainly, because it tells you the cause is structural rather than a failing of your particular team.

Flyvbjerg and Gardner assembled a database of around 16,000 projects across 20-plus fields and 136 countries. Writing in Harvard Business Review, they report that only 8.5 percent were delivered on time and on budget, and a mere 0.5 percent came in on time, on budget, and with the promised benefits.

Four things drive most of the gap:

The Planning Fallacy

Kahneman and Tversky coined the term in 1979 to describe a specific, repeatable bias: people underestimate how long a task will take, even when they have personally done the same task before and know it ran long. The bias survives experience. Asking your most senior consultant to estimate from memory does not remove it, and in some cases the confidence makes it worse.

The correction is documented too. Kahneman called taking the “outside view,” meaning using distributional data from a class of similar past projects rather than reasoning from the specifics of this one, the single most valuable step available for improving forecast accuracy. That method is reference class forecasting, covered below.

Scope That Moves After You Quote

PMI’s 2018 Pulse of the Profession found that 52 percent of projects completed in the previous 12 months experienced scope creep, up from 43 percent five years earlier. The same report puts the cost of poor project performance at 9.9 percent of every dollar invested.

An estimate built against a fuzzy scope is really just a number attached to a hope, and it will move every time the client’s understanding of the deliverable moves.

The Work Nobody Counts

Client calls. Revision rounds. Internal reviews. Onboarding a new team member mid-project. Waiting three days for client sign-off while your consultant sits idle. These hours are real and they are frequently absent from the estimate, because the estimate was built by listing deliverables rather than listing everything the team will actually do.

No Historical Baseline

Most firms cannot answer “how long did this take us last time” without a week of spreadsheet work. So the next estimate gets built from memory, which is exactly the input the planning fallacy corrupts. Without clean timesheet data, every estimate starts from zero.

What a Bad Estimate Actually Costs a Billable Firm

Generic project management advice treats a missed estimate as a schedule problem. In a services firm, it is a margin problem, and the arithmetic is worth walking through.

Take the 400-hour engagement from the opening. Quoted fixed-fee at a blended 150 currency units per hour; that is 60,000 in revenue.

Scenario	Hours Delivered	Revenue	Effective Rate	Change
On estimate	400	60,000	150.00	Baseline
15% over	460	60,000	130.43	Down 13%
40% over	560	60,000	107.14	Down 29%
70% over	680	60,000	88.24	Down 41%

A 40 percent overrun cuts your realized rate by 29 percent. If your target margin was 30 percent, that project is now at or below cost, and you delivered it while telling the client everything was fine.

The second cost is the one you never see on an invoice. Those 160 extra hours came out of someone’s capacity. They were unavailable for the project you could have sold. Overruns do not just eat margin on the project that overran; they suppress billable utilization across the whole firm.

This is why estimation accuracy sits alongside utilization and realization as a core operating metric for project-driven firms, and why it belongs in the same conversation as project profitability tracking.

Six Time Estimation Techniques and When to Use Each

There is no universally correct method. Mature firms use two or three in combination and reconcile the results.

Technique	Best For	Effort Required	Typical Accuracy
Analogous (top-down)	Early proposals, rough order of magnitude	Low	Low to moderate
Parametric	Repeatable, unit-based work	Low once calibrated	Moderate to high
Bottom-up	Well-defined scope, detailed SOWs	High	High
Three-point / PERT	Anything with real uncertainty	Moderate	Moderate to high
Reference class forecasting	Correcting known optimism bias	Moderate	High
Delphi / planning poker	Novel work, no historical data	Moderate	Moderate

1. Analogous Estimating (Top-Down)

You take a completed project of similar type and size and scale the estimate from it. A 6-week ERP rollout for a 40-person client suggests something in that neighbourhood for the next 40-person client.

Use it for the first conversation with a prospect, when someone asks for a ballpark. It is fast and it is defensible as a range. Do not use it to price a fixed-fee contract.

2. Parametric Estimating

You establish a rate per unit and multiply. 3.5 hours per test case, 12 hours per architectural drawing sheet, 2 days per data migration table. This works well when the work genuinely is repeatable, and you have enough historical entries to trust the rate.

The catch is calibration. A parametric rate pulled from a hunch is worse than a range, because it produces a precise-looking number with nothing behind it. The rate has to come from logged hours.

3. Bottom-Up Estimating

You decompose the project into a work breakdown structure, estimate each task individually, then roll it up. This produces the most accurate result for a well-defined scope, and it is the only method that gives you a schedule you can actually manage against.

The cost is time. Bottom-up estimation on a large project can take days of senior effort, which is why it usually happens after a deal is likely rather than during first contact.

A practical rule: no leaf-level task should be estimated at more than 40 hours. If it is bigger than a week of one person’s work, it is not decomposed enough to estimate reliably.

4. Three-Point Estimating and PERT

Instead of one number, you produce three: optimistic (O), most likely (M), and pessimistic (P). The Program Evaluation and Review Technique then weights them.

PERT expected value:

E = (O + 4M + P) / 6

Standard deviation:

SD = (P − O) / 6

Worked example. A migration task: optimistic 20 hours, most likely 32, pessimistic 60.

E = (20 + 128 + 60) / 6 = 208 / 6 = 34.7 hours

SD = (60 − 20) / 6 = 6.7 hours

So you plan 34.7 hours, and you know roughly 68 percent of outcomes should fall between 28 and 41.4 hours, and roughly 95 percent between 21.3 and 48.1. That range is the useful output. It tells you how much risk you are carrying, which tells you how much contingency the commercial terms need.

Three-point estimation also does something subtle and valuable in a team setting. Asking someone for a pessimistic case permits them to voice a risk they would not have raised against a single-number question.

5. Reference Class Forecasting

This is the outside view in practice, and it is the method most directly aimed at the planning fallacy.

1. Define a reference class of past projects genuinely similar to this one. Same work type, comparable size, comparable client profile.
2. Pull the actual outcomes for that class from your own records, specifically the distribution of estimated hours against actual hours.
3. Position the new project against that distribution rather than against your intuition.

If your last eleven fixed-fee implementations averaged 23 percent over estimate, and your bottom-up number for the twelfth is 400 hours, the outside view says plan for roughly 492. You will resist that number. That resistance is the bias, showing itself.

Reference class forecasting requires one thing most firms do not have: clean, queryable history of estimated versus actual hours by project type. That is a systems question more than a methodology question.

6. Delphi and Planning Poker

Several estimators submit numbers independently, without seeing each other’s. Divergences get discussed, then everyone re-estimates. Repeat until the spread narrows.

The independence is the whole point. In an open room, the first number spoken anchors everyone else, and the most senior voice anchors hardest. Delphi removes both effects. Use it when the work is genuinely novel and you have no historical class to draw on.

How to Estimate Time for a Project in Seven Steps

Step 1: Freeze the Scope in Writing

Before any number gets written down, produce a deliverables list with explicit exclusions. The exclusions matter more than the inclusions. “Two rounds of revision, further rounds billed at standard rate” is what stops the 52 percent scope creep statistic from becoming your project.

Step 2: Break the Work Down

Decompose to tasks of 40 hours or less. Include the non-deliverable work: kickoff, status calls, internal QA, handover, documentation, client training. If it consumes a person’s hours, it belongs in the breakdown.

Step 3: Estimate Each Task With Three Points

Run PERT on any task carrying real uncertainty. Use a single number only for work you have done many times and can price parametrically.

Step 4: Check Against a Reference Class

Roll up the bottom-up total, then compare it against actuals from similar completed projects. If your bottom-up figure sits below the historical average for that class, you need a reason more specific than “this team is stronger.”

Step 5: Convert Effort Into Duration

Apply real availability. If a consultant is realistically 65 percent available to this project, 100 hours of effort is not two and a half weeks; it is closer to four. Then map dependencies and identify the critical path, since only the critical path drives the end date.

A Gantt view is the fastest way to see whether your duration math survives contact with dependencies.

Step 6: Add Buffer Deliberately, at the Right Level

Buffers belong at the project level, not sprinkled across every task. Task-level padding gets consumed automatically, because work expands to fill the time allocated. A single project-level buffer that a PM releases against specific realized risks is defensible and controllable.

Sizing guidance based on how well you know the work:

Situation	Suggested Buffer
Repeat work, same client, mature reference class	10 to 15%
Familiar work, new client or new environment	15 to 25%
New service line, new technology, or heavy dependencies	25 to 40%
R&D or genuinely first-of-its-kind	Do not fix-price it

If the pessimistic-to-optimistic spread from your PERT work is wide, your buffer should be at the top of the band. The standard deviation you calculated is telling you something.

Step 7: Validate the Estimate Against Capacity

An estimate is only real if the people exist to deliver it. Check the number against your actual resource plan before it goes into a proposal. A perfectly accurate estimate for a team that is already 95 percent committed is still a project that will run late.

The Loop Most Firms Skip: Estimate vs Actual

Everything above is standard practice, and it is where most guides stop. The thing that separates firms whose estimates improve from firms whose estimates stay flat is what happens after delivery.

Track Estimation Accuracy as a Metric

Estimation accuracy:

Accuracy % = (1 − |Estimated − Actual| / Actual) × 100

Effort variance:

Variance % = ((Actual − Estimated) / Estimated) × 100

On the opening example: 400 estimated, 560 actual. Accuracy is 71.4 percent. Variance is +40 percent.

Track these per project, then segment them. Variance by project type. Variance by estimator. Variance by client. The patterns that emerge are specific and actionable in a way that a firm-wide average never is.

A firm might find its implementation projects run 8 percent over while its discovery engagements run 45 percent over. The problem is isolated to one service line, which probably needs a different scoping process or a different commercial model.

Set a Threshold and Review Live

Decide the variance level at which a project gets escalated. Fifteen percent over budgeted hours at any milestone is a common trigger. The point of a live threshold is that it fires while there is still room to act, whether that means renegotiating scope, adding a change order, or reallocating people.

The failure pattern is finding out at project close. At that point, the number is history.

Feed Actuals Back Into the Next Estimate

Completed projects with clean actuals become your reference class. This only works if the data is trustworthy, which means hours logged against specific projects and tasks as work happens, not reconstructed from memory on the last Friday of the month. Reconstructed timesheets are systematically inaccurate in the direction of round numbers and forgotten work.

Fixed Fee vs Time and Materials: Estimation Carries Different Weight

The commercial model determines how much an estimating error costs you.

	Fixed Fee	Time and Materials
Who absorbs overrun	Your firm	The client
Estimate accuracy required	High	Moderate
Buffer strategy	Priced into the fee	Communicated as a range
Main risk	Margin erosion	Client trust and renewal risk
Best for	Well-defined, repeatable scope	Evolving scope, discovery work

Under time and materials, a missed estimate damages the relationship. Under fixed fee, it damages the P&L directly. If your scope is genuinely uncertain and the client wants a fixed price anyway, the honest options are to run a paid discovery phase first, or to price the fixed fee against your pessimistic case rather than your most likely one.

Common Estimation Mistakes Worth Naming

Estimating with the person who will do the work absent: The partner who sells is rarely the person who delivers. Involve the delivery lead or accept a systematic gap.

Treating the client’s budget as the estimate: Anchoring the number to what the client said they can spend produces a proposal that wins and a project that loses.

Padding quietly: Hidden padding gets consumed and cannot be defended. Explicit contingency can be discussed, tracked, and released.

Ignoring ramp-up: A new team member is not productive on day one. On a three-month project, onboarding a mid-project addition can cost more hours than it adds.

Estimating in isolation from cash flow: A project that runs 40 percent long also collects payment later, which makes an overrun a cash flow problem on top of a margin one.

Never revisiting the estimate: An estimate made at proposal stage and never updated as scope evolves stops being a management tool by week three.

Where the System Matters More Than the Method

Every technique in this guide depends on one input: reliable history of what work actually took. PERT needs realistic optimistic and pessimistic bounds, which come from having seen the range before. Parametric rates need calibration against real units. Reference class forecasting needs a queryable set of comparable projects with estimated and actual hours side by side.

If that data lives in a mix of spreadsheets, an email thread, and someone’s recollection, no amount of estimation technique will fix your accuracy, because the correction loop never closes.

This is where Juntrax fits. Consultants log hours against specific projects and tasks as work happens, with approval workflows, so actuals are captured rather than reconstructed. Project budgets are set in hours and value, and cost tracks against budget in real time, so a project trending 20 percent over budget surfaces while there is still scope to renegotiate. Because PSA, resourcing, and financials sit in one platform, the estimate you made, the hours the team logged, the capacity you have left, and the margin on the engagement are all the same set of numbers rather than four reconciliations.

The practical effect is that estimation stops being an act of memory. When you scope the next engagement of a familiar type, you can look at what the last six actually took.

Frequently Asked Questions

What is time estimation in project management?

Time estimation is the process of forecasting the effort and elapsed time a project or task will require, usually in hours, days, or weeks. It informs the schedule, the price, and the resource plan. Effort measures person-hours consumed; duration measures calendar time elapsed.

What is the most accurate project time estimation technique?

Bottom-up estimation is the most accurate for a well-defined scope, because it builds the total from individually estimated tasks. Its accuracy improves further when combined with three-point estimation for uncertain tasks and validated against a reference class of similar completed projects.

How do you calculate a three-point estimate?

Use the PERT formula: E = (O + 4M + P) / 6, where O is the optimistic estimate, M is the most likely, and P is the pessimistic. The standard deviation is (P − O) / 6, which tells you how much uncertainty the estimate carries.

How much buffer should a project estimate include?

Between 10 and 15 percent for repeat work with a mature history, 15 to 25 percent for familiar work in a new environment, and 25 to 40 percent for new service lines or heavy external dependencies. Hold the buffer at the project level rather than padding individual tasks.

How do you measure estimation accuracy?

Accuracy % = (1 − |Estimated − Actual| / Actual) × 100. Track it per project and segment the results by project type, estimator, and client to find where the error is concentrated.

Why do project estimates almost always run over?

The primary cause is the planning fallacy, a cognitive bias documented by Kahneman and Tversky in 1979, in which people underestimate task completion times even with direct prior experience. Scope creep, uncounted administrative work, and the absence of historical baselines compound it.

What is reference class forecasting?

Reference class forecasting means estimating a project by comparing it against the actual outcome distribution of a class of similar completed projects rather than reasoning from the current project’s specifics. It is the standard correction for the planning fallacy.

How does time estimation affect billable utilization?

Overrun hours consume capacity that could have been sold to another client. A project running 40 percent over both erodes the margin on that engagement and reduces the firm’s available billable capacity, which pushes utilization down across the business.