Precast Manpower Estimator

Buildability is scored on design. The Code of Practice awards labour-saving points for how a building is put together, and Annex C sets an area-per-manday target — but it publishes no element labour rates. A crew size cannot be read out of a Buildability score, and this tool never tries to. It goes the other way: count what the model actually contains, price it with rates that are stated and editable, and let the programme decide the crew.

Read this before quoting any figure. This is a proof of concept: it turns a count of precast elements per building level into an indicative labour demand and floor cycle using assumed planning rates — not measured site outcomes. Every number is reproducible from the IFC alone.

Time per piece has three parts because they scale differently. Handling — hook on, sling, land, align, plumb, prop, unhook, return — barely moves with weight. Lifting does: a hoist winch runs slower under load (a Potain MD 185A does about 108 m/min light and 46 m/min on the geared-down winch), heavy pieces are inched in on approach, and rigging gets more deliberate. Grouting is the joint, and belongs to the connection rather than to the piece. Splitting them is what lets a 9-tonne transfer beam cost more than a 1.5-tonne plank instead of the same.

The reference crew is the crew the rates were observed with, not a choice about the answer — and it does not cancel. Quote a piece at 35 crew-minutes and the work content is 35 x reference_crew / 60 labour-hours, so reading a 6-person crew's rates as if they were a 10-person crew's overstates the work, and every crew derived from it, by exactly 10/6. It also anchors the diminishing-return curve: at crew = reference_crew the efficiency factor is 1, and the cycle is just the hours that crew would take. The 0.78 exponent is the falling return from adding people to one floor — from a 10-person anchor, 18 people do the work of about 15.8. State the crew your rates came from in the site factors, and read any derived crew far from it as an extrapolation.

Levels are erected in order, and that is the whole point of the last three lines. Level n+1 stands on level n, so a tower is a precedence chain: their cycles add. Adding people shortens each cycle, sub-linearly, until the workface is full at 18 — and then stops. Thirty levels cannot be erected at once, at any headcount, because twenty-nine of them have nothing to stand on yet.

Two sequence assumptions ship switched off, and stay off until someone states them. A cure and prop-release hold is elapsed time between levels — grout gaining strength, props staying in, a topping curing — and it is the one quantity here that neither a crew nor a second crane can shorten, so it is added after the MAX rather than inside it. The default of zero days is a declaration that the programme carries no hold point, not a claim that grout cures instantly; take the number from the grout's datasheet and the engineer's prop-release criterion. Repetition learning runs the other way: the unit form of the learning curve, where each doubling of the levels a crew has erected costs learning_rate of the previous one. Published construction rates sit in the 80–95% band and repetitive precast belongs at its shallow end, but the unbounded curve is wrong past the first handful of repeats — at 90% it would have the thirtieth level erected in 60% of the first level's time — so improvement is clamped at 20%. Both are assumptions about your site and your crew, never measurements from the model, and the panel says which way each one moved the answer.

Only two things genuinely run in parallel. Crews at once counts physically separate structures — another block, another tower — because that is what lets a second crew work in parallel. The tool never infers it from the model; you state how many you have, and the default is one. Cranes raise the hook ceiling. That ceiling matters: one crane placing 16 pieces a shift needs 563 shifts for 9,000 pieces no matter how many people are standing on the floor, which is why crane_days is a floor under the answer rather than a footnote. The panel names which of the three — sequence, crane, or simply not enough work — is binding.

Given all that, Crew from: project duration sweeps crew sizes from the lawful floor up to 18, and takes the smallest one whose sequenced total fits the window. If none does, it says the window is not achievable and reports the earliest finish it can reach, rather than quoting a crew that would not deliver it.

The floor is set by law before it is set by practice. Under the WSH (Operation of Cranes) Regulations 2011 nothing may be lifted until a lifting supervisor (reg 17), a rigger (reg 18) and a signalman (reg 19) have been appointed, and only a registered crane operator may work the crane (reg 5). Those are not interchangeable with erectors: MOM's Code of Practice requires the signalman to hold their line of sight and to “refrain from handling load/ rigging simultaneously when giving signal”, and the lifting supervisor to be present and to keep the operation in view. So the crew carries a lifting supervisor, a signalman per hook and riggers per hook, and only what is left over receives, aligns, plumbs and props the piece — four of them at the very least, which is the one part of this floor that is practice rather than law. At one crane and one crew that comes to 1 + 1 + 2 + 4 = 8, which is where the tested band starts. A second crane is therefore not a free lever: it brings its own signalman, its own riggers and its own registered operator, and the lever table charges for them.

None of these is a measured outcome from this project, and none of them is a published rate for a Singapore residential precast crew — no such table is public. They are a defensible starting point, calibrated against what is: the shipped defaults put a whole piece at 24–36 crew-minutes, the low end of BCA's own band, which is where a repetitive floor with a settled crew belongs.

