Seven systems, one problem
The problem
A frontline workforce of several thousand, hundreds of millions in annual labour costs, and no coherent way to manage rostering or time and attendance. Only 40% of the frontline had any rostering system at all. The rest were managed through spreadsheets, paper, and manual forms. Terminal managers were literally using scissors to build rosters. Planners got repetitive strain from copy-pasting shifts.
The organisation was running seven disconnected systems including one end-of-life platform that held the entire pay rules engine. Nobody had visibility of basic workforce data: leave liability, unplanned overtime rates, roster efficiency. Tens of millions in annual value was sitting on the table, mostly from payroll leakage, roster inefficiency, and reactive overtime driven by poor leave planning.
Where everyone was stuck
Two camps, both wrong.
One group wanted to procure an enterprise platform. Multiple teams had been circling this for years with various proposals to buy a new system. It felt like the obvious answer.
The other group was anchored to the existing rostering tool. The organisation had invested significant money and effort in it, and there was a strong "we're special, our needs are unique" narrative that made people reluctant to look beyond what they already had.
The trouble was, neither camp was asking the right question. The organisation hadn't mapped work demand to roster requirements across business units. It couldn't write a meaningful specification for a new system, or know whether the existing one was actually fit for purpose. The master data was incomplete: no proper role structures, no competency links, no way to connect "who can do what" to "what needs doing." And any enterprise implementation would take two years minimum, locking in design decisions based on incomplete understanding.
What I did
I pulled the key people together, got the full picture across all seven systems, and reframed the question. Not "which system do we buy?" or "how do we protect our investment?" but "what do we need to learn before we're ready to decide?"
That led to a five-year roadmap in three phases.
Years one and two: stabilise and learn
Expand the existing rostering system to the teams that had nothing. Not because it was the best tool, but because the organisation already owned it and rolling it out would deliver value immediately while teaching everyone what good rostering actually looks like. Fix the issues causing rework. Pilot digital time capture with one business unit. Start documenting the legacy pay rules. This phase delivers real value while building the organisational understanding that was missing.
Years three and four: procure with confidence
By now the organisation has 18 to 24 months of operational learning, clean data, documented requirements, and a pilot to point to. It can run a proper procurement process knowing exactly what it needs, rather than guessing.
Year five: retire the legacy
Migrate the pay rules engine, cut over to the new platform, clean up.
I built the business cases for the immediate investments, organised the resourcing for the rollout, and set the governance structure for the programme.
What this shows
The instinct to buy a new system wasn't wrong, it was premature. And the instinct to back the existing tool wasn't wrong either, it was just too narrow. The strategic value was in sequencing: getting immediate returns from existing tools, building organisational understanding, and using that learning to make the right long-term decision. It's the difference between solving a problem and buying a solution to a problem you haven't fully understood yet.