Payroll readiness

Sydney Water, Dayforce, and the payroll readiness question

This article is based only on public reporting and public documents. It is not an inside account of Sydney Water, Dayforce, Deloitte, any implementation partner, any union process, or any confidential project material. The actual cause of the Sydney Water payroll disruption has not been fully confirmed publicly, so this article does not try to diagnose the project from the outside.

The Sydney Water and Dayforce payroll disruption matters because it is a local Australian example of a risk pattern that appears in many HCM programmes. The public material does not support a neat story where one product, one configuration decision, one implementation partner, or one internal team can be blamed from the outside. The safer and more useful observation is narrower. Payroll was disrupted after go-live, which gives reason to believe that at least some part of the readiness picture did not hold under production conditions. That could have been technical readiness, organisational readiness, data readiness, support readiness, cutover readiness, or some combination of those areas.

I want to compare that pattern with Canada's current HR and Pay Transformation, but that comparison needs context. Canada is clearly different from Sydney Water in scale, jurisdiction, workforce, governance, and history. The comparison is useful because Canada has already lived through a highly visible public payroll failure with Phoenix, and its current replacement programme is framed around a lesson that every payroll transformation can learn from. A new pay system needs more than technical viability. It needs the organisation, data, processes, users, support model, governance, and deployment path to be ready at the same time.

What is publicly known about Sydney Water

In April 2026, a question was put through the Parliament of New South Wales about Sydney Water's PXP automated system, identified in the question as Dayforce. The question asked about cost, defects, alignment with existing systems and payroll, alignment with the enterprise agreement, delivery delays, operational capacity, and whether payroll would need more people to manage the new system. The published answer recorded a current cost estimate of 36.1 million dollars and stated that no true defects had been identified with Dayforce. It also said that user acceptance testing and parallel payroll testing were designed to uncover and resolve misalignments or configuration issues before go-live, that finding items during testing was normal in large IT projects, and that the project was fit for purpose and being configured to align with relevant systems and Sydney Water's enterprise agreement.

The same answer also said the programme had been rescheduled at the request of operational business units to better align with capacity and manage the pace of change for the workforce. That detail is relevant because it shows that business capacity and change absorption were already part of the public record before the July payroll disruption. It does not prove the cause of the later issue. It simply places organisational readiness within the public context of the project.

Public reporting in July 2026 then described issues after Sydney Water transitioned to Dayforce at the beginning of July, with workers reported as being underpaid, overpaid, or not paid at all. Reporting also referred to issues with superannuation and time-off tracking, and said the Australian Services Union had lodged a complaint with the Fair Work Commission. The same reporting said the union claimed it had previously warned Sydney Water about the system's ability to handle round the clock scheduling complexity, while Sydney Water was reported as acknowledging that the transition had not gone as planned and apologising to staff.

Those facts need to be handled carefully. A newspaper report is not a root cause analysis. A parliamentary answer is not a complete delivery file. A union claim is not an independent finding. A public apology does not explain every technical, operational, data, support, or governance cause. The responsible conclusion is that the full cause has not been publicly established. The broader implementation lesson is that a payroll readiness case needs to cover the real workforce, the real data, the real operating model, the support path, and the cutover conditions before go-live.

Readiness is broader than system readiness

When payroll goes wrong after an HCM launch, the discussion often moves quickly to whether the system was ready. That framing is too narrow because it treats readiness as a technical condition. A system can be configured while the wider payroll operating model remains fragile. A project can have UAT evidence and parallel payroll evidence while still carrying gaps in scenario coverage, data confidence, manager behaviour, payroll runbooks, support capacity, cutover decision rights, or employee communication.

Readiness has several layers. System readiness asks whether the configuration and integrations behave as intended. Data readiness asks whether employee, work assignment, tax, bank, superannuation, manager, location, pay group, and historical records are clean enough to trust. Payroll operations readiness asks whether the payroll team can run, validate, correct, approve, and recover the pay cycle under production pressure. Workforce management readiness asks whether rosters, time, approvals, exceptions, and cutoffs work in the way the business actually operates. Employee and manager readiness asks whether the people using the system understand what has changed and what they must do differently. Governance readiness asks whether the organisation can slow or stop a launch if the evidence is not good enough.

The public Sydney Water material points to a complex operational workforce, but it does not prove that particular scenarios were missed in testing. Round the clock scheduling would almost certainly have been known from the beginning of the project. The lesson is therefore more careful than saying the complexity was not understood. Known complexity still has to survive the full readiness chain, including configuration, migrated data, test evidence, payroll operations, support procedures, cutover timing, and live decision making. A payroll failure after launch gives reason to ask which part of that chain did not hold in production.

Why Canada is a useful comparison

