Web Magazine for Information Professionals

Implementing a Resource or Reading List Management System

Gary Brewerton takes us step by step through the various stages of implementing a Resource or Reading List Management System for your institution.

This article takes you step by step through the various stages of implementing a Resource or Reading List Management System; from writing the business case to involving stakeholders, selecting a system, implementation planning, advocacy, training and data entry. It recognises the hard work required to embed such a system into your institution both during the implementation process and beyond.

Reading lists have long been a feature of Higher Education in the UK. Traditionally they consisted of an annotated list of books and journal articles compiled by an academic and distributed to their students at the beginning of each term. Today they are often made available electronically and contain links to online content as well as traditional information sources. For this reason they are sometimes also called resource lists.

A Resource/Reading List Management System (RLMS) provides an easy way to discover, create and maintain these lists. However, implementing such a system at your institution may not be as simple as it first appears; it requires careful planning if you want it to be a success.

The Business Case

The first step in implementing an RLMS is to convince your institution of the need for one. A key driver at most institutions is improving the student experience in order to recruit and retain sufficient students of the right calibre. A RLMS supports this by providing clear guidance to students on which resources they need to support their learning and, at the same time, ensuring the library has an appropriate level of resources to meet this demand.

An RLMS can also be evidence of teaching excellence as it demonstrates a clear channel of communication between academics, their students and the library. And of course this channel is not just one way. Students can feed back on the usefulness of recommended resources on their reading lists. At the same time, the library may be able to provide actual usage data on the resources, which will also support academics in further development of their reading lists.

An academic library also has a vested interest in a RLMS as such a system allows it to align its collection management procedures with the teaching of the institution. This allows the library to ensure its resources represent value for money to the institution with the limited budget it has available.

There may well be other local considerations (eg presence of a VLE, authentication issues, etc) that can form part of your business case.

Key Stakeholders

Implementing an RLMS is not a one person job; it requires involvement from a number of stakeholders in your institution to achieve a success. Firstly the process would greatly benefit from the support and involvement of senior management. A Pro Vice Chancellor, Dean or similarly influential person chairing meetings would give the project a greater official standing and aid communication with those responsible for other relevant institutional activities.

Academics as the creators of the reading lists are obviously key to the success of the project. They are also the group that may feel the most aggrieved about any changes imposed upon them due to the implementation of the RLMS. Involving academic staff means that you can gain a better awareness of any such concerns and best be able to address them.  These academics may also become your ‘Champions’ during the advocacy phase of the project.

Students as the consumers of reading lists are also equally important. Their support for the project can influence others to get on board. However, it should be noted that student involvement can be problematic as it may not be possible to retain the same student(s) throughout an extended implementation process.

The library clearly has a vested interest in reading lists as they feed into its acquisitions and collection development procedures. The library is also likely to be best placed to assume, or at least assist, in the advocacy and training for the RLMS. The library may also find itself heavily involved in the data entry for the system and can at least play a quality assurance role in this activity.

There is also a need for technical staff involvement, whether this is from a central IT department or elsewhere in the institution. Their participation is needed to ensure that the RLMS is compatible with institutional technologies.

Ideally a project group comprising at least these five stakeholders (senior management, academics, student representatives, library staff and technical staff) should be convened to take forward the implementation. There may well be other people (eg procurement advisors, teaching support, e-learning officers, sponsors, etc) that your institution would include in any such project group.

Initial Considerations

There are a few basic questions that the project team needs to ask. Answers to these questions will influence both the choice of system and how you implement it.

Who owns your institution’s reading lists? The institution is likely to be the legal owner of the lists but may never have asserted its rights over them. As such some academics, particularly those with the lengthier reading lists commonly found in the arts or social sciences, may feel they own the lists. It is important to determine ownership and ideally be able to point to the relevant local policy that states such ownership. Where ownership of reading lists is uncertain, or where academics may have been given ownership, this will require greater advocacy and prolong the implementation process.

How many reading lists does your institution have and how long are they? This is important to know to help define the scale of the implementation project. The number of reading lists will be a similar value to the number of modules your institution supports, but remember that not all modules will necessarily have reading lists and some modules may share lists. There may also be reading lists that are not formally connected to a module but which it is nonetheless important to include. The length of any reading list is most likely governed by the subject it covers; engineering lists tend to be very short whilst social science lists can run into hundreds of items.

