A 15-minute adversarial roster review exercise

An ordinary roster check asks, “Does this look right?” An adversarial roster review asks, “How could a plausible-looking sheet mislead us?” You do not need a specialised tool or a real worker record. Set a timer for 15 minutes, use the invented case below and practise finding reasons not to publish yet.

This is a training exercise, not a claim that RosterField automatically detects every planted mistake. One person plays the file preparer, one the sceptical reviewer and one the release owner. If you only have two people, let the reviewer also make the final decision. Read the case before the answer key and write down what evidence would resolve each question.

The fictional case file

The planning workbook for Ridge Camp covers 7–13 October. The agreed headcount is six. The prepared CSV has columns for employment number, name, employer and daily shift codes. A recent XLSX version also exists. “D” means day, “N” means night and “R” means rostered day off according to this fictional team’s local key; nobody has agreed what “T” means. The project already has a published roster for the previous week.

The preparer hands over these notes:

1. Two rows named Jo Park appear, one for contractor Blue and one for contractor Gold. Their employment numbers differ.
2. One row for Leila Moss has a blank employment number, but her Thursday “N” appears in the planning workbook.
3. The exported CSV header says 08/10/2026 next to 09/10/2026. A coordinator reading another copy calls the first date “10 August”.
4. Marco Ives has “T” on Friday. The reviewer remembers “T” meaning travel on a different project.
5. A Saturday shift swap was agreed verbally after the CSV export. The preparer says the supervisor has the latest change in a screenshot.

None of these notes is permission to invent a shift, merge two people or assume that the screenshot is the publication source.

Spend the 15 minutes deliberately

Minutes 0–3: establish the target. Have the release owner state which project, dates, file and approval they think they are releasing. Is the CSV or the newer XLSX authoritative? Can anyone explain what changed after export? If not, record the uncertainty before inspecting rows.

Minutes 3–8: challenge identity and time. Ask the reviewer to locate all six expected people, not just count six rows. Are the two Jo Park records distinct people? Which employment numbers prove it in the source? Would a blank employment number exclude Leila from import? Compare the first, middle and last date against an unambiguous reference. A date that looks familiar is not evidence of the right month.

Minutes 8–12: challenge meaning and freshness. What does “T” mean for Ridge Camp, and who can approve that meaning? Is the Saturday swap in the selected source file? Which unchanged worker can serve as a control? If a workbook uses formulas, were the results recalculated and saved? A reviewer should ask about gaps even when the exercise notes do not mention them.

Minutes 12–15: call the decision. Say “publish”, “correct and re-review” or “hold for approval”, with a reason and named owner for each open item. Draft one sentence to tell affected workers if a later replacement is published. The timer is for finding questions, not a deadline that forces publication.

Facilitator answer key

The two Jo Park rows must not be collapsed because of a shared name; verify their separate employment numbers and intended shifts. Leila’s missing identifier needs source correction and a fresh review rather than a guessed value. The ambiguous date needs its intended day/month confirmed against the planning period and preview. “T” requires a project-specific explanation or source correction. The screenshot cannot stand in for an approved, reviewed workbook containing Saturday’s change. Even if four problems are fixed, the fifth can still justify a hold.

Ask which mistake could survive a casual glance: an unchanged row in the wrong date range may look entirely plausible. The best answer includes the evidence the team would seek, not merely a list of warnings.

Carry the habit into a real release

RosterField sits after planning: import the existing Excel CSV or XLSX, review what it represents, then publish the approved project version. A worker with the project link can search by name without an individual login; that convenience makes identity and privacy checks more important, not less. Do not use real names or expose internal notes when repeating this exercise with a team.

The day-first roster dates guide helps with ambiguous headers, and duplicate employment numbers explains a different identity failure from similar names. For a broader real-file pass, use the Excel upload checklist. A useful review ends with a defensible stop or release decision, not simply a finished timer.

Questions people ask

Can we run this exercise without using actual personnel records?

Yes. Invent every name, employment number, date and shift. The learning is in the questions reviewers ask and the evidence they seek, not access to confidential records. Keep any practice file clearly separate from the approved project source so it cannot accidentally become a release candidate.

What if the reviewer finds none of the planted mistakes?

Do not hand over the answer key immediately. Ask them to explain the project, period, expected people and source approval using evidence they can identify. Then reveal one clue and repeat the review. The debrief should identify which check was missing, not score a person’s performance.