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