A new system doesn't dissolve old resistance

A workforce of more than 2,000 people had outgrown its HR setup: several disconnected tools, manual handoffs between them, and a growth rate that made every manual step more expensive by the month. Deciding to replace the system was the easy part. Everything that had to happen after the contract was signed was not.

This is where most system replacements actually go wrong – not in picking the vendor. A new HR system touches almost every employee: how they log time, request leave, find their payslip. Swap it out without planning for how 2,000 habits change at once, and the technology can be flawless while the rollout still turns into chaos.

Why the timeline holds but adoption doesn't follow

A project team working to a tight deadline tends to optimise for what's measurable: are requirements documented, is the vendor selected, are the integrations built. All of that fits neatly into a Gantt chart, ticked off week by week. What rarely earns its own line is how the organisation is informed, trained, and – crucially – given time to actually understand why the change is happening and what it means for their own day-to-day work.

Skip that line and the outcome is predictable: the system goes live on schedule, but employees keep logging time in old spreadsheets, managers keep calling HR instead of using self-service, and the expected efficiency gains stay out of reach for months, if they ever show up. It isn't a technology problem. It's an ownership problem: nobody in the organisation asked for the change, so nobody feels responsible for making it succeed. And the more employees it touches, the more separate pockets of resistance there are to manage.

Owning the whole journey, not just the delivery

In this engagement, the brief was wider than a standard system project. Before procurement even began, a thorough needs analysis was run jointly with HR, IT and finance, building one shared target picture before a single vendor was approached – so requirements and evaluation were grounded in how the business actually worked, not a generic checklist lifted from a vendor's sales deck.

Through implementation, communication to employees ran through one channel – project leadership – rather than being scattered across the vendor and internal departments each saying something slightly different at different times. And critically: training and change management ran as their own, parallel workstream from the start, not an afterthought bolted on the week before go-live, in close collaboration with both the business and the system vendor across every phase of the project.

What planning for people, not just the system, delivers

The system went live on the original deadline, for an organisation of more than 2,000 employees, with 12 integrations in place and a five-month implementation phase. No extension, no pilot that quietly dragged on, no silent retreat back to the old tools after launch.

Practical takeaway: if your next system change touches more than a couple of hundred employees, give change management and training their own line in the project plan – with its own budget and clear ownership – from the requirements phase onward. Whoever owns the technical delivery doesn't have to be the one who owns adoption, but someone needs to own it explicitly, or no one will.