This time of year, many of you may be working towards projects to implement some new HR tech. If you’re a larger firm, you may have already done the financial analysis and gotten approval to go ahead with the project — you may have even started to engage some vendors or talked to some peers about what kinds of tech they use and recommendations they may have. But have you gathering your requirements — your list of “must haves” and “nice to haves” (and even things that you don’t need) for your new tech? If so (first give yourself a pat on the back), have you involved ALL the key stakeholders and gotten their input on the requirements? Any tech implementation is going to come with its challenges — there is almost always an unknown or a surprise that comes up during implementation, and that’s okay — having your tech requirements and referring to them through your project can help you stay on track and have a successful implementation.

What is Requirements Gathering and Why is it Important for HR Tech

Simply put, “requirements gathering” is a list of what you want and need for your new tool to do. It should include things like IT requirements (for example, are their systems that it must integrate with, does your company have software requirements), user requirements from all of the end users, language requirements, regional and country specific requirements — even things like branding requirements. It should also include all of your preferences, and things you don’t need or things you don’t care about.  Think of it this way, if you were going to buy a new car — would you just start looking at the dealer’s lot and buy a car or would you think about what you really need and some what things were really important (must haves or deal breakers) and what things you’re willing to budge on. If you do the former, you may find a car that you think fits your needs but then after time realize doesn’t — you missed a few things (the cup holder isn’t in the right place, or its too small, or maybe you really needed 4 doors instead of 2). Or maybe you ask your best friend what car they like and you get the same car — only to realize that it doesn’t work as well for you. Having requirements gives you a good road map of what you need to look for and why — and it also helps you lead the conversations with potential vendors, instead of the other way around. You want to tell them what you want and need… not the other way around.

Compare Your List With Other Stakeholders

If we continue with our car buying example — if you were going to buy a new car would you only use your criteria or would you consider the input and feedback of a spouse, a child, a neighbor, a sibling, a co-worker? The answer is: It depends — what is the relationship to you and to the new vehicle. Carefully think about who you is a key stakeholder and make sure to get their requirements. For HR tech, think about all the users of the system — don’t forget to think about groups who have downstream processes or rely on inputs or outputs from your system. Changes in your process and tools may impact processes and tools on their end too — which means that they may have asks and requirements to give you as you consider new tools. Not sure if you should include someone as a stakeholder or not? My recommendation is to tell them about you plans and get their feedback. Likely they will opt themselves out if they are not a true stakeholder. Getting a complete list of requirements from ALL the stakeholders you can work together to prioritize the list and agree on the “must haves” and “nice to haves.” Be patient and kind, but also strategic and realistic when prioritizing — you don’t want stakeholders feeling unappreciated if you list all of their must haves as nice to haves or even as not a requirement — so as you work through the process, seek to understand “the why” and come to consensus as a group.

Once you have a strong list of your requirements you’re ready to start talking to vendors and looking a demos. You’ll be able to look for the features that you need — and ask follow up questions on the things that you’re looking for. You want to lead the discussion, but also be open to what they want to show you — you can often pick up on new trends or features this way and its always nice to have an understanding of where the vendor and their tech is going. You may also opt to share parts of your list with the vendors in order to help keep them on task and make the best use of time by expressing to them the things that you are really interested in and want to see more of, and steering them away from things that they are really focused on telling (selling) you on that you really are not all that interested in. You many find that not every vendor can meet all your requirements — don’t get discouraged. Use your list to help narrow down the list of potential vendors based on what they are able to provide against what you need.

So… did you put the cart before the horse a bit and start looking at vendors before you had clear requirements? That’s okay — start applying the brakes on your search and speeding up working on the coming up with solid requirements and THEN go back and apply your list objectively to the vendors that you’ve already started to evaluate and see if they are still a good fit for what you need.

Your list is not static, you can always go back and change it if needed — but be thoughtful about it and gain consensus from stakeholders.

What are your thoughts on requirements gathering and using it for vendor selection?