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.

Herding digital cats

It's interesting that the report on the national digital presence for public libraries finally saw the light of day at the same time that BIC and a lot of library technology supply companies were meeting to progress the Library Communications Framework (LCF).

In their own ways they are each trying to solve the same problem: how to pull together a myriad disparate resources and services, each built to their own specific requirements, into a single user experience without requiring the availability of hundreds of library technologists in the front line of public libraries who probably will never exist.

I think they are both doable, with fair winds and fair spirits prevailing.

Deck of cards

One of the things I'm wiggling round inconsequentially like a loose tooth in the back of my head at the moment is a set of notes and checklists on the general theme of "doing stuff" aimed at somebody without the scars of experience who's got that rabbit-trapped-in-headlights feeling about a piece of work. It would be a hotch-potch of things I've learned over the years at work, things I wish I'd known before I'd done some pieces of work and things I've watched and marvelled as other people worked their magic. Essentially, a basic, interdisciplinary toolkit for somebody struggling to know where to begin.

Thinking about that "trapped" feeling where you can't see where to go next, or the only way is somewhere you don't want to go — particularly creative block and group-think — it occurred to me that there ought to be some tool that could help. Something a bit more proactive than "go and do something else for half an hour" that could combine displacement, suggestion and challenge. And it turns out that there is: the original out-of-the-box thinking. The usefulness of tools like Oblique Strategies and Distant Early Warning isn't in the apparent power of divination so much as the introduction of a random variable that disrupts the state of thought. I'll certainly have a play with that idea.

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.

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.

Neologism

Faeture (n): An unwarranted new "feature" that buggers up a tried and tested product.

Secret to Successful New Product Innovation: Keep the Boss Out of It

Interesting report by Nielson presented the other day here. The basic question is: why are some organisations better at innovation than others? The result of their study looks provocative at first:

"One secret appears to lie in the degree of senior management involvement in the creative process."

I'm happy to stop the ball rolling there and enjoy the point-scoring, but I think there's a much more important point made in this report:

“New product development success comes down to two important principles - - managing ideas lightly while managing the process precisely,”

This is important. Successful innovation is the intelligent application of creative thought.

• Creativity is about making new connections and doing something with them.
• Intelligent application is about persuading the creative process to do something useful with them.

You'll notice the active verbs involved here.

Library services aren't alone in the public sector in tending to manage ideas precisely while managing processes lightly, if at all. It's a habit we could usefully unlearn. Library service managers who organise and unclench can optimise the potential of both their workforce and their service. The ones who don't will struggle.

Is your library making milkshake mistakes?

A useful heads-up on The Unquiet Librarian's site (thanks again to Marianne for the link).

It's a variation on the "can't see the wood for the trees" problem where the purpose of a development activity has become ill-defined. In this case the key question for the developer is: "are we wanting to improve [however defined] the product or are we wanting to improve its sales?" If the former, then the behaviour of the product is paramount. If the latter, then the behaviour of the [potential] customer is paramount.

It doesn't matter how excellent your product is if the customer can't, or won't, use it or afford it. A 'good enough' product that doesn't require the customer's having to radically modify their usual behaviours is always going to have something going for it.

Slacking

I'm uncomfortably defensive about days spent working from home. I tell myself that on the plus side I'm not going to spend four hours commuting, the network connection is faster and more reliable, I have access to tools that aren't available at the workplace, yadda yadda yadda... And it's true, I am genuinely more productive than at work. But I do still feel uncomfortably defensive.

For one thing, it's too comfortable. I've been sat sitting on the sofa working on the laptop, a pot of tea to hand, the Hairy Bikers on DVD for background noise (the remaining background noise being provided by a robin, a wren and a charm of goldfinches). This can't possibly be work can it?

Oh, I've done all the usual systems housekeeping work. And reported the (sadly) usual problems. I've run a pile of statistics to test an idea that was worrying me about distribution patterns of reserved stock and written a few web pages but I can't say that I feel that I've been particularly productive today.

Part of the problem is that the world has changed. What have I been doing while I've been slacking?

• I've been eavesdropping on the ALA Virtual Conference (thanks to both Marianne and Stewart!);
• Watched lectures on the potential of the online cognitive surplus; Facebook game business dynamics and making a splash with social media;
• Checked out articles on Mashable and LGITU;
• Tried to get my head round the mechanics of the WriteToReply functions being explained by Tony Hirst. and
• Exchanged concerns with colleagues about the current state of play of one of the library management systems companies.

Nothing extraordinary there. You'll have done as much, probably considerably more. But have another look at that in the context of "work," without the use of a laptop and t'internet.

• Peeking through a window to watch a conference.
• Leaving the office for a day just to see a lecture or two or attend a seminar or meet colleagues from far, far away

In the old days what I'm calling slacking would have been A Hard Day's Work. Time was, so long as you clocked on and clocked off at the right time you were doing your work. It was OK to feel not particularly productive because you'd been In Work All Day and had earned your corn by your very presence. These days, I'm happy to say, the currency is deliverables, not time spent (shouldn't it always have been?). So where does that leave personal professional development? It was never much valued in the 'time served' model, but does it only have a utilitarian value in the 'focus on delivery model?' Dunno. I'd like to hope not; I believe that understanding for the sake of it increases the opportunities for the serendipitous development of solutions. But I'd be hard-pressed to prove it.

And I still think I've been an idle beggar today.

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!)