The Cost Estimate as a Risk Model: Why Bids for the Same Job Differ by Multiples
In our agency's archive sit three estimates from the same period: 306 500 rubles, 360 000, and 808 000. The first was for a healthcare-provider website, the second for a salon website, the third for a grocery e-commerce store. The difference between the first and the third is two and a half times.
It's tempting to chalk the difference up to complexity, but that explanation is wrong. An online store isn't technically two and a half times more complex than a brochure site. The real difference lies elsewhere: in the third case, the vendor took on uncertainty that simply didn't exist in the first two — around integrations, the catalog, payments, and everything the brief hadn't yet defined.
A cost estimate isn't a price list — it's the price of accepting risk. The spread between bids for a similar job doesn't reflect different vendor skill; it reflects a different split of uncertainty between the parties. Industry standards say this outright: estimate accuracy is set by how developed the input data is, not by how complex the work is, and the accuracy range can differ by an order of magnitude between stages.
What Actually Makes Up the Difference Between Estimates
Let's break a cost estimate into its components. The scope of work is only the first of them, and usually not the largest.
Scope of work. What the client sees in the estimate and uses to compare bids. It's calculated fairly precisely and varies the least between vendors.
Scope uncertainty. How likely it is that what's described turns out to be incomplete. This is where most of the spread comes from: one vendor builds in a buffer for the unknown, another doesn't — and the second one wins the tender.
Environment uncertainty. Someone else's systems, someone else's data, someone else's deadlines. Everything that depends on third parties, that the vendor can't control, but is still contractually on the hook for.
The price of trust. The buffer is bigger for a new client than for a proven one — and that's rational behavior, not a markup. A second project for the same client is almost always priced lower than the first, for the same scope.
| Component | Who sees it in the estimate | How to reduce it |
|---|---|---|
| Scope of work | Both parties | Clarify the list of deliverables |
| Scope uncertainty | Only the vendor | A list of exclusions and a change-order process |
| Environment uncertainty | No one, until work starts | Name the dependencies and the consequences of delay |
| Price of trust | No one | Break the work into staged, pay-as-you-go phases |
The second column explains why comparing bids "on price for the same work" is misleading: three of the four components aren't shown in the estimate at all — and they're exactly the ones that vary most between vendors.
What the Industry Standard Says About Estimate Accuracy
In engineering industries, the relationship between how developed the input data is and how accurate the estimate is has been formalized, and the numbers are worth knowing for anyone who receives estimates.
The accuracy range of an estimate is set by how developed the input data is: at 0–2% project definition, the range runs from −20…−50% to +30…+100%; at 65–100% definition, it runs from −3…−10% to +3…+15%. The standard states outright that a less-developed estimate for one project can turn out more accurate than a more-developed estimate for another.
I'll name the limitation directly: this is capital construction and engineering, and the numbers are expert-agreed ranges, not the measured variance of real-world bids. You can't carry the percentages themselves over to digital projects. What does carry over is the structure of the argument: estimate accuracy is a function of how mature the input data is, and that's a way to talk to a client in terms of stage, not in terms of trust in the vendor.
How to Estimate When You Have Little Data
There's a procedure built for exactly this situation, and it predates most project-management methodologies.
Intuitive expert estimates are systematically biased: they're non-regressive and overrate their own accuracy. The corrective procedure the authors propose has five steps — pick a reference class of comparable cases, get the distribution of outcomes for that class, get the intuitive estimate, assess the predictive power of that intuition, and shift the estimate toward the class average in proportion to that power.
This was a technical report, not a peer-reviewed publication, at the time it came out, and the method is demonstrated on a handful of examples — a real limitation. The procedure's practical value lies elsewhere: it replaces the question "how long will this take" with "how long did similar jobs take for us," and any company has data for that second question, as long as it's tracked actual hours on anything at all.
Traditional estimates for large projects are systematically inaccurate because of optimism bias and strategic misrepresentation, not because of how complex the work is. The proposed method is reference class forecasting — building the estimate on the actual outcomes of comparable projects.
The empirical base here is transportation megaprojects, and I read the preprint's abstract, not the full text of the journal version. Applying this to commercial estimates is done by analogy, and I'm flagging that. The second mechanism the author names matters more: strategic misrepresentation. Part of the spread between bids isn't a difference in risk assessment at all — it's a difference in willingness to quote a low price to win the contract, and it's worth a client's while to tell the two apart.
How to Read an Estimate as a Client
The second question is the most informative one. Assumptions are the list of unknowns the vendor took on faith in order to quote a number. An estimate with no assumptions section was either put together carelessly, or it contains a buffer whose size you won't be shown.
A practical move for the client: ask for two versions — one at a fixed price, one billed on actuals against a stated target. The difference between them is exactly the price the vendor charges for taking on the risk. It's usually bigger than clients expect, and that's an honest conversation, not haggling.
What a Vendor Should Do About It
The flip side of the same mechanism: you can lower the price without cutting your margin — by cutting the uncertainty you're taking on instead. Three tools work better than the rest.
Staged pricing. The first stage is scoping, at a fixed price; later stages get estimated once it's done. This removes most of the scope uncertainty and lets you quote an honest number instead of a buffer.
A list of exclusions. Explicitly named boundaries are cheaper than any buffer, because they turn the unknown into a separate conversation. More on this — in the piece on the scope-of-work document.
Explicit dependencies. Everything that depends on a third party gets named, along with the consequences of a delay. Without this, environment uncertainty stays with the vendor — and the vendor pays for it.
Four Rules for Writing a Cost Estimate
Write the assumptions before the line items
A list of what's taken on faith. It explains the number better than a list of priced line items does.
Estimate from a reference class
Not "how long will this take," but "how long did similar jobs take for us." The second question has a checkable answer.
Name the stage of development
A ballpark estimate from an idea and an estimate from a finished brief are different documents with different accuracy, and the client has a right to know which one they're getting.
Break the work into stages wherever the unknowns pile up
Staged pricing is cheaper than a buffer, and more honest than a fixed price quoted blind.
If two bids for the same job differ by multiples, the question isn't "why is this so expensive" — it's "what does each of them count as their own zone of responsibility."
Questions People Ask Most Often
Why do estimates for the same project differ by multiples?
Because it's not the work that differs — it's the amount of uncertainty the vendor takes on. An estimate has four components: the scope of work, scope uncertainty, environment uncertainty, and a buffer for an unfamiliar client. The client only sees the first one. Bids should be compared on their assumptions section and on the list of what's excluded from the work.
How can you tell an estimate is underpriced?
By the absence of an assumptions section and a list of exclusions. If the vendor hasn't stated what they took on faith and what they aren't doing, they either didn't understand the job or expect to negotiate an add-on later. A second tell is the absence of third-party dependencies: a real project always has them, and their absence from the document means the delay risk has been silently left with one of the two parties.
What should you do if there's no data for a precise estimate?
Split it into two documents: a precise estimate for the first stage, whose job is to scope the work, and an order-of-magnitude range for the whole project with the stage of development explicitly stated. Industry standards record that at minimal project definition, the accuracy range runs from minus fifty to plus one hundred percent — quoting a single number in that situation misleads both sides.
How representative is a ×2,6 spread?
These are three estimates from one company, from the same period, for different — though comparable-class — jobs; they haven't been checked by an independent party and aren't an industry benchmark. What's telling isn't the multiplier itself but the cause: the third project involved integrations with third-party systems — environment uncertainty that simply wasn't present in the first two.
The estimate totals (306 500 ₽ for the healthcare-provider website, 360 000 ₽ for the salon website, 808 000 ₽ for the grocery e-commerce store, 2015–2016) come from Alego.Digital's project archive. The service pricing model — a retainer plus a separate rate for extra hours — comes from the client-engagement policy of the same period. These are the author's company's internal documents; they haven't been checked by an independent party and are presented here to illustrate the mechanics. The breakdown of an estimate into four components is the author's own generalization of practice, not something formalized in the company's documents.
- AACE International. Recommended Practice 18R-97: Cost Estimate Classification System. aacei.org
- Kahneman D., Tversky A. Intuitive Prediction: Biases and Corrective Procedures, 1977. apps.dtic.mil
- Flyvbjerg B. From Nobel Prize to Project Management: Getting Risks Right. Project Management Journal, 2006. arxiv.org