Putting a System In

A scheduling product inherits whatever data you give it. Most implementations fail on that rather than on the software.

What has to be right first

Availability, current and split into hard constraints and preferences.

Contracted hours per person, including minimums where they exist.

Capability matrix with expiry dates.

Shift requirements per site: headcount by day part, plus capabilities.

Rest rules, minor limits and any local ordinance that applies.

Configured before the first rota is built, because a product fed stale data produces the same bad rota faster.

The order

One: fix the data above.

Two: configure constraints as hard checks.

Three: build one week manually in the product, at your hardest site.

Four: compare it against what you would have produced.

Five: run a month in parallel with the existing method, comparing outputs rather than totals.

Six: cut over at a quiet point, not before a peak.

The parallel month

Build in both, publish from the old one.

Compare: notice achievable, constraint breaches caught, time taken, and whether the output is workable.

Ask the managers which they would rather use, which is the answer that determines adoption.

A parallel month that produces no differences means the product is adding speed rather than quality, which is still worth something and is a different justification.

Telling people

What changes for them: where the rota appears, how to set availability, how to request a swap.

What does not: who decides, the allocation rule, the notice period.

That the constraints are now enforced, which is a benefit to them and worth framing as one.

And how to see their own hours against what they asked for.

What to watch in the first quarter

Notice achieved, which should improve.

Constraint breaches, which should go to zero and stay there.

Build time, which should fall.

Employer-initiated changes, which should fall if the buffer is configured.

If none of these moves, the deployment has replaced a spreadsheet with a subscription — a finding worth having before renewal.

Keeping it honest

Check what a vendor release changed, particularly to defaults and to the optimiser's objective.

Re-run the constraint checks after any upgrade.

And review the generated output monthly, because drift in a solver is invisible until someone reads the rota.

Do not cut over before a peak

The timing error that turns a deployment into a crisis.

A new system produces mistakes in its first month, reliably.

A peak produces mistakes anyway.

Together they produce a month nobody recovers confidence from.

Cut over at the quietest point in the year, which means planning the implementation around the trading calendar rather than the project one.

Reproduce the workflow

For another way to make this requirement testable, review staffing agency time tracking 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 Cyber Security Centre. This widely used specialist site offers a useful second reference for the issue.