Evolution of a Service Management Framework: Spotlight at Stanford as a Use Case

Abstract

Service management—the entirety of activities undertaken by an organization to design, plan, deliver, operate, and control information technology (IT) services offered to stakeholders—has long been applied successfully by the government and commercial sectors. In this article, service management is discussed in the context of open-source software developed in an academic library setting, by exploring the creation and growth of the Spotlight at Stanford service framework. First, service management is briefly introduced as a guiding principle and philosophy, within the Stanford Libraries context. Second, the Spotlight at Stanford software is described. Third, people who are key players in both the delivery and use of the software are discussed. Fourth, processes including goals and activities of the Spotlight at Stanford service team are reviewed. Fifth, various accomplishments are listed, including how the service team has contributed to the successful adoption and development of the web application at Stanford University. Finally, lessons learned are discussed and directions are shared for the future development of the Spotlight at Stanford service framework.

1. Introduction

Service management—the entirety of activities undertaken by an organization to design, plan, deliver, operate, and control information technology (IT) services offered to stakeholders—has long been applied successfully by the government and commercial sectors. In this article, service management is discussed in the context of open-source software developed in an academic library setting, by exploring the creation and growth of the Spotlight at Stanford service framework. First, service management is briefly introduced as a guiding principle and philosophy, within the Stanford Libraries context. Second, the Spotlight at Stanford software is described. Third, people who are key players in both the delivery and use of the software are discussed. Fourth, processes including goals and activities of the Spotlight at Stanford service team are reviewed. Fifth, various accomplishments are listed, including how the service team has contributed to the successful adoption and development of the web application at Stanford University. Finally, lessons learned are discussed and directions are shared for the future development of the Spotlight at Stanford service framework.

1.1. Purpose

This article is a discussion of Spotlight at Stanford, which is a product developed by Digital Library Systems and Services, a part of Stanford Libraries. A product is a tangible and discernible item that an organization produces. A service is the production of an essentially intangible benefit, either in its own right or as a significant element of a tangible product, which through some form of exchange, satisfies an identified need [1]. In other words, what helps to sustain, support, and transform the product is the service framework wrapped around it. The service is a set of activities that gives voice to users and creates a continuous, effective loop of dialog amongst all stakeholders.

Anecdotally, our sense is that the employment of service management frameworks for library and archive IT services is in a nascent stage. This is an area ripe for further research, to prove or counter this hypothesis, and gather information about current practices and future trends. Our intent for this article is to contribute to the corpus of documented knowledge for study by others, and to do so by describing the Spotlight at Stanford use case in considerable detail.

1.2. Stanford Context

The digital library team at Stanford manages a variety of different user-facing services. Examples include the Stanford Digital Repository, the Electronic Thesis and Dissertation service, and Digitization Services, to name a few. Each service has a different service manager (although some staff manage multiple services), alongside different stakeholders, objectives, and needs. We currently do not have a generalized “template” for service management, and we operate within a framework that encourages creative solutions coupled with a fair measure of “accountable autonomy.” Many of us who fulfill a service management role are in the same organizational unit, providing the opportunity to share our diverse approaches and employ tools and techniques that have worked well for our colleagues. We also work together to help cover for one another during key outages. For the past two years, we have conducted a digital library service expo for our primary constituencies, allowing us to showcase our portfolio of services, host question and answer sessions, and provide time for socializing.

1.3. ITIL and ITSM Background

ITIL (formerly an acronym for Information Technology Infrastructure Library) is a set of detailed practices for Information Technology Service Management (ITSM) that focuses on aligning IT services with the needs of businesses [2]. ITIL was created in the 1980′s by the UK government, in an attempt to improve the delivery of IT services and resources. Initially a voluminous group of documents, it has transformed to include several certifications, and has been widely adopted by the IT industry as a best practice framework for IT service management [3].

The focus of this article and the use case presented is on Information Technology Service Management (ITSM). This refers to the entirety of activities—directed by policies, organized and structured in processes and supporting procedures—that are performed by an organization to design, plan, deliver, operate, and control information technology (IT) services offered to customers [3].

A basic understanding of ITIL and ITSM, shared with our organization by a former manager with ITIL certification and extensive experience in the Silicon Valley software sector, served as a driving factor in our awareness of IT service management at Stanford Libraries. We used this new knowledge as a springboard to develop our Spotlight at Stanford service framework.