Who will initially input the lists onto the RLMS? Is this a job for the academics, local clerical support or library staff? Perhaps additional staffing is available (for a price) for data entry or maybe you already hold a significant number of reading lists in an electronic format that could be imported into the RLMS. The latter option will certainly be feasible if the team is migrating data from one RLMS to another.

Who will maintain the reading lists? Obviously the lists will need to be reviewed and updated over time. However, this need not be the same group which initially entered them; for example, library staff could have initially entered the reading lists into the RLMS, then academic staff would be responsible for maintaining them. It is important that this issue is clearly decided before any advocacy or training can begin.

Who should have access to the reading lists? Are the lists restricted to members of the institution or can anyone view them? Making reading lists available to potential students can be a valuable marketing tool but at the same time these lists do contain the intellectual property of the institution which it may well wish to reserve for its fee-paying students. Of course, this decision may be greatly simplified if your institution signs up to a Massive Online Open Course (MOOC) project [1] where educational content (including reading lists) is made freely available to self-learners.

Specifying Requirements

The project team should expand on the answers to the initial considerations to create a list of essential and desirable requirements. For instance, the following basic features in many ways define a RLMS:

It is also advantageous if the RLMS can provide you with information on both the number of reading lists entered into the system and the number of items, so you can easily monitor the data entry during the implementation.

Other requirements may be determined by local considerations. Do you have a VLE and if so how closely should this be integrated with the RLMS? What authentication options are supported? Are there any student information systems that contain data with which the RLMS could or should interact? For example, your institution may have a system that holds course details including how many students are registered on each module. The ability of the RLMS to interact with such systems can reduce the amount of data entry needed.

System Selection

With a list of requirements in hand, the project team can now draw up a short list of potential systems [2] to evaluate. There are currently a handful of commercial systems, usually delivering software as a service. In the UK it is relatively easy to obtain demonstrations of these systems from their suppliers.

There are also a growing number of freemium [3] reading lists solutions out there that may meet your requirements. These provide a free basic service to users and charge either for advanced features or use an alternate revenue stream such as taking a small referral fee when people purchase recommended items from an online bookstore.

Open source systems are also available, although live demonstrations of these systems by their developers may not be possible. However, the developers may provide an online demonstration, be this interactive or recorded podcast(s). Obviously one advantage of open source is that technical staff can gain first-hand experience with the system by simply downloading and installing it.

Another option is to develop your own RLMS. This will require significant local technical resource and is not something to be entered into lightly. An in-house system may well be the best match to your list of requirements, and this is increasingly likely to be the case if you need to integrate it with many other local (i.e. non-standard) systems, but you do need to consider the total cost of such a development.

With a short list of possible systems drawn up and the project team having seen demonstrations of them, the next step is to visit or speak with users of the systems. This is a great opportunity to learn more about the system and also to gain confidence that what you are seeking to accomplish has been achieved elsewhere: if they can do it, so can you. The usual questions to ask are:

The decision on what RLMS to implement is likely to be made based upon a number of factors. They include how well the system meets your list of requirements; what are the costs of the system (both in terms of money and resources); and your level of confidence in the supplier/developer of the system. The latter is particularly important if there are key requirements missing from the system that you are hoping will be developed in future.

Your project team may have the authority to make the decision on which RLMS to adopt, or, more likely, recommend an RLMS for approval from a higher power. Of course, the recommendation could even be not to proceed with an RLMS or wait until required features are developed before going any further. However, assuming that you do decide on which RLMS to implement, then the hard work can really begin!

In-house Development

If you decide to develop your own in-house RLMS, then this will impose delays in the implementation process as there is no point in promoting a service that has yet to be realised. However, it is important that ongoing communication occurs between the project team and local developers to ensure the resultant system is what is required. In addition, regular progress reviews will ensure the system is on track and other aspects of the implementation (eg advocacy, support, etc) will be ready when needed.

One major danger of any local development is feature creep. This is the continuous growth of requirements beyond what was decided at the start of the development. New requirements are not necessarily a bad thing and may be caused by factors outside the original scope of the RLMS implementation, but they must be strongly managed as so to avoid the development overrunning or the need for additional resourcing.

Implementation Planning

