Unless you have been living under a rock, you probably know that Microsoft has an entire slew of new products that are scheduled to be released in the coming months. Among these products are Windows Vista, the successor to Windows XP, and Microsoft Office 2007. Although these products are still a few months from being released, you should be thinking about their deployment right now.
Although Microsoft spends huge sums of money and dedicates countless resources to making sure that new products are stable and reliable, there is no guarantee that the new products will work properly in your organization. Your organization uses a combination of hardware and software that is unique, and it would be impossible to predict exactly how these new products will behave in your organization. That being the case, it would be a huge mistake to simply install Windows Vista or Office 2007 on all of the workstations on your network on the day that they are released. Instead, you need to do some testing and perform a pilot deployment to find out whether or not these new products will function correctly on your network.
Building a test lab
I could probably write an entire article on the subject of building a test lab. Even so, I don't want to spend too much time on this topic because there are a lot of other things that I want to talk about. Even so, I wanted to at least mention creating a test lab and give you a few pointers.
The basic idea of creating a test lab is to create an environment that mimics your production environment as closely as possible, but on a smaller scale. The scope of your test lab will depend largely on your budget and on the amount of space that you have to dedicate to the lab.
I have seen some companies install server operating systems on high-end PCs, and then configure those servers with similar administrative policies as with the production servers are using. I have also seen companies with high budgets create exact duplicates of their production network servers. In environments like this, it is not uncommon to configure the test servers by restoring backups of the production servers to them. This ensures that the test lab is an exact match of the production servers. An added benefit to this approach is that if a production server should ever fail, then there is an exact duplicate in the lab that can be used as a spare.
Whether your test lab is an exact duplicate of your production network, or just a basic approximation made up of a few PCs, there are two things that are important to keep in mind. First, it is important that the lab remain completely isolated from the production network. You don't want a software or configuration glitch in the lab to interfere with the production environment.
Another thing to keep in mind is that the lab should have a representative sampling of the PC is used throughout the company. One way that I have been able to accomplish this in the past is by confiscating a user's old PC when they order a new PC. After all, there's a good chance that other users in the company are still using that model of PC. Of course you need to have a representative sampling of the newer hardware on your network too. That is relatively easy to accomplish though, since you can just order current hardware.
In addition to helping you to evaluate the compatibility and stability of new software, a test lab can be used for many other purposes as well. Some of the other things that you can use your test lab for include:
- Performance planning and capacity testing
- Training users and support staff
- Testing new security policies
- Documenting deployment or administration procedures
Creating a pilot deployment
After you have tested the new software in a lab environment, it is time to perform a pilot deployment on your production network. A pilot deployment prior to a full rollout is essential, because in most cases it will be impossible for your testing lab to accurately simulate every aspect of your network.
A pilot deployment will consist of rolling out the new software to a select group of users in your organization. Choosing which users to include in the pilot deployment is an art form of its own. The first trick will be to figure out how many users to include in your pilot deployment. This can be tricky because on one hand you want to have enough users involved in the pilot deployment to give you an accurate assessment of how the full deployment will tell when the time comes.
On the other hand, the software that you are installing has not been previously run in your production environment. This means that anything could happen. If the software were to create a major problem, then the amount of effort involved in cleaning up the mess will be directly proportional to the number of users whose machines you installed the new software onto.
Another thing to consider is that you want to make sure that your pilot deployment participants make up a representative sampling of the organization. Users in your organization are probably running different types of hardware and software depending on their job responsibilities. It is therefore advisable that you try to design the pilot deployment program so that the new software is installed on a wide variety of different hardware and that any software that could potentially conflict with the new software is in use on at least some of the machines in the pilot deployment program.
As a general rule, pilot deployments are easier to manage if they are limited in scope to an individual department or to an individual area of the building. Even so, I tend to think that involving users from departments all across the company gives you a better representative sampling.
Hardware and software are not the only issues to take into consideration when you are trying to determine which users should participate in the pilot deployment program. I believe that it is important to consider the users themselves, and not just their computers in the software that they are running. For example, you would not want to involve a user in the pilot deployment program if they had a critical job function that would be hampered by unexpected downtime. For instance, you would not want to involve the person responsible for printing payroll checks in your pilot deployment program because you want to make sure that everybody gets paid on Friday.
I also recommend considering the level of knowledge that potential candidates have. You want the members of your pilot deployment program to be at least somewhat computer literate. After all, you're going to have to train the users on how to use the new software, and the training to take a whole lot longer if your training users to don't know much about computers, and do not want to learn. I know it sounds silly, but there are users like this in every company. Users participating in your pilot deployment program also need to be knowledgeable enough that they can communicate errors or problems to you in a meaningful way.
Finally, you need to consider the user's temperament. We've all had the frustration of working with the users that are prone to hysteria, panic, or rage when problems occur. These are not the types of users that you want to involve in your pilot deployment program.
After you have chosen the users who will participate in your pilot deployment program, the next step is to do some training on the new software. Hopefully, the IT staff has been working with the software throughout its beta testing phase and is already familiar with it. If not though, then it is important to bring the IT staff up to speed on the new software before going any further.
Once the IT department has been trained, it's time to design a training class for the participants in your pilot deployment program. My experience has been that it is best to limit the training class to no more than 90 minutes in length. If the class is longer than that, then retention levels tend to drop as does the attention span of the participants. You can of course have multiple training classes that teach the users more complex material by dividing it into bite sized chunks.
Whatever format you decide to use for your training classes, I recommend taking the time to put together some documentation for the users. This documentation should be designed to walk the users through various procedures. The documentation should be written in as easy to follow of a manner as possible, and include lots of screenshots. Providing the users with a quick reference guide is also a good idea.
As a technical writer, I personally developed documentation for in-house user training on many occasions. I can tell you from firsthand experience that putting together a good set of documentation tends to be tedious, time-consuming, and boring. Even so, I believe that creating good documentation is worth the time that it takes because it will cut down on support calls. Even though the new software that you are deploying could end up being perfectly stable and free from problems, you have to assume that your support center is going to be overrun by calls from pilot deployment participants. As such, you need to take steps to cut down on the "how do I" type calls so that your support staff is free to handle calls related to real problems. One of the best ways to reduce the number of "how do I" calls is to provide users with good training and good documentation.
Before the users leave the training class, you should make it crystal clear to them that they are not to contact the helpdesk for issues related to the pilot deployment program. Instead, you should provide the users with the name and phone number of a contact person whose job it will be to dispatch help for issues related to the new software. Since some of the program participants will invariably call the help desk anyway, it is important to inform the helpdesk staff that calls related to the new software should be forwarded to the designated point of contact.
The person who has been chosen to receive the calls from the program participants should have a good working knowledge of the software that is being deployed. This will allow them to screen their calls and answer any easy questions themselves. That person can then forward more complex or serious support issues to a technician who can personally visit the user who is having the problem and perform a diagnosis.
As the pilot deployment program progresses, one of the most important things that you can do is to treat small problems as big problems. It is easy to look at a small problem and consider it to be insignificant. In my opinion though, that is one of the worst mistakes that you can make. The reason why I say this is because pilot deployment programs are small in scale, so problems will not be widespread. When the full deployment occurs though, your helpdesk could be bombarded with hundreds (or thousands) of calls related to a very minor issue if you do not fix the issue during the pilot deployment program.
Know when to say when
Before you ever deploy the new software to the first machine in the pilot program, you need to have a rollback plan in place. I also recommend deciding prior to the pilot deployment under which circumstances the rollback should take place. This will help add balance to your pilot deployment. It helps protect the users against lost productivity due to software that just isn't going to work. At the same time though, having a clear policy in place regarding one rollback should occur prevents an excessively jumpy administrator from abandoning the new software over a minor glitch.
As you can see, a pilot deployment program should be an essential part of any new software deployment. In this article, I have given you hints based on my real world experience in an effort to try to help you to make deploying Windows Vista and Microsoft Office 2007 as painless as possible. Of course these techniques can be applied to virtually any new application.