Canada's Phoenix pay system is one of the clearest public examples of payroll transformation being much larger than technology deployment. Phoenix was introduced for the federal public service and became associated with delayed pay, underpayments, overpayments, and employees not being paid correctly. The details of Phoenix are different from Sydney Water, but the broad lesson is relevant. Payroll failure is experienced by employees as financial instability, and once trust is broken the organisation has to manage operational recovery, employee relations, legal risk, public confidence, and system correction at the same time.

Canada is now replacing Phoenix through its HR and Pay Transformation work, with Dayforce selected as the technology being assessed and prepared through a staged programme. The Canadian material is useful because it separates technical viability from implementation readiness. The Auditor General of Canada has already identified risks in the modernisation effort, including slow progress on simplification, backlog risk, lifecycle cost uncertainty, and schedule compression. That makes the example more useful for practitioners, because it shows a readiness-first approach under real scrutiny, with acknowledged risks.

The public Canadian programme language refers to feasibility, definition, readiness assessments, departmental testing, UAT, system integration testing, first wave readiness confirmation, vanguard deployment, phased onboarding, process standardisation, data readiness, and operational prerequisites. The point is that technical capability is only one part of the readiness case. In a payroll context, readiness has to be built, evidenced, challenged, and stabilised before deployment expands.

What readiness-first means in practice

Canada's Next Generation HR and Pay Final Findings Report describes testing across critical HR and pay capabilities and refers to complex situations such as shift work, employees with multiple roles during a work period, and worksites with limited internet access. It also says additional complex scenarios were added when pilot departments identified requirements that were not in the original definition. That is a useful public example of a test set being expanded by business complexity as the programme learned more about the workforce.

A readiness-first programme gives the business a way to show where complexity lives. This is especially important in payroll because the highest risk scenarios are often the combinations that sit at the edge of rosters, employment changes, approvals, leave, allowances, public holidays, historical corrections, and payroll cutoffs. For Sydney Water, no public material confirms whether those combinations were tested well, tested partially, or tested and then affected by another cause. The useful public lesson is that readiness evidence needs to remain connected to the real operating model all the way through launch.

The Canadian programme also places business process standardisation and simplification near the centre of readiness. Public lessons learned material says Phoenix was treated too much as an IT deployment and not enough as an integrated business transformation. The current programme is trying to standardise HR and pay processes before deployment, consolidate HR systems, improve data readiness, and prepare departments through workshops, validation, and phased onboarding. Whether Canada ultimately executes that well is a separate question. The useful principle is that payroll readiness extends beyond configuration.

Applying that lens to Sydney Water

Applying that readiness-first lens to the Sydney Water public case does not require an assumption that Dayforce cannot support complex payroll, that Deloitte failed to test known complexity, or that Sydney Water ignored its own workforce model. Those claims would go beyond the public evidence. The better question is whether the total readiness case held up when the system moved from project conditions into production conditions.

The parliamentary answer said UAT and parallel payroll testing were designed to uncover and resolve misalignments or configuration issues before go-live. Those are the right types of activity, but they do not automatically prove the whole readiness case. UAT proves selected scenarios in a selected environment using selected data. Parallel payroll proves selected pay runs under selected conditions. A live payroll cycle then adds production data, manager behaviour, employee support demand, operational cutoffs, remediation decisions, and time pressure.

For an operational workforce, readiness evidence has to be able to follow combinations. Late shift swaps, approvals after cutoff, rosters across public holidays, location-based allowances, role changes inside a pay period, historical corrections, leave interactions, superannuation data, and payroll override decisions can all be known complexities. The question for any programme is how those known complexities remain visible across configuration, data, testing, cutover and support. The Sydney Water case shows why that question matters, without needing to claim which specific scenario did or did not fail.

Configuration needs operating ownership

Payroll implementation changes how work gets done. The organisation needs to know who owns a failed validation, who can approve late time, who decides how to handle an overpayment, who contacts affected employees, who has authority to correct live data, who understands whether a pay difference is expected, who can approve a workaround, and who has the authority to slow or stop the next payroll cycle if evidence is not good enough. These questions are operational, and if they are unresolved before launch they are answered under pressure after launch.

The April parliamentary answer said the same Sydney Water payroll team that completed payroll processing before PXP would transition to completing payroll through PXP after go-live. That detail matters because it indicates organisational knowledge and likely project experience were expected to remain close to the new process. Retaining payroll knowledge is valuable, especially where the workforce has complex rosters, enterprise agreement conditions, and established operational patterns.

Retained knowledge still has to be translated into a new way of working. A new HCM and payroll platform changes validation paths, timing, exception handling, approvals, support questions, reporting views, and the way payroll teams diagnose differences. Experienced payroll people can bring the right judgement, but they still need rehearsed runbooks, decision rights, escalation paths, and evidence that the new process works under live conditions. The readiness question is how well the organisation converts existing payroll knowledge into operating confidence in the new model.

Stop criteria are part of readiness

Every payroll project needs a go-live decision, and the harder discipline is defining what evidence would make the organisation delay. Projects are usually good at describing what success looks like. They are often less explicit about what would cause a stop. That matters because payroll projects carry intense schedule pressure, and without clear stop criteria the final decision can drift toward optimism.

