Cost Benchmarking: How to Normalise Historical Data on Capital Projects
How to normalise historical cost data across time, location, currency and scope so cost benchmarking survives an estimate review on capital projects.
A gas processing facility built in Rotterdam in 2019 came in at £180m. A near-identical unit is being sanctioned in Texas for delivery in 2027, and the sponsor wants to know whether the £240m estimate on the table is credible. Pull the two numbers side by side and the comparison is worthless: different year, different labour market, different currency, different scope boundary. Cost benchmarking only works once those differences are stripped out. Get the normalisation right and £180m and £240m tell a consistent story; get it wrong and the benchmark quietly endorses a bad number.
This article covers what cost benchmarking actually requires to be defensible: the four dimensions every historical data point must be normalised across — time, location, currency, and scope — the indices and factors that do the adjusting, the battery-limits trap that wrecks most naïve comparisons, and how to build a benchmarking process that holds up in an estimate review. The payoff is a benchmark you can put in front of a steering committee without it falling apart under the first hard question.

Why raw cost data lies
The instinct on every capital project is to reach for a comparable: “the last one cost £X, so this one should be about the same.” The instinct is sound — historical cost is the best predictor of future cost — but the raw number is almost never usable as it stands. Two projects that look identical on a one-line summary can differ by 30–40% on cost drivers that never appear in the headline figure.
Consider the same scope built three years apart in two countries. Construction inflation might add 12–15% over the gap. A move from a low-cost to a high-cost labour market can add another 20% on the installation portion. A currency shift of 8% swings the number again. Before a single technical difference is accounted for, the two projects can legitimately differ by more than a third — and none of that variance tells you anything about whether the new estimate is good or bad.
This is why cost benchmarking is a normalisation exercise before it is a comparison exercise. The comparison is trivial once the data is on a common basis; getting it onto a common basis is the entire job. A benchmark quoted without stating the reference date, the location basis, the currency, and the scope boundary is not a benchmark — it is an anecdote.
The four dimensions of cost benchmarking
Every historical cost point carries four attributes that must be aligned to a single reference basis before any two points can be compared. Skip one and the comparison is contaminated.
- Time. Costs are anchored to the period they were incurred. A 2019 installed cost cannot be compared to a 2027 estimate without adjusting for escalation across the intervening years — see our detailed treatment of cost escalation in long-duration capital projects.
- Location. Labour rates, productivity, material logistics, and market conditions vary by geography. The same scope built on the US Gulf Coast, in northern Europe, and in remote Australia carries materially different installed costs.
- Currency. International benchmarks must be converted to a common currency, and the exchange rate used matters — a spot rate on the day of comparison is not the same as the effective rate over the construction period.
- Scope. The most dangerous of the four, because it is the least visible. Two projects can share a name and a capacity and still draw their cost boundary in completely different places.
Normalise all four and the residual difference between two projects is real — it reflects genuine differences in design, execution, or market. That residual is the signal. Everything the normalisation removed was noise.
A benchmark quoted without its reference date, location, currency, and scope boundary is not a benchmark — it is an anecdote.
Time: indices and escalation
Adjusting cost for time means applying a cost index that tracks how prices in the relevant industry have moved. For process and chemical plant, the Chemical Engineering Plant Cost Index (CEPCI) is the long-standing reference; it is a composite built from equipment, construction labour, buildings, and engineering sub-indices, most of which map to US Bureau of Labor Statistics producer price indices. For UK building and infrastructure work, BCIS indices serve the same purpose.
The mechanics are straightforward: multiply the historical cost by the ratio of the index at the target date to the index at the original date. A £180m cost from a period when the index stood at 600, brought to a period when the index reads 690, normalises to £180m × (690 ÷ 600) = £207m. The discipline is in choosing the right index — a composite plant index misstates a project that is 70% civil works — and in using a consistent index across every data point in the benchmark set.
A common error is to normalise the historical projects for time but leave the new estimate at its own base date, or vice versa. Every point in the comparison, including the estimate under review, must be brought to one agreed reference date. Mixing base dates reintroduces exactly the escalation noise the exercise is meant to remove.
Location, currency, and scale
Location adjustment uses location factors — indices that express how construction cost in a given area differs from a baseline, independent of the design. Move an estimate from the US Gulf Coast to a remote site and a location factor of 1.35 says the same scope costs 35% more to build there, driven by labour productivity, logistics, and local market conditions. Providers such as BCIS publish location factors precisely so that a cost captured in one market can be transposed to another.
Currency conversion sounds trivial and is not. The defensible convention is to convert using the effective exchange rate over the construction spend period — often approximated by the rate at the midpoint of construction — rather than a spot rate on the day the benchmark is drawn. A benchmark set assembled with today’s spot rate silently embeds every currency swing since each project was built.
Scale is the fourth adjustment, and it is not linear. Doubling the capacity of a process unit does not double its cost; the relationship typically follows a power law with an exponent around 0.6 — the familiar “six-tenths rule”. A benchmark drawn from a 500,000-tonne plant cannot be applied to a 1,000,000-tonne plant by simple proportion without overstating the larger unit’s cost. Where the historical data supports it, a fitted scale exponent is more defensible than a single-point ratio, and this is where benchmarking and parametric estimating for early-stage capital projects start to converge on the same underlying data.

