Evaluating Drill Program Management Software

An exploration program is a moving factory. Collars have to be in the right place. Rigs have to be on the pad. Core has to get to the shed. Samples have to get to the lab. Invoices have to match the meters that were actually drilled, not the meters someone remembered on Friday.

Searchers already type "drilling management software" and "drill program management" into Google. On Mining Software those queries hit the exploration and drilling category. This article is the evaluation frame behind that page. It is not a list of winners.

Strip the brochure and the job is coordination.

Geology wants meters in the right lithology. The contractor wants to invoice. The exploration manager wants cost per meter and a sample that still has a chain of custody when the assay comes back. The software that claims to run the program has to hold those three views without a nightly export.

Typical objects: program, rig, shift, collar, meterage, core tray, sample, dispatch, invoice line. If those objects are not named in the demo, you are looking at a logging app with a calendar stuck on the side.

Core logging and sample tracking matter. They are not the whole program. A geologist can log in a notebook. The program dies when the rig move, the stand-by hours, and the lab dispatch cannot be tied to the same day.

Stand-by that nobody coded. A rig that sat because the pad was not ready, or the water truck did not show, and the daily report still went in as drilling. If the system cannot flag stand-by against a reason code the supervisor signed, you will pay for it.

Meters that do not match invoices. The contractor invoices from their own sheet. Your geologist has a different number. Town rebuilds a third. The system that cannot reconcile those three is a filing cabinet.

Broken chain of custody. A sample bag with no dispatch, a dispatch with no lab receipt, a lab receipt with no QA/QC flags. That is not a software preference. That is a JORC problem waiting for a competent person.

Offline failure. Pads do not have office wifi. If the tablet only works in camp, the pad will stay on paper, and paper will win.

Handoff into the database. Program software that cannot give a clean collar, survey, and sample file to geological data management will force someone to retype. Retyping is how collars drift.

1. Daily report is the source. Can the supervisor sign a shift report on the pad, and does that report feed invoice, meterage, and sample dispatch without a retype.

2. Contractor extras. Stand-by, moves, water, bit changes. Are they coded, approved, and visible to geology and accounts on the same day.

3. Collar to lab. Follow one sample. Collar, tray, bag, dispatch, lab, QA/QC flag, back to the hole. If the vendor skips a step in the demo, they will skip it on site.

4. Offline. What is stored on the device, how conflict is resolved, and how long a pad can run without a tower.

5. Cost per meter that a manager believes. Not a dashboard. A number that matches the signed shift reports and the invoice.

6. Codes. Lithology, alteration, structure. Can the site use its own dictionary, and can it change mid-program without corrupting old holes.

7. Export to the database and the modeller. File types, validation, and who owns the collar if the two systems disagree.

8. Who runs it in six months. Name the exploration geo and the backup. If both are consultants, the next program starts on spreadsheets.

A geological database is the system of record for earth data: collars, surveys, assays, QA/QC, audit trail, JORC and NI 43-101 defensibility. MSR already has a long piece on geological data architecture and a database category.

Drill program software is the campaign engine. It cares about rigs, contractors, and whether Tuesday's meters were real. Some products try to do both. Many sites still run two. That is fine if the handoff is a file you can defend. It is not fine if geology lives in one world and accounts live in another.

Do not buy a logger because the sales deck showed a Gantt chart. Do not buy a contractor system because it showed a pretty log. Name the job.

Work a real week in the demo. Take last campaign's worst day: a pad not ready, a wet hole, a missed lab run, a disputed stand-by. If the tool cannot hold that day without a side sheet, it will not hold the next program.

Cost per meter is where programs get honest. You want meters from the signed shift, extras from the same report, and a lab count that matches bags dispatched. If those three numbers cannot sit on one screen for one hole, you will argue in town and pay in the field.

QA/QC on samples is not optional colour. Blanks, duplicates, and standards have to ride with the dispatch. A program tool that treats QA as "the database's problem" will lose bags. A database that never sees the pad will not know the bag was wet. The handoff is the product.

Junior teams often try to run the whole campaign in Excel plus a modeller. That works until the third rig. The question is not sophistication. The question is whether two people can reconstruct Tuesday without calling the contractor's Perth office.

The other leak is time. A program that cannot show meters versus plan by week will keep drilling after the budget is gone. You want a simple burn: planned meters, drilled meters, remaining, and a date the money runs out. If that view needs a pivot table in town, the field will not see it until it is too late.

Assay turnaround sits outside the program tool and still belongs on the board. If samples sit in a shed for ten days because dispatch was not booked, the geo is flying blind and the rig is still turning. The software should make that delay visible next to meterage, not in a separate lab portal nobody opens.

Safety and land access are not geology, but they stop the rig. A system that cannot record a pad as blocked, heritage, or wet will keep sending the contractor to a place they cannot drill. That becomes stand-by you will pay for.

One more practical test: can two people reconstruct last Tuesday from the system alone. Collar, meters, stand-by reason, samples dispatched, invoice line. If they need the contractor's WhatsApp and a geo's notebook, you do not have a program of record. You have a chat log with a login. That test takes ten minutes. Do it before you talk price. If they cannot, walk.

Start at exploration and drilling. Use this checklist in the demo, not the brochure. The search queries are already there. The gap has been packaging and a missing evaluation frame, not a missing "winner." Take a real program, a real invoice, and a real sample bag. If the tool cannot hold all three, keep looking.