I've seen HR tech projects go wrong in very predictable ways.
Not because the tool was bad. Not because the vendor failed.
But because there was no one truly owning the thinking behind the transformation.
And this happens at companies that spent serious money on the system. Companies that did their research, ran proper vendor evaluations, and signed contracts with reputable names. They did everything right — and still ended up with a system that technically works, but that nobody actually uses the way it was designed.
A 2024 Gartner survey puts a number to this: only 24% of HR functions are maximizing the business value from their HR technology. Which means three out of four organizations are sitting on an investment that is underperforming — not because the technology failed them, but because something upstream of the technology went wrong.
The missing piece is almost never a better tool.
The HR Team Problem Nobody Wants to Say Out Loud
Before we get to the question of who should own an HR tech transformation, we need to address something more fundamental — the team being asked to lead it is already running at capacity.
This is especially true in growing organizations. As headcount scales, HR teams rarely scale with it. Recruitment, compliance, employee relations, performance cycles, payroll — all of this is happening simultaneously, all year round. Asking these same people to also own a complex HR tech implementation is not a resourcing decision. It is a quality compromise dressed up as one.
What happens in practice is predictable. The transformation becomes a side project. Requirements get drafted between other priorities. Configuration decisions get made quickly because there is a vendor deadline, not because they have been properly thought through. UAT gets compressed. Training gets simplified. And by the time the system goes live, it reflects the team's bandwidth — not the business's actual needs.
This is not a criticism of HR teams. It is a structural reality. A growing organization cannot simultaneously ask its HR function to hold the business together and lead a technology transformation without something giving way. Usually, it is the transformation.
What Is Actually Missing
When organizations plan an HR tech transformation, the conversation almost always goes straight to which HRMS, which vendor, what timeline, what budget.
What rarely comes up is: who on our side actually understands how the business works well enough to ensure the technology reflects that — and not the other way around?
That is the role I am talking about. Not someone who knows tools. Someone who can sit with the Head of Finance and understand the approval exceptions that have been managed manually for six years, and then make sure that logic gets built correctly into the system. Someone who can read between the lines of a vendor demo and identify what is not being shown.
An HR Tech expert — internal or external — is fundamentally a translator. Between business operations, HR processes, and technology decisions. When that role is missing, the gap does not disappear. It gets filled by assumptions.
Why This Role Matters at Every Stage
Most people assume this is an implementation role. It is not — or at least it should not be. By the time implementation starts, the expensive mistakes have usually already been made.
Before transformation begins, the work is diagnostic. Understanding workflows deeply enough to identify what is actually broken, not just what people complain about. There is almost always a difference between the two.
During requirements, the job is translation. Business needs have to become structured, specific documentation that a vendor can actually build from. Vague requirements produce expensive misunderstandings — and the cost of that vagueness never shows up on the requirements document. It shows up eight months later during implementation.
At selection, the role is about challenging narratives. Vendor demos are designed to impress. Someone needs to ask the uncomfortable questions — what happens when this breaks, how does this handle our specific exception, what does the implementation team actually look like six months in, after the sales cycle is over?
At contracting, it is about scope clarity. Hidden gaps in deliverables do not usually surface until you are deep into implementation and the vendor points to the contract.
And then implementation — where most of the visible damage happens.
The Vendor PM Problem (And Why It's Not the Vendor's Fault)
Your vendor's project manager is not the problem. They are usually competent, often experienced, and genuinely trying to deliver. But they are managing multiple projects simultaneously, and their job — the one they are accountable for — is to deliver the system as scoped and on timeline.
They are not responsible for your internal alignment. They are not responsible for making sure the way your regional HR teams handle probation extensions was correctly captured in the requirements three months ago. That is not a failure on their part. That is simply not their job.
Someone on your side has to own that. And if no one does, that gap sits open — quietly — until go-live makes it expensive and visible.
What This Role Actually Looks Like in Practice
It is part diagnostician, part translator, part decision-driver.
It means being the person who reads the implementation tracker and asks why a particular workflow was simplified rather than built as originally discussed. Being in the room when a trade-off needs to be made and having enough context to make the right call without delaying the project. Understanding that go-live is not the finish line — it is the beginning of a different kind of work.
It also means being clear-eyed about change management. Not owning internal communications — that belongs with HR and leadership — but ensuring that what gets communicated actually reflects how the system has been configured. Adoption fails when people are trained on how the system was supposed to work, not how it was actually built.
This role requires something that is genuinely hard to find: deep familiarity with business operations, real understanding of HR processes, vendor-neutral judgment, and the ability to make decisions in ambiguous situations without freezing. It is not a technical role. It is a thinking role.
What Happens After Stabilization — And Why Most Organizations Get This Wrong
Go-live gets celebrated. Then everyone moves on. And this is exactly where the value begins to erode.
The months following go-live are when a system either embeds itself into how the business runs, or quietly gets worked around. Users find shortcuts. Managers route approvals informally because the system feels too rigid. Reports get pulled manually because the right dashboards were never configured. Month by month, the gap between what the system can do and what people actually use it for grows wider — and by the time anyone notices, the configuration is already outdated and the business has moved on.
Post-stabilization is not a passive phase. It requires active ownership of a different kind than implementation.
This is when the real audit happens. Are the workflows holding up against actual usage? Are there processes that were deprioritized during implementation and are now causing quiet pain? Are there modules that were licensed but never properly configured? Have business changes since go-live made parts of the original configuration obsolete?
It is also where ongoing optimization becomes possible. Most platforms — enterprise and modular alike — have significant functionality that organizations never activate because no one had the bandwidth or the expertise to build it out during the initial rollout. Post-stabilization is when that work gets done, and when the return on the original investment actually begins to materialize.
The HR Tech expert role does not end at go-live. If anything, it becomes more nuanced — less about managing vendor relationships and more about continuously aligning a system to a business that never stops changing.
A Final Thought
Most HR tech failures are not dramatic. There is no single moment of collapse. It is quieter than that.
It is a system that gets implemented on time and within budget, and then slowly fades into the background as people find workarounds. It is a significant investment that delivers a fraction of its potential because the configuration never truly matched how the business runs — and because the HR team expected to own it was already stretched well before the project began.
Bain's research found that 88% of business transformations fail to achieve their original ambitions. The reason is rarely technology. It is the absence of clear, sustained ownership on the side of the organization making the change.
That is the failure worth preventing. And it starts long before the vendor ever enters the room.