Monday Morning Moan - lessons to be learned for government digital services delivery again (and again and again and again and again and...)

Despite 25 years of government strategies and countless attempts to deliver digital business change successfully, there is a consistent pattern of underperformance.

An opening statement from a report from the UK Government’s National Audit Office (NAO) last week that had me involuntarily blurting out in Starbucks, ‘You don’t say!’. 

For anyone who’s tracked the various major IT programs in the public sector, the list of high profile failures is easy to tick off on your fingers.

The ‘North Star’ to date in the UK has been the National Program for IT (NPfIT) which, as I’ve noted before on many occasions, was commissioned by Prime Minister Tony Blair in one of his ‘searching for posterity’ moments on the back of an hour long briefing. Billions and billions of taxpayers pounds later, there was little to show for years of vainglorious posturing, other than an increasing line of tech vendors lining up to sue the Government.

But there are other challengers. The Verify ID program deserves its particular opprobium, while the COVID Test and Trace debacle will surely be a contender to take on NPfIT, but we’ll wait for the inevitable inquiry and possible legal actions to bed in before coming to a final judgement there.

Of course, government tech failures aren’t a UK-specific thing. Look across The Pond at America’s own VAMS (Vaccine Administration Management System) or the problems with the Obamacare IT rollout a few years back. And the recent JEDI row - see Kurt Marko’s excellent evisceration - is indicative of how badly things can go wrong in Washington as well.

Now, as is traditional in such moans, I must point out that there are exemplars of good practice in public sector IT, particularly at the local government end, and diginomica attempts to track and air these as often as possible. (Feel free to share more with us so that we can add to our catalog!)

But as programs get bigger, the more obvious the shortcomings become and are exposed to cruel scrutiny. And, of course, the biggest problem is that it’s your money that’s being poured down the drain.

But unlike in other areas of life, failure does not lead to banishment in government tech circles. If you’re asked to build a shed for a friend and then you blow the budget and take too long to build it, only to find when it’s ‘finished’ that it’s not fit for purpose and the roof falls in on anyone opening the door, chances are you’re not going to be asked to build any more sheds for anyone who knows you.

But round and round we go with the same old names in public sector tech provision. According to Tussell’s ranking of strategic suppliers to government  (not just tech), the ‘usual suspects’ keep on coming back. Oh, there are some newcomers joining the ranks of the dominant players - Hi, AWS! - but the bad old days of outsourcing everything to big US consultancies that were supposed to have ended just over a decade ago didn’t go away. They just lurked in the shadows until it was safe to come out again. So look down the Tussell list and welcome to the stage Accenture, Atos, Capgemini, CGI, Fujitsu etc etc etc.

And nothing seems to poison the well. Those of us long in the tooth enough will remember the sight of Fujitsu suing the UK Department of Health for £700 million after it was ejected from its NPfIT contract. Flash forward to 2019/20 and the UK Government paid out an estimated £453 million to Fujitsu for public sector work, according to Tussell.

Why, oh why? 

So why do things keep going wrong? The NAO notes:

This underperformance is often the result of decision makers fixing on technology solutions before fundamental aspects of projects and programmes are sufficiently thought through…When large digital business change programmes run into difficulty, the technology solution is often cast as the primary reason for failure. There is rarely a single, isolated reason which causes critical programmes to fail. Many of these programmes face intrinsic business challenges as well as technical challenges.

Our findings point to a range of problems, including: shifting business requirements; over-optimism; supplier performance; and lack of capability at the senior and operational level. Only a small proportion of permanent secretaries and other senior officials have first-hand experience of digital business change and as a result many lack sufficient understanding of the business, technical and delivery risks for which they are responsible. This means that many of the problems stem from the inability of senior decision-makers to engage effectively with the difficult decisions required to implement technology-enabled business change.

A second report, Organizing for Digital Delivery - produced in 2020, but finally released by the UK Government last week! - offers up its own suggested ‘challenges’ to digital transformation in the public sector, specifically:

• Challenge 1: Uncertain quality of technical product delivery.
• Challenge 2: Unaddressed legacy systems and technical debt.
• Challenge 3: Relatively weak operational performance monitoring.
• Challenge 4: Failure to leverage scale. Eg having to negotiate separately with vendors
• Challenge 5: Missed opportunities in leveraging Government held data sets.
• Challenge 6: Low technical fluency across senior Civil Service leadership.
• Challenge 7: Confusion over the role of the central functions.

On that last point, the report notes:

When McKinsey surveyed Permanent Secretaries about the role of the centre in late 2018 they found that, of all the centrally operated functions, departments had least confidence in GDS.

