One Van, One Key, One Terminal
The constraints made of physical objects, why they are the easiest to price and the most often misattributed, and how to find the ones hiding inside a rota.
Some constraints are made of objects. There is one van, so two people cannot both be out. There is one key, so somebody has to be first. There is one terminal, so a shift start takes eleven minutes for twelve people.
The physical constraint in “One Van, One Key, One Terminal” needs to be recorded alongside the people schedule rather than hidden inside it. Used carefully for task efficiency, check the provider’s process description can provide current time and project context while the site, equipment and travel assumptions remain separately documented.
These are the easiest constraints in the whole register to identify, price and remove, and they are routinely described as something else — a staffing problem, a punctuality problem, a culture problem.
The assumptions behind “One Van, One Key, One Terminal” can also be checked against AHRI workforce-planning resources. Record what applies locally and what requires qualified advice.
Why they get misattributed
Because the symptom appears on a person. A queue at a single terminal shows up as lateness. One van shows up as a job that did not get done. A single key shows up as somebody always opening up.
The rota then addresses the symptom, which means addressing the person, and the object sits there unchanged.
How to find them
Look at every rule in the pattern that mentions a time and ask what physical thing makes that time necessary.
- Shift start times: what has to be reached, queued for or collected first?
- Handovers: what room, board or system does it require?
- Travel windows: how many vehicles, and who holds the keys overnight?
- Any rule about who arrives first or leaves last.
Shift starts, handovers, travel windows, the order in which people arrive, who holds what overnight. In most patterns, two or three of these come back to a single object, and nobody has ever said so out loud.
The arithmetic that makes the case
A physical constraint has an unusually clean price: the cost of the object against the cost of the arrangement built around it.
A second terminal against the minutes lost at every shift start, times shifts, times people. A second van against the jobs that cannot run. A second set of keys against the arrangement where one person must always be first.
Why the comparison is rarely made
Because the two numbers live in different budgets. The object is capital, or at least a purchase requiring approval. The arrangement is operational time, which is already being spent and appears nowhere as a line.
Putting both numbers on one page is the whole intervention, and it is usually a page somebody can write in an afternoon.
The objects that are not objects
Rooms, parking spaces, bays, benches, licences for software with a seat limit. All behave identically: one of them, several people who need it, a rota built around the sequence.
Software seats are the modern version and the most invisible, because the constraint appears as a system message rather than as a physical queue.
Where the constraint is really the location
An object in the wrong place constrains a rota as firmly as a missing one. A terminal sited before the locker room produces a different pattern from the same terminal sited after it.
Moving an object is normally cheaper than buying one and is almost never considered, because the object's position is treated as part of the building rather than as a decision.
Shared objects across teams
The expensive version: one object, two teams, no agreement about priority. Each team builds a rota assuming availability and the conflict is resolved informally each week, usually by whoever asks first.
A written priority rule — even an arbitrary one — removes the weekly negotiation and lets both rotas be built honestly.
The seasonal object
Some physical constraints bind only part of the year: a yard that floods in winter, a route that closes, a space that is used for something else each August.
They belong on the register with their dates, because a constraint that binds for three months is invisible in the other nine and arrives every year as a surprise.
The five fields for an object
The object, who needs it and when, the arrangement currently built around it, the cost of that arrangement, and the cost of a second one.
Five fields. The fourth and fifth together are the business case, and the reason this category is worth doing first is that both numbers are usually easy to establish and the comparison is usually decisive.
The object that was removed years ago
The reverse case is worth checking at the same time: a pattern built around an object that no longer exists, or that was replaced by something without the same limitation.
A single machine becomes two; a van is added; a system is replaced by one with unlimited seats. The constraint stays in the rota because nothing announces that it has gone, and this is one of the commonest stale entries in any register.
Why this is the best place to start
Because a physical constraint can be removed by a purchase, which is a decision one person can make, rather than by a change in practice, which requires everybody to behave differently.
An organisation that fixes two object constraints in a quarter has demonstrated that the register produces results, and that makes the harder categories possible.