Estimation ·
The two-day estimating ritual
Why FEEED estimation is the most expensive form of data entry in the industry — and what replaces it.
Watch a senior estimator working a FEEED scope and you are watching one of the most expensive workflows in heavy industry.
A scope statement lands in the inbox. Forty pages of Word. The estimator reads it, opens a spreadsheet, opens a second spreadsheet of historical norms, and starts a conversation with another senior engineer that lasts two days. They argue about line meters. They argue about equipment counts. They argue about how a four-page narrative paragraph affects man-hour density. At the end of the second day a number falls out — one number, with a credibility band of plus or minus thirty percent that no one will ever defend in writing.
The cost of that two-day ritual, multiplied across the bid pipeline, is enormous. The amount of judgement actually applied is small. Most of those forty-eight hours is parsing prose into a structured table. Two senior engineers, billed at senior-engineer rates, doing what is structurally data entry.
Once you frame it that way, the question is not whether AI belongs in estimating. The question is what shape it takes.
The shape that works is narrow. A small open-weight model running locally on a laptop reads the scope document and emits structured tags against a known schema — counts, totals, density flags, narrative-complexity markers. The schema is the contract; the output is validated against it; malformed output triggers a retry. This is not “AI does estimating.” This is “AI takes the dictation.”
The estimator’s day starts with the spreadsheet already populated. Citations sit next to every value, pointing back to the source paragraph. Five minutes of skim, override the four numbers that are obviously wrong for this client, lock the basis-of-estimate. The judgement layer — the part that adds value, the part the senior engineer was hired for — is where their day spends its time now.
Three structural things have to be true for this to work.
First, the model runs locally. Anything client-coded going to a cloud API fails the audit. A four-and-a-half-gigabyte model running on a MacBook is enough.
Second, the prompt is tight. The model is not asked to “summarise the scope.” It is asked to fill a known schema. The prompt is a contract, not a creative brief.
Third, there is a human in the loop, in the right place. The estimator is not the model’s editor. The model is the estimator’s typist. The judgement does not move.
The result is not faster estimating. The result is more honest estimating, because the structured starting point exposes the assumptions that the two-day ritual hides under a single number. The conversation between two senior engineers used to end at “$X.” Now it ends at “$X plus or minus 8%, here is the evidence, here is what we assumed.”
That is what digital transformation in EPC project work actually looks like. Not autonomous agents. Not chatbots. A grinding, reliable upstream tool that removes the part of the workflow that adds no judgement, and gives the rest of the day back to the engineer.