Stop criteria might include unresolved material pay differences in critical employee populations, unproven high risk readiness scenarios, incomplete superannuation or banking validation, unresolved integration defects affecting payroll outputs, incomplete manager readiness for approval cutoffs, insufficient payroll support capacity, no tested recovery process, or a backlog of employee data corrections that would contaminate the first live pay. These criteria are evidence that the organisation understands payroll harm and has decided not to hide it inside a milestone.

Canada's current approach gives a useful contrast because its public material refers to readiness assessments, first wave readiness confirmation, vanguard deployment, and later waves after earlier waves have stabilised. The lesson is not that every organisation needs Canada's scale of governance. The lesson is that readiness gates need enough authority to slow deployment if the evidence is weak. A readiness gate that cannot change the plan is a ceremony.

HCM and payroll systems are different from ERP systems

HCM and payroll systems are different from ERP systems in one important respect. When an ERP implementation has problems, the organisation may face procurement delays, reporting gaps, reconciliation issues, workflow disruption, or finance close pressure. Those are serious issues. Payroll issues can immediately affect the money employees rely on to live. An underpayment, overpayment, missed pay, incorrect leave balance, or uncertain superannuation outcome can affect rent, mortgages, food, transport, loan repayments, family obligations, and trust in the employer.

That difference changes how readiness is discussed. Employee communication and support are part of payroll readiness because the organisation needs a prepared path for urgent pay issues, hardship escalation, correction timing, overpayment handling, superannuation questions, and confidence in leave and time records. Fair Work guidance on underpayments and overpayments is practical here. Underpayments need to be fixed quickly and accurately, while overpayment recovery requires discussion and agreement in limited circumstances, with written arrangements where repayment is agreed.

This is why a payroll readiness case includes support capacity alongside system evidence. If the first production pay cycle creates unexpected issues, the organisation needs to diagnose, correct, communicate, and support employees at the same time. Some issues may still occur, which makes the recovery path part of readiness from the beginning.

Readiness questions for Australian HCM programmes

For people searching for Sydney Water Dayforce commentary from Dan Mattock, the point of this article is deliberately narrow. It is a readiness article, not a blame article. The public record is useful because it gives Australian Dayforce and HCM implementation teams a concrete example to think with, while still keeping the limits of public evidence clear.

The Sydney Water case can be used carefully without turning it into a simplistic story about one organisation, one product, or one go-live. A more useful response is to sharpen the readiness questions Australian HCM and payroll programmes ask before launch. How complete is the readiness evidence for the actual workforce. How clearly are known payroll complexities connected across configuration, data, testing, cutover and support. How well are material parallel payroll differences classified by root cause, owner, fix, retest and approval. How confident is the organisation that employee data is clean enough to trust. How well have manager approvals, payroll cutoffs, late time, reopened time, corrections, and recovery processes been rehearsed.

The same questioning applies to the operating model. How much payroll capacity exists for first pay and hypercare. Who can make operational decisions in production. How will employee support handle underpayment, overpayment, and missed pay scenarios. What evidence would cause the organisation to delay. How visible are dissenting views, unresolved assumptions, and accepted risks at the final readiness gate. These are readiness questions, and they are safer because they do not assume a particular failure cause from the outside.

These questions become more useful when they are backed by an evidence pack. Business readiness can show that the future process is understood, owned, staffed, and accepted by the teams who will operate it. Configuration readiness can show decision lineage, affected populations, dependencies, known limitations, and owner approval. Data readiness can show reconciled employee, job, work assignment, pay, bank, tax, superannuation, location, manager, and historical data. Scenario readiness can show high risk combinations and business confirmation that the scenarios represent the workforce. Payroll readiness can show classified differences, closed or mitigated defects, rehearsed runbooks, and stop criteria. Support readiness can show staffed communication, triage, escalation, correction, and hardship pathways. Governance readiness can show that final decision makers have seen the full risk position.

The deeper lesson

Enterprise HCM projects often fail in the gap between configured and ready. Configured means the system has been built to do what the project believes it needs to do. Ready means the organisation can operate the system safely with real people, real pay cycles, real data, real managers, real exceptions, and real pressure. The Sydney Water payroll case appears, from public information, to sit close enough to that gap that the readiness lesson is worth taking seriously, while still being careful that the actual cause has not been publicly confirmed.

Canada's HR and Pay Transformation is useful because it shows what a readiness-first posture looks like after a major payroll failure has already occurred. It does not offer an easy template, and it does not remove the need for local judgement. It does show the value of separating technical viability from operational readiness, testing complex scenarios in a business-led way, standardising business processes before rollout, using independent challenge, and phasing deployment so the organisation can stabilise before expanding. For Australian HCM programmes, the practical lesson is direct. A launch is stronger when the organisation can prove readiness under real payroll conditions.