Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

IT Job Descriptions 5

Status
Not open for further replies.

shannonlapekas

IS-IT--Management
Oct 23, 2002
28
US
I am the only IT person for a network with 4 servers and 30 computers. I work am responsible for the website set up and maintenance. As well as all software support. I don't have a job description currently. I am having problems with my peers becoming completely dependant on my helping them with every computer related problem. I am interupted a hundred times a day for things like unlocking timed out programs and resizing columns in Excel. I am falling behind in maintenance and other critical work on the network because of these interuptions. How do you suggest that I help my staff become more self sufficient in their daily work? I would like to go to my manager with a list of ideas. Thanks
 
Based on the title of the thread "Job Description" and the tone of the post, it seems that you are operating under the assumption that helping your peers unlock timed out programs and resizing columns in
Excel in not part of your job. Although you seem to be quite happy to help, its causing you to fall behind of what you do see as your job - the maintenance and critical network tasks. Perhaps you're looking for something in writing, like a job description, from your manager to give you the justification for saying no to your peers when its not convenient.

Since you're the only IT person, I'm afraid that you find that providing peer supprt will be considered as part of your job. Therefore, perhaps the tact would be to approach the situation with the eye on improving efficiency.

One thing that you must do is to be able to prove to your manager the real amount of time spent on peer support. You need to have this documented.

My first suggestion would be to get a policy instituted that requests for support must be in writing - email is fine, but a number of questions will simply go away if they have to be put in writing - this also helps you in keeping track of who is taking your time, and what is taking your time. Its become the foundation of your documentation.

Just to throw out some other ideas.

Due to network critical tasks - peer support will not be available between certain tims, or only available during certain times.

Perhaps you can have scheduled training sessions - an hour a week or so - to address the most common issues so that you'll get less of those questions. (Again, your documentation can help determine the best topics)

Perhaps you can find someone who is comfortable and capable of handling these types of peer support and enlist their help and as a secondary resource. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
 
If enough of your problems are just because some of your users don't know the basics, maybe you can put together a class.

I ran into a similar issue where people were given computers with no prior experience or training. When something went wrong (a paper jam, or the need for another ink cartridge for instance), they were told don't touch it, call IT. I surveyed the users and put together a class or two. Those little annoying calls are at a minimum now. For software issue, I bought CBTs by Keystone. People use them all the time.

Jus a thought.
 
Thank you for the helpful tips. CajunCenturion you read me perfectly. I really am happy in my job. My company is small but they try to give me all the tools I need to do my job. I definitely don't think that helping people is not in my job description. The day before I posted this the exchange database was corrupted. The soft repair failed so I had to do a hard repair. While this was going on no one had access to the corporate e-mail. While I was fixing it 4 times someone came over and wanted me to unlock a timed out application. The last time someone came over I told them that I was unable to help them and told them verbally how to fix it. They just stood there and stared at me like I had lost my mind because I wasn't going to get up to help them. I realized then that I really need to help them become more self-sufficient. It isn't fair to them or to the company to have them be so dependant on one person. You never know when I might be hit by a bus. :) In a company as small as mine you have quite a few levels of skill. Training would probably be a big help. I have computer issue reports outside my office that they are supposed to fill out. No one ever does though. I wonder if there is a way to help them with their timing as well. I would have thought since everyone called to tell me that the e-mail was down that they would have known I was busy fixing it and maybe they should let me work on that. I was obviously wrong. I may need to set up some sort of signal to let them know when I am busy on an urgent problem. Thanks again for the advise. I have some good ideas to go to my supervisor with.
 
Hi shannonlapekas,

Following suggestions might help you.
1) As CajunCenturion points it out, I feel you can track
the the problems if you have the solutions documented
somewhere.Make the same available to Users in an
understandable way.Let me be specfic,
Instead of attending to [unlocking timed out programs]
[resizing columns in Excel] each time, record their
solutions somewhere in a common location which the
users have access to.Let them know thru e-mail.
The solution can be on a [Excel/Word/Notepad file] or
[Webpage in the intranet] or [a solutions tracking tool
like "Remedy" etc.]
The common location can be [A shared folder/drive in
your Office PC Network],
[Intranet], [Shared Folders/ Q & A Section in your local
E-mail systems like Outlook,Exchange etc.]
(Remember:This can prove to be a successful Knowledge
management technique.I use Outlook for this.)
2) Educating the user is the most important thing
that makes them not come to you and do on their own
3) It might take some time to achieve [1] and [2] but then
I bet, its a valuable investment.

I do something similar like [1], like collecting all
the most occuring problems & Solutions / Help in a Tool.
This has helped me save a lots of time in my Application
Support work.

All the best!
 
CajunCenturion you sound on a normal IT overload.

You need help not more documentation.

Like you I am IT Manager/Help Desk/Email etc for 87 people including our police dept. That includes 7 servers and workstations. But, according to my manager, I am not doing anything and more can be on your plate.

You sound like you have a good rapport with your manager. Support is essential from the manager otherwise users will just use. They know you have no outlet or support.

