Essays on HRMS selection, transformation, vendor evaluation, and the quiet decisions that determine whether a system fits an organisation or merely lives inside it.
The day you migrated is very likely the last day your data was ever fully trusted. From the first hour of real use, it begins to degrade — not through any single failure, but through a thousand ordinary actions. None of this is sabotage. It is simply what happens when real people use a system under real time pressure.
Every system has a direction. The only question is whether that direction was chosen deliberately by someone accountable for it, or whether it emerged by accident from whoever happened to push hardest this quarter. When no one writes the roadmap, the system still gets one — written by the loudest voice, the nearest deadline, and the vendor's release schedule.
HR will tell you it is an IT system. IT will tell you it is an HR system. Finance signed the cheque and considers ownership someone else's problem. Everyone touches it. Everyone depends on it. And in the specific sense that matters, no one owns it.
The day a system goes live is not the day its problems end. It is the day they start arriving in production, attached to real employees and real paychecks. And the team that understood every one of these things has already been reassigned.
A system that is live and a system that is used are two entirely different states, and the distance between them is where most HR Tech investments quietly fail — not with a crash on day one, but with a slow drift back to the old way of doing things over the months that follow.
You did not spend a year and a substantial budget to confirm that the software works. Of course the software works. You spent it to build a system that runs your business — your payroll, your approvals, your exceptions, your edge cases. And that system is precisely the one that testing, as most organizations run it, never actually tests.
"We can build that for you" is the most expensive sentence in the entire project. Not because customization is always wrong — but because almost nobody in the room understands that they are not buying a feature. They are taking out a loan. And the repayments come due at every upgrade, every patch, and every release, for as long as the system lives.
You are not moving data. You are moving the accumulated mess of every HR decision your organization has made for the last fifteen years — into a system that, unlike your old one, will actually enforce rules about what is allowed to exist.
The software you agonised over is largely the same in anyone's hands. The team that implements it is not. Give the same platform to two different implementation partners and you will get two different systems, two different timelines, and two different verdicts on whether the whole investment was worth it.
Here is the uncomfortable truth: the hard conversation already happened. You just didn't know you were in it. By the time a pricing proposal lands on your desk, the most important variables in that document have already been set — and most of them were set by you.
The scorecard gets filled in after the fact. The weights get adjusted to produce the number that matches the preferred outcome. The vendor who impressed the CHRO in demo two wins — not because the evaluation said so, but because the evaluation was quietly shaped to confirm what was already decided.
The reference check is supposed to be the one moment in a selection where you hear from someone with no stake in the sale. In practice, it is the most stage-managed step in the entire process - and the one organizations scrutinize least.
Two things are happening simultaneously in that room. The vendor is executing a presentation they have refined over years to land precisely this reaction. And your organization is experiencing it for the first time, with no shared criteria and no one whose job it is to ask the uncomfortable questions.
The vendor who presents first shapes the questions. The vendor who presents best shapes the shortlist. By the time the scorecard gets filled in, it is measuring what the vendors chose to show — not what the organization needed to know.
Feature requests tell a vendor what to build. Real requirements tell them what problem needs solving. Most HR tech documents skip that step — and pay for it during UAT.
Not because the tool was bad. Not because the vendor failed. But because there was no one truly owning the thinking behind the transformation.
Most HR tech projects don't fail during implementation. They fail much earlier—at the point of selection.