The HRIS Implementation That Does Not Overrun

TL;DR

• The core decision: who settles the arguments the implementation surfaces, because that's what determines the date.
• When doing nothing is right: when the organisation is mid-restructure and the shape you'd configure is about to change.
• What has to be true: somebody internally can make decisions about process without convening a committee each time.
• How the options split: by who leads and how you phase, which are separate choices people conflate.
• Decision rule: if a decision needs three people who cannot meet this month, that's your critical path, not the build.
• Outcome to expect: a later date than the vendor proposed and a system that matches how you actually work.

The Plan That Assumed You Were Ready

The vendor's plan is well made. It has phases, a start and a go-live date, and it's been run many times before. There's a column showing what the vendor does and a column showing what you do, and the second column looks manageable when you read it.

Then week three arrives. The task is to confirm the list of employment types. Somebody produces the list from the current system and it has fourteen entries, four of which nobody recognises, two of which appear to mean the same thing, and one that exists because of an arrangement from years ago that may or may not still apply to three people.

Settling that takes a fortnight, because it needs somebody who knows the history, somebody who can decide, and a check on whether anybody is still affected. Meanwhile the next task was waiting on it.

Recommended Tools

Best tools for HRIS Software

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

That's the shape of almost every overrun in this category. The vendor's part usually runs close to plan, because they do this repeatedly and their estimates are calibrated. The customer's part runs over, and it runs over on two specific things: data that isn't in the state anybody assumed, and decisions nobody has made.

What makes it hard to anticipate is that neither is visible before you start. Data looks fine until somebody tries to load it into a system that enforces rules the spreadsheet never did. Decisions look made until somebody has to write the answer down and discovers two departments have been operating differently for years without anybody noticing.

So the honest reframe: an implementation timeline is mostly a measure of how quickly your organisation can settle arguments about how it runs. The configuration is the easy part.

When You Genuinely Do Not Need to Act Yet

Your current setup is genuinely fine. The existing arrangement works, nothing is being missed, and nobody is waiting on information they can't get. An implementation is disruptive enough that starting one without a clear problem is a substantial cost for an unclear return.

Friction is starting to show. Somebody is spending real time on manual work, or a question keeps arising that the current setup can't answer. Worth noting and worth being precise about, because the specifics become the configuration requirements later, and vague problems produce vague configurations.

It has become a real cost. The current arrangement is failing in ways that affect people: wrong data reaching payroll, records nobody can produce, a single point of failure in one person's knowledge. Now the disruption is justified.

The edge case that should make you wait. A restructure, a merger, or a leadership change that will alter reporting lines and job architecture. Implementing during one of those means configuring a shape that's about to change, and then reconfiguring it afterwards. If something significant is coming within a couple of quarters, the right answer is usually to wait, even though waiting feels like inaction.

Five Questions This Reader Asks at 11pm

How long does an HRIS implementation actually take? Longer than the proposal and the difference is almost entirely your side. Vendor estimates are calibrated on their own work, which they do repeatedly and predictably. Your work involves cleaning data nobody has looked at properly and settling decisions nobody has needed to settle. The useful planning move is to take the vendor's timeline for their tasks and estimate yours independently rather than accepting a single combined number.

Why do implementations overrun? Two causes account for most of it. Data isn't in the state anybody assumed, because the old system tolerated inconsistencies a new one will reject. And decisions surface that nobody has made: what counts as an employment type, who approves what, what happens in a case that occurs twice a year. Neither is visible before you start, which is why the estimate is always optimistic rather than sometimes.

Should we phase it or go all at once? They solve different problems and you can do both, which people miss because the question gets asked as a binary. Phasing by module reduces the amount you have to get right at once. Phasing by population lets you find problems on a small group first. A hard cutover is simplest to reason about and carries the most risk on the day. The right answer depends on whether your bigger worry is complexity or exposure.

Who should lead it? Somebody internal with authority to make decisions, whatever else you buy. A vendor or partner can run the method, the configuration and the mechanics, and none of them can decide that your organisation will standardise on one approval route. Implementations stall waiting for internal decisions far more often than for external work, so the leadership question is really about who can settle an argument this week.

