Eight Years On From GDS …

… and what have we accomplished?

I wrote about Martha Lane Fox’s report on the future of e-government (shortly thereafter to become digital government, though Martha referred to it all as “government online services”) in November 2010.  The recommendations were not particularly new but they were tightly focused and provided the impetus to set up GDS and give it a power that had previously not been available to either a Cabinet Office technology-led function or, I think, any other cross-government technology-led team.

Handily, the EU have published their “Digital Economy and Society Index 2019“, and there’s a specific report on the UK.  Perhaps the last one of these that we will see.  The upside of that is that we may be top of the table in the next one that we self-publish, if only because it will be a table of one.

What, then, have we accomplished?  I’m afraid it doesn’t make for good reading.

We rank 11th overall in the EU.  The authors kindly say that this is “showing a somewhat above average performance.”  I take that to mean that given there are 27 member states, we are just above the mid-point.  If you were to measure performance by GDP, or by capital invested, or by expectation of position, I’m quite sure that this is a well below average performance.

It gets worse.  We are 18th for online service completion and a woeful 27th for pre-filled forms.  Put to one side the idea that “forms” are still the vernacular more than 20 years after we started down the online path.

Our best ranking, by far, is “digital public services for businesses” – I may be biased but I would put that down to the original work by HMRC as far back as 2001 followed up by good work by Companies House (which chose to do things their own way but nevertheless did a very good job – far above average one might say).  It is perhaps interesting to note that GDS has never paid much attention to business transactions – Verify ignores businesses (in the too hard box), the work with RPA around payments to farmers was abandoned after a disastrous launch etc.  And yet there we are in 2nd place.

Who’s first?

Estonia I hear you cry.

Would be a good guess.  They’re 2nd.  Finland is first.

Estonia is let down by open data (where they are 25th); Finland is let down by digital public services for businesses (16th) and open data (19th).

There are some lessons to learn here.  Trouble is we just never seem to learn them.

10 Years After 10 Years After

Strictly speaking, this is a little more than 10 years after the 10 year mark.  In late 2005,  Public Sector Forums asked me to do a review of the first 10 years of e-government; in May 2006, I published that same review on this blog.  It’s now time, I think, to look at what has happened in the 10 years (or more) since that piece, reviewing, particularly, digital government as opposed to e-government.

Here’s a quick recap of the original “10 years of e-government” piece, pulling out the key points from each of the posts that made up the full piece:

Part 1 – Let’s get it all online

At the Labour Party conference in 1997, the Prime Minister had announced his plans for ‘simple government’ with a short paragraph in his first conference speech since taking charge of the country: 
“We will publish a White Paper in the new year for what we call Simple Government, to cut the bureaucracy of Government and improve its service. We are setting a target that within five years, one quarter of dealings with Government can be done by a member of the public electronically through their television, telephone or computer.”
Some time later he went further:
“I am determined that Government should play its part, so I am bringing forward our target for getting all Government services online, from 2008 to 2005”

