You are currently browsing the monthly archive for June 2015.
I noticed this morning a blog post on the Wellcome Library plans to build a cloud-based digital library platform, ‘Moving the Wellcome Library to the cloud‘ It’s a fascinating piece of news. The Wellcome Library’s amibition and scale, talking about having over 30m digitised pages by 2018 and about building a platform that could potentially be made use of by others is interesting to see.
As we’ve seen with Library Management Systems, cloud-based systems are becoming commonplace but where digital libraries seem to be concerned, most of them are operated as locally hosted systems. The article also talks about the use of IIIF (International Image Interoperability Framework) which is something for digital libraries to take notice of. It also flags some developments to Wellcome’s media player to create a new Universal Viewer to handle video, audio and other material. Given how tricky we’ve found getting accesible media players it will be interesting to keep an eye on these developments.
Mention of APIs, commodity services and APIs are also in scope. Something definitely to watch for the future.
So we’re slowly emerging from our recent LMS project and a bit of time to stop and reflect, partly at least to get project documentation for lessons learned and suchlike written up and the project closed down. We’ve moved from Voyager, SFX and EBSCO Discovery across to Alma and Primo. We went from a project kick off meeting towards the end of September 2014 to being live on Alma at the end of January 2015 and live on Primo at the end of April.
So time for a few reflections about some of the things to think about from this implementation. I’d worked out the other day that it has been the fifth LMS procurement/implementation process I’ve been involved with, and doing different roles and similar roles in each of them. For this one I started as part of the project team but ended leading the implementation stage.
Tidy up your data before you start your implementation. Particularly your bibliographic data but if you can other data too. You might not be able to do so if you are on an older system as you might not have the tools to sort out some of the issues. But the less rubbish you can take over to your nice new system the less sorting out you’ve got to do on the new system. And when you are testing your initial conversion too much rubbish makes it harder to see the ‘wood for the trees’, in other words work out what are problems that you need to fix by changing the way the data converts and what is just a consequence of poor data. With bibliographic data the game has changed, you are now trying to match your data with a massive bibliographic knowledge base.
It might be ideal to plan to go live with both LMS and Discovery at the same time but it’s hard to do. The two streams often need the same technical resources at the same time. Timescales are tight to get everything sorted in time. We decided that we needed to give users more notice of the changes to the Discovery system and make sure there was a changeover period by running in parallel.
You can move quickly. We took about four months from the startup meeting to being live on Alma but it means that you have a very compressed schedule. Suppliers have a well-rehearsed approach and project plan but it’s designed as a generic approach. There’s some flexibility but it’s deliberately a generic tried-and-tested approach. You have to be prepared to be flexible and push things through as quickly as possible. There isn’t much time for lots of consultation about decisions, which leads to…
As much as possible, get your decisions about changes in policies and new approaches made before you start. Or at least make sure that the people on the project team can get decisions made quickly (or make them themselves) and can identify from the large numbers of documents, guidance and spreadsheets to work through, what the key decisions you need to make will be.
Get the experts who know about each of the elements of your LMS/Discovery systems involved with the project team. There’s a balance between having too many and too few people on your project team but you need people who know about your policies, processes, practices and workflows, your metadata (and about metadata in general in a lot of detail to configure normalisation, FRBR’ization etc etc), who know about your technology and how to configure authentication and CSS. Your project team is vital to your chances of delivering.
Think about your workflows and document them. Reflect on them as you go through your training. LMS workflows have some flexibility but you still end up going through the workflows used by the system. Whatever workflows you start with you will no doubt end up changing or modifying them once you are live.
Training. Documentation is good. Training videos are useful and have the advantage of being able to be used whenever people have time. But you still need a blended approach, staff can’t watch hours of videos, and you need to give people training about how your policies and practices will be implemented in the new LMS. So be prepared to run face to face sessions for staff.
Regular software updates. Alma gets monthly software updates. Moving from a system that was relatively static we wondered about how disruptive it would be. Advice from other Libraries was that it wasn’t a problem. And it doesn’t seem to be. There are new updated user guides and help in the system and the changes happen over the weekend when we aren’t using the LMS.
It’s Software as a Service so it’s all different. I think we were used to Discovery being provided this way so that’s less of a change. The LMS was run previously by our corporate IT department so in some senses it’s just moved from one provider to another. We’ve a bit less control and flexibility to do stuff with it but OK, and on the other hand we’ve more powerful tools and APIs.
Analytics is good and a powerful tool but build up your knowledge and expertise to get the best out of it. We’ve reduced our reports and do a smaller number than we’d thought we need. Scheduled reports and widgets and dashboards are really useful and we’re pretty much scratching the surface of what we can do. Access to the community reports that others have done is pretty useful especially when you are starting.
Contacts with other users are really useful. Sessions talking to other customers, User Group meetings and the mailing lists have all been really valuable. An active user community is a vital asset for products not just the open source ones.
and finally, Reflection Twelve
We ran a separate strand to do some user research with students into what users wanted from library search. This was really invaluable as it gave us evidence to help in the procurement stage, but particularly it helped shape the decisions made about how to setup Primo. We’ve been able to say: this is what library users want and we have the evidence about it. And that has been really important in being able to challenge thinking based on what us librarians think users want (or what we think they should want).
So, twelve reflections about the last few months. Interesting, enlightening, enjoyable, frustrating at times, and tiring. But worthwhile, achievable and something that is allowing us to move away from a set of mainly legacy systems, not well-integrated, not so easy to manage to a set of systems that are better integrated, have better tools and perhaps as important have a better platform to build from.