2. Technology

Spotlight Description

By 2013, we had reached a turning point with how we were showcasing discreet digital collections at Stanford Libraries. We define collections as curated groupings of library and/or archives content around a theme, that may have a unifying catalog record for the whole. We had developed four custom collections websites for partnerships between the libraries and outside collaborators, three of them international. These labor-intensive efforts, lovingly crafted, made it abundantly clear that we needed a more streamlined and sustainable approach for the discovery and delivery of our digital collection project content, with stakeholders both inside and outside of Stanford.

So, Spotlight was born: architected by Stanford Libraries user experience designer Gary Geisler, who conducted user interviews, created personas, and solicited community feedback. Stanford Libraries software engineers Jessie Keck, Chris Beer and Justin Coyne completed the first development cycle in early 2014, and the web application, or product, was launched. Spotlight is a plugin to Blacklight, and as we were already a Blacklight shop, this fit well into our suite of knowledge and tools [4,5]. A single instance of Spotlight supports multiple exhibits, such as Spotlight at Stanford [6], Figure 1. Each exhibit is equivalent to a collection website, as described in the preceding paragraph.

Stanford’s digital library solutions are based on open source software where possible. Open source solutions provide more control, as opposed to proprietary software procured from a vendor. We control our development costs, access to our data, and have reliable input into new features and other development decisions. With open source, everyone benefits from community expertise and contributions, and we can give back to the community as well. We created Spotlight for the community and for our own use, because we knew that a large community of Blacklight users already existed in academic libraries who would be able to benefit from a Blacklight plugin that supported the creation of digital exhibits. At Stanford, we run a local instance of Spotlight that is tailored to our digital library infrastructure. We also contribute to the master codebase, not only with bug fixes and dependency upgrades, but with the addition of new features such as internationalization, released in July 2018.

Exhibits are created by the primary stakeholders themselves. The first Spotlight exhibit for one of our historic map collections, “Maps of Africa” was published in the fall of 2014 [7], Figure 2.

3. People

3.1. Exhibit Creators

Spotlight at Stanford is an instance of Spotlight created and maintained by our digital library team for campus exhibit creators—faculty, librarians, researchers, and students. With a single hands-on training session by a service team member, creators can easily populate exhibits using a set of configurations, templates, and customizable widgets. In addition, the Spotlight at Stanford platform has proven to be a useful venue for showcasing the digital collections of organizations we partner with, for grant-funded projects and other initiatives.

3.2. Establishing a Service Team

During the year-and-a-half following the Spotlight web application release in 2014 and subsequent publication of the first exhibit, exhibit publication occurred with a good measure of support and training by Gary Geisler (the user experience designer). About four exhibits were published during this timeframe. In early 2016, a service team charter was crafted, and a service manager designated. Service team members were identified soon afterward, representing a broad cross-section of library constituencies. The service team began meeting regularly and quickly established a process to receive, triage, and communicate regarding user feedback. After a few months, the team identified a process to help with prioritizing goals and were off and running creating user documentation. Later in the year the team commenced work on creating a microsite describing Spotlight at Stanford which included both the product and the service.

3.3. Service Team Selection

Once the service manager was assigned, team selection was finalized. In selecting team members, we knew from extensive group and cross-collaborative experience that we needed to keep the team small enough so that consensus could be reached effectively (over time, team membership has fluctuated between 5–7 staff). By the same token, it was important to ask staff if they were interested in participating, and specifically inquire if they felt they would have the time to devote to this “other duties as assigned” responsibility. When the team was first formed, we were not at all certain of the time commitment. With experience, we have determined the commitment constitutes 1–5 hours per month, or more depending upon the tasks team members choose to volunteer for. Our environment at Stanford Libraries is significantly self-directed and not overly hierarchical, so a quick conversation with a supervisor to approve team participation is typically all that is necessary. The members include Spotlight’s user experience designer, staff from University Archives, and a Humanities and Area Studies bibliographer. Early on, team membership expanded to include staff from the sciences. We commenced with standing monthly meetings, reviewing the charter, and learning the features and functions of the product. We quickly established a user feedback process as a foundational task.

3.4. Team Building