It’s easy to pick holes with a strategy (or perhaps the absence of one) that’s resulted in more than 4,000 individual websites, dozens of inconsistent and incompatible services and a level of take-up that, for the most popular services, is perhaps 25% at best.
After all, in a world where most people have 10-12 sites they visit regularly, it’s unlikely even one of those would be a government site – most interactions with government are, at best, annual and so there’s little incentive to store a list of government sites you might visit. As the count of government websites rose inexorably – from 1,600 in mid-2002 to 2,500 a year later and nearly 4,000 by mid-2005 – citizen interest in all but a few moved in the opposite direction.
Over 80% of the cost of any given website was spent on technology – content management tools, web server software, servers themselves – as technology buyers and their business unit partners became easy pickings for salesmen with 2 car families to support. Too often, design meant flashy graphics, complicated pages, too much information on a page and confusing navigation. 
Accessibility meant, simply, the site wasn’t.
In short, services were supply-led by the government, not demand-led by the consumer. But where was the demand? Was the demand even there? Should it be up to the citizen to scream for the services they want and, if they did, would they – as Henry Ford claimed before producing the Model T – just want ‘faster horses’, or more of the same they’d always had performed a little quicker? 
We have government for government, not government for the citizen. With so many services available, you’d perhaps think that usage should be higher. Early on, the argument was often made (I believe I made it too) that it wasn’t worth going online just to do one service – the overhead was too high – and that we needed to have a full range of services on offer – ones that could be used weekly and monthly as well as annually. That way, people would get used to dealing online with government and we’d have a shot at passing the ‘neighbour test’ (i.e. no service will get truly high usage until people are willing to tell their neighbour that they used, say, ‘that new tax credits service online’ and got their money in 4 days flat, encouraging their friends to do likewise).
A new plan
 • Rationalise massively the number of government websites. In a 2002 April Fool email sent widely around government, I announced the e-Envoy’s department had seized control of government’s domain name registry and routed all website URLs to UKonline.gov.uk and was in the process of moving all content to that same site. Many people reading the mail a few days later applauded the initiative. Something similar is needed. The only reason to have a website is if someone else isn’t already doing it. Even if someone isn’t, there’s rarely a need for a new site and a new brand for every new idea.
• Engage forcefully with the private sector. The banks, building societies, pension and insurance companies need to tie their services into those offered by government. Want a pension forecast? Why go to government – what you really want to know is how much will you need to live on when you’re 65 (67?) and how you’ll put that much money away in time. Government can’t and won’t tell you that. Similarly, authentication services need to be provided that can be used across both public and private sectors – speeding the registration process in either direction. With Tesco more trusted than government, why shouldn’t it work this way? The Government Gateway, with over 7 million registered users, has much to offer the private sector – and they, in turn, could accelerate the usage of hardware tokens for authentication (to rid us of the problems of phishing) and so on.
• Open up every service. The folks at my society, public whip and theyworkforyou.com have shown what can be done by a small, dedicated (in the sense of passionate) team. No-one should ever need to visit the absurdly difficult to use Hansard site when it’s much easier through the services these folks have created. Incentives for small third parties to offer services should be created.
• Build services based on what people need to do. We know every year there are some 38 million tax discs issued for cars and that nearly everyone shows up at a post office with a tax disc, insurance form and MOT. For years, people in government have been talking about insurance companies issuing discs – but it still hasn’t happened. Bring together disparate services that have the same basic data requirements – tax credits and child benefit, housing benefit and council tax benefit etc.
• Increase the use of intermediaries. For the 45% of people who aren’t using the Internet and aren’t likely to any time soon, web-enabled services are so much hocus pocus. There needs to be a drive to take services to where people use them. Andrew Pinder, the former e-Envoy, used to talk about kiosks in pubs. He may have been speaking half in jest, but he probably wasn’t wrong. If that’s where people in a small village in Shropshire are to be found (and with Post Offices diminishing, it’s probably the only place to get access to the locals), that’s where the services need to be available. Government needs to be in the wholesale market if it’s to be efficient – there are far smarter, more fleet of foot retail providers that can deliver the individual transactions.
• Clean up the data. One of the reasons why government is probably afraid to join up services is that they know the data held on any given citizen is wildly out of date or just plain wrong. Joining up services would expose this. When I first took the business plan for the Government Gateway to a minister outside the Cabinet Office, this problem was quickly identified and seen as a huge impediment to progress

More to come.

Performance Dashboard July 2003 – The Steep Hill of Adoption

With gov.uk’s Verify appearing on the Performance Dashboard for the first time, I was taken all the way back to the early 2000s when we published our own dashboards for the Government Gateway, Direct.gov.uk and our other services.  Here’s one from July 2003 – there must have been earlier ones but I don’t have them to hand:

This is the graph that particularly resonated:

With the equivalent from back then being:

After 4 years of effort on the Identity programme (now called Verify), the figures present pretty dismal reading – low usage, low ability to authenticate first time, low number of services using it – but, you know what, the data is right there to see for everyone and it’s plain that no one is going to give up on this so gradually the issues will be sorted, people will authenticate more easily and more services will be added.    It’s a very steep hill to climb though.