It is probable that the timescale for the project has already been determined (eg ready for the new academic year) and therefore the two major constraints on the project will be the cost and scope. Cost may be licensing or subscription charges, purchase of hardware and, of course, staff time. Scope in this case means the number of other systems the RLMS needs to integrate with and number of reading lists to be entered into the system.

It is unlikely that you will be able to obtain every reading list in existence at your institution or motivate all academics to enter their lists into the RLMS. Therefore you need to set a realistic target number or percentage of lists to enter as part of the implementation process. An aspirational goal of 90% of the available lists may be appropriate for some institutions, whereas 60% may be more realistic for other sites. This target will depend heavily on how much institutional buy-in the project has; the greater the buy-in the higher the target.

With your timescale and target number of reading lists determined then it is possible to plan the implementation using standard project management tools such as work breakdown structures, network diagrams and Gantt charts. Key activities of the project plan will include advocacy, system installation, system configuration, training, data entry and support. If you have selected a commercial system then the supplier should be able to assist you in this process having (it is hoped) implemented their system successfully at other sites. Figure 1 below shows a simplified Gantt chart for a RLMS implementation.

Figure 1: Implementation Gantt chart

Figure 1: Implementation Gantt chart

If you have sufficient time, then one possibility is to run a pilot implementation. This will allow you to practise many of the activities, in particular advocacy and training, and also allow you to evaluate better your data entry and support needs. A pilot could be run with a single academic department but it would be better to involve academics (either whole departments or individuals) from multiple subject disciplines. This is because the size and style of reading lists can vary greatly between subjects; using a single department is therefore likely to skew the results of the pilot. Another advantage of using academics in different departments is that these early adopters can be used later to help promote the full roll-out of the RLMS.


It may be that some advocacy has already been done, either as part of convincing your institution of the need for a RLMS or as part of the system selection process. In any case, now that the implementation is actually happening, it is important that this begin in earnest. At the very least, you can now inform people of the key features of the system and project timescales. Subject liaison librarians are ideally suited for this advocacy role as they will have established channels of communication with academic departments. Where this does not already apply, it is a great opportunity to forge these contacts.

It is important to know which departments respond well to persuasion and which require more formal encouragement, perhaps by a senior member of the institution or an agreed institutional policy. If, for example, you have a teaching or e-learning policy then it may be possible to add a requirement for all courses or modules to place a reading list on the RLMS. It may also be useful to know how academics in the department use reading lists. How do they promote and motivate their students to use the lists? From where do they make them available? And who, if anyone, assists them in keeping the lists up to date?

Clearly departments do differ significantly from one another even in the same institution, and what works for one will not necessarily work for another. In some departments, local champions (maybe your early adopters) can do more than official promotions. If this is the case, it is important to identify and support your champions. You may also find that there is natural competition within a department or among departments of which you can take advantage. However, this does need to be handled with great care so as not to alienate those department(s).

If it has been decided that non-academic staff will be responsible for the initial data entry, then this certainly makes the advocacy activity easier as all you need from the academics are copies of their reading lists. On the other hand, getting academics to actually enter their lists onto the system themselves will take a lot more persuasive effort.

Use every opportunity you can to promote the RLMS. If an academic has bad feedback from their students relating to lack of available resources then maybe this is because of their lack of a reading list on the system. If there is an upcoming teaching assessment, then maybe you could suggest that a department invest some time in ensuring their lists are on the system so as to demonstrate a clear chain of events from an academic recommending a resource, to the library acquiring it, and the students using it.

Finally, you may need to consider possible competition from other sources for the reading lists. For example the local bookshop may already have an ongoing relationship with some of your academics or perhaps a freemium reading list service is asking your academics or students to upload their reading lists. It is important that you establish the selected RLMS as the official system as far as the institution is concerned. After all you will not want to see academics having to do the same job twice and if it is appropriate for the other source to have the reading list data then access to this can possibly be arranged.

System Installation and Configuration

Installation of the RLMS will be carried out by your technical staff, the system supplier or more likely a combination of them both. Critical tasks are integrating the RLMS with your institutional authentication systems (Shibboleth, LDAP, etc) and the library catalogue. Further integration with your Library Management System may also be possible, as could integration with a VLE and other institutional systems.

Once the RLMS has been installed, it then needs to be configured. This may include uploading local branding and department/course/module details to reflect the make-up of the institution. The latter could mean extracting such data from an existing institutional system and importing into the RLMS, or entering them manually.