• Weight moves the answer, but only through one term. Lifting minutes scale with tonnage; handling and grouting do not. A 9 t transfer beam therefore costs more than a 1.5 t plank — about 19 minutes more at the default rate — but not proportionally more. Piece count still dominates a normal residential floor, which is what the stage split under the results is for.
• Quantities are taken as declared. The model is read without its geometry, so a contradictory pair of quantity families cannot be arbitrated against a measured volume the way the full appraisal does — the declared NetVolume, else GrossVolume, is used. This is the price of opening a several-hundred-megabyte model in a tab, and it is the reason a tonnage-sensitive result is worth checking against the authoring tool.
• An assumed weight is an assumed labour figure. Models exported without base quantities fall back to a reference weight per type. The lifting term is then an assumption stacked on an assumption; the per-element table marks every piece it applies to.
• Joints are typed, not counted. IFC carries no connection take-off, so grouting labour rests on an assumed number of joints per element type. It is the single largest soft spot in the estimate, which is why the range is built from it.
• The rates are assumptions. They are not derived from completed floors. Replace them with approved site outcomes before any operational or commercial use.
• A level named Unassigned is a parsing artefact, not a floor. If an export omits spatial containment, the whole building can land in one bucket and its cycle will look absurd.
• Precast detection is keyword-based. Untagged precast is silently excluded; a mislabelled in-situ element is silently included. Both shift the answer.
• Models above 400,000 elements are truncated. That is this page’s own ceiling, four times the engine default, because this page builds no geometry. When it is hit a warning appears above the results and the labour figure is an under-estimate — and so, in turn, is the crew the programme demands.
• The duration is the erection window, not the contract. The tool takes the months you give it as time available for precast erection. Substructure, fit-out, and any float between the last panel and handover are yours to deduct before typing the number.
• The number of crews is your claim, not the model's. The tool cannot tell one tower from two, so it takes the number you give it and splits the levels evenly between crews. Set it above one only where there really is another structure to stand on, with its own crane and its own access.
• Levels worked by one crew are treated as interchangeable, in order. Their cycles add, which is right, but the arithmetic does not sequence a transfer floor before the tower above it, or model a crew trailing a floor behind doing grouting while the next is erected.
• The lifting roles are a floor, not a plan. The crew is never sized below the lifting supervisor, signalman and riggers that must be appointed before a crane may lift, and that floor rises with every hook — but the tool cannot tell you that your appointed people are trained, in date, or actually on the level. It also charges one signalman per crane and one lifting supervisor per crew, which is this tool's reading of their duties; the Regulations state the appointments, not the arithmetic.
• The crane ceiling is one number. Lifts per shift does not vary with piece weight, radius, height or wind, and a second crane is assumed to have equal reach. Real crane contention needs the simulation this PoC does not have.
• Grout cure and prop release are a number you supply, not one the tool knows. The programme carries a per-level hold and reports what it costs, but it ships at zero and the model cannot derive it: the curing regime is a property of the grout, the ambient conditions and the engineer's prop-release criterion, none of which is in an IFC. Leaving it at zero is assuming a level is released as soon as its own erection finishes.
• The learning curve is an assumed rate, and a blunt one. It is applied by repetition count, so it cannot tell a genuinely repetitive typical floor from a transfer level that happens to come next, and the 20% clamp is a stated stopping point rather than a measured plateau. A crew's real curve comes from its own recorded cycles.
• Out of scope entirely: erection sequencing within a level, crane availability and crane cycle contention, deliveries and site logistics beyond the flat allowance, weather, post-installation works, and every trade other than precast.

• Real-time, in-tab processing. Your model is read, parsed and discarded in this browser. There is no upload endpoint, no database, no project storage and no analytics.
• Nothing persists. No cookies, no local storage, no session. Closing or reloading the tab discards everything — there is nothing to resume and nothing to delete.
• Enforced, not just promised. A Content-Security-Policy confines this page to its own origin and blocks form submission, so model data cannot leave even if the code were faulty.
• Traffic is inbound only. The page downloads two static reference files, the buildability code and the classification rules. Nothing is sent back.
• CSV export is generated in the browser and saved by the browser. It is not transmitted.
• What the host still sees: the ordinary web-server record of your request for this page and its assets. It never sees your IFC — that does not cross the network.
• The source links are the only way out. The citations under “where the default rates come from” are ordinary links to other sites; they open in a new tab, send no referrer, and carry nothing about your model. Nothing on this page follows them for you.
• Size. Files above 1 GB are rejected before parsing, and a cap of 400,000 elements applies — when it is hit the model is truncated, the warning banner says so, and the labour figure and the crew derived from it are under-estimates. The model is read in slices rather than as one string, which is what makes a large file possible at all: file.text() has to produce a single JavaScript string, and an engine caps a string at 2²⁹ − 24 characters, so anything past about 512 MB used to fail with RangeError: Invalid string length before a line of this page ran. Only the entity types a take-off reads are parsed — elements, the spatial tree, quantities, properties, materials, units — and the geometry, which is most of an IFC and none of this calculation, is stepped over. Measured on a synthetic 600 MB model: 22 seconds, 323,120 precast elements, 9.0 million geometry entities skipped, about 1 GB of tab memory. Parsing still runs on the page thread, so the tab will be busy while it works; the progress figure is real, not a spinner. Above 400 MB the page says so before it starts.