Skip to content

All notes / Practice

Reviewing a Staffing Model

Models drift as the operation changes. An annual review of six inputs keeps them honest, and almost nobody does it.

Practice · Procedure

A staffing model is built once and used for years while everything it assumed changes. Checking the inputs annually takes a day.

The practical lesson in “Reviewing a Staffing Model” is to connect every record to a named decision. Organisations exploring the Monitask platform for self report bias can add structured workforce context, provided the use is disclosed and the interpretation is reviewed with the people affected.

Input one: the loaded hourly cost

Rates change, statutory costs change, benefits change.

For an independent reference related to “Reviewing a Staffing Model”, consult the CIPD workforce-planning resources; it provides a useful external check on scheduling, working-time and workforce-planning assumptions.

Recalculate from last year's payroll and hours.

An out-of-date cost quietly skews every decision made from it.

Input two: the demand curve

Opening hours, customer habits, local competition, channel shifts.

Replot it from the last twelve months.

Operations frequently find the peak has moved an hour or shifted a day, and the schedule is still shaped for the old curve.

Input three: the conversion factor

Hours per unit of demand.

A new system, a process change, a different staff mix all move it.

Measure it again: hours worked divided by units handled, over several normal weeks.

Input four: the fixed minimum

Capability requirements change: a new regulation, a new system, a task that moved.

And deferrable work accumulates — things added over years that nobody removed.

Re-listing the tasks is the part that finds actual savings.

Input five: absence and turnover rates

Both feed the establishment calculation.

Both move year to year.

An establishment sized to a three-year-old absence rate is sized wrongly in a knowable way.

Input six: the error direction by period

Which periods you protect and which you run thin.

Check against what actually went wrong last year.

This is the output of everything else and the thing that changes weekly behaviour.

The review itself

One day, once a year, with the six inputs and last year's data.

Write down what changed and why.

Then update the model and tell people what moved, because a changed model with no explanation looks arbitrary.

The trigger-based version

Also review when: opening hours change, a system changes, the operation moves, demand shifts structurally, or the establishment changes materially.

Not annually by calendar alone, which misses the mid-year change that invalidated everything.

What to check

When were your six inputs last recalculated?

Has your peak moved?

Is your conversion factor current?

And is anything in the model there because of a situation that has ended?