The gang did the same trade, on the same project, at half the rate they managed six months earlier. Everyone on site knows why: the sequence changed twice, access got squeezed by a late-running enabling package, and instructions kept arriving after the crew had already started. Nobody disputes that something went wrong. What the client's QS disputes is the number, because a programme delay analysis explains why the completion date moved, but it says nothing about why the labour cost twice what it should have.
That gap between delay and disruption is where measured mile analysis earns its place. This post covers what measured mile actually measures, why it beats other productivity-loss methods when the data allows it, the records it depends on, and where it falls down if those records were never kept.
What measured mile analysis actually measures
Measured mile analysis compares the productivity achieved during an unimpacted period of a project against the productivity achieved during the impacted period, for the same trade, doing the same type of work, ideally with the same crew. The difference between the two rates is treated as the productivity lost to disruption, and that loss is then valued.
This makes it fundamentally different from the delay analysis methods most commercial teams already know. Time impact analysis, as-planned versus as-built, and windows analysis all answer a critical path question: did this event push the completion date, and by how many days. Measured mile answers a productivity question: did this event make the work cost more to do, independent of whether the finish date moved at all. A trade can be disrupted, working at half its normal rate, without ever going near the critical path, and none of the delay methods will find that cost. Measured mile is built to find exactly that.
It also sidesteps a weakness of the more theoretical alternatives. Industry productivity curves and estimating guides can model what disruption should cost in the abstract, but a defending party will always argue the model does not reflect this project, this crew, this site. Measured mile uses the contractor's own achieved output as the baseline, on the same job, which is far harder to dismiss as theoretical.
Why it works when other methods stall
Three features make measured mile the preferred method whenever the underlying data supports it.
It uses the project's own evidence, not an external benchmark. The baseline period and the impacted period both come from the same site, the same trade, often the same supervisor. That removes the usual argument that the comparison rate is drawn from a different project, a different climate, a different workforce.
It is intuitive to a tribunal or adjudicator. "This crew laid forty metres a day before the access problem and eighteen metres a day after, doing identical work" is a sentence a non-technical decision maker can follow and test. Total cost claims and modelled productivity curves rarely have that clarity.
It survives cross examination better than the alternatives, provided the underlying records are sound. The method itself is well established and widely accepted in UK and international forensic practice. Its weaknesses are almost never about the method. They are about the data behind it.
That last point is the whole game. Measured mile is only as strong as the records that populate the two periods being compared.
The record problem that breaks most measured mile claims
Measured mile fails for one recurring reason: nobody was recording daily output granularly enough, for long enough, before anyone knew there would be a claim.
No clean unimpacted period. The method needs a genuinely comparable baseline: same trade, same type of work, free of the disruption being claimed. On a live project with rolling changes, that period can be surprisingly hard to isolate if daily records do not clearly show which weeks were clean.
Output was never logged at the granularity the method needs. A diary entry reading "concrete gang on site" tells you who was there, not what they achieved. Measured mile needs a daily quantity: metres poured, units fixed, panels erected, matched to the labour hours that produced it. Without that pairing, there is no rate to compare.
The impacted period is contaminated with other causes. If three separate disruptions overlap in the same weeks, isolating the productivity loss attributable to just one of them becomes an argument about apportionment rather than a clean measurement, and apportionment arguments are exactly where these claims get eroded.
The reconstruction happens after the fact. By the time a dispute is live, someone is often asked to rebuild daily output from photographs, delivery dockets and memory. A rebuilt record carries less weight than one made the day the work happened, and the other side knows it.
What a measured mile analysis needs to hold up
Four things, kept as routine as the diary itself, not assembled only once a claim looks likely.
Daily output by activity and crew, not a weekly or monthly roll up. The finer the grain, the more defensible the baseline period and the more precisely the impacted period can be isolated.
Labour hours matched to that output, so a rate (units per hour, or hours per unit) can be calculated for every day, not estimated after the fact from a payroll total.
A dated record of what changed, so the point where the unimpacted period ends and the impacted period begins is fixed by evidence, not by argument. An early warning, a diary entry noting an access restriction, an instruction changing sequence: any of these anchors the boundary.
Consistency between the diary, the labour allocation and the programme. A measured mile analysis that draws on three records telling three different stories about the same week gets picked apart before the productivity numbers are even discussed.
This is the layer the QS AI Agent is built to remove the guesswork from. Gather reads every site diary entry as it lands, ties daily output and labour to the activity and cost code behind it, and keeps a continuous, dated record of exactly when conditions changed, so a measured mile baseline and impact period can be identified from real data months or years later, rather than reconstructed from a supervisor's memory once a dispute is already live. If you want to see what a disruption record looks like when it is built from live site data instead of assembled after the claim starts, book a 15-minute demo.
Common mistakes that undermine a measured mile claim
- Logging output weekly rather than daily, which hides exactly the granularity the method depends on.
- Choosing a baseline period that was not actually clean, because nobody checked it against the diary for other disruptions running quietly underneath.
- Letting labour hours and output quantities live in separate systems that were never reconciled to each other.
- Waiting until the dispute is live to start measuring productivity, instead of running the comparison as a routine commercial check while the work is still happening.
- Claiming the whole disrupted period as loss without isolating the specific weeks the identified cause was actually active.
A worked example
A £40m rail enabling package. A pipework crew averages 34 metres installed per day across the first eight weeks, a period with no notified disruption and a stable sequence. In week nine, a late-running interface with another contractor forces repeated access restrictions and resequencing. Over the next six weeks, the same crew, doing the same work, averages 16 metres per day.
Run it without daily records. The commercial team can point to the interface delay and the general chaos it caused, but has only a monthly output total and a payroll figure to work from. The productivity claim gets valued as a rough percentage uplift on labour cost, which the client's QS treats as an estimate rather than a measurement, and negotiates down hard.
Run it with daily diary and output records in place. Eight weeks of clean baseline data give a defensible 34 metres per day rate. Six weeks of impacted-period data, each day tied to a dated diary entry recording the specific access restriction in force that day, give a clear 16 metres per day rate. The productivity loss is 18 metres per day across six weeks, valued against the actual labour cost for those weeks, not an estimated uplift. The client's QS still queries individual days, but the method and the baseline are not in dispute, only the edges.
Same disruption, same crew, same underlying loss. The only variable was whether daily output existed as a record or had to be estimated from a monthly total.
Frequently asked questions
What is measured mile analysis in construction claims?
Measured mile analysis compares the productivity a trade achieved during an unimpacted, disruption-free period of a project against the productivity it achieved during a disrupted period, using the same trade and type of work. The difference in output rate is treated as the productivity lost to disruption and valued as a claim, making it a method for proving loss of productivity rather than delay to completion.
How is measured mile different from delay analysis?
Delay analysis methods such as time impact analysis or as-planned versus as-built assess whether an event affected the critical path and moved the completion date. Measured mile analysis assesses productivity loss independent of the critical path, so it can identify cost impact from disruption even where the completion date was never affected.
What records does a measured mile analysis need?
The method needs daily output by activity and crew, labour hours matched to that output so a productivity rate can be calculated for each day, and a dated record of when conditions changed so the boundary between the unimpacted and impacted periods is fixed by evidence rather than argument. Records kept at a weekly or monthly level are usually too coarse to support a defensible analysis.
When does measured mile analysis not work?
It struggles where no genuinely clean unimpacted period exists, where multiple disruptions overlap so the loss cannot be attributed to one cause, or where daily output and labour records were never kept at the granularity the method needs. In those situations, other approaches such as total cost or modelled productivity methods may be the only option, though both carry more risk of challenge.
The bottom line
Measured mile analysis does not need a clever argument. It needs a clean baseline, a clean impacted period, and daily records granular enough to calculate a rate for both. Most measured mile claims do not fail on the method. They fail because nobody was logging daily output before anyone knew a claim was coming.
Keep that record running as routine, not as a reaction, and the analysis writes itself from evidence instead of memory when the dispute finally arrives.
Want daily output and disruption records already assembled when a claim comes together? Gather links every site diary entry to your programme and cost codes as the work happens. Book a 15-minute demo.
Source: Gather Insights, the AI-powered site diary and commercial record management platform for UK construction.
Key Takeaways
- Measured mile analysis proves productivity loss from disruption, a different question to delay analysis, which only tests critical path impact.
- It compares a trade's output rate in a clean, unimpacted period against the same trade's rate in the disrupted period.
- Using the contractor's own achieved output as the baseline makes it harder to challenge than modelled productivity curves.
- The method needs daily output by activity and crew, matched to labour hours, not weekly or monthly totals.
- Most measured mile claims fail on missing daily records, not on the method itself.


.webp)




