How I Did It: Five Key Steps to Manage Technology Change

Nixon Peabody, LLP is a Global 100 law firm with more than 700 attorneys across the U.S., Europe and Asia. In this guest post, Karen Keegan, Nixon Peabody’s assistant controller, discusses how to the firm let business flow by effectively managing technology change.

One of the most feared projects for companies is changing organization-wide technology solutions. From ensuring that there are no technical snags which could derail the project when it goes live, to making sure that everyone is aware of the change and effectively trained, there are countless scenarios to consider.

We recently moved our law firm of more than 1,500 employees to the newest version of Chrome River. With staff based in 16 offices around the world, many of which don’t have expense system administrators, we needed to ensure that we got it right first time, in order to save ourselves from a barrage of support calls from confused users. To ensure that our changeover was as smooth as possible, we worked with the Chrome River team to develop an effective migration plan.

Here are my five best practices for managing technology change. While these applied to Chrome River in our case, a similar blueprint could be effective in any kind of organization-wide technology migration.

1. Take the opportunity to review business processes first

Companies often keep outdated and obsolete business processes, not because they want to, but because changing them can cause disruption, so it’s easier to keep the status quo. Nixon Peabody has been a customer of Chrome River for almost 10 years, so of course there have been technology and best-practice changes since then, and some of our business rules have also undoubtedly changed in the meantime. Prior to making the move, we decided to perform a review of some of our back-end processes as well. If your organization also needs to perform a periodic review of its internal processes, prior to a change is an ideal time to do so.

In our case, we deleted old rules that we didn’t need anymore, took out general ledger codes that we no longer use, improved some rules that had hard employee codes rather than roles, improved descriptions of rules, etc. Having done this makes things flow a lot more smoothly now.

2. Keep end-users in the loop

Many people are resistant to change, even if it means life will be easier for them afterward. People who have been using a system don’t want to have to adjust the way they do things, and blindsiding them with a big change can lead to frustration. Therefore, you need to give people time to adjust and absorb news of the impending change, as dramatic as that may sound.

Communicate the change to users at least one month ahead of time. We found that our secretaries and others really appreciated enough lead time to get used to the idea of change. It gave them an opportunity to ask questions. We also used this as an opportunity to get buy-in by pointing out all of the great benefits of the new platform. Getting buy-in is a key point here. I do like to get users excited about upcoming changes!

3. Test and validate the system thoroughly

As we decided to do a rules review prior to the migration, it was essential that we did a thorough testing and validation of these rules before the change took place, to avoid incorrect processes being deployed. Any rule that is changed must be tested, and all the conditions that the system has must be validated, in order to ensure everything is flowing properly. It’s better for any significant issues to be uncovered and corrected during testing rather than after going live, so approaching the testing from a standpoint of “what needs to be corrected?” rather than assuming everything will work correctly is preferable.

4. Make it easy for everyone to get up to speed

In order to make the change easy for our team, we found that it was critical to make it easy for our users. First, we developed step-by-step training materials. Creating clearly-written, step-by-step instructions for our users and making sure these are easy to find (for example, we put a link to the instructions on the Chrome River system home page, so our users could see them each time they log on) was key. Keep in mind that some users may be opening the solution for the first time, or may only log on a few times a year, if they don’t need to use the system regularly.

Before launch, “test drive” the instructions with different kinds of users: those who access the system regularly so are comfortable with the old process, those who only access it infrequently, and those who have never used it before, and see how they all respond. They should be very basic, but also cover the different variables. If practical, provide live training (or training via WebEx) and video tutorials on your company’s intranet site. Thankfully, Chrome River is very easy to use, but you should still ensure that everybody is comfortable with it.

5. Roll the solution out incrementally if needed 

Part of the employee communications process needs to be setting a clear deadline when the old system will be turned off. However, for larger organizations, it can be easier to move teams over in waves, instead of switching between the two systems for the entire organization at the same time. Doing this over a period of a couple of weeks, either by geographical location or by department, may make training and internal user support easier to execute. Keeping the old system “open” for a short period of time is also an option so users have a chance to catch up on training.

In sum, while a technology migration may look daunting at the outset, if you create an effective plan, there is no reason that it should cause any major headaches. In our case, we were lucky – Chrome River is extremely easy to use, both for expense submitters and approvers, and for the the finance and admin side. We also worked closely with the Chrome River project management team to make the process smooth all round.  

Karen Keegan, assistant controller, Nixon Peabody LLP