A rose is a rose is a rose…

On Tuesday afternoon me and Rochdale Borough Council go our separate ways. Strangely enough, of all the things I should be thinking about the one I keep coming back to is: "How should I describe myself on Linkedin?"

For a while (at least the four weeks I've promised myself) I'm not going to be in a job and have a job title. "Resting," while dead accurate doesn't really cut it, so I'm having a think. Besides which, I've long since been irritated by the way we all define ourselves by our jobs: when we're introduced to each other with the routine: "And what do you do?" We never boast of the many very splendid things we're capable of: we give a job title or rôle. That's a pity. Even in an employment context this tells so very little of us. So I decided to pick up the "And what do you do?" question and find a different answer.

Casting round amongst family and friends wasn't helpful, though I'll admit to being quite taken with "Provender of finely-wrought artisan drivel" and "Keen amateur idle beggar."

Thinking about my own experiences and the rôles I've assumed or had thrust upon me there are a few consistent strands:

• Identifying and documenting operational processes and procedures
• Helping lines of business find new ways of doing things that add value to the operation
• Helping operations and people accept and adapt to change
• Identifying and delivering ways of measuring continuous service improvement

Bearing this in mind I bounced a lot of descriptive phrases round in my head. Many sounded like the worst kinds of Management Speak. Many were either too vague or too narrow. A lot of them felt too much like I was parking my bike on somebody else's lawn. It boiled down to two in the end. And I'm still havering between them: one feels vague and one feels like I'm trespassing. One is the working assumption of many of the people I've said cheerio to over the past month. The other is the rôle I've taken on repeatedly over the past twenty-seven years and the one I've tended to feel has been the most productive and worthwhile.

I've a few more days for havering. Who knows, it might end up being Keen Amateur Idle Beggar after all!

In the end there is no "In the end"

Projects and events are finite but, unless you're a journeyman project manager or an events manager, they have to live in the context of the organisation or service that they serve. As such they are episodes in a longer serial narrative rather than stand-alone short stories.

There are a number of ways in which these episodes are embedded in the narrative. The past is part of the backdrop and rationale for the activity. The activity itself is — for good or ill — a landmark in the narrative but this is static. The resources employed and delivered are identified in the business case and in the lessons learned process but these only provide the potential for the future narrative, they don't impel it.

So what does get the narrative moving?

"What happens next?"

• What happens next? = continuous service improvement
• What happens next? = business case for future projects
• What happens next? = sustainable service delivery

If your organisational reaction to a project or event is to push it into the drawer marked "History" you're losing the benefit of experience and you have to wonder why on earth you bothered in the first place. Similarly, if it doesn't evoke a "what happens next?" response perhaps you shouldn't have done it in the first place.

Change management: I'm asking you questions because I'm trying to help you get it right

If you were to say to me: "You have to make the following changes to your library management system," my response would be: "Perhaps. But not yet." This isn't me being precious or obstructive; this is me doing my job. There are times when the brown stuff is hitting the fan and you have to do something in a hurry but most of the time it isn't; and even when it is you need to go back and check your workings-out when the fuss has died down.

If you're working in an ITIL environment — and I am — the assumption has to be that you do what the customer asks, so long as it doesn't screw up the integrity of the system that you're managing. So I'd need to ask you a series of questions to make sure that it doesn't. It's important to point out that under ITIL it doesn't matter whether or not the requested change plays Hob with the business; so long as the system remains intact my job would be done. So, for instance, if you were to ask me to set the library loan period to two hours, with a £100 per hour overdue rate I'd be perfectly entitled to raise my eyebrows and ask: "Are you sure?" but the default position is that the change would be made. The customer is always right, within the confines of their rôle and competencies. (I'm not being "neoliberal" here: "customer" in this context has a particular definition.)

That's the principle of the thing. In reality it's a bit more complicated because we want to avoid the dialogue: "It doesn't work." "It does work, it just doesn't do what you wanted it to do." This is a dismal and unproductive conversation which could do serious damage to the working relationship so we make the effort to avoid it. So I'll ask a few more questions:

"What do you want to do?"
It's astonishing how often this question causes a problem. If you don't know what you want to do, how will you know when you've done it? How will you know if the proposed change will address the issue to hand? And if it is the solution to a problem, is it the best solution? You'd be surprised how often the first applied solution to come along becomes accepted as an essential compnent of the process, regardless of the impact on the efficiency or effectiveness of the business. Just because you know how to pick a lock within two minutes just with the aid of a hair pin doesn't mean you'd necessarily want to throw your front door key away.

"Who does this affect and are they OK with it?"
Systems and services don't live in hermetically-sealed bubbles. At least have a think about who's involved and/or do an outline impact analysis on the back of a fag packet. And do make sure that anyone affected by the change knows about it and what it means to them. If the impacts are big and scary enough you may need to sketch out a communication strategy for them.

"What happens if it goes wrong?"
Give the risks a degree of respect. Don't assume nothing could go wrong or they'll come and bite you on the bum. Make sure you know what could happen if it goes wrong; what the impact would be; and that you have a Plan B, a safety net and/or the capacity to go back to where you started from.

"What do you mean by...?"
Make sure you're talking about the same thing with the same meaning. "Better," "Improved" and "Modernise" are words that should be deprecated in this conversation: what do they mean in the working context? For instance, a set of catalogue records may be more complete, with every tag full of data; or may exhibit a purer adherence to current cataloguing standards; or may be Dewey classified to fifteen decimals, but is it actually better? For whom? You may need to sketch out a quality description document for changes to key data or even a quality plan if you're talking about large-scale fundamental changes.

"How will you know if it's worked?"
Because we want to avoid that dark and dismal dialogue, right?

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.

Demonstrating the Return On Investment: Make Do & Mend

I recently read an article about funding pressures on libraries and one comment in particular struck me:

"We may be entering an age of austerity where getting the basics right and on budget will be of greater value than leading the pack on innovation."

This is where many of us have been all along. Which is not to say that we are strangers to innovation. We can't afford to be early adopters of expensive experiments but we can be innovative. Innovation thrives on adversity, after all. It just won't often be revolutionary change (let's be honest, anybody looking to the English public library sector for revolutionary change needs their bumps feeling). It can be, and often is, sustained small incremental changes which aren't remotely sexy but deliver the goods.

When times are hard there is a biting incentive for change and, importantly, it is more difficult to go out and buy a magic wand in the hopes that it will make everything all right in the end. Which is good: one of the stultifying factors to progressive development is the argument that something cannot be done because "we haven't got Item X." This may be a computer, some software, access to the internet, somebody with the job of doing something, a bit of training, or whatever. You've been there, you know what I mean. Of course, the truth is that this something can't be done that way because we haven't got Item X. If that something still needs to be done (and it does no harm to ask the question), there are three options:

1. Get Item X;
2. Find a way of doing the necessary without Item X; or
3. Keep your head down and hope that the whole thing will go away.

It's dispiriting to see how often option three comes into play in the public library sector.

As a matter of principle it's important to know what you've got and what it can do, that's simple resource management. When the brown stuff hits the fan this can be the difference between success and failure. How flexible and adaptable are your systems? Systems begin with and end with a human being.

• How knowledgeable is your workforce? — how do you know?
• How 'sharing' is your organisational culture? — go on, be honest, if only with yourself. Why do libraries, of all things, persist in having 'need to know' cultures?
• How flexible is your workforce? — have a serious think about the next question before you answer this one!
• How flexible is your management?

Maximising the effectiveness and efficiencies of what you've already got isn't a new challenge, but it is one we can no longer duck. Small systemic changes can make big differences. But only if they can be applied systemically and bought into by the organisation and its managers both.

Ten tips for entrepreneurs

Another nugget of gold on The Travelin' Librarian site flagging up a post on the ReadWriteStart channel for first-time entrepreneurs and start-ups. In it, Kevin Rose, Digg's founder, provided ten tips for budding entrepreneurs - you can see the details here. None of it is rocket science, indeed at least a couple are self-evident truths until you take a step back and realise how often they aren't acted on in real life.

I'd argue that they apply significantly to developing a public library service.

1. "Just Build It: You don't need anyone's approval and in fact, you probably won't get it, so don't even try." -- you're working in a bureaucracy; in all probability you're working in one of the more conservative corners of that bureaucracy. Sometimes you've just got to let that genie out of the bottle.
   
2. "Iterate: Build, release and iterate. Make a list of the features you want to create over the next six months and get going" -- definitely!!! Don't imagine you've finished the work. Look at it, review it, ask yourself how it could be made better. If resources allow, do it. If resources don't allow, why did you do it in the first place? Development needs to be sustainable.
   
3. "Hire Your Boss: Make sure you hire people that you would want to work for, who challenge you and you can learn from." -- I think this is the single most challenging idea for an English public library service to take on board. The rigid, top-down hierarchical model of working didn't work all that well in the first place and has become a liability if library services are going to use all their available resources nimbly and effectively.
   
4. "Demand Excellence: Ensure staff are committed to and understand your vision" -- the second sentence is important. Excellence isn't something that is measured after the event, it is something that's signposted to before the event. You demand excellence by delivering vision.
   
5. "Raising Money: The higher your evaluation is, the more equity you have to work with. Beg, borrow and steal. Be creative about finding ways to cut costs." -- more pertinent now than ever! If you can get money, use it. They can't take it off you if you've spent it. Investigate new delivery channels to see if you can do the same or better cheaper (at least one example will be coming up in point 9).
   
6. "Hack the Press" -- make sure that you're getting your message out there. Not just to via "official" channels: chat up anyone and everyone who might be useful.
   
7. "Invest in Advisors" -- not necessarily consultants in the bureaucratic sense. Invest in people who know things that you may find useful. (Including your own staff!) The investment doesn't necessarily have to be in money or stocks: librarians around the world are sharing ideas, advice and news in all sorts of different forums, make sure you're tapping into them. And then make sure that you're also using the same model to tap into networks outside the library arena (be creative about it) - you will be amazed at just how often the answer to a problem is a devolved community knowledgebase with meeting and event management facilities and free internet access. Join in, be positive, be useful; the effort you invest this way can be paid back many times over later on.
   
8. "Connect With the Community" -- any public library service that isn't doing that already should be boarded up.
   
9. "Leverage Your User Base to Spread the Word" -- talk to your customers; tell them what you're doing; then get your customers to be your marketing tool. Time was, we only had word of mouth to work with (but when it works it works very well indeed). Now there are all sorts of new opportunities, many of which are free. Which ties in nicely with point 5. If it costs £x to print out a couple of hundred leaflets which may or may not be actually read could you not use the money one something more concrete that you could tell people about buckshee on Twitter, Facebook, etc.?
   
10. "Analyze Your Traffic: Pay attention to how people are using your site, and then learn and evolve" -- not just your web traffic (though that's important). How does/doesn't your online audience traffic relate to your library's visitors?

I know which ones I have and haven't been doing (and I'm not going to say here which they are!)

Reflective journal processes

There's a nice diagram of the Reflective Diary/Journal Process on the Businessballs site. I'm forever telling people that "experience isn't what happens to you, it's what you do with it" and this diagram provides a useful template for following this through. One of the more dispiriting truths is that too many people's experience of training or development activities stop at stage two of this process: "What did you think of the training?" "Very good/bad" and back to business as usual.

And how many pieces of work do we get involved in that completely ignore the question: "How will I measure and know that I've succeeded in this?" I know I'm a bore about needing to know the success factors but I do feel this is absolutely important. If you don't know how to tell when you're successful you can only know how to fail.

Because it's that good: 10 Exciting Ways To Waste Your Training Dollars

Thanks, yet again, to Marianne Lenox for flagging this up. It's an excellent summary of common conventional mistakes that compromise the effectiveness of training activities.

Library Management Systems: Development directions

I'd entirely forgotten I'd written this. The library management system market is in a state of flux at the moment (the moment being the best part of a decade now!) and one of the questions we're all hoping will go away is: "why do you need a library management system in the first place?" Other council services have customer databases and keep track of customer transactions. And/or have resource management systems that include acquisition, distribution and use to end of life. Why are libraries different?

Well, we are different in many ways. We have international database standards for our catalogues so that we don't have the pain that many public sector document management systems are going to have over the next ten years. Most of our base data can be easily mapped from one system to another, from one library service to another so we can do collaborative work like regional loans and consortium working. (An argument that will be easier to pursue when library management systems deliver their promises on interoperability with non-library systems.)

But are we different enough to satisfy an entirely understandable corporate wish for a nice, simple one-stop solution? That's entirely down to the library service's specification of functional requirements (the UK Core Specification being just a fraction of what a modern library service needs) and the business case supporting that functional specification. If it turns out that a one-stop solution delivers to that specification, excellent, everyone's a winner. If it doesn't and some other solution does then some hard choices need to be made.

I don't know what, if any, input I'll be allowed to have on our choice of a new library management system; I suspect very little. I will keep making the case for a functional specification and a business case, though. There's no point in telling somebody to paint your front door any old colour and then spending a decade complaining that it was painted red.