Who Runs It Afterwards

The project ends at go-live. The system then generates work every period, indefinitely, and that work is routinely unassigned.

The recurring work

Every period: close, export, reconcile, handle corrections.

Every week: new starters, leavers, role changes that the integration did not handle.

Every month: reference data hygiene, project codes opened and retired.

Every quarter: access review, data quality check.

Every year: rule changes from legislation or agreements, retention enforcement, renewal.

On demand: support questions, corrections, subject access requests, audit queries.

Totalled, this is a part-time role in a mid-sized organisation and it is usually absorbed by someone in payroll who was not asked.

What goes wrong without an owner

Rules drift out of date after a legislative change nobody applied.

Reference data accumulates, until the project list is unusable and everyone picks a catch-all.

Access is never reviewed, so people who changed role three years ago still see their old team.

Corrections pile up at period end because nobody handled them earlier.

Retention is never enforced, so the system holds ten years of records under a three-year policy.

None of these announces itself. They are found during an audit or a dispute.

Naming the owner

One person, named, with allocated time.

Not "payroll" as a department, which means nobody in particular.

With a deputy, because period close does not wait for annual leave.

With authority over configuration, or every change becomes a request to someone busier.

The runbook

Period close, step by step, including what to check and what to do when a check fails.

The export and reconciliation procedure.

How to correct after export.

How to apply a rule change, including whether it is retrospective.

Who to contact at the vendor, and what counts as severity one.

Written so that the deputy can follow it, which is the test. A runbook only its author can use is a note to self.

What to report

Corrections per period, by cause. A rising figure is a configuration problem, not carelessness.

Reconciliation differences.

Support questions by topic.

Access review result, including a clean one.

Time spent on administration, which is the number that justifies the role and which nobody tracks until the person leaves.

The runbook test

One check that tells you whether the runbook is real.

Can the deputy close a period using it, without asking the owner?

Try it once, deliberately, while the owner is available to watch rather than help.

Whatever they had to ask is a gap, and it takes minutes to fill while it is fresh.

A runbook only its author can follow is a note to self, and it fails on exactly the day it is needed.

Count the hours

The number that justifies the role and that nobody tracks.

Time spent on period close, corrections, reference data, support and access reviews.

For a month, honestly.

Annualised, it is frequently a substantial fraction of a role, absorbed by someone who was never asked.

Which is the argument for naming it, and the number to produce when the person doing it leaves and the work becomes visible by its absence.

Administration changes with workforce churn

Temporary assignments and frequent joiners make ownership visible. This operational example helps frame the cases; the trial should still test onboarding, reassignment and prompt access removal.