HR Systems: Case Studies & Results

An Irish semi-state body needed a new HRIS with integrated Time & Attendance, and — as a public body — had to select it through a full EU public procurement: a published tender on eTenders, run to the letter, in a way that would withstand scrutiny from every unsuccessful bidder and any later audit. The added complication was the requirement itself. The organisation ran both national and international operations, so the system had to work across multiple jurisdictions — a genuinely different problem from a single-country HRIS, and exactly the kind of requirement that looks minor in a demo and becomes a crisis in implementation. Get the selection wrong and it isn't just a bad buy: it's a challengeable award, and a system that fails the international staff the day it goes live.

I ran it start to finish. I scoped the market and carried out preliminary market consultation to understand who could realistically deliver, then mapped the organisation's actual processes and wrote the requirements specification myself — so the tender rested on what the organisation genuinely needed, not a vendor-supplied template. I designed the weighted scoring model — functional fit, technical, commercial, implementation and support — and built the published RFT around it. The tender drew fifteen vendor responses, which I then took through a compliant evaluation: chairing an evaluation panel to a documented consensus rather than one person's marks, with structured, scored demos feeding in as a weighted component. Through evaluation I supported the contract negotiations on the commercial side once a recommended supplier emerged (the body's procurement function ran the formal award), and I stayed on afterwards as a fractional client-side project manager, steering the implementation through to go-live against the very requirements I'd written.

The moment that mattered: several vendors who looked strongest on paper — polished, well-known, impressive in the room — were built for a domestic Irish deployment. Because the requirements were written from the real international operation and the scoring was weighted to test it properly, the evaluation exposed what a surface comparison never would: those vendors couldn't actually handle the multi-jurisdiction reality. The gap surfaced during scoring, where it was a mark on a page — not during implementation, where it would have been a very expensive failure.

A defensible, fully documented EU procurement, from market consultation to award and on into delivery — with the system chosen on evidence against real requirements, not on demo polish or brand recognition. The organisation got a system that genuinely fit its national-and-international operation, an award that could stand up to challenge, and continuity from the person who wrote the requirements right through to go-live.

A public tender has to do two things at once: pick the right system, and be run so rigorously that the process itself is unimpeachable. Most of the risk hides between those two — in requirements that are too vague to distinguish the right vendor from the impressive one, and in scoring that rewards presentation over fit. Getting both right takes someone who has written the requirements, designed the scoring, sat on the evaluation, and then lived with the result through implementation. That end-to-end line of sight — with no vendor to favour — is the difference between a selection that survives contact with reality and one that doesn't.

A high-turnover public-sector organisation was procuring a new payroll and workforce system. The vendor's standard fee model priced on total active employees on the payroll record. For this workforce, that figure was wildly misleading: 2,719 unique people were paid across the year, but only around 1,094 payslips were issued in an average period. As drafted, the contract would have licensed — and charged — against the inflated 2,700+ number, locked for a three-year term.

I reviewed the commercial model against how the organisation actually pays people, and rewrote the licensing definition to price on average employees paid per period: verified annually from a processed-payslips report, zero-value cessation runs excluded, divided by the standard periods per frequency, rounded up, and locked for the term.

Licensing settled at roughly 1,100 rather than 2,700+ — tens of thousands of euro saved every year, across the full three-year term. The vendor had priced per employee for any part of the year; I pointed out how much of this workforce was short-term, and that the model should reflect the people actually being paid in each period. They had room to move to win the business, and did. The day rate came down as well. Not through pressure — through knowledge. Buyers rarely realise how much is negotiable, because they've never sat on the selling side. I have. I know where the give is, and I ask for it on your behalf.

The evaluation had taken months; the contract was days from signing, and the commercial detail still hadn't been read line by line. Closing that gap before signature is the work.

An organisation was decommissioning a legacy HR system that held fifteen years of employee history — contracts, letters, forms and documents, much of it stored inside the database where the front end couldn't reach it. Over 100,000 files, effectively locked in.

The old vendor had little interest in helping get the data out. The new vendor didn't want to take responsibility for migrating it and suggested simply leaving it behind. That's the gap where employee history quietly disappears during a system switch — and 'exclude it' wasn't the right answer. The old system had to be retired, the fifteen years preserved and archived, and specific content carried forward into the organisation's new SAP platform. Every part of it was sensitive employee data — which ruled out the obvious shortcut of putting it through an online AI tool.

Rather than run the data through AI, I used AI to build the tools — small programs that ran entirely inside the client's own environment, across several strands of the job:

• Extraction and archiving. Recovered the fifteen years of stored documents out of the legacy database, rebuilt the archive into one clear folder per employee, then secured it — encrypting the files, packaging per employee, and verifying every archive before anything was handed over.
• Making the data viewable. Turned a sprawling, cryptic Excel extract — hundreds of columns, essay-length free text buried in individual fields — into clean, readable Word documents, one per employee.
• Loading into SAP. Took hundreds of separate job descriptions, held inconsistently across Word and PDF, and transformed them into structured XML for import into SAP.

Throughout, the discipline was the same: nothing was uploaded, nothing was shared. The AI only ever saw the structure — column names, file formats — never a single employee record. Neither did I.

The old system was retired cleanly. Over 100,000 documents spanning fifteen years were recovered, secured and archived in a form the organisation could actually use, and the job descriptions were loaded into SAP as structured data. Built and tested quickly, the tools run in minutes and are reusable across every table in the extract. The entire engagement stayed inside the client's four walls, start to finish.

Data migration isn't finished when the data leaves the old system — it's finished when it's delivered: safely, verifiably, and in a form people can use. Doing that at this scale without the sensitive data ever leaving the client's environment, or reaching the consultant, isn't a policy document. It's a working method — data minimisation in practice.

A large multi-entity organisation was running a cloud-hosted HR and Time & Attendance system — an older platform on a SQL back end — across several operating companies. Leaver records had accumulated for as long as twenty years, holding personal data decades beyond any lawful retention period: a clear storage-limitation and data-minimisation exposure under GDPR. The obvious fix, deleting leavers through the application front end, was painfully slow and completely opaque — nobody could say what a single 'delete' actually touched across the database. And no documented, repeatable method existed for purging leavers safely at volume.

No blind deletes. The principle was simple: map everything a deletion touches before touching anything.

• Schema discovery. I identified every table where leaver personal data and its dependent records lived — clocking and time data, audit trails, authorisation and access records, and the related tables around them.
• Dependency mapping. I worked out the referential relationships and the correct delete order, so nothing orphaned or broke downstream.
• Test-first. I wrote and validated the SQL against a controlled sample before it went anywhere near volume.
• Controlled execution. I ran the purge in verified batches, checking record counts at every stage and keeping an audit record of exactly what was removed.

The one that mattered most: front-end deletes were mysteriously slow, and I root-caused it to an undocumented database trigger tied to a background service — firing on every delete, covered in neither the client's knowledge nor the system's documentation. Identifying it explained the slowness and let the purge be re-engineered to run cleanly and at speed.

Around 9,000 leaver records — some going back twenty years — were purged safely across multiple group databases, using a documented, repeatable method that's reusable for every future retention cycle. The organisation's retention exposure was materially reduced, and it can now evidence lawful, controlled purging: what was removed, when, and that nothing else broke. Once the trigger behaviour was understood and handled, the whole purge ran in a fraction of the original time.

Most deletion goes the wrong way round — delete first, find out what broke afterwards. Doing it properly means the opposite: map everything a deletion touches, then delete with confidence. That's storage limitation and data minimisation applied in practice, not written into a policy — and it's the kind of hands-on data governance that only comes from being technical as well as advisory.

A large multi-entity group ran several distinct payroll cycles across its operating companies — a mix of monthly and weekly runs, salaried and store-based populations. Every pay period, payroll files had to move from the group's Time & Attendance system to a separate, secure payroll platform, on a strict schedule, across five different pay streams. The existing routine was manual: generate the export, find the file, transfer it by hand — repetitive, time-sensitive, and exposed to human error on exactly the days when payroll couldn't slip. And because payroll is sensitive personal and financial data, every transfer had to be secure and leave a clean archive trail for audit and re-runs.

I mapped each of the five pay streams end to end — source export, local staging, secure transfer, archive — and built one standard, repeatable automation pattern applied identically across all five, so every stream behaves the same way and stays easy to maintain. Each run generates the export from the source system, stages it locally, timestamps and archives a copy, transfers it securely to the destination — landing both in the live processing folder and in a permanent archive on the secure endpoint — then cleans up the local copy. The whole chain runs unattended on a schedule, with no manual step on a normal day.

Security was handled properly, by design rather than bolted on:

• Key-based authentication — a generated key pair with the private key held only on the source machine, not stored passwords.
• Host-key verification — the destination server's fingerprint is checked before any live data flows, with a mismatch treated as a hard stop. The automation cannot silently transfer sensitive payroll data to an impostor endpoint.
• Encrypted in transit — payroll data never moves in the clear.

And it was built to be operated: identical logic per stream, the permanent archive held on the secure endpoint, and failures surfaced for intervention rather than hidden — the kind of job you need to be able to reason about at 2am.

Five payroll streams now deliver automatically, securely and on schedule, with no manual file handling on a normal cycle. The pattern is consistent and documented, simple to extend to further streams or destinations, and every file sent leaves a permanent, timestamped archive — full re-run and audit capability. The manual, error-prone routine is gone.

Payroll deadlines don't move, and the data is about as sensitive as it gets — so ad-hoc manual handling is both a reliability risk and a security one, multiplied across five parallel streams every pay period. The best automation is the kind nobody has to think about: it runs on time, every cycle, and leaves a clean trail behind it. Building that — the secure plumbing under payroll, not just the strategy above it — is hands-on integration work, and it's the kind PPM Prime delivers.

A large public-sector organisation was running a multi-strand HR systems programme — migrating organisational and employee data into a modern workforce-management platform, while also aligning to a national SAP-based staff records and pay programme. Employee org structure — who sits where, reporting into what — had to be prepared for both target systems at once, and each had different rules: one platform with hard limits on custom structure fields, the other a more demanding SAP-based system. Internally, the structure existed in several conflicting forms — a manually maintained spreadsheet, the IT directory, a vendor's sample template — none of which agreed, with no single source of truth. Meetings were going in circles: HR, IT and the implementation partner each held a piece of the picture, and were effectively talking past each other.

I named the real problem first: this wasn't a data problem, it was a single-source-of-truth problem. Before anyone built anything, I got the group to agree which source would be authoritative. Then I set the sequencing: build the structure to the more demanding system's standard first and pare it back for the simpler one — rather than building it twice and reconciling later. To de-risk the build, instead of constructing the whole file and hoping, I had the data stripped down to only the fields that define org placement, duplicates removed to expose the true unique structure, and a single validated sample row sent to the implementation partner to confirm the shape before building the rest. And I distilled a long, circular discussion into the two questions the group actually needed answered — can the target platform accept the directory's structure, and which structure fields does the SAP-based system genuinely need — so the meeting ended in decisions rather than more debate. The data-protection consideration I raised early, and made sure the right people were looped in, without letting it derail the working session.

A confused, multi-source org-structure problem became an agreed source of truth and a clear, sequenced, low-risk build plan. The team left with concrete next actions and a validate-one-row-first method that removed the risk of building the whole file wrong. Effort and divergence risk were both cut by building once, to the harder standard, rather than twice.

Org structure is the backbone of an HRIS — get it wrong at migration and everything built on top, reporting lines, approvals, leave, access, inherits the error. But the real value here wasn't in a file. It was in turning a stalled room into decisions: translating between HR, IT and the vendor when they were talking past each other, and finding the cleanest path to a correct migration with no vendor axe to grind. That's the bridge — and it's often the thing a complex programme needs most and has least.

A public-sector body was running a live Time & Attendance system with a small in-house team. Its single riskiest annual task — rolling every employee's leave balance over at year-end — had to be done correctly, and the team wasn't confident doing it unsupported. Get it wrong and every employee's leave entitlement for the year starts from a bad number: a highly visible, morale-affecting error. Alongside it, day-to-day controls needed tightening — employees could self-modify records they shouldn't be able to — and routine admin, adding a new supervisor, setting up user accounts, needed to be understood and repeatable in-house. The system also carried non-obvious local quirks — specific formatting conventions and custom triggers — that a generic 'read the manual' approach would miss entirely.

The point wasn't to complete the task — it was to leave the team able to do it themselves. So I did it with them, on the live system, not behind closed doors. The year-end rollover was run as a deliberate, backup-before-you-touch-anything process, modelled explicitly so the team would adopt the same habit: any misstep was recoverable, every time. I tightened the controls, removing the ability for employees to self-modify records where that shouldn't be permitted and closing a data-integrity gap. I set up new supervisor and user accounts step by step, leaving a process the team could repeat unaided — including the local quirks that aren't in any standard documentation. And all of it worked with the organisation's actual configuration and its non-standard leave cycle, rather than a textbook default.

The highest-risk annual process was completed safely — with the in-house team having done it hands-on, and able to repeat it the next year without holding their breath. Controls were tighter, an integrity gap closed. The team could now run routine administration itself, cutting vendor dependency, cost and turnaround time. And the system's local quirks were transferred to the people who actually operate it day to day.

The highest-risk processes are exactly the ones done once a year, under pressure, by someone who last did them twelve months ago — the classic recipe for error. And over-reliance on the vendor for every routine change is slow, expensive and fragile. Sustainable ownership only happens when the in-house team can do these things themselves, safely. That's the aim I work to: the client ends up more capable, not more dependent on me. Go-live isn't the finish line — the system sticking is.