Libraries and COVID-19

IFLA provides a pretty comprehensive overview of the impact of COVID-19 on libraries and the known factors involved in returning to something like business as usual.

https://www.ifla.org/covid-19-and-libraries

Managing libraries in a crisis

This is an interesting conversation, not least because of the multiple external disasters the library has had to deal with.

For me this highlights the point that while operational processes can be best delivered just in time the management and governance of a line of business or a public service has to be just in case. Those risk assessments, contingency plans, fallback positions and reviews of  organisational strategies are all essential components of day-to-day business as usual.

In my experience crisis management seems to have been the norm in English public libraries for the past thirty years, even without earthquakes, shootings and pandemics. It would be good if the preparations for reopening libraries could be used not just to put together the essential tools needed for a safe and orderly resumption but also the opportunity to review how these services are structured and supported so that they don't have to be managed on adrenalin.

I'm pessimistic about this because the pressures on the limited resources available will be understandably focussed on the return to business as usual but the problem all along is that we've never established what business as usual really is or how its resilience is to be resourced.

Baby steps out of lockdown.

Resuming business after closing a service — particularly after an unexpected closure — is always more work than the closing was. There are all the consequences of the closure to be tidied up, all the preparations for reopening, all the things that need catching up with before it's business as usual.

And then there's the additional complication where nobody knows if it's necessarily safe to go back to business as usual. And whether or not it will stay safe. It's like working in a building where you can't be sure there's not an unexploded bomb in the cellar or that somebody won't accidentally bring one in with them.

I suspect all returning workforces will have a tricky tension between the popular idea that they've had a rest so should have plenty of energy and the exhausting reality that lockdown will have released a lot of adrenaline over an extended period without the options of fight or flight. The challenge for managers is:

• Not to fall into the trap of making the assumption people have had a rest; 
• Making sure staff don't fall into that trap and start beating on themselves and/or colleagues; 
• And also watching out for their own wellbeing.

The return to business as usual needs to be treated as a managed change process.

• Each step must be specified, planned, and have a rollback plan in case of failure. 
• The physical and mental safety of staff and customers need to be success factors as much as much more than the delivery of intended outcomes. 
• An essential component is transparency: being upfront right from the start that business as usual will be a while coming and that each step taken towards it is dependent on the safety of staff and customers. It's imperative that all stakeholders are told this loud and clear.

There will be a lot of pressure for a sudden abracadabra transformation back to business as usual. It is the responsibility of senior managers and politicians to resist that. (Some will resist the responsibility or even be the loudest voices demanding a swift return to the old status quo. They will be godparents to the local 2nd and 3rd pandemic spikes.)

And then, of course, there's the question of how to manage staff who've worked throughout the lockdown. They'll need a lot of help processing the experience and returning back to normal. That in itself is a significant task and may need support from external agencies. Added to that is the need to manage the relationship between those who worked through the lockdown and those who didn't, the risk of resentments ("We had to work and you didn't," "Why are they getting special treatment?" etc.) needs to be managed out.

All of this is a big management load and I'm not convinced every library service is going to have enough management resource to do this by themselves, especially as many of these issues will apply to the managers as much as the people they are managing. There will need to be a national matrix of support coming in from both library and corporate local government perspectives. I'm hoping that the various national associations, professional organisations, unions and government departments are working on resources to help local managers address both the operational issues involved in the safe resumption of services and, just as importantly, the personnel issues involved in returning back to normal business in times that are very far from normal.

Libraries at Home

This is a very promising piece of ongoing work by Libraries Hacked.

"Watch" pulls together podcasts and videos, "Read" is a blog feed and they're working on "Listen."

This is the sort of thing I'd hoped would have been the basis of a national digital library platform but those projects always seemed to begin and end in discussion of expensive sexy portals.

I wonder how many English library authorities still do Unity submissions. The obvious add-on to the Libraries at Home site would be a union catalogue search which could easily be done with WorldCat if the data's there to be found.

https://www.librariesathome.co.uk/

Sustaining change