We started the Gateway with just the Inland Revenue, HM Customs and MAFF (all department names that have long since fallen away)- and adding more was a long and painful process.  So I feel for the Verify team – I wouldn’t have approached things the way they are but it’s for each iteration to pick its path.  There were, though, plenty of lessons to learn that would have made things easier.

There is, though, a big hill to climb for Verify.  Will be interesting to watch.

The Power Of One

It’s a long time – ten years – since I first put this slide on a screen:

DWP Conference 30th January 2003

In later iterations, I modified it a little:

Dan Jellinek Transforming Government Conference 13th May 2004

And sometimes I added this slide to try and emphasise the point:

Also Dan Jellinek Conference

And just to make it clear it was about the citizen (the user in today’s words):

13th May 2004

There was also a post, “There Can Be Only One”, in July 2004 showing that the debate about how many sites were needed was still in full flow.

At the same time, I was able to show that thinking in action:

BITS Conference 13th May 2004

I remember only too well how we took the sprawling content on the Department of Health’s then site, http://www.doh.gov.uk and turned it into something with a far greater consistency and user focus on a new site, http://www.dh.gov.uk.  So when I read a post on the GDS blog from Alice Ainsworth who was doing it all over again, 9 years on, I knew where her head was at.  DH has now moved 4 times in ten years – from the original platform to DotP, to Stellent, to WordPress and now to gov.uk.  Let’s hope that there are not as many moves over the next ten.

It’s impressive to see the figures that GDS’ “Inside Government” team report:

18 out of 24 …

This has been a long journey.  Long, in fact, doesn’t even describe it – as Gerry Gavigan’s neatly summarised steps show (and, as others, including Jerry Fishenden, have also shown in the past).

Ten year, or more, then, to crack the problem of delivering a single, comprehensive site covering all of government – ok, there are some stragglers to come on board in the centre and the job of taking on the agencies and NDPBs is massive and only just starting.  But certainly more progress in the last year than in the previous ten.  It’s an impressive job, no question.

Shaping the transactions so that they make sense to the user … delivering the green line’s upward slope in my original slide … how long for that now?

Is Agile Going To Be Beta?

The blog post announcing the formal launch of the Government Digital Service closed with this paragraph:

Next year we look forward to a faster pace for delivery. While our roadmap is not finalised, and indeed will never be given the agility to which we aspire, we can look forward to some major releases.  

Since reading it I’ve been wrestling with what I think of the approach that GDS is taking. Several times (at least) I’ve decided that I agree with it; several other times I’ve thought it wrong – the issue I’m debating stays the same and, that is, whether it’s wrong or right for government to build a team in-house to design, develop, deliver and operate a system.

The early deliveries from GDS are interesting markers but not definitive about capability – e-petitions was fast and did what it was supposed to (but there was already a perfectly adequate solution in place; replacing it doesn’t seem to have achieved anything new); alpha.gov looked nice and stirred up some interesting debates (accessibility, IE6 and so on) which needed to be had (I’m looking forward to the debate on whether Welsh will be supported and at what cost) but, to the casual viewer, it was just a website (to the techs i spoke to, it was just a custom-built website and many wondered why anyone had bothered to build from scratch again); and the identity programme has been relaunched (early days yet but my fingers are firmly crossed).  It’s good and right that if you’re going to try a new approach you don’t take on something big for your first deliver of course.

The thing that I debate is whether, in an environment where the strategy is reuse, commercial products, British SMEs and frameworks like gCloud (plus PSN and others), should part of government be building a team who will deliver a website that will be the view that almost the entire population has of government online?