Prior to presenting the contents of this article at Open Repositories 2018, proposal reviewers asked several questions, and the answers have been carefully woven into this article. One question was particularly striking, “Why is team building considered service management?” Hopefully the story related in Section 4.6 about the business value exercise helps to address this query. Because we are human and teamwork is sometimes hard, in order to be effective we need to be open to new ideas and new ways of working together. Without the work we have done to focus on team building and communication—both inside and outside of the service team—we would not be experiencing the successes that are being shared in this article. Good teamwork is a success multiplier. Team building is foundational to all that we do, and it can get short shrift as an intrinsic value in the digital library environment.

4. Processes

4.1. Spotlight at Stanford Service Framework

The Spotlight at Stanford service is a framework that we have developed organically over time. The framework ensures that promotion, support, and advice regarding the use of Spotlight is underpinned by a set of practices carried out by a service team and service manager. These practices include training users, providing robust user documentation, facilitating user feedback, communicating with developers, getting the word out on campus about Spotlight at Stanford, reporting on our mutual successes, and keeping an eye out for new opportunities.

Together, the service team and service manager provide a wide array of activities for supporting the use of Spotlight. At the beginning of a year, we typically brainstorm and prioritize a set of goals that the team works on both individually and collaboratively. Our goals focus on improving the user experience, and often include creating and updating user documentation, alongside communicating to users about development work underway and new releases. We triage feedback from users and troubleshoot bugs and outages. We often consult with prospective new users, and present at various campus forums about Spotlight, to help increase our user base. In order to understand how we got here, a timeline of our progress is depicted in Figure 3, followed by a breakdown of our service framework development process.

4.2. Charter

The service team charter was drafted in early 2016 and has stood the test of time, not only as a good focal point to get us started but as a continuing touchstone. The charter focuses on the following three areas: promotion, support, and advice, as summarized in Figure 4.

4.3. Internal Communication

Internal team communication is essential. We set up an email list and a slack channel. We maintain a wiki, monthly agendas and notes, and share and track tasks on Google Drive.

A few months ago, while executing development work the engineering team created a slack channel notification for each time a Spotlight exhibit is published or unpublished, something that otherwise we had no way to track.

4.4. External Communication

Several of the service team members meet regularly with their larger department or group. They requested information to be shared at monthly service team meetings, on Spotlight topics relevant to the constituencies they represent. To support service team members, the service manager provides regular information updates to the service team for use at these department meetings, including:

• Information on past, current, or upcoming sprints with near-term features on the development road map and timelines if possible;
• Current Spotlight issues that require workarounds;
• Newly published exhibits with demos of new or novel ways of showcasing content;
• Anything new and noteworthy, including slides or recordings of recent Spotlight presentations.

4.5. Managing Service and Product Feedback

To facilitate user feedback, we configured the feedback submission button for each Spotlight exhibit so that it created a ticket in JIRA [8]. Each feedback email is sent to the service team, alongside the primary contact for each exhibit—typically the exhibit creator. The service manager takes the lead on triaging the tickets, with backup from the team at selected points. Each JIRA ticket is categorized for action, and the backlog regularly groomed.

4.6. Establishing Business Value to Define Service Team Activities

After getting a user feedback process in place, the team stalled. Bruce Tuckman’s model of group development identified four phases he proposed as necessary and inevitable: forming, storming, norming, and performing [9]. Our team went through these phases. After the phase where we formed, the storming phase, where members both gain trust but also disagree, was evident during our free-form discussions on what we should be doing as a service team.

The tool that brought us together—into the norming and performing phases—is one adapted from a workshop on how to be an Agile product owner [10]. The tool combines story points for software development tasks with business value points to help a product owner prioritize tasks for each Agile sprint [11]. Our service team discussion up to that point had yielded a lengthy list of potential tasks to undertake. We did not consider the difficulty of each task, but rather the business value, and we set priority using a group process that involved ordering tasks using Fibonacci numbers. For business value, the team was instructed to evaluate how significant the impact of the completed task would be to the end user, and also to the team in the execution of our service work. As service manager, I facilitated the business value exercise, but I did not participate in the prioritization. This exercise was very successful and caused people to consider impact while helping them realize we could not do everything in the first year. The need to reach consensus was motivational, and the team really pulled together at that point. Happily, our business value exercise solidified us as a team, and we identified several key goals for the year, including creating current user documentation and publishing a microsite on Spotlight at Stanford about both the product and the service.

