The Normalisation of Deviance: How pushing your luck becomes the new normal

There was a useful thread on Twitter about the normalisation of deviance, the idea that if you get away with something outside the accepted norm and gain advantage by doing so then it becomes the new norm. In this case decisions made to cut corners or push technology beyond its specified limits eventually led to disaster but this needn't always be the case: it could be that similar decisions in a difference context might have lead to more streamlined processes or an easier life. How can we predict the outcome beforehand? Very often we can't, but we can — and must — manage the associated risks.

Perfection paralysis is always a potential barrier to change. "Good enough" is usually good enough but realistically there will be times when we have to cut a corner or two to get to "Good enough for now" within the available time and resources. It's as well to know the difference.

• "Good enough" — Job done to the specified requirements. Leave well alone and don't break anything unless the changes are part of a managed transition process.

• "Good enough for now" — Job done near enough to the specified requirements but the job needs to be reviewed to make sure it really is good enough and that the cut corners don't have any nasty unintended consequences. Then do a lessons learned to find out if there are any unanticipated benefits, remembering to look at both the processes and the outcomes.

"Good enough for now" is your deviation from the norm. Even if everything turns out to be hunky dory you'll want to amber list this in your risk register to flag up that the next change process needs to factor in the impacts you've identified during the lessons learned.

Learning from experience

