Managing a Systems Upgrade

1. Managing a Systems Upgrade Or, “Test a little bit of everything” SUNYLA 39th Annual Conference June 13-15, 2007 Marianne Hebert SUNY Potsdam

2. Why Plan for a Systems Upgrade? • Hurray! We STP’d !!! (OOPS, we thought we were done!) • Since STP, we all have had several upgrades: • Hotfixes • Service packs • Oracle upgrades • Version upgrades • Systems upgrades and migrations will never end • We should be prepared and organized

3. Check a “Little Bit of Everything” • What features need to be working as of day one? • Check Data • Check GUI Module Functions and Displays • Check Printed products and Reports • Check Course Reserves Module • Check WebOPAC displays • Check all your Tables That’s a lot of work!

4. Why formalize a plan? • Good planning ensures that most important features will be working on STP Day • Data checking helps staff learn new features with an eye towards new work flow and procedures • On STP Day, system managers may not be available to fix every surprise problem at once (especially if he/she is not a full time systems manager) • Distribute the workload. On smaller campuses system managers wear many hats • System managers are likely super users. He/she can do anything, anytime (which does not take into consideration local policies and procedures within each module or staff permissions)

5. Design a “pretty good” Plan • A pretty good plan does not have to be overly complex or perfect. • Being “pretty organized” ensures that the most important features and data will be operational on day one. • We need to be considerate of OLIS schedules. We do not need everything to be 100% for STP to happen. • Assess your needs. What is the scope of the upgrade and what aspects of the system will be affected? • Create templates that can be used or tweaked for next time. • Be flexible. Schedules are meant to be broken. Plans never go as smoothly as intended.

6. Overview • Develop a Project Timeline • Appoint Teams • Determine Testing Parameters • Design Testing Templates • Check lists of testing activities • Data testing vs. Module functionality • Distribute assignments • System Manager Responsibilities • Prepare for PROD down time • Collaboration is the key to success

7. Devise a Project Timeline • OLIS provides us with campus dates for DEV and PROD, training schedule, etc. • Develop a Local Timeline: • Outline of who does which tasks and when • Populate your timeline with local events, that may impact the project, or may be impacted by the project (e.g. holidays, start of semester, Freshman Orientation, IL classes, etc.) • Timeline items can be TBA until further information is made available

8. Appoint Teams • Make sure the project is endorsed by library administrators • Who has authority to make assignments to staff in each area? • Who has authority to require everyone to be available and participate? • Appoint staff who have work responsibilities within each module • Make sure each team has at least one “leader like” person • Volunteer to meet with each team to help answer questions • Teams don’t have to be super formal or permanent • Use existing personnel structure (i.e. Circulation and Acquisitions)

9. Potsdam’s Team Structure (simplified) Library Director Patron Access Leaders TeamTech Leaders Area Coordinators such as Collection Development, IL Reference, and Automation Automation Coordinator is required to be invited to all Patron Access and TeamTech Meetings

10. Determine Testing Parameters • What aspects of the system is being affected by this upgrade? • Data completeness and accuracy • GUI Module functions and displays • WebOPAC displays, searching and patron features • Indexes • Services, Reports, Printed Products • Course Reserves • Permissions • Test new or changed features

11. Testing Assignment Considerations • How often does a system librarian order a book, check out a loan, catalog a new title? How often does the system librarian make policy or work flow decisions in a department? • Who uses the system day-to-day? Who are the module experts? • Delegate! Encourage module experts to design their own testing assignments • What are the most important features to test? What features are critical on day one? • What features in the past required special configurations and testing? • Make sure everyone understands that they are testing the upgrade, not looking to customize or change existing functions or displays

12. Design Testing Templates & Forms • Provide templates and examples to get teams started • Assignments can be “forms” that testers can complete and hand in when done. • Provide “Problem Reporting Forms” for staff to use during testing and beyond to help them provide complete (rather than sketchy) information

13. Distribute Testing Assignments • Assignments should be manageable • Preferably not more than two hours to complete • Schedule several days for staff to complete their assignments • Compare: DEV to PROD or PROD to DEV • Create Test records on DEV • Bib, holding and item records • Patron records (i.e. fake 09 patron for checking emailing of notices) • Acq order records • Make documentation available to all, encourage staff to use it

14. Devise a Reporting Mechanism • Staff need to know how to report in • Encourage teams to meet and discuss their findings • 20+ written reports to review is time consuming, and may not be necessary • Staff can email coordinator when they are done • Send assignment forms only when problems are detected • Provide Feedback • Acknowledge receipt of reports, emails, etc. • Thank teams for their participation and work • Respond to problems reported in timely manner • Be forthcoming if you can’t figure out what is wrong

15. Side-Benefits of Staff Participation • Training/learning the new features is imbedded in testing process • Staff are empowered to take a lead in suggesting and implementing new work flow and procedures • Area coordinators get a head start on documenting procedural changes • Many different “eyes” see different things. Many staff are more likely to spot problems and issues than a single systems manager

16. System Managers are not IDLE • Back up files on server • Back up locally created templates • Check system tables and parameters • Repackage and distribute GUI clients • Write documentation on how to install new clients and uninstall old clients • Check a “little bit of each module” before assignments are distributed • Maintain communications with OLIS/ITEC and Library Staff • Attend OLIS training sessions

17. System Managers are not IDLE • Design and deliver local training and information sessions • Troubleshoot problems reported by testing • Test PLIF and patron scrubbing • Verify Permissions • Document all server tables and files changes • Configure and test printed products • Write documentation • Continue with other duties as assigned: Reference, Collection Development, etc.

18. Be prepared for PROD down time • Even if ITEC/OLIS says you are live, it may take a few hours to repackage, test and distribute a new client • Be prepared with non-LMS work in the event that down time lasts longer than expected • Have procedures ready for off-line circulation • Provide alternatives to the WebOPAC (e.g. SUNY Union Catalog, ICEPAC, etc.) • Critical staff need to be available for testing (i.e. no vacations on STP day). • Finish outstanding work, run final reports (e.g. cataloging saved locally, acquisition budget reports, send patron notices, etc.) • Stop jobs in job_list (job daemon)

19. Not just for ALEPH • A Team approach to a systems upgrade can be scaled and applied to other library systems (Serials Solutions, ILLiad, Federated Search engines, etc.) • Don’t forget to celebrate your successes! And don’t fret if the upgrade was a little rocky, you’ll have another upgrade soon!

20. Questions? Presentation and examples are available at: http://www2.potsdam.edu/hebertm/upgrade