The microsite we subsequently developed outlined the benefits of the service, summarized key use cases, explained the technology, and provided contact information for interested users on the Stanford campus [12], Figure 5.

4.7. Team Process

Once service team tasks are prioritized for the year, the team discusses tasks in detail and one or more team members sign up to lead specific high priority tasks. We start with the highest priority tasks first, and leave the lower priority tasks unassigned until later in the year. Often, a more experienced team member will pair up with someone who is less experienced and/or who wants to learn more about a particular task. Since most tasks either involve creating documentation or articulating a plan, a draft is created and shared via Google Docs. Once a first draft is completed, team members are notified and they provide comments, request clarifications, and ask questions. Technically, the service manager has the final say about whether or not documentation is complete, or if a course correction is needed. In practice, this has rarely been necessary to execute in a formal way. Most commonly, the service manager or user experience designer’s expertise is contributed in a collaborative tone, which has served to improve the quality of the final product. Deadlines are somewhat fluid initially, but we typically work towards completion of tasks by the start of fall quarter each year. We remain flexible because we understand, with the exception of the service manager, all tasks the team members undertake fall into the “other duties as assigned” category. We work on tasks over the course of many months, and we agree together on deadlines well in advance. For that reason, we have never missed a hard deadline we have established for ourselves.

There are many ongoing tasks that are the sole responsibility—or the primary responsibility—of the service manager. These tasks include items such as triaging feedback tickets, reviewing exhibit requests and creating exhibit stubs, conducting training and consultations for prospective exhibit creators, writing statistical reports, and giving presentations. Service team members, when they feel sufficiently knowledgeable, will sometimes conduct exhibit creator training and consultations, or respond to user feedback when they feel particularly informed, or when the service manager is on vacation. The annual priorities identified by the service team fall outside of, but are complementary to, the day-to-day tasks for running the service that are managed by the service manager.

5. Benefits and Conclusions

5.1. Service Management Impact on Ongoing Open-Source Software Maintenance and Development

When we have a development work cycle for Spotlight at Stanford, the product owner is often the project manager for a major digital collection project that is leveraging Spotlight for discovery and delivery, alongside Spotlight’s storytelling features. Most recently, our periods of development work have incorporated significant new features, as part of Spotlight’s core code (for the community application) or on local features to be visualized in Spotlight at Stanford. The service manager often serves as Scrum master on these development work efforts [13]. This puts the service manager in a unique position, where the service manager has the opportunity to juggle the Scrum hat alongside advocating for work on the technical debt backlog and bugs. In addition, the service manager is then also able to represent user concerns to the product owner.

The service manager’s ability to serve as an advocate has resulted in a number of positive benefits. The team now uses semantic-like versioning paired with the GitHub changelog for new releases, using clear, understandable language. The service manager has become more comfortable with the practice of the development team releasing early and often, due to the mutual trust we have established. The service manager has faith, through experience now that problems caught early can be diagnosed more easily and fixed more quickly. The development team also knows that both the service manager and the service team are on the front line with users, and the feedback they share is more understandable and often more actionable.

As highlighted previously, team building is essential to a high functioning service team. In fact, these positive communication foundations make a difference throughout the entire service life cycle. Facilitating open communication and working on fostering trust goes a long way to helping every stakeholder in the process feel more understood. Key communication partnerships are highlighted in Figure 6.

5.2. Service Management Impact on Product Adoption and Success

How has the work of the service team impacted Spotlight at Stanford? We benefited from significant growth on numerous fronts in the calendar year 2017. The number of exhibits grew by 145% over the 2014–2016 total, adding 32 new exhibits in 2017, and bringing the lifetime total number of exhibits published to 54 at the end of 2017, as summarized in Figure 7a. In 2017, the service team conducted 15 training sessions for 22 exhibit creators and fielded 171 feedback tickets filed by exhibit creators and users, as depicted in Figure 7b.

Our growth continues apace; in early December 2018, prior to the compilation of statistics for the calendar year, we have 76 published exhibits.

The service team will be including an additional task to measure success in the upcoming 2019 business value prioritization exercise. The task is to conduct a round of formal user interviews to explore satisfaction levels with both the service and the web application. This would be the first round of user interviews conducted since the personas were developed to inform the creation of Spotlight in 2014. We will see where this task ends up on our priority list.

