Note: See also this article and this article on the legal aspects of open source licenses. See also this article by Bruce Byfield, but for group migration, please ignore the item on not expecting to need training. ;>
One person learning a new program is a simple process. Decide, learn, do. But switching over ten, a thousand, or ten thousand users can be a little more involved. You get a few more things involved:
- One person decides to switch. With 100 users, it's certain that at least one of them didn't want to switch.
- One person can affect the attitude of many others, positively or negatively. If Chris starts working on the new program, learns to use it, and others see that, then they believe they can use it, too. If Chris doesn't try, doesn't learn, and others see her failing, they think they'll fail too.
- And this is before anyone even starts complaining about, or praising, the product. How users talk about the product, especially the dominant people in your organization, really affects it. How the head of marketing talks about it, how the manager of the desktop publishers for your internal publications group talks about it, how Marge in accounting who's been there 20 years talks about it--all that matters enormously.
- Anytime you do something involving a lot of people, whether it's new software or soap or sandwiches, unexpected problems arise. You really can't over-plan a project involving a lot of people.
To make the switch as calm, cool, and collected as possible, you need to plan. Plan not just the physical implementation, the installation, but plan the social and mental implementation with the people who will use it. To make a somewhat odd analogy, the issue with the space shuttle problems was not really the foam or the O rings. It was the communication between the engineers and the people who made the decision, and it was the culture that made it OK not to report problems. The physical issues with switching to the software can be handled. The most important thing you can do is make sure the human part of the transition is done well.
Here are a few thoughts based on my experience with the product, and what I’ve gathered doing training for other companies over the last four years.
1. Talk to Other People Who've Done It. Take an OpenOffice.org-Using IT Director to Lunch.
Find others who are or have been in your position, and just find out what their experiences were like. You can learn so much from just talking to other people who’ve adopted the program. Get on the users@openoffice.org mailing list (www.openoffice.org) and find other people in your position who are using OpenOffice.org. Google around the Web; maybe you actually know someone at Ernie Ball Music, for instance (http://news.com.com/2008-1082-5065859.html) and can just go over there at lunch and find out how their transition went. Start or join a Yahoo discussion group just for people who are considering or in transition.
Get as much technical and cultural information from them as possible. Others' experience is really valuable.
2. Make Sure It's Got the Features Your Users Absolutely Need, and See What Additional Features It Provides.
Research how OpenOffice.org works and what it can do. This task can be done by you, by your motivated IT person, or anyone else you assign to or hire for the task. But the thing is, you’ve got some core features that your users absolutely must have, some tasks they complete that they must do but might not have to do the way they’re doing.
The drawing program might
allow you to ditch your licenses for Visio or Corel or Canvas or
Illustrator. The data source connection features are extremely
powerful. Keep an eye out not just on what you already use that you have
to have, but on what you can’t do now that you could do with
OpenOffice.org.
A note on Excel macros--some people use them to do things that can be done perfectly well with Calc functions. So if you hear that the macros won't convert, ask what the macros are actually accomplishing.
If you don't find a feature at first, check around. Perhaps more than other programs,
OpenOffice.org has a high ratio of “stuff it can do” to “stuff you can
see that it can do.” For some features, it’s easy when you know how—you
just have to know how. So get googling, get a book, get a free doc
download from www.openoffice.org, get a little training, go to a seminar, ask the users@openoffice.org mailing list, etc.
Don't be afraid to mix and match. If you Sam and Francine must have some Excel macros for certain spreadsheets, then keep a few licenses. You're looking for the best solution, not necessarily purely all open source all the time.
Find the people at your organization
who just love to fiddle with software all day. and ask them (with their
managers' permission) to spend some time just dinkin' around. They'll
find stuff that everyone else misses, and they'll help start culture
that it's cool new software.
There will be at least one very specific thing that users do that you won't expect, that can't obviously be done with OpenOffice.org. (Of course, you can't convert to PDF in Microsoft Office; it's true of any software.) Really pay attention to what the tasks is actually trying to accomplish, rather than focusing on the task itself. There might be a workaround, another feature that does a similar thing, or simply an organizational, non-software solution.
For instance, if Jim really needs to have the flotsam feature, it might be because Dave always asked for documents to be delivered in flotsam format. Dave doesn't actually need it, it's just that that's what he's used to; plus Dave is leaving the organization in a month. Jetsam format might do just as well.
Consider interoperability. Take a few documents back and forth between OOo and Word, or your office suite. See how it works. Consider, and research, how many documents users receive from Microsoft Office users and need to edit, and how many users need to send to Microsoft Office users, and whether those documents need to be edited. If most or all the documents you need to send out can be sent in PDF rather than Word, you're golden. Or if the documents go between formats nicely, you're also a nice warm yellow.
3. Find Other Sources for the Cute Stuff Word and Publisher Provide
One of the things many users really like doesn't have anything to do with the actual software. They like the goodies. Word’s vast collection of clipart is nice but isn't really all that necessary. You can get similar goodies elsewhere. The Big Box of Art has a million images and is $60 or so, and then there's the open source clip art library.
For cool templates, remind users that all their current templates can be opened successfully in OpenOffice.org. So all the pretty stuff still works. There are also many OpenOffice.org templates out there. Just google away--here are some on the OpenOffice.org site.
Publisher does not provide any decent export so all the Publisher files will be left behind. But Writer and Draw are decent alternatives, with use of the aforementioned clip art.
4. Time to Get Your Hands Dirty and Convert Some Test Documents
Experiment with the program. Now it’s time to take OpenOffice.org out for a real spin and see what she does on your organization’s documents. Some transitions, especially now with the enhanced compatibility and filters in OpenOffice.org 2.0, go really well. Some have some interesting tweaks to make that, once made, work fine. It all depends on what your docs are like.
Here are some tips on converting documents.
- Hang out in Tools > Options. There are a lot of windows here that can help. Default tab settings are a big factor. Open a text document and choose Tools > Options > Writer > General lets you fiddle with those. Tools > Options > Writer > Compatibility is another great window; fiddle with these. Try marking the Printer Metrics option first. Click the image to see if larger if you like.
Then open a Calc spreadsheet, choose Tools > Options > Calc > General, and try those settings. Click the image to see if larger if you like.
- Use the Conversion Wizard. You can convert mass numbers of Word files to OpenOffice.org. Choose File > Wizards > Document Converter.
Consider contracting out some of the conversion. If your users don't have to convert it all themselves, they'll be a lot happier.
Don't expect perfect conversion. Even conversion between versions of Word isn't perfect.
<>
Consider which documents you actually need to convert. If you have a document you provide that doesn't actually need to be changed, just make a PDF of it and leave it as is. (You might need to use another product to make the PDF if it doesn't open nicely in OpenOffice.org.) Or print it or scan it, and leave it as is.
5. Get the Influential People On Your Side
This is what I was talking about earlier. Once you've got the program kind of figured out, invite the managers and a smattering of "regular users," including the people who other users listen to, to a lunch and learn.
Tell them the advantages, show them the software, show the cool features, let them fiddle with it, and show off the new features that you don't have with your current software. PDF comes to mind, the drawing program (File > New > Draw) comes to mind. Make some labels and mark the Synchronize checkbox on the last tab of the labels window, then show how you can make a change to one labell and click Synchronize to apply that change to all the others.
Ask for their input. Ask about how they will do their jobs day to day with the new software. Make sure you have a good ratio of people who like it, to people who might complain. Tell all the people who are invited that they're an important part of the adoption process (they are), and that you need their input to ensure that OpenOffice.org can help them do their jobs.
Before the lunch and learn, make sure you have buy-in from whoever's at the top of your organization. Make sure that he or she communicates to his reports that they need to show support for the product, or they'll have departments full of dissatisfied users who don't feel like they can do their jobs with the new software. (Nobody wants that in their department.) Have those managers then show up at the lunch and learn. Not to say "you're using it, get over it," but to show enthusiasm. Have them get a little giggly over the drawing tool (you can do cool 3D stuff) or be overly impressed by the mail merge tool. Not to put on an over-acting show; just to make sure that they demonstrate, as well as state, support and enthusiasm.
Depending on how these go, you might want to have a few.
Another idea to get influential people on board is to give them some say in how the money saved will be spent. If anti-change Sam from Accounting can tell people that he's the one responsible for switching money from the software budget to the health care plan, he might be more enthusiastic.
When you send out reports on the lunch and learn, be sure to mention that Sam, Brenda, and Lucy all had excellent suggestions, and worked hard to provide much-needed input to the IT team.
Consider schwag. Everyone on the OpenOffice.org Transition Advisory Team (your lunch and learns) gets a mug, a tshirt, something. Make'em on Cafepress.com. Order 15 to get a bulk discount. The schwag could be plain, just the OpenOffice.org logo, or be self-mocking, "I Gave the IT Team a Piece of My Mind" or a pun, "Open to Discussion: OpenOffice.org 2006 Transition Advisory Team."
6. Execute a Transition Plan.
As many people say, just do it. Introduce the adoption schedule and let people know that while you’ll be giving them time, training and manuals and rewards. You absolutely must make sure everyone knows they're not going to be
thrown into the new software without help. Make sure they know that
there will be help, there will be time, there will be training and
documentation.
This is also the time to start transitioning your legacy documents to OpenOffice.org, or planning how it will occur.
The other part of this step is the tough love--make sure that people know it *is* going to happen and no amount of objections will stop it. (You've already done a lot of research and gotten a lot of feedback, so you know at this stage that switching is the right decision.) Make sure people know that Microsoft Office or their other office suite will fall off the face of the earth in three months. (Or whatever your transition timeline is.) The exception to this is if you're keeping the old software around to edit legacy documents. In this case, though, you might want to have that software on selected computers, or do something else to make sure that as of the launch date, everyone is using OpenOffice.org on new documents.
7. Offset Fear and Confusion With Information and Support.
Demonstrate how it works to the people who will be using it. People are usually going to be apprehensive about the idea of change, but you can reduce that considerably just by doing a few seminars, demos, lunch and learns, and other short and reassuring demonstrations of what it’s going to be like. Make sure everyone in the organization comes to at least one session. Show the object bars at the top of each application, for instance. The Word and Writer, and Excel and Calc object bars, look very similar. Then slowly show how a few of the core procedures will be performed. Simply knowing what the change is going to be like, ahead of time, alleviates some fear and change resistance. I’ve seen this repeatedly when I do training.
Give short quick-reference handouts at the end of each presentation, so that everyone has at least a little documentation, before they even touch the software.
Again, consider schwag. Give a magnet, button, sticker, etc. to everyone who asks a question during the presentation. Cafepress.com is a goodplace to do this. The person who asks the most questions (constructive ones) might get a USB drive or a small MP3 player or another prize.
8. Show Appreciation.
People will be happier doing just about anything if you recognize the effort they're putting into it publicly. In all communications, in training, in demos, etc., be sure to recognize that they will be the ones learning the new product, that this is a significant task, and that you appreciate it.
Another thing you can do is just plain provide rewards. Suggestions include prizes for:
- The department that completely switches
to OpenOffice.org first
- The person who logs the most “Cool
OpenOffice.org Tips” on the company intranet
- The person who
does the most document conversion.
Motivational rewards can be anything--a department pizza party or trip to the waterslides, an extra day off on a three-day weekend, a weekend trip for two to the nearby national park.
Whatever works, based on your people and the money you’re saving.
9. Teach Users How to Use the Product.
It's important to have OpenOffice training. The training can take
many forms. It can be one book and your in-house open source
enthusiast (who will be patient with users who have less experience than he or she does). You can send everyone in the organization to OpenOffice.org
training or have someone come onsite to train. You can hire someone to teach your internal trainers. You can obtain OpenOffice.org books, training materials, or both. Make sure that everyone at least has a reference book for the department to use.
Make sure everyone has used the product before they have to start using it. You wouldn't give someone a car who didn't know how to drive. Give'em a chance to learn before they have to do their job.
Make sure that everyone has a CD to use it at home. When I do training, at least half the people in each class want a CD to use at home.
10. Consider an Ongoing Joke or a Big Payoff.
When I was at Great Plains Software, our main architect Dave Gaboury wore a Great Plains Dynamics tshirt every day for a year and a half until our Dynamics product shipped. (He had seven.) Maybe for your Openoffice.org project, the IT head wears the same OpenOffice.org project tshirt until everyone is up and running on the software, or maybe he or she dies their hair green, or tries out for American Idol, if all the departments are up and running successfully by the official transition date.
11. Make the Official Switch.
As promised, make it happen. Take the other office suite off all desktops (unless you still need it some places as noted above). People will use what's familiar, if they can. It's like when I went to France in college--I hung out with my friend Stephanie who spoke French much better than I did. When she left Rennes for Paris for her internship--well, gosh, my French got a lot better when I had to speak it and understand it. Go figure. ;>
Happy users are more productive. Happy users say hi to you in the hall rather than growling. Happy users mean you as IT director are happy. And it doesn't cost that much to get all that.
But! Now I am actually writing it! I've got content, it's goin' fast, it's going to be out by spring.
