Determining Whether System Changes or Policy Changes Come First

The views expressed in this post are solely those of the author and do not represent the views of ACUPA or Purdue University.

For the last two years, a project team has been working to overhaul Purdue University’s human resources and payroll systems. With the system changes have come several policy changes, mainly related to classification, benefits, and leaves. This has created a tricky balancing act of figuring out at what point in the build of the system we move forward with policy changes—a sort of chicken or the egg conundrum.

Here is what I mean. If I run policy changes through the process—which requires obtaining and reviewing stakeholder feedback, vetting the draft with the University Policy Committee, and gaining approval from the Executive Policy Review Group—before the system is built, we run the risk of finding out the system is not able to support those changes. Then I have to go back through the policy process to make changes again. If the project team builds the system before we have approval for the changes, we run the risk of not gaining approval for those changes. Then the project team has to rebuild parts of the system.

I know what you’re thinking: good policy is not written based on system capabilities, right? I agree. What is different here is that most of the proposed changes are ones that HR, payroll, business managers, and supervisors have wanted to make for a while. They have been stuck in an archaic system of manually processing and tracking sick leave, continuous service, family sick leave, and other benefits because the original policies that outlined those benefits, while well-intentioned and appropriate for the time, did not foresee unintended consequences or the growth of the institution to the size it is now. Change creates fear and fear infects culture, so administrators have been reluctant to make changes. The powers that be have decided this time, however, that change needs to happen. My job is to make sure that the policy process runs smoothly, doesn’t hold anything up, and continues to promote communication to the university community about the changes.

My biggest challenge has been getting the project team to keep me in the communication loop. For example, in the spring the team contacted me about a policy that needed to be updated because training was going to start on the system piece set to go live for the summer. What the team failed to realize is that the desired changes required not only a change to the policy, but approval from the board of trustees. I quickly reached out to legal counsel to get a resolution drawn up for the board that could be added to its next agenda. Then I redrafted the policy so it was ready to move forward once the board took action. Thankfully, we have an interim policy provision that allowed me to get this done quickly.

Other project team members have done a better job of communicating with me along the way, but we are getting down to the wire, with go-live of the largest piece of the system set for January 1. We have already identified the crucial policies that must be updated by that date, and I have been circulating drafts and discussing feedback with the policy owners for the last several months. My boss added an extra meeting for the Executive Policy Review Group in December, just in case something gets delayed. I think we have our bases covered and that everything will come together for January 1. And while there may be a few things that get overlooked in the chaos, I am confident that the policy approval process is working the way it was meant to.

I can’t say with certainty whether a policy needs to be updated before a system or vice versa. I can say that what helps me to be successful in my job is building relationships with policy owners so that they see me as a resource and not a hindrance. If they have a positive experience working with me on one policy, I know they will be motivated to work with me on the next policy.