Prep Before Deployment

“Must-have” software, hardware and training seems to come in waves. In my 25 years working with personal computers, I've seen peaks and valleys in upgrades. In the late 1980s and early '90s, moving to personal computers, networks, databases, spreadsheets and from DOS to Windows was at its peak. Later on, Microsoft Word 97 was at the top, as were PDAs, document management systems, Office 2003, Windows 7 and wireless. The valleys can be comfortable once the kinks are ironed out and the training has been completed. I believe, relatively speaking that is, that we've been in a valley lately. But not anymore.

We're on a peak again, a rather high one at that. With Office 2010 (32 and 64 bit), along with all of the third-party (major and minor) applications that are trying to keep up, I'm feeling the air get a bit thinner.

Let's talk about those kinks, how to minimize them, and spend more time in the comfort zone where the air is easier to breathe.

The Initial Decision to Upgrade

If you were on that rather mid-sized peak of Vista/Windows 7 and Office 2007, you may be just fine (although this column is not intended to advise on whether or not to upgrade). Your Office version is capable of both backward and forward document compatibility. The document management systems are reasonably stable, and you've probably dealt with the template/macro issues by now. You may lose a few features from 2010 files when opening them in 2007, but most legal documents don't use all of the new bells and whistles that Word provides with each new release anyway.

Thinking About a Hybrid Environment?

Some firms are mixing and matching Office versions in their environment (for example, Word, Excel and PowerPoint 2003 with Outlook 2010), or running full installs of both Office 2003 and Office 2010 on the machine (side-by-side). With either of these, it is critical that you work with your third-party vendors, integrators, and even your Microsoft tech in some instances, to be sure that: 1) the mission-critical third-party software will run in that environment; 2) the integrator knows exactly what they're doing as far as where to install which component, how the registry will be affected and how to deploy; 3) if the current workflow your users are familiar with will be impacted; and 4) you've got all of the necessary hardware/system resources.

If you do plan on running a hybrid setup, lay out a timeline for a full deployment in the not-too-distant future of just one version of Office. If you depend on this type of environment being long-term, you will surely run up against some of the issues listed above.

What Do I (or My Integrator) Need to Know Moving Forward?

Once the decision has been made to upgrade, and after you've talked to your third-party vendors, integrators, etc., the following are some tried and true tips.

• Consider creating a brand new image that will be used for all machines. This is ideal ' as simply “upgrading” existing machines can leave a lot of files, folders and registry settings behind that could interfere with what you may believe will be an “all new” software image.
• If you are not creating a new image, be sure you fully uninstall the old software that you plan on upgrading before installing the new applications. Ask your third-party vendors if their software needs to be removed prior to the major installations of Office, document management systems, etc., and then re-installed afterward.
• Research and learn the differences between .msi and .exe installation files. They have common, but not exclusively unique, parameter switches for installing and generating logs. Some software applications use an .exe file while others use an .msi.
• If your software vendor provides an .exe but you want to install with an .msi, let the vendor know what you want and why. It may have suggestions for extracting the .msi ' if it is possible with its product. Then it will need to ensure that you understand the need to install any pre-requisites their software requires.
• Have a thorough knowledge of: 1) how the User Account Settings impact installation; 2) administrator account versus having local admin rights, and elevated admin permissions; and 3) how you're going to install on a machine that only has standard user privileges.
• When you consider hiring an integrator, provide it with a list of your mission-critical software, and have it explain to you its experience or understanding of those products.

What Next?

Prior to a full deployment to your firm, you'll need to run a few machines in a test environment to ensure that there are no conflicts. If you don't have a separate test environment, try to set aside a machine or two, and designate a user(s) who doesn't have a heavy production load and can “put it through its paces.” The person you designate will ideally have an open-mind, and understand her role. Certain people will poison the waters for the rest of the staff if they run across an issue and don't/won't realize she is “testing” and that things will get resolved based on her feedback. Run these tests as both a standard user and administrator.

Many large firms create a Pilot Group. This may be a practice group, power users or Word Processors. When you have as much feedback as you would from a group that is working “live” with the new configuration, you'll be better prepared prior to deploying firm wide. The bottom line is that you should endeavor to create plenty of good documentation for your IT staff and trainers during the entire process.

Conclusion

Hopefully this column provides food for thought before moving forward with a big change. Spend the time getting intimate with your new configuration prior to deployment. The air won't be so thin once you get over that peak.

