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

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

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

Participant selection

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.

Software training

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.

Technical support

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

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


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