Payroll Failures Don't Start at Go-Live. They Start Months Earlier.

When a big footy game finishes, everyone knows the score. The value for the team comes afterwards, when coaches and analysts help them understand it all. They should look beyond the result to the decisions, turning points, warning signs and missed opportunities that shaped it long before the final siren. Ideally, they can separate themselves enough from the result to be able to gain perspective.

Then you have the knowledgeable, typically very experienced spectators and colleagues who give their perspective. That was the nature of the discussion among our Directors, as the recent Sydney Water payroll story unfolded and continues to unfold.

We were not involved in the project, so we cannot know what happened internally or judge the decisions made by Sydney Water, its implementation partner or the technology provider. Only a proper, independent review of the project evidence could establish that.

But when a major payroll implementation results in employees being underpaid, overpaid, not paid correctly or even not paid at all, the public outcome naturally raises broader questions. The most useful question is not simply, “What went wrong at go-live?” or “Whose fault is it?”

It is: How far back do you want me to go? And what decisions led to this?

Because these situations rarely begin on payday. This is a symptom of an underlying, untreated issue. Go-live is usually the point where your work to that date and the series decisions made bears fruit. The trick is to ensure it bears fruit that is ripe. Hint: No one decision causes this, it is typically a series of decisions whose responsibility lies in various key governance roles on the project.

Go-live is often treated as a single decision made at the end of a project. In practice, it is the cumulative result of hundreds of decisions made over many months.

Which risks were accepted? Which defects were deferred? Were the consequences fully understood? Was the business genuinely ready, or was the technology simply available? Were difficult messages escalated clearly? Did the sponsor receive the evidence they asked for? If not, why was the project allowed to proceed?

These are not technology questions. They are governance and executive decision-making questions.

A strong project sponsor is critical because the sponsor is the ultimate decision-maker for the program. If you think of the project as a company, the sponsor is effectively its CEO. There may be a steering committee and several senior stakeholders, but accountability cannot sit vaguely with a group. There needs to be one person who owns the decisions and is prepared to stand behind them.

That does not mean every negative outcome is automatically the sponsor’s fault. The quality of a decision depends heavily on the quality of the information provided.

A strong sponsor knows what evidence they require and refuses to proceed without it. They should be prepared to say: “You haven’t given me what I asked for. I am not comfortable going live until you do.”

A weaker governance environment accepts incomplete information, relies too heavily on optimistic reporting or allows project momentum to become a substitute for evidence.

Testing is often discussed as though it provides a simple pass or fail answer. It rarely does.

Testing produces evidence. Executives must interpret that evidence, understand the remaining risks and decide whether those risks are acceptable.

That decision changes according to the system, the organisation and the potential impact. A low-impact defect in an ERP implementation may be manageable after go-live if it is well understood, appropriately mitigated and does not materially affect customers, employees or operations.

Payroll is very different.

“You can, to some extent, accept a little bit of risk and resolve that with an ERP. You cannot do that with a payroll solution.”

Payroll directly affects people’s livelihoods and wellbeing. Employees depend on being paid accurately and on time. Errors can quickly create financial distress, industrial action, regulatory scrutiny, reputational damage and a loss of trust.

The different risk profile therefore demands different disciplines.

A payroll parallel run is not a dummy test. The existing payroll system and the new system operate alongside one another using the same live payroll data. Their outputs are then compared and reconciled, line by line.

That process needs to cover the organisation’s full range of payroll scenarios: weekly, fortnightly and monthly cycles; different employment arrangements; enterprise agreements; allowances; superannuation; deductions; leave; termination payments; director payments and any other material variations.

The point is not simply to run the test. It is to identify discrepancies, fix them and repeat the process until the organisation has reliable evidence that the new system produces the correct result.

The saying ‘leave no stone unturned’ holds especially true in this sense.

“I’m not backing a go-live decision until I see the tests from your parallel pay runs and until I see zero issues with your pay runs in your parallel testing.”

That does not mean a payroll program will never encounter an unforeseen issue. It means known and repeatable payroll scenarios should have been proven before employees rely on the new system.

For payroll, a genuine rollback strategy is also essential. Importantly the rollback strategy is Plan B to parallel testing. Organisations need a working alternative until successful payroll cycles have been completed and confirmed.

In practical terms, payroll requires a backup plan for the backup plan.

“You only turn it off after successful pays have happened in the system.”

By the time a project approaches go-live, the pressure to proceed can be immense. The organisation has invested significant money and effort. Employees and leaders are expecting the change. Implementation resources may be scheduled to move elsewhere. Commercial milestones, licence commitments or contractual consequences may be involved.

Nobody wants to be the person who delays the program.

But a hard decision is hard for a reason. The organisation still needs someone prepared to make it, and this

