Your next estimate should remember the last job

The idea in brief

• Stop rebuilding context. Bring estimates, quotations and project history into a comparison the team can review.

• Connect the reasoning. Keep scope, quantities, revisions and decisions attached to the number.

• Make experience compound. Turn each approved review and delivery lesson into a better starting point for the next pursuit.

In this article

1. Where firms go wrong today

2. What the future of estimating looks like

3. Building a graph of intelligence: implementation, ROI and earning trust

4. Why this is hard to build in-house

5. Use cases worth starting with

1. Where firms go wrong today

A development team can pay for the same lesson twice. Once when a scope gap becomes a cost on site. Again when the next estimate review misses what the last project taught the team.

Picture an estimate that is nearly ready. One quote excludes temporary protection. Another is silent. A senior estimator remembers a similar job where that gap became an expensive argument, but not which folder contains the clarification.

The firm has the experience. The person making the next decision does not have it in front of them.

• The comparison gets rebuilt. Different formats, trade breakdowns and revisions consume time before the commercial review begins.

• The total hides the basis. An allowance, a low bid and a committed price can sit beside one another without their differences being clear.

• The lesson stays local. Accepted clarifications and delivery lessons remain in inboxes, marked-up spreadsheets and the memory of a few people.

Faster document search helps. The larger opportunity is to stop reconstructing the same relationships every time the team has a question.

2. What the future of estimating looks like

The next review should begin with the evidence already organized: a comparable cost breakdown, the material changes, the open scope questions and the relevant lessons from previous work.

• Comparable costs. Align divisions and building elements, reconcile trade detail with summaries, and retain subtotals for buildings or phases. Show changes in both dollars and share of the work.

• Rates with context. Compare quantities and unit rates against the documents and relevant jobs, preserving scope, units, location and pricing period.

• Scope made visible. Read qualifications throughout the package. Separate exclusions, provisional sums and costs carried elsewhere. Silence remains “not stated.”

• Cost tied to time. Check staffing, resource plans and general expenses against the programme. Keep fixed costs, duration assumptions and fee calculations explicit.

• A useful executive view. Lead with material changes, missing information and decisions required. Assess the quality of the submission as well as the arithmetic.

The estimator still decides what the evidence means. More of their time can go to resolving the question, with less spent finding the material needed to ask it.

3. Building a graph of intelligence

An integration can retrieve a quotation. A company brain should connect that quotation to the package it prices, the drawing revision it relies on, the scope it excludes and the decision it supports.

Those connected records form a knowledge graph. A node is a specific record or fact: a drawing revision, a quantity, a quotation, an exclusion or an approval. A link explains the relationship: this quantity comes from that drawing; this quote prices that quantity; this decision accepted that scope. Each connection retains its source, version and status.

For a developer, the value is seeing how a change in one document affects the questions that matter before committing money: what does it cost, what is included, when can it be installed and who still needs to decide?

Follow one façade package through the review

Consider an illustrative project. The developer’s approved estimate, E06, carries 2,000 m² of façade at CAD $650/m², or $1.30 million. Drawing D05, issued for pricing, increases the area to 2,200 m². The subcontractor’s submitted quote, Q02, retains the same rate but states a 16-week lead time and excludes temporary protection. The GC’s current estimate submission, E07, carries $1.43 million for the package.

The arithmetic explains a $130,000 increase. It does not establish that the revised estimate is complete or ready to approve.

One package, several connected decisions. Every record retains its source and status. All amounts and timings are illustrative. View full-size diagram.

The newest file is not automatically the approved answer

E06 remains the approved cost baseline while E07 is under review. Q03 can inform an option without becoming a procurement instruction. The company brain should show all three states together, so the team can see what is committed, what is proposed and what still needs evidence.

The output is a review the developer can act on: confirm protection coverage, explain the quantity increase and resolve the lead-time conflict with the GC before award. The record identifies the responsible person and required response date. Once the authorized decision is recorded, it becomes the basis for subsequent checks.

If Q03 is revised or D05 is superseded, the system should reopen the conclusions that rely on it. The earlier review remains traceable to the evidence available at the time. At closeout, the final package cost and protection arrangement can become an approved lesson for the next project.

Implementation: start with a decision

1. Define the review. Start with one package approaching award. Specify the comparison, required clarifications, decision owner and deadline.

