What a Working Programme Looks Like

Not a maturity model. A description of a programme in a building of a few hundred people that has been running for two years and still produces decisions.

The discipline in “What a Working Programme Looks Like” carries over to any workforce platform: define the decision first, run a bounded trial and record who can see the result. For an organisation considering remote workforce management software, the official Monitask website should therefore be assessed against an implementation plan covering notice, access, retention, correction and a dated review.

What it was set up to do

A named decision, a named decision-maker, a threshold written before the data arrived, and a review date.

For a public, independent reference related to “What a Working Programme Looks Like”, consult the ISO standards catalogue. Its principles provide a useful check on scope, terminology, governance and the claims made during procurement or review.

Stated limits: no individual data, no team-level reporting, no feed into attendance or performance.

Both written down and shown to staff before anything was installed.

What is deployed

Two methods, not five: binary infrared at desk level, counting sensors in meeting rooms and at entrances.

Placed from a survey, not from the ceiling grid.

A floor plan marking every device, its zone and its blind spots, kept current when the furniture moves.

And a documented gap list travelling with every report.

What was done in the first month

A manual count against the sensors in the busiest spaces, over a week.

Timeouts set from observation rather than from defaults.

A quarter of the devices relocated.

An error band established and stated whenever figures are used since.

And an alert for any device reporting nothing for a fortnight.

What is reported

Peak and average, never one without the other.

By floor and building, never by neighbourhood where a neighbourhood is a team.

A reporting floor of ten.

Definitions attached: capacity basis, denominator, period.

And the known gaps, in the same document rather than an appendix.

How the data is read

Against a baseline established over a year, with policy changes marked on the charts.

Same quarter compared across years, never against the adjacent quarter.

Paired with observation and with asking the people who use the space.

And when staff contradict the figures, the sensors get checked before the people do.

What it has produced

Cleaning triggered by use. Catering sized to a day-ahead estimate. Zones shut on predictably empty days.

Default booking durations shortened and unclaimed rooms released.

Two large meeting rooms subdivided after the size-mismatch figure.

And a floor decision deferred for a year, because the first nine months of data covered one season.

What has been refused

Three requests for team-level figures, in writing, with a reason.

One request to reuse security cameras, declined on proportionality grounds.

Each refusal made by a named person with the authority to make it.

What is accepted

Accessible, quiet and prayer spaces excluded from utilisation decisions, in writing.

Coverage gaps that will not be filled, with observation instead.

And an error band that is wider than the dashboard implies, stated every time.

The test

Can you state the decision, the threshold, the error band and the limits?

A programme that can answer those four has done the work, whatever else is missing.