Workshop

call the risk/benefit ratio—the amount of risk compared to the potential benefits.
Once you decide you need to start using a new product, you’ll still want to make sure you aren’t going to
have any problems with it right out of the gate. For example, many IT shops were using Windows 95
internally for the better part of a year before they rolled it out to the masses. (Of course, using a new
operating system introduces a sea of changes; a year is typically a longer pilot-testing period than you’ll
want for a new word processor or spreadsheet.) The most important part of pilot-testing is the concept of
limited production. After you’ve played with the product in an isolated area, roll out a limited
deployment—in other words, install it for a couple of folks who will use it for their daily work and see
how it goes. If it goes well, you’re usually going to be fine. What’s more, if something goes wrong, you
only have to roll back a limited number of folks.
Another aspect to keep in mind is the concept of incremental rollouts. This means that after a limited
deployment, you start giving an application or system to more and more folks rather than doing it “all at
once,” thus rolling it out in small chunks that get bigger as the rollout becomes more successful. For
example, you might give five people a new application. Later, you give the application to 10 more
people; then 15, 20, and in your final increment, you might be rolling out 30 people a week (once you’re
sure that things are working fine). Using an incremental rollout ensures that if you have a problem early
on, the least number of folks are affected.
Even if you don’t have problems during a rollout, a new application or device can produce secondary
effects in another item that doesn’t seem to be related to the new item. Accordingly, a good rule of thumb
is to shut down new items during network or communications trouble. The trouble might not be related to
the new device or program that you’ve installed, but if you shut it down, you’ve ruled it out as the source
of the trouble.
If the trouble goes away, you can then kick the problem back to the vendor you bought the offending
item from (or to the manufacturer). However, make sure the problem is reproducible (that is, make sure it
happens repeatedly when you reintroduce the program or device back into the network) before going to
your vendor.
You should try to give your vendor as much information as possible, especially when using telephone
support, so that the technician can attempt to re-create your situation in his or her shop. Again, backup
documentation such as logs and incident reports are key—in fact, technical support tends to pay much
more attention to you if you can put your problem in writing.
Summary
Many network problems are the result of human-initiated change. Finding this change involves
documenting and communicating your own actions, as well as politely interviewing your coworkers and
outside vendors. Even unintended changes due to the “fat finger factor” can seriously damage a network,
so it’s worth considering where you’ve been, no matter how unrelated it might seem. You’ll also want to