Cases / Estimating & costing
Estimating & costing

Build a parametric assembly

Give an assembly named parameters and drive its component quantities from formulas over them: enter the wall area when you apply it and let the reinforcement, the concrete and the composite rate follow.

4 steps12 minCost consultancy / QS practiceGeneral contractorSpecialist subcontractor

How it works, step by step

4 steps across the platform - what you do at each one, and why it matters.

1

Name the parameters

Assemblies

Give the assembly the few named parameters it really turns on. Each is one of three kinds: an input the estimator enters when they apply it, with a sensible default; a constant that does not move, such as a rebar ratio; or a calculated value derived from the others, such as area from length times height.

Why: The parameters are the questions the assembly asks whoever uses it, so keep them to the ones that genuinely change between jobs. Every extra input is another figure somebody has to be right about at half past five on the day the tender goes in.

InBuild-up you price repeatedlyWhat actually varies job to jobOutNamed parametersResolved default values
2

Drive the quantities from a formula

Assemblies

Set a component's quantity from a formula over the parameters instead of a fixed number, the reinforcement as wall area times the rebar ratio, the formwork as area times a double-sided factor. Any line whose quantity is computed carries an fx marker on it.

Why: A fixed recipe makes you re-derive the steel by hand every time the wall moves. Written as a formula the relationship is stated once, so the ratio you agreed with the engineer is the ratio in every priced line, and the fx marker stops anyone reading a derived quantity as one that was measured.

InNamed parametersComponent linesOutQuantity formulasComputed lines marked fx
3

Prove it before anyone uses it

Assemblies

The editor checks the parameter graph as you work and flags problems inline against the parameter or component they belong to: a name referenced but never defined, two parameters sharing a name, a formula that will not parse, a cycle where two calculated values depend on each other. Then run the expansion preview at real values and read the quantity each line moves from and to, plus the rolled-up rate the server will write.

Why: A cycle or a stale reference does not announce itself in a spreadsheet, it just returns a number that looks plausible. Previewing at values you actually expect is what catches a formula that is right in principle and out by a factor of ten, and because the preview runs on the same decimal arithmetic as the live expansion, the rate you read here is the rate that lands, exact to the cent.

InDraft parametric assemblyValues you expect on the jobOutNamed errors, if anyBefore and after per line
4

Apply it to the bill

BOQ

Place the assembly on a bill position and enter the one figure it asks for, the wall area for that element. The components expand at those values and the composite rate follows, with nobody retyping a quantity.

Why: This is where the parametric version earns its keep over a fixed recipe. When the wall grows at the next design issue you change one input rather than eleven component quantities, and the two or three that would quietly have been forgotten move with the rest.

InProven assemblyWall area for this elementOutPriced bill positionComponents at computed quantities
Modules

Modules in this playbook

AssembliesBOQ

2 / 184 platform modules

More in Estimating & costing

Estimating & costing

Estimate from a cost database

Pull priced items from a real cost database, build the bill from them, bundle recurring bui…

4 steps12 minOpen
Estimating & costing

Set contingency from cost risk

Turn a single-point estimate into a range, run a Monte Carlo over the genuinely uncertain l…

3 steps11 minOpen