Local Developer Success Story: University of Cambridge

May 27, 2011 by kirsty-pitkin

Developer overhauls a time-wasting library reporting system and upskills library staff to make better software decisions in one fell swoop.

In this DevCSI case study, Michelle Pauli explores a local developer success story from the University of Cambridge, examining how the developer improved the online reporting services for college and departmental libraries within the institution, and provided valuable education about future software sourcing…

The problem space

The University of Cambridge libraries team was using a commercial library management system that could not cope with the demands of specialised reporting for the 70+ libraries it supported.

Librarians need reports – the basic information to run libraries, such as details of all the items on a specific shelf or a list of outstanding fines. However, Cambridge’s librarians were unable to run these reports themselves as it had to be done through an access client. Every time a librarian needed a report they had to request it from the libraries@cambridge team who would run the report and email it to the librarian.

It was resource-intensive for the system support team – taking up about 70% of two people’s time – and frustrating for the librarians who had to wait for emails for figures they urgently needed to go about their work.

What the developer did

Huw Jones, a systems support librarian with developer experience, had been brought into the libraries@cambridge team from a college library on a part-time basis. He quickly identified the issue and spotted the way out.

Using a rapid, agile development cycle, he talked to librarians and started to develop a web-based automated service based on demand, tackling the librarians’ most-requested reports first. It was an iterative process and included feedback from those who created reports in the team as well as the librarians. Extensions to the system came through request by librarians, who were asked to let the development team know about anything causing them problems.

The result was a web interface that took the onus off librarians to wait for an email and turned running reports into something they could control and manage themselves.

Screenshot from Libraries@Cambridge

Tangible business benefits

“We were locked in a cycle of spending all our time running to keep up and not having time to look around and see what could be done better. It was an investment in time to get time back,” says Jones.

This investment in time-saving has allowed the two members of staff who had previously been spending the majority of their time running reports to focus on other areas of activity instead, including record quality, bibliographic control, more training courses, looking into improving quality of data, and branching out to new areas. New services include stock checking and an FAQ database as well as service improvements.

It has saved the IT staff time, as they no longer have to print out stock checks and walk over to librarians with them, and the new system can identify and correct cataloguing errors automatically.

And it has saved librarians time as they no longer have to send out requests and wait for emails. They can access information about their services at any time.

In addition, librarians are able to access far more information as they are no longer restricted by the capacity of the support team. As a result, the number of ad hoc reports produced has increased from approx 2,000 a year when run manually, to 3,437 last year under the new system.

A total of 57,000 reports across all the libraries were produced last year, of which 36,500 were scheduled reports, including daily circulation stats which were previously run monthly with far less detail.

Why use a local developer?

Cambridge’s in-house solution to its libraries problem was responsive and organic and removed the issues of annual maintenance fees and quality support that would have arisen had it outsourced.

“With outsourcing the costs are not just financial, with licenses and support fees, but also in staff time supporting and communicating with vendors,” says Jones. “It also makes sense to have local control over the system. Once seen as separate, we now see it as a network of things we have available eg the library management system, access to student data and other systems. So now when we build interfaces we think of these systems as a network of resources we can build on top of.”

The experience of local development has “upskilled” all the staff involved to the extent that Jones believes that they will be able to make a much more informed choice about commercial v local development in the future having now had the experience of going down both routes.

Furthermore, it has had a positive impact on the development team’s wider ambitions and aspirations. “We are now much more involved with trying to get funding for collaborative partnerships to do interesting things – having done some local development and having more project expertise and collaborative experience as a result, we now want to expand outwards,” says Jones.