156 iNForMAtioN tecHNoloGY AND liBrAries | DeceMBer 2011 Mark Dehmlow Editorial Board Thoughts: Sharing Responsibility in the Digital Age T his topic is very resonant for me because this past year we launched a new interface to our catalog, rich with all of the features that our users have been self-trained to expect from browsing the Internet. We actually launched this project in public beta for two years, T–W–O years. I should also mention that the initial implementation team was diverse, drawing from technol- ogy, public services, collections, and technical services. Yet, when we launched the project into production, it was only then that we heard concerns and complaints. Those concerns revolved around two things—first, there was functionality in the classic catalog that wasn’t in the new one, and second, people were used to the old way of doing things and didn’t know how the supposedly more intuitive interface worked—a kind of Opacholm syndrome, and more importantly for librarians, they wanted to know how to exploit the system powerfully. We also found during the first semester, there were few instructors teaching the new system because they were afraid they couldn’t speak authoritatively about it. People are creatures of habit and even though something might be easier to learn if it were your first exposure to it (Macs vs. PCs anyone?), often times changing from a more com- plex, but well understood, process is difficult. I remember years ago at another institution I worked for, helping the organization move from a menu driven ILS interface to a graphical user interface. It required staff to actu- ally rethink the process they were performing because although the GUI is able to make the process more effi- cient, it also hides many of the more mundane parts of it. With all of those concerns on the table all of a sud- den, what did we do? We spent the Summer after our production launch providing targeted training sessions and gathering in person feedback from our internal stakeholders. It probably amounted to more than thirty meetings over the course of three months. We synthesized feedback, identified the biggest pain points, and spent a couple of months developing solutions. Providing a more organized training program and targeted feedback ses- sions as a replacement for our more generalized call for input bought us a lot of goodwill internally. It also gave us some direction on what areas to focus on and opened more dialog with the rest of the library. In the end, it is really important for all areas to be responsible for trying out new systems, even if those responsible are doing more outreach than simple general calls for participation. In some ways, those deploying new systems have the greater onus in this relationship in that they are driving many of the effort; this is especially critical for changes that have broad impact. Taking a more organized and proactive approach to training and accli- mating our organizations to change can go a long way to reducing conflict and stress. Everyone is extremely busy, and the tendency for people is to ignore the things that aren’t directly in front of them. Making efforts toward a more proactive strategy raises awareness and by meeting in person, you show people that their input is valuable enough to make time to listen and talk to them. Taking this type of approach is important even in the cases where projects are managed by committees. Liaisons don’t necessarily provide organizational saturation and often- times the vital information about a new system is filtered through their own sense of what is critical. A good start to determine how much communica- tion is needed is to first gauge the potential impact—if a change affects more than a certain percentage of the library and its users, it probably means it will require a good deal more outreach so people don’t feel quite as off balance when the change is implemented. Those deploy- ing projects should add a couple of months onto the end of planning cycles to help provide training and gather feed- back in a hands on way—e-mail announcements are more often ignored than not given the sheer amount of e-mail everyone gets these days. Another possible strategy is to devise testing scripts for anyone trying the system to fol- low as opposed to just having them “try it out.” A script will give people some direction and hopefully get them into system functionality that they otherwise could miss by trying it without any specific goal. I am not so naive to think we will reach an all- encompassing-Kumbaya moment where communication is perfect and everyone agrees on what kinds of changes to implement in our organizations. I do think though, that teams and individuals who are implementing new systems can help alleviate anxieties if we build more time into our deployment processes to ease our organizations into change instead of hoping they learned how to swim before we all jump in. Mark Dehmlow (mdehmlow@nd.edu) is head, Library web Department, Interim head, Library Information systems De- partment, hesburgh Libraries, university of notre Dame, notre Dame, Indiana