Big is the enemy of good (part two)
In my last post I wrote about how applying for a job can be a complicated process.
I picked an example from a public sector website and highlighted the difficulty in completing a straightforward set of activities.
This was partly down to confusing language, unclear instructions, and procedures that seemed to favour the ticking of boxes rather than concluding the task in hand.
I also mused on some of the possible underpinning factors.
In this post I'll talk more about the reasons why I think we wind up with digital solutions that don't solve the problems they're meant to.
It's not all doom and gloom though. As I discuss towards the end, alternative options are peaking through the clouds.
Everyone's and no-one's responsibility
There’s something soothing about reading Jennifer Pahlka’s Recoding America: Why Government Is Failing in the Digital Age and How We Can Do Better, published last year. It’s not as if the picture she paints is a pretty one – quite the opposite in fact.
The detailed descriptions of the assorted projects she led, or was intimately involved in, while CEO as Code for America or serving as U.S. Deputy Chief Technology Officer offer anyone who’s worked at the digital coal face in government or a large organisation a slew of examples to reflect on, and maybe even take comfort from.
She systematically breaks down the intricate, ill-focused, expensive, exhausting knots that governments and the public sector tie themselves in when striving to deliver services.
There are several recurring themes in the book: the inflexibility of systems to adapt, the gulf between policy intent and implementation (there's a particularly sweet anecdote about "policy vomit"), and impenetrable decision-making structures.
One of the best examples that binds the themes together is the story of the U.S. Air Force's use of an enterprise service bus (ESB), a wincingly painful account of retrieving data from satellite systems. It's also a focus of Ezra Klein's must-listen podcast interview with Pahlka.
The ESB story pulls back the curtain on the bizarre urban myth-like reasons that a simple, practical software solution can't be implemented and a complicated one (that doesn't work) is pursued indefinitely at the cost of billions.
While it's at the extreme end of things, the problems the ESB tale illustrates are endemic in much of the public sector, where it's not always easy to get straightforward answers, or pursue the most rational course of action, without running into tangled hierarchy.
If an organisational HR function sits separately from its finance function, which sits separately from its technical infrastructure, which sits separately from its web operations, which sits separately from cybersecurity [etc, etc, you get the picture] and there simply aren't the ways and means to cut across these or coordinate decisions, it can make solving the most minuscule of problems a challenge.
It's even trickier when there are multiple organisations involved, each with their own version of the above functions, and vastly different staff and skills profiles.
This point is particularly well exemplified in Pahlka's book where the independent state legislature in each of the 50 U.S. states means it's incredibly difficult to implement and maintain common standards, let alone centralise entire services.
"Gosh, that sounds hard." I thought to myself, before remembering that here in Scotland we have over 150 organisations making up the public sector.
Every context comes with its own complexities.
Too big to succeed
As I've intimated in the title, sometimes it's the sheer size of the perceived issue that gets in the way.
In government and public sector terms, the notion that big problems require big solutions is often how business gets done.
There's a curious double bind that prevails: to get a programme off the ground often requires the need to puff out business cases with compelling cost benefit analyses made up of, frankly, unknowable numbers.
But because those numbers are at best sketchy, and the long-term value so hazy and finger-in-the-air, the inevitable happens when delivery can't match intent.
Therefore big, visionary programmes end up faltering and failing: massive overruns, spiralling costs, and benefits kicked into the long grass.
And when it's all going to pot, the arduous chore to investigate 'why?' kicks in. Cue even more time, energy and resource being sapped as everything and everyone gets hauled over the coals.
I offer no specific insider knowledge here, so I am very much open to challenge on all of what follows.
Part of the reason for focusing my previous post on job application processes is that UK Government's Shared Services Strategy – one of those big, visionary programmes – appears to be, on the evidence I can glean, already too far down the road to back track, already too big to succeed.
The back office of the future
For decades, monolithic Enterprise Resource Planning systems have lumped the critical organisational activities of HR and Finance (and sometimes Procurement and IT) together as 'back office'.
What I find curious when I read the Shared Service Strategy for Government is for all the talk of improving efficiency and enhancing user experience, it seems to be a given that the functions of HR and Finance are natural bedfellows.
Indeed, one of the lead statements is: "We are bringing together back-office government finance and HR transactions to deliver a transformed customer experience for civil servants."
I'm hypothesising slightly here, but it strikes me that a modern HR operation doesn't have that much in common with a corporate finance function. Sure, there are overlaps – payroll for instance – but the inextricable link seems at least worthy of question.
I'm sure there are bona fide strategic reasons and a wealth of user research behind all of this. However part of me can't help wondering if the overarching context has more to do with large IT companies finding clever ways to modulerise and make money out of the component parts, rather than any clear-eyed analysis of user and business needs.
And that ties into the points I made about job application user journeys previously – a sense of a process bolted together rather than designed with real people in mind.
Without due care and attention the end result becomes a half-baked version of what it needs to be. Yes, you may have gained efficiencies but does it actually do the job it's meant to?
If the desired outcome is, say, “a workforce fit for the future” then perhaps shoehorning people into homogeneous processes your software supplier has designed isn't the route to success.
What's the collective noun for clusters?
The Shared Services Strategy makes some fairly standard proclamations about the transformation it's seeking to achieve. The jargon of change programmes becomes somewhat workmanlike once you've waded through a pile of business cases.
Where the document gets altogether hazier is the decision to break the proposed programme of work into five Shared Service Centres. If you squint a bit it's possible to sort of see the rationale for this, but the explanation is at best opaque.
As noted in the most recent National Audit Office report on the programme 'service centres' are now referred to as 'clusters'. Appropriately so, as on the strength of the following paragraph (one of many similar themed in the audit report) you may well resort to uncouth language.
"Clusters described the strategy as “exceptionally ambitious” and the timelines as “challenging”. Once clusters have implemented their individual solutions, they will still have work to do to ensure data and process convergence across government. Governance arrangements also differ by cluster, with the Matrix cluster being the only one to have a joint investment committee. Individual departments in the Matrix cluster have also signed a ‘declaration of commitment’ that sets out agreed ways of working and reaffirms their commitment to the Shared Services Strategy. Other clusters currently use existing departmental governance structures, meaning that all proposals must be approved by each department’s boards, slowing the decision-making process down. The Cabinet Office does not know how much the strategy has cost to date."
I don't know about you, but if a solution is projected to cost hundreds of millions of pounds yet is unable to articulate tangible benefits and is reliant on impossible-to-follow governance arrangements, one might choose to question the approach.
Subsequent to the NAO report, a parliamentary enquiry dug further into the issues. This concluded (I paraphrase): there isn't a contingency plan; there was never a business case; there isn't enough funding; benefits haven't been quantified; there is no monitoring in place; and "there are lessons to be learned from this strategy that will be applicable to future government projects".
Lessons to be learned you say? It's not as if the warning signs weren't evident for anyone who cared to look.
In the wake of the Post Office Horizon IT scandal there’s been lots of in-depth analysis of the multiple reasons – both human and technological – that caused such a cataclysmic series of failures.
This informative blog post by Dafydd Vaughan breaks down the different factors at play, and helpfully links to numerous other large-scale IT failures that should be required reading for anyone who's planning a public sector technology project.
It's noteworthy how many times the same large IT vendors appear on the list.
True to form, Private Eye recently reported that Fujitsu is potentially bidding, albeit in partnership, for a slice of the Shared Services pie despite supposedly pausing government tenders while the inquiry into the Post Office Horizon scandal takes place. I'm sure your compliance teams are all over it, eh lads?
Strategically smaller
So what to do? It's all very well for me, standing outside the tent, offering my critique in an over-opinionated newsletter.
I'm also highly aware that there are lots of sensible, talented, diligent people working in the public sector who know all of this but will be too uncertain, or disempowered, or jaded, or confused about who exactly to seek permission from, to know how to make a difference.
And it's not to say there aren't strong examples of good practice in the ether.
The UK Government's platforms have been game changers when it comes to providing straightforward reusable service components. Scottish Government has focused on rolling out its own identity, payments and cloud platforms [full disclosure: I previously led one of these programmes]. However, they remain the exception rather than the rule.
None of these examples are what you would call 'small' either. They've all taken time, required significant investment, and have had to overcome various hurdles along the way. But they're committed to implementing services in a particular way, rooted in the needs of the user base they're seeking to serve.
What sets them apart from the Shared Services Strategy is the focus on delivering change in bite-sized chunks.
Rather than implementing technology in huge inflexible blocks, built by vendors who trade in lock-in and disappointment, the strategy becomes about defining the right outcomes and breaking what you deliver into corresponding constituent parts driven by user needs.
If one of those parts goes off-piste and is no longer fit for purpose, then your whole programme isn't suddenly at risk. But if your entire strategy is geared around a big technical solution, by association the risk becomes much, much bigger.
Smaller, therefore, is strategic. Smaller should be core to the mission.
Small(er) is beautiful
As I was busy drafting this (aka rearranging the same paragraphs over and over again) two exceptionally useful, critically-timed reports were published in quick succession:
Public Digital's The Radical How, a Nesta-funded paper that absolutely gets to the heart of the matter
Dr Natalie Byrom, Rachel Coldicutt and Sarah Gold's People first, always which calls for a reimagined Government Digital Service, with a whole heap of ideas as to what that entails.
I was particularly delighted, as it meant I no longer had to come up with a pithy, optimistic conclusion to my reflections.
The notion of 'smallness' features in both publications; People first, always talks of the need to reign in contract values, quoting directly from a source who says:
"Government must do the hard work to break up contracts into smaller units"
While The Radical How is peppered with talk of small teams and "small, bounded experiments". This point on the need to change the governance around funding stood out for me:
"The very fact business cases take so much time and effort to construct disincentivises teams from starting small, testing assumptions, and asking for small amounts of money to do so."
If you're at all interested in this stuff I'd encourage you to pore over both these reports, embed their principles into your work, send them on to your managers, quote them in meetings, shout the key messages from the rooftops (OK, maybe too much).
I'll close things off with a hopeful quote from the final chapter of Jennifer Pahlka's book.
Just in case it's not evident, everything I've written here comes from a position of caring deeply about how public money gets spent and how public services get delivered.
There's no getting away from the fact that to avoid mistakes of the past, fundamental rewiring is required. But with the right impetus, the right vision, and the right focus, change is possible.
"What if the way technology has played out in our society over the past decade, increasingly dominated by late-stage capitalism, was just a practice run and government's belated adoption of digital is what we were practicing for? What if, just as we most need institutions capable of bold collective action, we are at the beginning of the real digital revolution, the one that happens inside our public institutions?"
What if, indeed.
😮💨 Thank you for reading.