I asked and you responded about your perspective on jumping up a release or Double Jumping [1]. You explained in the comments how you firm and you approach this question. Now I would like to offer some of my advice on making this call….
When is the right time to upgrade your software release?
[2]
Think about these things… (portions originally published in AUGI Hot News 2005)
Before the next Project begins.
Many people want to prepare and move before a major project starts. Rather than move the whole company at one time they take one project into the next release and manage the process like a Project Manager. This can be a good thing and a bad thing.
The Good – It sets you up to use the increased productivity in the new release to be applied to the new project. It also places you on focus for the future since the project will outlast your prior release use. By taking a project into the next release, you can control the tools used on a small scale, selecting which new tools to apply. Sheet Sets? Project Navigator? Vault? No need to expect to use all of the new improvements, just select the ones that will impact the project for the better.
The Bad – Your upgrade troubles may slow down the project schedule. Training and tech support issues may impede project timeline. Productivity may (will) take a slight dip until users get up to speed. All of the this impacts the project
My Advice – make sure the Project Manager is supportive. Let him or her know the issues surrounding the use of the new software. Make them your ally. If not – he could turn into your worst critic.
Lessons Learned – Make sure you track the troubles you have. Document anything that is a concern. make a definite process of expanding it to the next project.
After Training
Most firms want to do some form of training. It may be formal, informal or just a handout.
The Good – When you have completed training your users are hopefully excited and ready to use the software. Training can create momentum for the migration.
The Bad – Training takes time away from project work. Productivity loss from training time may need to be recovered as users return to the project environment.
My Advice – you need to train before the migration begins, but you may want to wait a week or two so that all the projects are caught up from any time lost during the training.
Lessons Learned – Training does not stop when the class ends. Keep in touch with the users. Make handouts that can be used as reference material.
When demanded by clients
Sometimes the client sets the pace for upgrades.
The Good – May force your team to make a move if you are having difficulty making progress. It is often hard to get the migration started. After I was prepared, I have used a clients demand for upgrades to get my team moving.
The Bad – The demand may come before you are ready. You may not have trained. You are forced to move and may be reluctant. Bad morale may creep in since it was not your choice
My Advice – The whole issue of when to move may or may not be in your hands. If it is, then you should carefully think and plan for the move. If it is not, you should prepare for it because it may be inevitable. Be prepared!
Lessons Learned – Be prepared before they ask you. Get everything set and migrate your content prior to the question being posed.