From Client to Consultant: Lessons Learned During Implementation | Part 2

As you know from my previous blog post, I was a former HR technology manager working on the client side of an engagement with HRchitect implementing a new time and attendance system. During that implementation project, I found that thoroughly understanding requirements documents and User Acceptance Testing (UAT) is critical to the success of the project. What was the third most valuable lesson I learned?

Lesson Learned: Spend the money now on separate policy profiles

Most companies and organizations set up their policy profiles by Work Week differences or employee type differences (Exempt vs Non-Exempt vs Contractors), etc.  Typically in those scenarios, the rules for time keeping and payroll are significant enough that it makes sense that each group needs their own Policy Profile.

What happens if your Non-Exempt employees in two locations, have very similar rules, but they differ in maybe 3 premium calculations?  Your first instinct is to try to save money. You might ask, “Can’t we make this one Policy Profile work for both locations and simply add code to the calculations to look at the ‘location field’, and then apply the correct calculation at that point?”  The quick answer is, of course.  Sounds reasonable.  As the HR Technology Manager for a very large power company, we tried this shared policy approach but slightly different rules for each location.  It worked.

However, as a lesson learned, there are drawbacks to that approach, and we decided for our future implementations, even though it was more expensive in the short term, if you can afford it, split the users into their own policy profiles so system maintenance in the long run becomes much cleaner and requires less testing for future changes.

Drawbacks to sharing a Policy Profile where some of the rules and calculations are different for different groups:

1. You have a re-org or your company gets acquired and now your location codes in your HR data are changing. That requires all hard-coded rules in the configuration to be updated with the new HR codes.  Which also requires new rounds of user acceptance testing.  Rather just needing to update the Policy Mapping screens, now you need a change order and full project to request and test this change to every calculation where this code is used in the configuration.  If locations were separated at the Policy Profile level, more than likely this re-org change would only require a change to the Policy Profile mapping setup, and requires less user acceptance testing.

2. Things change. HR policies change.  Premiums change.  New absence codes get added for one site and not the other.  After 6 months of being live, a new change request comes in for only one of the locations.  Once the developers make the change that is required, now all sites that share that profile need to test, both for new functionality added for the new site, as well as regression testing for all of the sites that share this profile, even though they should not be impacted.  If the impacted site were in their own Policy Profile at the start, this change would be much easier and not impact every site that shares the profile.  User acceptance testing will require less time and fewer resources.

3. You must be EXPLICIT with your change requests. In a Policy Profile that is shared with different calculations based on different criteria, if one of the groups requests a change, a simple change can cause quite a havoc if something that was shared is changed for one group, and the other group did not agree and doesn’t want the change. Without proper communication in the change request to apply the location filters to the change order, you can spend many days where Location 1: “It’s working for us”, Location 2: “It’s not working for us, please fix”.  Location 2: “It’s fixed now, thanks!”  Location 1: “Where did our change request go, it was working yesterday?”  If this group had been separated into their own policy profiles, the change orders and user testing would be much cleaner.  Communication needs to be very explicit for the change being requested so that all new team members are aware that the Policy Profile is shared by users with slightly different rules.

HRchitect helped me and the rest of the HR technology team at the power company through a complex implementation project with much success. In my current role as an HR Technology Consultant, and in the spirit of continuous improvement, I share these lessons learned with each of my clients to ensure they have a smooth, successful implementation project. Through ongoing education, working collaboratively, practicing effective communication/listening skills, and adapting to every situation, we have a team that can help your organization ensure the highest level of success. Our services span from helping organizations create HCM technology strategic plans, evaluation and selection services for new or replacement systems, change management, and implementation services.