michaeltfoy.com

My Tips for Successful Software Migration Strategies

Disclaimer: This article is based merely on my own personal experiences and opinions. This article in no way reflects the thoughts or opinions of GMC Software Technology, its employees, or its clients.


I definitely consider myself a veteran of software migrations. It’s one of my favorite professional topics, as a matter of fact. I’ve seen as many smooth transitions as I have full-scale failures. I’ve witnessed them as a ground-level associate battling in the trenches, a manager helping to motivate others to hang in there, and as a consultant, fully versed in the rules of operational war and peace. Here are some things I think you should absolutely keep in mind if you are an output-dependent company looking to replace one software solution with another.


DON’T SKIMP ON THE TRAINING
Before I started training software users for a living, I was a full-time software user myself. For whatever reasons, be it the money, the required time, or the unwillingness or lack of foresight to make the proper investment in workforce education, many jobs that I had through the years had poor training programs. Okay, maybe I shouldn’t sugarcoat it. Some companies I worked for had no real structured training programs at all whatsoever!

What I’m saying is that as a software user, I was presented with the same dreaded challenge many of us have had at one point or another in our professional lives: “figure it out!” Was I able to? Mostly. Ha. You know, I can’t begin to adequately describe the countless late nights or weekends I spent trying my best to “figure it out!”

So what’s so bad about that? I made mistakes. Some of them were even costly. It wasn’t due to my lack of trying. Every mistake seemed to take me and the rest of my colleagues by surprise. Hindsight then became the real training program.

So what are the procurers of new software solutions to do? What do you, oh responsible decision maker, need to keep in mind? Saving some bucks up front could cost you a lot of bucks later on. A lot of bucks! Would you stop your car in the middle of the highway and hand your keys and the wheel over to a ten year old in the back seat? Why not?

Here’s my advice. If the software company offers a training program, buy it. Factor it in to the budget as a non-negotiable necessity. Remember, a smaller investment now is nothing compared to a very costly mistake - or series of mistakes - later on. Allow their experts to tutor your experts, the right way, right from the beginning!

Assign at least one “lead” software integration person to attend the full training course offered. This person will be attached to the hip of the trainer for the duration of the training engagement. This should be someone who will be an actual full-time user of the software. This person should be already extremely well-versed in your previous software solution (the one being replaced). They should have a clear, ground-level view of your existing processes. They should know how to ask all the right questions of the trainer.

Make a time investment in your team during this phase as well. Shield them from their usual activities during the training engagement. Provide them with a solid, uninterrupted training experience. You may read that and say, “yeah, right.” What about deadlines? Get ready to miss a whole lot more future deadlines if you distract your team from learning about the new product. Stay with me. This can work.

Think about splitting your team up into different learning sessions. Perhaps half of them can attend sessions in the mornings, and half of them can attend sessions in the afternoons. Or, consider splitting them up into entirely different weeks of training. That might be costly when it comes to training expenses, but still, consider it an investment in success. Fully factor it into your up front, overall budget for the new software.

A good environment should be provided for training. Provide lunch and refreshments for your team. Give them a conference room to disappear into. Make sure they have properly configured, working computers to use throughout the sessions. Promote little cell phone use, restricted access to email or to the Internet, and yes, restricted access to the trainees! Keep other departments away from the training room. Interruptions are just going to be a pathway toward potential long-term excuses.

Oh, yes… excuses. Get ready to hear all of these and more someday if you refuse to consider my advice about training:
- I was never trained on this.
- I couldn’t learn anything in training. I had too much work to do.
- No one ever showed me how to use that feature.
- I really don’t know what I’m doing.
- People kept interrupting me during training. I must have missed that part.
- No wonder I made that mistake. No one ever showed me how to use this stuff.
- How could I possibly learn anything? I was too busy answering emails.
- We couldn’t get the damned thing to work during class. Our computers kept crashing.
- I didn’t get any hands on experience during training. There weren’t enough computers.

All this and much, much more! Don’t skimp on the training, folks.


START SMALL
After the new software has been installed, do not get overly ambitious and try to convert your largest, most complicated projects first. It’s new software! Start small. Take your list of projects for conversion and start by converting the smallest, easiest projects first. What do you gain by taking this approach? It would be simpler work, so the time to completion of at least one project is accelerated. You’ll be able to say that you have an active project fully based in the new software.
I believe there is also a strong psychological advantage to this approach. The sense of accomplishment your team will have for successfully building even just one project in the new software will be a relief to them. They will build confidence. They’ll be able to quickly move on and attack the next project for conversion. Another one will be crossed off the list. Then another one. And another.

Imagine the opposite approach: starting with an extremely complicated project. Let me be clear. I think that is a huge mistake. The user will take a longer time to produce the finished product. They will also certainly spend tons of time going and back and forth, experimenting with features of the new software. New software. New. Anything new requires an open mind, right? What happens if the user starts to struggle with all the new features? Frustration is born. The user may start to feel that the old software was better. Much easier. Doubt creeps in.

Confidence is contagious. So is frustration, unfortunately. I have seen this exact thing happen many, many times. Then I’ve heard statements like, “this thing doesn’t work.” Or, “this is impossible.” Or, “this is taking forever. Let’s just do it the old way.”

I believe that to consider your software migration a success, you’ll need everyone on board. You’ll need all of your associates and colleagues, especially the users of the new software, believing that the new product is far superior to the old one it is replacing. Therefore, the approach of “starting small” can quickly rack up completed project conversions and show the ROI sooner. It can also build crucial confidence and experience for your users.


FIND HELP IN EXPERIENCED PEOPLE
Let’s touch on some unfortunate truths. Some people just won’t make it through a changeover, even with the right training at the start of your migration. Some people aren’t going to have the aptitude to start fresh with a new toolset. Then too, some of your teammates actually won’t want to catch on. I’m talking about that whole “resistance to change” thing. Can any of this be fixed, or, are you going to have to start giving out copies of “Who Moved My Cheese?”

You may want to consider bringing in some new folks that might be able to contribute right away. Search for some talented people who already have used the new software. Perhaps even better, they may have also already gone through a similar migration toward the exact same software and away from a replaced solution. They may already know what to expect when it comes to glitches, potential errors, quality control, and process management.

Make the new person or people an immediate in-house resource for the rest of your team. The knowledge and confidence will spread. Healthy competition may even develop, and as long it is indeed healthy, and the new members of the team are not treated partially or of greater importance, you could make great strides together.

ENGAGE PROFESSIONAL SERVICES
Another possibility is to engage the company from whom you purchased the software to “borrow” one or more of their associates via a professional services engagement. These are your experts. Your heavy hitters. If issues come up, you’ll have a guaranteed insider at your service. You’ll also be rewarded with unparalleled know-how, experience, and direction.

Honestly, you will pay a worthy premium with this approach, but one that is also potentially negotiable or flexible. Does the help have to be on-site, or can you receive the assistance remotely? Can you include a bank of migration hours in your initial software purchase contract, rather than what will in essence become an additional cost that will have to be approved separately by your finance team? What makes more sense - to allow your team to stumble through things on their own, or to have a clearly experienced leader accessible to ease through the transition?

Thanks for humoring my take on a successful software migration strategy. Please feel free to spread my words of advice if you agree with them, and certainly reach out with your questions and comments.