What do we do about historic records? Decide early, because it affects everything downstream. Bringing across full history is expensive and sometimes necessary. Bringing current state only is faster and resets every trend line you had. Keeping the old system readable is the middle path and it has its own cost. There's also a question about what you're obliged to retain, which differs by jurisdiction and by record type, so establish that locally before choosing.

What Actually Consumes the Timeline

Estimating this properly is mostly a matter of knowing where the time goes. It isn't where the plan suggests.

The second and third rows are the ones that surprise people, because they don't look like work. They look like confirming something that already exists. What actually happens is that writing the rule down reveals it was never agreed, and the conversation to settle it involves people whose calendars don't intersect easily.

The seventh row is where teams under time pressure cut, and it's the worst available saving. Testing with tidy sample data proves the configuration works for cases that were never going to be difficult. The value is entirely in running your genuinely awkward records through it: the person with two positions, the one who left and came back, the contract type that doesn't quite fit. Those are the cases that generate support requests in month one.

Five Diagnostic Questions You Can Self-Assess Against

Who can make a decision without convening anybody? Name them. If every question about process needs three people in a room, your critical path is calendar availability rather than any technical work, and no amount of vendor resource changes that.

Have you looked at your data properly? Not at a summary. Open it and look for the inconsistencies: duplicate people, missing dates, employment types nobody recognises, reporting lines pointing at people who've left. Doing this before the project starts converts a mid-project crisis into preparatory work you controlled the timing of.

Is anything structural changing in the next two quarters? A restructure, a merger, a leadership change that will alter reporting lines. If so, you're configuring a shape that's about to move, and the reconfiguration will cost more than the wait would have.

Who is doing this alongside their normal job? Usually everybody, and usually nobody has reduced the normal job. That's the most common reason internal tasks slip, and it's entirely predictable at the start. Either reduce something or extend the timeline honestly.

What have you decided about history? If the answer is that you'll work it out during migration, you'll work it out under time pressure with the wrong people available. Decide early, because it changes the scope of the data work substantially.

Six Ways Implementations Are Run, Reviewed

Vendor led with a fixed methodology

The vendor runs the project using their standard approach. It earns its place on predictability: they've done it many times, the sequence is sound, and the estimate for their portion is usually reliable. For a straightforward configuration it's frequently the fastest route.

Where it falls short is that the methodology assumes a customer who is ready. It has a step where you confirm your job structure, and it allows a week, because for most customers that's a confirmation. If yours turns out to be a genuine argument, the plan has no slack for it and the date moves.

Fine if your decisions are already made. Before committing, look at the customer column honestly and ask whether each task is a confirmation or a decision.

Ask the vendor a direct question too, because a good answer is genuinely informative: which customer task do their projects most often stall on. Anybody experienced will answer immediately and specifically, usually naming data or job structure, and their answer tells you where their methodology has the least slack. A vendor who says their projects run to plan is describing a sales position rather than an implementation history.

Partner or implementer led

A third party configures and manages the project. It earns its place where the product is complex enough that expertise genuinely matters, and where an experienced implementer has seen your situation before and can tell you what usually goes wrong.

Where it falls short is the seam. You now have three parties, and questions can fall between the partner and the vendor, particularly anything touching product limitations. Quality also varies more than with a vendor's own team, and the person who sold you the engagement may not be the person who does it.

Ask who specifically will do the work and what happens when something turns out to be a product issue rather than a configuration one.

It is also worth establishing early who owns the relationship if the two disagree. Partners occasionally recommend configuration workarounds for things the product does not do well, which is pragmatic and leaves you maintaining complexity that the vendor did not design for and will not support. Knowing in advance whether you or the partner raises product limitations directly with the vendor prevents a category of stalled conversation.

Internally led with vendor support

You run the project, the vendor supports and advises. It earns its place because internal knowledge is what the project actually needs: who knows why an arrangement exists, who can decide, who will notice a configuration that doesn't match reality.

Where it falls short is capacity and experience. The internal lead is doing this alongside their job, hasn't done it before, and doesn't know which shortcuts are safe. The result is a project that makes good decisions slowly, which is better than the reverse and still late.

Viable if you genuinely free somebody up. Not viable as an addition to a full workload, which is how it's usually attempted.

The honest test is whether somebody else has picked up named responsibilities, not whether the lead has been told to prioritise the project. Being told to prioritise means doing both and dropping whatever nobody chases, which is usually the project in the weeks when operational work is loudest. Moving two or three specific duties to somebody else is a real reduction and is visible to everybody, which also protects the lead from being blamed for the slip.

