Choosing the right HR software: a requirements list that actually discriminates

Writing requirements that discriminate

1. Start from three real people. The two contract case, the secondment, the person whose hours change. Every requirement that follows from modelling those three is a real requirement, and most products fail at least one.
2. Add the obligations, not the features. What you must be able to prove, to whom, and for how long. Right to work evidence, working time records, pay history. These turn into retention and access requirements, which are the ones vendors answer honestly.
3. Add the reports somebody already produces. Three reports that exist today and are used. If a product cannot produce them, either it is wrong or the reports are, and both are worth discovering now.
4. Score, do not tick. A yes or no grid rewards vendors who say yes. Score each requirement from demonstrated, to described, to absent, and record who demonstrated what.

Why an hris requirements checklist from the internet fails

Published checklists are assembled from feature lists, which means every serious product satisfies almost all of them and the exercise produces no ordering. Worse, they set an expectation of breadth that pushes buyers toward products sized for larger organisations.

Use one as a prompt for things you forgot, never as the list itself. The items that matter to you are the ones you can explain to a colleague without reading them out.

What an hris requirements template should contain

Four columns: the requirement in your own words, why it exists, how it will be tested, and the score. The second column is the one that prevents a requirement surviving into the final comparison after everybody has forgotten why it was there.

Keep it under forty rows. Longer lists are not more thorough, they are less discriminating, and the weighting becomes arbitrary once the list is long enough that nobody reads it whole.

Hris system requirements that come from outside HR

Security, identity and finance all have requirements that arrive late and can stop a purchase: single sign on, audit export, cost centre structure, retention. Collect them at the start rather than discovering them in the security review.

The usual late arrival is single sign on, which some vendors price as a premium tier. Ask about it in the first conversation, because finding out at contract stage changes the price and the comparison.

The decision note

Write half a page at the end: what was chosen, what it does badly, what was rejected and why. It takes twenty minutes and it is the only artefact that survives the people who made the decision.

It also makes the next review cheap, because the question then is whether the reasons still hold rather than whether to start again.

Common questions

How many requirements is too many?

Beyond about forty the list stops discriminating, because every serious product satisfies the common ones and the weighting of the rest becomes guesswork.

Should we run a formal tender?

Where procurement rules require it, yes. Otherwise a scored shortlist of three or four with the same tests produces a better decision faster, because the tests are live rather than written.

Who should be in the evaluation?

Whoever will operate it daily, whoever is accountable for payroll accuracy, and one line manager. A panel larger than that tends to add requirements rather than judgement.

What if no product passes?

Then a requirement is either wrong or genuinely unusual. Work out which, because an unusual requirement is an argument for a specialist product or for keeping that process outside the system entirely.

Coverage by country

• Employer of record vendors covering Singapore
• Employer of record vendors covering Mexico
• Employer of record vendors covering Spain
• Employer of record vendors covering Colombia
• Employer of record vendors covering United Kingdom
• Employer of record vendors covering France
• Employer of record vendors covering Hungary
• Employer of record vendors covering New Zealand