When you're doing any sort of serious developmental work, whether it's solving a problem or exploiting a new opportunity, you have to start by defining your preferred outcome then look at all the possible options for getting you there. One of the things that constantly dismayed me when working in public libraries was just how limited "all the possible" usually was, and that these limitations were often imposed as a matter of principle rather than practice. Often summed up with a look of complacent contentment and the mantra: "Ah well, you see, they don't work the same as libraries." I still bump into this thinking quite regularly on the lists and social media, often as a dogmatic statement along the lines of "Libraries have got nothing to learn from…" This is, of course, the veriest nonsense: libraries can learn a great deal from other business operations, if only the reasons why adopting a particular policy or process would be a bad idea in a public library context (and that aren't "Ah well, you see, they don't work the same as libraries.")

The other reason why it is nonsense is that although a business operation may be very different to yours some of the operational functionality requirements may be very similar, or the same. There's no particular philosophical or ethical difference between opening the public doors to a library first thing in the morning and opening the public doors of a shop, for instance.

The exciting thing about not imposing any constraints on where ideas can come from is that you can often find alternatives to the organisation's "default setting" that are cheaper and more effective to apply.

The responsibilities in my last job included a transport management system called Tranman. Very generally speaking it was used to manage the council's fleet of vehicles and the jobs done in the vehicle workshop. Some of the jobs done in the workshop were part of the routine maintenance work included in the service level agreements with the council departments using the vehicles. A lot weren't: repairs necessitated by accidents or driver abuse were chargeable extras and the workshop also did a lot of private repair work, services and MOTs as part of the operation's income generation. Extremely different to the business operation and purpose of the public libraries I was also supporting.

They had a problem. A lot of the jobs were taking ages to complete and invoice on the system because they were missing information about the parts that were issued to them. Even worse, some jobs had been completed and invoiced without including the rechargeable costs of the parts. This was playing hob with their cash flow and making the accountants cross. So we had a look at it and basically the situation was:

• There was a manual process involving somebody trying to catch up with a pile of paperwork at the end of the month
• There was a technical solution which could automate the stock issue but wasn't being used

What was needed was for the parts to be issued to the jobs in as close to real time as possible and that wasn't going to be done manually from the paperwork.

We had a long, hard look at the technical solution. None of us were big fans. It was hard work to get set up and running and, frankly, was over-engineered for its purpose. On paper it looked great:

• A piece of software on the stores manager's PC generated barcoded labels for each part, the barcode including the appropriate part number and bin, together with a human-readable description.
• The parts bins were labelled up accordingly.
• When a part was to be issued to a job the store man entered the job number into a PDA, read the appropriate barcode and entered the number of items being issued.
• The PDA was then plugged into a console attached to the store manager's PC and the data uploaded into Tranman.

In reality it wasn't so hot:

• The barcoded labels soon got scruffy and unusable.
• We could make the barcodes on the labels as big as we wanted but the descriptive text was always tiny and difficult to read, especially in some of the darker corners of the store room.
• The keys on the PDA were very small (6mm across), which was difficult enough for me with my never-done-a-stroke-of-hard-labour-in-his-life delicate fingers and not a lot of fun for workers who'd spent years bashing their finger ends on bits of metal on cold Winter's days. The incidence of input error was high.
• Uploading the data was a bit hit and miss at first: it took quite a while for us to iron out the problems and making sure the solutions were properly packaged into the virtual application. (I for one was praying nothing happened to that PC as I wasn't confident we wouldn't have at least a few of these problems again with a new deployment of the software.)
• It wasn't easy to see where and when something went wrong. The lack of transparency meant that you couldn't do any quality control to make sure that the right parts actually were being issued to the right job.

Something had to be done. 

We looked at various somethings: we spent far too long trying to sort out better barcode labels; then we had a fruitless quest for a more user-friendly PDA that could do the job. Over the next few months, in between a pile of other pieces of work we were doing with this system, we tweaked this process as best we could but in the end it felt more like we were working through levels in an arcade game rather than getting anywhere with improving the process and addressing the cash flow problem. By this stage I was thoroughly fed up and went and had a sulk in my tent. On reflection it was apparent that all we had been doing was following the same ploughed rut over and over again. 

We'd let our problem-solving be dictated by the "solution" rather than either the problem or the desired outcome.

So I looked again. And wondered why the issuing of parts to a job in a vehicle workshop was very much different to the issuing of library books to a borrower…

The solution I came up with was cheap, not especially elegant but did the job and could be seen to do the job. There were two elements:

• A standard barcode reader, same as you'd see in a shop or library
• A folder containing sheets of labels including all the information needing to be entered into the job record:
• The description of the part in a large, readable font
• The part number as a barcode (using the "3 of 9" font)
• The bin number as a barcode
• The store location as a barcode

The process was:

• The request comes in for the part for the job
• The stores man gets the part then opens the job record in Tranman
• The part number, bin number and location are input by reading the barcodes from the appropriate sheet
• The only manual input is the number of parts
• The parts are issued to the workshop

For out-of-hours working the process was:

• The request for the part is recorded on a paper job sheet
• The fitter working on the job gets the part
• Next working day the stores man issues the part in Tranman as above

Getting a working test sheet turned out to be a bit of a problem because initially I was doing it in MS Word and the formatting it imposed was disabling the begin and end codes of the barcode (an asterisk *). Jacking it in and doing the job in Wordpad gave us some test sheets we could use to demonstrate proof of concept. I used Crystal Reports for the final print out of all the parts.

Sadly, this is as far as I got with it by the time I was leaving. We'd checked that each step should work as expected but we'd not given the process much hammer and inevitably there'd be some snagging to do. One thing I'd have liked to have done, given the time, would be to modify the Crystal Report so that the first few pages were limited to the high-volume items, to save the stores men having to routinely wade through so many pages.

So that's how I applied a bit of standard public library functionality to a problem in a completely other environment.

So what are the takeaways from this?

• Don't mistake differences in business operation with differences in operational functionality. In this case, issuing an item in real time is issuing an item in real time.

• If your problem-solving energies are being devoted to the solution perhaps you've got the wrong solution.

• To solve a problem you have to know what problem you're solving and the outcome you desire of the solution.

Specification: the importance of purpose

If I were to ask you what you could do with a stick like as not you'd quickly come up with half a dozen entirely practicable ideas. You could use it to prod cans off supermarket shelves or prop up a flower stem, You could poke a wasps' nest or hit a golf ball across the lawn. You could stir concrete or poke holes in doughnuts with it. And so on until bedtime.

But what if I asked you what a stick could do? You'd probably need to think a bit about that. Especially if I asked what a stick could do that wasn't really what you could do with a stick. It could stay where it was or it could rot or, if it were fresh off the tree, it might take root and grow. There aren't many other options as spring immediately to mind.

Like any technology, the usefulness or not of the stick is dependent on the purpose to which it is actually applied. This is why whenever we're looking at any new equipment or application the "What would you want to do with it?" question is infinitely more important than "What does it do?" It may be capable of doing very many splendid things but until somebody actually puts it to work these are only a potential usefulness. And very often the use a technology is put to isn't the one intended by the person who built it (screwdrivers weren't designed for levering the lids off tins of paint, they just happen to be very useful for doing so).

When you're building a specification or statement of user requirements you need to be mindful of the difference between describing what something will be and describing what something will do. Specifications too often describe — and prescribe — processes without describing their preferred outcomes. Which is perverse because if the object isn't to specify a physical object or deploy some sort of brand you want as much freedom of interpretation as possible. In design thinking terms you're defining the problem not building the prototype.

The purpose of specification is to define the problem to be solved. If you use the specification to define the prototype then you could be missing out on better potential solutions. Like Henry Ford might or might not have said: "If I had asked people what they wanted, they would have said faster horses."

Public library technology requirements

Ken Chad's put together a schematic derived from the initial discussions that have been going on about a new generation of core specification(s) for library management systems. You can see a copy here. The more I think about this the more I think that what we really need is a standard methodology rather than a standard specification. When I get a bit of space and time I need to revisit this thinking.

LMS development

I've been invited onto the group Ken Chad's pulling together to have a look at what comes after the UK Core Specification for library management systems, which is a flattering and interesting opportunity to try and put something positive into the library pot. At Rochdale we've no plans to change our LMS any time very soon so you may wondering why I'm bothering to get involved and potentially get some additional homework. The answer is: enlightened self-interest. The suppliers I'm working with have finite development and support resources and I would prefer to have them working on something that would add value for us looking forward rather than addressing scores of variations on the theme of "requirements that libraries have identified as missing from UKCS." 

I'm not going to tell any tales out of school but the first telephone conference meeting this morning felt really positive. The more so given the size, scope and — let's be honest — vagueness of the job in hand. So that bodes well.

If all that comes out of the work of this group is that libraries and suppliers aren't diluting scarce resources with redundant requirement iterations then that would be no bad thing. More than that, it's been interesting to see how quickly the idea of replacing or revising the UK Core Specification for library systems has evolved over the past few months from a change of specification into a change of methodology and this seems to be a group that could pick up on that, with the potential for some very useful medium-term benefits.

Core specification or core specifications?

Thinking about the prospect of a revision of the UK Core Specification, I got to wondering whether or not it should be a single, monolithic beast.While it's useful to have something to act as a basis for a formal Statement Of User Requirements at the start of a procurement process perhaps its singularity could cause a problem as much as a solution.

When I did the lessons learned with my manager after Rochdale procured Spydus we both thought that we'd got the best of the available options but it would have been good to have been able to have some of the nice bits of functionality of some of the other systems on top of that. Of course, we were procuring a single library management and the idea of a best-of-breed pick'n'mix of bits of systems wasn't — and probably still isn't — a practical option for us. But it's an appealing idea and it would be a shame if a revised UKCS closed the door on it unnecessarily.

Needless to say, there are pitfalls as well as advantages…

In favour of a modular UKCS:

• Possibility of building "best-of-breed" hybrid systems
• Potential for increased diversity in the market place
• Contracts could be awarded to more than one supplier
• Newcomers to the market could concentrate on doing one thing well rather than having to make a big commitment investing in developing a universal solution

Problems with a modular UKCS:

• Which modules? One of the problems with the existing UKCS is that it presupposes the shape of the solution — there'll be a an acquisitions module, a serials module, etc. etc.
• One of the things we tried to so when we were putting together our requirements was to get people to think about functional outcomes and outputs rather than bolt-ons or "modernisations" of the machinery they knew. I'd like to imagine something similar for a revised UKCS but that's easier said than done.
• How would/could you specify the interaction between modular components?
• Procurement processes hate shades of grey. A complex procurement — a bit of this, a bit of that — would be bloody hard work (a simple procurement like ours was a hard slog).
• It would be more work for the suppliers — instead of a simple first-past-the-post competition for each organisation's procurement they'd be entering into a series of Nash equilibria.
• It would be hard work technically:
• How would the interfaces between system components be set up and managed? And who by? We have fun enough with SIP2 and EDI, enriched content and interfaces with third-party services and systems!
• If the main part of the system is provided as Software as a Service, how would the rest of the functionality work with it?
• What would be the maintenance and support arrangements? Could Service Level Agreements be constructed in such a way as to encourage collaborative working between competing suppliers?

The problems may not be insurmountable. The benefits may not be realisable. Either way, I think it's important that the possibilities should be explored.

Just one big serendipity engine(there, I said it!)

Excellent day out at "Liver and Mash," the latest Mashed Libraries event, despite a stinking cold.

For the first half hour I wondered to myself: "what have you been and gone and done?" and I expect there will be photographs of me on the web looking bewildered. But the venue was cosy, the people were nice and we were greeted with bacon butties before we had our coats off. And the ideas suddenly started to click.

The morning session was extremely quick-fire, which meant that the speakers had to rattle their way through a bewildering amount of content in very short order. Which turned out to be great: there was no opportunity to become wearied by a presentation and a lot of very diverse ideas and functions were given an airing. My notes suggest that just under a hundred different services were mentioned before lunch. Of course they weren't done in depth, the whole point of the morning was to be an eye-opener as to the possibilities, and this it did in spades. And some of the most interesting and challenging ideas weren't necessarily technical: I particularly like the idea of the library customer experience being a journey with rewards along the way. That's an idea we must be able to work with somehow: talking about it afterwards I wondered if the same shouldn't also be true of the staff development path. Besides that I've got a long list of resources to investigate and suggest to colleagues.

Post-lunch (cottage pie! it really was a cosy day!), the sessions were more in-depth. I now know enough to know how much I don't know about mapping APIs. I think I've learnt enough to explore a few ideas for mapping libraries and mobile library routes. I'll have to have a play fairly soon while I still remember what I think my notes mean.

It's been a long week. I started it by looking at integration and interoperability issues in Birmingham; spent a day in York looking at LMS developments; a couple of days back at the sausage factory catching up with stuff and collating notes on our customer-facing business needs (we'll draw a veil over the network problems and a couple of human communication issues); then this last day's explosion of ideas... It's going to be a long job to pull the strands together the way I would hope to do.

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.

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.