The development of our LMS specification. Part 1: What, how and why?

This is part 1 of an update from the Bloomsbury LMS project team about the development of our LMS specification, a PDF version is available for printing and reading off line.

What, how, and why?

1. What?

In 2012 a group of the Bloomsbury Colleges and Senate House Libraries found they shared a common vision for a 21st Century LMS. The goals were clear and simple:

  • A flagship shared service model
  • Shared access to resources
  • Interoperability

During the summer of 2012 a scoping, scanning and feasibility exercise was carried out – ending with a Functional Specification, Option Analysis and Options Costing for review in October.

Commercial and open source solutions and providers were assessed in the context of their closest match to the vision, goals and strategic directions of the consortium partners.

2. How did we do it?

  • Specification process and sources

The starting point to get the juices flowing on the Functional Specification was the “Unified (‘Next Generation’) Library Resource Management System” document. The project team used the text-based version of this ‘Unified Spec’ (our shorthand) to focus discussion.(This document generously shared by another university, courtesy of Ken Chad’s LibTechRFP site.)

Whilst in many ways superseded, the “United Kingdom Core Specification for Library Management Systems (LMS) UKCS Version 3” was also used on a few occasions, to fill in gaps on core library processes that weren’t reflected in the ‘Unified Spec’.

For the more 21st Century elements of our requirements, sources were more varied and heavily reliant on the skills, experience and vision of those involved. Whatever the source, it often acted as a prompt to say “No, we don’t want that, but we do want this”.

  • Starting point: structure

The first step in the “we do want this” process was agreeing the structure of the Specification – based on discussions around the concept of a 21st Century LMS.

Discovery and Resource Management were included on top of core library processes such as Cataloguing and Circulation. These basics of library operations are still critical, and effectively format agnostic, that is even if the formats and mechanisms of these processes and the resources concerned are fundamentally electronic – the principles don’t change.

  • End point: review and prioritisation

After a number of weeks of meetings of the six consortium Systems Librarians, a review of the Specification was used to prioritise each requirement.

This version was then used to check in with the various library specialisms, where staff had been involved along the way to ensure that wishlists and essentials were covered from the professional point of view.

  • Bigger picture

Going far wider than a traditional specification, the context of the Bloomsbury LMS was set and rounded by including aspects such as:

  • A BLMS concept diagram
  • Key usage statistics and existing library systems across the consortium
  • The enterprise context (business systems that interact with LMSs and beyond)
  • Technical requirements at a high level

3. Why?

The benefits of the process followed and its outputs are far wider than the goal of delivering a successful operational system.

The Functional Specification has a longer term and more extensive role to play in the project than a simple selection tool for the most appropriate system.

This 21st Century shared service LMS will succeed as much on the aspects that traditionally fail in major technology projects, as on the system itself i.e.

  • Ownership
  • Cultural change
  • Process understanding
  • Testing

The Functional Specification for the Bloomsbury LMS project is intended to support all of these aspects, and more – not just to select the software to deliver it.

Written by Sharon Penfold, BLMS Project Manager.