The Zombie Stack Exchanges That Just Won't Die
I'm preparing for a conference presentation on librarians' experiences communicating with IT departments effectively. There's not much scholarly literature on the subject, and I suspect most librarians learn through trial and error. I would love input from fellow librarians, so that my presentation is not based solely on my experiences -- what proven, reliable methods of reporting have you discovered? Have you found some things ineffective (especially if they are funny!)?
Melissa
Maybe this is taken for granted but a ticketing system that both the librarians and the IT folks have access to, and like to use is essential. It provides visibility into issues/requests and helps people monitor the progress of their work. They also provide some uniformity to the way issues are reported, which can help in planning.
Having been on both sides of this sort of thing, helping users and asking for help, I think the biggest thing is about clearly explaining exactly what you thought should be happening and exactly what isn't happening without bringing in all kinds of extraneous detail. In this sense, it ends up having a lot to do with imagining what it is that might be the problem and first trying to isolate and make that problem reproducible.
All this said, there are some very real basic vocabulary problems that can come up. I remember once when I spent about five minutes explaining what "drag and drop" meant to a guy who wanted to use Zotero. My hope is that he is now dragging and dropping things all over the place.
Similarly, a friend, who works in IT for a school district recently had a user who reported that they couldn't get on the school website from home. Initial questioning revealed that the user could not access any web pages from home. Further questioning revealed that the user did not have an internet service provider. They had a school given laptop and they thought since the internet is wireless these days that the school laptop would just get that wireless from their house.
All this is to say that IT people in a support role are going to be constantly trying to gauge where you are at in the continuum of computer wisdom. The more specific and detailed information you can give, ideally with information about how you tried a few different ways and can clearly reproduce your problem, the more likely they can help you quickly. Keep in mind that they need to figure out if you are someone who has no idea about computers, someone who needs to be taught drag and drop or who needs to have the nature of internet service providers explained to them.
When I collect information for this purpose I try to keep the questions limited:
It's not clear how much information you are trying to collect for your IT staff, but these few questions give you a sound basis from which you might probe further (you can probe further like you might do a reference interview).
As someone who actually works in IT (albeit, with a degree from a library school), I can tell you that even communication between different IT departments (our group + the networking group + the security group) can be rather problematic.
When reporting computer problems, the most important thing, in my opinion, is:
'It doesn't work' or 'my computer is slow' is about as useful as going to a librarian and saying, 'I'm looking for a book'. We need a lot more information than that. So, for example, good trouble reports:
I was looking at (website), and was at (URL), when I tried to click on the link titled (title). My computer locked up with no error messages, and I had to reboot to clear it. I was using (browser, version) on (machine name) running (OS, version), and I believe I had (list of applications) open at the time. I tried it after rebooting, and it locked up again.
I was using (application), and I tried to use (feature) in the (menu) menu. It gave me a message (exact error string, not some paraphrase). It had worked yesterday with this same document. I tried other documents, and they don't complain, but this one always does.
The problem is that with software, we don't necessarily know what's important or not, so as Henry said, it's going to be like a reference interview, as they try to get various bits of information from you to try to narrow down the problem.
If you can, learn how to take screen shots on your computer -- on MacOS, it's command-shift-3 (you'll hear a camera click sound bite) or for a region, cmd-shift-4 and you'll get cross-hairs to drag a box. For a window, cmd-shift-4, then spacebar, and it'll give you a icon of a camera and you can click on the window of interest. In current versions of MacOS, you'll get a file named 'Screen shot (date) at (time)' on your desktop.
(but if you take more than one, only send them the one that shows the error message or the problem ... you can tell 'em you have more pictures if they need it ... sending 20MB of attachments w/ the trouble ticket isn't productive)
Then try re-creating the problem (assuming it isn't 'hey, there's smoke coming from my computer' ... yes, we've gotten those calls before ... and if you're going to make that call, please make a note of what color smoke it is, after you've unplugged the machine), and ask your co-workers if they can re-create it, so we know if it's a localized problem or not. You can then call in one ticket that something's wrong, rather than have everyone in the department call in that you can't get to the internet. (yes, we know, and if we didn't have people keep coming in telling us 'the internet is down', we'd likely be able to get it back up faster. Yes, we know we said give us 30 minutes 45 minutes ago, but you have to add 5 minutes for every other person who came in to bug us)
I'm not a librarian, but I do happen to be a systems administrator. There are a few key things that are important:
Don't lie or sugarcoat. If you think you did something to create the problem in the first place, disclose this. We'll find it eventually and be mad that you made our work harder. If you are forthcoming in the beginning, there won't be a problem. It's our job to fix things, after all!
Give details or screenshots of any error messages that you see. "It stopped working" doesn't tell me anything. While long strings of numbers or seemingly random words in error messages might not mean much to you, it does to me. Be detailed about any error messages that you see.
If the IT department is unable to reproduce the error, because it is intermittent, keep a log with the date, time, computer, and specific error.
Has anything changed since the last time that the computer/application worked normally? Even small things like updates matter here.
Are you able to reliably reproduce the problem? If I'm able to replicate the issue at will, then I am more able to effectively troubleshoot it. If you have an application behaving strangely and you can give me the exact steps that I can take to cause the same error every time, then I will love you forever.
Keep support contracts on your software! In some work environments, the IT department might not be responsible for buying the software in use, they only support it. If this is the case, please, please, please, pay the yearly fee to keep the support conrtact for that software up-to-date. There's nothing worse than discovering what appears to be a bug in the actual software and not being able to get it fixed because the vendor won't speak with you, since you're not under contract.
We have developed an internal problem reporting system via the web that is not as complicated as RT, but still gives our systems department enough information to triage and tackle a problem. Here are the things we ask for:
Urgency
Your name, phone, e-mail
We encourage non-IT library staff to report problems using this form rather than a phone call, which allows us to tackle problems faster and record statistics on our work.
Successful problem reporting also relies on a collegial relationship between librarians and IT. It can be easy to have an "us vs. them" attitude about IT, but in the end we share the goal of helping our users. At our institution some of the librarians are IT, and our systems department has worked hard to foster a culture of openness and collaboration so non-IT library staff will feel empowered to report problems. Once non-IT staff understand that their reports are vital to the continuing success of the organization, they are more likely to report issues.
Before sending a request to IT, nail down what you need as best you can. We can certainly help with this, but the show of effort and respect for IT's time does wonders. From my perspective:
I am a librarian with responsibility to liaise with the IT department. I maintain a prioritized list of medium/long term projects (not tickets) and meet weekly with IT to discuss their progress. For issues: absolutely have some kind of ticketing system, although RT, Footprints, et al leave a lot to be desired for end-user friendliness. Our system copies (emails) me on tickets so I look for trends, old tickets, etc and can contact the IT member who is responsible for ticket management and/or the librarian to clarify information and keep things moving. Vocabulary is a big problem, but maybe bigger is patience: I remind folks that while every ticket is important, the IT staff have only so many hands and hours to work with and we far outnumber them.
in addition to what's written above - some great advice here!, my two cents: not everyone on the library staff needs to be able to effectively comminicate with the it staff - both departments already have their own vocabulary, jargon, time frames, and more importantly, priorities to make discussions complicated to the point of bad bad headaches. what seems to work well is to appoint a few different staff members in the library branch to be an it liason.