Big or small?
Should you focus your efforts on a smaller number of really big technology projects, or a larger number of smaller projects? Of course there is no one right answer for all institutions, and it’s likely no institution would rely on one approach to the exclusion of the other. But it can be difficult to find the right balance between the large-scale, high-impact initiatives and those that are more nimble and quick to appear.
The largest projects certainly receive a great deal of press: an Endeca implementation, a Web site redesign, a Google Book Search partnership. Each institution’s definition of “large” will differ, however. While a Web site redesign is something every institution will go through at some point, the other two examples mentioned here are likely not to be realistic options for most institutions. For most, a project on the scale of upgrading to a new version of an operating system on all public computers or implementing a link resolver is the largest investment of time and money, requiring a great deal of management time, and these generally receive a similar proportion of publicity.
But the smaller projects can also have considerable impact. In many institutions, launching a blogging service can be done with more modest planning and technical support. Even “quick and dirty” initiatives can prove highly effective, such as writing a Greasemonkey script to perform a library service, or setting up an implementation of LibX. Often the simplest idea, quickly implemented, will fill a great user need.
Digitization projects, especially, can be either large or small depending on how they are implemented and the technological infrastructure in place at a given institution. Delivering the same number of locally-digitized materials at two institutions might be a “large” project at one and a “small” project at the other. A digitization project is a small one if the digitization is the most difficult part—if a complete infrastructure for storing, indexing, and delivering that type of material already exists into which this new material can simply be deposited with a minimum of customization. That same project will be large if that infrastructure does not already exist, or if it needs to be extended to accommodate planned functionality. The latter approach can be an extremely effective one, adding new features to a central infrastructure with each new pool of content. An early digitization project might provide basic search and browse capabilities, and the next few might iteratively add more advanced features such as faceted browsing, “bookbag” capabilities, or the ability for users to create and save resource annotations.
An iterative approach can serve to make projects that once were considered large smaller over time. Each successive digitization project will get easier as an institution’s experience an infrastructure grows. It is in our best interest not to become complacent with current functionality as adding content with that same functionality becomes easier. We can use the resource savings from experience to add new features and improve your infrastructure. Simply putting materials online is not enough—libraries must continue to provide innovative services for discovery and use of our resources. As parts of digitization projects get easier, we will benefit from reallocating that energy into the development of new services.

Recent comments
2 years 3 weeks ago
2 years 12 weeks ago
2 years 28 weeks ago
2 years 30 weeks ago
2 years 30 weeks ago
2 years 31 weeks ago
2 years 37 weeks ago
2 years 37 weeks ago
2 years 39 weeks ago
2 years 41 weeks ago