Absence from blogging over the last few months feels very much like some form of winter hibernation but it’s mainly been a case of not having too much time for reflection in the middle of a library management system implementation. We haven’t quite finished yet but are a long way through the process and have been live on a cloud-based LMS for just over a month. So I can try to put together some early thoughts about the process and experience.
I worked on our project proposal around Christmas 2012 for a project we termed Library Futures that included a library management system and discovery procurement and implementation. But that wasn’t really the start of the process. We’d spent a bit of time looking at what our needs were and working with some consultants to get a better idea of the best options for us. I’d also had some involvement with the Jisc LMS Change project, all of which helped us to understand what was out there and what our options were. So that takes us back into 2011 and maybe a bit earlier. And a lot of the thinking was about the best timing for changing systems as the LMS market was in the early stages of the ‘Software as a Service’ reinvention and products were (and maybe still are) at an early stage. So by my rough calculation that’s a couple of years in the planning, followed by a year to secure approval, followed by an eighteen month or so procurement and implementation stage. It takes a long time and a lot of effort, and the final stage of implementation isn’t the most time-consuming part.
In the procurement stage we went the full EU tender route and for our requirements catalogue (specification) made extensive use of the LibTechRFP exemplars http://libtechrfp.wikispaces.com/ not just the UK Core Specification but also the examples for the Library Services Platform, Electronic Resources Management and Search and Discovery. And we also needed to add in our own requirements and cut out features aimed more at a traditional ‘physical’ university. It ended up with quite a large and detailed catalogue of requirements. But I’ve always felt that to be important for library systems as the detail is vital (and not just because the successful tender response forms part of our contract). Library management systems have to cover a lot of functions and it’s important to get the detail to understand what using that system will mean for you in practice. Interesting to me though was to find some of our search requirements already getting reused in another systems requirement document in the institution.
I’m always on the lookout for useful new tools for projects, website and so on. So it was good to see a tool like Basecamp being used by the supplier we chose. It isn’t a free tool (other than for an initial period) but it worked well as a way of sharing files and having the sort of discussions that you need when going through the implementation process. I felt the to do list feature worked a bit less well. As a communication tool it worked neatly without being too formal or time-consuming. We’ve ended up using it on two different projects with two entirely different suppliers so it is obviously doing something right.
Final thoughts for the moment are about the range of skills needed in a team putting in an LMS. Some obvious ones such as systems and IT knowledge, procurement and project management, and for libraries obvious areas such as knowledge of the library acquisitions, cataloguing/metadata and circulation processes. But also ones that can get overlooked around training expertise, administrative support, decision making, business analysis and data quality. And above all some determination and team spirit to get through an immense to do list.