3 Common HRMS Requirements Gathering Mistakes
Your HRMS is a big ticket item and a long term investment. The stakes are high to choose the right software for your needs! HRMS requirements gathering is a major piece of the puzzle; ensure you’re positioned for success by avoiding these common HRMS requirements gathering mistakes.
1) One-sided participation leads to incomplete requirements
If your HRMS requirements gathering involves only the inside of HR or a certain segment of HR, you’re designing a solution inside a bubble that is bound to burst. While everyone does not need an equal vote in the process, to make the best HRMS selection, you need to get an understanding of HR data usage and functionality requirements from all impacted parties. This may include core HR back office operations, HR leadership, self-service managers and employees and any outside departments where HR data is utilized, such as Finance as well as internal IT who may need to create interfaces to and from the new HRMS. It is better to ‘over ask’ for input rather than miss a crucial requirement that can derail your implementation later. Solicit feedback from the various stakeholders via meetings or surveys to understand what requirements each group sees as important for a new HRMS.
2) Allowing the vendor to lead discussions
While a vendor may have experience in rolling out their own HRMS software to companies of a similar profile, it is a fatal error to allow the vendor to drive any sort of requirements gathering via the ‘this is what our software does’ methodology. Often, it may seem easier up front to incorporate the vendor’s materials into your planning, but to get a true reading on HR requirements you need to start them internally or via an impartial third party consultant prior to matching against a vendor’s offering. Use a vendor’s materials only as a supplement to your own organization’s needs.
3) Lacking prioritization in requirements
Not all requirements are created equally, nor should they be seen as such. Too often, an HR executive will weigh in heavily on a requirement that can overshadow more pressing requirements, due to status. To mitigate this risk, create a ranking such as ‘critical/high/medium/low’ or a numerical scheme to classify your requirements to the HRMS selection team. Such a ranking forces your organization to consider its strategic direction and enables a more objective review, due to group discussion and consensus.
Featured white papers
Four HRMS selection myths that could damage your project
Misconceptions about HRMS selection that could derail your software project
Three neglected HRMS stakeholders and what they can tell you
The groups all too often left out of HRMS stakeholder analysis
Four HRMS cost benefits to help sell your project to c-level
How HRMS can cut running costs in the long term, and how to sell these benefits to senior management