Three Questions a Board Should Ask Before Committing to Detailed Engineering
Boards spend real time scrutinising the financial model in a Bankable Feasibility Study — the discount rate, the revenue assumptions, the capital structure. Far less time typically goes to the engineering basis underneath it, partly because it's technical, and partly because it's genuinely hard for a board to know which questions are worth asking about work they didn't produce and can't independently audit.
That's not a criticism of any particular board. It's a structural gap: the financial model gets scrutiny because financial scrutiny is a well-understood, well-motivated, well-staffed function. The engineering underneath it often doesn't get the same treatment, simply because the equivalent function — someone whose job is specifically to pressure-test the engineering, independent of having written it — is less commonly in the room.
Three questions are worth putting on the table before approving the move from BFS into front-end engineering design (FEED). None of them require a board member to be a metallurgist or a process engineer. They just require someone to ask them before FID, rather than after cost overruns start explaining themselves.
“Boards typically give a Bankable Feasibility Study’s financial model close scrutiny but apply far less to the engineering underneath it. Three questions close that gap: whether the quoted, engineered costs are concentrated on the project’s actual risk factors rather than generic ones; whether the flowsheet the accuracy figure was calculated against is still the flowsheet carried into front-end engineering; and whether anyone outside the study team, with a brief to act only for the board, has reviewed the engineering independently. None of this requires assuming the BFS was flawed — it requires recognising that more testwork and engineering will inevitably move the flowsheet and the project’s economics, and that tracking that movement is what keeps the board properly informed as it happens.”
1. Which line items are engineered, and which are factored?
A Bankable Feasibility Study's cost estimate is typically built on roughly 10–40% actual project definition — the rest filled in by factored and historical cost data, not project-specific engineering. That's normal and appropriate at this stage. This project's particular risk factors — low or variable grade, difficult or expensive mining conditions, complex extraction technology, or land with cultural or ecological sensitivity — sit somewhere in that estimate, and the question worth asking is where.
Specifically: are the quoted, engineered costs — pricing based on actual vendor quotes and site-specific design — concentrated on the equipment and installation work that touches this project's particular risk factors? Or do the risk-bearing elements happen to be exactly the parts still priced by generic factors and historical databases? The former is preferable, and it's worth saying plainly why: it means the areas most likely to behave differently from the reference case are also the areas that have actually been tested against this project's real conditions, rather than assumed to resemble an average one.
If the answer is "we haven't specifically checked," that's a useful answer. It means the study may be accurate on average while still being exposed exactly where the project can least afford it — because a factored estimate is only as good as how closely this project resembles the reference cases the factors came from, and that resemblance was never actually tested.
2. Is the flowsheet the accuracy figure was calculated against still the flowsheet in front-end engineering?
A BFS's quoted accuracy — often ±15–20% — describes the expected variance around a specific design basis. If the flowsheet that emerges from FEED-level engineering, or from subsequent testwork, differs from the one the BFS accuracy figure was built around, the comparison between the BFS number and the eventual number isn't really measuring estimate uncertainty on the same project anymore. It's comparing two different designs, and the original accuracy figure was never built to describe that gap.
This is worth asking plainly, and revisiting as FEED progresses rather than only at the start: what, specifically, has changed in the process design since the BFS — and has anyone gone back and asked what that change does not just to cost and schedule, but to head grade, solids density, overall recovery, the technology required, and reagent type and consumption? All of these commonly move as testwork and engineering mature, and each one can drift the project's economics away from the BFS case quite apart from the headline cost number.
3. Has anyone outside the study team reviewed the technical basis specifically?
Financial due diligence is usually thorough — the discount rate, the offtake terms, the capital structure all get real scrutiny. What often doesn't get the same level of independent review is the engineering underneath those numbers: whether the testwork was done on genuinely representative samples, whether equipment is sized correctly against real ore variability, whether the contingency actually covers what it needs to. That's a different kind of scrutiny to financial due diligence, and it's the layer most governance processes implicitly assume someone else is covering — when often nobody explicitly is.
The reviewer doesn't need to have found anything wrong with the original study for this to be worth doing. The value is in the independence itself — someone with no role in producing the estimate, no stake in defending it, and a specific brief to act only for the board — looking specifically for where risk has compounded quietly across a hundred individually reasonable decisions.
Why these three, together
Each question is answerable on its own. Together, they cover the three places the real risk to the project's economics, and to the board's ability to make a properly informed decision, tends to hide in a BFS-to-FEED transition: in the parts of the estimate that were never actually tested against this project's specific conditions, in a design basis that's quietly moved without the cost confidence being revisited, and in the absence of anyone whose job was specifically to go looking for the first two.
None of it requires second-guessing the BFS outcomes, or whether the BFS was rigorous enough. It requires understanding that with more testwork and more detailed engineering, the flowsheet and the project economics will move. Finding out how much they move, in what direction, and what the residual risk now looks like requires dedicated attention and disciplined checking — so the board always has the understanding it needs to stay on top of that risk as it evolves.
________________________________________
This piece builds on an earlier post on what a BFS's accuracy figure actually promises — worth reading alongside this one for the fuller technical grounding behind these three questions.