An argument for doing it this way might be that the single domain game plan is so different from what the market already has that custom building is the only option. That would, indeed, be the argument that I used in 2002 when we built a new platform for direct.gov the first time round.  We took a different approach then – we built a team to architect the strategy and then we partnered with commercial companies to design, deliver and support the site.  That didn’t mean that I didn’t get called at 3am if there was a problem, but it did mean that I wasn’t the first person to be called (the suppliers own escalation chain made sure I was called when it was necessary).   We ended up having to build a substantial service management wrapper around our suppliers though – some cared more than others for customers, some cared more than others about paying away service credits and some didn’t seem to care for one or the other.

Ultimately, we had top designers/architects on the team and a world-class service management team – and our suppliers fielded top class people in the design and architecture space too.  But we didn’t have a team coding, building user interfaces, handling style sheets, deploying code on servers, thinking about performanace optimisation, worrying about how much RAM was needed on a server or whether we had enough disk space allocated and so on. We did, for quite a while, have a great team building trial versions of applications that we thought might be useful in the future, but everything that went into production was built and managed by suppliers under contract.

Our contracts were not of the traditional “come up with all the requirements, fix the price and wait for it all to go wrong” variety – we managed our projects in tight phases with agreed deliverables (and agreed assumptions) and we built in flexibility to change direction if an assumption proved wrong or if we needed to trade features coming up to a deadline.  In an early 2000s sort of way, that was probably agile or something like it.

GDS, of course, are huge proponents of the Agile process.  Having your own team isn’t a pre-requisite of being agile but it probably makes it easier – if you can switch direction and take your team with you without thinking about deliverables in a contract you can probably move faster (of course, if you have to switch direction too often, you probably should spend more time up front thinking about what it is that you want to get done first).  Brent Hoberman at Lastminute told me once, whilst he was still running the show there, that he revelled in his ability to walk out onto the floor and have the developers change something – if the sales numbers had dropped, for instance, and he needed to raise the profile of a particular promotion.   You can, of course, do the same with a team provided by a supplier – a lot depends on how you structure the contract and how much resource you have available for “pool” work or support work.

What happens, I wonder, when the site is live (I was going to write “done” but I realise that the paragraph I highlighted from the GDS blog suggests that “done” is going to be all too subjective”)?  Does GDS scale down its team and maintain a small dev/fix team and keep service management in-house?  Does it move the operation to a supplier (transitioning live code developed by one team to another team can be very challenging – especially if the documentation and comments are less than complete)? Does it keep the team large because, actually, it’s true that a site as vast as this can’t ever actually be done and there will always be new features to add, things to tweak or things to replace because they don’t quite work how it was all imagined?

In the 1990s, government started outsourcing its IT.  I’d like to think, had I been there at the time, that I would have argued for keeping it in-house and for outsourcing the handling of all of the paper processing (a set of processes with a low rate of change that cried out for being made more efficient – and that could have been made so with better control of the IT).   Since then, almost every central government department and something like 40% of local authorities, have moved their IT to an outside supplier. They made that choice for a variety of reasons – some would have looked at their own organisation and decided it was too small to operate at an efficient price, some would have found suppliers able to stay up to date with new technology, others would have looked at what everyone else was doing and copied them, some would have wondered how to build a career structure for a role that increasingly looked like a dead end within their own organisation and so on.

So is the GDS strategy a reversal of 20 years of outsourcing?  It is it a one-off aberration that will stand or fall based on the management team in place today?  Is it an experiment that could lead to new approaches right across government in certain niche areas?  Is it an attempt to do something new and the only way do to that was to build a team and, when it’s not new, the team will eventually disband?  Is it a spot of empire-building? I simply don’t know.

The degree of transparency that GDS have opened up about their development process (and the debates therein) is very much to be applauded.  No government team has said quite so much about what they are up to as this one, I’m sure.

I’d like, then, to see the same transparency about what the roadmap (incomplete as it may be) looks like – when does alpha move to beta, when does beta move to production (indeed, is beta going to be production itself), when will the service move to a UK host and to which one, what happens to service management?  What will the team look like in six months, a year, two years? Sometimes the broadcasts need to step out of the weeds and show us the whole landscape so that we can appreciate the true majesty.

I’ll see you your 50 year storm …