“Must-have” software, hardware and training seems to come in waves. In my 25 years working with personal computers, I've seen peaks and valleys in upgrades. In the late 1980s and early '90s, moving to personal computers, networks, databases, spreadsheets and from DOS to Windows was at its peak. Later on, Microsoft Word 97 was at the top, as were PDAs, document management systems, Office 2003, Windows 7 and wireless. The valleys can be comfortable once the kinks are ironed out and the training has been completed. I believe, relatively speaking that is, that we've been in a valley lately. But not anymore.

We're on a peak again, a rather high one at that. With Office 2010 (32 and 64 bit), along with all of the third-party (major and minor) applications that are trying to keep up, I'm feeling the air get a bit thinner.

Let's talk about those kinks, how to minimize them, and spend more time in the comfort zone where the air is easier to breathe.

The Initial Decision to Upgrade

If you were on that rather mid-sized peak of Vista/Windows 7 and Office 2007, you may be just fine (although this column is not intended to advise on whether or not to upgrade). Your Office version is capable of both backward and forward document compatibility. The document management systems are reasonably stable, and you've probably dealt with the template/macro issues by now. You may lose a few features from 2010 files when opening them in 2007, but most legal documents don't use all of the new bells and whistles that Word provides with each new release anyway.

Thinking About a Hybrid Environment?

Some firms are mixing and matching Office versions in their environment (for example, Word, Excel and PowerPoint 2003 with Outlook 2010), or running full installs of both Office 2003 and Office 2010 on the machine (side-by-side). With either of these, it is critical that you work with your third-party vendors, integrators, and even your Microsoft tech in some instances, to be sure that: 1) the mission-critical third-party software will run in that environment; 2) the integrator knows exactly what they're doing as far as where to install which component, how the registry will be affected and how to deploy; 3) if the current workflow your users are familiar with will be impacted; and 4) you've got all of the necessary hardware/system resources.

If you do plan on running a hybrid setup, lay out a timeline for a full deployment in the not-too-distant future of just one version of Office. If you depend on this type of environment being long-term, you will surely run up against some of the issues listed above.

What Do I (or My Integrator) Need to Know Moving Forward?

Once the decision has been made to upgrade, and after you've talked to your third-party vendors, integrators, etc., the following are some tried and true tips.

• Consider creating a brand new image that will be used for all machines. This is ideal ' as simply “upgrading” existing machines can leave a lot of files, folders and registry settings behind that could interfere with what you may believe will be an “all new” software image.
• If you are not creating a new image, be sure you fully uninstall the old software that you plan on upgrading before installing the new applications. Ask your third-party vendors if their software needs to be removed prior to the major installations of Office, document management systems, etc., and then re-installed afterward.
• Research and learn the differences between .msi and .exe installation files. They have common, but not exclusively unique, parameter switches for installing and generating logs. Some software applications use an .exe file while others use an .msi.
• If your software vendor provides an .exe but you want to install with an .msi, let the vendor know what you want and why. It may have suggestions for extracting the .msi ' if it is possible with its product. Then it will need to ensure that you understand the need to install any pre-requisites their software requires.
• Have a thorough knowledge of: 1) how the User Account Settings impact installation; 2) administrator account versus having local admin rights, and elevated admin permissions; and 3) how you're going to install on a machine that only has standard user privileges.
• When you consider hiring an integrator, provide it with a list of your mission-critical software, and have it explain to you its experience or understanding of those products.

What Next?

Prior to a full deployment to your firm, you'll need to run a few machines in a test environment to ensure that there are no conflicts. If you don't have a separate test environment, try to set aside a machine or two, and designate a user(s) who doesn't have a heavy production load and can “put it through its paces.” The person you designate will ideally have an open-mind, and understand her role. Certain people will poison the waters for the rest of the staff if they run across an issue and don't/won't realize she is “testing” and that things will get resolved based on her feedback. Run these tests as both a standard user and administrator.

Many large firms create a Pilot Group. This may be a practice group, power users or Word Processors. When you have as much feedback as you would from a group that is working “live” with the new configuration, you'll be better prepared prior to deploying firm wide. The bottom line is that you should endeavor to create plenty of good documentation for your IT staff and trainers during the entire process.

Conclusion

Hopefully this column provides food for thought before moving forward with a big change. Spend the time getting intimate with your new configuration prior to deployment. The air won't be so thin once you get over that peak.