"Surely" it "can't be that complicated"

In the strange armpit of time between Christmas and New Year I was reading an article about the Arts Council and British Library project which aims to “create a single digital presence for libraries”.

The article had the headline “Millions wasted on attempt to create nationwide UK library website, campaigners claim” and did a neat job of encapsulating many of the challenges around digital in the cultural sector.

I have no real inside knowledge about the project and whether or not it is actually “millions wasted”.

But there are a number of aspects of the coverage that I think are interesting to unpick.

In the article was a quote from Tim Coates who is “a libraries campaigner and former head of bookseller Waterstones” where he said (amongst other things):

“It should be like the website for John Lewis – that, wherever you are, it doesn’t depend on their individual shops.”

To be fair to the article it does make an effort to point out that “The problem has been that there are 150 library authorities in England alone, each with their own technology and management systems”.

But I think that the quote from Mr Coates is symptomatic of the view that many decision-makers in and around the cultural sector have of ‘the digital’.

I have been in numerous conversations with institutional leaders where variations of “surely it can’t be that hard” have been uttered (and the John Lewis website is often then cited, apparently the only place these people spend any time online).

The lack of even a high-level understanding of how technical complexity might occur and, more importantly, the realities of delivering technical projects is a really serious issue and gap in many (most) leadership conversations.

This is something that the excellent Kati Price has been pointing at for a while now, and we discussed this leadership challenge on the Digital Works Podcast.

It’s one thing to not let challenges distract from a compelling vision, a scenario in which you do everything required to reduce and remove obstacles and support your teams in achieving that vision.

It’s quite another to dismiss or refuse to engage with reported challenges, and instead express frustration and amazement that the challenges are, in fact, a challenge.

But back to this libraries project. For example, integrating 150 systems is a big task but, probably (I’m guessing here), the most difficult technical part of this libraries project will be around transforming and normalising all the data that comes from those disparate systems so that the ‘single digital solution’ can actually present something coherent and useful.

And then within that data consistency challenge will be all sorts of messy non-technical things relating to human processes, inconsistencies, and failings.

Not to mention the boring but essential job of establishing access to those systems, and working with underfunded, overstretched council IT teams.

Then you have the - probably nearly impossible - job of dealing with (at least) 150 sets of (I’m assuming) very non-digital stakeholders in extremely non-digital organisations.

Added to that is the fact that neither the Arts Council nor the British Library has, as far as I’m aware, a particularly extensive track record in delivering projects like this.

And lastly, with a project like this I don’t expect that an MVP approach would be acceptable to the many (very non-digital) people who would need to be involved in a decision like that.

I suspect that it may also be the case that there isn’t absolute clarity about what the project is actually trying to achieve.

All of which is to say, I’m not surprised that millions of pounds have been spent on this project so far. And millions more pounds will probably be spent before it’s finished.

Tl;dr

• Decision-makers need to get more comfortable engaging with the realities of complexity, trusting their teams, and accepting that, sometimes, something that “feels” like it should be straightforward, actually isn’t.
• An iterative approach to large, complex projects will usually save you time and money in the long run (not to mention help with stakeholder buy-in). I’m not necessarily advocating for a full-fat adoption of Agile, to pull a useful bit from the MVP definition I linked to above: “A key premise behind the idea of MVP is that you produce an actual product (which may be no more than a landing page, or a service with an appearance of automation, but which is fully manual behind the scenes) that you can offer to customers and observe their actual behavior with the product or service. Seeing what people actually do with respect to a product is much more reliable than asking people what they would do.”.
• A clear, shared understanding of the outcome that a project is trying to achieve is essential (I’m writing a bit more about outcomes vs outputs next week).
• And, to people like Mr Coates, commenting on things you don’t understand isn’t especially helpful and often makes you look quite foolish.

A final note to also say that I’m not excusing ‘technical complexity’ as a reason why something shouldn’t happen, and the sector has also often been guilty of overengineering solutions to problems, or letting perfect be the enemy of good enough.

But sometimes, actually quite a lot of the times, things are actually more complicated than you thought they would be, and they take longer than you want them to.