Requirements gathering is not a new phrase in corporate vernacular. In fact, if you have had anything to do with a systems implementation in the past ten years, you are pretty au fait with defining requirements before implementing any system. Knowing what you need (and want) before purchase is a common practice. Everyone goes through this routine in their mind before making purchases even if it is as simple as buying a new phone or selecting a restaurant to dine in. However, when the purchase is to suit or meet the needs of more than one (i.e. yourself) the choices start getting a little harder. Add to that the supply of complimentary and supplementary products and services, pricing, affordability, personal and other preferences, your purchase is no longer as simple as it seemed before.
This is no different from when the Human Resources (HR) or Information Technology (IT) department is trying to select a HR system. To know what the system needs to do for the users may seem fairly easy until you start the process. So if you are faced with a similar challenge, here are some quick tips on how to approach defining and gathering requirements:
- Start with the why: This has to be the first question you ask before you even think about commencing the requirements gathering process. Knowing what the problem is, is crucial to ensure success. Starting by asking “do we need a system to solve that problem” will ensure that you don’t end up solving the wrong problem!
- Now you know the why, it’s time to ask who: and no it isn’t about who will solve the problem, but whose problem needs solving. A lot of organisations don’t get this right. Defining who the key “end-users” are, is critical to the success of any (system) purchase decision. However, depending on the type of organisation this can complicate the meaning of the term “end-user”. Generally, any user of the system is an “end-user”. But depending on what functionality they are using and number of users of the said functionality, may change what type of requirements they have and how they are named. A great example is a system administrator user. If you are gathering requirements to go to market for an Applicant Tracking System (ATS), the user who will administer the ATS and maintain the back-end configurations and recruitment templates will have a completely different set of requirements to the Hiring Manager who will interact with the front-end when they have a need to recruit for a position. Similarly, the requirements for a Recruiter will be different from those of a Reporting Analyst who is producing recruitment reports. So before jumping to the actual requirements gathering, the next step is to think of “who” will need to use the system. When thinking of defining the “who” start by thinking about every type of user in the end to end process? Some of the common roles across most processes that are executed using systems are those of
- system administrators who are responsible for managing the configuration and permissions in the system;
- system support teams that support users in resolving issues, functional users;
- output users – this can be anyone who is relying on the data available in the system to make decisions;
- cross-functional users – this can be anyone who is accepting data produced by this system to process a transaction in another system or set of processes;
- any external audiences like shareholders, compliance bodies or clients who may have the need to receive particular parts of the system outputs;
- candidates – are a pretty self-explanatory category, these are the target users of career websites to apply for jobs.
- Organise the users to get the ball rolling! Now that the list of users is defined, the next steps are to start discussing their availability, and preparedness to discuss their requirements. In most cases, model user(s) of each type should be easy to find in (and outside if applicable) the organisation. These users should inform what goes into a requirements set. But not all users know what they need versus want versus like. In fact, most users would struggle to articulate their requirements to the right level of detail that is required to select a system out of the thousands available in the market! A good requirement set will usually articulate the three key aspects – people, process and technology, in clear statements. For example for a recruiter, an important requirement would be to have the ability to post to different sourcing channels like Seek, LinkedIn, Monster, etc. at different points of time depending on the geography of operations of the business. To articulate requirements with this level of detail will require a tried and tested templated approach in order to avoid the pitfalls of asking the wrong question and getting the wrong answer. In addition to this, every users’ requirements tend to be limited to their experience and use of systems from past. This poses a difficult challenge for companies, as technology is constantly evolving with new features and functionality available in the market all the time and it can be hard to keep up.
Don’t panic, there is help available. Organisations’ usually need help in two main areas to get the requirements process right: a trusted advisor who knows the relevant software market; and has a templated approach and tools to get the requirements right. Well-connected organisations will use their networks to scan for trusted advisors like HR Lead Consulting who are technology agnostic and focus on getting organisation’s requirements right and bring with them the right tools like Skop.es to assist with the process. If your organisation is just getting started in this process, or has already embarked on the journey but struggling to get it across the line, ask for help.
If you would like to know what’s features and functions are available across the many vendors and find the one that best matches your HR system requirements, get in touch with us today. We have a unique tool to assist businesses select the right HR software.