If you lack independence, this amplifies the difficulty even more.

An independent advisor is not motivated by a software licence, a delivery bonus, an implementation milestone or the need to protect the decision that was made earlier. The focus is the client’s outcome and whether the risk of proceeding is acceptable.

“They don’t have a horse in the race on the technology front or the partner front. They are simply client-side independent resources who have no horse in the race, and they give you advice which you may not like at times, but it is the advice you need to hear.”

Independent advice does not remove accountability from the sponsor, nor does it mean the advisor makes the decision. The advisor’s role is to ensure the risks are clear, the evidence is complete and the executive understands the consequences of the decision being made.

I have advised clients to proceed while documenting risks I would not personally accept. In those situations, the sponsor understood the evidence, knowingly accepted the risk and made an informed decision. When the risk later became an issue, the discussion was not about who had failed to warn whom. It was about how to resolve it.

That is an important distinction. Good governance does not guarantee every decision will be risk-free. It ensures decisions are made knowingly, transparently and with clear accountability.

One of the less visible parts of independent advisory work is understanding how the sponsor makes decisions.

Some sponsors want a concise summary and make decisions quickly. Others require detailed evidence and time to examine it. Some naturally challenge the project team. Others need support to identify the questions they should be asking.

The advice and evidence need to be presented in a way that protects that particular sponsor and helps them make a sound decision.

“As an advisor, my sole job is to foresee what decision a sponsor will make. And ultimately to help shape it through my experience and problem solving”

That does not mean manipulating an executive towards a predetermined answer. It means recognising how they process information, where their blind spots may be and what they need to properly understand the risk.

Sponsors do not lead major payroll transformations every day. An experienced independent advisor has seen the patterns repeatedly across organisations, industries, technologies and implementation partners. That broader experience helps the sponsor recognise risks that may not be obvious within a single project.

The level of governance required also depends on who is affected.

A payroll implementation in a relatively simple private business is not the same as one in a major utility with several employment arrangements, government stakeholders, unions and a large, diverse workforce.

That stakeholder environment changes the project’s risk profile. It affects communication, governance, testing, decision rights, escalation and contingency planning.

Stakeholder analysis should therefore happen at the beginning, not while the project is already in flight. Organisations need to understand who will influence the project, who will be affected, how those groups make decisions and where resistance or competing interests may emerge.

It is as important to choose the right people for a project as it is to identify the people who should not go near it.

Where capability or behaviour is affecting delivery, leaders need to be prepared to make changes. That may mean bringing people in, moving people out or resetting responsibilities. Avoiding those decisions because they are uncomfortable rarely makes them easier later.

Once a risk becomes a live issue, the immediate priority is to protect the people affected and restore the operation.

Payroll errors need to be rectified urgently. Employees need clear communication. Manual interventions, fallback processes and additional checks may be required.

At that point, arguing about blame does not pay anybody correctly.

“When a risk has eventuated into an issue, the response is more important at that point than what had happened.”

Accountability still matters, but it should be established through a proper review rather than assumption or public speculation. Large transformation outcomes are usually multifaceted. The client, implementation partner, technology provider and other parties may each have made decisions that contributed to the result.

The more valuable organisational response goes beyond fixing the immediate issue. It asks whether the same weaknesses have appeared before.

What happened in the last three or four technology projects? Were there similar gaps in governance, resourcing, testing or executive oversight? Were lessons identified but never acted on?

Every project should include an independent post-project review, including projects considered successful.

Organisations often review failures and assume successful projects need no examination. That is risky. A positive outcome does not always prove the process was sound.

“Just because you got lucky this time doesn’t mean you’ll get lucky next time.”

A project may have succeeded despite weak controls, individual heroics or risks that simply did not eventuate. Reviewing successful projects helps organisations distinguish repeatable good practice from good fortune.

Stories about failed payroll or enterprise implementations naturally focus on the visible consequences. Employees were affected. Operations were disrupted. Unions, regulators or the media became involved. Executives were then required to explain what happened.

By that point, most of the opportunities to prevent the outcome have passed.

The questions that matter need to be asked weeks and months earlier.

Do we have the right foundation, people and responsibilities? Is the evidence complete? Have we tested the real operating scenarios? What risks are we accepting? Who benefits from proceeding and who is independent of that outcome? Is the sponsor receiving what they need to make a defensible decision? What happens if we are wrong?

No transformation program will make only perfect decisions. That is not a realistic standard.

Good governance is the ability to recognise when a decision needs to be challenged, to bring in additional expertise when required and to act while there is still time to change the outcome.

That is the lesson I take from high-profile transformation failures.

The headline tells us what became visible.

The real value lies in understanding what led to failure.