Embedding Collective Ownership in a Systems Migration

Editor's Notes

• #2: Introduce ourselves… Our Powerpoint is on Sched/Slideshare with references and recommended readings. In our time together, we’ll spend some time going over what we did in our migration, how we did it, and why. We hope to do this somewhat quickly because what we’d really like to do is talk amongst you about how we can use system migrations to shape our libraries’ organizational culture toward deeper collaboration, team learning and taking initiative from the ground up. We are calling this “collective ownership” and we’re interested in how you can pursue collective ownership in a huge, complex project like a system migration.
• #3: Here is our agenda for this session. We’ll begin with some background about our library and our migration project. This shaped our perspective on what a system migration means for a library. Then we’ll go into more detail about how we built collective ownership into our processes. We’ll end with takeaways including discussion of the NASIG Core Competencies and supporting learning at the individual and organizational level. .
• #4: University of Redlands is in Redlands, a city of 70,000 in southern California between Pasadena and Palm Springs. It’s a private, teaching-intensive liberal arts university with a College of Arts & Sciences and Schools of Music, Business and Education. Johnston Center allows students to create their own interdisciplinary concentrations. Spatial and GIS focus with ESRI (maker of mapping software) the largest employer in the area. Armacost Library’s mission emphasizes self-directed learning and critical pedagogy. We have 7 librarians, 6 FT and 2 PT staff supporting nearly 5,000 FTE on the main Redlands campus and regional centers.
• #5: Our migration included moving from Innovative Millennium to Ex Libris Alma and Primo (our first ever discovery service) and OCLC ezproxy. We cancelled Link+ consortial borrowing. Other systems remained the same.
• #6: Our migration experience included four phases: Strategic planning (making the decision to migrate and building partnerships with administration and campus IT) Vendor selection (cycles of progressively more formal research ended in a formal RFP, site visits and contract negotiation) Migration (all library employees assigned to project teams to implement the systems, working with Ex Libris, OCLC and campus IT). Went live June 2017. Post-migration (one year to set up reserves, e-resources, acquisitions, and analytics. Clean data and assessment) I coordinated each phase of the project and Paige was on the team involved with strategic planning and vendor selection. She also facilitated one of our migration project teams (more on that later) Many presentations and articles on system migrations focus on only one or two of these phases, most commonly migration. Since we were at a smaller library we had the opportunity to be actively involved in all four phases of the project and this has shaped our perspective on how system migrations affect a library.
• #7: Migrations change a library in at least three dimensions. Technology changes (this is what we talk about most commonly at NASIG). System architecture (e.g. client-server to cloud computing), support for new protocols and standards (e.g. SUSHI) and staff adapt their skill sets to take advantage of the new functionality. Much of the ER Core Competencies is devoted to understanding change in this area. Migrations also change the library as a workplace or organizational culture. People need to learn to work together in different ways or take on new roles; this changes their professional identity. People have been known to retire or leave because of a system migration, and new people may come in to fill new or re-defined positions. As staff come and go, traditions are disrupted and re-formed. The migration fits into the organization’s existing narrative and also extends that story. And migrations affect the way that patrons see the library, and its impact on their lives. A system migration might bring a new user interface. It might allow the library to offer new services or might mean the end of a popular existing service. How libraries communicate with patrons about these changes sends signals about their willingness to be user-centered and support their needs. System design also impacts information literacy because it communicates expectations about how library users are supposed to interact with information (e.g. discovery services normalize a single search box and support running a particular strategy: run your search first, refine results later via facets)
• #8: Shared values guided us in responding to each of these dimensions of change. We wanted to maintain the agency of our staff and faculty librarians throughout the migration process, rather than having the change be driven by technology, an ILS vendor or upper administration. As we prepared to migrate, we attended conference presentations and heard about directors who had made unilateral decisions about whether to migrate or which system to choose, leaving staff feeling powerless. Or libraries who were frazzled by the relentless pace of the migration, or felt disappointed that the system they got didn’t meet their requirements. We read articles by instruction librarians who resented having to teach through a discovery service that they believed was actively undermining their work. We took these concerns seriously and planned for how to address them. We saw the role of library leadership as marshalling the resources needed to support decisions by front-line library employees. The role of the vendor was to be a true partner with us (e.g. Ex Libris proposed the migration plan but we modified it heavily to fit our needs) The new system was an opportunity to build collaboration with other units on campus and solve problems (IT, business office, student financial services [fines]). Also an opportunity to build capacity within the library. Despite being a small library where we each wear multiple hats, there hasn’t always been consistent understanding of how our work is interconnected, or willingness to cross-train and back each other up to provide seamless services for library users when key staff are out of the office . We wanted staff to know that decisions about configuration and data migration have library-wide impact and they need to take their colleagues’ needs into consideration when filling out the migration forms. We also tried to consider the needs of library users and particularly how the new system would support teaching and learning – our library’s bottom line. We focused on the user experience and information literacy. Would the system make it easier to accomplish ACRL Framework tasks (evaluate authority, search strategically, recognize the value of information, etc.)? Would we have flexibility to customize the interface? How is kb exposed in the discovery layer?
• #9: These values were voiced in many conversations over time, and particularly in library leadership meetings. In 2016 our director retired unexpectedly due to health reasons and our Provost asked several of our librarians to serve as interim library leadership in a matrix structure. Currently our team is our instruction coordinator as Interim Director, myself as systems librarian and Interim Assistant Director, and collection development coordinator contributing advise (he served as interim director for several years in the 2000s). When we started we agreed that we wanted a weekly standing meeting and recurring agenda topics helped us develop our values for the migration project: We discussed what the library operations and materials budget is for and monitored progress on spending it down. We negotiated with the Provost, ITS and other units on campus for resources that we needed to support our staff and operations. >> Prepared us to make compromises and seek collaborations to pay for the ILS we wanted, building agency for our library. >> We paid for the one-time migration fee by shifting money around in the library budget and convincing the Provost to tap a development fund. We reached an agreement with ITS to pay part of our annual maintenance. Discussed staff evaluations and dealt with personnel issues – addressing negative behavior and filling staffing gaps because of turnover before our migration. >> Prepared us to think strategically about who would do what on our migration project teams and build collaboration and cross training into the structure of the project. >> Came up with groundrules for how teams will work together (Paige will say more about this) Talked about big picture of how we support library users and what kind of workplace we want to be. Our interim director articulated the philosophy: “I want to work in a place where my colleagues support my work and we help each other succeed.”
• #10: Next, I'll share a bit more about our values and how we embedded them into our process.
• #11: Chances are that if you're attending this session, you are either a decision-maker or exert some degree of influence with systems-related decisions. If you want to embed collective ownership into a system migration, it helps to remind ourselves and empathize with what it’s like to be on the receiving end of systems decisions. In my next slide you'll find that many of these feelings and experiences relate to each other like a set of dominoes in that, one thing will affect another. Given our positions, it's important that we proactively seek to stop or otherwise prevent a negative domino effect.
• #12: In a systems migration colleagues will face unknowns. As they lose status and authority with the outgoing system, they may struggle to find their place in the library. This can affect self-esteem, and how satisfied or safe people feel around their co-workers. As a result, it's easy to see why colleagues may struggle to see this change as a positive thing.
• #13: In their research, Yeh & Walter state that one of the most critical factors for success is involving colleagues in decision-making processes. Baronas and Louis back that up, and underscore the value of making things predictable by outlining what will happen and when. They also encourage us to empower people with meaningful tasks. It’s useful to keep this in mind when evaluating vendors. A vendor's ability to provide updated and well-organized documentation, will make it easier for colleagues and your leaders to learn, engage in decision-making, anticipate next steps, and develop expertise in parts of the system.  
• #14: The ability for colleagues to do these things was especially important given our vision to use our systems migration to increase agency, collaboration, and user-centeredness.
• #15: This vision can also be conceived as spanning across being more self-oriented and being more other-oriented.
• #16: As an extension of this vision, a lot of work went into addressing challenges to realize opportunities. One book that that helped me comprehend how we might move from one column to the other was Eric Toshalis’s 2015 book "Make Me! Understanding and Engaging Student Resistance in School." In his book, Toshalis advises teacher to maintain high expectations of students even when encountering resistance; and that one way to meet that resistance is to provide more support. The point being that if you increase the challenges that your colleagues must face, you must also increase the amount of support you provide to your colleagues. 
• #17: One of the first things our library did was to assign everyone to at least one team. Considerations like workload, strengths, and time commitments were taken into account, but everyone participated in the migration.
• #18: Each team had insiders and outsiders so that, those with day-to-day expertise were balanced with fresh ideas, questions, and perspectives.
• #19: Teams were facilitated by an outsider who served to facilitate, rather than lead, meetings. Without voting rights, these facilitators helped teams figure out what they wanted, and lead themselves.
• #20: For this to work, everyone had to come to table, and come to the table as learners. Facilitators and leadership emphasized that no one knew more or knew better than anybody else, and that we were all learning together, at the same time. The leadership and librarians understood this clearly, but I think it took a while for the staff to believe this. Once they did, I think it helped them take their rightful place at the table. 
• #21: Looking again at team structure, individuals were carefully chosen to serve on at least one team. Those that did serve on multiple teams or liaised with the vendor, acted as bridges of communication between these groups. You might notice that even here, people had others to help them carry the load, and no single person had to work alone.
• #22: In addition to all this support, teams worked transparently and were held accountable to themselves and each other. Meeting agendas and minutes were regularly uploaded to the cloud where anyone in the library could easily access them at any time. This also helped migration leaders stay abreast of team activities.  Next, we'll look at how things worked at the team level. 
• #23: I facilitated the Access Services team, and while I had never worked closely with this department, there were a few things I knew from having worked there for several years. For example, I knew that this group was more extroverted as a whole, and could appreciate laughter and fun, perhaps more so than other teams within a meeting setting. Knowing that the room we were to meet in was 3-4 times larger than it needed to be, I knew that people would disperse like the they do in a movie theater. To counter this without explicitly requiring that everyone sit together at the table, I used a deck of cards and had us play a quick game at the start of our first meeting.  
• #24: Knowing my team and knowing what the research says about system migrations and resistance, I underscored as often as I could and as much as I could that we each have something to contribute, that fear and anxiety are normal, change is difficult, so we all need to support one another and give each other room to make mistakes. Furthermore we worked to make visible what would otherwise be hidden.
• #25: For example, one way I made the hidden visible was by visually sharing everyone's weekly time commitments related to migration. This made it easy for team members to see how commitments compared between part-timers and full-timers, insiders and outsiders, and supervisors and supervisees. 
• #26: I also had everyone (1) think about how much power they had within the context of our university, (2) think about how frequently they'd be working with the new system, then (3) plot themselves on this graph. Once everyone plotted themselves on the graph, we all took a moment to see where everyone was located on the graph, observe where we were in relation to others, then added other groups like technical services, student workers, and IT to the graph. We then discussed how to rearrange ourselves and others in ways that made sense to us. 
• #27: This helped us to have a shared understanding (1) that those who worked most often with the system, related policies, and were part of this team were well-positioned to inform team discussions; (2) that those who didn't work as closely with the system and policies but had some degree of power (like the Access Services Supervisor and Library Director) were well-positioned to support the first group; (3) that the team had to consider those who had enforce systems configurations and policies (like student workers); and (4) that those most impacted by team decisions would be students. This helped clarify who was responsible for what, and the reasons behind this.
• #28: To increase predictability, meeting agendas which were purposely consistent and predictable. This consistency and predictability became especially important because I had each team member develop expertise in a certain area and later facilitate a meeting on that area. Each agenda was provided one-week ahead of time, focused on one topic, listed where and when to meet, who was responsible for taking minutes, where our time would be spent, and related homework. We also followed a rhythm beginning with an opening activity, reporting out from other teams, suggesting changes to team ground rules, and ending on a positive note.
• #29: These opening and closing activities were scripts I had everyone follow no matter how uncomfortable it made them. For example, I feel distracted because I have a deadline. I'd like to be a better team be being present and not thinking about my deadline. I hope to learn more about handling requests. I could use some help with focusing on requests rather than my deadline. Sharing challenges, asking for help, and encouraging one another was not something our team normally did. But knowing how hard things were going to be we needed to push past our discomfort and find ways to support one another. My hope was that these scripts would give people some of the words to do this.
• #30: Before I hand things back to Sanjeet, I wanted to share one more activity. Periodically, after learning a number of tasks, I had everyone rate how confident they felt completing certain tasks. At the next meeting, I’d share what I’d received which helped them see that they weren’t alone, or that there were a range of responses.
• #31: We’ve been talking about how system migrations bring change to libraries in multiple dimensions and how we tried to structure our project to encourage collective ownership of this change. Willingness to learn continuously and collaboratively is perhaps the single greatest attribute needed for collective ownership to succeed. So I’d like to conclude by thinking about collective ownership in light of individual and organizational learning, and particularly the NASIG Core Competencies for E-Resource Librarians. These remarks will be aimed primarily at e-resource librarians and those in positions of leadership.
• #32: A common reaction to the Core Competencies is to feel overwhelmed by their breadth. There is a sense that you have to know all these things in order to get hired (perhaps because we created the competencies by examining job ads) I think it’s important to remember that we aren’t born with these knowledge, skills and attributes and we all acquire them over time, whether through formal professional development, learning informally from colleagues, or gaining firsthand experience on work projects.
• #33: I wanted to focus on several competencies that I see as related to increasing collective ownership during a system migration. I grouped them into categories according to the values that I mentioned earlier. To support your library’s agency: Project management (5.2) and time management (7.4) Evaluate vendor products (3.6), system administration (5.6 ), understand technology (2) Persuasive communication including selection of evidence (3.8) and framing (4.5) To build a culture of collaboration: Effective working relationships (4.4, 5.5) Supervision, training, motivation (5.1) Broad communication encompassing internal and external stakeholders (4.1) To promote user-centeredness: “Dogged persistence in support of users” (7.3) Flexibility and open-mindedness (7.1) “Rises above personal frustrations to provide the best possible services” ( 4.3)
• #34: Developing these competencies takes time, we can’t expect to be good at everything right away and we may need multiple attempts. For example, one area that I have struggled with is organizing meetings that make good use of participants’ time and have clear outcomes. Early career experiences leading teams in web redesign – didn’t prepare teams to contribute, uncertain roles. 2011 LFAP cohort: meeting structure enables participation (agendas, minutes, to-do lists, groundrules) Practiced leading ER workflows and chairing 2 faculty committees Systems team vendor research posed new challenges: putting a cross-functional team to different purpose, tighter deadline. Worked with colleague to develop sequenced agendas. Learning is not efficient. Unsuccessful experiences may help people contribute later. When an entire team commits to this kind of learning it scales up to organizational learning and contributes to collective ownership.
• #35: So what ideas can we leave you with? Encouraging to recognize that when something doesn’t turn out well, it’s not the end of the story, but part of a longer narrative of learning that ultimately strengthens us. Can we build safe places to fail and learn into our processes and workflows? We had some instances of using smaller, low stakes situations to put together the pieces for the bigger project. E.g. during the time we were researching vendors, we used the replacement of an expiring Innovative server to learn how to free up money and work with IT on a time sensitive project. This helped us when we needed to set up Ezproxy and Alma external integrations during our actual migration. At each step along the way big decisions were not made alone. A systems team evaluated vendors and chose our #1 choice. Our matrix of directors developed the team structure and agreed on concessions to offer during contract negotiation. Our project teams decided together how to fill out migration and configuration forms. This resulted not just in stronger buy-in but also better quality decisions. For those in leadership: be aware of your own limitations and find colleagues who have complementary strengths. You can’t and don’t have to do this alone.
• #36: Quote from Candise Branum and Turner Maslund’s article on management from a critical librarianship perspective. Collective ownership is not just an effective means to the end of getting a migration done. Putting our colleagues in position to participate equitably in the project contributes to just libraries and just society. This sounds good, so how do we get there? Let’s open a discussion: what experiences do you have with migrations that we can learn from?