… and raise you a Perfect Storm says Mike Bracken.  I do like the continuity of analogy around storms.  GDS is certainly operating within a favourable environment with a wide range of factors aligned.  Now is the time.

He goes on to say:

as one of our new recruits Mike Beaven, who is running our transformation programme put it more succinctly: “How often do you get the chance to digitise a G7 economy?”

The answer to that depends on whether this effort succeeds, building on the progress made by all previous efforts.  If it does, the team may get hired to do the other 6.  If not, it might be “How often do you get to balkanise the digitals?”

AlphaBeta.gov …

Is what Alpha.gov.uk (and the soon to be beta.gov.uk) are doing really different? I mean, it’s a website, right?  We’ve had a few of those before, more than a few (thousand) in fact.  As someone who used to do, in the Office of the e-Envoy, what the Government Digital Service (GDS) team (formerly the alphagov team) are doing, I watch their progress with interest, applauding the successes and wondering about the things still to do, occasionally scratching my head.

I was part of a team a lot like the GDS team.  We had a bunch of hugely talented people drawn from inside and outside of government (plus quite a few secondees from major technology companies too); we published a lot of what we were doing; we took on some difficult projects (some right at the very edge of what was going on in industry let alone in government); we worked hard to draw other departments in (we often had to pitch for them to use what we were doing during a competitive tender process;  we used open source products; we did work for other departments who commissioned us to build things; we put in place things that, 10 years on, are still in place now and drawing ever greater usage; we built things from scratch, used beta products, and integrated some complex stacks; we even used the first cloud service in government in 2001 when we paid by usage and didn’t own any assets; we worked across government to write and edit content; we dealt with accessibility from day one with the aim of creating the most accessible sites; we tried to lead the way in doing things in a different way; we, too, dealt with the long tail of the vast range of services that government offers; we did things, like MessageLabs anti-virus, that weren’t strictly in our remit but felt like the right thing to do; we lived and breathed our services, taking it personally if there were problems or if customer were not happy.

eDt vision, September 2001

So are GDS all that different? My sense is that they are, and they aren’t.  They’re doing what we did, and more, and better.  And they have some things to work on – based on current progress, I’m pretty confident that they’ll sort those out too.

The team – there is a greater focus on people already inside government.  In 2001 we tried hard to recruit civil servants into the team but often failed to attract many (or, indeed, any).  The Cabinet Office wasn’t seen as the place to do what we were trying to do; it wasn’t a delivery department.  We had some great civil servants for sure, but not enough to make them the core of the team.  The GDS folks, and the Alpha team in particular, have attracted some terrific people into the team, even converting some outsiders into insiders along the way.

The process – this is open government in action.  From 2000-2005 we published almost everything we did, but almost always to those inside government.  We were amongst the first (and probably actually the first) to make available every detail of the volumes, the service delivered, the product roadmap and so on; the team often spoke at conferences but the audiences were mostly other government people (and the larger suppliers). GDS are publishing pretty much everything they do, including decompositions of decisions made (particularly the ones that have attracted criticism), via blogs, twitter, the press and doubtless other routes.

The roadmap – I get the sense, and I don’t know this for sure, that the alpha team don’t know where they’re heading with each piece of work they start, and I mean that in a good way.  When we started work we had to bid for money, build requirements list, test the requirements with customers and deliver what we said we were going to deliver.  We wiggled a little as we went but we pretty much got to where we had said we were going to, for better or worse.  These guys are working in a much more iterative way, shifting left and right to work around some problems or to add in new capability.  The beta will, I hope, evidence that approach even more.

Things still to see

Alpha tied itself closely to politics – the PM and Deputy PM were pictured smiling on the front page.  The GDS blog has a banner picture of Francis Maude:

If we’d had any obvious political link there would have been a lot of trouble.  Things change, of course, but my view is that these two shouldn’t mix (and I don’t mean the PM and Deputy PM).   The public ministerial support is, though, a brilliant thing to have in your pocket.

A single great website is, of course, essential for government (I think my position on that has long since been clear).  27 million people a month visit the existing direct.gov.uk but it has remained largely untouched since I left it in 2004/5 (it’s had a technology refresh and significantly increased functionality, but it still looks and feels largely the same – that is meant as no slight to the team who have worked diligently to upgrade it and keep it fresh, just an observation that it’s still orange and looks much the same).    For instance, the screen shot on the left is from 2007, the one on the right from 2011.

But transactions are where it’s at.  We built the government gateway to support both single transactions and joined up transactions (that is, ones that would link more than one department and send each of them the relevant data.  The vast bulk of those transactions come from sites other than direct.gov; the vast bulk of direct.gov’s transactions are for Car Tax.  That all needs to change.  We didn’t ever crack it.  It needs cracking – integrated transactions, simple pan-device (and even pan-channel) authentication, pre-population of data that government already knows about you and so on.

We built tools and services for all of government to use.  Our aim was to massively reduce spend on technology by building something once that could be used by many.  It was a great aim then and it’s still a great aim.  I don’t yet see where the GDS team are going with this.  Folks in government are still building and rebuilding websites – I know of a dozen that have gone live this year alone and that’s only the ones that I know about.  As Simon Dickson has argued before, there’s a great case for a lightly centralised service supporting government entities that still need their own site. I say “lightly” because I think there’s a need for two or three competitive offers working from consistent templates with each innovating and improving as well as co-operating and sharing.

We regularly confronted the question of whether to build something ourselves or to use existing products.  With the gateway, we used a not-yet-released to market Biztalk which needed around 100,000 lines of custom code to get it to do what we wanted.  Microsoft took all that we had done (under licence) and released a new version a year or so later which did all that we needed and left us with only 8 lines of custom code.  When looking at the engine for direct.gov (and later dh.gov and several other sites), we looked at Vignette, Stellent and others but went with a custom build – that was a difficult decision and one that proved wrong in the end as the engine was subsequently scrapped and replaced by Stellent.  GDS look to be going custom again which is likely to prove interesting perhaps 2 or 3 years from now.

We also confronted the issue of how much to do in-house and how much to outsource.  We were lucky to have a great skunkworks team who could rapidly build proofs of concepts, but we went with suppliers for all of our production versions (and we hosted with them too, not having a real cloud supplier at the time – plus we were also tied in knots by the Critical National Infrastructure badge, one that we wore with pride at the time but one that, in hindsight, was plainly an albatross).  Keeping everything in-house, managing turnover of staff, staying on top of emerging developments, dealing with 24 hour support, knowing that the only people in the way of criticism is your own team etc is a tough place to be – we were there too, but we had dozens of supplier people working for us too, so at least the load was spread.

In the end, GDS will make their choices on each of these and a million more decisions.  I hope that they recognise that, whilst it may all feel new/different/special, some of what they are doing has been done before (not just during the time of the Office of the e-Envoy around but by people in the 25 years before, dating all the way back to the computerisation of major transactions like PAYE).  Lots of lessons were learned and lots more will be learned from here on.  It would be good if the ones learned again aren’t the same as the ones learned before.

We, too, made decisions that attracted flak from armchair commentators, professionals and the press.  Perhaps the largest flak resulted from choosing Microsoft to deliver the gateway (when the previous attempt had failed dismally).  Microsoft were the only company willing to step into the fray – others suggested we scale down our ambitions and make use, for instance, of Windows NT and e-mail.  That decision proved to be the right one, despite the seemingly endless flak,

Alpha and all that follows it needs to part of a long-term delivery plan, one that shows how the Government’s ICT strategy will be implemented (a document describing that is due out any day now I believe).  But it also needs to be part of a wider delivery plan that shows what will happen within and across government where the real world services will be challenged in the same way as the technology ones are being (and have been).  Technology can create a veneer of joined up capability but it can’t truly transform the services in and of itself.

I will keep watching with interest because the challenge they’re taking on is the right one to undertake and because I believe in it too.  This is a new time in government.  Maybe it’s even a new 50 year storm.