Test shift-allocation proposals against supplied task constraints

Two machines need coverage and two people appear available. A simple “first person to first machine” rule can leave a task uncovered even when a feasible pairing exists. A small synthetic example is enough to reveal that software error.

This article tests a constrained assignment calculation. Eligibility and availability are supplied assumptions. It does not establish competence, safe staffing, employment rules or permission to work a shift.

Work through the two-person example

Assume two simultaneous operation tasks, C1 and C2, each requiring one person in this simplified model. Setup is outside the example. Each person can receive at most one assignment. The supplied eligibility table is:

If a greedy proposal assigns Beena to C1 first, Arun cannot cover C2. Only one of two tasks is covered. The feasible alternative assigns Arun to C1 and Beena to C2: two tasks covered, no person double-booked and both eligibility constraints satisfied.

Now set Beena's supplied availability to No. C2 is uncovered. The correct output reports that gap; it does not assign Arun to C2 or infer that overtime, a task change or a substitute is acceptable.

These are invented people and constraints, not a staffing recommendation. HSE's task-specific discussion of competence explains why a generic training flag should not be substituted for a supplied task-eligibility decision. HSE training and competence guidance.

Test shift-allocation proposals against supplied task constraints — reporting workflow

Follow the workflow below, or open its complete text version.

Read the complete workflow as text

1. Load supplied task eligibility and availability → Build candidate person-task pairs
2. Build candidate person-task pairs → Propose one assignment per person
3. Propose one assignment per person → Check every task and person constraint
4. Check every task and person constraint → Report uncovered tasks with reasons
5. Report uncovered tasks with reasons → Compare with a manually checked example

State the model's boundaries alongside the result

The example has no travel time, setup activity, breaks, skill levels or overlapping task intervals. A real planning model needs those constraints where applicable, supplied by the responsible owners. Omitting a constraint can make a proposal feasible only on paper.

Store the task version, availability snapshot and eligibility-source version used for each run. If a source changes, mark the proposal as based on earlier inputs. Re-running should create a new proposal reference rather than silently changing an already reviewed roster.

For each uncovered task, show whether there were no eligible candidates, no available candidates or a conflict with other assignments. These explanations help a planner investigate the input or the schedule without weakening the rules.

Compare the software with a hand-solved case

First reproduce the two-person example. Then add a third task, remove one eligibility link and introduce overlapping intervals. Verify that the algorithm never assigns the same person to simultaneous tasks and never turns an unknown eligibility value into Yes.

A worksheet can establish the expected answers. Native planning software may already support the constraints. Custom optimization is justified when the actual assignment problem cannot be represented or explained by those tools. A clever algorithm with unclear inputs is difficult to review.

The pilot deliverable is a reproducible proposal and an exception list. Actual roster approval, legal working limits, staffing sufficiency and safety remain outside the calculation. Use the result to identify where the proposed allocation and the supplied constraints disagree.