Setting limits: When to say "No" to end-users

Setting limits
When to say "No" to end-users
By Sandra Gittlen

Network World, 02/11/03

IT has always been a 24x7 operation. No matter what time, day or night, IT managers have been subject to inconvenient pages that interrupt personal time. In the past, pagers mostly went off when gear went down or when applications were faltering. Now, with so many end-users working 'round the clock from home and other remote locations, IT must answer calls from users too.

The problem with this change is the intense burnout IT professionals face. There seems to be no downtime from users wanting assistance for remote access and even home networks. The trick is for IT to set limits.

And I do mean trick. Because essentially what you have to do is train your users to evaluate their own needs. Though every user thinks their problem is urgent, it's the job of IT to show them how to rate their network needs. And IT must give them the tools to solve some of their problems on their own. Here are some tips for setting boundaries.

1. Create a priority list. Similar to the government's color-coded list for terror threats, IT should develop a system for network problems that maps to personnel and hours of operation. If a problem is minor, such as difficulties formatting a Word document, then the user would know who to contact and when they are available to answer that question. However, if the problem has to do with network errors while running the company's numbers at the end of the month, then that would have a different color code and person to contact.

2. IT must know the nuances of business and prepare accordingly. Going back to the numbers example. If IT knows that the CFO's office is going to be working night and day during the last week of the quarter to get the financials in order, then they can plan to be more available during that time period. They must communicate this window of availability to the CFO's office, making sure to assign a person or team to the task. Likewise, if the marketing department is trying to push through a campaign, then IT must be aware of that and have someone at the ready who is skilled in the systems' marketing uses.

3. Publish a knowledgebase online and to the user desktops. Though not all users want to help themselves, many do. If you give them the tools to solve their own problems, chances are they'll give it a shot. One way to do this is to put together a knowledgebase of common questions and their solutions. Many IT departments already have such a program that they use among themselves. The challenge is to create one that is user-friendly.

The mistake some IT departments make when publishing their knowledgebase is to simply keep it online. If one of the problems users are having is getting online (which is a very common problem) that does them no good. So you have to make sure to publish a copy to their desktops. Also, use software that lets you push updated versions of the knowledgebase to the desktop and a central location online (perhaps the company intranet).

4. Have IT workers set limits. IT engineers are great at their jobs because they love to solve problems - day or night. However, if you give users an inch, they'll take a rope and expect your staff to be available around the clock. Even if your team is checking mail around the clock, have them show restraint in answering questions. If users realize that their non-urgent questions are not being answered till the next day, they might stop asking these questions after hours. However, if they know they are going to get instant responses to the most trivial questions, they'll feel free to ask away, wasting your team's time and energy.

As IT manager, it's your job to protect your team. You must guide them in setting priorities as well as being flexible. The more effort you put into creating a system that sets limits and at the same time addresses the needs of the company, the more likely you'll be to save your team from burnout.

Error 404--Not Found

From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

10.4.5 404 Not Found

Error 404--Not Found

From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

10.4.5 404 Not Found

Error 404--Not Found

From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

10.4.5 404 Not Found