Why Unit4 payroll defects survive go-live

Parallel running is the strongest evidence a payroll implementation can produce, and it proves less than most project boards assume.

A parallel run compares the new system’s output against the legacy calculation, pay group by pay group, for a real period and a real population. What it proves is precise and narrow: parity for the employees who were in that run, for the pay and deduction elements that were active in that period, and for the statutory events that happened to fall inside the window.

What it does not prove is everything outside the window. The court order that starts next quarter. The back pay that follows a pay award settled after cutover. The honorarium, the special allowance, the overpayment recovery running alongside a statutory payment. The sickness that crosses from full pay to half pay to nil pay in a period the run never reached. The year-end patch not yet applied. None of those is a testing failure. Each is a piece of the payroll that was never in scope, and if it is not written down as out of scope it will be read as proven.

That is the first reason defects survive go-live. Silence about what was not tested gets treated as evidence that it was.

Phased user acceptance testing across the full HR and payroll process set is the right structure. It runs from position administration, applicant, starter, induction and probation, through absence, occupational health, leaver and contractual change, and on to loans, deductions, pensions and court orders. Done properly it proves process coverage: every route a real case can take through the system has been walked at least once.

It does not, by itself, prove arithmetic. In practice a tester records a pass when the screen accepted the entry, the workflow routed and no error appeared. The payroll question is a different one. Did the pay and deduction element produce the right value, against the right value reference, in the right period, on the right cost? The two questions look identical on a test workbook and they are not.

The discipline that separates them is dull and effective: write the expected value before the script is run, calculated by hand or from the legacy system, then compare to the penny. Elements with conditions attached, half-pay and nil-pay transfer on long-term sickness, back pay spanning a pay award, a deduction that interacts with a statutory payment: none of these reveals itself at screen level. They show up in the comparison, and only if somebody wrote the expected answer down first.

The defect lifecycle is not complicated. Identification, triage, severity categorisation, assignment, fix verification, closure, tracked in whatever issue tracker or service desk the programme already uses. The failure is almost never in the mechanism. It is in how severity gets set.

Severity should be set by what the defect touches, in this order: a payment to an employee, a statutory submission, a deduction owed to a third party, then a report. A defect that under-pays twelve people once a year outranks a defect that annoys forty managers every week, and on a queue sorted by ticket age it will lose to it every time.

That inversion is the second reason defects survive go-live. The backlog that an organisation is still carrying two years later is rarely the set of things nobody could fix. It is the set of things that were real, were logged, were never severe enough to be scheduled against a release date, and then aged quietly into normality.

Triage also works best live and in the room. In one web migration workshop, four defects were identified, root-caused and resolved within the same session, because the people who could reproduce the behaviour and the person who could read the configuration were looking at it together rather than exchanging tickets.

A project board asked to authorise a payroll cutover is usually given a status colour. A status colour is an opinion. What the board needs is a residual-risk statement, and it has four parts: what was tested and passed, what was deliberately not tested and why, what remains open with its severity, and what compensating control covers each open item for the first live cycles.

Written that way, the decision changes character. The board is no longer being asked whether it believes the programme. It is being asked whether it accepts a named list of risks for a stated number of pay periods, which is a decision it can take and minute.

Two items belong on that list in almost every implementation. The first is the statutory calendar: year-end and statutory patches land on their own timetable, not the programme’s, and each needs its own test plan proving it before the live run. A patch applied three months after go-live is the most common source of a defect that appears to come from nowhere. The second is the population the parallel run could not reach, stated as a population rather than as an assurance.

Go-lives delivered with no critical defects outstanding are not delivered by optimism. They come from parallel payroll testing and regression validation run hard enough to find the problems while there is still time to fix them, and from a board that was told the truth about what remained.

At an international organisation, payroll, absence, expenses and timesheets were unproven, and there was no evidence base on which a go-live could be signed.

What closed that gap was not more testing in general. It was three specific artefacts: a parallel run designed and executed to compare new-system output against the legacy calculation for every pay group; a maintained defect register with resolution rates reported to the project board, so the trend was visible rather than asserted; and a test completion evidence pack that carried a quantified residual risk assessment into the go-live decision.

Parallel runs proved calculation parity across an estate of over 2,500 employees, and the decision was taken against quantified residual risk rather than an untested assumption.

Read the engagement in full on the case studies page.

Three routes, in ascending order of commitment, and none of them requires an email address to start.

• Read the worked example. The parallel run, the defect register and the evidence pack behind one go-live decision are written up as proving a payroll against an estate of over 2,500 employees.
• Run the free configuration health check. Twelve questions across the six assessment domains, scored on the page: the Unit4 configuration health check. It is the quickest way to see whether your open defects are a backlog or a symptom.
• Read the diagnostic brief. The fixed-scope engagement that turns a defect inventory into findings, remediation options and an estimate is described in full on the Unit4 X-Ray brief.