Check an estimate before you send it
Put a priced bill through the validation rules, clear every warning and error, then export…
Sett et investeringsoverslag med en sats per kvadratmeter bak det, skriv ned hva det forutsetter, prissett designoverslaget for samme omfang, og sammenlign det med den godkjente versjonen ved hver port.
5 trinn gjennom plattformen - hva du gjør i hvert og hvorfor det betyr noe.
Build 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.
Hvorfor: 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.
Record 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.
Hvorfor: 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.
Price 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.
Hvorfor: 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.
Set 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.
Hvorfor: 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.
Report 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.
Hvorfor: 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.
4 / 190 plattformmoduler
Everything in this case follows how construction work is measured, priced and paid for in this market. The forms, the cost breakdown and the payment rules are the ones used there, not a generic version of them.
Standards it follows
You do not have to set any of that up by hand. The first time you open the platform it asks which market you work in. Choose this one and it sets the interface language, loads the matching cost database and records the cost classification, and it adds an example project you can open straight away.
The rule checks for this market come with the platform too. Switch them on once and an estimate that misses something the market expects is flagged while you are still working on it, not after the tender has gone out.
Put a priced bill through the validation rules, clear every warning and error, then export…
Pull priced items from a real cost database, build the bill from them, bundle recurring bui…
Turn a single-point estimate into a range, run a Monte Carlo over the genuinely uncertain l…