Prioritizing your requirements when comparing HRMS

For an HRMS, as with any purchase, if you don’t really know what you want, you won’t know what you’re getting. And in this scenario, what you get is highly unlikely to be what you need. Hence the need for a carefully identified set of clear requirements that address the following:

• Organizational context – your current business priorities, future strategy (expansion, diversification, consolidation, acquisition, etc), current performance measures (KPIs), existing HR processes and policies.
• Functional requirements – what do you want the system to do? Clue: the requirements will differ depending on which stakeholder you ask (C-suite and executives, HR leadership, managers, and employees, operational HR staff, or specialist staff).
• Technical requirements – basic but essential specifications, including number of records, number of users, deployment (cloud, on-premises, or hybrid), language and currency requirements, regulatory and compliance issues, mobile access, the need to integrate with other software and systems.

How to weight different requirements when selecting or comparing HRMS

Your requirements are essentially the selection criteria for your HRMS and should be communicated openly to vendors as part of the RFP or invitation to tender, and the demo process. Otherwise, you’re effectively inviting someone to apply for a job without telling them anything more than the job title (responsibilities, accountabilities, entitlements – all left to guesswork).

Use our HRMS requirements guide (and feature list) during your HRMS selection project

Having identified your HRMS requirements, it helps to organize them under category headings. Those headings should fit your business but a generic list looks like this:

• The system – the functional and technical requirements.
• Support packages – updates, patches, upgrades, helpdesk, consultancy, etc.
• The vendor – is the vendor stable enough for the length of relationship you’re expecting?
• References – satisfied past customers or other endorsements.

The criteria from the first two categories are the most straightforward to assess in a demo situation. They can be weighted (if necessary) and then scored according to performance against a standard checklist of your criteria. If any criteria are of particular value to your business (for example, you absolutely must overhaul your time and attendance monitoring…)  then that criteria can be weighted, attracting double or triple points like some of the squares on a Scrabble board.

As for the points and scoring, a simple rating scale that can be used by your demo team to objectively evaluate each offering is:

0 = does not meet requirements

1 = partially meets requirements

2 = fully meets requirements

3 = exceeds requirements.

This system will usually give you a clear ‘winner’; i.e. the best HRMS available for your needs. However…

Factors to consider when weighing up two like-for-like HRMS systems

Occasionally, it happens that two different systems result in the same score using the above evaluation system. In such cases, a more discussion-based approach can be taken to deciding between the two. You’ve already assessed the technical and functional requirements and now other factors may provide a tipping point, such as:

• Implementation timescale
• The stability of the vendor’s business
• System scalability
• Pricing model and overall cost
• References (preferably from businesses similar to your own)