Lessons Learned

It being the end of year and it being a time for reflection and review and that I thought I'd put down a few thoughts on a process that's sadly neglected by many library projects: Lessons Learned.

In my experience, too often the lesson learned is; "We seem to have managed that in the end, so it's OK to fly by the seats of our pants next time, too." This is an opportunity missed: experience is not what happens to you, it's what you do with it. If what you do with it is nothing then the experience is lost. So it's important to build the Lessons Learned process into any project.

The purpose of a Lessons Learned Document is to capture the experience accrued by the project in a formal document for use on similar future projects, including:

• Problems that occurred, how they were handled and how they may be avoided in the future.
• What went well with the project and why, so that other project managers may capitalize on this experience.

It is not the purpose of a Lessons Learned Document to apportion praise or blame.

This document should be used to support the continuous service improvement processes within the organisation.


Just to put my money where my mouth is, these are the recommendations from the lessons learned process from our project migrating from Dynix to Spydus:

1. A specification of operational functions is essential for the Statement of User Requirements. The more explicitly practical and measurable the more robust the selection process in procurement.
• Actively encourage staff input in the specification process to get ideas for the specification and buy-in for the project.
• Actively investigate other solutions and technologies so that you aren’t just doing a like-for-like replacement and limiting yourself to established business delivery models.


2. Before a procurement process that you own begins you need the following:
• What is the process? What are the critical paths?
• Who are the stakeholders — customer/ project/ procurement/ legal/ partners/ whoever
• Who is/are responsible for doing each step of the process?
• What information/ documentation is required for each step?
• When do you know each step has been completed?
• Has this all been agreed by all the stakeholders?


3. Agree a Project Initiation Document and work from it.
   • Make sure that you know who is doing what and in what order.
   • Make sure you know what isn’t to be done.


4. Work to the project:
   • Make sure that you’ve agreed who is doing what and in what order.
   • Make sure everyone knows what isn’t to be done.
   • Have clear lines of communication.
   • Get together regularly to review progress and, where necessary, revise action plans.
   • Allow at least three weeks between Subject Expert Training and Train the Trainers to allow options to be explored, modelled and tested for use (particularly with new functionality) adequately.
   • Train the Trainers is an opportunity to test the commissioning to date. Allow at least a week between Train the Trainers and the first batch of Cascade Training to test the safety of any changes.
   • Have cut-off points for commissioning changes:
     • No changes to codes and data structures after data migration.
     • Severely limit the number of system parameter changes after Train the Trainers.
     • Admit no changes to any part of the system (except in emergency) on the day you go live.

Make sure that the technical infrastructure requirements are included in the Statement of User Requirements and agreed with the supplier before commencing the installation.

The OPAC is an integral part of the system, not an add-on, so it needs to be treated as part of the whole.

• The training for the management of the OPAC needs to be included in the Subject Expert programme.
• Make sure that all the people having input to the commissioning of the OPAC understand its purpose and function.

Spending time cleaning up the data using familiar tools in the system you know saves a considerable amount of time, effort and problems with both the data migration and the operation of the new LMS.

Prepare for the MARC21 environment by making sure the existing catalogue data maps at least adequately and by making sure that there is sufficient MARC21 expertise within the organisation to verify that it does.

It’s useful and important to see how a reference site uses a process.

• It’s important to make sure that the ‘right’ experience of a site visit is realized: be clear about what the experience needs to be beforehand and proactively manage distractions.

Any library service that is not already used to MARC cataloguing should make sure well before the Subject Expert Training that:

• There is sufficient expertise for the catalogue data mapping process.
• Staff who will be using catalogue processes (including acquisition via EDI) need to understand at least the basics of the format.