When a smelter project comes in over budget, the post-mortem almost always lands in the same place: the estimate was wrong. The cost engineers were too optimistic. The contingency was too thin. Steel moved, labour moved, the bauxite-to-billet capital intensity crept up the way it always seems to.
I’ve sat through a lot of those reviews, on both sides of the table. The estimate is the easiest thing to blame, because it’s a number on a page and the page has a date on it. It is also, in my experience, rarely where the money actually went.
Most large overruns on aluminium projects are not born in the estimate. They are born at the contractor interface, the seams between work packages, the scope nobody quite owned, the integration risk that got priced by no one and discovered by everyone.
The estimate takes the blame because it’s easy to put on trial
A capital estimate is a convenient defendant. It is written down, it is owned by an identifiable team, and by the time the overrun is visible the assumptions behind it are months old and easy to second guess. So that is where the inquest goes.
Image used for represenational purpose
But re-run the same project in your head with a perfect estimate, every quantity correct, every rate exactly right on the day of sanction and most of the overruns I’ve seen would still have happened. Because they did not come from getting the numbers wrong. They came from how the work was carved up and handed out.
The published data points the same way, even if it rarely gets read like this. Oxford’s megaproject research, led by Bent Flyvbjerg, finds that nine out of ten large projects run over budget, with overruns above 50 per cent far from rare. Independent Project Analysis, which has benchmarked thousands of capital projects, arrives at it from the other side: the strongest predictor of whether a project lands on budget is the maturity of its front-end definition, not the polish of the estimate. Estimates overrun, in IPA’s framing, because scope was left undefined and on a smelter, undefined scope is almost always an interface nobody pinned down.
A smelter is one system pretending to be separable scopes
A modern aluminium smelter is not a collection of independent buildings. The potline, the gas treatment centre, the rectifier and busbar system, the cast house, the paste or anode plant, the power island, these are one tightly coupled system that the contracting plan pretends to be separable.
You split the work because you have to make it tenderable. Civil to one contractor, mechanical to another, electrical to a third. The pot technology sits under a licensor with its own battery limits. The power supply is sometimes ring-fenced entirely. Each package is estimated cleanly. Each contractor prices what is inside their red line and nothing outside it.
The overrun lives in the white space between the red lines. The cable that needs a structure that isn’t ready. The GTC tie-in waiting
on a duct another contractor was supposed to leave in place. The licensor’s pot scope that stops precisely where the owner’s balance of-plant begins, with a handshake nobody fully engineered. The commissioning sequence that assumes everyone finished in an order none of them was actually contracted to finish in.
None of that shows up in the estimate. All of it shows up in the final cost and, just as painfully, in the schedule. On a smelter every week of delayed first hot metal is lost ramp-up margin you never recover. Interface failures do not only inflate CapEx. They push out the date the asset starts paying for itself.
A case from the owner’s side
Let me give a concrete one, with the specifics kept deliberately loose, because the lesson travels and the project details don’t need to. Earlier in my career I sat on the owner’s side of an aluminium casting and remelt expansion. We had taken it through FEL 2, we had our number, and we went to the market for the main package on an EPC basis. The bid came back well into double digits above our FEL 2 estimate. The investment committee was only weeks out.
The reflex in that situation is to re-bid and hope for a better price, or to negotiate the single bidder down and book the difference as “market conditions.” We did neither. That gap was not a market signal. It was the contractor pricing the interface risk we had handed them in one lump and then adding margin on top of margin, because they could not see clearly where their scope ended and ours began. When a contractor cannot price a risk, they do not absorb it. They wrap it in contingency and charge you for the privilege.
So we changed the architecture of the contract, not the estimate. We broke the single EPC package into several separate tenders and pulled the integration engineering in-house, onto the owner’s team. We chose to own the interfaces ourselves rather than pay someone a premium to own them badly.
We closed that project comfortably below the industry benchmark for comparable capacity, not below the inflated bid, below the benchmark. Same scope, same site, same market. What changed was who carried the integration risk and how visibly it was priced. The approach shaped how we ran the expansions that followed.
I am not telling that story to argue that multi-package always beats EPC. Sometimes it is exactly the wrong answer, if the owner has no engineering bench, splitting the work just means you now own a
dozen interfaces you can’t manage instead of one you paid someone else to manage. The point is narrower and more useful than “split everything”: that overrun was never an estimating problem, and no amount of re-estimating would have fixed it.
The EPC-versus-EPCM debate is usually about the wrong thing
This is where the choice of contract model tends to go wrong. Teams argue it as a pricing question. Lump-sum EPC gives me certainty; cost-reimbursable EPCM exposes me to overrun. So they reach for EPC and feel safe.
But a lump-sum price is only as firm as the scope definition underneath it. If you award EPC off an immature front end, you have not bought certainty. You have bought a low anchor and a change order engine. Every gap the contractor finds after award, they find on your account, at their margin, with you over a barrel because the schedule is already moving.
I have watched owners take EPC specifically for the comfort of a fixed number, then erode that number to nothing through variations over the following eighteen months. The contract form was never the real problem. The front-end engineering simply was not mature enough to define the interfaces before they were handed away.
What I’d actually check, before I’d ever touch the estimate
If you are an owner about to commit capital to a new smelter or a brownfield expansion, or if, as I often do now, you are running technical due diligence on one for an investor, the estimate is not the first thing I would interrogate. I would look at five things upstream of it.
The interface register. Does one actually exist, and does it name a responsible party for every tie-in between packages? If the interfaces live only in people’s heads, the gaps are already sitting inside an overrun you cannot see yet.
Who prices the white space. When a scope gap is found between two contractors, is there a defined party and a defined mechanism to price it, or does it become a fight every time? “We’ll sort it out later” is the single most expensive sentence on a capital project.
FEL maturity at award. You should not be awarding a lump-sum package off FEL 2 thinking. Carrying the front end to genuine FEL 3 / FEED maturity, with the interfaces defined to that level, not only the equipment, is what makes a fixed price actually fixed. A lump sum is only as firm as the scope definition under it; FEED is where interface ambiguity is either resolved or quietly priced into the overrun you meet later.
The owner’s bench. Whoever holds the integration layer needs the people to hold it. If the owner has no engineering depth, and hands everything to an EPCM that is also thin on this asset class, the interface risk has an owner on paper and no owner in practice.
Change-order governance. Not whether changes happen, they always do, but how quickly they are priced, who approves them, and whether project controls can see the cumulative drift before it becomes irreversible.
None of those five is an estimating question. Every one of them decides whether the estimate survives contact with construction.
The estimate is an output; the interface is the system
When a project comes in high, the instinct is to argue with the output. Re-estimate, re-baseline, hunt for the contingency that should have been there. It is the wrong end of the problem.
Define the interfaces, price them, own them, govern them and the estimate tends to hold. Get them wrong, and no contingency will save the number. I have seen both outcomes more than once. The difference, almost every time, was not the quality of the estimate. It was the quality of the seams.
There is a wave of new smelter and brownfield expansion capacity going into the ground right now across India and Southeast Asia. The estimates on those projects will be argued over in a hundred review meetings. The interfaces will quietly decide how they actually close.
Voyagerman Technology
