When a scheduling, HR or recruitment system is replaced in a people-intensive business, it's easy to assume the hard part is the technology. It rarely is. The hard part is that operations can't stop for a single day while the change takes place – wages have to be paid, shifts have to be staffed, and employees notice immediately if something goes wrong.

Choosing the system is an operational decision, not an IT decision

A system that looks best on a requirements list can be the wrong choice in practice. The right decision starts from how the business actually works: how shifts are allocated, how exceptions are handled, how data flows between systems. That's why we always start in the operation and let the requirements drive the choice – not the other way around. It's that mapping which determines whether the implementation is straightforward or painful.

Requirements gathering and UAT are where the risk is designed out

Most problems at go-live aren't surprises – they're missed requirements. Structured requirements gathering, anchored with the people who will actually use the system, followed by rigorous user acceptance testing (UAT) with real-world scenarios, is what catches the errors while they're still cheap to fix. Don't test that the system works in theory; test that it can handle a real Monday morning.

Going live across multiple sites at once demands a plan that holds

When a new system is rolled out across many sites in parallel, it's less about the system and more about coordination: a clear sequence, training at the right time, a support structure that catches questions immediately, and a decision path that resolves problems in minutes – not days. We have led this kind of change – scheduling, HR and recruitment – in businesses with geographically dispersed sites and tight timelines, where the entire organisation had to switch over at the same time.

Ownership all the way to stable operation

A go-live isn't the finish line – it's the most vulnerable phase. Whoever runs the project has to take responsibility for the outcome all the way until the system is stable and the business stands on its own – not hand over at deployment. That's when pace, structure and operational ownership decide whether the investment actually pays off.