Editorial Board Thoughts: The Checklist

At my home institution, Johns Hopkins, we have a renowned professor who made a keen insight several years ago. Dr. Peter Pronovost, professor of anesthesiology and critical care medicine, of public health policy and management, of surgery, and of nursing, took note of the fact that many careless errors were occurring in hospital intensive care units, errors that were due not to ignorance, but to overlooking simple, mundane processes and procedures that maximize the safety of patients and increase the likelihood of positive medical outcomes. How to remedy this situation? As is often the case, the simplest solution is the most profound, the most effective, the most brilliant. Pronovost implemented straightforward checklists of processes and procedures for doctors and nurses to routinely follow in the intensive care unit (ICU). There was nothing on these checklists the medical staff did not already know; indeed, they were so basic that what was listed almost went without saying. But the brilliance of Pronovost's insight was that the very implementation of a "just saying" checklist resulted in an immediate and significant improvement in patient outcomes. So simple. So easily done. Might we here in the library IT world implement just such a checklist? In particular, I'm wondering whether we might begin to construct a fairly comprehensive checklist of what I'm calling "software genres" for use in libraries. It doesn't take much insight to see that software packages map to services and that groups of these packages cluster around such services. Such clusters, I'm thinking, are actually genres of software. So, for instance, let's think about a standard library service: a service that fulfills the need of academic institutions to store, archive, and provide access to faculty research. We see software systems emerge to fulfil this need, e.g., DSpace, CONTENTdm, Fedora, EPrints, and Islandora. We can think of each of these systems as the fulfilment of similar sets of requirements and these requirements as being dictated by the satisfaction of a need. These systems individually represent concrete instantiations of clusters of similar requirements. But these systems also cluster among and between themselves insofar as the requirements and the needs they satisfy are similar. They form a genre of software. Now, we've identified one genre of software useful in libraries: institutional repository software. What other genres might there be? How about the Granddaddy of them all: a software system/concrete-instantiation-of-requirements fulfilling the need in libraries to enable the creation and collection of bibliographic metadata, to provide access to that metadata to library patrons, to enable the management of the circulation of physical and electronic objects mapping to that metadata and to manage acquisition of materials including serial publications? Why it's the venerable integrated library management system, of course! And here we'll find such open-source examples as Koha and Evergreen alongside their commercial counterparts. Continuing to compile, we'll begin to gather a table of data similar to what's below. But what good is this? Don't we all already know about these software "genres"? Aren't we just in some sense stating the obvious? To the extent that these software genres and the software packages classified by each are obvious, this table, this checklist, resembles the checklists that Professor Pronovost presented to doctors and nurses in the ICU. Those doctors and nurses certainly knew to wash their hands, to properly sterilize around an area of catheterization, etc. And if they were about to overlook a hand-washing or sterilization, the checklist brought this need and requirement immediately to their attention. So too we might be aware of, say, the fact that many libraries implement systems to manage visual resources, electronic images. We may work in a library that does not. …