So you’re thinking it’s Time to Upgrade?
If you have been paying an annual maintenance fee for your software, you’re probably expecting the vendor to provide you with an upgrade, that makes just makes sense. But be careful what you wish for…..you might get it! And when you do, will you be ready and prepared for it? Will you make the most of it? Will you realize the benefits that the vendor was hoping you would? These are just a few questions that should be explored prior to pressing the upgrade button. What follows, is a look at some of the things that you should think about and plan for, if you think it’s time to upgrade.
Training
I’m going to start and end this article emphasizing training. And yes, I already know that the last time you asked to get more training you were told that “times are tough and we’ll have to see how it goes.” I agree that times are tough, however, I see no sense in making them tougher. I find it interesting. We would never deny employees from getting safety training if there was a chance of putting them in harm’s way as a result. Why then would we not train staff so they are equipped to achieve success when otherwise they would fail? Oh sure, in the second case the employee is not harmed but the company certainly is if the employee fails or the upgrade fails.
Start the project with training. Let the vendor use their data and their examples. This will allow them to show you how their system performs best without restrictions. You may have or most probably, will have some restrictions to deal with but save that for later in the process. First off, learn the product and make sure the vendor is teaching you how the product should be used with real life examples. Acquiring a good working knowledge of the program will enable you to make informed decisions throughout the upgrade process.
Setting Goals and Objectives
Here I suggest you start with one simple mission statement. “We will upgrade to take advantage of moving to a web based system that we can access from anywhere.” Once the main objective is set, you can list other reasons for upgrading. This list should be discussed with your supplier. The software vendor might have some additional ideas for you. They might also temper your expectation for some items.
Accept the Change
Are you ready to accept change? The upgrade should bring change. The best way to deal with change is by ensuring that you know what the consequences are. Again, training can be key to ensure you have a good understanding. Then you can assess what the change means to your organization. Generally the software developer has changed the way the software works to improve the process. New operating platforms can often dictate the way the software works. It may be a bit more difficult to use, but now you can use it in the field. So there can be trade-offs. The key is to understand what changes are coming and try to make sure that all involved understand the reason for the change
Determining Gap
It’s very important to determine the exact differences between the old version and the new one. There will generally be a document that the software vendor provides with new features and changes to the software. It’s a start but it isn’t always complete, so be careful. Back to training. You’ll have to gain a reasonable understanding of the new version to determine how it might affect your current processes. From that, you’ll need to develop plans to either update your process to match the software or configure the software to match your process. Either way, some careful planning will be required.
Document Everything
I can’t say enough about documenting everything. There should be a written Migration Plan in place before moving forward. It will be critical to make sure you have plans in place that everyone on your team understands and accepts. Make sure you assign the roles and responsibilities clearly and write them in your plan. Share your plan with the software vendor. They may provide some insightful comments that assist in improving your plan. Create a good flow chart or flow charts that represent your work flows in the software. This is an important step in communicating your vision of ‘how it should work” to others. The other step that often gets missed is updating you plan from time to time. Show your successes as you work through the project and document any differences between the plan and the actual role out. It will be helpful in future when you try to remember why you implemented the way you did. As an example, staff often changes and this sort of legacy documentation can be very helpful.
The Bottom Line
Training. There, I said I would. I started by expressing the need for training and I will end with it. Make sure you get the appropriate training to you and your team. It’s hard to say how much training each person needs. It depends on factors like the user’s current knowledge set. I’d say a good start is to ask you users what they think they need. I will also tell you that there should always be some update training on an ongoing basis. When I used to train people on software we always found little ticks and tips that made their lives easier and made them more productive as employees. It can easily pay for itself in production.
Working closely with your software vendor and creating a thorough written migration plan are probably the two other best pieces of advice that I can offer.
