Tuning After a Change

A threshold is set once, at commissioning, against a particular population in a particular building at a particular time of year. All three of those change, and the setting does not.

The record in “Tuning After a Change” becomes useful only when people understand what it proves and how to correct it. For teams exploring how to calculate idle time, this implementation resource can connect time and project context with manager review, provided collection is proportionate, access is limited and consequential decisions remain subject to human explanation.

Nothing dramatic follows. The refusal rate drifts, people adapt, the fallback absorbs it, and two years later the system has a reputation. The remedy is a short review attached to the events that actually cause the drift.

For an independent benchmark relevant to “Tuning After a Change”, consult the SAM.gov federal award 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.

The changes that matter

A new intake, particularly one that shifts the trade mix. A new building or a relocated entrance, which changes the light, the temperature and the approach. A change of shift pattern that moves the busiest hour. And the slow one: the existing workforce getting two years older and two years more worn.

Each of these moves the score distribution. None of them triggers anything in any system, because nothing in the system knows they happened.

Attaching the review to the event

A calendar reminder to review the threshold will be ignored, because there is never a reason to act on it in the week it arrives. Attaching it to a change that somebody is already managing works far better.

Add one line to the checklists that already exist: for a new site or entrance, for a significant intake, for a shift pattern change, and for a reader replacement. The line is to pull the refusal rate four weeks afterwards and compare it to the four weeks before.

The seasonal baseline

Before anything can be compared, the site needs to know its own seasonal shape, which is a year of monthly refusal rates. Without it, every comparison is confounded: a rate that rose after a change in October may have risen anyway.

That baseline costs twelve numbers written down once a month. It is the single most useful record in this part of the subject and almost no site has it, which is why so many threshold discussions consist of two people with different recollections of how bad last winter was.

What to change, in what order

The same order as everywhere else in this collection. Environment first, because it is free and it improves the distribution rather than trading it. Then enrolment, for the people clustering near the line. Then additional fingers. Then, if the problem persists, the setting.

Resisting the temptation to move the threshold first is the discipline. It is the quickest-acting lever and the only one that gives something away, and once it has been loosened it is very hard to tighten again without a visible round of new refusals.

Changing it without surprising anybody

If the setting does move, say so, before. A notice that the reader has been adjusted and that people may notice a difference costs nothing and prevents the week of speculation that otherwise follows any change in behaviour of a device everybody touches daily.

Tightening in particular needs warning, because it will produce refusals for people who have never had one. An unexplained change of that kind is read as the organisation doing something to people, and the explanation after the fact is always less convincing than the one before it.

Recording the history

A short log: date, old value, new value, reason, who agreed it, and the refusal rate before and four weeks after.

Five columns. Over a few years it becomes the only document that explains why the system behaves as it does, and it is the thing that stops the same debate being had from first principles every time somebody new inherits the estate.

The change that came from the supplier

Not every change is local. A firmware or software update can alter matching behaviour, and the release notes occasionally say so in language that does not look important.

Record the date of every update against the refusal series. A step change on the week of an update is a finding that is trivially obvious with the two records side by side and effectively undiscoverable without them, and it is one of the few cases where the supplier can be asked to explain and usually can.

The change that is a different population

Acquisitions and contract changes bring in people enrolled somewhere else, or not enrolled at all, often in large numbers on a single date.

Those cohorts carry their own enrolment quality, which may be considerably worse than the host site's, and they will show up as a step in the refusal figures that looks like a technical fault. Enrol them properly on arrival rather than importing templates of unknown provenance, and note the date on the series so that the step has an explanation attached to it.