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!)?
Tell me more
×
Libraries & Information Science Stack Exchange is a question and answer site for
librarians and library professionals. It's 100% free, no registration required.
|
|||||||||||
We're looking for long answers that provide some explanation and context. Don't just give a one-line answer: please explain why you're recommending it as a solution. Answers that don't explain anything will be deleted. See Good Subjective, Bad Subjective for more information. |
|||||||||||
|
I'm not a librarian, but I do happen to be a systems administrator. There are a few key things that are important:
|
||||
|
|
|
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:
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. |
|||
|
|
|
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. |
||||
|
|
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. |
|||
|
|
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:
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) |
|||
|
|
|
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). |
|||
|
|
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. |
|||
|
|
