Should you be tracking construction cycle times? Here's the case for it

Most buildings aren't built once. They're built as the same unit, repeated: a data hall, an apartment floor, a hotel room, a hospital ward. In many project types, most of the schedule lives inside a unit like this, built over and over.

But if you ask a team, “How long should one data hall, or one apartment floor, take to build?”, most can only answer with a ballpark figure. Rarely an objective number based on the units they’ve recently delivered. That’s precisely what measuring cycle time (the time it takes to build one repeatable unit from start to finish) gives you. 

At the Intelligence Lab, we’ve received several questions about measuring construction cycle times recently. So, we dug into the data to see whether we could answer the question – among all other construction metrics, are cycle times worth tracking? And if so, what can they teach us?

To do this, we looked at two rather different examples: 

1. MEP fit-out across eight data halls at a single data center.
2. Floor-by-floor structural-to-finish cycle across a multifamily high-rise.

What does cycle time measure?

A lot of construction, whatever the asset class, is built not as a single bespoke object but as the same unit repeated over and over.

Cycle time is the time it takes to build one instance of a repeatable unit (a data hall, an apartment floor, a hospital room, etc.) from a defined start milestone to a defined finish milestone. 

Examples

Data center: A 95-day gap inside one building

At the data center, the repeatable unit was the data hall, and the cycle ran from initial bracketry (10% complete) to electrical final fix (90% complete). Across eight essentially identical halls, cycle time ranged from 154 to 249 days – a 1.6× spread, on the same site, with the same crews and the same design. Without a per-unit cycle time measurement, that spread wouldn’t show up in a typical status report. But it certainly raises some questions about what’s going on under the surface.

Multifamily: A vague feeling becomes a precise number

At the multifamily project, the unit was the floor, and the cycle ran from blockwork (10%) to floor tiling (90%), measured against the client's 153-day target. Most floors ran over target, ranging from 177 to 261 days. 

That's not a new finding on its own. Most site teams can tell you when it feels like certain floors are moving slower! What cycle time adds is precision: which floor, how many days over, and against what commitment. 

So, should you be measuring construction cycle times?

The two examples above are single-project findings, not industry benchmarks. But they point to the same conclusion from two unrelated asset classes. If a large share of your schedule lives in a repeating unit and you're not measuring how long that unit takes to build, there's a number in your data that would tell you more than your current status report does. 

For example, over time, measuring cycle times can unlock: 

• Benchmark bands: Low, median and high cycle time per unit type, so every new unit is judged against real history, not a guess.
• Outlier detection at scale: Slow units surface automatically, across every site, not just the one you happen to be watching – giving you the signal to investigate root cause immediately.
• Schedules built from evidence: Anchored to what you actually achieve, not what the last estimate assumed.
• More predictable pricing: When cycle time is a known, benchmarked number rather than a guess, the schedule risk baked into a bid or budget shrinks.
• Year-over-year improvement: A single, comparable curve across sites that tells you whether you're getting faster, and by how much.

The catch: Measuring cycle times only works if you have standardized data

Comparisons like these get sharper the more every project measures the same unit, the same way. If one site calls a floor “started” at first concrete pour and another calls it “started” at formwork, or one team splits a data hall into four zones and another into six, it’s much harder to make a comparison.

That alignment doesn't happen on its own. When they’re left to drift, activity lists, milestone definitions, and zone breakdowns diverge from project to project. It’s something organizations have to plan for deliberately, either themselves or by working with tech partners.

Ideally, before the first cycle time is ever recorded, these four key things should be decided at the design and planning stage: 

• The definition of the repeatable unit.
• The work-breakdown structure.
• What “started” and “done” mean at each milestone.
• The schedule template itself. 

If you establish these solid foundations across every project, cycle time, along with every metric built on it, can scale relatively seamlessly from a single project to the whole portfolio.

So, what do you think? Are you likely to pay closer attention to cycle times going forward? Let us know.