In March of last year I wrote about efforts of the Resource Discovery Systems and Strategies team (RDSS, previously called the Discovery Strategy Team) to map Duke University Libraries’ discovery system environment in a visual way. As part of this project we created supporting documentation for each system that appeared in a visualization, including identifying functional and technical owners as well as links to supporting documentation. Gathering this information wasn’t as straightforward as it ideally should have been, however. When attempting to identify ownership, for example, we were often asked questions like, “what IS a functional owner, anyway?”, or told “I guess I’m the owner… I don’t know who else it would be”. And for many systems, local documentation was outdated, distributed across platforms, or simply nonexistent.
As a quick glance through the Networked Discovery Systems document will evince, we work with a LOT of different systems here at DUL, supporting a great breadth of processes and workflows. And we’ve been steadily adding to the list of systems we support every year, without necessarily articulating how we will manage the ever-growing list. This has led to situations of benign neglect, confusion as to roles and responsibilities and, in a few cases, we’ve hung onto systems for too long because we hadn’t defined a plan for responsible decommission.
So, to promote the healthier management of our Networked Discovery Systems, the RDSS team developed a set of best practices for sustainability planning. Originally we framed this document as best practices for maintenance planning, but in conversations with other groups in the Libraries, we realized that this didn’t quite capture our intention. While maintenance planning is often considered from a technical standpoint, we wanted to convey that the responsible management of our systems involves stakeholders beyond just those in ITS, to include the perspective and engagement of non-technical staff. So, we landed on the term sustainability, which we hope captures the full lifecycle of a system in our suite of tools, from implementation, through maintenance, to sunsetting, when necessary.
The best practices are fairly short, intended to be a high-level guide rather than overly prescriptive, recognizing that every system has unique needs. Each section of the framework is described, and key terms are defined. Functional and technical ownership are described, including the types of activities that may attend each role, and we acknowledge that ownership responsibilities may be jointly accomplished by groups or teams of stakeholders. We lay out the following suggested framework for developing a sustainability plan, which we define as “a living document that addresses the major components of a system’s life cycle”:
- Governance:
- Ownership
- Stakeholders
- Users
- Maintenance:
- System Updates
- Training
- Documentation
- Review:
- Assessments
- Enhancements
- Sunsetting
Interestingly, and perhaps tellingly, many of the conversations we had about the framework ended up focusing on the last part – sunsetting. How to responsibly decommission or sunset a system in a methodical, process-oriented way is something we haven’t really tackled yet, but we’re not alone in this, and the topic is one that is garnering some attention in project management circles.
So far, the best practices have been used to create a sustainability plan for one of our systems, Dukespace, and the feedback was positive. We hope that these guidelines will facilitate the work we do to sustain our system, and in so doing lead to better communication and understanding throughout the organization. And we didn’t forget to create a sustainability plan for the best practices themselves – the RDSS team has committed to reviewing and updating it at least annually!