Project cost estimation: estimate the range, then decide how much of it to promise

Project cost estimation is the process of forecasting what a defined scope of work will cost your firm to deliver, before you set a price. Done well, it gives you an expected cost and a spread around it, then a deliberate choice about how much of that range to promise.

Before I joined Teamwork.com, I'd trace most scope creep to the pitch, where a firm underbids to win, then spends delivery arguing about what the low number covered. You'll leave with a per-role estimate worksheet, a contingency figure sized from its spread, and a commit rule for each pricing model.

What a project cost estimate counts before pricing starts

Settle what goes inside the range first: every cost your firm carries to deliver the scope, and nothing the client pays on top. Loaded cost rates, margin and price are a separate step, covered in the guide to pricing professional services projects. Cost estimation in project management stays on the cost side, which has three layers:

• Direct labor: Hours per role multiplied by each role's internal cost rate, usually the largest and least certain line.

• Direct non-labor: Licenses, stock assets, contractors and travel bought for this project, often fixed quotes with no spread.

• Indirect overhead: Shared tools, admin and management time, usually folded into a loaded cost rate instead of listed line by line.

Whichever layer you're pricing, keep cost rates and billable rates apart. An estimate built on billable rates already contains your margin, so you can't see how much risk the price is absorbing. Once approved, the estimate becomes the baseline for your project budget, and any overhead you leave out resurfaces later in your cost to serve.

Assumptions belong in the estimate as well. The agencies I worked at had no shared intake or scoping process, so every project re-decided its scope and the assumptions lived in people's heads. Write them beside the hours instead: who supplies content, how many revision rounds, what's out of scope. An estimate without its assumptions can't be re-estimated, or defended when the client asks what changed.

Choosing a project cost estimation method for the stage you're at

The right estimating method depends on how much scope you can see, which is exactly what your written assumptions tell you. At the pitch you might have a one-page brief, and at sign-off you have a task list. Most projects pass through both stages, so project cost estimation usually takes more than one method.

Estimation method picker

Three-point estimating sits on top of the other three. You can apply optimistic, most likely and pessimistic figures to an analogous total, a unit rate or a bottom-up task list. Bottom-up, for its part, needs a work breakdown structure before it's worth the time.

AACE International's estimate classification for process industries shows ranges narrowing as scope firms up. In its Recommended Practice 18R-97, a concept-stage Class 5 estimate typically runs 20% to 50% low and 30% to 100% high, at 80% confidence. AACE also warns that accuracy ranges should come from risk analysis of the specific project and never be pre-determined.

Those figures describe process plants, not websites or software, so don't borrow them as a services benchmark. Borrow the principle instead: an estimate made from a brief deserves a wide range, and the client deserves a new one when scope gains detail.

In practice, re-estimate at three points: after the first scoping session, at sign-off, and whenever a change request adds work. Each pass should narrow the pessimistic case. If it doesn't, the scope is less settled than it looks, and the time and scope side of project estimates needs another look.

Four steps that turn role-level hours into a number you can promise

Three-point estimating pays off when you run it role by role and carry the result all the way to the number in the contract. Take an illustrative project cost estimate example: a website redesign covering a 20-page marketing site, a CMS with integrations, QA and launch.

The assumptions are that the client supplies content, two revision rounds are included and there's no custom backend. Internal cost rates are $60 an hour for the project manager, $55 for the designer, $70 for the developer and $45 for QA. All figures are illustrative.

Step 1: Give every role three hour estimates

Ask whoever will do the work for three numbers instead of one. The optimistic figure assumes everything lands first time, and the most likely figure includes normal friction. The pessimistic figure is a realistic bad case, such as both revision rounds used in full and an integration that fights back.

The expected figure weights the most likely case four times. These are the standard PERT formulas, written for task durations and applied here to hours. Standard deviation (SD) is a measure of how far outcomes typically land from that expected figure:

$$E = \frac{O + 4M + P}{6}$$

$$\text{SD} = \frac{P - O}{6}$$

For the developer, with 110 optimistic, 140 most likely and 230 pessimistic hours, the expected figure is 150 hours with an SD of 20 hours. At $70 an hour, that's $10,500 expected, with a spread of $1,400:

$$E_{\text{developer}} = \frac{110 + 4 \times 140 + 230}{6} = 150 \text{ hours}$$

Pro tip: Write the reason beside every pessimistic figure, such as "third revision round", so the client risk conversation has specifics.

Run the other roles the same way and a pattern appears: on every line, the pessimistic tail is longer than the optimistic one.

Project cost estimate example: website redesign worksheet (illustrative)

Step 2: Roll the roles up to an expected cost and a spread

Expected labor comes to $19,630, which is $1,230 above the $18,400 you get from the most likely hours alone. That gap is the long pessimistic tail showing up in the average, and a single-number estimate never shows it.

To combine the spread, add the variances (each SD squared) and take the square root. In dollars:

$$\text{Combined SD} = \sqrt{300^2 + 550^2 + 1{,}400^2 + 270^2} = \sqrt{2{,}425{,}400} \approx 1{,}557$$

Round that to $1,560. The square-root method assumes the role estimates are independent. If the same client delays would hit every role at once, use the simple sum of the SDs, $2,520, as the conservative spread.

Non-labor adds a fixed $1,700: $1,200 for the CMS license and $500 for stock assets. Both are quoted prices, so they carry no spread.

The developer line carries $1,400 of the spread on its own, so that's where extra scoping effort pays back first. An hour spent pinning down the integrations narrows the range more than an hour refining the design estimate.

Resourcing forecasts were consistently hard when I worked agency-side, for a similar reason: the averages looked calmer than reality because they hid who was overloaded. A per-role spread applies that lesson to the estimate, pointing at the line where the risk actually sits.