A phased rollout by module

Core record first, then additional capability over subsequent phases. It earns its place because it reduces how much has to be right simultaneously, and because the first phase teaches you things that improve the later ones.

Where it falls short is the extended period of running two arrangements. People work partly in the new system and partly in the old, which is confusing, and the temporary bridges between them tend to outlive their phase. Momentum also decays: later phases compete with whatever has become urgent since.

Good for complexity. Keep the phases close together and write down what the temporary arrangements are, so they can be removed rather than becoming permanent.

Give each temporary arrangement an owner and an expected end, in the same note. Bridges between old and new systems are built quickly under pressure, nobody documents them, and a year later somebody finds a scheduled job moving data between two places for reasons no one can reconstruct. The note costs a few lines and is the only thing that makes removal safe later.

A phased rollout by population

One group first, then the rest. It earns its place as the best way to find problems at a survivable scale, because the first group surfaces the configuration errors, the missing training and the awkward cases with far less exposure.

Where it falls short is that the first group has to be representative. Choosing an easy team because they're cooperative means you learn that the system works for straightforward cases, which was never in doubt. It also duplicates effort for a period, since both arrangements need supporting.

Choose a group with real complexity in it, and tell them plainly what they're doing and why. People are generally willing when they understand the role.

Build in a way to collect what they find, because otherwise the learning stays with individuals and never reaches the configuration. A named person collecting issues for the first fortnight, with an obvious route for reporting them, turns a pilot group into the thing it is supposed to be. Without that, the first population simply experiences the problems and works around them quietly, and the second population meets the same ones.

A hard cutover on a single date

Everything moves at once. It earns its place on simplicity: one set of rules, one place to work, no confusing intermediate state and no temporary bridges to remove later. For a straightforward organisation it's frequently the right call and the fastest overall.

Where it falls short is concentration of risk. Everything that was going to go wrong goes wrong in the same week, and the team absorbing it is the one that just spent months preparing. Rollback is also largely theoretical: once payroll has run from the new system, going back is not a real option.

Do it if the configuration is simple and the team has capacity that week. Don't do it across a period when something else significant is happening.

Check the calendar properly before fixing the date, and further ahead than feels necessary. Payroll cycles, period ends, peak hiring, holiday periods and anything with an external deadline all compete for exactly the people who need to be available. The week that looks quiet six months out is usually quiet because nobody has scheduled anything into it yet.

The Decision Table

The fourth row is the one that determines most timelines and the one least often addressed at the start. If decisions are genuinely unmade, the project's pace is set by how fast your organisation settles arguments, and that's a function of who can decide rather than who can build. Naming somebody with authority before you begin is the single highest-value preparation available.

The second row is worth defending even when it's unpopular. Waiting looks like inaction and the alternative is configuring a job structure that will be redrawn in two quarters, then paying to redo it. Using the waiting period for data cleaning converts the delay into preparation.

The Decisions Nobody Has Made Yet

This is the part worth reading before the project starts, because these questions arrive as tasks in week three and each one can take a fortnight.

What is an employment type, and how many do we have? Most organisations discover their list has accumulated, contains duplicates, and includes categories that exist because of a single historical arrangement. Rationalising it means deciding which are genuinely different and what happens to anybody currently sitting in one you're removing.

What is a position, and is it separate from a person? Systems generally model a position as a thing that exists independently, which somebody occupies. Many organisations have never thought this way, and it matters for vacancies, for somebody holding two roles, and for whether a departing person's position persists.

Who approves what, and what happens when they're away? The current answer is usually that people work it out. A system requires a rule, including for absence, and writing it down reveals that two departments have been doing it differently.

When does a change take effect? Systems want effective dates. Organisations frequently operate on when somebody got round to updating the record. Deciding that changes are dated from when they actually happen rather than when they were entered is a small decision with large consequences for every report.

What counts as a leaver, and when? Last working day, contractual end date, or the point at which access is removed. These differ and they affect counts, access and payroll instructions.

What do we do about the exceptions? Every organisation has a handful of arrangements that don't fit any standard model. The decision is whether to configure for them, handle them manually, or end them. All three are legitimate and the default, which is to configure around them, adds permanent complexity for a small number of cases.