2. Connect the records. Link the approved estimate, current submission, quotations, drawings, schedule and relevant prior-job lessons. Retain units, revisions and permitted use.

3. Validate the relationships. Have the team check whether the linked sources support each finding. Keep missing evidence and disputed scope visible.

4. Keep the loop current. Revisit affected conclusions when documents or approvals change. Preserve the decision history and carry approved lessons forward.

ROI: measure the work that gets better

The first return is capacity: less time preparing a review and more time exercising judgment. For a development team, the operating question is how quickly a complete estimate submission becomes a useful, checked set of comments to the GC.

Use a review round to mean one complete GC estimate submission and the developer’s consolidated response. Calculate average confirmed errors as the total confirmed errors divided by the number of completed rounds. Keep open questions and false alarms separate. More errors found is not itself a performance target; also track material issues missed and the effort needed to check findings.

For turnaround, start the clock when the agreed submission requirements are complete and stop when reviewed comments go back to the GC. Report the number of rounds and measurement period, and track time spent waiting for missing information separately. Compare active reviewer time as well as elapsed turnaround.

Time released is capacity; cash savings depend on how it is used. A flagged scope gap is an exposure to resolve. Record the action taken and commercial result before treating it as an avoided cost.

Implementing the graph is not trivial: the graph has to earn trust

The hard part is keeping the relationships dependable as the job changes. A graph that connects Q03 to the approved budget before the alternative is accepted could produce a tidy comparison with the wrong commercial basis. The team needs to be able to inspect, correct and trust the connections behind each finding.

• Stale information. Preserve the approved baseline alongside newer working files. Record which revision governs each use and when an approval takes effect.

• Conflicting evidence. If the estimate assumes protection is included but the quote excludes it, leave that conflict open until a clarification or authorized decision resolves it.

• Permission boundaries. Use only the working files the team is allowed to access. Carry source restrictions into comparisons, benchmarks and summaries.

• Unreliable connections. Similar wording can describe different scope. Validate the relationship and attach the exact source passage or drawing reference.

• Excessive retrieval. Bring forward the evidence needed for this package and decision, while retaining the route back to the wider record.

4. Why this is hard to build in-house

A prototype that answers questions about a folder is achievable. A dependable system has to keep working when the quotation changes, access is revoked, a new estimator joins or the source systems evolve.

• Permissions. Enforce who can see each source, and carry those restrictions into every answer and comparison.

• Long context. Select the relevant evidence across large estimate packages without losing scope, revisions or source references.

• Freshness. Detect changes, distinguish approved baselines from working files, and revisit conclusions that rely on old information.

• Connectors. Keep document stores, email and project systems synchronized as formats, APIs and access rules change.

• Infrastructure ownership. Own deployment, security, monitoring, recovery and operating costs after the prototype is finished.

• Continuous evaluation. Keep testing models, prompts and retrieval on real estimating work. Each improvement needs comparison against a benchmark, then checks that it has not made other tasks worse.

The build decision is about owning that operating responsibility. Firms with the right team may choose to do so. Others can put their internal effort into the review rules and commercial judgment that make their approach distinctive, supported by a maintained platform.

5. Use cases worth starting with

Start where the team already repeats a consequential review. The same foundation can support several outputs:

• Estimate comparison. Normalize formats, reconcile detail and explain movements by division, element or project phase.

• Trade and rate review. Compare major rates, expose scope differences and bring together commitments spread across packages.

• Scope and quantity checks. Find qualifications, missing scope and discrepancies between the estimate and supporting documents.

• Staffing and fee checks. Reconcile resource plans with the schedule and cost totals; verify duration and fee assumptions.

• Submission assessment. Review completeness, reporting requirements and the evidence behind an executive cost summary.

• A lessons and cost registry. Connect pursuit estimates, accepted changes and actual outcomes so the next team can understand why costs differed.

An approved estimate should carry a handoff: assumptions still open, exclusions to resolve, alternates accepted and the documents behind each decision. At closeout, explain variances and carry the approved lessons forward.

Your team learned the lesson. The next estimate should not have to pay for it again.

At Mason, that is how we would scope the work: choose one consequential review, connect the evidence it needs, and validate the handoff with the people accountable for the estimate.