FEATURE
Mapping the LSP Migration Project: An Implementation Blueprint
by Janetta Waterhouse
| This implementation blueprint includes the most important aspects of communication, scope, and training so that you can plan for a successful migration. |
The term “library services platform” (LSP) was coined in 2011 by Marshall Breeding to describe a new set of products developed to take a different approach to library resource management. Such products, according to Breeding, address “the fundamental changes that libraries have experienced over the course of the last decade or so toward more engagement with electronic and digital content” (2011). Some LSP options include Alma and WorldShare Management Services (WMS), which are in use in more than 1,000 libraries (Breeding 2017), and many more libraries are preparing to make the move from their ILS of the ’90s to the newer platform architecture. If your library is considering a migration, it’s best to have a project plan. In this article, I will suggest how you might develop a blueprint for proceeding and succeeding.
Project Management Options
There are many approaches to project management. In my experience, libraries rarely have the types of projects that fit a formal waterfall project-management methodology. That methodology refers to completing all of the planning prior to commencing the project, while agile project management refers to a methodology that uses iterative development with incremental delivery. For many of the innovative projects undertaken by libraries, developing iteratively may be preferable because gaining stakeholder feedback throughout the process will lead to a better service or product. Indeed, flexibility is critical for all projects. In formal project management, “rolling wave planning” is the term for starting with high-level plans, and detailed planning happens as the project progresses (Project Management Institute 2013). Given the size, cost, and impact of an ILS to LSP migration, not to mention the very likely tightly scheduled interactions with a third-party vendor—the exception being libraries that are moving to an open source solution independently—project planning and preparation are crucial to a successful implementation.
If you’ve ever heard the expression “Good, fast, cheap. Pick two,” you’ve been exposed to what is referred to as the triple constraint: scope, time, and cost. There are certainly other aspects of project management that are important, such as quality, risk, and stakeholder management. Given that all of the major—and perhaps many of the minor—LSP vendors have been through multiple ILS to LSP migrations with other libraries, the time and cost are likely to be fairly fixed. That leaves scope, which in this case is considerable, and two other aspects that are key to a successful migration project: communication and training. This implementation blueprint includes the most important aspects of communication, scope, and training so that you can plan for a successful migration.
Note: This blueprint starts at the point following procurement when a product has been selected and a contract signed. Procurement processes are often dictated by the organization, but keep in mind that a library with an existing contract may be able to extend that contract, especially for essential services. A conversation with the institution’s procurement department should cover all options. For example, if a library has a contract with one vendor for bibliographic records and resource sharing, a contract with a second company for an ILS, and a third company for a discovery system, then it’s possible that it could choose an LSP vendor from one of those three by extending an existing contract. But beware: Even if that is a possibility, the library’s culture should dictate the thoroughness of the selection process. For smaller, well-led organizations in which most staffers are interested in one particular system over others for valid reasons, extending a contract will streamline and expedite the contract process. Conversely, for larger organizations—especially with a paucity of capable leadership that can engage key stakeholders—circumventing the RFP process is a surefire way to add additional stress to an already complex project. Stakeholder management is key to determining the best approach for procurement.
Communication
Communication is the single most important aspect of a project of this size and scope and should be addressed first. The Project Management Institute (PMI) classifies communication methods as interactive, push, and pull (Project Management Institute 2013). Interactive communication, such as virtual and in-person meetings or phone calls, is considered the “most efficient way to ensure a common understanding by all participants on specified topics” (Project Management Institute 2013). However, an LSP migration involves too many people and too many details to rely only on meetings. Push communication is a way to send information to people, and the most common form is an email list—but it can include blogs and marketing materials (Project Management Institute 2013). Pull communication is “used for very large volumes of information, or for very large audiences, and requires the recipients to access the communication content at their own discretion,” and in libraries often takes the form of a staff intranet (Project Management Institute 2013). All three communication methods will be essential for project success and should be part of the blueprint prior to project launch and continue past the go-live date as local issues are worked out.
Whatever tools are chosen for each method, keep in mind that these are formal communication channels, and at least one should continue on after the project ends and the new LSP becomes the daily tool for staffers. There will also be informal communication channels that library leadership should keep a close eye on. Picking up dissatisfaction early will help with a smooth transition. Preventing the spread of rumors and false information will keep people on track and motivated. Additionally, getting the right questions and concerns to the vendor sooner rather than later can help clear up any concerns with data migration.
Scope
Even before a contract is signed, seeing a map of the project’s scope will provide a starting point for the library’s change agents who are eager to get started and may provide comfort for those who are anxious. Unfortunately, many libraries don’t understand the scope of this type of project until it’s underway and find themselves insufficiently prepared. While it’s impossible to plan for every contingency, having an implementation blueprint to map the migration project will help everyone prepare for the work that lies ahead. As far as the scope of an LSP migration, there are two primary aspects, each with many considerations for libraries: data migration and system configuration.
Data Migration
The primary data-migration consideration for libraries’ first ILS implementations was bibliographic data in MARC format. Now, however, data that is essential to libraries extends much further than MARC records. Data migration now includes multiple data types, and there are several questions a library should work through for each type of data, preferably prior to contract signing. The questions that should be asked for each data type are as follows:
- Where is the data coming from—the ILS or some other source?
- What data will go, and what data isn’t needed or wanted in the new system?
- What data must be cleaned up prior to migration, and what cleanup projects will be needed after migration? (Keep in mind that the migration itself is likely to raise previously unforeseen data issues.)
- When will the vendor capture the final data? What is the time lapse before going live? And will there be a gap load? Or will manual data entry to catch up be necessary?
- How will data be verified in the new system? After the vendor loads data, each library will need to review it before signing off on the migration, so it’s a good idea to have some bad examples ready to look up for comparison to what’s in the ILS.
Not all data types can be migrated by all vendors, and regardless of whether the data is migrated or not, it’s a good idea to archive reports from the legacy system. The types of data that may be part of the data-migration scope include the following:
- Bibliographic, holdings, and item data are still a major consideration for an LSP migration due to the complexity of the MARC and MARC Format for Holdings Data (MFHD) formats. The data questions listed should all be reviewed carefully for each data type but especially for bibliographic data. For instance, will MARC records from the ILS be used in the new system? Or will master records from WorldCat with the institution’s holdings be used? If the latter, how long has it been since a reclamation project?
It may be tempting to want to clean up all bibliographic data prior to migration, but staff time is a limiting factor, and the administration will need to set priorities. It’s worth noting that an ILS includes additional information that may not be possible to migrate. One example is whether a record is suppressed or not. Item status is not part of the MARC format, and it’s not unusual for all records that have migrated to appear as available.
- Knowledgebase (KB) data tends to be confusing for many librarians and staffers. Even though OpenURL resolvers and journals A–Z lists originated separately (Wilson 2016)—each using a KB to note full-text holdings for a library—it’s safe to assume synonymity among KB, a journals A–Z list, and resolver terminology. Another cause for confusion is that many libraries have loaded MARC records for electronic resources into their ILS, so when librarians and staff members talk about access to electronic resources, they may be thinking of these records instead of the links to the full text that appear in discovery system, resolver, and journals A–Z search results.
Suffice it to say that most libraries would not want to fully populate a new knowledgebase resolver (KR) from scratch if there’s any alternative to migrate some or all of the data. Vendors may be able to use a data extract of one KR, in UKSG and NISO’s KBART format (NISO), in order to select collections and titles in the new KR. Given the importance of electronic resources, however, a library should expect to review the newly populated KR to add or remove resources as needed.
- Not all LSPs can migrate acquisitions data, and even those that do many not be able to migrate all fields. The LSP vendor will know what’s possible, but even if a library can migrate acquisitions data, many current budgets, ledgers, and/or fund codes were established more than a decade ago, when closer to 100% of a library’s budget was spent on print materials. The complex, hierarchical fund code structure in place may no longer be suitable for a library’s collections reporting needs, and it’s worth considering updating the fund structure as part of this larger project.
- Patron data can be pulled from the ILS, although patrons from before a certain date should not be migrated, or a library could choose to load patrons from the organization’s directory using the standard patron load process.
- Circulation data can include items that are checked out, items on hold, and circulation statistics, such as last checkout date, number of checkouts, number of soft loans (used in the library but not checked out), or last inventory date. Libraries will need to know what’s in the current system in order to know what can migrate.
- Electronic resource data includes administrative data, licenses, usage statistics, and notes. Even though a hallmark of an LSP is that it was designed for electronic resources instead of print, some vendors sell the electronic resource management (ERM) module of an LSP product as a separate component at an additional cost. Libraries can still function without the module and the data that populates it. However, to realize the full power of an LSP over its legacy ILS, ERM data and functionality should be included.
Note: This will probably need to be a separate project, as many libraries don’t already have this data in an ERM system to migrate, and even if they did, not all vendors can migrate it—meaning it would need to be manually added. At least one vendor has the ability to migrate at least some ERM data, so it’s possible that some libraries will have all possible data, including electronic resource data, on going live. For the others, however, an LSP go-live date is not likely to be delayed while this data is entered—and it’s often a tremendous amount of data. Populating the ERM module, or ERM system, if a separate system is being used, is the long tail of an LSP migration: It continues past going live, possibly longer than a year, until it eventually becomes part of the normal ERM workflow.
- Digital collections aren’t really a separate type of data, but it’s worth mapping how digital collections are made available in the current system and what options are available in the new system. For example, a library may have brief records only in the OPAC, with no master records in WorldCat. Migration might include creating master records or deleting the brief records and having the discovery system harvest the data directly from a repository. Any decisions made may have implications with other data types and should be taken into consideration early in the data-migration process.
System Configuration
The second major aspect of the implementation blueprint scope is system configuration. The new discovery system and LSP will have to be configured in a variety of ways prior to rollout and regular use by the public and staff. The types of configuration needed will vary, but should include the following:
- Discovery—The two main components of a discovery system (the central index and user interface) will need to be customized prior to going live. The vendor may assist with some portion of this and is likely to provide reasonable documentation and training for this work.
- Authentication—Most LSPs should be able to use third-party authentication with an organization’s existing system, such as LDAP (Lightweight Directory Access Protocol), Shibboleth, or CAS.
- Patron loads—The LSP will undoubtedly require a different file format for libraries that have been loading patrons automatically, and updated code and testing will be needed.
- Staff roles and permissions—Identifying the functionality of each staff member and assigning the correct roles and permissions will have to be done before testing for going live.
- Administrative data—The standard library data used for materials acquisitions, cataloging, and circulation will need to be entered and administered. Some of this information may be created as part of the data-migration process, but all should be verified. This includes library hours, shelving locations, patron types, fiscal years, and circulation policies. A library’s circulation policies in particular may be quite dated and complex. Reviewing the existing policies and verifying that the library wants to continue with them well in advance of system configuration is advisable.
- KR—If a library allows direct searching of its journals A–Z list, this may need to be customized. Moreover, unless a library has already configured the KR for the new LSP and has been using it as its OpenURL resolver—for example, a library using OCLC’s WorldCat Knowledge Base and migrating to WMS—it will have to manage a subproject to migrate OpenURL resolvers. This is, unfortunately, a non-trivial project, depending on the size of the library and the number of resources. Library staffers will need to update the URL for the resolver with every publisher the library has content from. Timing can be tricky with a resolver migration, because dozens or even hundreds of publishers will have to be contacted, but not until the new KR is sufficiently populated to accurately link to resources. Finally, when the new KR is ready, libraries will want to update Google harvesting settings.
- Website and research guides—Search boxes and widgets in use will have to be updated to search the new system. The longer a library has had these indirect searches available, the more widespread they may be. It’s a good idea to have reference and instruction librarians keep an eye out to make note of all the places that will need to be updated.
Training
The formal project management category that covers training is human resource management, which includes other processes, such as acquiring and managing the project team. Training is often fraught with the most tension in an LSP migration, because many library employees have been doing their jobs for years and feel they have a certain level of expertise that is being taken from them. Another training challenge is timing: Beginning functional training too soon will make it hard for staff members to retain the skills, and the LSP will generally have new releases every few weeks—meaning the system may change before going live, but engaging staffers during the project is critical.
I suggest starting with skills needed for the migration and designing development plans with timelines for each individual or team. A good starting point is change management itself. Understanding the dimensions of change may be a good way to ease what is likely to be a stressful transition for at least a few staffers. As far as technical skills go, there may be additional reporting and data extraction, assessment, and cleanup skills to develop for specific staff members working on that aspect of the migration. Many, if not all, workflows are likely to be different in the new system, making this a good time to optimize them. Libraries could identify someone to facilitate workflow analysis, which may require research or training. It’s also important not to neglect behavioral or interpersonal skill development, especially since an implementation of this size can create conflict in the organization.
It’s necessary not to underestimate the difficulty in transitioning away from an OPAC. Even libraries that have previously implemented a discovery system have likely continued to have an OPAC available to staffers and patrons. With the move to an LSP, the OPAC goes away, and with it, the comfort level of staff members to replicate user search results. Ideally, everyone will become as comfortable with the discovery system as he or she was with the OPAC. The problem is that discovery systems are more complex than the OPAC, and many library staffers who have used a discovery system for years don’t really understand how the various pieces of data are integrated, discovered, and linked. For this reason, I recommend starting with a conceptual overview of discovery systems (Hoeppner 2012) and comparisons between KRs (Wilson 2016) versus central indexes and KR data (NISO) versus bibliographic data. These concepts will form a foundation on which to build the technical skills related to the new system, including local discovery system configuration, the functional modules of the LSP, and the sources and methods for updating data in the new system.
The planning and deployment of training is a good opportunity to engage instruction and reference librarians who may otherwise be on the sidelines for a library system migration. Most libraries will have in-house expertise for developing instructional materials, methods, and delivery. Along the way, these likely public-facing librarians and staff members can begin to learn the new system.
Summary
Beginning with and encouraging effective project communication, mapping the two main areas of project scope—data migration and system configuration—and planning carefully for a wide range of training needs, libraries will be able to make the move to their new library system as effectively as possible.
|
