← All guides

Historical cost data: how to make last year’s jobs useful for this bid

You have years of work sitting in folders, exports, and people’s heads. On bid day it might as well not exist. The problem is not storage. It is that nobody defined what “useful” means before the clock started.

The job of this page

Stop treating last year’s jobs as a nostalgia pile. Define the few fields that change this bid, own one pull before you price, and only then ask AI to help. Dumping a SharePoint folder into a model is not a strategy.

Why buried history does not help

PDFs of final estimates. Spreadsheets named final_v7. A senior estimator who “knows how that job went.” Ops who lived the change orders and never wrote them down.

When the next similar package lands, someone greps a drive, skims a PDF, and guesses productivity from memory. That is not historical cost. That is tribal recall with a filing cabinet.

What “useful” means for this bid

Useful is not every line from every job. It is a short, owned set you can actually pull:

• Assemblies that match this package. Same cost codes, same units, same scope shape. Not a rolled-up total from a different building type.
• Productivity that survived the field. What you assumed vs what the crew actually got. Written somewhere ops and estimating both trust.
• Change drivers. The few things that moved cost after award: design gaps, vendor lead times, access, sequencing. Named, not “it was hard.”
• Vendor and market notes that still matter. Quotes that aged, alternates that flipped, labor that moved. Dated so you know what is stale.

If you cannot point to those four for a prior job in under an hour, you do not have historical cost ready for bid. You have archives.

One owned pull before bid

Pick a owner. Estimating lead or coordinator. Before the bid clock is real, they pull the comparable jobs against that short list. One place the pull lives. One version the room uses.

Do this before you open the new drawings for deep takeoff. The history should shape assumptions, not show up as a scramble the night before submission.

Where AI helps (and where it does not)

AI helps when the data is structured: assemblies, units, productivity, change notes in fields you can query. It can surface comparable jobs, flag outliers, and draft a one-page brief for the bid room.

AI does not help when you dump unstructured PDFs and hope the model invents a cost basis. Garbage in, confident garbage out. Structure first. Model second.

One concrete picture

Mid-market specialty contractor. Bid room opens a package that looks like three jobs from last year. Someone drops a SharePoint link in Slack. Two estimators open different PDFs. One remembers productivity that ops already know was wrong. Nobody owns the pull.

Same company, next cycle: they define a one-page “useful history” sheet (assemblies, productivity, change drivers, dated vendor notes). A coordinator owns the pull before bid. AI summarizes the structured sheet into a brief the room actually reads. The PDFs stay in the archive. They are no longer the source of truth for pricing judgment.

Scene is an illustrative pattern, not a named client case study.

What “done” looks like

You can answer, in writing: which fields make a past job useful for this bid, who pulls them, and where that pull lives before pricing starts. AI is allowed on top of that. Not instead of it.