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.

Figure 1
[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].


comments powered by Disqus