The clipboard came back

The system went live on a Tuesday, on schedule, and for the rest of that week it worked exactly as promised.

The shift supervisor logged every quality hold on the screen instead of the clipboard. The engineers who had built it were still on the floor, walking past twice a shift to see how it was going.

Three weeks later the plant head walked the same floor at the end of a night shift and found the clipboard back on its hook by the line, half a page filled in pencil.

The screen was still there. Nobody had switched it off. The supervisor filled it in too, for the record, in a quiet ten minutes before the shift handover — after the hold had already been called the old way, over the radio, same as always.

Nothing had broken. The project had already been marked delivered in the monthly report, two weeks before anyone noticed which log the floor actually trusted.

Why we build it this way

A new system is not software that gets installed once and then simply exists. It replaces a habit — a specific thing a specific person used to do, at a specific moment, from memory or a clipboard or a radio call. A habit has an owner and a moment it happens, and it does not change just because a screen was switched on next to it.

The common approach treats the rollout the way any IT project gets treated: a training day, a manual, a go-live date, a support number to call if something breaks. That gets you a working system. It says nothing about whether the person on the floor at two in the morning, alone, under nobody's eye, reaches for the new way or the old one — and the old way is one radio call faster.

Training once covers the two days people are being watched doing it. It says nothing about the third week, when the novelty has worn off and the habit has either held or quietly reverted, and by then the people who could tell the difference have usually moved to the next site.

So we treat it as a change to how a decision gets made, not as a delivery of software. That means naming the exact habit it replaces before anything is built, naming the one person accountable for whether the new habit sticks, and staying on the floor long enough to watch it survive its own first month — not leaving the week it goes live.

How it works, roughly

Before anything is built, we write down, specifically:

• Which existing habit this changes, who does it today, and how
• What stays with that person afterward, and what changes about how they do it
• What we will check in week three and week eight, not just whether the system is still running

Your people use the system while we are still there — not a demo, the actual shift, on the actual floor, while we can still change what is wrong with it. That is where a habit either sticks or quietly reverts, which is why we stay through it instead of handing over at go-live and finding out later.

When someone disagrees with what the system says, that disagreement is written down as a decision, with their name against it — not waved off, and not silently overridden by going back to the old way. That record is what shows, months later, whether the new habit is the one actually running the floor.

We leave with runbooks, the name of who owns what, and the record of what was decided and by whom — not a training deck and a hope.