HR leaders: is the performance module inside your HRMS or HCM enough?

What this is, and what it is not

You are not grading any product here. You are stating what your appraisal cycle cannot run without, and the sheet then shows which of those requirements each option carries. That order matters: most software decisions go wrong because the requirement gets written after the demo, which means it gets written around whatever the demo showed.

Who fills it in, who reviews it

One person marks it — whoever actually runs the cycle, usually the HRBP or HR Ops lead rather than the CHRO. They know which capabilities are load bearing and which have never been switched on. The HR head reviews the output, not the input: fifteen minutes on the result is worth more than an hour on the rows. Budget about twenty minutes for all nine categories.

How to mark each row

Mark against the cycle you will actually run in FY 2026-27, not the one you aspire to.

Two errors distort the result. Marking everything Must have — if everything is critical then nothing is, and the output stops being usable in a management conversation. And marking something Not needed because your current system does it badly — the question is whether the capability matters, not whether you like today's version of it.

Reading the four numbers

• Must-have capabilities — the size of your actual requirement. Under 15 and you are a light user with real flexibility. Over 30 and you are running a serious performance function, whether or not the business calls it that.
• Not covered — must-haves a bundled module typically does not do at all. Each one becomes a spreadsheet, an email thread, or a thing that stops happening.
• Covered only partly — the quiet cost. Nothing fails visibly; work simply returns to HR every cycle and never gets logged anywhere.
• Covered by PRO — where a purpose-built system goes beyond both, so the comparison is three-way rather than two-way.

Decision guidance

Use your gap count — not covered plus covered only partly — against your must-have count.

Taking it to management

Bring three things and nothing else: the printed gap list with your organisation's name on it, generated from your own answers rather than a vendor's deck; the effort estimate in HR hours per cycle, because management will engage with a number and will not engage with a feature list; and the shortlist you want to evaluate, so the conversation is about a decision rather than about software in general.

Expect one question above all others. "Why can't we just use the module in our HRMS?" — because the module saves an invoice line, and the real question is whether it costs more in HR effort than it saves in licence fee. Your gap count is that answer.

What to ask every vendor, in writing

A demo shows a product at its best. A written answer is the only thing you can hold a vendor to at the next renewal — ours included.

1. Each row you marked Must have: supported today, on the roadmap, or not planned — and ask for roadmap items to carry a version or a quarter.
2. Whether the exceptions work, not only the happy path: skip-levels, multiple reviewers, appeals, and a separate blue-collar cycle if you run one.
3. How you get your own data out — goals, ratings, comments and history, in what format, on request, at any time.
4. Who is accountable for running the cycle in year one, your team or theirs, and what it costs if it is theirs.
5. Whether performance support is a dedicated team or shared with payroll and leave, and what happens in cycle-close week when every manager calls at once.

Keep the replies. They are your evidence at the next review, and they turn a vendor conversation into a documented decision.