Library systems documentation: Pulling it together with SharePoint

Documentation is crucial for a library systems office. But how have systems librarians documented their procedures, organized their documentation, and shared their knowledge? What tools do they use? This article will explore these issues and provide a case study of how the library Systems Team at the University of Maryland University College implemented SharePoint as a portal to organize and share their collective knowledge.Library Systems Documentation: Pulling it Together with SharePoint Introduction Documentation is crucial for a library systems office. But how have systems librarians documented their procedures, organized their documentation, and shared their knowledge? What tools do they use? This article will explore these issues and provide a case study of how the library Systems Team at the University of Maryland University College implemented SharePoint as a portal to organize and share their collective knowledge. Why is documentation so important? Those who claim that documentation is not so important because “anyone in the future should be able to figure out what was done in the past” should “[m]ake that argument to someone who has inherited an undocumented network and watch the response!” (Wilson, 1998, p.100). The goal of documentation is “to keep technology running smoothly and serving the good of the institution” and “includes organizing, collocating, and disseminating the knowledge that will help you and others succeed in your library’s technological environment.” It also provides “a concrete pool of evidence for you to point to in describing the importance of your department’s function to your institution” and “paints a picture of what you have done and of the technological environment that needs supporting (Engard and Gordon, 2012, p. 94).” What needs to be documented? “Think of the information that would have made your job easier and provide it for yourself, your staff, and your successor” (Engard and Gordon, 2012, p. 94). Document “how you do things so that if you have to do them again, you don’t have to start from scratch trying to remember how” (Rossman, 2003, p. 22). This includes configuration information for networks, servers and computers, maintenance procedures, as well as support issues and problem resolutions (Engard and Gordon, 2012). It is also important to establish a method for consistently documenting procedures and decisions (Wilson, 1998). How should things be documented? For common tasks, provide step-by-step instructions and be liberal with screen shots. These will coalesce into “a pool of documentation” for the systems staff (Engard and Gordon, 2012). From a higher level, to organize that pool into an effective portal, it is especially important to develop a carefully thought-out taxonomy, mapping out your sites, content types, and navigation, as well as a governance strategy for its ongoing management (Buckley, 2011). What tools are available? Common tools available in organizations include intranets, shared network drives, shared e-mail folders, help desk ticketing systems, and document management systems (Engard and Gordon, 2012; Lappin, 2010). A centralized portal and a tool that can manage records in multiple formats are desirable (Lappin, 2010). Large-scale enterprise content management (ECM) systems exist, but what many organizations really need is a system that provides basic content services (BCS) such as Microsoft SharePoint, which is a dominant player in this field (Pelz-Sharpe, 2008). SharePoint is of particular interest because it provides an integrated portal platform that combines document management tools with Web 2.0 communication and collaboration features, and it is readily available to Microsoft customers as part of the Microsoft Core Access License (CAL) Suite for institutions (Dahl, 2010; Diffin and Nangle, 2011). Wikis and Document Libraries provide a means of collaboratively creating, editing, storing, and managing documents. Many types of files can be stored in the Document Libraries, and SharePoint is designed to work seamlessly with Microsoft Office (Dahl, 2010). Announcement, discussion, and blog tools allow a centralized hub for managing a team’s communications. Calendar and survey tools are also included, as are workflow tools for managing projects and tracking issues (Herrera, 2008). What have other libraries done? In the literature, there are a number of examples of libraries that have implemented SharePoint for documentation and communication. For example, SharePoint has been implemented at Towson University to create a portal for the reference team (“RefPortal”) (Dahl, 2010); at the University of Mississippi to build departmental sites (Herrera, 2008); at the University of Maryland University College for the Document Management Team (interlibrary loan and book delivery) (Diffin et al., 2010b); and at the University of Alabama for instruction requests, reference, and interlibrary loan (Ennis and Tims, 2010). At the University of Mississippi, the library’s Information Technology department has a SharePoint site, and they use SharePoint’s blog for IT alerts and news items and have developed wiki pages for setup and troubleshooting tips (Herrera, 2008). At the University of Alabama, after developing their initial SharePoint sites, the library used SharePoint to create “Help Central,” which functions as a help desk and knowledge portal. It provides a ticketing system for users to report issues, for the staff to track and monitor the tickets, and for solutions to be added to a knowledgebase (Ennis and Tims, 2012). The present article will elaborate further on how SharePoint can be used as a portal for systems documentation, and discuss how a taxonomy was developed, how the actual documentation was written, and some of the best practices that were adopted. Background UMUC Library Systems The University of Maryland University College (UMUC) is a predominantly distance education institution serving more than 97,000 students in more than 25 countries (University of Maryland University College, 2012a, 2012b). Information & Library Services (ILS) relies heavily on technology to deliver library services to students, faculty, and staff worldwide. The Systems Team consists of four librarians: a Systems Librarian, a Digital Services Librarian, an Advanced Technologies Librarian, and a Web Specialist. Each of these librarians has very specialized knowledge, which makes it difficult for anyone else to fill in on those duties. (For the purposes of this article the Digital Services Librarian is being considered as a second Systems Librarian, in that this position also provides technical support for faculty, staff, and students.) The team manages a wide variety of areas, including access to electronic resources, server applications, software installation, cataloging, and the Web site. Other responsibilities include developing multi-media learning objects, in-house databases, and customized programs for the Web site. Before SharePoint Before implementing SharePoint, all of the four team members managed their own documentation. There was a tendency to use the library’s shared network drive (the “S-drive”), but team members also kept documentation on their individual computers and in file cabinets, and much was kept in their own heads. Some procedures were documented; some were not. There was no systematic effort in creating, organizing, and sharing knowledge among the whole team, and there were no best practices. Documentation on the S-drive could be difficult to find and sometimes became outdated. Earlier, some of the staff members had made “Survival Guides” listing where their documentation was stored, and the Systems Librarian compiled a local “Procedures” Web page to try to point to all the various documentation, but none of these were consistently maintained or were ever heavily used. What the team needed was a central portal and more consistent procedures for documentation. Cross-training initiative Since ILS is a small library, it is critical to have training and documentation that allows someone to step in for another person and keep things moving in case of absences due to illness or vacations. The Document Management and Electronic Reserves (EReserves) Teams had recently embarked on a successful cross-training initiative that included using SharePoint for documentation and conducting cross-training sessions between the two groups. To keep the knowledge fresh once the initial training was complete, every member of both teams worked in the other area one day a month. SharePoint was chosen as the collaboration tool because it was designed specifically to manage documents, share information, and facilitate communication. Plus, the UMUC IT department had a license for it and had made it available without the library incurring any additional cost. While other options were considered, such as free, online wikis, none of them had all the functionality offered by SharePoint. Also, these services could disappear or become fee-based at any time, and there was no guarantee that data would be retrievable if the services went down. Knowing that the IT department hosted the secure SharePoint server and that they backed it up daily eliminated the concern for potential data loss (Diffin et al., 2010b, p. 231). The cross-training worked so well that the Assistant Director for Systems and Access Services then expanded the idea to the Systems Team. Using the concepts learned by Document Management and EReserves, the Systems Team began a more formalized process of sharing and documenting knowledge. Implementation Getting started The Assistant Director for Systems and Access Services had some initial meetings with the Systems Team to discuss the cross-training project and to decide how the team would proceed. The main focus of this project would be building the knowledgebase. The UMUC IT Department had created a SharePoint site for the Library, and a Systems sub-site was added. The launch of the Systems site created a sense of community among the team members and officially marked the beginning of the implementation. Site structure As part of the planning, the first priority was to develop the site structure. This provided a fresh start to reorganize the documentation strategically. The structure and hierarchy was mapped out according to the team member functions, including: cataloging, electronic resources, in-house applications, IT (hardware, software, and server management), multi-media learning objects, patron and staff assistance, and Web site management, plus useful contacts. Best practices and conventions Given that the Document Management Team had already “implemented best practices for the wiki so it would have a homogenous look and feel even though several different people were working on it” (Diffin et al., 2010a, p. 575), a member of that team was invited to speak to the Systems Team. He covered the basics of SharePoint’s tools and features and shared best practices on style and visual aids. Verdana was chosen as the text font and standardized sizes were adopted for content and headers. Annotated screenshots were preferred over descriptive paragraphs for concision. Breadcrumb trails would be added to the very top of every wiki page for navigation. Internet Explorer became the preferred browser when updating wiki pages because important formatting features in SharePoint were exclusive to this browser. A consensus was reached that the wiki feature would be used as the main tool for creating, organizing, and sharing documentation because of the following features, as summarized by Diffin and Nangle (2011, p. 136): 1. Editing and updating is easy through the WYSIWYG (What-You-See-Is-What-You-Get) editor. 2. Errors can be quickly and easily undone using version history which encourages collaboration. SharePoint creates a new version of the document whenever any change is made in a document. 3. E-mail alerts inform subscribers of any changes to wiki pages. 4. Permissions can be added to selected pages that contain sensitive information. 5. Visual aids (e.g. screenshots) can be inserted to simplify documentation. In addition, all wiki pages can be distributed and shared via URLs. The Systems Team then came up with documentation conventions for the wiki pages that specified several recipe-style elements to be included as needed, such as background information, tools, how-to steps, and problem resolution. Tools included what the user would need (e.g., software, user IDs and passwords, directories) to complete the documented task. The how-to section included step-by-step instructions with screenshots. Problem resolution indicated things that have gone wrong and steps that were taken to fix the issue. When the rubber hits the road Based on the job duties, the responsibilities for creating content in SharePoint were divided among the four library professionals. The Systems Librarian was responsible for Web sites, cataloging, and IT. The Digital Services Librarian documented electronic resources and provided assistance with Web sites. The Web Specialist worked on in-house applications. The Advanced Technologies Librarian covered the multi-media learning objects. Each member decided on the structure and content within their assigned functional areas while still following the basic agreed-upon guidelines and conventions. The Systems wiki site then started to take shape. Over time, the initial structure was fleshed out considerably, as documentation was migrated from the S-drive or created anew. In some cases, sub-menus were created to refine the organizational structure. For example, the top-level IT page linked to a page called “Server Applications,” which in turn linked to pages on EZproxy, ILLiad, and PeopleSoft. As documents migrated off the S-drive and were converted into wiki pages, shortcuts were provided from the S-drive to the new SharePoint site so that anybody looking for the old documents could get to the new documents quickly. Perhaps more importantly, links were provided in SharePoint to the documentation that still resided on the S-drive, so that SharePoint could effectively function as a portal to all or most of the documentation. The idea was that a user could come to SharePoint and still get to everything, even if some things were still on the S-drive. While Word documents on the S-drive were generally re-done in wiki format, other types of documents (e.g., spreadsheets) were simply uploaded into SharePoint into the “Documents” area. These were organized into subfolders as needed, and were linked to from wiki pages where appropriate. The S-drive would still be needed for certain types of files, such as software installation executable files. Also, documents that were not currently in use but were needed for historical purposes would remain on the S-drive and not migrated. During implementation, monthly team meetings were scheduled to review progress. The members presented their new wiki pages, elaborating on the procedures, policies, and knowledge contained therein. The other team members then had a chance to ask questions about the procedures. For example, one member asked for clarification on how Captivate tutorials were created; another asked for details about updating electronic resources. This cross-training enabled all the team members to become familiar with each other’s work and to know where to look if questions came up during a team member’s absence. After much of the initial documentation was created, team members made an ongoing effort to review and update their pages and met every few months to discuss the updates. They signed up for e-mail alerts to be notified when pages were updated. The Result The home page The Systems home page includes a checklist of important maintenance functions in the center. On the right is a who’s who, indicating which staff have responsibilities for the various areas. At the bottom of the home page is a list of current projects. The site navigation bar on the left contains the menu linking to the top-level functional areas of the wiki. Also included on the navigation bar are standard SharePoint links to “Documents” (the library of uploaded documents, such as spreadsheets), “Pictures” (in this case, the library of uploaded screenshots), and other tools (Calendar, Lists, Discussions, Sites, People, and Groups). 1. Home page Organization The major functional areas, comprising the top-level navigation, are as follows: Cataloging: This includes cataloging and weeding procedures, links to useful documentation (such as MARC standards), and the necessary tools (such as OCLC logins). Contacts: Important contact information for the IT department (including after-hours and emergency numbers), plus other UMUC units and external vendors of vital importance, as well as the after-hours contact information of the library Systems Team members is gathered here. Electronic Resources: Providing technical support for electronic resources includes documentation on setting up, branding, and troubleshooting electronic resources, maintaining the SFX linking service, and obtaining Lexis.com IDs for the Legal Studies program. In-house Applications: This section includes documentation on special processes that were created by or for the library. These include everything from Access and MySQL databases that were created for in-house use, outward-facing systems such as the electronic reserves request system used by faculty, and processes involving external systems, such as the nightly processes that extract patron data from PeopleSoft and load it into the library catalog. IT: This section became a launchpad for a broad range of systems documentation, including equipment inventories, software installation instructions, server applications (such as EZproxy and ILLiad), and IP and domain information. Learning Objects: Documentation in this section covers how multi-media and interactive learning objects on the library Web site were created and are maintained. Patrons and Staff: This section includes tools for assisting patrons (e.g., verifying whether a patron is current), a setup checklist for new employees, how-to pages for library staff (e.g., how to access network printers, tips for using Dreamweaver), plus links to some of IT’s help pages (e.g., about using UMUC e-mail and calendars). Web Site: The Web site management page contains documentation on how to use the content management system and what Web site conventions are in use (e.g., image and file naming conventions). 2. Top- level page for “IT” category 3. IT > Software Installation 4. IT > Software Installation > ILLiad Project management Although not initially considered during the planning stages, SharePoint has also been used by some of the staff as a simple project management tool. Pages have been set up for special projects, indicating to-do lists and timelines. These pages will be saved after project completion in order to document what was done. “Project” sections have been added to the top-level pages as needed, with links to these pages. Links to current projects are also placed on the Systems home page for easy access. 5. Project page that was developed when servers had to be taken offline for a facilities electrical upgrade In fact, SharePoint was used by the authors to collaborate on this article. A project folder was created in the Document Library, and each added a Microsoft Word document with their respective parts. The parts were then combined into a master document that was reviewed by the group. Further changes were made to the master document by the individual members with Word’s change tracking feature turned on, and SharePoint prevented more than one individual from working on the document at a time. The group then met again and reviewed the changes, approving or modifying them as needed. No documents were e-mailed back and forth, nor was there any confusion about what version was the most up-to-date. SharePoint, in conjunction with Word, proved to be a very useful collaboration tool. Conclusion SharePoint has been a very successful portal for the Systems Team. There is now a single, consistent interface for documenting and sharing knowledge and procedures. Having one central, structured location for documentation works much better than e-mailing how-to instructions back and forth or trying to find documents on the departmental shared drive. Links to wiki pages can be sent easily to library staff who ask about specific procedures. The two Systems Librarians, who need to cover for each other, have particularly benefitted and have been the heaviest users and biggest advocates. Having their documentation readily available is critical for the Assistant Director for Systems and Access Services, who also provides back-up coverage for technical support. The initial planning of the interface gave it a solid structure on which to grow, and consistent procedures for creating documentation have helped it grow in a somewhat orderly fashion. Placeholders for items that still need to be documented have been put in place, as have links to documentation that still lives on the shared network drive, enabling SharePoint to function as a more comprehensive portal. While the top-level structure has been stable, some of the lower-level structure may need some adjustment, as some pages have ended up getting buried. For example, to find the page on DreamWeaver Tips from the Systems wiki home page, the user has to click on Patrons & Staff on the left navigation menu, then on a link to Staff Instructions, and finally on a link for the DreamWeaver Tips page. This has frustrated some library staff members. Creating and updating wiki pages in SharePoint is not difficult due to the WYSIWYG editor