Skip to content
The Published Rota

All notes  /  Tools

When the Rota Is Generated

An optimiser does exactly what it is asked. What it is usually asked, what that produces, and the constraints that have to go in first.

Tools · Analysis

Automatic rota generation is not the problem. What it is told to optimise is.

What it is usually told

Minimise labour cost subject to covering forecast demand.

That is the whole objective in most default configurations.

Everything else — rest, fairness, stability, hours people need — is either a constraint someone added or absent.

What that produces

Precise matching to forecast, with no buffer, so every variance becomes a cut or a call-in.

Short shifts, because they fit demand curves better than long ones and cost less per person.

Clopenings, because nothing forbids them.

The same people on the same awkward slots, because the optimiser found that arrangement cheapest and has no reason to vary it.

Week-to-week variation, because last week's pattern is not in the objective.

None of this is a malfunction. It is the answer to the question asked.

The constraints that go in first

Minimum rest, hard.

Minor employment limits, hard.

Capability requirements, hard.

Maximum hours including the averaging period, hard.

Contracted minimum hours, hard.

Then, and only then, optimise within what remains.

Adding stability to the objective

Most products can weight it if asked; few do by default.

Options: penalise deviation from the person's usual pattern, penalise week-to-week variance, require a minimum number of identical shifts.

Ask the vendor whether this is possible at all, because the answer sorts the market quickly.

And measure the result: schedule variability per person, before and after.

The accountability problem

"The system generated it" is not an answer to someone asking why they have four different patterns in a month.

A person is accountable for the rota regardless of what produced it, and that person needs to be able to explain and override it.

Which means the override has to be easy, and the fact that it was used should be unremarkable rather than an exception report.

Reviewing what it produces

Before publication, every time, by a person who knows the team.

Looking for: the same names on the same awkward slots, patterns that changed without reason, shifts that are technically legal and practically unworkable.

Ten minutes.

An unreviewed generated rota will contain something nobody would have chosen, and publishing it teaches the team that nobody looked.

Review before publishing

Ten minutes, every time, by someone who knows the team.

Looking for the same names on the same awkward slots, patterns that changed for no reason, and shifts that are legal and unworkable.

An unreviewed generated rota will contain something nobody would have chosen.

Publishing it teaches the team that nobody looked, which is the more expensive outcome.

Reproduce the workflow

For another way to make this requirement testable, review stealth monitoring software. Treat it as a starting point, then reproduce the case with real roles, sites and exceptions.

Independent reference

For a thematic point of reference, see the National Institute of Standards and Technology. This widely used specialist site offers a useful second reference for the issue.