38 research outputs found
Cloud collaboration: Using (Microsoft) SharePoint as a tool to enhance access services
No full textOutline
•About Us
•Intranet overview
•Cloud computing overview
•Move to SharePoint
•SharePoint Wiki for Remote Circ Locations
•SharePoint as Comprehensive Cloud Intranet
•ConclusionCloud Collaboration:
Using (Microsoft) SharePoint as a Tool to Enhance Access Services
Jennifer Diffin
Assistant Director for Systems and Access Services
Fanuel Chirombo and Dennis Nangle
Library Technicians
April 29, 2010
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleOutline
•
About Us
•
Intranet overview
•
Cloud computing overview
•
Move to SharePoint
•
SharePoint Wiki for Remote Circ Locations
•
SharePoint as Comprehensive Cloud Intranet
•
Conclusion
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleHistory of UMUC
•
Founded in 1947
•
Primarily distance education serving working professionals
•
Approximately 86,000 worldwide headcount (~27,000 FTE)
•
Member of the University System of Maryland and Affiliated Institutions (USMAI)
•
Military contracts
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleInformation & Library Services (ILS)
•
Staff located in Largo, MD
•
Previously had physical libraries in Germany and Japan
•
Remote/satellite locations change
•
27 library staff members, 2 graduate assistants
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleDocument Management (DM) Team
•
1 Librarian
•
1 Library Associate
•
3 Library Technicians
•
4-5 student workers (shared with other library departments)
•
Remote circulation points throughout Maryland
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleILS Circulation Locations
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleOverview of Intranets
•
What is an intranet?
•
Functions of Intranets
•
What are the benefits
•
Limitations of UMUC Intranet
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleWhat is an Intranet?
•
A private network belonging to an organization’s members, employees, or others with authorization.
•
“…part of the organizational internal information system, dedicated to the support of group work and mastering of organizational knowledge.”
Botazzo, 2005
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleFunctions of Intranets
•
Administrative –finance, human resources, records management, course scheduling.
•
Academic-research, course work, publishing and course administration.
•
General-communication and public relations.
Weiner, 1999
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleWhat are the Benefits?
•
Sharing information and documents
•
Easy updating of documents
•
Saves time through online discussions
•
Quick and easy access to vital information
Natarajan, 2008
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleLimitations of UMUC Intranet
•
Restricted contributors-difficult to update, edit and/or access.
•
Interdepartmental promotional tool.
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleCloud Computing-An Overview
•
Became an official ‘buzz word’ in 2006
•
Has several definitions and contexts
•
An ‘official’ definition:
–
“In cloud computing…the software resides on an [I]nternet server run by or on behalf of the software supplier, and users get to access the features of those applications via the [I]nternet”
Venkatraman, 2009
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleA Helpful Metaphor for Cloud Computing
“My attitude towards online information…was pretty close to taking my paycheck in cash, and stuffing it under the mattress because I didn’t trust a bank to hold it for me… Now we can treat the [W]eb much more like a bank with a network of ATMs: it’s a secure repository with a network of points where you can withdraw your information on demand.”
Gunderloy, 2008
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleThe Appeal of the Cloud
•
Cost-effective
•
Efficient
•
Fosters Innovation
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleCloud Concerns
•
Security
•
Privacy
•
Data Ownership
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleThe Road to SharePoint
•
A Complex History
•
Initial Obstacles
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleA Careful Approach
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleSharePoint in Context
•
Departmental Move
•
Creating a service point without ILS staff
•
Developing a wiki for the new service point staff
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleEffective Knowledge Transfer
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleDocumentation Pre-SharePoint:
Dorsey StationWaldorf CenterCollege ParkAdelphi
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleDocumentation Post-SharePoint:
Dorsey StationWaldorf CenterCollege ParkAdelphiLargo
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleDocument Management’s “Cloud Intranet”
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleSharePoint-a Comprehensive Cloud Intranet
•
Information storage
•
Coordination
•
Communication
•
Collaboration
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleInformation Storage
•
Wiki for remote location of information
•
Document library
•
One-stop location of documents
•
Secure and easily accessible
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleCoordination
•
Calendar
•
Work scheduling
•
Leave scheduling
•
Responsibilities
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleCommunication
•
Discussion Board
•
Announcement
•
Sticky Notes
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleCollaboration
•
Version History
•
E-mail alerts
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleConclusion
•
Cloud Intranet
–
Convenient to access
–
Secure server
–
Flexibility
•
Strategy is essential
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleQuestions?
Jennifer Diffin –[email protected]
Fanuel Chirombo –[email protected]
Dennis Nangle –[email protected]
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleReferences
•
Bottazzo, V. (2005). Intranet: A medium of internal communication and training.Information Services & use, 25(2), 77-85. Retrieved from http://www.iospress.nl/html/01675265.php
•
Gunderloy, M. (2008). Is your information under the mattress or in the ATM?.Retrieved 12/11, 2009, from http://webworkerdaily.com/2008/07/30/information-under-mattress-or-in-atm/
•
Natarajan, M. (2008). Knowledge sharing through intranet.Journal of Library and Information Technology, 28(5), 5-12. Retrieved from http://publications.drdo.gov.in/ojs/index.php/djlit/article/view/414/286
•
Venkatraman, A. (2009). Capture the cloud.Information World Review, (255), 16-17.
•
Weiner, S. (1999). The university intranet.EContent, 22(5), 66-69. Retrieved from http://www.econtentmag.com
© Jennifer Diffin, Fanuel Chirombo, and Dennis Nangl
Library systems documentation: Pulling it together with SharePoint
No full textDocumentation 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
Predictors and consequences of achieving persistent remission, intermittent remission or never achieving remission in patients with recent onset inflammatory polyarthritis: Results from the norfolk arthritis register (NOAR)
No full textBackground: Relatively few studies have assessed sustained remission over a follow up of more than three years and at multiple time points to identify predictors and consequences of remission in patients with inflammatory polyarthritis (IP) and its subset rheumatoid arthritis (RA). Objectives: To assess: i) which baseline clinical and demographic factors are associated with achieving persistent remission (PR), intermittent remission (IR) or never achieving remission (NR) in patients with IP and ii) the association between achieving PR, IR or NR on functional disability progression. Methods: Patients aged >16 yrs with recent onset IP (≥2 swollen joints lasting for >4 weeks and symptom duration <2 years) were recruited to NOAR from 2000 to 2008. Baseline variables collected included age at symptom onset, BMI, C-reactive protein (CRP), rheumatoid factor (RF), anti-cyclic citrullinated peptide (anti-CCP) antibody, DAS28-CRP, HAQ score and self-reported comorbidities. Remission was defined as no tender or swollen joints (out of 51) and was assessed 1, 2, 3 and 5 years after baseline. Patients were classified as NR if they were not in remission at any anniversary assessment, PR if they were in remission at ≥3 consecutive anniversaries and IR otherwise. Univariate and multivariate ordinal logistic regression analyses were used to assess the association between baseline characteristics and remission group (NR was the lowest order group). A stepwise variable selection process was used to derive the multivariate model. Missing values were imputed using multiple imputation by chained equations in the multivariate model. A random effects model was used to examine the effect of remission group status on HAQ scores over time. Results: 868 patients were included in this study; 65.8% female, mean age at symptom onset 55.9 (SD 14.6) yrs and median disease duration 6.5 [IQR 4.1 to 11.1] months at baseline. The number (%) of patients achieving NR, IR and PR was 471 (54.3), 296 (34.1) and 101 (11.6), respectively. In univariate analysis, female sex, higher number of swollen or tender joints, satisfying the 2010 RA criteria, higher HAQ and DAS28-CRP scores, having at least one comorbidity, being hypertensive, depressed or obese at baseline were all associated with lower odds of being in a higher remission group (table). Female sex, higher number of tender joints, CRP, DAS28, HAQ, time from symptom onset to starting DMARD treatment and being hypertensive at baseline were independently associated with lower odds of being in a higher remission group in a multivariate model. IR and PR were associated with a reduced HAQ score compared to NR (referent), adjusted β (95% CI) for IR and PR -0.51 (-0.60, -0.43), -0.85 (-0.98, -0.72) respectively, p<0.001. Conclusions: Only 11.6% of patients achieved PR during a five year follow up. As well as clinical and demographic factors, comorbidities at baseline were significantly associated with reduced probability of remission. Benefits of remission in terms of improved functional disability were seen, supporting the “treat to target” strategy. (Figure presented)
Cloud collaboration: Using Microsoft SharePoint as tool to enhance access services
No full textProper knowledge-base access and document storage has long been an issue for the Document Management Team (Access Services) at the Information and Library Services of University of Maryland University College. Team members researched Share-Point and decided it could be exploited as a combination of intranet and cloud computing technologies. SharePoint?s features allow it to be a 1-stop location tomanage information in a secure, efficient, remotely accessible, and consolidated manner. The team could then reduce redundancy and knowledge gaps by using the collaboration and communication features. This article will discuss the steps the team took to transition several previous avenues of document storage and knowledge base access into SharePoint, specifically in the case of creating a troubleshooting wiki for remote circulation locations.Cloud Collaboration: Using (Microsoft) SharePoint as a Tool to Enhance Access Services
Jennifer Diffin, Fanuel Chirombo, Dennis Nangle
University of Maryland University College
Abstract
Proper knowledge base access and document storage has long been an issue for the Document Management Team (Access Services) at Information and Library Services of University of Maryland University College. Team members researched SharePoint and decided it could be exploited as a combination of intranet and cloud computing technologies. SharePoint’s features allow it to be a one-stop location to manage information in a secure, efficient, remotely accessible, and consolidated manner. The Team could then reduce redundancy and knowledge gaps by using the collaboration and communication features. This paper will discuss the steps the Team took to transition several previous avenues of document storage and knowledge base access into SharePoint, specifically in the case of creating a troubleshooting wiki for remote circulation locations.
Introduction
Remote access to information, knowledge sharing, and communication play pivotal roles in distance education. The growing popularity of cloud computing combined with intranet technology has made achieving this much easier. The University of Maryland University College (UMUC) has chosen Microsoft’s SharePoint product as an internal information sharing solution that combines the best features of both intranets and cloud computing, such as security, ease of use, and remote accessibility. This article will focus specifically on facilitating internal staff communication and collaboration across remote locations by using SharePoint as an intranet and cloud computing solution.
Background
The University of Maryland University College has a strong history of distance education. UMUC was founded in 1947 “to provide off-campus, evening, and weekend courses for adult, part-time students throughout the state” (Hudgins, 2000, p. 1). Within a decade it was offering classes at military installations around the world. UMUC currently has a worldwide headcount of over 86,000 students in over 20 countries (University of Maryland University College, Office of Institutional Planning, Accountability and Research, 2009). Information and Library Services (ILS), formed in the early 1990s, works diligently to support faculty, students, and staff in their research needs.
Although UMUC has worldwide office locations, the library is currently located in Maryland. In the past, there were satellite libraries in Germany and Japan. The library support for these locations is now remotely handled by ILS. Within the State of Maryland, ILS has three remote circulation pick-up and return locations. Although they are all physically located in the same state and time zone, communication and training was historically uneven and unreliable.
ILS’ Document Management Team (Access Services - Circulation and Interlibrary Loan) struggled with the best way to handle training and documentation for these remote circulation points over the years, as well as their own internal documentation and communication. Since library circulation is not the main responsibility of the non-library staff at these remote circulation points, it is extremely important to keep all documentation current and accurate, and to maintain open communication to answer questions and provide additional training as needed. There is also a need to keep this knowledge current at the main library location and to streamline the workflow through efficient communication and collaboration. An early attempt at documentation was three-ring binders. These were difficult to keep current as each binder had to be manually updated across all locations when procedures changed. Then, a staff member attempted to create an online circulation manual that pointed to material on a shared network drive. While this was a step forward in centralizing and digitizing the documentation, it never got off the ground due to security issues. Next a standalone wiki was created. This seemed promising as it was easy to access from the remote locations and it was easy to update. Documentation only needed to be updated in one location, and was then accessible by all who needed to use it. Yet, the wiki was located on a local computer that was not backed up on a regular basis. The staff constantly worried about the computer crashing and losing everything in the wiki. Also, while the wiki was a great place for documentation and procedures, it did not really allow for staff collaboration and communication.
Intranets – a brief definition
Of the Document Management Team’s previous information sharing solutions, the online circulation manual could be most likened to an intranet-based solution. An intranet is a private network belonging to an organization accessible only by the organization’s members, employees, or others with authorization. Similar to the Internet, an intranet’s Web site looks and act just like any other Web site, but the username-and-password authentication surrounding an intranet fends off unauthorized access. Bottazzo (2005) defines the intranet as “…part of the organizational internal information system, dedicated to the support of group work and mastering of the organizational knowledge” (p. 79). Gunjal (2004) identifies central information storage and effective communication flows in organizations as some of the important attributes of intranets. Within libraries, Gunjal singles out the facilitation of information sharing as the primary benefit of an intranet as “it helps in dissemination of stored information as well as allows to access to remote information” (p. 9). For example, any paper documents can be converted into HTML and made Web-accessible on an intranet. Such documents can range from staff training manuals, policies, schedules, procedures, to calendars of events (Gunjal, 2009).
Weiner (1999) divides intranet functions at a university into three categories. These are administrative, academic and general. The administrative functions are concerned with finance, human resources, records management and course scheduling. The academic functions refer to research, course work, publishing and course administration. General refers to communication and public relations. This can range from calendars of events that display the programs and activities of the organization to a vast range of internal organizational information that may include employee lists, telephone and office number lists and geographic locations of departments.
Building on Weiner, Natarajan (2008) provides a list of some of the key benefits of an intranet: (1) Employees can share information and documents; (2) Any authorized staff member can easily update documents; (3) Teams can save time through online discussions instead of holding physical meetings; (4) Organization can access their vital information easily and quickly. The shared access provides a platform where documents are saved in a standard form at a specific location where every employee can easily access a specific document. The intranet’s bulletin or discussion board is an important outlet that allows employees to express their opinions and ideas. Employees can make use of a calendar of events on the intranet to arrange meetings and book other appointments. Gunjal (2004) conclusively asserts that “intranets are relatively cheap and easy to develop because they use the existing technology of the internet” (p. 14).
As much as intranets have emerged as an effective paradigm for information sharing, the UMUC intranet is set up as more of a one-way communication tool. In order to update or add information to the intranet, one must submit a request to the UMUC department that is responsible for its maintenance. Due to this delayed and inefficient method, the UMUC intranet could not serve as a proper consolidated space for multi-user collaboration. The University’s departments primarily use the intranet as a way to promote their department to the rest of the university; the intranet is not used in the ways Natarajan and Gunjal suggest above. As a result, the Document Management Team attempted to create an intranet of their own: an online circulation manual that was web-based, and linked to pages on the shared network drive. This approach was effective for those whose offices were at UMUC’s stateside headquarters, since they had access to this shared network drive. However, remote circulation staff was unable to view the manual, which essentially forced the Team to start at square one with their knowledge base. Also, due to the fact that the online circulation manual links to an internal drive, the IT department deemed it unsafe for remote access. The fact that the UMUC intranet was not set up as a document repository necessitated the Document Management Team to consider cloud computing as an optional knowledge base and information sharing system.
Cloud Computing- a brief background
The term cloud computing, while certainly prevalent in today’s technological discussions, came into prominence in 2006 when Google CEO Eric Schmidt started referencing the term in popular discussions (Nelson, 2009). Certainly, the term (and concept) has skyrocketed in popularity since then. However, a definition of cloud computing reflects the metaphor applied to the concept itself: anomalous and difficult to pin down. Archana Venkatraman (2009) offers an appropriate definition of cloud computing: “In cloud computing…the software resides on an [I]nternet server run by or on behalf of the software supplier, and users get to access the features of those applications via the [I]internet” (p. 16). Mike Gunderloy (2008) defines cloud computing more simply, comparing the difference between traditional and cloud computing to the difference between retrieving money stored under the mattress or at an ATM:
My attitude towards online information…was pretty close to taking my paycheck in cash, and stuffing it under the mattress because I didn’t trust a bank to hold it for me… Now we can treat the [W]eb much more like a bank with a network of ATMs: it’s a secure repository with a network of points where you can withdraw your information on demand. (p. 1)
A brief scan of recent library literature shows that cloud computing is lucrative for libraries of all kinds. Most libraries’ motivations for moving into the cloud are cost effectiveness and efficiency. Lynn Collier (as cited in Venkatraman, 2009), the Director of Archive and Compliance Solutions at Hitachi Data Systems, further explains the cost-effectiveness of the cloud: “A key prerequisite to cloud computing is to pinpoint where maximum savings can be made based on a realistic and accurate understanding of the content” (p. 17). Andrew Pace (2009), Executive Director for Networked Library Services at OCLC, emphasizes that the key benefit to cloud computing for libraries is to free up the librarians’ time to allow for innovation:
Despite a surge of online content being available to patrons, libraries will continue back-office operations for all types of materials. The more these workflows are industrialized and served by network-level applications, the more time and effort libraries can assign to other intellectual endeavors. (p. 649)
While there is plenty of documentation to prove the effectiveness of cloud computing, there are several concerns surrounding the adoption of this new technology. Paramount to all other concerns is the issue of security. John Sheridan (as cited in Venkatraman, 2009), head of e-services at the National Archives, explains: “While there is an exciting possibility and inevitability of the cloud model for the information community, concerns of portability, security, and privacy remain unsolved” (p. 17). It would appear that cloud computing’s greatest strength - ease of use and access - is also its greatest potential downfall. Another issue that commonly plagues cloud computing software is ownership (or lack thereof). Robin Hastings (2009) warns, “Data ownership is an issue any library must consider before making the decision to upload to a public server. Sensitive information like budget data, internal memos, or documents concerning major organizational decisions should never be uploaded to a public server” (p. 12). These two concerns cause many libraries to look at cloud computing as more of a recreational platform to reach out to patrons, and not a reliable location for sensitive internal data.
The Document Management Team saw the problems inherent in both intranets and cloud computing, but realized that the valuable functions of the technology were difficult to ignore. Intranets, while touting security, are frequently inaccessible to those outside of an organization’s range of IP addresses and its firewall. Cloud computing, on the other hand, is efficient and easy to access from any location, but is laden with security issues. With these concerns in mind, the Document Management Team was initially hesitant to migrate their information into SharePoint. However, after much research and trial testing, the Team realized that an effective approach to the SharePoint application could result in the creation of a “cloud intranet” -- an online environment that takes advantage of intranets and cloud computing’s strengths, while circumventing their inherent weaknesses. SharePoint became a consolidated storehouse of the Team’s information and knowledge base, all while maintaining a high level of security. The UMUC library’s recent move to a new physical location illustrates how effective the Document Management Team’s SharePoint site was as a functioning cloud intranet.
Move to SharePoint
ILS began investigating Microsoft SharePoint in 2008 while it was being piloted by the IT Department at UMUC. It quickly became clear to the Document Management Team that this could be what they were looking for in terms of bringing documentation, communication, and collaboration together in one place. Although having a “free,” institutionally supported program to use was a factor in the decision to use SharePoint, the product’s features and limitations were carefully considered before the Team decided to move forward. In the context that the Team is using SharePoint, it can be defined as both an intranet and cloud computing, or even cloud collaboration: “… unlike a simple intranet or collaboration solution, SharePoint also includes portal, Web content management and business intelligence capabilities” (Koplowitz & Owens, 2009, p.8). Although the Team had made progress over the past several years by moving from print binders to an online circulation manual to a wiki, nothing up to this point worked as a truly collaborative space. After some initial interest in SharePoint, several factors slowed down the migration process.
One reason for the slow start to the migration project was the turnover of several staff in the Document Management Team. This change in staffing was just one more indication that using SharePoint was a good idea: “The SharePoint approach helps limit the liability of concentrating knowledge in one person and minimizes the effects of attrition” (Fox & Deutsch, 2000). Having a primarily new Team was a great opportunity to switch the knowledge base to SharePoint and spread the knowledge around the Team as much as possible.
When the project did start taking shape, there was a conscious decision to not simply repeat what had been done before. The Team implemented best practices for the wiki so it would have a homogenous look and feel even though several different people were working on it. Initially, the Team simply moved documents from the messy, outdated shared network drive to the SharePoint document library. They then realized an opportunity to step back and rethink the hierarchy and structure of the information. As Koplowitz & Owens (2009) noted, “Just because the tools exist doesn’t mean the structure will build itself. Careful planning is required, and plans will need to adapt as new lessons are learned. Don’t take lightly the opportunity a blank slate offers” (p.22). Many documents became wiki pages instead of storing them in the SharePoint document library based on this thoughtful restructuring of the information.
In addition to asserting that libraries can use an intranet to access remote information, Gunjal (2004) states:
With increasing emphasis on resource sharing not only between libraries but between different branches and departments of a library, the intranet offers the potential to be a very important tool in libraries’ effort to make the most efficient use of their resources. (p.10)
The Document Management Team saw this potential in SharePoint and decided it would work very well for documentation and training at the remote circulation locations. Consequently, the next step in the migration to SharePoint involved setting up a site for the remote circulation points to use when needing to refer to policies, procedures, and documentation. This would replace the haphazard method of documentation these remote sites were currently using. The project was further spurred on by the need to train and provide documentation for the people staffing a new remote circulation location.
SharePoint Wiki for Remote Circulation Locations
In preparation for ILS’ move to the new UMUC Academic Center at Largo, Maryland, the Document Management Team worked with UMUC’s Office of Enrollment Management (OEM), which staffs the Information Desk at the library’s previous location, to provide a circulation point and train them on relevant policies and procedures. On September 3, 2009, the Associate Provost for ILS, Assistant Director for Systems and Access Services, and the Document Management Librarian met with OEM management to discuss the feasibility of the Information Desk becoming a remote circulation location. It was decided that OEM staff should be trained and given an opportunity to pilot being a circulation point while ILS was still in the same building. On September 14, 2009, the Document Management Librarian met with the Assistant Director of the Information Desk to demonstrate SharePoint as an informational and collaborative tool that could be used as a knowledge base for staff to refer to when they had circulation questions. The Assistant Director was very interested in using SharePoint and expressed an interest in also using it for his own team. The Document Management Librarian and Library Associate trained all of the OEM staff who work at the Information Desk on November 3-5, 2009. By November 17, 2009, the SharePoint wiki for the Information Desk was in its final form and location. Although this was specifically created as a result of this Information Desk becoming a circulation point, it was also intended for it to be used by the other remote circulation points. All of the remote circulation locations are now using the SharePoint wiki. The Information Desk officially became a remote circulation location on November 18, 2009.
The main SharePoint feature used for the new remote circulation documentation was a wiki. Although the Team had already been using a standalone wiki for documenting procedures, it was one of several places to look for this information and one was never sure what was current or accurate. The standalone wiki was also never backed up and the computer it resided on could crash or disappear at any time. Moving the wiki and all other documentation into SharePoint allowed for consolidation of information, all users know where to look for information, and can trust that it is the most recent version. Also, SharePoint is on a secure server that is backed up daily, so there is no fear of data loss.
The SharePoint wiki is easy to create and maintain using a WYSIWYG (What You See Is What You Get) editor. The Document Management Library Associate created the content for the wiki for the Information Desk and other remote circulation locations in November 2009. A student worker put the content into the wiki using the best practices guide, which was created as a SharePoint wiki page. The remote circulation wiki includes step-by-step directions for circulation functions and a troubleshooting section. It also includes a staff list of the Document Management Team including pictures. This was especially helpful during the training and transition phase.. It helped the Information Desk staff become familiar with the Team and to know who everyone was when a member of the Team dropped off and picked up books at the Desk during the transition. The three training sessions during the first week of November 2009 for the Information Desk Staff were face-to-face. After a couple of attempts to find the appropriate “home” for this wiki within the Document Management SharePoint site, the wiki was given its own site called “OEM & MD Ops.” Office of Enrollment Management (OEM) and Maryland Operations (MD Ops) are the depart
ENDO-Pore test files
No full textFASTA files from C3POa for analysis using Cleavage Site Investigator. "ENDO-Pore: High-throughput linked-end mapping of single DNA cleavage events using nanopore sequencing" Oscar E. Torres Montaguth, Stephen J. Cross, Kincaid W.A. Ingram, Laura Lee, Fiona M. Diffin and Mark D. Szczelkun https://doi.org/10.5281/zenodo.505704
Predictors and outcomes of sustained, intermittent or never achieving remission in patients with recent onset inflammatory polyarthritis:Results from the Norfolk Arthritis Register
No full textObjectives: Early remission is the current treatment strategy for patients with inflammatory polyarthritis (IP) and RA. Our objective was to identify baseline factors associated with achieving remission: sustained (SR), intermittent (IR) or never (NR) over a 5-year period in patients with early IP. Methods: Clinical and demographic data of patients with IP recruited to the Norfolk Arthritis Register (NOAR) were obtained at baseline and years 1, 2, 3 and 5. Remission was defined as no tender or swollen joints (out of 51). Patients were classified as NR or PR, respectively, if they were in remission at: no assessment or ⩾3 consecutive assessments after baseline, and IR otherwise. Ordinal regression and a random effects model, respectively, were used to examine the association between baseline factors, remission group and HAQ scores over time. Results: A total of 868 patients (66% female) were included. Of these, 54%, 34% and 12% achieved NR, IR and SR, respectively. In multivariate analysis, female sex (odds ratio, OR 0.47, 95% CI: 0.35, 0.63), higher tender joint count (OR = 0.94, 95% CI: 0.93, 0.96), higher HAQ (OR = 0.59, 95% CI: 0.48, 0.74), being obese (OR = 0.70, 95% CI: 0.50, 0.99), hypertensive (OR = 0.67, 95% CI: 0.50, 0.90) or depressed (OR = 0.74, 95% CI: 0.55, 1.00) at baseline were independent predictors of being in a lower remission group. IR and SR were associated with lower HAQ scores over time and lower DAS28 at year 5. Conclusion: Women with higher tender joint count and disability at baseline, depression, obesity and hypertension were less likely to achieve remission. This information could help when stratifying patients for more aggressive therapy
Point to share: Streamlining access services workflow through online collaboration, communication and storage with microsoft sharepoint
No full textThis article explains how the Document Management Team (circulation and interlibrary loan) at the University of Maryland University College (UMUC) implemented Microsoft?s SharePoint product to create a central hub for online collaboration, communication, and storage. Enhancing the Team?s efficiency, organization and cooperation was the primary goal. Although the group is already highly effective, it is always interested in making further improvements. Document Management consists of three technicians and two professionals, and this small staff is currently responsible for providing services to 86,000 students plus faculty and staff at a largely distance education institution. The Team?s previously adopted tools to improve internal operations had been adequate, but not optimal. Also, a long-standing and over-arching concern about the potential loss of some or all of the Document Management knowledgebase existed. These reasons prompted the Team to carefully examine SharePoint as a prospective tool. It was hoped that this early scrutiny would prove beneficial in the long run by avoiding a repeat of earlier technology implementations? shortcomings. The group quickly realized the software would not be a cure-all but felt the prospects were good that it would be useful and dependable. SharePoint was fully implemented with great success due to the Team?s careful consideration of collaboration, communication, and storage needs.A Point to Share: Streamlining Access Services Workflow through Online Collaboration, Communication and Storage with Microsoft SharePoint
Abstract:
This article explains how the Document Management Team (circulation and interlibrary loan) at the University of Maryland University College (UMUC) implemented Microsoft’s SharePoint product to create a central hub for online collaboration, communication, and storage. Enhancing the Team’s efficiency, organization and cooperation was the primary goal. Although the group is already highly effective, it is always interested in making further improvements. Document Management consists of three technicians and two professionals, and this small staff is currently responsible for providing services to 86,000 students plus faculty and staff at a largely distance education institution. The Team’s previously adopted tools to improve internal operations had been adequate, but not optimal. Also, a long-standing and over-arching concern about the potential loss of some or all of the Document Management knowledgebase existed. These reasons prompted the Team to carefully examine SharePoint as a prospective tool. It was hoped that this early scrutiny would prove beneficial in the long run by avoiding a repeat of earlier technology implementations’ shortcomings. The group quickly realized the software would not be a cure-all but felt the prospects were good that it would be useful and dependable. SharePoint was fully implemented with great success due to the Team’s careful consideration of collaboration, communication, and storage needs.
Keywords:
access services, collaboration, communication, academic library, SharePoint, software, storage.
Introduction
Internal communication, workflows, and teamwork can often be greatly improved through the intelligent application of appropriate technologies. However, libraries sometimes ignore or misapply information technology, which often negatively affects staff and patrons. As a predominantly distance education campus serving a global population, University of Maryland University College (UMUC) relies heavily on information technology to meet student, faculty and staff needs. From its modest beginnings in 1947, UMUC has grown to over 86,000 students in more than twenty countries (Office of Institutional Planning, Research and Accountability 2009). Information and Library Services (ILS) at UMUC has depended on savvy staff and technological solutions out of necessity in order to provide library services to UMUC’s students, faculty, and staff worldwide.
History/Background
ILS’ Document Management (DM) Team, which provides circulation and interlibrary loan services, recognized workflow issues beginning in 2005. Over the previous few years, ILS had grown from a handful of staff to more than two dozen librarians and technicians. This rapid growth created lapses in knowledge, documentation, and information sharing behavior as individual responsibilities changed and new services were developed. Originally, the DM Team used five print binders to house training manuals and troubleshooting guides. These were fed by centrally-stored digital documents held on a shared network drive. During the growth period, updates to these binders became ad hoc. No one binder contained the most current or most accurate information. In fact, there was a good chance that one could uncover multiple solutions to one problem. Further complicating this, the shared drive, which was created to hold the most authoritative versions of all documentation, suffered from the staff increases as well. Nearly all information was scattered in personal folders, current documents could not be differentiated from the outdated, and nearly all documentation was poorly labeled. This made it virtually impossible to locate the precise document needed. Furthermore, the network drive supported all of ILS, not just the DM Team, making it more difficult to quickly locate needed documentation and compromising team productivity. Document Management did make a concerted effort to customize a portion of the network drive. New folders specifically for Circulation and ILL were created, and a great deal of relevant documentation was moved into them. Although it became a convenient location to place documents to which the Team needed access, there were no set standards to follow. Staff members were unaware of changes to documents, thereby rendering the information inconsistent and unreliable. At this point, the team decided that an entirely new solution was required.
The DM Team’s first attempt to grow beyond the network-drive-and-binders arrangement involved a Web-based manual. It was believed all staff would be able to access information using a single, easy-to-update online source. However, the site remained unconnected to the Internet due to unresolved security issues, such as password protection and privacy concerns. After one year, the Web concept was determined not to be a complete solution. The Team then developed a wiki as a kind of “band-aid” with the understanding that this was not a robust solution; the wiki was on a test server that was neither supported nor maintained by the University’s IT department. Also, as is true of wikis, it could not support critical spreadsheet and word processing documents.
After taking stock of the previous knowledge management systems, the DM Team realized that three overarching issues permeated their past: disparate communication, collaboration, and storage. This is not to say that the Team was entirely lacking in collaboration or effective communication. Neither does it imply that knowledge storage was completely haphazard. The Team then realized that the key to moving forward successfully was to discover and implement a system that would provide one centralized location, which would eliminate redundancy, knowledge gaps, and encourage information sharing amongst DM staff.
Looking for a Streamlined Solution
As a first step, the Team decided to strategically review DM’s knowledge management needs in light of their roles and duties. Within ILS, the DM Team is one of the front-line service points for patrons. Thus, staff must be accurately informed on any policy and procedure changes in DM and ILS. They also need to be able to quickly access information in order to provide timely and accurate responses to patron inquiries. Service delays and misinformation in this area could potentially cause unacceptable patron inconveniences due to UMUC’s virtual environment.
A primary streamlining tool that emerged as a result of this review was the implementation of a universal organization standard based on Anne Thompson’s Standard Naming Conventions for Electronic Records (2005). This was then used to store documents, which would in turn make locating and saving documents a more efficient and reliable process. After fully assessing the problem, the Team recognized that beyond possessing a common standard, they needed a regularly maintained and centralized knowledgebase.
In 2008, the Team evaluated several products with the intent to provide a more robust solution. One tool DM evaluated was Microsoft SharePoint 2007 (http://sharepoint.microsoft.com/product/Pages/default.aspx), because it was already installed at the University and centrally managed by the University’s IT department. SharePoint is a centralized platform for storage and communication, which combines several Web 2.0 technologies with traditional digital document storage to facilitate a consolidated workflow. The Team was initially impressed with the potential of SharePoint because it integrates many technologies that the Team already used in one central location. The Team had a wiki, a calendaring system, and a document storage system, but these were stand-alone systems. SharePoint puts all of these and more in one integrated application. After evaluating all the pros and cons of SharePoint, the DM Team determined that by implementing SharePoint, they could significantly improve their workflows.
Implementing a New Solution
In the initial implementation phase, the Team began moving documentation from several decentralized channels into SharePoint. During this pilot phase, it became apparent that SharePoint could easily duplicate the problems encountered in previous systems if standards were not developed. Thus, the Team created a best practices document to provide guidelines on naming conventions, document retention, and appropriate applications of the SharePoint tools. This approach ensured that the migrated information was organized logically to enhance the usability of SharePoint’s features, such as the wiki and document library.
Due to some staff turnover, the move to SharePoint began slowly. Once the migration was underway, it became evident that SharePoint offered many streamlining features that were previously not available to the DM Team. Remote accessibility through a VPN (virtual private network) allows staff to log in from home if needed. It has a built-in wiki and document library that can be used as a knowledgebase. Beyond the knowledgebase capabilities, SharePoint also allows for collaboration and communication to all come together in one place. SharePoint’s customizable homepage allows for several notifications and features to be displayed at once as soon as the user logs in (see Figure 1). Automatic email alerts notify staff when changes are made to any SharePoint site section, including documents, the wiki, etc. Staff can choose to receive alerts immediately so they are instantly aware of issues and can deal with them right away. The email alerts make a huge impact on keeping staff current and help build a more collaborative team.
Figure 1: The Document Mangement SharePoint homepage displays a Twitter feed, schedules, etc.
When a document was edited on the shared drive, it was often saved as a different version under a new name. It quickly became difficult to tell which document was the official and current version. The SharePoint version history control in the wiki and document library allows staff to update documents and wiki pages without fear of losing previous versions. Only one version of each document (the most current) is visible, while all previous versions are hidden, but still available. This function simplifies organization, saves staff time, and eliminates confusion by making it easy to identify the correct version. Team members have also been able to save time editing documents by mapping SharePoint as a network drive on their computers. Documents and wiki pages can be saved and edited directly through their PC’s “My Network Places” rather than staff always accessing the SharePoint site (see Figure 2). Figure 2: Once the SharePoint site is mapped, users can access and save items throught their PCs.
Collaboration
Many of SharePoint’s features had the potential to facilitate collaboration from within a centralized hub. The Team held several meetings to discuss how to thoughtfully approach the wiki in SharePoint, which resulted in a project timeline, wiki table of contents, style guide, and reference manual for developing wiki pages. The Team began framing the wiki’s structure by using the relevant content from the previous wiki. Initially, two separate wikis existed in SharePoint: one for circulation processes and another for interlibrary loan (ILL) duties. While the Team worked on developing the structure, it became apparent that two wikis were inefficient and unnecessary, and the Team restructured the content under the categorical umbrella of “Document Management.” Under this approach, categories like “Contacts,” “Passwords,” and “Shipping” contained all information for both circulation and ILL. Once the structure was complete, the three library technicians could begin to share the wiki migration project with the library’s six part-time student workers.
To prepare and train these new contributors, the Team created a Word document that outlined how the wiki pages were to be structured, whether a student or full-time employee could complete the task, and which sections were completed. Once the expectations were clear, the Team introduced the student workers to a special wiki page that explained how to properly create and design individual wiki pages. Additionally, there was a style guide to refer to which allowed the wiki to look cohesive and uniform amidst the several contributing hands that were involved in its creation.
As the Team was navigating the previous Web-based wiki, they realized that pages were text-heavy and impeded staff from easily referencing a particular process or policy. One of the ways the Team solved this problem was to rely on visual examples via screenshots. However, in order to successfully integrate this visual element into the wiki, more careful planning was required. The Team, therefore, created a “Wiki Screenshots” photo library in SharePoint, which functions much like the document library feature but caters more toward supporting certain photo-hosting functions. With 156 screenshots in use in 159 wiki pages, it was essential that the Team established standards. For screenshot files, the Team continued to use Thompson’s conventions. DM decided to structure the photo library directory to mirror the wiki layout (see Figure 5). Figure 5: The “Wiki Screenshots” photo library mirrors the categories of the wiki
Since the screenshot process is a relatively tedious one, the Team instructed all wiki page developers to write the text first, with placeholders indicating where a screenshot needed to be placed in the future. After the text was complete, the page creator was responsible for taking and inserting the corresponding screenshots. To facilitate uniformity, a separate instructional page was created that could be referenced to learn how to create screenshots using three different tools. Due to the diverse resources within the library, several screenshot methods had to be explored and documented. By using standards to supplement SharePoint’s features, staff could easily contribute to the wiki implementation project.
Extending beyond creating standards and documentation, the Team also took advantage of several SharePoint features to integrate fearless collaboration with seamless communication. The Team was able to put their trust in several contributors, since SharePoint allowed them to revert to previous versions of wiki pages in the event a page creator made an error. Any changes a page creator makes are clearly color-coded, so if a Team member needs to make corrections, there is no need to meticulously read through the previous version (see Figure 6). Also, whenever a staff member makes a change to a wiki page, individuals receive an email alert. This feature solves a major issue the Team had with the previous wiki; those referring to the wiki were mistrustful of the content, since they could not necessarily rely on the information’s validity.
Figure 6: An example of the version history feature in a wiki context
Lastly, the Team felt more secure having the wiki on the SharePoint server, which is housed in and supported by the University’s IT department and is backed up daily. The previous wiki was housed on a spare computer in an office instead of on an official server with nightly backups. Also, this computer was not housed within the library nor in IT; therefore DM had little control over it, and it was neither supported nor maintained by IT. The computer was dated and had been known to occasionally crash, making the DM Team nervous about losing data that would be difficult to replicate without any backups.
Communication
One of the quick resolutions to the communication issue was the implementation of various calendars. The SharePoint calendar system is immediately usable due to its intuitiveness, yet serves a powerful function. The Document Management Team set up their calendars to schedule and streamline workflow for the technicians and student workers. The Team created three primary calendars: “Tech Duty Schedule,” “Student Worker Schedule,” and “Staff Leave Schedule.” The three technicians ensure rotation of their responsibilities by creating a monthly schedule of their daily tasks and adding it on the Tech Duty schedule in SharePoint (see Figure 7).
Figure 7: Document Management’s “Tech Duty Schedule.”
The Document Management Team’s Library Associate is responsible for creating the Student Worker Schedule that displays the student workers’ hourly activities. The Library Associate uses this schedule as a quick reference tool when preparing information for student payroll. The entire library staff uses the schedule to identify individual students who can help with certain tasks on a particular day. The student workers refer to their calendar to coordinate their work activities.
Individual Team members are responsible for recording their absence from work on the Staff Leave Schedule. The information recorded on this schedule ranges from a few hours of absence to leave days. The Team members record the reasons for absence, for example, arriving late or leaving early. The leave calendar also keeps record of staff working outside their normally-scheduled hours.
Both library management and Team members find the leave calendar to be a handy reference point when completing timesheets. The fact that every Team member is aware of what the others are doing makes it simple and effective to coordinate work activities. Management also refers to the schedules when following up on tasks and/or when identifying team members who could help with other tasks. Other library departments, like the Reference Team, also rely on the Tech Duty Schedule when routing telephone and email inquiries that need Document Management technicians’ attention. Apart from coordination, the calendar is an important communication tool for team members. Email alerts received when changes are made help staff prepare their work accordingly.
The Document Management Team set up a Discussion Board on their SharePoint site to facilitate and effectively manage communication. Here, team members discuss work-related topics by posting queries, comments and questions and also responding to postings. The Team uses the Discussion Board to build consensus on issues that require group decision-making. Team members can respond to discussions while working on other tasks at their desks, eliminating the need for time-consuming meetings. The Team is now able to permanently store discussions that are quickly referenced and easy to access. The Team also created an Announcements section on SharePoint to post information that is essential for professional development. Team members share information on conference proceedings, any interesting articles that are relevant to library work, as well as information about external library partners.
Storage
In preparation for the transition into SharePoint, the Document Management Team carefully approached the issue of document storage. As was mentioned above, the Team had already reorganized the existing files by using Thompson’s naming conventions. However, DM also carefully assessed the utility of their existing documents: which files were still relevant, and which documents could serve a more effective purpose by being reformatted as a wiki page. A total of 1,167 reports, forms, records, and other documents remained after this weeding process was complete. Fortunately, the actual act of uploading the documents to SharePoint was the simplest part of the process. It only took two part-time student workers two days to complete the project.
The Document Management Team now creates, stores, and shares files using the SharePoint document library. The Team uses this site to store various file types, such as Microsoft Word, PowerPoint and Excel (http://office.microsoft.com/) and Adobe Acrobat (http://www.adobe.com/products/acrobat/). Every team member can open and edit these files. SharePoint’s version history allows team members to track the original document before changes were made (see Figure 8). This is a major advantage over the shared network drive because that did not provide a platform to track changes made to a saved document. The Team finds files quickly and easily when using SharePoint’s search feature. Figure 8: The version history view for SharePoint’s document librari
Facilitating successful implementation of a person-centred intervention to support family carers within palliative care: A qualitative study of the Carer Support Needs Assessment Tool (CSNAT) intervention
No full textBackground: An understanding of how to implement person-centred interventions in palliative and end of life care is lacking, particularly for supporting family carers. To address this gap, we investigated components related to successful implementation of a Carer Support Needs Assessment Tool (CSNAT) intervention, a person-centred process of carer assessment and support, using Promoting Action on Research Implementation in Health Services (PARIHS) as a theoretical framework. This study identifies how the PARIHS component of ‘facilitation’ and its interplay with the components of ‘context’ and ‘evidence’ affect implementation success.Methods: An MRC Framework Phase 4 study to evaluate implementation of the CSNAT intervention at scale, over six months, in 36 UK palliative care services. 38 practitioners acting as internal facilitators in 35/36 services were interviewed. Field notes were collected during teleconference support sessions between the external and internal facilitators. Results: Successful implementation was associated with internal facilitators’ ‘leverage’ including their positioning within services, authority to change practice, and having a team of supportive co-facilitators. Effective facilitation processes included a collaborative approach, ongoing communication, and proactive problem solving to address implementation barriers. Facilitators needed to communicate the evidence and provide legitimacy for changing practice. Contextual constraints on facilitation included having to adjust recording systems to support implementation, organisational changes, a patient-focused culture and lack of managerial support.Conclusions: The CSNAT intervention requires attention to both facilitation processes and conducive organisational structures for successful implementation. These findings are likely to be applicable to any person-centred process of assessment and support within palliative care.<br/
