A feasibility model exists to answer one question: should this project proceed? Fixed assumptions are the right tool for that. A single recovery figure, a design availability, a nameplate throughput — each states the performance the project is expected to deliver. The study is approved on those numbers, and capital is committed against them.

‍

Once operations begin, I have seen this go two ways: either the model was never made available to the people running the project, or it was available but never used. In both cases there was no baseline that performance was measured against.

‍

What the Investment Case Promises

‍

What is underwritten is not what the project is. It is what the project is expected to do — a set of operational numbers, judged credible enough to justify capital:

• recovery at a stated feed grade
• availability across a defined maintenance regime
• throughput sustained at design rate
• unit costs at that level of activity

‍

Those figures are the promise the project makes to the people funding it. They are also, once the plant is running, entirely measurable.

‍

Where the Baseline Gets Left Behind

‍

At handover, operations picks up production reporting, budgets and monthly cost variance. Resetting budgets from recent actuals is the right way to run the year ahead — it reflects current conditions and keeps targets achievable. But none of it answers whether the project is delivering the case it was approved on. Each reset moves the reference point, and the operation is measured against its own recent performance rather than the forecast that justified the investment.

‍

The forecast has not become wrong. It has become disconnected.

‍

‍

Building a Model That Takes Actuals

‍

Every operational improvement program depends on the same three things: a problem defined precisely enough to solve, a baseline that quantifies it, and a way to measure movement against that baseline. I have seen programs fail on exactly that — the problem loosely defined, the baseline never established. Money and effort go in, and what comes out is either the wrong outcome or a gain nobody can trace back to the spend.

‍

The investment case is the baseline. To use it as one, the model has to take actuals, and that should be designed in:

• parameter definitions that match how the operation already measures itself
• a period structure that accepts monthly actuals against the forecast for the same period
• calculation logic that updates the investment case as actuals replace assumptions

‍

Without that, every forecast-to-actual comparison has to be rebuilt by hand. That is often why it stops happening.

‍

What Tracking Actuals Makes Possible

‍

Once actuals run through the same structure that produced the forecast, variance carries both a cause and a value. Optimisation questions become answerable:

• What is the return on a plant availability improvement program?
• Where is the economic bottleneck — mining, processing or logistics?
• What is the trade-off between maintenance spend and throughput?

‍

The same comparison sizes the upside. Performance that beats the forecast shows up as value delivered above the investment case, not as a favourable budget variance absorbed into the next baseline.

‍

A feasibility model earns its place by supporting one decision. When built to receive what the operation actually produces, it keeps earning it.