MSHA Compliance Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the workplace examination scope get underestimated so often?

Almost every quote for MSHA compliance software prices the examination as a form, estimates it at two or three weeks and moves on. Then design starts and the real object appears. The examination is not per site, it is per working place, which means somebody has to maintain a register of what counts as a working place and which of them were actually worked that shift. It runs at least once each shift under 30 CFR Parts 56 and 57, so the completeness question is per shift per place, not per day. The record has to name the adverse condition and the corrective action, so those are two linked objects with independent lifecycles rather than one narrative field. And the unit of aggregation across everything is the mine ID, not the plant, not the region, not the business unit.

The scope failure is specific to mining because MSHA structures its enforcement around mine IDs and shift level examinations in a way that no general safety product assumes. A developer coming from an occupational health and safety background will build a periodic inspection, which is a different shape entirely. The fix is cheap if you do it before design: write down your working place register, per site, and hand it to the developer as a deliverable. Then make the acceptance test operational rather than functional. Produce every examination record for one plant for the last six months, with corrective action status attached, in under two minutes. If the build cannot do that, it is not finished, whatever the feature list says.

What goes wrong when you migrate paper exam books and training certificates?

Migration is where these projects quietly lose a month. The training file at a mining group is not a database, it is filing cabinets of scanned certificates, a spreadsheet at corporate that tracks refresher dates for permanent staff only, and a folder per contractor firm that may or may not be current. The same person appears three times: once as a name typed by a site clerk, once as a payroll record, once as a contractor roster line with a middle initial. Nobody has a person identifier that survives across all three, so a naive migration produces a training register full of duplicates, and duplicates in a currency check mean somebody shows compliant when they are not.

The second trap is migrating too much. Historic examination books should be preserved as scanned images indexed by mine ID and date, not parsed into structured rows. Nothing operational depends on a 2019 exam being queryable, and the transcription cost is enormous.

The approach that works: build a person registry first and run a deliberate reconciliation pass with your site clerks in the room, because they are the only people who know that D. Reyes on the crusher roster and Danilo Reyes in payroll are the same man. Then migrate only two things live, current training currency per person per mine ID, and open citations with their abatement dates. Everything else is an image archive. That sequencing turns a six week migration into a two week one and removes the class of error that matters.

Why do human resources (HR) and contractor onboarding integrations break after launch?

The integration everyone builds is a nightly feed from the human resources or payroll system so the roster does not have to be maintained twice. It works in testing and starts drifting within a month, for a reason that is structural rather than technical. Your human resources system knows employment status. It does not reliably know which mine ID a person is assigned to this week, because assignments move by verbal instruction from a superintendent and get reflected in payroll only when a cost code changes. So the feed keeps the roster current and the assignment stale, and assignment is the thing your training currency check depends on.

Contractors compound it because they are not in the human resources system at all. A crew arriving Monday exists in an email from the contractor firm and in whatever the gate clerk typed, and when its composition changes midweek, nothing updates.

The fix is to stop pretending assignment is an integration problem. Treat assignment to a mine ID as data owned by the compliance system, entered by whoever actually knows it, and use the human resources feed only for identity and employment status. Then run a nightly reconciliation that produces an exception queue rather than a silent overwrite: people active in payroll with no mine ID assignment, people assigned to a mine ID who have left, contractor records with no current training verification. Give that queue a named owner. A reconciliation with no owner is a report nobody reads.

What happens when Part 50 reporting and contractor verification are not covered?

These two get pushed to phase two more often than anything else, on the reasonable argument that examinations and training are the daily volume. What actually happens is that both revert to the spreadsheet they were supposed to replace, and the spreadsheet now competes with a live system, so the group runs two records of truth for the parts that carry the sharpest deadlines.

Part 50 is a timing obligation more than a paperwork one. Certain accidents require immediate notification, injury reports run to a defined period, and quarterly employment and production data files per mine ID. When an incident is recorded in the new system but the reporting decision lives in a spreadsheet at corporate, the classification step is where the delay enters, and late or inconsistent filing is exactly what shows up when your record is looked at as a whole rather than day by day.

Contractor verification is the other one. If the gate check stays manual after the system goes live, you have a training currency engine that covers your own people and not the crew most likely to be unfamiliar with your site.

Neither needs the full workflow in phase one. What phase one needs is small: an incident capture with a classification step that puts a named person and a deadline on the record, and a contractor training status that is verifiable at the gate from a phone. Build those two thin slices with the first release. The complete Part 50 form workflow and contractor onboarding portal can wait, but the clocks cannot sit outside the system.

Should you build custom or configure what you already own?

Configure, and we will say this before quoting. If you run one or two mine IDs, a single commodity, and one training regime, a disciplined paper examination book plus a spreadsheet of training expiries genuinely satisfies the requirements, and the money belongs in guarding and training. There is no version of a custom build that beats that at that size.

If you already own VelocityEHS or Intelex, configure them first and mean it. Both have capable inspection and training modules and both will handle a group that has one dominant site pattern. Bring in the vendor's professional services, build the mining forms properly with per shift cadence and linked corrective actions, and give it two quarters. A large share of the groups who call us about a custom build have configured neither product seriously, they have configured it half way, kept a shadow spreadsheet for the awkward parts, and concluded the product failed. Predictive Solutions is worth buying if what you want is observation based leading indicator data, which it does well, but do not buy it as a compliance record system because that is not what it is.

The honest build threshold is around eight or more mine IDs, or fewer if your sites genuinely differ, if your exam records are paper and you have already had an inspection where producing them was the problem, or if the aggregation your corporate safety director needs cannot come out of the product you own without a quarterly spreadsheet exercise.

How do hidden costs get into the quote?

Five things, and they are consistent enough to check for by name. First, offline capability. Every quote says the app works offline, and the difference between caching a form and correctly reconciling a week of queued exams from four devices in a pit with no signal is weeks of work. Ask what happens when two examiners sync conflicting records for the same working place.

Second, mine ID count versus site count. Groups quote their site count, but a plant and a pit can hold separate identifiers, and every one is a separate compliance universe.

Third, standardising the examination form across plants. This is not software work at all, it is change management, and it usually takes longer than the build. Every plant manager believes their form is right.

Fourth, regulatory configuration. Training hour requirements and forms move, so they belong in configuration with effective dates. Hard coding is cheaper this quarter and a release every time a rule shifts.

Fifth, supervisor training. The system is only worth anything if foremen use it every shift, and budgeting nothing for that is the most common way a good build fails.

What separates a build that works from one that fails here?

Daily use by the people at the sharp end. A compliance system that supervisors use once a week to satisfy corporate will be filled in badly, in batches, and a record that looks batch entered undermines the whole file. That is why the sequencing advice is always the same: ship workplace examinations at every site and nothing else, get the daily habit, then add the rest on top of a system people already open.

The second separator is where the rules live. If training hours, thresholds and form layouts sit in configuration with effective dates, your compliance manager can absorb a regulatory change in an afternoon. If they sit in code, you are dependent on a developer's availability for something your regulator does not consider optional.

The third is ownership. You should hold the repository, the cloud accounts and the right to hire anyone else to continue the work, agreed in writing before kickoff. At Digital Heroes the code is yours from the first commit. This matters more here than in most categories because these records have long retention obligations and may be examined in a proceeding years after the developer relationship has ended.

The last one is measurement. Pick two numbers before the build starts and track them from week one: examination completion by site and shift, and open corrective actions by age. If those are moving in the right direction six months after launch, the build worked.