That’s the Government Digital Service (GDS), once the seeming beacon of hope to get government tech delivery in order and the subject of near universal resistance from departmental fiefdoms that saw their eternal right to waste taxpayers money on abortive IT being taken away from them. (I’m also minded to observe that the very fact it was deemed a good idea to bring in McKinsey to survey obdurate senior civil servants is indicative of underlying issues in their own right!).

Lessons to be ignored learned

So what can be done? Do we just swallow the idea that it is the role of the public sector to prop up the bonuses of US systems integrators and chalk it up as a political reality? The NAO inevitably has its own ‘lessons to be ignored - sorry, learned. These are:

• Understanding aims, ambition and risk - Avoid unrealistic ambition with unknown levels of risk; ensure the business problem is fully understood before implementing a solution; plan realistic timescales for delivery, which are appropriate to the scope and risk of the programme.
• Engaging commercial partners - Spend enough time and money exploring requirements with commercial partners at an early stage; adopt a more flexible contracting process that recognises scope and requirements may change; work towards a partnership model based on collaboration with commercial suppliers.
• Approach to legacy systems and data - Plan better for replacing legacy systems and ensure these plans are appropriately funded; recognise the move to the cloud will not solve all the challenges of legacy; address data issues in a planned and incremental way, to reduce the need for costly manual exercises.
• Using the right mix of capability - Be clear about what skills government wants to develop and retain, and what skills are more efficient to contract out; better align political announcements, policy design and programme teams’ ability to deliver through closer working between policy, operational and technical colleagues.
• Choice of delivery method - Recognise that agile methods are not appropriate for all programmes and teams; when using agile methods ensure strong governance, effective coordination of activities and robust progress reporting are in place.
• Effective funding mechanisms - Ensure that requirements for both capital and resource funding are understood and can be provided for; see technology as part of a service that involves people, processes and systems in order to better consider the economic case for investment.

All of which is sound enough and easy enough for everyone in Whitehall to nod sagely at before signing off the next multi-million pound contract to a US cloud services provider.

Organizing for Delivery also produces its own ‘lessons’, but in reading those, my eye was caught by the comments offered on Twitter by Mark O’Neill, one of the co-founders GDS back in the day, former Chief Digital Officer at the UK Department for Education and someone whose view on public sector tech has always been well-worth taking on board - check out his twitter handle @marxculture.

Of the eight recommendations in Organizing for Delivery, I can't do better than repeating what O’Neill says - quoting from twitter:

(1) Build mechanisms to put the citizen at the heart of all design decisions

Or, more simply, ‘What’s the user need?’. Which has been mandatory since 2011. The core problem with this is that, to be blunt, government is not always about “put(ting) the citizen at the heart of all design decisions.” UC and other benefits, immigration…There are many services where the Minister is at the heart not the citizen.

(2) Strengthen the accountability of Departments and their Permanent Secretaries

Which is not wrong but appears in every such report on every function in government. Why will making this recommendation this time be different?

(3) Hire a Permanent Secretary level head of function

Why? I am not opposing the idea but there is no clarity how such a person will make a difference. And my own experience is that anyone in the role will leave in despair within 2 years.

(4) Re-focus and add teeth to the centre

All the things in this section are essentially a list of what GDS did for its first 5 years. Without understanding why GDS ceased doing those things it risks being built on sand.

(5) Create clear investment swim lanes to address the legacy debt

(6) Set up a quarterly business review process.

It’s deja vu all over again.

(7) Invest in developing the technical fluency of senior civil service leadership

We have a key saying in design - “The purpose of any system is what it does”. The Civil Service leadership system generates a particular “caste” of people. If you want to change that “caste” then you need to change the system itself. That would require a radical rethinking of the Civil Service rather than a couple of days on a course in Oxford.

(8) Create a Government data application centre of excellence

This has been a recommendation in every report since data started being collected. It is not wrong, better APIs and open data standards are a good thing. But what is the citizen need here? Working in any large bureaucracy is like being on a merry-go-round. You are always in motion but the same sights keep coming round again and again. So too, it seems, does the need for the original GDS.

You’ll get no argument from me on any of that.

It's the hope that gets you...

There  was a brief period in the UK under Francis Maude when he and the emergent GDS team looked like a positive wave of change in how the public sector delivered digital transformation and the big ticket tech vendors bemoaned their lot, with the then CEO of CGI complaining:

You’ll be aware that the government is making life difficult for IT vendors. I find this adversarial approach quite unhealthy.

Those days are firmly in the rear mirror. The oligopoly empire struck back. In Washington, the US Digital Service has at least managed to survive the Trump era, although it was a close run thing, and is now doing interesting work on its mission.

But we’ll all be back soon to discuss the latest ‘IT cock-up’ - © mainstream media coverage of hugely expensive and utterly avoidable technology-centric debacle.