Encouraging and managing bottom-up change doesn't have the razzmatazz of a big transformation programme and looks (but not necessarily is) inefficient at the input end but the output is more efficient and sustainable. A culture of continuous small, incremental change and review is healthier and more effective than the traditional years of stasis punctuated by short periods of stress and upheaval.

Here are a couple of useful takes on this:

• People Aren’t Sick Of Change. They’re Just Sick Of Change Programmes

• Minimum Viable Transformation: Change should be Small and Imperfect

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.

An adventure in failure

I toddled along to Library Camps' FailCamp recently. I thought I'd put in a pitch for a discussion about my experience with the People's Network, not as a technical failure but as a failure of project management. I'd put together a few notes, and these are they, with a couple of clarifications arising from the discussion.

---

Introduction

At the fag end of the Major administration in the mid-90s the government accepted a proposal that every library in the country should provide free access to the internet. The details were finalised by the Blair government: Lottery money would be provided to do the necessary; each local authority had to match the Lottery funding, either in money or kind; bids had to be submitted to claim the money; and final delivery on the ground had to be completed by the end of 2002. There was no "national People's Network" along the lines of the academic JANET network — every local authority had to invent their own solution.

We had 19 sites to work with, 10 of which were completely offline. In 2001 our public internet provision was 2 coin-operated PCs in big wooden cabinets plugged into ‘phone lines. We successfully put our bid in at the last possible moment (literally half an hour before the final deadline), received confirmation of funding in May 2002 and by December 2002 all the libraries and 142 public terminals were online. This was a failure. Years later this would feature in staff conferences as “The failure we have to live with.”

Why was it a failure?

Because the customer (the Library Service) saw it as a failure.

So the customer’s always right? 

No: sometimes, as in this case, the customer can be irresponsible and wrong-headed. But if, in the end, you can’t demonstrate to the customer that you have successfully delivered what was required then to some degree, however unfairly, you have failed.

So why a failure?

• There were no pre-defined success factors. If you can’t define success you can only fail.

• The desired outcomes were extremely vague — “Public access to the internet” could, and did, mean many different things to different people or to the same people depending on which way the wind blows on any given day. So you could only fail.

• There was no buy-in to the project by the line of business. While the IT Department planned for and delivered a business transformation project the Library Service didn’t and expected that the change to the service offer to the public didn’t mean that there would be any corresponding change to the libraries’ business as usual. So the customer experienced severe disruption without getting the expected benefit. The lack of buy-in also meant the customer could behave as if the disruption was imposed from without rather than being a service transition within their operational business.

• Technical assumptions made based on the base specifications of the national project didn’t match the real-life requirements that evolved post-implementation. The necessary changes were made within weeks but that wasn’t fast enough — the new solutions weren’t immediately available to solve each problem as it was presented. The narrative became: “It doesn’t work properly.”

• There were the inevitable technical hitches, not least because we were applying technologies we were only just learning directly into a live environment within a very limited time frame. Test environments for the technologies but no test environment for the business implementation. When problems arose the same people trying to solve the problem were the ones being pressured to roll out the problematic solution to all sites p.d.q. The narrative became: “It doesn’t work properly.”

• The Library Service didn’t know what it wanted the public internet for, save that everyone said they should have it and everybody else was doing it. “We want public internet provision” is the same as “We want tables and chairs,” what you get and how you get it depends on what you want to do. Nature abhors a vacuum so the public either found their own uses for the service (some of which — reasonably or not — didn’t find favour with the library staff) or wanted to do things which the solution wasn’t designed to deliver (generally typified as: “I can do this on my PC at home, why can’t I do it on this?” — downloading ringtones and loading software brought in on disks onto the public PCs were the two most popular). The Library Service’s user input to the design and specification went no further than “We want the internet,” consequently expectations weren’t managed, were confused and were inevitably often disappointed.

• As stated already this was seen as a technical implementation, not a business transition. Providing public access to the internet creates a new support load at the front end of the business. Members of the public needing help creating documents, finding and using online services or creating and using email were seen as technical problems to be addressed by “techies,” not service delivery issues and customer support to be addressed by the business. This disconnect was presented as a failure of project delivery not as a failure of business management.

• There was a complete failure of the relationship between business managers and technical support. This lasted years.