What has the service team been up to in 2018? We used the same business value exercise to help prioritize our goals. We settled on a set of goals intended to make our user documentation more robust. This included an idea of Gary Geisler’s to create a demo exhibit, helping exhibit creators to better use and visualize the Spotlight at Stanford tool set.

As Gary started creating the “exhibit on exhibits,” and he demonstrated an early skeleton to the service team, we had a collective “aha!” moment. We realized that all the yearly goals we had set for ourselves would result in content that could be folded in to the exhibit on exhibits. This required some adjustments, but we were excited to work together on this unified whole and as they say, “eat our own dog food.” We published the public-facing exhibit on exhibits in September 2018 [14], Figure 8.

We’d like to highlight a couple of exhibit successes. In January 2018, we migrated Parker on the Web to Spotlight at Stanford, as shown in Figure 9. Parker was a standalone website we launched at Stanford in 2009, with our partners at Corpus Christi College, Cambridge University. It was rapidly becoming outdated, and we needed to remove the paywall which had limited visibility of the richest scholarly content to paying institutions only. Among other enhancements, we created a feature that imports bibliographic entries from Zotero, and indexes and displays them in Spotlight. Alongside indexed annotations, robust descriptive metadata display, and the ability to view images in Spotlight via Mirador [15], Parker on the Web made the transition to a well-supported, sustainable platform amid much fanfare among medievalists the world over [16].

Images of Rome was a collaboration with a team based at Stanford’s Center for Spatial and Textual Analysis [17]. The distributed team prepared their digital images for accessioning into the Stanford Digital Repository and labored intensively over the creation of robust descriptive metadata. They also created point location data, in order to leverage Spotlight at Stanford’s Blacklight heat map UI, which enables the display of geolocation data on the show page for each item record. The exhibit garnered significant press, including articles in the National Geographic and Smithsonian Magazine. We recently partnered with the same team on a second project, featuring an archival collection of photographs of Rome, to continue their documentation of Rome’s spatial history. The team published this second exhibit in December 2018, “The Urban Legacy of Ancient Rome. [18], Figure 10.

The Urban Legacy of Ancient Rome was a collaboration built upon the model that emerged from the Images of Rome exhibit [19], a collaboration with the same research team. Successful touchpoints included:

• Stanford Libraries collaborates across campus with a number of key constituencies, including various research centers like the Center for Spatial and Textual Analysis (CESTA), the home for a team documenting the spatial history of ancient Rome [20].
• The research lead from the CESTA Rome team reached out to key staff in Stanford Libraries, with a specific interest in building a Spotlight at Stanford exhibit to showcase recent work, and to use it as a deliverable to satisfy a granting agency.
• Using the same approach as we employ for working with library curators on digital projects—especially in terms of the division of labor—we agreed to collaborate with the CESTA team and support their request for both long-term preservation of their digital images in the Stanford Digital Repository (SDR), and hosting of a Spotlight at Stanford exhibit for The Urban Legacy of Ancient Rome. This support included:

  ○

  Lightweight project management;

  ○

  Provision of digitization specifications for the CESTA team to use with the on-site imaging vendor in Rome;

  ○

  Provision of the specification and training so that the CESTA team could register content in the SDR system, and deliver fully prepped digital images to the library for accessioning into the SDR by digital library staff;

  ○

  Metadata consultation for the CESTA team so that they could create descriptive metadata to suit their project requirements; training so that the team could upload the metadata to the SDR themselves, and also enable them to perform quality control on their work;

  ○

  Further specialized metadata consultation to specify and enable CESTA team creation of properly formatted geo metadata;

  ○

  Creation of the exhibit stub for The Urban Legacy of Ancient Rome; training so the CESTA team could create their exhibit, and follow-on service support related to fine-tuning of the exhibit prior to CESTA team publication.

5.3. Spotlight Service Community

We would not have achieved our successes without the support and dialog of the Spotlight Service community. Established by colleagues in late 2017 from Texas A&M, Stanford, Harvard and Cornell, we conduct community calls, share demos and best practices, and maintain a code4lib slack channel. We facilitate the exchange of ideas, leverage the good work of our colleagues, and learn from one another by openly sharing our experiences. We believe we have an obligation to share our successes and challenges with our colleagues, and we are the better for it.

