This case study makes use of the following, which are described in more detail in the linked resources:
|A - What? - Function Palette||Documented|
|B - What? – Shared Services Spectrum|
|C - What – Profiles, Scenarios & User Stories||Possibly|
|D - Who? - Business Ownership Map||Documented|
|E - Where? - Service Location Map||Documented|
|F - How? – Requirement v. Resource Matrix|
|G - Why? – Business Benefits Ranking||Discussed|
|H - Difficulty - Dependencies Matrix||Documented|
|I - Difficulty – Potential Risk Register||Documented|
David Kay and Owen Stephens from the LMS Change project visited the University of Stirling on 1 November 2012 to work with:
- Colin Sinclair
- Mark Toole
- Sonia Wilson
1. The Problem
The University of Stirling has run a Reading List Management system (RLMS), Talis List, for some years.
The key reasons for running this system have been to ensure physical and electronic items that are being recommended to students by academics are available within the library’s collection.
This system has been a locally hosted and locally run service. The library has taken on the role of maintaining the reading lists and ensuring they are up to date, with library staff collecting, entering and updating the data in the system.
The University is now in the process of implementing a new RLMS (Talis Aspire), which is a remotely hosted system. While the new RLMS is generally a locally operated service, data in the service is hosted remotely and maybe pooled (with permission from the contributing institution) to produce value added services.
The key reasons for implementing a new system are:
- Lack of support for older system
- Better user interface
- Potential of enabling academics to maintain their own reading lists without input from library staff
- Better integration with acquisitions processes within the library
While Reading List Manage systems serve a relatively straightforward function, the workshop quickly identified a large number of integration points with other library, University and 3rd party systems.
b) Delivering Reading lists
While the need for a RLMS with well designed and easy to use management functions was clearly identified, the requirements for a dedicated student-facing interface for the RLMS was less clear. It might be that the most appropriate route to deliver the reading lists to students is the ‘Succeed’ VLE (Blackboard).
While the course area on Succeed is the natural place for reading lists to be surfaced, this brings its own challenges, as students generally want access to the reading lists before courses are made available on Succeed.
It could also be that Succeed would be the natural place for academics to access management functions associated with the reading lists (such as adding or amending items on the list). It was noted that achieving the same quality of interface within Succeed as is delivered by Talis Aspire natively could be challenging.
c) Workflows associated with Reading Lists
The addition of items to a reading list may trigger library workflows to ensure the material is available as part of the library’s collection.
Such a workflow could include a check against the existing collection, which may require an evaluation of the number of students requiring access to a resource. It might also require the acquisition of the material in some form. This could include the purchase of physical items, electronic items, or the digitisation of material. In the latter case this would ideally integrate with the recording of items digitised under the CLA licence.
The workshop also identified the potential of exploiting ‘purchase on demand’ (PDA) agreements to fulfill reading list requirements. As there is already a commitment to purchase reading list materials, in this instance PDA may act as a cost effective way of providing any materials that students actually wish to use on a just-in-time basis, as opposed to investing in all materials on the list just-in-case.
3. Methods Used
a) Function Palette
b) Business Ownership Map
c) Service Location Map
d) Dependencies Matrix
Scores in this matrix were allocated 0-3, where ‘3’ indicates a high degree of dependency, and ‘0’ indicates no dependency. Some dependencies were not allocated a score, and just annotated with notes about the dependency.
For example the matrix indicates a high degree of dependency (scored ‘3’) between the RLMS and the VLE, particularly noting dependencies for Authentication, the User Interface (UI) and the list of Courses/Modules for which lists are required.
e) Potential Risk Register
1. Target numbers – source/accuracy
2. Timing of Modules – numbers; purchase cycle
3. Profile of work in library – HR!; Volumes; Timing – post deadline submission
4. Acquisition Budget – Partially mitigated by central book fund; Semester 1 pulls too much budget
5. Imaginative use of PDA – Policy to do PDA rather than buy
6. Link checking – report failures rather than blind checking
7. Change of LMS raises integration issues
d) Business Benefits Ranking
Discussion generated information that could have been used to develop a more rigorous ranking.
Efficiency / Streamlining
- (LT) – Academic time
- (T) – Library time
- – Better integration with acquisitions e.g Oasis
- (S) – RLs for more modules – Students
- (LT) – see other RLs – library
- (LT – Improved collection management
- (S) – one stop shop VLE
- (S) – see RLs in advance
- (T) – PDA opportunity
- (T) – change from ageing unsupported system
- Ability to output into multiple environments
This workshop used a wide range of methods and all participants felt they generated a rich and useful discussion. The two tools that stood out were the initial ‘Function Palette’ exercise, and the ‘Dependencies Matrix’, although the latter exercise was not completed during the workshop.
The Function Palette drew out the surprising number of systems and services that related to a Reading List Management system. It is perhaps the fact that an RLMS is related to such a wide range of systems, not just within the library, but across the university, that made this exercise so useful.
The Dependencies Matrix was of particular interest for the same reason. After mapping out functions via the function palette it was helpful to understand how these components related to each other and the dependencies between them.
The ‘Business Ownership’ and ‘Service Location’ mappings were useful, although the service location exercise became more interesting once the direction of travel was considered rather than simply mapping the current situation.
While the ‘Business Benefits’ and ‘Potential Risks’ listings were useful, they perhaps offered less discussion points and insights than the other methods. The Risk Register was a list created as a rolling exercise while using the other tools. For this reason it is not an attempt to create a complete risk register or assess likelihood or impact of the risks listed.
Overall all participants in the workshop agreed the set of exercises had been extremely useful and helped in understanding the requirements the library had for an RLMS.