Fifteen steps, four phases, and one uncomfortable pattern: the steps that get dropped under deadline pressure are almost always the ones that would have made the estimate defensible. Here is the process as it is actually run, what each step puts into the model, and what the missing steps cost you six months later.
Nobody produces an estimate in one pass. It is assembled out of decisions — what is in scope, how a quantity was measured, which rate applies and why that one. The estimating process is the ordered set of steps that turns a brief and a set of drawings into a number with a reason behind every part of it.
Queensland’s Project Cost Estimating Manual sets out fifteen of those steps across four phases, and the sequence is not arbitrary: each consumes what the previous one produced. You cannot reality-check a base estimate you have not built, or size contingency against risks nobody has written down. Run them out of order and you are deferring the same work to a point where it costs more.
The process scales, but not in the way people assume. A minor works package may need an hour on some steps and a sentence on others; what does not scale is the requirement to consider all fifteen and record the consideration. “Not applicable, and here is why” is a complete answer — silence is not, because a reviewer cannot distinguish a step you dismissed from one you never thought about. It is also iterative rather than linear: estimates are produced at concept, business case, tender and award, each pass re-entering the loop with better information and a tighter range. The steps do not change between passes. Only the evidence does.
TX1:Trinity holds scope parametrics, quantities, build-ups, allocations and code sets in one local project, so the audit trail is a by-product of estimating.
Start a free 14-day trialGrouping the steps into phases is more than tidiness. Each phase fails in its own way, and knowing which one you are in tells you what kind of mistake to look for. Foundation errors are omissions: something real was left out. Development errors are method errors: the wrong technique for the information available. Risk-phase errors are confidence errors: uncertainty acknowledged in words but not numbers. Finalisation errors are transmission errors: the estimate was right and the reader received something else.
The boundaries also mark where it is cheapest to stop and check: a scope omission caught at the end of the foundation phase costs an afternoon, and caught after presentation it costs a re-forecast.
Scope, information, site and collation. This phase decides what you are pricing, and nothing later recovers from getting it wrong.
Item types, historical data, the base estimate and reality checks. Where the number is made, and where global rate, unit rate or first principles is chosen element by element.
Risk, contingency and the cashflow that carries escalation. Converts a deterministic figure into a funded position in out-turn dollars with a confidence level attached.
Presentation, validation, approval and capture. The estimate stops being yours and becomes an asset others read, challenge and update without you.
The middle column is where the step’s output physically goes when you work in an estimating package rather than a spreadsheet. Several steps say outside the software: pretending a tool walks a site or chairs a risk workshop is what makes estimators distrust tools. Step 10 is the clearest case — contingency is derived by Monte Carlo simulation run against this model rather than inside it. The right-hand column is the bill that arrives later.
| Step | Where the output lands | What skipping it costs |
|---|---|---|
| 1 · Establish Project Scope | Defining numbers held once as project parametrics. | Everything downstream prices the wrong job, faithfully. |
| 2 · Collect Available Project Information | Outside the software — but the revisions you priced belong in the project file. | A design change becomes an argument about memory, not a variation. |
| 3 · Become Familiar with the Project Site | Site reality entered as applied factors, not as a footnote. | Constrained work priced at textbook productivity: systematic under-recovery. |
| 4 · Collate Estimating Information | Quantities measured into the schedule; code sets applied first. | Re-measurement under pressure, with no audit of the original basis. |
| 5 · Determine Work Item Types | A code set carrying fixed, measured, provisional and lump sum types. | Provisional allowances read as measured work; the estimate looks over-certain. |
| 6 · Understand Historical Data | Rates from a maintained build-up library, not retyped per project. | Rates with no provenance. The honest answer is “experience”. |
| 7 · Develop Base Estimate | Build-ups, crew rates and formulas give direct cost; margins follow. | Rarely skipped, often mismatched — a global rate where first principles was due. |
| 8 · Undertake Reality Checks | The estimate re-cut through another code set. | The cheapest error-catching step, and the first one cut. |
| 9 · Assess Project Risks | Discrete risks priced as entries; risk carried as a named margin. | A percentage nobody can defend, covering risks nobody has named. |
| 10 · Determine Level of Contingency | The priced model is the input, deterministic or probabilistic. | A budget with no confidence attached to it. |
| 11 · Determine Cashflow and Escalation | In the program, not the model — but say real or out-turn. | Real dollars against an out-turn budget: overrun before a shovel moves. |
| 12 · Presentation of Costs | Totalled through whichever code set the audience reads. | The board sees one number and delivery another. |
| 13 · Estimate Validation | A portable package, so review interrogates the model. | Findings land after the submission date, when nothing can be done. |
| 14 · Estimate Approvals | The approved version kept as its own checksum-validated package. | No baseline, so “what changed” has no answer. |
| 15 · Document and Capture in 3PCM | Assumptions, exclusions and build-up detail in the project file. | It cannot be updated, defended or learned from — not even by its author. |
A step you skipped is an assumption you did not write down. Each of the fifteen either changes the number or records why the number is what it is. Skipping one in the first group is visible immediately; skipping one in the second is invisible until somebody external asks a question you can no longer answer.
The number is the smallest part of an estimate. What makes it useful is the reasoning attached: this quantity came from this drawing at this revision; this rate assumes a four-person crew at this productivity. Strip that away and you have a figure worth almost nothing, because a figure cannot be updated — only replaced by another with equally little behind it.
That is why the steps which feel skippable are the documentation steps, and why skipping them is the expensive decision. Site familiarisation, reality checking, validation and capture do not change today’s bottom line; they change whether it can be defended, adjusted and reused. Under pressure the mind optimises for the number, because the number is due on Friday.
Read it the other way and the process makes obvious sense. The fifteen steps are not fifteen tasks; they are the fifteen places an assumption gets made, and the process exists so each is made deliberately and written where the next person finds it. An estimate that documents its own assumptions survives a change of estimator, a change of scope and an independent review.
Ask any estimator which steps get compressed when a submission date moves left. Not the hard steps — the ones whose absence is invisible on the day.
Drawings tell you what is to be built. They rarely tell you the only access is a load-limited single-lane bridge, or that what the geotechnical report calls weathered rock is something a hydraulic hammer will earn its keep on. Site knowledge converts textbook productivity into the productivity you will achieve, and productivity is the largest lever in any resource-based rate. Skip the visit and constrained activities get priced as unconstrained — a bias that is systematic, always one way, and nearly invisible from inside the model.
An estimate built line by line can be internally consistent and still wrong by a margin one parametric comparison would catch in minutes. Total it a different way — per kilometre, per square metre of deck, per tonne erected — and hold it against completed work. Where it disagrees, either the project is genuinely different and you can say how, or there is an error. The step is easy to drop because it usually confirms the number.
An estimate priced at today’s rates describes a project built today, and no project is built today. Spreading cost over the construction program and applying published escalation parameters converts real dollars into out-turn dollars — the only basis a funding body can commit on. The failure is rarely that escalation is forgotten; it is that the basis is left unstated, so a real-dollar estimate meets an out-turn budget and the gap is booked as estimating error.
Independent review by a qualified estimator with no part in building the estimate is the only structural defence against your own blind spots, and above twenty-five million dollars in Queensland, concurrence review by a CE1 pre-qualified estimator is required rather than courteous. A reviewer given the model can test it; one given a printout can only confirm the printout adds up.
The last step is the first casualty: by the time you reach it the estimate is submitted and the next job has started. It also has the longest consequences. Documentation makes the estimate updatable at the next gate, comparable against the out-turn, and usable as historical data. An organisation that habitually skips it will still be estimating from memory in ten years.
The pattern is not laziness. It is optimism bias — the documented tendency to underestimate cost, duration and difficulty while overestimating benefit — operating on the process rather than the numbers. Each of these steps only pays off in a future where something went wrong, which is exactly the future optimism bias discounts. That is why the counter-measures are structural: mandatory historical data, a risk assessment that names what could go wrong, dual reporting at P50 and P90, independent review, and benchmarking. None asks the estimator to be less optimistic; they give optimism fewer places to hide.
TX1:Trinity is a Windows desktop application built on WPF and .NET over a local SQLite store, so the whole project — resources, build-ups, allocations, code sets and carbon — lives in one file rather than across workbooks. That is what makes the documentation steps cheap instead of heroic: steps 4 through 8 and step 12 all write into the same model.
Scope numbers from step 1 go in once as project parametrics and are referenced by name in formulas, so a change in corridor length propagates through every dependent quantity instead of sixty cells. Site knowledge from step 3 goes in as applied factors, where EffectiveBaseRate = BaseRate × AppliedFactor keeps the library rate and the site-adjusted rate distinct. Step 7 runs the pricing pipeline explicitly: direct costs plus overheads give total cost, markup applies per resource type, then risk, corporate and profit margins resolve to a sell price — each layer separately reportable.
Built-up resources recompute as the sum of their contributing rows, so changing a component cascades to the package rate, to every item using it and to all allocations. That is the mechanism behind steps 8 and 13: a reality check that finds a wrong labour rate is one edit, not a rebuild, and a reviewer’s challenge is tested live rather than taken on notice. Code sets run in parallel — WBS, contract structure, client chart of accounts — so step 12 is a choice of view. For steps 13 to 15 the portable .tx1 package carries the whole project, checksum-validated.
What the software does not do is chair your risk workshop, walk your site or write your scope narrative. Those remain steps you run; the model is where their conclusions land.
Fifteen, in four phases: foundation (1 to 4), development (5 to 8), risk and refinement (9 to 11), and finalisation (12 to 15). The count is fixed; the depth is scalable. A minor works package and a major corridor both pass through all fifteen, and what changes is how much evidence each generates. Every step must at least be considered, and the consideration recorded, even where it does not apply.
Site familiarisation, reality checks, cashflow and escalation, validation, and final documentation. They share one property: none of them change the number on the day you skip them. Pricing cannot be skipped, because the estimate would be blank. The steps sacrificed under deadline pressure are the ones whose absence stays invisible until somebody external reads the estimate.
Peer review is independent checking by a qualified estimator who had no part in building the estimate, and it applies to every estimate. Concurrence review is an extra layer on higher-value projects, in Queensland above twenty-five million dollars, by estimators pre-qualified under the CE1 category. Peer review asks whether the estimate is right; concurrence review asks whether a credentialled third party will put their name to it.
At step 10, but it is decided by the quality of steps 4 through 9. Contingency is either deterministic, a justified percentage applied at element level, or probabilistic, read off a simulated distribution as the gap between P50 and P90. Either way it inherits the structure of the base estimate. If the build-up underneath is lump sums with no resources behind them, there is nothing meaningful to range.
Much of it, as a by-product rather than a separate exercise. Build-ups record their own workings, so a rate arrives with its crew, productivity and consumables attached. Code sets let one estimate be totalled several ways for presentation and benchmarking. The .tx1 package carries the whole model, checksum-validated, so a reviewer opens the estimate rather than a report about it. Scope narrative, workshop records and approvals still live in the project file.
The risk and refinement phase is where most of the arguing happens at a funding gate. Two chapters take it apart.
Build the estimate in a model that records its own workings, then hand a reviewer the model instead of a printout.