If You’re Not Prepared to Go Deep, Don’t Start
The real shape of HRIS projects
Almost every HR or payroll system project starts with a set of sensible sounding goals to ultimately create a better experience for employees and the organisation
A large scale HRIS replacement is not a software upgrade. It is an intervention into the way an organisation describes itself, governs itself, and enforces its own rules. If a project is not structurally prepared to engage at that level, then the most likely outcome is not failure in the traditional sense, but something quieter and more persistent. The organisation ends up with a newer, more expensive system that quietly preserves most of the old complexity and calls it progress.
The comforting fiction of implementation
The word implementation does a lot of quiet damage in this space. It suggests that the hard work has already been done by someone else, and that the organisation’s job is mostly to configure, migrate, test, and train.
In reality, the software is the easy part. Payroll, HR, and workforce systems sit at the intersection of industrial rules, organisational structure, funding models, and operational reality. They are where all of the compromises, exceptions, and historical decisions get turned into something executable. Changing the system means, whether you intend it or not, reopening those decisions.
Most projects are not set up to do that.
They are funded and governed as IT programs with business input, rather than as organisational change programs with technical components. They have timelines that assume that most things are already known. They have steering committees that can make prioritisation decisions but not structural ones. As a result, they drift, almost inevitably, toward the safest possible version of success, which is to reproduce the existing world in a new platform.
The depth most organisations quietly avoid
In every large organisation there are layers of structure and logic that almost nobody wants to touch.
There are job frameworks that have grown over decades. There are enterprise agreements and local arrangements that intersect in ways that only a handful of people really understand. There are pay rules that exist partly because of law, partly because of history, and partly because at some point someone needed to make a problem go away quickly.
There are also data models and organisational structures that look strange from the outside but encode very real funding, governance, and operational constraints. None of this is accidental. It is the accumulated result of trying to keep a complex organisation functioning. A serious HRIS project will run into all of it. The question is not whether these things exist. The question is whether the project is actually empowered to deal with them.
The difference between installing software and changing a system
It is perfectly possible to run an HRIS project that is essentially about installing software. You map the old fields to the new ones, replicate the old structures, reimplement the old rules, and focus most of your energy on testing and change management.
If that is all the organisation wants, it can work. What it will not do is change anything fundamental.
The more difficult class of projects are the ones that use the system change as a forcing function to ask harder questions. Why do we have five different ways of describing the same role. Why does this allowance exist. Why do we attach costing here rather than there. Why do we have entire categories of exceptions that only exist because nobody has been able to unwind the history behind them. Those questions are not technical. They are organisational, industrial, and sometimes political. If the project is not designed to go there, it will not, no matter how good the software is.
The invisible constraint: industrial and governance reality
One of the patterns that repeats across sectors, particularly in government, education, health, and large asset heavy organisations, is that many of the things that look like “bad structure” from a systems point of view are in fact the product of very real industrial and governance constraints.
Changing an organisational model often means rewriting job descriptions, reclassifying roles, and potentially reopening agreements. That is not a configuration exercise, it is an industrial process, and it comes with risk, cost, and politics attached. In those circumstances, organisations frequently make a rational decision to carry complexity forward rather than confront it all at once.
The mistake is not in making that choice. The mistake is in pretending that the project is still transformational after that decision has been made.
Why “we’ll fix it later” almost never works
Another common pattern in these programs is the idea that the hard parts can be deferred. We will get live first, then we will clean up the structures. We will replicate the current rules for now, then we will simplify them. We will migrate the data as is, then we will rationalise it.
In practice, later rarely arrives.
Once a system is live, it becomes production infrastructure. Changes get harder, not easier. Testing becomes more expensive, risk tolerance drops and the business moves on to other priorities. The project team disperses, budget is gone and what was supposed to be a temporary compromise quietly becomes the new permanent architecture. At that point, the organisation is no longer postponing transformation, it has decided, by default, not to do it.
The technical depth most organisations also avoid
Even when organisations accept that there is structural and organisational depth in these programs, they often dramatically underestimate the technical and data depth.
Historical data is the first place this shows up. Almost every project says it will migrate years of history. Almost no project truly confronts what that means. Different schemas, different concepts, different rules, different structures, and different semantics get flattened into something that technically loads but no longer quite means what it used to mean. Bulk data transformation is not an IT task. It is a semantic translation problem, and most projects only discover that when they are already too far in to change course.
Integrations are the second place the illusion shows up. “The platform is open.” “It has APIs.” This sounds reassuring until you ask the harder questions. Who is building these integrations. Who owns them. Who tests them when one side changes. Who supports them three years from now. Who fixes them at four o’clock on a Thursday when payroll is due. An API is not an integration. It is an invitation to build and operate a piece of software. Most organisations do not staff or govern that reality honestly.
The third and most fashionable illusion at the moment is AI. We have seen this movie before. When SaaS arrived, a lot of vendors took their existing on premises products, put them in someone else’s data centre, and called them cloud platforms. Very little changed in the actual architecture. We are now seeing the same pattern with AI. A chat interface or a summarisation feature is bolted onto the same underlying product, and suddenly the system is described as “AI powered”, even though the rules engine, the data model, and the workflow engine underneath are exactly the same as they were before.
You can see this in small but telling ways. Why does a major HR platform still not properly support panel based interviews after years on the roadmap and hundreds of customer requests, but can ship an “AI assistant” in a few months. Because one requires changing the actual product model, and the other lives at the marketing and interface layer.
The risk and custody depth almost nobody scopes
There is one more layer of depth that is almost always under discussed in these projects, and that is risk, custody, and sovereignty.
HR and payroll systems hold some of the most sensitive data most Australian organisations have. Tax File Numbers. Bank details. Home addresses. Salary information. Performance data. Disciplinary records. Health and leave information. In many cases, this data is more sensitive than anything else the organisation holds.
Under Australian law, particularly the Privacy Act and related obligations, organisations carry serious responsibilities for how this data is stored, processed, accessed, and disclosed. Yet in practice, most HRIS projects treat data residency and security as a procurement checkbox rather than an architectural question.
This is where the “Russian nesting dolls” problem appears. You select “Australia” as the region. The SaaS provider may still be a US headquartered company and therefore subject to foreign legal regimes. The platform may run on a global cloud provider whose Australian region is actually a mesh of replication, failover, and optimisation systems. Support staff, monitoring tools, and analytics pipelines may operate from other countries. AI features, reporting tools, and integrations may quietly export slices of data to yet more places.
Every “integration”, every “open API”, every “AI feature” is also a new data export path. Most organisations cannot draw a complete diagram of where their HR and payroll data goes, who can access it, under which legal regimes, and under what operational circumstances. They are governing by assumption rather than by evidence, and making compliance commitments based on vendor assurances they cannot technically verify.
The quiet failure mode
Most HRIS projects do not fail in a way that shows up in headlines. They go live. People get paid. The system is technically “modernised”. The failure, if it happens, is quieter.
A few years later, the organisation discovers that it is still carrying most of the old complexity, but now it is locked inside a more expensive and harder to change platform. The people who knew how the old world really worked have moved on. The workarounds have become institutionalised. The system is treated with a kind of respectful fear. At that point, the organisation is not running the system. It is living inside it.
Being honest about what you are actually doing
None of this means that every HRIS or payroll project needs to become a multi year organisational redesign exercise. That would be unrealistic and, in many cases, irresponsible. It does mean, however, that organisations should be honest with themselves about what kind of project they are actually running.
If the goal is to replace a system and keep the underlying structures and rules largely intact, that is a legitimate choice. It should just be described that way and governed that way. If the goal is to simplify, standardise, or fundamentally change how the organisation works, then the project has to be empowered, resourced, and governed as that kind of intervention. Trying to do the second while pretending you are doing the first is how you end up spending a lot of money to stand still.
The real decision: Every serious HRIS or payroll program is, whether anyone admits it or not, a bet on how much organisational truth the organisation is prepared to confront. If the answer is “not very much”, then the safest and most honest thing to do is to keep the scope shallow and be clear about what you are and are not changing.
If the answer is “a lot”, then the project needs to be designed very differently from the start. If you are not prepared to go deep, do not pretend that you are. Because the organisation will still get a new system. It just will not get a new reality.