None of these is a technology question. They're all questions about how the organisation runs that nobody has needed to answer precisely, and the implementation is simply the thing that forces the precision. Answering them before the project starts converts your critical path from calendar availability into actual work.

There is a benefit to answering them that survives even if the purchase never happens. Each one is a genuine gap in how the organisation is described, and closing it improves things immediately: approval routes people can point at, an employment type list that means something, changes dated from when they occurred. Teams that work through these and then decide to wait a year on the software are usually better off than when they started.

Where Implementations Go Wrong

The first row is the most preventable failure in this list. The vendor's plan is honest about what you have to do; the trap is that a line saying confirm employment types reads like an administrative step. Going through the customer column before signing and marking each item as either a confirmation or a decision takes an hour and reprices the whole timeline.

The fourth row costs the most in the first month after go-live. Every organisation has records that break assumptions, and testing with clean data guarantees you meet them in production, with real people affected and the project team already stood down.

What to Put in Writing

The second row is the cheapest planning exercise available here and almost nobody does it. Take the vendor's plan, read only your column, and mark every line as either something you can confirm from existing documentation or something that requires a decision. The count of decisions, multiplied by how long your organisation takes to settle one, is a better timeline estimate than the proposal.

Questions to Ask Before You Commit

On decisions. Who can settle a process argument this week? A bad answer is a committee.

On data. Has anybody actually looked at it? A bad answer is that it's clean.

On capacity. What has been taken off the internal lead? A bad answer is nothing.

On the plan. Which customer tasks are decisions? A bad answer is that they're confirmations.

On testing. Will we test with our awkward records? A bad answer is sample data.

On timing. Is anything structural changing soon? A bad answer is probably not.

On stalling. Which customer task do your projects usually stall on? A bad answer is that they run to plan.

What Getting This Wrong Costs

The first cost is the overrun itself, which is more expensive than the extra weeks suggest. An implementation running long consumes the attention of the people who run HR operations, and that attention is not available for the ordinary work, so a backlog accumulates behind the project and has to be cleared afterwards by the same exhausted team.

The second cost is configuration that encodes a decision nobody meant to make. When a question arrives in week three and the date is under pressure, somebody chooses quickly so the project can move. That choice then becomes how the organisation works, because unpicking it later means reconfiguring and retraining. Decisions made to protect a timeline outlive the timeline by years.

The third cost is trust in the system, which is set in the first month and is hard to reverse. If go-live produces visible errors, managers who were sceptical conclude they were right, and adoption suffers permanently. Most of those first-month errors come from the same source: awkward records that were never tested, meeting the configuration for the first time in production.

The fourth cost lands on the people who ran the project. An overrun consumes evenings and goodwill, and the team that absorbed it is the same team expected to support the new system afterwards, at precisely the point when questions peak. Teams finish these projects depleted far more often than anybody plans for, and the effect on the months after go-live is rarely counted as part of the cost.

So before signing anything, do three things. Name somebody who can decide without convening a meeting. Open your data and look at it properly. And go through the vendor's plan marking which of your tasks are genuine decisions rather than confirmations. Those three will tell you more about your real timeline than any proposal.

When You Are Ready to Go Further

None of this needs to wait for a vendor. The data cleaning, the decisions about employment types and approval routes, and the question of what history matters can all be done before anybody signs anything, and doing them early removes most of what causes overruns.

There's a version of this worth considering even if you're not buying yet. Work through the decisions listed above and write down the answers. Some organisations discover that half their problem was undecided process rather than missing software, which is a useful and cheap thing to learn. The rest arrive at an implementation with the hard part already done.

Then, when the project does start, protect the testing. It's the phase that gets compressed when dates slip, and it's the one whose absence is felt by real people in the first month. Run your worst records through, not your tidiest ones.

And plan for the month after go-live as part of the project rather than as a return to normal. Questions peak precisely when the team is most tired, so keeping some capacity reserved past the date, rather than releasing everybody the moment the system is live, is what determines whether the first weeks build confidence or spend it.

HROpsLab publishes independent comparison work across HR tooling, applicant tracking and payroll. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is looking at what your current tooling actually supports here, our comparison work is one place to start.

Frequently Asked Questions

The vendor's plan is honest. It just assumes you already agree with yourselves.

Settle the arguments first and the date takes care of itself.