Author: Cynthia Ng

A panel of speakers presented on different aspects of the Evergreen ILS during today’s session. Speakers were:

• Ben Hyman, Managing Director, BC Libraries Cooperative
• Jed Moffitt, Director of Information Technology Services, King County Library System (KCLS)
• Steven Chan, Sitka Project Team
• Matt Carlson, ILS Administrator, King County Library System
• Grace Dunbar, COO, Equinox

The Sitka Perspective

• 54 libraries in BC
• consortia model
• think about the end user first
• multi-faceted selection criteria
• check with your colleagues about your ideas
• every ILS is a work in progress
• got equinox to teach them to fish
• now they teach others to fish

Why Open Source? The Community

• community is a powerful thing and driven by the community
• vibrant, growing community
• who do you want to be involved with?
• plus you can have control

Examples

• centralized policy and way to push out to staff computers
• localize view for search results
• easy to access data and pull data for reports and visuals
• mobile OPAC using an open web services API to add My Account functions (still in development)

Sneak Peak to Evergreen 2.2

• increased flexibility for MARC match set editor
• authority control sets, ability to customize control set

Join Us!

• Evergreen 2013 in Vancouver!

Matt Carlson, ILS Administrator, from King County Library System and Grace Dunbar, COO, from Equinox talked about implementing Evergreen ILS at King County.

Why a New System?

• many reasons, wanted to have more control over tool that everyone was interacting with
• a lot of development
• buy in is hugely important: demos with all branches, took Evergreen on a road show
• might provide new features

Are you ready for [the OSS]?

• and Is [the OSS] ready for you?
• is there a test server with a stable release
• do a gap analysis – software dependent? or workflow dependent?
• are gaps major or minor?
• major gaps = large development projects e.g. missing acquisitions module
• minor gaps = if missing, be creative e.g. receipt not printing exactly the same way
• Have the resources i.e. developers in-house? If not, you may have to outsource (how Equinox got involved)

Requirements

• what do you really need?
• requirements: don’t have staff sit down and say what they want, use
• use cases – no edge cases, focus on what people do
• workflows
• focus on outcomes, not processes
• be specific

Finding your development partner(s)

• engage the community via irc, mailing lists, conference
• evergreen conference is in Vancouver in 2013
• look locally (other OS projects, students, GSoC participants, etc.)
• write an RFI or RFP: if want OSS, rethink how RFI/RFP is written because companies don’t own software, provide service
• request a quote from a vendor
• may need consultant to help

Contract

Be specific in:

• hours estimates
• costs
• ownership of work
• documentation
• interaction with community: make sure that contributions/development work will be accepted, local customizations can be the death of a system
• deliverables
• milestones
• testing/sign

Client Perspective

• challenges
• communication
• scope creep: important to assess input, but cannot just keep adding things
• be realistic about time for testing, clarifications and feedback
• best practices
• update your project plan
• build a team of subject matter experts
• provide real examples, use cases and mockups whenever possible
• never too soon to start thinking about your go live timeline and identify dependencies

Vendor Perspective

• challenges
• multiple clients/projects competing for time
• communication: keeping communication restricted to need to talk to people, while making sure community is kept in , while making sure the feedback can get back up in a meaningful way
• use cases and mockups: drawings can solve a lot of problems
• best practices
• 1-to-1 project managers: one from client side, one from vendor side
• clear, shared objectives (client/vendor/community)
• set priorities: something will get changed or not implemented, so set top 5 things

Test

• create a test manual and use it
• engage staff and patrons in creative solutions
• will need a test server for testing and training
• have an exit strategy

Stay on Target

• still stick to priorities
• functionality is key, outcomes work?
• can always make tweaks later
• must have plan B, no plan survives initial contact!

Training

• managers aren’t necessarily trainers: critical to find the right trainer
• set aside mandatory time: absolutely needed! Something that people will be interacting every day
• structured feedback is critical, so that feedback is meaningful
• have a plan for on-going training: new staff, staff that couldn’t attend, changes that come along that need refresher

Implementation

• implement in phases, whenever possible
• have a fall back position: rollback to previous version, hot spare, offline mode, handwritten checkouts, smoke signals – communicate fall back plan to staff (aware of procedure, etc.), make sure patrons know you’re doing something new
• change is hard: celebrate

Take Aways

• Don’t… freak out
• Do… have fun, this thing you’re doing is really cool!
• Do… have a life outside this project

What’s Working and Not Working Now

• things have gone very well
• implemented many changes, several upgrades
• minimal downtime, had some bumps
• still some features still not there yet