I have been told the documentation is not what is wanted to help users, you know it so do it!

I wish you luck!

 
jockbir,
While it is true that additional help is what everybody truly wants, documentation also has its place. Documentation can be used to accomplish several tasks at the same time.
1) By forcing users to put requests in writing, you're forcing them to think about the problem they're having. This can lead to them realizing they already know the answer, or at the very least save you some time figuring out what problem they're having.
2) Also by forcing users to put requests in writing, the ones that aren't important will go away because it actually requires some effort on their part.
3) Having requests in writing can help prioritize which tasks need to be accomplished first.
4) Retaining documentation about problems can help remind you which solution worked when a difficult problem crops up again.
5) Showing where your time goes can help justify to management why you are requesting additional help (which we all agree is probably a good thing).
6) Documenting where your time is spent can help when management dumps more work on you. "Yes, I can take on another project, but it will cause something else to slip. Here is what I have ahead of me. What do you think my priorities should be?" (Or something like that.)
7) If you need to go to higher levels for support (such as a manufacturer), documentation helps you convey what problems you're having, and reduces the chance that you'll forget to mention an important detail.
8) In the event of a conflict, documentation can be used to show what events happened when. If you have written documentation, and the other party is going off of memory, you'll often have more credibility.

Above all else, every situation is different. What works in one place may not in another. However, simply discarding documentation because you're spending the time trying to keep up with the ever-increasing workload is like (to quote a post-it pad I once saw) being "too busy mopping the floor to turn off the faucet."
 
I am trying to impletment a IM program that will require a person having a problem with their computer to IM me. That way I have the problem in writing. When I send them a solution (if there is an easy one) I am requesting that they keep a book of the repairs so they do not have to come to me every time they have a problem. On my end, I am putting together a book of the problems they have sent me and what my solution was to the problem. I am sharing this with my manager on a weekly basis in our weekly team meeting. So far so good. The staff seems to like it because they get ahold me quicker and get updates as to when a problem will be resolved. I am getting more done during the day than I have been able to in the past.

I think what it comes down to is that I have a good supportive manager though. If my manager actually believed that I sit in my office twiddling my thumbs all day I doubt that I would be able to convince her that I need the staff to be more self sufficient. She is aware that I work from home most nights and come in on most weekends so it is easy for her to see that I am busy.

I appreciate all the good feedback. I had been letting documenting problems slip because I was feeling overwhelmed by my job. I think that getting back into the good habit of documentation will let me have a good reference in the future.
 
Hi Shannonlapekas, I'm excited to share this with you, its my first post. I recommend that you do a quick Database with the types of support calls. Then look into creating a (e.g. “Job Aid”) specifically for the recurring problem questions in order to be proactive with future calls. I support 260 users and this is what was done. 1. Recommend a how to do workbook for the self/learn teachers. 2. Create a Job Aid with visual help (e.g. pictures). 3. Training class no more than a hour with a specific target in mind. 4. You taking a class on prioritizing workload for your own self-development and survival.
 
At my work, we have access to training cds. Personel can use them on their own time or at work in order to learn the skills. Perhaps your company would be generous enough to offer to purchase a set of training cds for the software that your company uses. Then new employees or employees that need to use those programs can then do the tutorials on their own to learn the skills necessary for the job.. Education does wonders!
 
draft a job specification for discussion with your manager
Best of Irish Luck, David.
djwilkes@hotmail.com
 
Hi,

Try setting up Frequently asked Questions articles on those you get asked all the time and put them somewhere that people can get to them - either on the intranet or on a shared directory on the fileserver, which everyone else has read only access to, but make sure that readers know suggestions for improvements are welcome. Then you can tell people to RTFF (read the flipping FAQ)

John
 
I agree with JrBarnett & Cajun.

My case is almost simlar Shannon. When I first came in 2 years ago, I had to answer to each and every calls of every little easy to solve problems. Like how to add a receipient in the address book, how to delete an entry, etc. At first, I tried to force them to write down what problems they are having in a logsheet in my room. The response wasn't great. They liked to call because they felt that I could respond faster. I do but sometimes I'm just tied up with trying to revamp the intranet so I don't respond as fast as the users like to have. Finally my colleague and I finished the intranet and all procedures and problems that are easy to settle by the users themselves were placed on the intranet. We just emailed to all of them the URL and they have to check before coming to us regarding more major problems.

It takes some time for the users to settle down and bother us less with minor problems. I've also started taking down notes on what I do everyday so that I can type a report to my boss on what I'm doing. It helps me re-think some of the ways I can do to reduce user problems.

Whenever the users call, I ask them exactly what is the problem before I go over.
 
This is an interesting thread and one containing some very good ideas about how to share/cascade knowledge. As Shannonlepekas mentions above, there is something in the 'get hit by a bus' syndrome in that it is better to share knowledge rather than have the company grind to a halt because the Oracle (and I'm not talking RDBMS here) isn't available. The flip side to this is that the graveyards are full of 'indispensible' people and some way some how the show will be made to go on ;-)

I'm really pleased things appear to be working out for the good of everyone involved - long may it continue.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top