How to Evaluate Mining Software Without a Six-Month Pilot

Every vendor pitch ends the same way. "Let's run a pilot." Six months, a champion on your side, a sandbox environment, a standing fortnightly call. By month three you have spent more hours administering the trial than the software would ever save you. By month six you are in too deep to say no.

I have sat through enough of these to know what the long pilot is really for. It is not about proving the software works. It is about getting you committed. The more of your shift you sink into it, the harder it gets to walk. That is not evaluation. It is a procurement decision in slow motion, wearing a hi-vis vest and calling itself diligence.

The pit does not stop for a software trial. Grade control still has to land, the trucks still have to move, and the survey pickup is still due Monday. You do not have six months to find out whether a tool earns its place. The good news: you do not need them. You can get a clear, defensible answer in a few weeks if you run the evaluation instead of letting the vendor run it for you.

A six-month pilot feels thorough. It is mostly theatre.

First, it runs on artificial conditions. The vendor sets up a clean environment, loads tidy sample data, and walks you through the happy path. None of that survives contact with your actual site — your messy legacy exports, your half-documented naming conventions, the surveyor who codes things his own way. You are testing a showroom, not a ute that has done 200,000 kilometres on corrugated haul roads.

Second, the pilot becomes its own project. Someone on your crew gets pulled off real work to babysit it. They build workarounds, learn the quirks, and quietly become the reason it looks like it is going well. Take that person away and the whole thing falls over. You have not proven the software works. You have proven that one motivated person can make anything limp along for half a year.

Third, time is the vendor's weapon, not yours. Every week you invest is sunk cost they get to lean on. "You're already three months in." "The team's trained up now." "Switching would waste all that effort." A long runway turns your own patience into leverage against you. The honest tools do not need that. They show their value fast or they do not have it.

Before you let anyone install anything, write down the questions you are trying to answer. Be specific. "Is this software good?" is not a question. It is a feeling.

Real questions look like this. Can it ingest our block model without three days of manual cleanup? Does the haulage output match what we already know from last quarter's reconciliation? Can a shift supervisor who is not a power user actually drive it at 5am without ringing the help desk? Does it talk to the two systems it absolutely has to talk to, or does it need a custom connector someone has to maintain forever?

Five or six questions like that, written down before the demo, change the whole dynamic. They turn a vague "let's see how it goes" into a checklist with a pass or fail at the end. And they stop you getting dazzled by features you will never use. Most mining software is sold on the long tail of capabilities. You will live or die on the three or four things you do every single shift. Evaluate those. Ignore the rest until they matter.

This is the single biggest lever you have, and most buyers skip it.

A demo on the vendor's sample data tells you nothing except that their sample data works. Of course it does. They built it. The question that matters is whether the tool survives your data — the gaps, the bad surveys, the units someone entered wrong in 2019, the drillhole that goes to the centre of the earth because of a typo.

So hand them a real, anonymised slice of your own. A genuine block model. A week of actual dispatch logs. A grade control dataset with the warts left in. Then watch what happens. Does the import choke? Do the numbers come out close to what you already know is true? When it hits a record it does not like, does it flag it clearly or silently swallow it and hand you a clean-looking answer that is quietly wrong?

That last one is the dangerous failure. Software that breaks loudly is annoying. Software that produces a confident, wrong number is how you end up explaining a reconciliation gap to the GM. Feed it your mess on purpose and see how it behaves when the inputs are not perfect, because on your site they never will be.

If a vendor will not let you run the tool on your own data during evaluation, that is your answer. You do not need the other five months.

Before you start, define your kill criteria. These are the specific, non-negotiable failures that end the evaluation on the spot, no matter how much you like the rep.

Put them in writing and share them with the vendor. For example: if it cannot import our model format without manual rework, we stop. If the haulage figures are more than a set percentage off our known reconciliation, we stop. If it needs a full-time administrator we do not have, we stop. If it cannot export our data back out in a usable format, we stop — because anything you cannot leave, you do not own.

Kill criteria do two things. They protect you from sunk-cost creep, because the decision was made when you were thinking clearly, not three months in when you are emotionally invested and the rep has bought the crew lunch twice. And they smoke out weak tools fast. A vendor confident in their product will happily agree to clear pass-or-fail conditions. One who gets cagey and starts renegotiating the goalposts is telling you something. Listen.

You do not have to choose between a six-month pilot and signing blind. Break the commitment into stages, and make each one earn the next.

Stage one is a short, structured proof on your data against your written questions. A week or two, tightly scoped. Stage two, only if stage one passes, is a limited live trial on one bench, one crew, or one process — real work, real stakes, but contained. Stage three is the broader rollout, by which point you have actual evidence instead of a vendor's promise.

Each gate has its own pass-or-fail. You can stop at any one of them without having bet the production season. The vendor still gets a fair shot to prove the tool. You just stop financing an open-ended experiment and replace it with a series of small, reversible bets. If the software is good, it clears each gate and the staging costs you nothing. If it is not, you find out in week two instead of month six, and you have lost a fortnight instead of a season.

This is also how you keep negotiating leverage. A tool that has only earned stage one is not owed a three-year contract. Match the commitment to the evidence, every step.

Here is the whole thing on one page.

Week one: write your five or six real questions and your kill criteria before anyone installs anything. Pull a genuine, anonymised slice of your own data — a real model, real logs, real grade control with the mess left in. Hand it over and watch the import and the core workflow you run every shift. Not the feature tour. The daily grind.

Week two: put it in front of the people who would actually use it, not the champion who wants it to win. Ask the shift supervisor, the surveyor, the dispatcher. Check the outputs against numbers you already trust from past reconciliation. Run it against your kill criteria honestly. Then make the call: pass, fail, or move to a contained live trial on one crew.

That is a real evaluation. It is faster, it is harder to fake, and it puts you back in the driver's seat. The six-month pilot was never measuring the software. It was measuring how long it takes to wear you down. Do not give it the chance.

---

This article is general guidance, not procurement or engineering advice. Evaluate software against your own site's requirements, data, and integration constraints, and involve the people who will actually use it.

• Mine Planning & Design Software - Strategic and tactical mine planning, pit optimisation, and scheduling tools.
• Fleet Management & Dispatch Software - Real-time fleet tracking, haulage optimisation, and equipment utilisation.
• Geology & Resource Modelling Software - Geological modelling, resource estimation, and grade control software.