The three questions to answer before buying HCM.

Most HCM selection processes begin with a feature list. That is the first mistake. By the time a company in this segment is shopping, the platforms on any credible shortlist can all do the things a feature list captures. The differences that decide whether the purchase succeeds live somewhere else — and they can be reached with three questions, none of which a vendor demo will answer for you.

One: what is the actual shape of your workforce?

Not the headcount — the shape. A 900-person company that is single-site and salaried is a fundamentally different platform problem than a 900-person company spread across multiple states with hourly, shift-based labor and complex scheduling. The second company will live or die on time, attendance, and labor-cost visibility; the first will barely touch those modules. Platforms are not equally good at both shapes, and the mismatch does not show up until you are running real pay cycles on it.

Answer this honestly before you look at a single vendor, because it determines which capabilities are load-bearing for you and which are marketing.

In practice the shape question resolves into a handful of concrete tests. What proportion of your people are paid hourly, and are their hours predictable? Do you schedule anyone, or does everybody simply arrive at the same time each day? How many distinct pay rules — differentials, premiums, guarantees, callbacks — would you have to explain to a new payroll administrator? In how many states, and how many municipal jurisdictions, does someone physically perform work? Does anyone work under a collective bargaining agreement?

A company that answers "mostly salaried, no scheduling, three states, no unusual rules" has an HCM problem, and most credible platforms will serve it well. A company that answers "sixty percent hourly, round-the-clock coverage, eleven pay rules, five states and two local ordinances" has a workforce-management problem wearing an HCM costume — and the shortlist that suits the first company will fail the second inside one pay period.

The uncomfortable part is that most companies describe themselves as the first and turn out to be the second. Rules accumulate one exception at a time, each locally reasonable, and nobody has ever written the complete list down. Writing it down is itself most of the work of answering this question.

There is a related trap worth naming. Companies frequently scope the platform against the business they intend to become rather than the one they are. Some of that is prudent — buying for two years out avoids an early migration. But scoping for a workforce shape you do not yet have, and may never have, is how a straightforward company ends up administering an enterprise configuration it does not need. Buy for the shape you can see, with a clear view of what extending the platform would later cost.

Two: what breaks if the implementation slips?

Every platform sells the steady state — the clean, configured system a year after go-live. Almost no one sells you the transition, which is where mid-market implementations actually fail. The right question is not “can this platform do X” but “what happens to payroll, compliance, and my team’s workload during the twelve weeks it takes to get there, and who is accountable if the timeline slips?”

Implementation readiness — scoping, sequencing, and internal preparation before contracts are signed — is the single highest-leverage thing a buyer can invest in, and it is almost entirely absent from the standard selection process.

It helps to price a slip rather than fear it in the abstract. A three-month overrun costs the internal hours twice — once on the project and once on the legacy process you are still running alongside it — plus whatever the vendor charges for extended services, plus the compounding cost of a team that has now been told twice that go-live is imminent and has stopped believing it.

The failure modes are predictable enough to ask about directly. Source data turns out dirtier than discovery assumed. Configuration requests quietly cross the line into customization. Nobody internal has authority to decide, so decisions queue behind a committee. Parallel payroll gets cut from two cycles to one because the calendar tightened. Every one of those is visible in advance if somebody asks, and invisible if nobody does.

So put the question to the vendor in its uncomfortable form. What did your last three implementations of my size and shape actually look like — planned duration against delivered duration — and may I speak with one of them? A vendor willing to answer that is telling you something no scoring matrix can.

Then put the answer in the contract. Implementation scope, named delivery staff, the number of parallel payroll cycles, and what happens commercially if the date moves are all negotiable before signature and none of them are negotiable after it. The moment of maximum leverage is the moment before you sign, and almost nobody spends it on implementation terms.

Three: who owns this in year two?

A platform decision is a multi-year commitment, but the selection process treats it like a one-time purchase. The question that predicts long-run satisfaction is about ownership after go-live: who optimizes the configuration when your business changes, who catches the compliance edge cases, who is on the phone when the system underperforms its promise. If the answer is “whoever the vendor assigns,” you have bought software, not an outcome.

Ownership after go-live has three parts, and they are usually held by three different people or by nobody at all. Someone has to own the configuration as the business changes — new states, new pay rules, an acquisition. Someone has to own the data, so that the reporting keeps meaning in year three what it meant in year one. And someone has to own the relationship, which by year two is mostly a question of how quickly an escalation moves.

Ask specifically what happens at six in the morning on payroll Monday. Named representative or ticket queue. Response commitments in writing, or best effort. Whether the person who implements you stays attached to the account, or hands off at go-live to a support organization that has never seen your configuration. These answers are rarely volunteered and almost never appear on an evaluation matrix, and they are what your team will feel every week for the next five years.

Why three, and not ten

There are longer frameworks, and we have written some of them. This one stops at three because these are the questions whose answers reorder everything downstream. Get them right and the remainder of the evaluation collapses into something manageable. Get them wrong and no amount of diligence across the other forty criteria will rescue the decision.

They also share a useful property: not one of them can be answered by a vendor. They are questions about you. Which means you can work through all three before taking a single call, and arrive at the first conversation already knowing what you are looking for rather than being told.

These are the questions we work through with clients before any recommendation — and they are the reason we can offer a considered recommendation rather than a comparison. If you would rather answer them alongside someone who has already run the analysis, that is what our platform practice is for.