Lessons learned?

• Experience isn’t what happens to you, it’s what you do with it.

• You need to specify desired outcomes and success factors. How will you know if the project has successfully delivered? If you don’t you can only fail.

• If you get to the implementation phase of a project without you and your customer both having the same clear idea as to what you’re going to deliver you can only fail.

• If the only pre-implementation meeting you have with business managers is devoted to anything other than the nitty-gritty of the project you are going to fail. (In this case it was 3 hours discussing the location of one table in one library, and no, I’m not making that up. A textbook example of Parkinson's Law of Triviality.)

• Never. Ever. Work on a “We’ll leave you to it” basis. By doing so you are taking the entire risk of the enterprise on your shoulders. Insist on milestones where you get sign-offs of the work that has been done to date. No sign-off, no further work will be progressed. You will be hated for it. But you’ll be hated if you cop for the blame for any problems or failures so you may as well go for it .

• All technical implementations are business transitions, otherwise they wouldn’t be done. The changes may be small or incidental, they may be majorly disruptive. Whatever, changes — and their associated risks — need to be managed and not ignored. Business failure may be blamed on the technical solution not on the failure of business transition management.

• If business managers are more concerned with assigning blame than in finding solutions you need to get out. This type of organisational culture fosters failure without ever learning from it.

hors de combat

Been to what had been planned to be the last of this year's leaving do's (during which I heard some news suggesting there'll be another this Summer). Leaving do's feel a bit strange: it's nice to see old faces, catch up with the gossip and that, but it's sad to see how tired and stressed out the working remainder are. It was always a bitter joke that the people that retired looked ten years younger than the ones still in work. When I first moved out of libraries into my last team fourteen people struggled to do the work expected of the six who remain (who have also had a few other odds and ends dumped in their laps). At the last library leaving do I looked around and wondered how on earth they're keeping the doors open (it was a constant struggle back when there were twice as many bodies available to shift around at the last minute). I feel well out of it and incredibly sad for the people left behind trying to deliver services with ever-dwindling resources.

I think that goes for English public libraries generally, too. I consciously stepped away from the nightmare about eighteen months ago. Before then I'd been doing odds and ends and then I'd offered to lend a hand to the Library Taskforce. After a while I had to conclude that that had become an expensive hobby that wasn't getting anywhere. This was no fault of the Taskforce, it was the fault of the political realities it has to work in. At that time much of the work that we had been talking about had been stalled for the best part of six months awaiting a ministerial signature to the action plan, a consequence of a change of Prime Minister and a ministerial reshuffle. Ironically, the plan was published the same day I finally decided to send the email thanking them for having me and wishing them luck in the future. Not planned, just one of those nasty coincidences real life throws at us.

My breaking with the Taskforce wasn't a reflection on the action plan, it was a reflection of my sense that I wasn't doing anything useful. Until the plan was authorised we couldn't take any action. We'd spent a few months discussing how to use the library data that the Taskforce had managed to collect so far. Objectively this was nothing much, just a list of all the libraries in England and their current status (open, closed or various flavours of "community" library). In fact, collecting this was like pulling teeth and involved trawling round hundreds of web sites to build a list, then each library authority was sent a list with the note more or less saying: "We think these are all your libraries. Please could you confirm/deny and make any corrections. Thanks." Most authorities responded and any corrections were made to the "definitive" list; when an authority didn't respond the hope had to be that they hadn't found any mistakes. And then we sat around, full of ideas and possibilities but not being able to get anywhere. Which is why I felt I was being useless and eventually quit.

(When this data set was finally released, after the action plan had been authorised, there were howls of anguish about what wan't included. "This is available already from CIPFA statistics," somebody complained, ignorant the fact that the reason why CIPFA stats weren't trawled in the first place is that a large minority of library authorities don't submit the data every year, or in some cases at all. This was what it said on the tin: an attempt to create a definitive list of English public libraries with a model process for keeping it up to date, the base on which to build other national or regional data sets about the libraries, their services, their use and their contexts within their communities.)

There were things in the action plan I could argue with but by and large it provided something to work with, given the working realities of a fatally-fragmented service with no standards for service delivery or performance management set as a small backwater in local government provision that had had its funding halved, with most of what remained buttonholed by adult and children's care services. The underlying problem was (and still is) that there is no way of changing that working reality: on top of the usual inertias and contests between vested interests there were the lingering effects of Localism and — worse, much, much worse — a Brexit that was already occupying most of the time, energies and resources of government with scant room for business as usual let alone a radical rethink of public library policy. So the action plan was inevitably going to disappoint anyone looking for a white knight to charge to the rescue of English public libraries. The complaint was that this was too little, too late. And of course it was: nothing short of a shitload of money and a time machine was going to be any different. And even then, once you'd gone back to the Golden Age of English Public Libraries (which I would argue would be 1996 – 2007) what response would you get? "Oh we're much too busy, besides, they can't cut us we're a statutory service." In my experience the history of English public libraries over the past thirty years is littered with the expectation that somebody will come along to make everything better, just so long as they don't change anything.

Which brings me to the other reason to step away awhile. There's a fine line between many years of experience and a hell of a lot of baggage. For example, when the argument is being made that English public libraries are best placed for bringing information literacy to their communities the reply: "Well, they didn't, did they?" isn't an unfair response but it isn't helpful or useful, especially not in the context of an existential struggle for the future of the service. It's the sort of stuff that might be useful to a post-survival lessons learned or a "How did we get there and how do we stop it happening again?" process but isn't useful now.

So I've withdrawn from the field. Whether or not this is temporary, I don't know. Life happens while you're making other plans. I wish those still engaged the best of luck, with the unhappy knowledge that they will need it.

Library data part three-and-a-bit: sharing customer data

Having had a quick scamper through the worry list, what customer data could be shared openly?

Let's start with what can't be shared:

• Name
• Full address
• Unique identifier for the data record
• Nearly all combinations of data elements within the record

The first two are obvious Data Protection precautions; the last two are less obvious precautions for the same reason: they make it possible to identify the individual data subject.

Any data extraction for release as open data must specify the required data elements. Required fields need to be selected for extraction rather than having fields not required filtered out post-extraction. This prevents any accidents. Once data's openly out in the wild it's out in the wild.

"Registration location" and "Library/libraries used" (if available) are both safe in themselves as they aren't personal data and will have data sets broad enough not to be able to identify individual data subjects. They could be combined with each other and any one of the following:

• Category (e.g. type of borrower)
• Ethnicity
• Disability
• Gender
• Year of birth/age in years (if only date of birth can be extracted then this data shouldn't be used)

The data extract could be:

       Bedlam Library     Child
       Bedlam Library     Child
       Bedlam Library     Adult
       Bedlam Library     Adult

But not:

       Bedlam Library     Child     Male
       Bedlam Library     Child     Female
       Bedlam Library     Adult     Female
       Bedlam Library     Adult     Male

Any two of these could be combined:

• Category (e.g. type of borrower)
• Ethnicity
• Disability
• Gender
• Year of birth/age in years (if only date of birth can be extracted then this data shouldn't be used)

A postcode dump for the whole library authority could be made available but not combined with any other data because of its very specific nature for identification purposes.

I think that's pretty much it. And I'd still want to run it by an Information Governance expert before going ahead (and for them to check my Privacy Impact Assessment).

Library data part three: dangerous demographics

The data about the people registered with a library is at one and the same time the most potentially useful and the most potentially dangerous. So dangerous, in fact, that when it comes to making this data openly-available the default position must be: Don't. Do. It.

That position will be strongly challenged by many so I'll devote the rest of this post to explaining the dangers and the next one will have a look at the data that might be openly-shareable so long as all the necessary precautions are taken.

Demographic information is immensely useful to a library service. Operationally it's important to see that the service is meeting the needs of all its communities and not just providing a service "for people like us by people like us." It's important to be able to make sure that particular services are reaching their target audiences and that you're not doing anything to put sections of the community off using your services. And it's essential that you have this data for Equality Impact Assessment of policy decisions. So why would you not want to share the data to get a bigger picture?

Generally speaking there are three main concerns:

• Privacy. The library is one of the few safe public places left for the individual. Removing the right to privacy is an information governance issue just as much as an ethical one and both need to be taken very seriously (both are generally given too much lip service and too little analysis and action).
  
  It also compromises the quality of the service being provided: if library customers know that how they as individuals use the library will be made public a good many of them will modify their behaviour and not use the library the way they want or need to. If they don't know this the library will have committed a significant breach of trust. 

• Legality. Does the library have the legal right to share the data? If it is possible to identify individual data subjects then the answer is categorically: No, unless the data subject has explicitly said that their data may be shared.
  
  Anonymising the data so that it is no longer personal data is easier said than done. It isn't a matter of just removing all the names. We'll have a look at this later on.
  
  The agreement has to be an opt-in and the purpose of this data sharing has to be clearly stated. "We want to make your data open so that other, as yet unknown, people can manipulate it to get as yet unknown information and outcomes" would be an open invitation to the Information Commissioners' Office to come and investigate your organisation.

• Safeguarding. This is the most problematic and under-appreciated concern. Anybody knowing whether or not a person even visits a library, let alone uses it, may put that person in actual physical danger. In some controlling relationships a partner may only be allowed out to go to the shops and heaven help them if they do anything else. They may be allowed to take a child to library activities such as story times but not for themselves. An abusive partner discovering that somebody was somewhere they shouldn't be — the wrong end of town or even the wrong town — could be a trigger for violence. The test here isn't: "What is reasonable?" because this isn't about safeguarding people against reasonable action. It's about safeguarding them from action that may be anything but reasonable.
  
  In my head I can hear somebody saying: "If they let us know that they're in an abusive relationship we could put a flag in their record to say their data's not to be shared."
  
  
• This requires the data subject to actively opt out of data sharing.

• Identifying yourself as a person in an abusive relationship is a brave thing to do and not something that should be required to be done at a public service point in a library.

• The library suddenly becomes a less safe place.

• Someone's got to remember to filter out the flagged records before sharing the data.


I don't think any of that is acceptable. (And said so when it was said to me that time).

Anonymising the data requires more than stripping out all the names. The Information Commissioner's Office has a useful checklist (pdf).

In public libraries the combination of nearly any two data elements may be enough to make that data subject identifiable, or at least narrow the number of possibilities down enough to make it statistically probable they could be identified. The combination of "library where registered" and "library used" plus one other datum is usually OK but this needs to be tested with the particular data set, in case of nasty surprises. Other combinations very quickly narrow down to the individual.

A lot depends on the data itself: if the categories used are very general it might be safe to combine it, though it may be so general as to be pretty useless. I really did once work with a library service that thought it was OK to have two ethnic identifiers in the system: blank for "people like us" and "ethnic" for anyone who looked or sounded a bit foreign; I put a block on that the first chance I got; even so it wasn't until we got all the libraries onto the library management system that we finally got right of the last of the old Browne Issue tickets with a red E on them (disturbing symbologies like that make me wonder what librarians were thinking about in the eighties).

• I'd imagine my local library authority will have thousands of white adult males in their database. How many — or few — teenage Bangladeshi females would there be?

• Postcode data very quickly narrows down. There are perhaps ninety people in my postcode area. Twenty-odd adult white males. About four males in their fifties. One white male in his fifties.

• Age data gets very specific very quickly. "Adult" and "Child" is pretty safe but as soon as you start refining that down it becomes problematic. Full date of birth is so specific it 's a red flag. 

So we would need to be very careful about what data — and what combination of data — is made available. In a library consortium setting this should be governed by formal data sharing protocols that had been passed by each authority's information governance experts and given the OK by whoever is responsible for the authority's information risk so all the data of all the people who have actively agreed to their data's being shared can be made available to the appropriate staff for the appropriate purpose within the consortium. That's a very specific remit for a very specific purpose for the use of a very specific group of people, with checks and balances and sanctions for abuse.

Which is exactly not the case with the open release of data, so different rules need to apply and need to be applied proactively (the genie doesn't go back into the bottle if you find you've made a mistake). Hence the greater need for precaution.