This is part 2 of an update from the Bloomsbury LMS project team about the development of our LMS specification and is especially relevant if you are planning an Open Source solution for your library management system. A PDF version is available for printing and reading off line.

Why?

1. Context

In 2012 a group of the Bloomsbury Colleges and Senate House Libraries found they had a common vision for a 21st Century LMS shared service.

As captured in Part 1 of this case study, the project team worked through a robust but agile process of developing a Functional Specification – agreed and prioritised to suit all 6 consortia partners.

Part 2 of this case study is a more generic view on the purpose of a Functional Specification. This is at a time when possibly HE libraries are questioning their value in a marketplace where all next generation systems can claim to deliver the same functionality.
Checking the value is more than valid – the time, effort and commitment required to develop a Specification is significant. Even adapting another institution’s or adopting something like the “Unified (‘Next Generation’) Library Resource Management System” still takes time to validate and tailor the content.

2. What is the purpose of a specification?

A 21st Century LMS is best seen in the setting of enterprise IT – part and parcel of the business and administration systems that underpin the purpose of a university.

A specification is not simply about the selection and tender process for a commercial supplier (whether for software, consultancy or other services).

The specification is an important part of any selection process, but offers far more to the institution in terms of a successful implementation and operational service.

Specifications underpin critical factors such as:

• Process mapping and understanding
• Ownership and stakeholder engagement
• Cultural change
• Testing, above all
• Acceptance and sign off
• Operational services

3. Does an Open Source solution need a specification?

Unequivocally, yes.

As above, specifications have a far wider role to play than basic selection of a new commercial system or service.

In some ways, the specification is more important as there may well be more development or implementation work to get an open source system fully operational. You as the owner of the system need to know your requirements inside out to make sure they work as
needed, or can be adapted within the constraints of the software – or developed using a third party product.

The benefits of having a specification as listed above are equally valid for open source, in particular:

• How do you know what to implement without having clearly unpicked critical processes?
• How do you know what to test?
• How will you be able to support the operational system?

You don’t have the same safety net on the open source front that you have with a commercial system.

Commercial support and other services related to previous or next generation LMSs may be poor in reality, but you have a contract. In theory at least, there is legal comeback as a last resort.

That said, unless an institution is fortunate enough to have a full blown systems development capability, external support services in some form will be required for successful implementation of this enterprise solution. Even if that just takes the form of an IT contractor or three.

Once more the value of a specification comes into play – so all parties involved in developing the new system are working to the same script.

Open source or not.

Written by Sharon Penfold, BLMS Project Manager.

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.