Why HRMS implementations fail: software before process

A business I looked at had bought HR software eighteen months earlier. It held employee records that were partly current, leave that some departments used, and an attendance module nobody had switched on. Payroll inputs were still built in a spreadsheet. The licence was being paid monthly.

Nobody had made a decision to abandon it. Each department had simply reverted to what worked when the system asked them for something it could not handle, and nobody had been made responsible for noticing.

The five ways it fails

1. 1

   The approval routes did not match reality

   The system was configured with a manager-then-HR route, while in practice the founder approves anything unusual and the site in-charge approves on the floor. The first exception broke it and people went back to chat, permanently.

2. 2

   The data was half-loaded

   Employee records migrated with gaps — missing dates of joining, three date formats, no reporting lines. Every report then disagreed with the spreadsheet, so people trusted the spreadsheet, so the system was never the source of truth.

3. 3

   Nobody owned it after go-live

   The implementation had a project owner and the running system had nobody. Questions went unanswered, small faults accumulated, and within two quarters the system had a reputation.

4. 4

   It was configured for a process nobody agreed

   The vendor asked what the leave rules were, somebody answered from the policy document, and the policy document did not describe what actually happens. The system now enforces a rule the business does not follow.

5. 5

   It went live everywhere at once

   Every module, every location, one date. When two things went wrong simultaneously nobody could tell which was causing what, and the appetite for the whole project collapsed.

What to settle before configuration

None of this is software work. All of it is decisions the business has to make, and a vendor cannot make them for you.

1. EMPLOYEE MASTER
   One list. Who is on it, what each field means, who maintains
   it. Reporting lines current. This is the foundation; every
   module references it.

2. APPROVAL ROUTES
   For each request type: who approves, up to what limit, who
   is the deputy, what happens on escalation. Written as it
   actually happens, not as the policy says.

3. CUT-OFF DATES
   Attendance closes, inputs due, register approved, payment.
   Published. The system enforces these; if they are fictional
   the system will be seen as the problem.

4. EXCEPTIONS
   The five situations that do not follow the rule. Every
   business has them. Configure for them or they will be the
   reason people leave the system.

5. OWNERSHIP AFTER GO-LIVE
   One named person, with time allocated. Not the project
   sponsor. Not 'HR' collectively.

Businesses that settle these five find configuration straightforward. Businesses that do not find configuration becomes the forum in which the decisions get made badly, under time pressure, by whoever is in the meeting.

Migration is where the credibility is won or lost

Employee data usually lives in four spreadsheets with four conventions, and everyone hopes somebody else will clean it. Nobody does, so it migrates as it is, and the first report is wrong.

Clean before you migrate, not after. Decide the mandatory fields, fix the date formats, confirm reporting lines with managers, and reconcile the headcount against payroll before loading anything. It is dull work and it decides whether people trust the system's numbers — which is the only thing that matters in month three.

Go live in a sequence

One module, one cycle, then the next. The order that works for most businesses runs employee records first, then attendance and leave, then payroll inputs, then everything else.

That sequence is not arbitrary. Records are referenced by everything; attendance and leave produce the data payroll needs; payroll input is where the benefit becomes visible to management. Performance, training and the rest can follow once the base is trusted.

Include payroll inputs in the first real cycle even if only in parallel. A pilot that stops short of payroll never tests the thing that actually has to work, and the problems it would have exposed arrive later with more at stake. Sequencing this properly is the core of HRMS implementation work rather than an afterthought to it.

The uncomfortable precondition

A system enforces whatever process you give it. Where the process is undefined — a soft cut-off, no named approver, rules that vary by manager — configuration forces those decisions to be made, and businesses often experience that as the software being rigid.

It is not rigidity. It is the first time the business has had to state what its rules are. That is why HR process consulting and implementation are usually better done together: decide the rules, run them manually for a cycle, then configure what you have proved.

If you would rather see what that looks like against your own approval routes and cut-offs than against a generic demo script, GullyHR software can be configured around your process for the demo. Book a free demo and bring last month's inputs.

How to tell, in month two, whether it is working

Do not wait for a six-month review. Three signals in the second cycle tell you almost everything.

First, is anybody still doing the old thing in parallel? A spreadsheet maintained alongside the system is not belt and braces; it is the system losing. Second, did the month close on the published cut-off, or did corrections keep arriving? Third, when something went wrong, did somebody fix it in the system or work around it?

The project owner who was never given the time

Beyond process and sequencing, there is a resourcing failure that accounts for a large share of stalled implementations and is visible from the start if anyone looks.

The project is assigned to someone already doing a full job. They are given no reduction in their existing responsibilities, because the implementation is understood as something the vendor does. When month-end arrives, or a resignation needs handling, the implementation is what gets postponed — correctly, because it has no deadline that anyone outside the project feels.

The result is a project that advances in the gaps between other work, which means it advances slowly enough that the business's attention moves on before it lands. Vendors rarely raise this, because the delay reads as a client-side issue and pushing on it is uncomfortable.

Ask for the time explicitly at the outset, as a number of days per week and a named thing that stops. If nothing can be taken away, that is a real answer and it should change the timeline rather than be absorbed silently. An implementation given two days a week for three months finishes; the same implementation given whatever is left over runs for a year and is quietly abandoned.

It is also worth agreeing in advance what would cause the project to be paused rather than pushed through. Implementations that fail rarely fail suddenly; they pass several points where stopping was the right call and nobody had the authority or the framing to suggest it. Naming those points at the start makes the decision ordinary rather than an admission that something went wrong.

Two answers out of three going the wrong way is recoverable in month two and very difficult by month six, because by then the workaround is the process. That is the point at which an HRMS implementation either takes hold or quietly becomes a licence you pay for.