UF Postings Past: Are You Ready to Upgrade?
March 9, 2008 – 3:26 pmMost of us who have ever been involved in implementing a piece of enterprise software has faced this. You gather requirements and evaluate software vendors. You jump various political hurdles inside your company. You build your implementation team and start ramping up to install the product. In this middle of all of this, blammo! The vendor changes upgrades their product. Sometimes the upgrade is no big deal; sometimes it’s radical- like they rewrote it as a web application, or the app that used to be in powerbuilder is not written in c# or java. No big deal because you planned for that to happen, right? Uh, right?
For most companies, the answer is wrong. When evaluating vendors, never forget to do some basic homework on their future roadmap, how it will affect your project, and how their roadmap matches up to your plan.
Here’s some things to do to prepare for major version changes during your implementation:
1) Managing the version change within your project plan and scope
If there is a version change or other major product upgrade in their roadmap, be sure that you put that in your project plan. Make sure that you put time in your project plan to evaluate the new product and adjust the project plan according to the requirements of the new product. You doubtlessly will have to upgrade to the new version to achieve support from the vendor at some point; it’s easier to change now than after you’ve gone to production with the product. Treat this essentially as a major change request would be treated, only you have the bonus that you know when it will (probably) be and can schedule this in your project. If you are tempted to put it off until after you go live, don’t. This is like all other major project changes. The later it happens in your project, the more money and resources it will take to implement.
2) Managing the version change and having the right resources
Do you have the right resources available for the new version? If the code base changes in the new version, you’ll need programmers and techies versed in that code base. You’ll need systems architects available when you evaluate the new version of the product so that you can determine if the new version requires more and/or different hardware. You will probably need a business analyst to look at the new features in the next version to consider how the way the product will be used by the company may change and improve. You may need testing folks to change their testing plans, if any are already written, and you will likely need your trainers to adjust any material they’ve done up to now.
3) Managing your resources before the version change
Do not make the mistake of doing work for the sake of having people work before the change in versions come down. There will be a lot of work that can be done beforehand. There will be some work that may become obselete with the new version as well. Evaluate your task list carefully. Don’t waste time sitting around waiting for the new version, but don’t waste resources working on things that will be rendered obselete either. It’s a careful tightrope to walk.
Last but not least, never forget to document, document, document. Keep up with your vendor’s version upgrade schedule. You will have to upgrade the product again after it is in production. This is a learning experience as to how to do that. Save as much lessons learned and project plan material as possible from your upgrade so that you can make your future transitions more smooth.
Vendor products change. This is a reality of their business model. Plan for the change so it can fit within your business model.
Like this post? Buy me a cup of coffee.Popularity: 19% [?]
