I had a great opportunity to travel to the northwest this month to attend the Oregon Library Association meeting (briefly) and the Montana (combined with Mountain Plains) Library Association meeting (slightly less briefly). I’ve been wanting to highlight one presentation I saw from that trip ever since I got back and this is the first free moment I’ve had to put it all together.
In Oregon, I was participating with colleagues Carl Grant from Ex Libris and Neil Block from Innovative Interfaces in a pre-conference on library-vendor relationships. That sounds like enough fun in and of itself, but it’s actually not what I want to highlight. Before we spoke, Steve Shadle from the University of Washington and Steve Casburn from Multnomah County Library gave presentations on “Partnerships with vendors : case studies and lessons learned.” Each was talking about the early adoption of solutions by their libraries and gave advice to other libraries considering the same.
Initially I sat up and took notice because I have been a seeker of such early adopters for the last three years. This has been a successful endeavor. Nevertheless, our team has been struck by the amount of change management required even for libraries who don’t fear (and those who actually embrace) early adoption. Steve Shadle presented a step-by-step approach to increasing the likelihood of a successful implementation. It was only icing on the cake that he happened to be talking about UW’s WorldCat Local implementation.
But the other thing that struck me was not the comparison to activities at OCLC, but the similarities I saw in UW’s plan to the one that was implemented at NCSU when we were implementing the Endeca catalog. It probably seems like a truism at this point that the philosophical and political battles are much larger than the technical ones. A successful implementation only has a little bit to do with the solution being implemented and a whole lot to do with how the organization goes about it.
I probably won’t do Steve Shadle’s slides justice, but I was jotting down his steps to success. A smarter man would have asked Steve to co-author this post, but as his slides are not available on the OLA site yet and I was anxious to tell his story, here are the steps he outlined:
- Describe the Problem
- Get administrative support
- Brainstorm with the solution provider
- Develop use cases / scenarios
- Understand your development partner
- Articulate a vision
- Be the first on your block–use early adoption to your advantage to set development priorities
- Be ready to exit if necessary
- Know your data and your systems
- Understand the development culture of your partner
- Understand your own culture
- Plan for success
This is a good list (even though I joked with Steve that he had created a twelve step program). I take full responsibility for the numbering, as he did not number the steps; in fact, since these are often not sequential, it’s probably best not to think of them as steps at all, but a list of ingredients for a successful recipe. If I had to pick my two favorite ingredients, they would be the administrative support and theplanning for success. The latter isn’t just motivational. In UW’s case, it meant, planning for 59% and 101% increases in consortial borrowing and ILL traffic, respectively. The former is a must that we all know about. If your bosses don’t support you, you have a tall hill to climb. If I were to add one thing to the list, it would be “get staff support for administrative decisions.” Many projects have grass roots and require administrative buy-in and resource support. An equal number, I think, start at the top and require the support of grass roots staff to be successful.
The only regret of this meeting was that there were not many, many more people in attendance. As so much of library innovation is happening in partnerships between libraries and service providers, libraries and libraries, or libraries and the open source community, I think it would be great to have even more opportunities for presentations like the one I participated in at OLA. But I’m cooking up an idea on that front as well. More on that later.
The risk of brainstorm with the solution providers is that you got bypassed after you developed and discussed your use case scenarios with them. In other words, they just wanted your ideas not your work, which often took as much effort to be prototyped and finalized as what you did with the finally delivery of the work.
The ground breaking work started with the ideas that were derived from previous knowledge, skills, experience, and training, etc. at interdisciplinary levels, which often got ignored.
What would you do if the environments in which you are allowed to work only permit you to exhibit ideas, not the delivery of work? As soon as they understand your intent, you will be driven out of the office by “invisible forces that could cause negative emotional scaffolding, and other unknown factors,” which I would be very reluctant to associate with the reality. Thank you so much for tips, though!