Written by Eric Frokjer
At a high level, the software implementation process seems straightforward, right? It boils down to setting up the software, making sure it works, and then turning it “on” so people can use it.
Nevertheless, there’s a lot more complexity behind the scenes of each HCM technology implementation. Here’s a guide to the implementation elements that I find most often catch clients off guard. This will help you go from feeling like “you don’t know what you don’t know” to knowing what to expect in your implementation, and why certain elements make such a difference.
- The requirements gathering phase can be long and intense
Thorough requirements gathering takes time, but it’s worth it since your requirements documents tell your implementation team exactly how to configure your system. Initially, it may seem like this part of the project is moving at a tortoise-like pace, when you’re ready to move as quickly as a hare and get on to the next phase. There’s a reason to take your time and thoroughly document requirements, especially those esoteric details that you may need to bring in key internal SMEs or vendors to capture. If a key process or workflow is missed in the requirements phase, you often don’t find out until User Acceptance Testing (UAT) when one of your tests, based on a use case where that missing process/requirement comes into play, fails. To fix this, you have to identify the missed requirement, re-do the system configuration, and then test again, crossing your fingers that everything works this time around.
For every missed requirement, you can count on additional work for the project team, and depending on the size of the miss, the level of effort to design, configure, and test can have a serious impact on the project timeline and resourcing. You can see why there’s a very good reason to not rush through requirements gathering. The more detail you put in to this phase pays dividends in terms of time saved later.
After the initial requirements gathering sessions are completed, some time will be spent reviewing and revising the requirements documents. For the aforementioned reasons, the time you invest double-checking your documentation will be worth it.
- How detailed each of the requirements need to be
You already know it’s important to document all of your requirements. Beyond that, I find that clients are sometimes caught off guard by how detailed each piece of the requirements documentation may be. For example, in a full-suite HCM system implementation, where benefits is one of the modules being implemented, a client may think that a requirement stating “Need to be able to do a passive open enrollment for all employees” is sufficient, but you’ll actually need to get more granular here. When you’re done, you’ll have all the details for each benefit plan, such as the carrier, coverage levels, rates the employee pays, rates the employer pays, whether or not the deduction is pre-tax or post-tax, rounding rules, and various plan attributes like co-pay amounts and out-of-pocket maximums specified.
The same highly-detailed documentation is necessary for all of the processes your team follows for any of the technology modules you’re implementing. Again, we promise that spending the time to get the details right here will be worth it in the end.
- Why it’s important to make sure the data going in to your new system is clean
No one likes dirty data! Yes, it can be time consuming and boring to clean your data before you import it into the new system, but clean data will make the rest of your project much smoother. Since you’re loading and validating data to be used in your new system and other integrated systems, and you know the data will be pulled into reports, you want the information to be accurate. Some of the fields we often see giving clients trouble are the spelling of the names of cities (i.e., Los Angeles vs. L.A., inconsistent abbreviations for words like Street or Avenue, and inconsistent use of mixed case). You need to be mindful of these types of things when you’re doing your data clean up.
- Overall amount of time a client needs to dedicate to completing their portion of the implementation
Unless you are implementing systems frequently, you might not understand the demands on your time required to review and sign off on different project phases, building test cases and testing, reviewing data loads and test output, and working on integrating your different systems. Your implementation partner can provide you with materials that outline which stakeholders and subject matter experts need to be involved in your project, and an estimation of hours per week each person will need to dedicate to the project. It’s a good idea to review this with your project team before beginning the project, so participants can plan ahead accordingly to make sure they have enough time to dedicate to the project.
- Sometimes you can obtain baseline test scripts from the software vendor
Testing software before go-live is vital to the success of the project, but it can be challenging to come up with an exhaustive list of every possible test case. Some vendors will provide you with baseline test scripts, which will give you a starting point in the testing process and will save you some time. After reviewing the scripts from your vendor, you’ll have a better idea of what to test, and what steps to take in order to test those specific use cases. Ask your vendor if baseline test scripts are available.
- The internet browser that is used to test your system matters
Most software is tested on newer browser versions (i.e. the last 3 or 4 iterations), but if the live system is loaded onto an older browser, there’s a chance it won’t work correctly or fail to load altogether. Check with your IT department to make sure browser updates aren’t locked down, which sometimes is the case if the organization uses legacy systems that need to run on old versions of browsers.
- End-user training specific to different groups is an investment that pays immediate dividends
There’s a significant value in conducting highly specific end-user training to your different user groups. Your administrators need to understand how to do very different tasks with the system than what your managers or general employee populations need to use. You could spend time on a one size fits all training, but we suggest conducting end user training for individual user groups so they’re able to see the actual look and feel of the system, rather than simply reading a printed user guide or e-guide. Tailored training to these distinct stakeholder groups will greatly increase system adoption. With this approach, your employees will leave the training understanding how to do what they need to do with the system. In the current age where employees prefer self-service, giving the employees the education they need to master the new system will cut down on questions for your HR department, freeing up HR’s time to focus on more strategic activities.
To make sure you’re well-prepared for your next HR technology project, contact the team at HRchitect. We’ll make sure you know what to expect during different phases of the project and will be by your side every step of the way during your next implementation.
Eric Frokjer has over 25 years of experience working with HCM technology and has been working with HRchitect since 2012. He enjoys working with clients to successfully implement HCM systems including Benefits, Core HRIS, Payroll, and Time & Attendance.