Recently, we discussed why it is so important to choose the right super users for a GHR Payroll implementation. These are the people who should be involved in design meetings from the beginning of the project. Doing this ensures that everyone is on the same page and that there are no surprises once we get to parallel testing the supervisor structure. If you're using a time to tenant system, something to keep in mind is to make sure that the supervisor structure is accurate for time approvals. This is important because that structure will be fed over for time approvals into your timekeeping system which is something you can start working on ahead of time if you know you’re going to be implementing payroll.
Other people that should be absolutely included in these design meetings are the functional leads. As you're doing the testing and validating the data, it's important to have those leads in the room making decisions and being fully engaged in the project, especially to support payroll implementation testing. What we typically I do once they have gone through unit testing is back off from everything and transfer everything to the leads. That allows us to be sure that they are self-supporting when we roll off our project. When you require the functional leads from the beginning, they are usually so much better at navigating the system and knowing where to go than past projects where the lead has come in late. It allows them to be fully engaged and understand how the processes run within the system.
Involving these leads from the beginning is all well and good, but if you aren’t prepared to backfill for day-to-day operations, this will backfire. It is inevitable that the person will become overwhelmed if they are trying to learn a new system while continuing to complete their typical duties. We have watched folks burn out one too many times because no one understood the importance of supporting them during this project, which is a quick way to lose a hard worker.
There are several reasons our team feels so strongly about this. Our experiences are shaped by what we've seen in some design sessions, conference rooms, or even virtual meetings. Time after time, your functional leads are the people putting out the fires and working through issues. This is a situation where if your lead can’t be fully engaged to give us everything needed to properly design the system for you, then issues aren’t discovered until the system integrated tests when we see unit tests for the first time.
Sometimes the lead doesn't even have the full end to end process, so you might get halfway through your project before someone realizes all this stuff you forgot to do. When that situation arises, our team can’t be blamed for something they were never made aware of in the first place. You can almost always be sure this important item was missed because someone was trying to do two jobs at once instead of focusing on learning an entirely new system.
We wanted to touch on this again because we’ve watched it either push out a project timeline because of a last-minute redesign or seen clients go live with something they are not happy with just to finish the project. That’s essentially the worst-case scenario because then you have to try and optimize the processes afterward, something that eats away at valuable time post go-live. Typically, clients hardly have the time to take off for a project in general, let alone another six months to fix everything that could have been done correctly the first time if their resources had more support.
