Build a Small Workforce Roster Model

A small roster makes an excellent optimization model because every assignment and every conflict can be inspected. Someone must cover Monday morning, someone else Tuesday evening, and so on. Yet the decisions are connected. A person can be qualified for a role but unavailable at a particular time. A schedule can meet coverage rules while placing nearly every inconvenient shift on the same employee.

A small model is a useful way to understand these relationships without building a complete application. We will schedule four employees across four shifts, starting with hard rules and adding a preference. The example is deliberately small enough to inspect by hand.

Define the decision

Let the employees be Ada, Ben, Cora and Dev. There are four shifts, numbered 1 through 4, and each shift needs exactly one employee. Define a binary decision x[e,s] that equals 1 when employee e works shift s and 0 otherwise.

That is valuable information rather than a reason to silently ignore availability.

The first hard rule is coverage: for every shift, exactly one employee must be assigned. The second is workload: in this toy example, each employee works exactly one of the four shifts. Together, those two rules make every feasible assignment a one-to-one matching between people and shifts.

We also need availability. Suppose Ada cannot work shift 4, and Dev cannot work shift 1. The model prohibits those two assignments. If a required shift had no available staff, no feasible roster would exist under these rules. That is valuable information rather than a reason to silently ignore availability.

Add a modest preference

Suppose each employee has a preference penalty for each shift. Smaller numbers mean more desirable assignments, and an unavailable assignment is forbidden rather than merely given a large penalty. The illustrative penalty matrix is:

An objective is to minimize the sum of penalties for assigned shifts. Notice how availability and preference are handled differently. A low preference does not make an unavailable shift acceptable.

Enumerate a tiny model in Python

For four employees, there are only 24 possible one-to-one assignments, so an exhaustive check is practical. This is a demonstration of the model, not a scalable production technique.

Each person receives their lowest-scored shift, so no feasible schedule can improve the total further.

from itertools import permutations

people = ("Ada", "Ben", "Cora", "Dev")
penalty = {
    "Ada": (1, 3, 2, None),
    "Ben": (2, 1, 3, 2),
    "Cora": (3, 2, 1, 2),
    "Dev": (None, 3, 2, 1),
}

best = None
for assignment in permutations(range(4)):
    costs = [penalty[p][s] for p, s in zip(people, assignment)]
    if any(c is None for c in costs):
        continue
    score = sum(costs)
    if best is None or score < best[0]:
        best = (score, assignment)

score, chosen = best
print(score, [(p, s + 1) for p, s in zip(people, chosen)])

The optimal illustrative assignment is Ada to shift 1, Ben to shift 2, Cora to shift 3 and Dev to shift 4, with total penalty 4. Each person receives their lowest-scored shift, so no feasible schedule can improve the total further.

What makes the real problem harder

Real rosters have multiple people per shift, qualifications, contractual limits, rest requirements, consecutive-day restrictions and varying demand. Preferences may involve fairness over several weeks rather than isolated penalty scores. Some assignments become locked after publication, and changes may have an operational cost.

These are reasons to evolve the model carefully, not to write a giant formulation on day one. Start with coverage and nonnegotiable rules, validate small cases, then introduce preferences whose meaning can be explained to the people affected.

A useful roster is more than a complete calendar. It is an explicit agreement about what the organization must provide, what it would like to provide and how competing preferences are handled when not everyone can have their first choice.