By Adrienne Silla | Head of , Australian Payroll Association
The project plan says the implementation is on track.
UAT is underway, the issues list is manageable and everyone is working towards the go-live date.
Then someone who has just joined the project asks a seemingly simple question:
“Why did we decide to configure it this way?”
And suddenly, what sounded like a simple question has a six-month history behind it.
Anyone involved in a payroll or HRIS implementation knows far more happens behind the scenes than the project plan suggests. The obvious risks are generally identified early. Data migration, integrations, configuration, testing, timelines and change management all make their way onto the risk register. But some of the challenges that can have the greatest impact are much harder to see at the beginning. And often, they have very little to do with the technology itself.
The people behind the project
Resourcing is a good example. Organisations naturally think about their own project team. Who will provide the payroll expertise? Who will lead testing? How much time will HR, IT and finance need to contribute?
What can be less visible is the resourcing model on the other side of the project. Vendor project managers and implementation consultants are rarely working exclusively with one client. They may be balancing workshops, configuration, testing, defect resolution and go-lives across multiple projects. Through implementation work, we have encountered vendor resources managing significant client portfolios, in some cases up to 10 projects at a time.
That isn’t a criticism of the consultant or vendor. It is simply part of the delivery environment. But it is something organisations should understand when they enter an implementation. For payroll, this can be particularly important.
Payroll configuration is rarely just a matter of selecting a setting on a screen. It can come down to the detail of an Award interpretation, Enterprise Agreement condition, allowance, leave entitlement or working arrangement. That detail then has to carry through configuration, testing and defect resolution. If the people supporting the project are spread across multiple implementations, continuity and access to the right expertise can become important risks. It may also not receive much attention during an RFP, where the focus naturally sits on functionality, timelines and cost.
Questions about the implementation team’s structure, resource availability, continuity when resources change and escalation pathways can become equally important once the project is underway.
What happens when people change?
Of course, vendor-side resources aren’t the only people who change. Payroll SMEs leave. Project managers move on. New employees join halfway through an implementation and inherit months of decisions, workshops, spreadsheets, emails and testing history. Anyone who has joined a project halfway through will know the experience.
You ask what seems like a straightforward question, only to discover there are six months of conversations behind the answer. The challenge isn’t necessarily the change in personnel. It is the knowledge that can disappear with them. This is why good documentation matters so much. Not just the final decision, but the why behind the decision. A configuration choice that makes perfect sense today may be difficult for someone new to the project to understand six months later if the reasoning was never captured.
And it isn’t just people who change. Organisations change too. Policies are updated. Structures move. Enterprise Agreements change. Business processes evolve. New locations or employee groups are introduced. A requirement documented at the beginning of an implementation may still be technically correct, but the business context surrounding it may look very different several months later.
That is why clarification throughout an implementation is normal. Payroll requirements can look relatively simple on paper but become much more nuanced when translated into system configuration. Revisiting a requirement doesn’t necessarily mean the original requirement was wrong. Sometimes the detail simply becomes clearer as the project progresses.
Payroll doesn’t stop for the project
Then there's the challenge every payroll professional will recognise: business-as-usual doesn't pause just because UAT has started. Employees still need to be paid. Deadlines still arrive. Queries still need answering. Leave still needs processing, new starters still commence, and employees still terminate. Compliance obligations, month end, year end and everything else in between continue regardless of what's happening on the project schedule.
And more often than not, the people with the deepest payroll knowledge are the same people being pulled into workshops, configuration reviews, testing and defect discussions. A project can have all the right names on the resourcing plan and still struggle to get enough of those people's time. This is one of the hidden risks of payroll implementations: the project is competing with the payroll team's most important job, running payroll.
Testing the system isn’t the same as testing payroll
Testing brings another important lesson. There is a difference between proving that a system function works and proving that payroll works. A system might correctly calculate an ordinary employee’s pay. But what happens when that employee works overtime, takes annual leave, receives an allowance, changes hours, has a retroactive pay increase and then terminates?
Payroll relies on employee data, time and attendance, scheduling, leave, allowances, calculations, approvals, banking, superannuation, statutory reporting and finance all working together. Something can operate perfectly well in isolation and behave very differently once it meets a real employee scenario. And, as most payroll professionals know, employees are very good at producing scenarios that no test script ever imagined. That is why good payroll testing isn’t just about ticking off system functionality. It is about testing the real-world payroll scenarios that the business is actually going to encounter.
The risks between the lines
Perhaps that is one of the bigger lessons from payroll and HRIS implementations. The challenges don’t always sit neatly with the client, the vendor or the technology. They often sit somewhere in between. They sit in competing priorities. In changing people. In knowledge transfer. In different interpretations of a requirement. In a business process that changes halfway through the project. And in the everyday reality of keeping both a project and a payroll moving at the same time.
Not every risk can be predicted or avoided. Complex payroll and HR technology projects involve a lot of moving parts, and things will inevitably change along the way. But recognising these less visible risks early can make them much easier to identify and manage when they emerge. Sometimes the most valuable support isn’t another person ticking off tasks on the project plan. It is having someone who understands payroll look at what is happening between the lines.
If you’re preparing an RFP, considering a new payroll or HRIS platform or already somewhere in the middle of an implementation and could use additional support, get in touch with the Australian Payroll Association.
