An old joke about the restaurant business goes something like this: In a busy palace of cuisine, one waiter says to another during a rare idle moment: "Gee, this would be a great job if we didn't have any customers to wait on." Alas, however true that remark might be, without any customers to wait on, there would be no job, either. IT managers would do well to ponder the benefits of preparing their users for changes in the same vein,...
so as to forestall the more vexing aspects of supporting them in the aftermath of inevitable changes in the IT infrastructure.
The secret to making users happy is to arm them with information and equip them with the tools they need to do their jobs. Where changes to systems, software and hardware are concerned, this practice can be summarized in the short series of maxims presented and briefly explained here. The basic underlying principle, however, is to communicate early and often, and to make sure that users have the information, training and support they need to cope with those so changes so inevitable in the workaday life. This does involve some extra planning and effort, but the results should ultimately save time, money and wear and tear on IT, help desk and technical support staff.
1. Provide plenty of warning: When change is necessary, let your users and their managers know well in advance. With enough advance notice, in fact, user and management input can often help improve the kind, quality and quantity of changes that need to be made.
2. Pilot your way to success: The bigger the changes contemplated, the more disruptive they can be. Make a pilot implementation part of your cut-over plan, and involve a group of interested users in the process. A well-run pilot project will teach you what users need to know, where problems and pitfalls lie, and where and what kind of advance training and communication are needed to get the rank and file ready to make a switch. This also provides a great opportunity for IT staff to become familiar with new systems and capabilities, and to train up help desk or technical support staff before the pilot gives way to full-scale deployment.
3. Ask for and act on feedback: Make users feel like their opinions count, and they'll often go to great lengths to share them with you. A Web-based system that permits users to post comments or suggestions can still be moderated to separate the wheat from the chaff (but all responses should get an e-mail acknowledgement at the very least), and actionable or interesting items posted and shared with the pilot and (eventually) the entire user communities. Prizes (free lunches, an extra hour off from work, or other low-cost items) can provide additional incentives for participation and boost feedback quality. Often, some of the best ideas for preparing users for change come from pilot users who suggest what would work best for other users who share their needs, concerns and job roles.
4. Keep track of common problems, pitfalls, misunderstandings and questions: Check any active forum or message online and you'll see more knowledgeable users or experts holding forth for the less informed or experienced, but you'll also invariably find a gold-mine of frequently asked questions and their answers. Known as FAQs, such documents seek to distill common issues, solve typical problems, and enshrine the collective wit and wisdom of experienced users for the benefit of their less-experienced or knowledgeable brethren. Any well-run changeover operation will use its pilot population to identify the core questions (and answers) that should go into such a FAQ.
5. Let the pilot drive the full-scale deployment: Developers, managers and users all represent important constituencies when it comes to funding, creating and using new systems and services. Unfortunately, all three groups often have very different ideas about what kind of information is important and what kind of training they need. It's essential to start out with some kind of training during the pilot, but to refine and improve that training based on community feedback as initial training efforts are built and delivered. Assume at least half of what you're saying and doing will have to change and you may be pleasantly surprised when your estimates turn out to be too liberal.
6. Make sure all the pieces are in place before the big switch occurs: Far too many introductions include no pilots and simply present users with a new system and a "sink-or-swim" approach. Far fewer headaches will occur -- and far less helpdesk or technical support activity needed -- if users are informed and trained in advance, and helpdesk and technical support likewise prepared to provide help and assistance from the moment that new systems or services go live.
7. Maintenance is hard to do right, but try anyway: The temptation to rest on your laurels -- at least for a while -- can be irresistible once a launch is underway and new systems are up and running. But that's the time when polling users becomes even more important. Now, answers to questions like "What else do you need to know?" "How can we prepare you to do your job better?" "What don't you like about the new system or service?" "What more can we provide by way or training?" and so forth become even more important. Technology is indeed a key to improving productivity, but nothing beats its informed application in the hands of interested, knowledgeable users.
Ed Tittel is a writer, trainer and consultant who specializes in markup languages, information security and IT certifications. He writes and answers questions regularly about IT careers and organizational topics. E-mail Ed with comments and questions at firstname.lastname@example.org.