3. Case Study A — Optimizing Formwork & Falsework Strategy for a 20-Storey Commercial Office Tower
The figures, rates, and project parameters used below are illustrative — constructed to demonstrate how the calculation engine behaves, not drawn from a specific tender or client project. The mechanics and the resulting cost curves are representative of real project behaviour; the specific dollar figures are not sourced data.
3.1 The Question
A 20-storey commercial office tower has a typical floor plate of 1,800 m² (36,000 m² of structural floor area in total), with a system formwork and falsework set costing $220,000 to fabricate, mobilise, and commission. The traditional estimate asks “what is the concrete floor rate per m²?” The real question a first-principles model can answer is: how many formwork sets produce the lowest total project cost once both capital outlay and construction duration are accounted for?
A flat-rate estimate — 36,000 m² at a blended floor rate — hides the cost structure entirely: formwork capital, crane allocation, floor cycle time, and time-related preliminaries all behave differently, and none of them are visible in a single rate.
3.2 Modelling Floor Cycle Time as a Formula
Floor cycle time is governed by how many levels can be worked concurrently, which in turn depends on the number of formwork sets in circulation. In Methvin, this is authored as a resource-level formula referencing a project variable (Formwork_Sets) — a project-scoped variable inheriting from the global default unless overridden (Section 2.6) — rather than typed in as a fixed duration:
T_floor(N) = t_curing-to-strike + MIN(T_formwork_cycle(N), Crane_Hook_Time_Budget) + t_strip + t_reposition + t_pour + t_align
where T_floor(N) is the effective days-per-floor as a function of the number of formwork sets N, and t_curing-to-strike — the time for concrete to reach strike strength — is largely fixed regardless of how many sets are held. T_formwork_cycle(N) is the raw formwork turnaround time, and it falls as N increases: additional sets let more levels be formed, poured, and stripped concurrently. The MIN() function makes that trade-off explicit in the equation itself — as N grows, T_formwork_cycle(N) keeps falling, but once it drops below Crane_Hook_Time_Budget, the tower crane’s shared hook-time allocation across formwork, steel, and façade trades, the crane rather than the formwork sets the pace, and additional sets stop shortening the cycle.
Assumption check: this formula holds for a single tower crane shared across trades and a floor plate simple enough to form as one pour per level — a simplification used here to isolate the trade-off being demonstrated. A building with a split core-and-perimeter pour sequence, or with a second crane, would adjust this for concurrent pour zones, which the underlying engine handles by letting each zone’s cycle be entered as its own formula node rather than derived from a single assumption.
3.3 Why a Flat Duration Rate Fails
Many systems assume duration per floor is simply inversely proportional to the number of formwork sets — double the sets, halve the time — because they have no mechanism for expressing a fixed component and a bottleneck-constrained component in the same calculation. This ignores the fixed component of the cycle: concrete needs a broadly constant number of days to reach strike strength no matter how many sets are available, and every additional level being worked concurrently competes for the same crane hook-time each shift. Extra sets therefore deliver large gains at first, then rapidly diminishing ones as the crane, not the formwork, becomes the bottleneck.
3.4 Effective Cycle Time by Number of Formwork Sets
Formwork Sets | Effective Days / Floor | Programme Duration (20 Floors) |
|---|---|---|
| 1 | 12.0 days | 240 days |
| 2 | 8.0 days | 160 days |
| 3 | 6.0 days | 120 days |
| 4 | 5.0 days | 100 days |
| 5 | 4.5 days | 90 days |
| 6 | 4.3 days | 86 days |
Beyond 4–5 sets, the tower crane’s shared hook-time budget — not formwork availability — becomes the limiting factor, which is why the marginal reduction in days/floor flattens sharply from Set 4 onward. In the underlying worksheet this is the MIN() function referenced in 3.2 resolving to the crane constraint rather than the formwork-cycle constraint.
3.5 Scenario Results
Formwork Sets | Capital Cost | Programme Duration | Preliminaries Cost | Total Cost |
|---|---|---|---|---|
| 1 | $220,000 | 240 days | $4,440,000 | $4,660,000 |
| 2 | $440,000 | 160 days | $2,960,000 | $3,400,000 |
| 3 | $660,000 | 120 days | $2,220,000 | $2,880,000 |
| 4 | $880,000 | 100 days | $1,850,000 | $2,730,000 |
| 5 | $1,100,000 | 90 days | $1,665,000 | $2,765,000 |
| 6 | $1,320,000 | 86 days | $1,591,000 | $2,911,000 |
Preliminaries cost is time-related site overhead — supervision, crane hire, temporary works, and cost of capital during construction — modelled here at $18,500/day. Every column in this table is a formula output, not a manual entry: changing the $220,000 set cost or the $18,500 daily preliminaries rate recalculates every row through the dependency graph described in Section 2.8.
3.6 The Insight
The optimum is neither the smallest formwork spend nor the shortest possible programme — it’s the point where the marginal capital cost of an additional set stops being offset by the preliminaries saved through a faster cycle. Here, that’s 4 sets: $880,000 in formwork capital against a 100-day programme, for the lowest combined cost of $2.73M. Finding that point requires recalculating the full model across every scenario — exactly what a flat unit rate can’t do, and exactly what the formula, variable, and DAG-based recalculation engine described in Section 2 does natively.
3.7 Dynamic Recalculation During Tender Progression
The scenario in 3.1–3.6 assumes the tower crane’s hook-time budget is dedicated to this building for the full programme. Tenders rarely stay that clean. Partway through pricing, the design team confirms a neighbouring tower will share the same crane corridor, cutting the Crane_Hook_Time_Budget variable referenced in 3.2 from a dedicated allocation to a 60% share. In a flat-rate estimate, absorbing that change means re-deriving the floor-rate assumption by hand and hoping every downstream reference gets updated. In Methvin, it means editing one project variable.
Because Crane_Hook_Time_Budget feeds the MIN() function inside T_floor(N) (3.2), which feeds the scenario table in 3.4, which feeds the total-cost model in 3.5, the entire trade-off recalculates the moment the variable changes — no re-keying, no re-running a separate spreadsheet, no chasing the change through six tabs by hand. And because the crane constraint now binds at a lower set count, the answer itself changes:
Metric | Baseline (Dedicated Crane) | Revised (60% Shared Crane) |
|---|---|---|
| Optimal formwork sets | 4 sets | 3 sets |
| Days / floor at optimum | 5.0 days | 7.0 days |
| Programme duration | 100 days | 140 days |
| Total project cost | $2.73M | $3.25M |
(Illustrative figures — see note at the start of this paper.)
The optimum formwork spend has moved from 4 sets to 3, and the target total cost has moved from $2.73M to $3.25M — not because anyone re-modelled the project, but because one variable, three layers down in the dependency graph, was edited once. That is what “live” means in a computational estimate: the recommendation itself is a function of current inputs, not a snapshot taken the day the tender was priced.