Travel Between Sites
How travel between sites constrains a rota, why it is systematically under-planned, and the three ways a multi-site pattern goes wrong.
Planned against actual travel on one week of a four-site operation
Parking and loading were never counted.
Close enough to plan with.
Nobody had made this journey at 08:00.
Accurate.
Two jobs deferred, one taxi.
Two routes were planned from a map and were out by 13 and 26 minutes, which is most of an hour a day for the people driving them. Both errors were in the same direction, as they always are. This is one employer's own week, not a benchmark.
Travel is a physical constraint that behaves like a scheduling one. It consumes shift time, it fixes sequences, and it makes some combinations of work impossible however willing everybody is.
The physical constraint in “Travel Between Sites” needs to be recorded alongside the people schedule rather than hidden inside it. Used carefully for digital payroll timesheets, read more in this Monitask guide can provide current time and project context while the site, equipment and travel assumptions remain separately documented.
It is also the constraint most consistently under-planned, because the time it takes is known to the people doing it and estimated by the people building the rota.
For an outside reference relevant to “Travel Between Sites”, consult Safe Work Australia fatigue resources. Compare the general material with the organisation’s jurisdiction, sector and written agreements.
Where the estimate comes from
Usually from a map, at a quiet time of day, with no parking, no equipment to load, and no handover at either end.
The real number includes all four and it is routinely half as long again as the planned one. A rota built on the map number produces a day that does not fit, every day, and the difference is absorbed by the person driving.
Getting the real number
Ask the people who make the journey, take the median of what they say, and sanity-check it against vehicle data if it exists.
- Ask the people who make the journey what it actually takes, door to door.
- Take the median rather than the best case.
- Add loading, parking and any handover at either end.
- Check it against vehicle data where that exists.
This takes an afternoon for a whole operation and is the single most valuable input to a multi-site rota. Nothing else in the pattern can be right if this number is wrong.
The three ways a multi-site pattern goes wrong
The first is the day that does not fit: planned travel is shorter than real travel and every day overruns slightly.
The second is the impossible combination: two sites assigned to one person on one day when the journey makes it infeasible. The third is the sequence problem, where the work is possible but only in one order, and the rota does not record which.
Travel at the ends of the day
The first and last journeys are different from the ones in between, because they interact with the start and end of the shift and with whatever the contract says about commuting.
Whether travel to the first job counts as working time differs by jurisdiction and by contract and is a question for somebody qualified in the place concerned. What the rota can do is be explicit about which journeys it is treating as which.
The sequence constraint
Where a route only works in one order, that order is a constraint and should be in the rota rather than in the head of the person who worked it out.
Routes get rebuilt every time somebody new does the planning, and the knowledge about which order works is usually lost each time. Writing it once saves it being rediscovered by failure.
Clustering, which is the main lever
Assigning people to geographic clusters rather than to whatever work arrives reduces travel more than any other change, and it conflicts with flexibility and with fairness.
Clusters mean the same people serve the same places, which is good for continuity and bad for cover. Both effects are real and the choice should be made knowingly rather than falling out of the dispatch method.
Vehicles, which travel with the problem
A multi-site pattern is usually also a vehicle allocation problem, and the vehicle constraint is often tighter than the travel one.
Counting vehicles against simultaneous journeys, by hour, for a typical week finds the pinch points immediately and usually explains a pattern nobody could account for.
Travel as a named block
Travel as a named block rather than as a gap. A shift that contains ninety minutes of travel should show ninety minutes of travel, in the pattern, visible to whoever is assigning work.
Where travel is invisible, it is assumed to be slack, and the slack gets filled with work that then does not get done.
Travel that is really a handover problem
A journey between sites frequently carries an information transfer with it: somebody drives over to say something that could have been written.
Where that is happening, the constraint is not travel; it is a handover arrangement wearing travel's clothes, and the fix belongs in the handover section rather than in the route.
What it costs to get this wrong by ten minutes
Ten minutes per journey, three journeys a day, across six people, is three hours a day of planned work that does not happen.
That is the scale of the error introduced by estimating travel from a map, and it is why the afternoon spent collecting real numbers is the best-value hour in a multi-site operation.
The matrix worth keeping
Between each pair of sites: the real journey time, the time of day it was measured, whether a vehicle is required, and the date.
Four fields and a small matrix. It is the most useful single page a multi-site operation can hold, and almost none of them do.