{"id":3665,"date":"2005-06-07T09:29:37","date_gmt":"2005-06-07T16:29:37","guid":{"rendered":"https:\/\/www.caddmanager.com\/CMB\/?p=3665"},"modified":"2019-07-01T09:39:20","modified_gmt":"2019-07-01T16:39:20","slug":"migration-madness-part-four","status":"publish","type":"post","link":"https:\/\/www.caddmanager.com\/CMB\/2005\/06\/migration-madness-part-four\/","title":{"rendered":"Migration Madness – Part Four"},"content":{"rendered":"
This entry is part 4 of 6 in the series Migration Madness<\/a><\/div>\n

In the last installment we outlined the areas of concern related to moving from one release of software to the next.  Let\u2019s quickly review.
<\/p>\n\n\n\n

The three areas of reflection are:
<\/p>\n\n\n\n

  1. What to do before the migration<\/li>
  2. The actual migration event or period<\/li>
  3. What to do after the migration<\/li><\/ol>\n\n\n\n

    We move now to the second stop on this trip which is actually moving ahead and making the migration.
    <\/p>\n\n\n\n

    Let\u2019s first discuss when to make the move<\/strong><\/h2>\n\n\n\n

    You should move when it makes sense.  Sometimes we are forced to move and start using a new release even before we have time to prepare.  
    <\/p>\n\n\n\n

    When is the best time to move?<\/strong>
    <\/p>\n\n\n\n

    Before the next Project begins<\/strong>.  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.
    <\/p>\n\n\n\n

    The Good \u2013 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.
    <\/p>\n\n\n\n

    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
    <\/p>\n\n\n\n

    My Advice \u2013 make sure the Project Manager is supportive.  Let him know the issues surrounding the use of the new software.  Make him your ally. If not \u2013 he could turn into your worst critic.
    <\/p>\n\n\n\n

    After Training<\/strong>
    <\/p>\n\n\n\n

    The Good \u2013 When you have completed training your users are hopefully excited and ready to use the software.  Training can create momentum for the migration.
    <\/p>\n\n\n\n

    The Bad \u2013 Training takes time away from project work.  Productivity loss from training time may need to be recovered as users return to the project environment.
    <\/p>\n\n\n\n

    My Advice \u2013 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.
    <\/p>\n\n\n\n

    When demanded by clients<\/strong>
    <\/p>\n\n\n\n

    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 client’s demand for upgrades to get my team moving.
    <\/p>\n\n\n\n

    The Bad \u2013 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
    <\/p>\n\n\n\n

    My Advice – The whole issue of when to move may or may not be in your hands.  If it is, then you should think carefully and plan for the move. If it is not, you should prepare for it because it may be inevitable.  Be prepared!

    <\/p>\n\n\n\n

    Start the migration with your best users<\/strong>
    <\/p>\n\n\n\n

    Let them have the software earlier.  Load the next release on their machines with plenty of time for them to use it. Let them test it out.  Let them find the good and the bad of the next release. Have them write down what they find and report back to you.  By having them work with the software (not on production drawings) you can find the strong points you can capitalize on when trying to convince others to join the move.  You also can defuse the weak points by finding out what is failing and plug the hole before it does much damage.

    <\/p>\n\n\n\n

    Migrate a small team or the whole office \u2013 you should figure out which may be best for your office.  Some take the whole office to the next release in one weekend. Others take smaller teams forward making the move progressively expanding to the rest of the office.   
    <\/p>\n\n\n\n

    My advice – the bigger the firm \u2013 the smaller the migration group.  Taking a large group (30 and above) at the same time to a new platform is tough.  A smaller team generates fewer support issues. You can use the lessons learned from the small group to make the next groups move even smoother.

    <\/p>\n\n\n\n

    Line Up Support before You Start <\/strong>
    <\/p>\n\n\n\n

    Management should be fully behind you before you begin.  This would include Project Managers, Leads, Engineers, and anyone who might feel the impact of a move.
    <\/p>\n\n\n\n

    Vendors \u2013 keep them involved.  They can provide support and lessons learned from other firms that have made the transition.
    <\/p>\n\n\n\n

    Your Family \u2013 yep \u2013 those folks at home that could be impacted by the time you may need to make the change happen.  Don\u2019t leave them out of the loop. They may not understand what you are talking about, but they need to know when you are faced with deadlines and milestones.  If a spouse makes a meal that you don\u2019t make it home in time to eat, you best should have warned them. If the kids have a big game coming up, make sure they realize that you could miss it if worse case scenarios kick in.  
    <\/p>\n\n\n\n

    Stay focused on the goal:  Getting your team to the next level with the least resistance.  Keeping everyone involved will help.<\/p>\n
    ","protected":false},"excerpt":{"rendered":"

    This entry is part 4 of 6 in the series Migration Madness<\/a><\/div>

    In the last installment we outlined the areas of concern related to moving from one release of software to the next.  Let\u2019s quickly review. The three areas of reflection are: What to do before the migration The actual migration event or period What to do after the migration We move now to the second stop […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[13],"tags":[],"series":[95],"class_list":["post-3665","post","type-post","status-publish","format-standard","hentry","category-cad-management","series-migration-madness"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t