Step 3: Size contingency from the spread

Contingency is the money you hold above the most likely cost to absorb the risk you've estimated. Commit a fixed fee at expected plus one SD and labor lands at $21,190. Contingency over the most likely labor is then $2,790, about 15% of $18,400.

A flat 10% buffer on the same job gives $18,400 plus $1,840, or $20,240. That's only $610 above the expected cost, about 0.4 of an SD, which is thin protection for a fixed fee. It's how a cost overrun gets built in at the quote.

The trouble with any flat percentage is that it ignores the spread. A tight-range project and a wide-range project get the same buffer, so one is overpriced and the other is underprotected.

Step 4: Commit the part of the range your pricing model puts on you

Who carries the risk decides how much of the range you promise. For the fixed-fee case, in dollars:

$$\text{Fixed-fee labor commit} = 19{,}630 + 1{,}560 = 21{,}190$$

• Fixed fee: Commit to expected plus one SD, which is $21,190 labor and $22,890 total cost with non-labor.

• Time and materials: Estimate at the expected $19,630 labor ($21,330 total), set a budget alert there, and agree a not-to-exceed cap at $21,190 labor.

• Retainer: Commit monthly capacity in hours from the most likely figure, then track the spread as overage each month.

On a fixed fee, any cost past the committed figure comes straight out of the project's margin. If you use the correlated $2,520 spread instead, the fixed-fee labor commit rises to $22,150. On time and materials, reaching the cap triggers a change conversation before more hours go in. That's the point where scope creep either becomes a change order or becomes your cost.

A wide spread on a fixed fee means a high price, so the commit rule also shapes which model you offer. Read the guide to choosing a billing model before you default to one.

Where the range method needs adjusting

Below about 40 hours, three-point estimating costs more effort than it saves. Use a single bottom-up figure, check it against one comparable past job, and manage the risk through terms such as a time and materials cap.

With no history yet, start from the outside view: what comparable past projects actually cost, even as rough totals from old invoices. Set your optimistic, most likely and pessimistic figures around that reference instead of around the plan in front of you. Then calibrate from the first projects you deliver.

Compare actuals with the estimate by role after every project

Project cost estimation only improves when you check actual hours against expected hours, role by role, after each project closes. Without that check, the same optimism goes into the next estimate.

That optimism has a name. In a 2006 PMI paper on reference class forecasting, Bent Flyvbjerg describes the planning fallacy, a term from Lovallo and Kahneman's work, which builds on Kahneman and Tversky. People tend to underestimate the costs, completion times and risks of what they plan. If that bias shows up in your estimates too, your misses are likely to lean one way, so averaging them won't cancel them out. The fix Flyvbjerg describes is the outside view: base the forecast on what comparable past projects actually took.

HM Treasury's Green Book (2026) makes a similar correction formal for UK public-sector appraisal, telling practitioners to size optimism adjustments from their average historical forecast errors. Your firm's version of that evidence is a calibration ratio, worked out per role once delivery ends:

$$\text{Calibration ratio} = \frac{\text{Actual hours}}{\text{Expected hours}}$$

A ratio of 1.0 means the estimate held. If developers keep landing at 1.2, widen their pessimistic case and raise the most likely figure on the next similar job. Track it by role, because a blended ratio lets one role's overrun hide behind another's early finish.

Review the role with the widest spread first, since a better estimate there moves the commit number the most. Calibration only works, though, if hours are logged against the right role and project.

Data point: Firms with highly ready data report project margins of 43.6% vs. 35.2% for firms whose data is not ready or fragmented. That's from SPI Research's 2026 Impact of AI on Professional Services report.

SPI measures data readiness broadly, but for estimating, the practical reading is that a calibration ratio is only as honest as the timesheets behind it. Late or misfiled hours make an estimate look better than it was, and that error flows into the next quote and your project profitability.

A spreadsheet works to start: the Project Profitability Tracking Template captures baseline estimates and compares plan with actual as delivery runs. A PSA, or professional services automation platform, connects projects, resources, and financials, so the estimate and the actuals share one record. That matters once you're calibrating across dozens of projects instead of a handful.

How Teamwork.com carries the estimate from quote to actuals

Teamwork.com carries a cost estimate through quoting, budgeting and delivery, so the range you built stays tied to what the work costs. It's the agentic PSA for professional services firms, connecting projects, resources and financials. Project tools can't manage the money, and teams resist traditional PSAs; Teamwork.com gives you PSA-grade financials in a platform your team actually uses, so your committed number, alerts and actuals sit in one record.

• Turn the estimate into a quote without retyping it: spreadsheet estimates get copied into a proposal, then a project plan, and each copy drifts. Quotes in Teamwork.com hold cost rates and billable rates per person, so every line shows what it costs you beside what you charge. When the client accepts, the quote converts into a project with no re-entry, so delivery starts on the figures you priced.

• Get warned at the number you committed to: a fixed fee or a cap only protects margin if someone sees spend approaching it. Budgets in Teamwork.com cover fixed fee, time and materials and retainer models, and notify you when spend reaches a threshold you set. Set that threshold at the expected cost, and the alert lands before the cap does, so the change conversation comes first.

• See which role's estimate missed: calibration stalls when pulling actuals for a closed project means a day of exports and cleanup. Time tracking logs hours against tasks as delivery happens, and the Profitability Report shows cost, billable value and margin by project. You can compare estimated and actual hours logged, so the inputs for each role's calibration ratio are ready without a rebuild.

Invanity, a digital agency, runs budgets and cost rates per client and project in Teamwork.com and reconciles them against billable rates. It saw a 50% decrease in time spent building project plans.

The range you estimate at the pitch stays visible through delivery, and every closed project narrows the next one.

FAQ