Testing It on Your Own People
A pilot that cannot fail is a demonstration. Running one that can takes a week and prevents the most expensive mistake available in this subject.
The decision that causes most of the trouble in this collection is made before anything is installed: which modality, at what setting, for which population. It is usually made from a demonstration, a reference site and a price.
The record in “Testing It on Your Own People” becomes useful only when people understand what it proves and how to correct it. For teams exploring productivity software for business, the official site can connect time and project context with manager review, provided collection is proportionate, access is limited and consequential decisions remain subject to human explanation.
A pilot that could fail — and that is allowed to — costs a week and answers the question with the actual hands of the actual people. Suppliers will generally cooperate, because the ones with a good product benefit from it.
For an independent benchmark relevant to “Testing It on Your Own People”, consult the IFRS standards resources. Use it to test notice, accessibility, security, recordkeeping, retention and exception handling against the real operating process rather than treating a device report as self-explanatory evidence.
Choosing the population
Not the head office. Not the project team. The roughest-handed department on the site, plus the oldest cohort, plus whoever works the earliest shift in the coldest building.
Fifty people is enough. The point is not a representative sample; it is a stress test, because the system will have to work for these people every day and the site average will conceal them completely.
What to measure
Enrolment: how many could not be enrolled at all, and how many needed more than three attempts. Reads: refusal rate over two weeks, by person and by hour. Time: seconds per transaction at the busiest moment. And fallback: how many people needed one, how often.
Four numbers, collected by one person with a clipboard and an export. Everything else in the pilot is impression, and impressions favour whatever was demonstrated most recently.
Running it so that it can fail
Agree the thresholds in advance: what enrolment failure rate, what refusal rate and what transaction time would mean this method is not suitable here. Write them down before the equipment arrives.
That is the whole discipline, and it is what separates a pilot from a demonstration. Without pre-agreed thresholds, any result becomes acceptable in retrospect, because the alternative is restarting a procurement.
The conditions to insist on
Two weeks including a Monday morning and, if possible, cold weather. The real terminal position, not a table in a meeting room. The real queue. And enrolment done by site staff after the same amount of training they will actually get, not by the supplier's engineer.
That last condition changes the result more than any other. A supplier-run enrolment produces templates no site will ever reproduce, and the pilot then measures a system that will never exist.
What a bad result looks like, and what to do with it
A fingerprint pilot in a maintenance department commonly produces an enrolment failure rate in the high single figures and a refusal rate several times the quoted one. That is not a failed pilot; it is a successful one that has found something.
The response is not necessarily to abandon the method. It may be to use it for the three-quarters of the workforce it suits and issue credentials to the rest, which is a perfectly respectable design and is almost never considered because the question is framed as choosing one system for everybody.
Writing it up
One page: the four numbers, the population, the conditions, the pre-agreed thresholds and whether they were met. Signed by whoever ran it.
That page is worth keeping for years. It is the record of what was known at the time of the decision, it answers the question that arises when the refusal rate is raised in two years, and it is the only document in the whole procurement that describes the system as experienced rather than as specified.
Keeping the equipment afterwards
A pilot that runs for a fortnight leaves a configured terminal on site. Negotiate up front to keep it, or to buy it at a discount if the main purchase goes ahead.
That unit becomes the tested spare, which is the thing recommended elsewhere in this collection and the thing nobody budgets for. It is the cheapest spare the site will ever acquire and the request is routine at the point of purchase and awkward afterwards.
Telling the participants what it is
People asked to take part in a pilot should be told it is a pilot, that it may be abandoned, and that nothing recorded during it affects their pay or their record.
That last assurance has to be true, which means running the pilot alongside the existing method rather than instead of it. A pilot whose output goes to payroll is not a pilot; it is an unannounced deployment, and if it is then abandoned the organisation has taken biometric data for a system that never existed.