Scope alignment: the battery-limits problem
The adjustments above are arithmetic. Scope alignment is judgement, and it is where benchmarks most often go wrong. Two projects quoted at the same “total installed cost” can have drawn their battery limits — the boundary of what the number includes — in entirely different places. One might include owner’s costs, site infrastructure, and first fill; the other might be inside-battery-limits process equipment only. The gap between those two definitions can exceed 25% of the total, and no index will ever correct for it because it is not a price difference — it is a content difference.

Normalising for scope means decomposing each benchmark to a defined cost breakdown structure and confirming, line by line, that like is being compared with like. Are owner’s costs in or out? Is contingency included, and at what confidence level? Are enabling works, temporary facilities, and commissioning captured? A disciplined benchmark states its inclusions and exclusions explicitly, ideally against a standard code of accounts so that every project is sliced the same way. This is where a robust cost breakdown structure earns its keep — without one, scope normalisation is guesswork.
The practical test is simple: if you cannot state exactly what each benchmark number includes and excludes, you cannot use it. A tight, well-normalised number from a slightly less similar project beats a fuzzy number from a closer one every time.
Building a cost benchmarking process that survives review
A benchmark is only as good as its provenance, so the process has to be documented, not improvised. Start by defining the purpose and the boundary: what question is the benchmark answering, and what is inside and outside the comparison. Then assemble the reference set — enough projects to be statistically meaningful, similar enough to be genuinely comparable. Two well-understood analogues beat ten loosely related ones.
For each project in the set, capture the raw cost together with its four normalisation attributes, then apply the adjustments in a consistent order: escalate to the common date, convert to the common currency, adjust for location, adjust for scale, and reconcile scope to the common code of accounts. Record every factor used and its source. When a cost benchmarking result is challenged in review — and it will be — the answer to “why is this credible?” has to be a traceable chain of adjustments, not an assertion.
Finally, express the output as a range, not a point. Normalisation reduces noise but never eliminates it, and a benchmark presented as a single number invites false precision. A defensible cost benchmarking output says: on a normalised basis, comparable projects delivered at £X to £Y per unit of capacity, and the estimate under review sits inside, above, or below that band — with the reasons stated. That is a benchmark a steering committee can act on, and one that will still stand up when the estimate is revisited at the next stage gate.
Key Takeaways
- Cost benchmarking is a normalisation exercise before it is a comparison exercise: raw historical costs are almost never comparable as they stand.
- Every data point must be aligned across four dimensions — time, location, currency, and scope — before any two projects can be compared.
- Time and location adjustments rely on cost indices (CEPCI, BCIS) and location factors; every point in the set, including the estimate under review, must be brought to one reference basis.
- Scale is non-linear and follows a power law (roughly the six-tenths rule), so capacity differences cannot be corrected by simple proportion.
- Scope alignment via a common battery-limits definition and code of accounts is where most benchmarks fail — no index corrects a content difference.
- A defensible benchmark is documented, traceable, and expressed as a range, so it survives challenge in an estimate review.