Most estimate reviews spend their time on arithmetic. Do the subtotals roll up to the total? Do the extensions match quantity times rate? Did someone paste a value over a formula? Those checks are worth doing, and on a spreadsheet estimate they aren't optional. But they find the errors that are easiest to find. A review that stops there has confirmed that the estimate adds up. It hasn't asked whether it adds up to the right project.
The expensive misses rarely live in a formula. They live in scope nobody priced, in a quantity taken from a superseded drawing, in a rate carried forward from a job with different conditions, and in an assumption that quietly holds up a large share of the number. A reviewer who only checks the math will sign off on all of them.
Here's how to structure a review that goes further, and how to make sure what it finds actually gets settled.
Review a version that can't move
Before anyone opens the estimate, fix what's being reviewed. A review of a live workbook is a review of a moving target. The estimator corrects a line during the meeting, someone updates a quote that afternoon, and by the time the findings are written up, half of them point at numbers that no longer exist.
Name the estimate version, freeze it, and review that. If the estimate changes after the review is prepared, don't present the old basis as if it were current. Refresh the review evidence, or start a new review on the new version. Every finding should say which version it was raised on, so anyone reading it later can see exactly what the reviewer was looking at.
What to look at besides the arithmetic
Scope coverage. Walk the scope against the WBS and ask what's missing, not what's wrong. An empty WBS code, a package with no established scope, a discipline that appears in the design basis and nowhere in the estimate: these are the findings that matter most, because nothing in the arithmetic will ever flag them. A missing line adds up perfectly.
Basis and maturity. For each major area, ask where the quantity came from and which drawing revision it reflects. A quantity from a 30% model sitting next to a rate priced for a fully detailed design is a mismatch, even if each is defensible on its own. Check that the method fits the maturity, too. A factored number is reasonable early in design and a warning sign late.
Reasonableness against your own history. Compare the key unit rates and ratios with what your company has actually measured on comparable work. An outlier isn't automatically wrong, but it needs a reason, and the reason belongs in the basis. Look at outliers in both directions. A rate well under your history deserves at least as much attention as one well over it.
Movement since the last version. Every significant change since the prior version should have a cause someone can name. If the reviewer can't find one, that's a finding.
Assumptions that carry money. Find the assumptions that would move the number most if they turned out wrong: a working-hours assumption, a productivity factor, an owner-furnished equipment list. Ask whether each one is written down, whether it can be tested, and whether the people who could prove it wrong have seen it.
Risk evidence. If a risk analysis supports the estimate, confirm it was run on this version and not the last one. A risk result tied to an older basis describes a different estimate.
Write findings someone can close
A review produces findings, and the quality of a finding decides whether anything happens next. "Concrete looks light" is a comment. A finding states what was observed, where, how serious it is, and what would settle it.
It helps to keep three things apart:
- The finding: what the reviewer observed, stated against the version and the lines it concerns.
- The decision: what the team decided to do about it, who decided, and why.
- The action: the work that follows, with an owner and a date.
When these blur together, findings either stay open forever or get closed by someone writing "addressed," with no record of how. Severity matters as well. A review that marks everything as major tells the estimator nothing about where to start.
Settle every finding on the record
Each finding should end one of two ways. Either the estimate changes, and the change shows up in the next version with the finding as its cause, or the estimate stays as it is and the decision records why. Both are legitimate. What isn't legitimate is a finding that disappears because the next version was issued and nobody carried the open items forward.
Check for that explicitly. When the next version is reviewed, the first question should be what happened to the last review's findings. A finding raised on version 3 and silently absent from version 4 is a gap in the record, even if the underlying problem was fixed.
Keep what the room saw
Reviews often end in a presentation, and the presentation is part of the record. If the slides were built from a live estimate and someone updates a figure the next morning, the deck no longer shows what the room was shown. Present from the frozen basis, and keep the issued review exactly as issued. Six months later, when someone asks what the review found and what the team decided, the answer should be a document, not someone's memory of the meeting.
Questions a review should be able to answer
Before you call a review complete, check that it can answer these:
- Which estimate version was reviewed, and is that version frozen?
- What scope did the reviewer confirm is covered, and what did they find missing?
- Which rates or ratios fell outside your own history, and what's the reason for each?
- Does every significant movement since the last version have a named cause?
- Which assumptions carry the most money, and who has seen them?
- Was the risk evidence run on this version?
- For each finding, who decided what, and where is the change or the reason?
Where the software fits
Jakten Assurance runs this kind of review as a guided Version Review. You prepare the review basis, review the required content and risk evidence, record findings, decisions and actions, prepare the presentation, present from a frozen session basis, and issue the review artifact. Findings and follow-up actions are recorded against the Estimate Version they were raised on. If the estimate basis changes after the review is prepared, you refresh the review evidence or create new evidence rather than present a stale basis, and blocking validation has to be resolved before the review is issued. Once issued, the review stays frozen as historical evidence.
For the reasonableness check, Standard Metrics and Version Knowledge put your company's benchmarks and measured results beside the version. A metric result can be promoted into a finding after you've checked its definition, values and citations.
Assurance doesn't price the work, and it doesn't decide what a finding means. The reviewer and the estimating team do that. What it keeps is the record: what was reviewed, what was found, and how each finding was settled.
The Jakten Assurance page has a short demo and the screens as they ship, on a fictional semiconductor fab project.