Go or no-go: the evidence a project board should require before a Unit4 payroll cutover

The first question a board should ask is not whether testing went well. It is what the pack contains, and whether anyone outside the programme can read it.

A test completion evidence pack carries the strategy that was agreed, the execution record phase by phase, the defect register with discovery and fix rates tracked over time, the list of what remains open at what severity, and a recommendation. Progress reporting through execution should already have been arriving on a fixed cadence, as daily or weekly dashboards showing those same discovery and fix rates, so the pack reads as the last instalment of something the board has been watching rather than a document produced in the final week.

The same discipline applies below the programme, to individual configuration changes. Every change should leave a written baseline of what was there before, a test execution record, and a post-change validation. That is what gives a change an audit trail after the consultant has left, and it is the difference between a board authorising a documented estate and a board authorising a recollection.

A useful test of a pack: hand it to someone who was not in the programme and ask them to state, from the pack alone, what was tested, what was not, and what is still broken. If they cannot, the board cannot either.

Go-live decisions should be made against quantified residual risk, not a status colour. That single substitution changes what the board is being asked to do.

A colour asks the board to decide whether it believes the programme. A quantified residual risk statement asks it to accept a named list, and that list 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 how many live cycles. A board can minute that. It cannot meaningfully minute amber.

Quantified does not mean a probability invented to look rigorous. It means stated in units the organisation recognises: how many employees fall in the untested population, how many pay periods the manual workaround has to survive, which statutory submission is affected and when it falls due. Those are numbers the programme already knows and rarely writes down.

Two items belong on almost every list. The statutory calendar, because year-end and patch releases arrive on their own timetable and interact with a fresh configuration. And the population the parallel run could not reach, stated as a population rather than as reassurance. Go-lives delivered with no critical defects outstanding come from parallel payroll testing and regression validation run hard enough to find the problems while there is still time, and from a board that was told plainly what remained.

Assurance that stops at the test report leaves the riskiest hours of the whole programme undocumented. Payroll cutovers fail in the cutover window at least as often as they fail in configuration.

The runbook is the artefact that covers it, and it sits alongside the build plan, the milestone plan and the critical path documentation rather than replacing them. It is a sequenced list of tasks with an owner against each, a duration, a dependency, and a stated checkpoint at which the result is verified before the next task begins. It names the point of no return: the moment after which reverting costs more than proceeding. It states the rollback position before that point and the recovery position after it. It says who is awake, when, and how they are reached.

The payroll-specific entries are the ones most often missing. The final legacy run and its sign-off. The balance and year-to-date transfer, reconciled rather than assumed. The banking file cut-off and the submission deadline that does not move because a programme is late. The first live run in the new system, with a comparison against the parallel run result rather than a wait to see whether anyone complains.

A go decision taken by a room is a go decision owned by nobody. The governance that prevents this is unglamorous and it works.

A responsibility matrix set at the start says who is accountable for the decision, who is consulted and who is merely informed, and it should be revisited before cutover rather than assumed to have survived the programme. A risk register carried through delivery means the open items at the decision point are the ones the board has been watching, not a new list assembled to explain a delay. A communications plan says who tells employees what, and when, if the first run is late. Sponsor updates on a weekly cadence mean nobody arrives at the decision meeting hearing the position for the first time.

Then the decision itself is made against something specific. Not a date, and not a programme phase, but the exit criteria the test strategy set out before execution began: scripts executed, severity thresholds for open defects, reconciliation checkpoints met, runbook rehearsed. A board that adopts those criteria at the start can hold a go or no-go conversation in twenty minutes. A board that meets the question for the first time on the night will take the date, because the date is the only fixed thing in the room.

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 the board eventually decided against was not a status report. It was 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 board as the programme ran, and a test completion evidence pack carrying a quantified residual risk assessment.

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.

• Read the Embedded Intelligence Method. Why every configuration change leaves a written baseline, a test execution record and a post-change validation, and how that becomes the evidence a board signs against.
• See how a payroll was proven against an estate of over 2,500 employees. The parallel run, the defect register and the evidence pack behind a go-live decision.
• Read the Unit4 X-Ray brief. The fixed-scope diagnostic to commission when the evidence pack you have been handed does not answer the board’s questions.