We created a Spotlight Community wiki, where we document best practices, meeting agendas and more [21], Figure 11. We also maintain a Youtube playlist for our demos [22].

5.4. Next Steps for the Spotlight at Stanford Service

We are currently at the beginning of our third year as a team, preparing to work on new goals. The service manager is also looking ahead to the coming year to continue evolving the service, hopefully incorporating new tools and including some team rotations to infuse us with new energy and ideas.

One of the challenges for service managers is trying to stay a step ahead of the service team. For Spotlight at Stanford, the service manager remains on the lookout for new trends and tools in service management. For example, they are completing a webinar on service blueprinting, a service design tool they hope to share with the team in the upcoming months. Service blueprinting provides an organization with an objective picture of how your organization delivers, what they deliver, and an end-to-end view of how it is orchestrated. The service manager also tries to keep their finger on the pulse of big picture trends and changes in the department, and at Stanford. For example, a separate instance of Spotlight has been set up so that students can create digital portfolios for selected classes, and the uptake is being monitored to see how the use and need for this service grows.

5.5. Key Takeaways for Building an IT Service in a Library or Archive

Each organization has different resources available, and we are conscious of Stanford’s robust digital library staffing model. Here are key takeaways we hope will be useful to anyone interested in building an IT service, or iterating on an existing one, irrespective of resources.

• Have a plan but be willing to change it

  ○

  When a plan is written down, particularly when this entails committee or management approval, it is hard to take a step back and course correct if something starts to go awry. It is not unheard of that what was thought to be a good idea in theory falls flat in actual practice. The key to a successful service framework is continual iteration and improvement.

  ▪

  If your proposed division of labor is not working out, regroup with your colleagues and try something new.

  ▪

  If timelines and deliverables not being consistently, get advice from a mentor, or huddle with your team to try and determine why, in a non-confrontational way.

  ▪

  If the use of your service is not growing as you anticipated, consider various methods for gathering feedback from users and target the highest priority item received from the feedback as an opportunity to change something about your service model.

  •

  Learn about IT service management and service design.

  ○

  If there are user experience designers in your organization, chances are they may have service design training. Reach out and tap into what they know and ask for their suggestions for additional resources or training opportunities.

  ○

  Check out online and in person training opportunities. One example is http://libraryjuiceacademy.com/. They currently offer a course on service design.

  ○

  Get to know people in your broader IT organization. Find out if they offer lectures or workshops in IT service management, or if they have a reading group.

• Be willing to try something new

  ○

  Be open to advice from a mentor or colleague. Maybe you have an idea for a new way to do user outreach, for example. You are not sure it will work, but no one has ever tried it before. Taking a chance will always provide useful information. Even if your new approach is not successful, perhaps in trying it you are led to an even better solution.

• A small change can have a big impact

  ○

  Let’s say you have set up a small service team. Do you have meeting agendas? Are action items and due dates recorded? Do you rotate note taking responsibilities? Sometimes implementing the basics, especially if they are new to your organization’s way of doing business, can be transformational.

• Listen to different points-of-view

  ○

  How often do you attend colleagues’ presentations and colloquiums when you have the chance to do so, either locally or at professional conferences? Here, we are referring specifically to colleagues who are the customers of your service(s).

• Share what you learn

  ○

  Seek out local, regional, and/or national opportunities to present a lightning talk, participate in a panel, or give a full presentation. Your experiences are valuable and unique, and your colleagues can benefit from them.

  ○

  Sharing failures and course corrections can help teach others who may be taking a similar path. This can also spurn dialog and encourage colleagues to talk about their failures and organizational concerns.

• Relationships matter

  ○

  Service management is collaborative work. Building and nurturing professional relationships are essential to productive interactions. How often do you interact with colleagues who are service customers?

  ○

  Does your organization offer training geared towards the improvement of customer service in general? What about communication and conflict resolution? These are important foundations to maintaining effective relationships and may be applicable to building your service framework.

Thank you to all Spotlight at Stanford service team members, past and present: Gary Geisler, Amy Hodge, Sarah Lester, Ryan Perkins, Josh Schneider, Kathleen Smith, and Doris Cheung-Wu. They really work hard, and we are better together!