Why do HCM and HRIS implementations fail, and what is the evidence?

General information, not legal, tax or accounting advice. This page separates what we could verify from what is merely repeated, and it states which parts are BRG’s own practice experience rather than measured data.

What we could verify about failure rates

The most-quoted figure we found is on Josh Bersin’s own HCM Excellence research page (retrieved 15 Oct 2026), which says: “our research shows many HCM implementations fall short of expectations. Cost overruns are common, milestones are missed, and two out of five projects are categorized as failures.” The page does not give a sample size, a respondent profile, a date, or a definition of “failure,” and it does not name the underlying study. We therefore treat it as a directional statement from an industry analyst, not as a measured rate we can apply to a particular employer.

Other percentages are repeated across vendor and consultant blogs, including figures on how many projects met their goals or budget and ranges attributed to a research firm. We could not retrieve the original report for any of them, and several are quoted through a vendor’s marketing page. We have not repeated them. If a vendor quotes you one in a sales process, ask for the original document, its sample, its date and its definition of success, because an unsourced percentage cannot be tested.

Why a single failure rate is not the useful question

Even a well-sourced rate would blend very different projects: a ten-person payroll swap, a multi-country suite rollout and a mid-market consolidation share a label but not a risk profile. “Failure” can mean a missed date, a budget overrun, incorrect pay at go-live or low adoption a year later. For a buyer deciding how to prepare, the more useful question is which specific failures recur and when each one becomes visible.

The five failures BRG sees, and when each surfaces

The following is BRG’s own advisory experience, as set out on its migration risks and implementation readiness pages. It is practice experience, not a measured study, and the timings are typical rather than guaranteed.

First, source data is worse than anyone admitted: duplicate employee records, terminated staff still marked active, inconsistent job codes, pay elements nobody can explain. Every timeline assumes clean data. This typically surfaces when data loading begins, around weeks four to six, and is prevented by auditing an export before a date is committed.

Second, configuration becomes customization. Each product does some things natively and can be made to do others, and the second category carries permanent cost in upgrade friction and brittle integrations. Much of what pushes a company across that line is policy nobody would defend if asked. It surfaces in configuration workshops and is prevented by auditing your own rules first.

Third, nobody internal can decide. Implementations generate a steady stream of decisions, and when they route through a committee the queue becomes the critical path. No single delay looks like a problem, which is what makes it dangerous. It is prevented by naming one person with authority and protected calendar time before kickoff.

Fourth, the parallel payroll gets cut. Running old and new payrolls side by side for at least two full cycles, reconciled including taxes, garnishments and every deduction, is the practical proof that the configuration is right, and it is the last item before go-live and so the one a tight calendar eats. This is the failure that shows up as incorrect pay in front of employees. BRG’s position is to fix the cycle count in the contract so that cutting it is a commercial conversation.

Fifth, the change was announced rather than managed. Managers and employees meet the system through a launch email, adoption stalls, shadow spreadsheets survive, and the reporting the platform was bought for is built on data nobody is entering properly. This tends to appear months after go-live, framed as the system not doing what was promised.

Timelines: what we can and cannot say

BRG’s published planning range for a mid-market employer is three to six months from contract to a stable go-live, with the variance coming mostly from data quality, pay-rule complexity and how quickly internal decisions get made. That is BRG’s own planning guidance from its engagements, not an industry benchmark, and we did not find an independently verified benchmark to compare it with. Treat any fixed duration quoted before someone has seen your data as an assumption.

What to do with this before you sign

Readiness work is typically two to four weeks and can run alongside the tail of vendor selection: audit the source data, review which of your policies are load-bearing, name the internal owner, write the parallel-cycle count into the contract, and plan training and the retirement of the old process. See HCM selection criteria for what to evaluate and HCM cost for how the commercial side interacts with delay.

What we could not confirm

We could not retrieve the original of the report commissioned by a consulting and services firm from Josh Bersin’s company, so we cannot confirm its sample, wording or the percentages quoted from it elsewhere. We did not find an original, retrievable analyst source for the percentage ranges attributed to Gartner that circulate in vendor content. We did not find a stated methodology for the “two out of five” sentence. We have no independent data on failure rates by company size, platform or industry, and none on the cost of a failed implementation. The five failure modes and the three-to-six-month range are BRG’s experience and have not been validated by a controlled study.