Most estimates on a large capital project have a basis of estimate. Far fewer have one that survives contact with a skeptical reader.
You can usually tell which kind you're holding within a few pages. The weak version is a narrative written the week before the estimate is due. It restates the total, lists the drawings that were available, and closes with a paragraph of boilerplate exclusions carried forward from the last job. It describes the estimate. It doesn't defend it.
A defensible basis of estimate does something harder. It lets someone who wasn't in the room, whether that's a reviewer, an owner's cost engineer, or you in eighteen months, rebuild the reasoning behind the number without calling the estimator. Here's what that takes.
The test: could a stranger reconstruct it?
Before getting into sections, it helps to have a test. For every major number in the estimate, a reader should be able to answer three questions from the document alone:
- What scope does this cover, and what doesn't it cover?
- Where did the number come from? Quantity takeoff, historical data, a vendor quote, a factor, an allowance?
- What would have to be true for it to be right?
If the basis of estimate answers those three questions for the lines that matter, it's defensible. If a reviewer has to ask the estimator, it isn't yet.
The seven parts
A useful way to structure a basis of estimate is around seven things: scope, basis, methods, assumptions, qualifications, commercial evidence, and totals. The headings vary between companies. The content shouldn't.
Scope. Say what the estimate covers in terms the project team would recognize: facilities, systems, areas, and the work breakdown structure the estimate is organized under. Then say, just as plainly, what's excluded.
Exclusions are where most basis-of-estimate trouble starts. "Owner's costs excluded" means one thing to the estimator and something else to the finance team. A good exclusion is specific enough that two readers would draw the same line.
Basis. The design and information the estimate was built from: which drawing set or model, at what revision, which specifications, which equipment lists, and which site conditions were assumed known.
This is also where you state the maturity of the design. An estimate built on 30% design information is a different kind of document from one built on issued-for-construction drawings, and the basis section is where a reader learns which one they're holding.
Methods. For each major area, how was the cost developed? Detailed quantity takeoff priced against unit rates, parametric factors from historical projects, vendor budgetary quotes, or an allowance where nothing better existed?
Mixed methods are normal. What matters is that the reader can see which parts of the estimate rest on which method. A number built from takeoff and a number carried as an allowance shouldn't look identical on the page.
Assumptions. These are the conditions the estimate depends on that nobody has confirmed yet: labor availability, working hours, productivity, escalation basis, the procurement strategy, the construction sequence.
Two habits separate useful assumptions from filler. First, each assumption should be specific enough to be wrong. "Normal productivity" can't be tested. A stated productivity basis can. Second, the important assumptions should point to the lines they affect, so that when one changes, someone knows which numbers to revisit.
Qualifications. These are the conditions under which the estimate holds, as opposed to the conditions it assumes. They set the boundary of the number's validity. A price is good until a date. A quantity holds within a design envelope. A rate depends on a contract form.
Qualifications protect both sides. They tell the reader when the estimate stops meaning what it says.
Commercial evidence. This is the part most often missing, and the part reviewers value most. Commercial evidence is what backs the numbers: vendor quotes and their dates, should-cost benchmarks, historical metrics from comparable work, the change items already absorbed into the total and the ones still pending.
An estimate that cites its evidence can be challenged line by line, which is exactly what makes it defensible. An estimate that doesn't can only be challenged as a whole, and it tends to lose.
Totals. Finally, how the totals build: direct cost to indirects, markups, allowances, escalation and contingency, up to the loaded project total. The build-up should be explicit enough that a reviewer can follow the arithmetic, and the totals in the narrative must match the totals in the estimate.
That last point sounds obvious. It's also one of the most common findings in any review, because the narrative was written from an earlier version of the estimate.
Where good BoEs go wrong
Even teams that know the seven parts run into the same few failures.
The BoE is written last. When the narrative is assembled at the end, the reasons behind decisions made weeks earlier have been forgotten. A basis of estimate works better as a running record that grows with the estimate than as a report written about it afterward.
The figures drift. The estimate is revised, the BoE isn't, and the document now defends a number that no longer exists. Any figure quoted in the narrative should come from the version it describes, not be typed in by hand.
Blanks become zeros. A missing input silently rolls up as nothing, and the total looks complete when it isn't. A defensible BoE says "not yet available" where that's the truth.
Nothing is frozen. An estimate issued for a funding gate has to stay exactly as it was issued. If the BoE can be quietly edited after issue, it's no longer evidence of what was presented.
A short checklist before you issue
Before a basis of estimate goes out, check that:
- Every exclusion is specific enough that two readers would draw the same line.
- The design basis names its revisions and states its maturity.
- Each major area says which method produced its number.
- The key assumptions are testable and point to the lines they affect.
- Quotes, benchmarks and pending changes are cited, with dates.
- The totals in the narrative match the estimate version being issued.
- Anything unavailable is labeled unavailable, not left as zero.
- The issued document is retained exactly as issued.
Where the software fits
This is the problem the Living Basis of Estimate in Jakten Assurance is built around. Assurance doesn't price work or generate quantities. Every dollar enters by importing the estimate into governed Packages. What Assurance does is keep the basis of estimate tied to the Estimate Version it describes.
The Living BoE is composed from structured, cited evidence and your own narrative. Governed blocks read live figures from the version for cost, coverage, change trends and the project build-up, so the numbers in the document are the numbers in the estimate. You arrange the sections, add your own text around the evidence, and review the composed document, citations and totals before issue. Draft edits stay drafts. Issuing produces a retained artifact that stays frozen as historical evidence you can compare against later versions. And where an input is missing, Assurance shows it as unavailable rather than as zero.
If you'd like to see how that works on a fictional semiconductor fab project, the Jakten Assurance page has a short demo and the screens as they ship.