Estimating & costing
Check an estimate before you send it
Put a priced bill through the validation rules, clear every warning and error, then export…
3 steps8 minOpen
Cases / Estimating & costing
Estimating & costing
Hold the design estimate to the approved budget
Set an investment estimate with a rate per square metre behind it, write down what it assumes, price the design estimate against the same scope, and compare it with the approved version at every gate.
How it works, step by step
5 steps across the platform - what you do at each one, and why it matters.
1
Set the investment estimate as a rate, not just a total
Conceptual EstimateBuild the feasibility number from the building type, the gross floor area and the quality level, and read off the rate per square metre it implies as well as the total.
Why: A total is a fact about a building nobody has designed yet, and a design team cannot work to it. A rate per square metre is a constraint they can test every decision against, which is the whole mechanism of cost-capped design, and it stays comparable when the area moves.
InBuilding type and quality levelGross floor areaOutInvestment estimateRate per square metre
2
Write down what the approved number assumes
Basis of EstimateRecord the basis: the scope covered, the standard of finish, the price level and date, what is excluded, and where the rates came from. Keep it with the estimate rather than in the covering email.
Why: Every argument at the next gate is about whether the design changed or the estimate was wrong, and only the basis can answer it. Without one, a stage that comes in over is always explained as a scope change, and there is nothing on either side that can contradict that.
InThe approved numberWhat it assumedOutWritten basis of estimateExclusions on the record
3
Price the design estimate and name the version
BOQPrice the design item by item against the same scope the basis describes, and save a named version of the bill at the moment it goes for approval so the approved state can be retrieved exactly.
Why: The version that was approved is the only meaningful thing to measure later movements against, and it is unrecoverable a month afterwards unless somebody named it at the time. Naming it costs a moment and turns the next comparison from an argument into a report.
InDesign as it standsThe stated basisOutDesign estimate priced by itemNamed version at the gate
4
Compare against the approved version at every gate
BOQSet the current bill against the version approved at the previous stage and read the difference by section: which items were added, which quantities grew, which rates moved. Work the rate per square metre out again on the current area and put it beside the one you started with.
Why: Nothing here declares a limit or returns a verdict, and that is the honest shape of it: the product shows you where the money went and the cap is held by people. What makes that workable is running the comparison at each gate rather than once at the end, because a section that has grown by six percent is a design conversation while a total that has grown by twenty is a re-approval.
InThe bill as it stands nowThe approved versionOutWhich sections movedThe rate per square metre now
5
Report the position with the movement explained
ReportsReport the stage total, the rate per square metre, the difference against the approved figure and the sections it came from, with a line on each saying whether it was a scope change, a design decision or a price movement.
Why: An approving body asked to consider a number will ask where it came from, and a report that answers that in advance gets a decision instead of a deferral. Naming the cause per section is also what tells the design team where the savings have to come from, which is the only useful output of the exercise.
InThe gate comparisonOutStage report for approvalWhere savings have to come from
