Basics for Adopting Linux/Open Source - page 2
Changing Some Old Ideas
The first big step in starting any project of this nature is to honestly assess the needs of your company and see what kind of changes are really needed. Notice the emphasis on honest. While you might want to rip out every licensed copy of Windows in your company, you obviously can't do this in a practical application of change.
When you look a move to open source software, don't just prepare a report on the numbers. That's easy, given the vast disparity in licensing costs between closed-source and open-source applications and the labor cost savings gained from any move to a Linux platform. The numbers are good, but they cannot comprise the entirety of your arguments vis a vis Linux.
Include in your evaluation, then, a look at the general readiness of the department or team you want to try to migrate to the new software. Are they motivated? Are they optimistic? How's their morale? If they are having problems in any of these areas, you may want to pick another group to be the prototype area for change. Also, see how they are doing on their workload. If they are perpetually several days behind schedule, they may not be a good group to experiment with.
Next, draw up a list of incentives for the team so they know what they're gettng out of this. Don't just tell them that "management said I could experiment on you, so there." That will not only de-moralize them, it will also make them so ristant to change that even if Linux could change lead into gold, they won't sign off on it.
While you're making this list, focus on the team's requirements. Maybe a complete desktop renovation is what they need, or maybe what will help them more is a complete back-end replacement of their server platforms. Try to identify the one change that will do the most good and then stick with that. Don't change platforms willy-nilly just for the sake of "Linux is good."
Be sure you know how the team works. Who does what, and what is it they do that is so important? How does the team's output integrate with the rest of the company?
A classic trick to software adoption is recognizing people on the team that are technically-minded or willing enough to become early adopters. These folks serve two purposes: they help work out the early bugs in the platform switch and they will serve as pseudo-support for the rest of their team after the entire migration has been implemented. If you're really lucky, these people will also be opinion leaders on the team (and maybe in the overall company), so you'll get some good press, too.
As you're doing this, make sure everyone who needs to be in the loop is in the loop. Don't go off and work some dark magic on your own and then pop up three weeks later and say "done!" If no one sees how you made the changes, they might be a little leery of later making those changes company-wide. In other words, document, document, document.