Problem solve Get help with specific problems with your technologies, process and projects.

Proper planning, communication help avoid user headaches

A recent, informal survey of readers revealed that while admins deal with plenty of technical issues, their most common problems come from users who submit redundant and often ridiculous complaints. Here, Ed Tittel provides seven strategies for improving communication in your enterprise and heading off user headaches before they occur.

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.

More on this topic

Six tips for making a Windows administrator's task of monitoring and restricting user rights easier

Guide to network administration

More Administrator tips

If IT can tell the users what's coming, help them understand and appreciate what's new and different, and work closely and constructively with users not just to fix what's broken or sub-par, but also to improve on what's available, user headaches should be further and fewer between. While a certain amount of pain is inevitable, less is likely when users are too busy getting things done to complain about the obstacles in their way to success.

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
This was last published in February 2006

Dig Deeper on Network Administration

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.