In chapter 9 of The Portable MLIS, G. Edward Evans (2008) imparts valuable advice on the subject of collections, from how a library’s community expresses different kinds of needs to why a librarian should build relationships with vendors. Being new to the library field, I found the information shared in this essay to be very helpful, as it helped me discover some of the hidden complexities of library life. For example, having to keep an eye on the world’s various monetary exchange rates in order to properly plan acquisitions, or the fact that accommodating technological advances like the compact disc means having to re-acquire large parts of your collections.
The piece that most interested me, however, was the discussion of the various types of needs that must be met in order to build an appropriate library collection. At first I found the discussion somewhat alien, until I realized that it is very much like the process I go through at my current job. I work in the Product Development department of a small software development company, and our task can be thought of as building a collection of features. After every new version is released, it is my job to develop a plan for the next release, which involves deciding which new features and enhancements will be included. Like a collections librarian, I have a budget: the time our developers can dedicate to the new release before the new release date. And the process we follow takes into account the same factors that Evans describes.
First, of course, we must include a basic set of “normative needs,” those features that are recommended by best practice lists and expert opinion. For example, we should include a way to add a record to the database, basic query functionality, an intuitive user interface, standard security protocols, and so on. Then, we need to investigate what the competition is doing, and make sure we build in “comparative needs.” If all our major competitors offer certain reports or functionality types, we will likely fail in attracting customers if we do not offer it. Of course, it could be that everyone else is offering something that is not useful to the customer, because that is what has always been done, so we need to verify that the addition is warranted (every development hour we spend on something that is not useful is an hour we cannot spend on a feature that may be crucial to success). Finally, we turn to the customers and users, and first we listen. Usually, we hear plenty about what our application does not have, or what pieces do not work properly. That gives us a third set of features to add to the pile. Second, we watch. We sit with users as they navigate the application, and we analyze how they use the tool, and that tells us what the users need, which is not always the same as what users articulate they want.
One of my concerns as I begin my journey in librarianship is that there is so much to learn, and I know so little. Collections was one of the topics that most worried me, because I thought it would be this strange, arcane process that I know nothing about. After reading Mr. Evans’ exposition, I feel better about the task at hand. There is still much I do not know, and a great deal to learn, but I realize now that it’s not so different from the processes I follow every day: know what the experts say, benchmark the product against others in the same field, listen to the users and their concerns, and analyze their usage patterns to discover how what they need differs from what they say they want. Once you have all that information, it’s simply a matter of prioritizing appropriately, and minding the budget, and having strong relationships with your vendors and colleagues, and knowing the ruble-to-dollar exchange rate, and keeping up to date on the latest information technology trends, and…
Evans, G. Edward (2008). Reflections on Creating Information Service Collections. In Haycock, Ken & Sheldon, Brooke E. (Ed.). (2008). The Portable MLIS: Insights from the Experts. (pp. 87-97) Westport, CT: Libraries Unlimited.