Obtaining User Buy-In Before a Change
Considering a migration? You'll need to woo your users first. Emmett shares a few tips on conducting an effective feasibility study.
In study after study, one of the things that never ceases to amaze me is the
importance of user buy-in to the success of a project. The more comfortable
users feel with a change -- and the more they endorse it -- the more likely
the project will be successful from the start. In this regard, at least, the
field of integration is no different than any other.
Recently, the desktop has come under some intense scrutiny when it comes to
integrating diverse operating systems. With the release of Windows Vista and
Microsoft Office 2007, some companies are debating whether to pay for the upgrades
and purchase the new hardware, or migrate to Linux and open source solutions.
Before seriously considering any such undertaking, I strongly encourage you
to include all of your users in a feasibility study. This will help you determine
whether you should explore the possibility of migration or stick with what you
have. Here are some suggested steps for conducting such a study:
Step 1: Talk to the Users
Communication is crucial to any project. Hold meetings with groups of users
and explain to them that you're considering a change in operating systems and
that you need their help to determine whether to go ahead with it. Tell them
your reasons (usually monetary) for considering this change and ask them for
assistance. Tell them that you have every reason to believe that the change
is worthwhile and necessary, but that you want them to help you identify areas that may make the move problematic.
It's important for you to set the tone -- and for that tone to be positive.
If you tell users during the meetings that you don't know if the change
will work -- instead of saying that you're sure it will -- you'll be sending
a message that lacks confidence and potentially make the transition more difficult.
Step 2: Educate
Take these meetings as an opportunity to show users what you're talking about.
Remember: While there aren't many people who haven't heard of Linux,
there are many who don't even know it's an operating system. Show them
examples of how to use it and compare it to what they're currently using.
Step 3: Put the Operating System in Their Hands
Live CD versions are available for almost every Linux distribution. You can
burn a copy of the bootable CD and distribute it to every user. Show them how
they can boot from it and begin to work within the operating system without
worrying about how it'll affect what's currently installed on their machine;
if they get stuck, they can pop out the CD and reboot back into their original
operating system.
Encourage users to boot the CD and experiment -- open files they normally access,
try various operations, etc. It's important, however, for you to explain that
they're running from the CD and not the hard drive; the OS will be slower, they
won't be able to save configuration changes, and so on. Make sure they
understand these limitations and that this is just a trial. They won't be faced
with these same limitations if the operating system were actually installed.
As an example, Figure 1 below shows an Ubuntu 7.10 Live CD booted and accessing
a file on the native NTFS file system. That file was created in Microsoft Word,
but can now be accessed and edited in OpenOffice.org Writer. The more users
try to access their files, the more they can get used to the interface and talk
honestly about it.
[Click on image for larger view.] |
| Figure 1. With
the Ubuntu Live CD, you can access existing Office files on the system with
OpenOffice.org applications. |
A couple of notes: First, virtualization lets users run multiple operating
systems side-by-side without needing to boot into one or the other. While that's
useful for administrators, it can be confusing for users, and I would discourage
taking this approach.
And second, the Live CDs are limited in the packages they include and install
on boot. While you can install other packages while running the OS, it's impractical
(and time-consuming) to do so on a CD-based OS as the changes are lost on boot.
Because of this, you either need to know the extent to which users can experiment,
or move to something more expensive -- like bootable Flash from Mandriva --
to let them experiment.
Step 4: Listen
Now that your users have tested the operating system you're considering, listen
to what they have to say. Some of their comments will be frustrating -- users
who complain through their daily operations will probably receive this change
in much the same way -- while others will be so sugar-coated as to be completely
unrealistic. Discount both extremes and listen to the majority.
If it looks like the change should be considered further, create some dual-boot
machines and begin another round of tests that bypass the limitations of running
the operating system from a CD and in memory. If, on the other hand, your users
have decided that the change won't work, then accept their findings and respect
them by not staying on the topic.
Regardless of which direction you take, don't forget these two things: One,
document the findings. Besides user buy-in, documentation is key to the success
of any project. You should create this documentation no matter what action you
end up taking -- you never know when you'll need to refer back to it again.
And two, thank everyone involved. This is something administrators -- and managers
-- don't do often enough.
About the Author
Emmett Dulaney is the author of several books on Linux, Unix and certification,
including the Security+ Study Guide, Fourth Edition. He can be reached at [email protected].