Training and Support

It is to be hoped your selected RLMS is easy to use, but you will still need to provide training. Before your trainers can train others they must first become familiar with the RLMS themselves. This may involve organising training from a supplier, or reading available documentation, or simply having a good play with the system. If your initial data entry is being undertaken by a small group of staff (library or otherwise), then training need not be an onerous task.

If your academics will be undertaking the initial data entry then your training programme will need to be more extensive. Training could take place in central locations such as the library and also in departments. Ideally the training should be group sessions although do not be afraid of one-to-one training, particularly in the case of your local champions. In your training sessions you may encounter some resistance to the RLMS. It is important to remind people of the aims of the project and benefits the system will bring. However, it is worth recording any criticism of the system as this can be used to inform further development of the RLMS.

You might also want to consider recording one of the training sessions or specifically creating an online version of the training. This can then be used countless times thereafter by trainees at a time that is convenient for them.

Beyond the organised training there is also a need to provide ad hoc support during the implementation process. This may be to answer queries from those doing the data entry or to explain any changes that might have come into effect since the training, for example an update of the RLMS that introduces valuable new functionality. As well as providing phone and email contact details, it may be worth considering establishing a blog or electronic forum to assist in supporting the implementation; either of these solutions would prove an ideal platform to host an FAQ .

Data Entry

Of all the activities relating to implementing a RLMS, data entry is in many ways the most vital. Without a sufficient critical mass of reading lists, the system may not be taken seriously when it is launched, and both it and the project potentially deemed a failure. Therefore, it is important to monitor the progress of lists entered into the system against the agreed targets and to take remedial action if necessary.

Such action could be as simple as encouraging those already undertaking the data entry (academics, library staff, temporary staff, etc.) in their efforts or recruiting more people to assist in the process. Alternatively you could redefine the scope of the project, perhaps limiting data entry to reading lists for first-year students.

Regardless of who enters the reading lists into the system, there is likely to be a need to check the quality of their input. Such checking needs to address the accuracy of the citations and overall organisation of the reading list. Common mistakes encountered can then be fed back into the training programme and, one hopes, resolved.  If it is not possible to check all the lists, then certainly checking a sample of them could be beneficial.

Launch and Beyond

With a lot of hard work and a little luck, by the time the launch date arrives, you will have successfully begun the process of embedding the RLMS into your institution’s workflows and procedures. If you have achieved close to your target percentage of reading lists then this is good news; if you have successfully entered over 90% of your institution’s lists into the system, then this should be a cause for celebration.

However, whilst the implementation project may now be drawing to a close, the work of implementing the RLMS continues. Without continual advocacy, training and support you may not be able to get the remaining reading lists entered onto the system or, even more importantly, maintain those lists already entered into the system. The latter is particularly important if a different group of staff (ie the academics) did not initially enter the lists but are now responsible for keeping them up to date.

The launch also signifies a change to the advocacy. Before the launch this will have focused on the academic staff. As the launch approaches this will need to expand to include your students, after all they are the main beneficiaries of the RLMS. Obviously the launch itself represents an ideal opportunity to promote the system to them, perhaps with an official launch event.


Implementing a RLMS is a lot of work. There are many questions that need to be considered, not least: which system to adopt and who will be responsible for inputting the reading lists. It will require the co-operation of many people in the institution, especially the academic staff. However, with careful planning and an effective programme of advocacy and support, you will have begun to embed the system into your institutional procedures and soon have realised the benefits.


I am grateful for the support and encouragement of my colleagues, in particular Jon Knight, Jason Cooper and Ruth Stubbings.


  1. Pappano, Laura. “The Year of the MOOC.”The New York News. The New York Times Company, 4 Nov 2012. Accessed 11 December 2012
  2. Chad, Ken. helibtech. SCONUL, 2012. Accessed 11 December 2012
  3. Froberg, Peter. Freemium 101: A brief introduction to the freemium business model. n.p., 2012. Accessed  11 December 2012. http://www.freemium.org/wp-content/ebook-101.pdf  

Author Details

Gary Brewerton
Library Systems Manager
Loughborough University

Email: g.p.brewerton@lboro.ac.uk
Web site: http://www.lboro.ac.uk/library/   

Gary Brewerton is the Library Systems Manager at Loughborough University and is interested in library automation, information and communication technology, and open source development (eg LORLS).