They hung around in post offices and job centres videoing people interacting with government services, they carried out surveys on the street asking people about the different forms they needed to fill in, they watched people use both paper services and online ones so as to understand what did and didn’t work, there was much angst over why the tax credits forms said on the last page (and in very small print) “also available in large font”, they built tables of what services were used and by who and figured out which services were the most complicated and needed to be joined up, they counted transactions across the whole of central and local government looking for services to take online that would have the most impact...
... and they stitched together technology in an attempt to deliver on a promise that government should be online and joined up, they wrote an entire web site delivery platform from scratch integrating existing search engines and databases, they made sure the engine rendered on mobile devices and, yes, tablets as well as every possible browser the world had ever seen, their deliveries were rapid and iterative and user testing was prevalent throughout with videoed sessions with users (pulled from the street) working with the site (leading to yet more iterative deliveries), they released beta test versions for the public and watched what happened...
... they were a mixed team of civil servants (many borrowed from right across government), contractors and supplier staff, they walked the floor of government in casual gear using macs alongside a restricted network and with all types of the latest smartphones in use, they owned the government's approach to online identity and worked with all of government to deliver authenticated transactions, and they supported the rest of government in their efforts to get services online as well as to recover things that hadn't gone so well …
... and they relentlessly published facts and figures of what they were doing whilst secreting themselves in a building far away from the madding crowds of the rest of Whitehall … and created a single website for all of government that could be accessed from the URL www.gov.uk.
Who am I talking about?
GDS 2012?
No, e-Delivery team 2001-2005.
 |
| June 2001 |
We embarked on a similar journey then as the one GDS is on now, though we were under the watchful eye of the e-Envoy (and then the head of the e-Government Unit) rather than the Executive Director, Digital. We too inherited an existing site - ukonline.gov.uk - that didn't quite do what the vision (outlined some years before in a paper called me.gov) had proposed. We set ourselves the grand aim of transforming the users’ experience of government - yes, a huge focus on the citizen - into something that truly represented 100% online and joined up. A dozen years ago this was all going on before the words agile, digital by default, user experience and easier
done than said were coined. After all, we put men on the moon before any of those words were used so I can’t say that we were breaking even a little bit of new ground.
Watching GDS from afar, it is hard not to see the similarities, but much harder to see the differences. Perhaps that’s because I am at a distance. We achieved a lot in a short space of time, whether measured in government cycles or geological ages (which are often much the same). GDS too, appear to be achieving a lot, though separating smoke and mirrors from reality is difficult for an outsider.
We got a lot right - and much of what was done then is still running and is still referred to in government documents published during the Coalition’s term as the best examples of delivery - but we also got a lot wrong. I'd like to think it balanced out to the positive, but others will be better judges of that than I am.
I was never sure, back then, whether I was the Emperor and everyone else was really unable to see the wonder that lay before them or whether I really didn’t have any clothes on.
I am fascinated by what I see in GDS now - the diverse people, the agile approach, the focus on delivery, the excitement, the enthusiasm, the arrogance (well, the hubris really) and also the sense (wrapped up in that arrogance) that this is all new and that those who went before are not worth listening to.
Government is crying out for change. Change needs new ideas, new people and new ways to execute. This kind of change is very hard to get rolling and many times harder than that to sustain. I watch, then, with fascination wondering if this is change that will stick and, especially, if it is change that will pervade across government. Or whether its half-life is actually quite short - that when the difficult stuff comes along (as well as the routine, mind-numbing stuff), things will stall. Perhaps the departments will rebel, or the sponsors will move on, or delivery will be undermined by some cockups, or the team will tire of bureaucracy once they move into the transaction domain.
If GDS now is much like eDt then, and with the launch of the new gov.uk website only hours away, I wanted to think through some of the issues that need to be addressed.
Are You Just Too Different?
Different is good in some ways. It creates a shared identity amongst those who are in the new team - they consciously step away from the constraints and limitations of the old ways of doing things. They cast aside contracts, process, bureaucracy, legacy IT, dress codes and whatever else they need to do to get things done. Meanwhile those who aren't part of the new club look in, some jealously very much wanting to be part of it and some expectantly, waiting for the seemingly inevitable failure - the egg on the
face, the fall from the ivory tower, the crash and the prolonged burn. I suspect
the camps are pretty evenly split right now, with everything to play for.
 |
| July 2000 |
The question is really how to turn what GDS do into the way everyone else does it. In parallel with GDS’ agile implementations, departments are out procuring their next "generation" of IT services - and when you consider that most are still running desktop operating systems released in 2000 and that many are working with big suppliers wrapped up in old contracts supporting applications that often saw the light of day in the 80s or, at best, the 90s, “generation” takes on a new meaning. To those people, agile, iterative, user experience focused services are things they see when they go home and check Facebook, use Twitter or Dropbox or have their files automagically backed up into the cloud. Splitting procurements into towers, bringing in new kinds of integrators, promising not to reward "bad" suppliers and landing new frameworks by the dozen is also different of course, but not enough to bridge the gap between legacy and no legacy.
I am on the record elsewhere as noting that, today, GDS is an aberration, not the new normal. Becoming the new normal is a massive, sustained job – and one that needs a path laid out so that everyone gets it. Some will take what I say below as an attack on GDS; that's far from what it is, it's an attempt to look ahead and see what is coming that will trip it up and so allow action to be taken to avoid the trouble.
The Absence of Roadmap
One of the strengths of the approach that GDS is adopting is that the roadmap is weeks or maybe months long. That means that as new things come along they can be embraced and adopted - think what would have happened if a contract for a new site had been let three months before the iPhone came out? Or a month before the iPad came out?
It is, though, also a significant weakness. Departments plan their spending at least a year out and often further; they let contracts that run for longer than that. If there is – as GDS are suggesting – to be a consolidation of central government websites by April 2013 and then all websites (including those belonging to Arm’s Length Bodies) by April 2014 then there needs to be a very clear plan for how that will be achieved so that everyone can line up the resource. Likewise, if transactions are to be put online in new, re-engineered ways (from policy through to user interaction), that too will take extensive planning.
Having a roadmap that shows, even roughly, what is planned and when is one way to bring departments towards you rather than have them wait to be told. The digital strategies that are due out around the end of the year look, so far, too vague to count as a roadmap. They contain aspirations rather than commitments and look a lot like what we saw in 2001.
Beware The Hockey Stick
In 2001, we looked at departmental plans for achieving the Prime Minister’s stated aim of 100% of government services online by 2005. What we saw, perhaps obviously in hindsight, was a very high proportion of services magically appearing online in the last quarter of 2005 – a hockey stick shaped graph. It feels like we are heading that way again. It’s not clear how things will be done in the new way (who will pay, what will need to be done, how will it be contracted, what’s the sequence etc) so departments are hedging and putting things out, quite conveniently I imagine, to around the time of the next election.
Can You Do It Yourself?
GDS have taken what is, in my view, a brave decision to do the bulk (if not all) of the work in-house - it is, in many ways, an approach that is entirely inconsistent with everything that the government preaches elsewhere, in IT and business. As a result not only am I unclear what problem they are solving, but I’m also wondering whether they are solving the wrong problem the wrong way.
It is, though, an interesting bet. In five years, is it likely that the same model will be in place?
In 2001 we formed a small team of folks skilled in business and technical architecture, project delivery and commercial/finance/procurement. We wrote no code ourselves (not for production at least - we had a team that worked on proof of concept ideas that tested out what we might get others to do). We believed that code writing was one of the many things that government outsourced.
We contracted with various suppliers to do the work - the supply chain for the government gateway (often described as built by Microsoft) involved, for instance, over 40 UK-owned small businesses. We consciously did this because government - and especially the Cabinet Office - had little desire to maintain a substantial delivery team in house after it had spent the last decade outsourcing it. We created an intelligent customer that represented the whole and not just the single parts of the government.
We chose that model because we believed that building a team for the long term is very difficult, especially within the constraints of the civil service. We also believed that suppliers, over the long term, would outperform us because they would bring in new talent, train staff and keep them focused on the task. If one person, or one supplier, didn't work out, there'd be another one behind that one, and another one and another one. Quite different from the civil service model that makes hiring difficult (especially in this fiscal environment) and exiting staff near impossible.
Sustained Sponsorship
There is no doubt that Francis Maude is a key driver, perhaps even the key driver, of the change agenda across government, particularly in ICT. I’m told, frequently, that when issues with departments arise, Mr Maude is briefed and he handles the issue in a bi-lateral with the relevant departmental minister and progress is then unlocked. That is certainly a big help – though I suspect some departments are readying their rebellious faces whether or not Mr Maude moves to be Government Chief Whip.
Being closely associated with a political sponsor is, to my mind, quite new for those involved at the sharp end of technology delivery. I expect Ministers to champion policies – where would Universal Credit be without the sustained sponsorship of Ian Duncan Smith (and, conversely, where will NHS reform go now that Andrew Lansley has moved on). But to see such close involvement from Ministers (ok, from one Minister) in website reform and the technology choices that underpin that is fascinating and potentially dangerous for GDS.
During the time of the e-Envoy we had four Ministers and, if you add in eGU, nine. I suspect that my experience of the Cabinet Office is more common than the current experience where there has been stability for the last 2 ½ years. GDS will need a plan B if Mr Maude does move on to something new. There will also need to be a 2015 plan B if power changes hands. Of course, if your roadmap goes out only weeks or months, then no one is looking at 2015. That’s a mistake.
What’s The Model, Really?
Any delivery model can be made to work and, of course, any delivery model can be done badly. Picking a model is necessary but it’s not the only part of success. How that model gets optimal impact needs to be understood along with how it will evolve.
eDt felt that they were in the wrong place notwithstanding outstanding support from our sponsors. We were in a policy department with no reputation or desire to own delivery. Indeed, the Cabinet Office had acquired this very team by accident after bidding for, and winning, some money from HMT which was then supplemented by further funds from the Inland Revenue). Over a couple of years, we explored all of the available options then - trading funds, agency status, spin off, joint ventures with the private sector - but, in the end, the team was folded into a big department, the DWP, and there ended government's flirtation with a very different approach for delivering services across the whole of government. Until, of course, somewhat unexpectedly, some of it returned to the Cabinet Office. It truly is a funny world.
Cabinet Office has, then, acquired GDS by accident. History repeats. Chris Chant landed in the somewhat foundering G-Cloud programme, arranged for a lot of Macs to replace some ageing and expensive PCs and, somewhere along the way, fired up a programme to replace direct.gov.uk and achieve massive cost savings and so was born alpha.gov.uk. Not a lot of people know that I think.
It would be a shame for history to continue to repeat. If gov.uk and everything that underpins it from a delivery approach is to survive 5 years, let alone 10 years there needs to be thinking about how this will work. I’ve said on this blog before that I believe the right answer may be a spin-off of GDS or a mutual so that it can get access to capital, bid for work and fully reflect its costs. There are other choices; what’s important is to look at them and lay the ground work for making a choice and achieving it.
Transparency Of Everything
The GDS approach looks similar to a startup backed by a venture capitalist prepared to lose everything if the bet doesn't work out (and who was anyway backing multiple other horses running the same and similar races). The VC in this case is UK government.
GDS have succeeded in being wildly transparent about their technology choices and thinking. They are not, though, transparent about their finances. That should change. The close association with politicians seems to mean that GDS must champion everything that they do as a cost save – witness recent stories on identity procurement costs, website costs comparing direct.gov.uk and gov.uk and so on.
Comparative costs need to be properly comparative, not presented only in the best possible light. Use fully loaded costs (that is, costs including items such as accommodation, pensions, employer NI contributions and so on, all of which would be included were the numbers like for like with a supplier cost). Let’s see the numbers.
Given the inhouse staffing model that GDS is operating, changes are really represented only by cost of opportunity. That makes comparing options and, particularly, benefits difficult. In a beta world, you make more changes than you do in a production world – once you’re in production, you’re likely to make incremental changes than major ones (because, as Marc Andreessen said long ago, interfaces freeze early – people get used to them and are confused by too big a change).
It is important to know what "done" is - and not to claim that done is never done because there are always new things to do. The budget for "done" needs to be known - so that variances to that status are clear, so that opportunities can be embraced are understood in the context of scope done and cost done.
In this agile world, done is never done; there is always another iteration to deliver. In government IT as a whole, done is never done too - requirements change, new transactions appear new devices come into play and others fade away.
The important thing is to be clear what is going to be delivered in return for X million pounds so that the consequences of that can be measured – a gambler (that is, the government when acting as a VC) only backs a horse that keeps running races and that wins more than it loses.
It’s Transactions That Are Important
GDS' most public delivery is "just another website” - those who know (and care) about these things think that it might be one of the sexiest and best websites ever developed, certainly in the government world. But it isn't Facebook, it isn't iTunes, it isn't Pirate Bay. It's a government website; perhaps “the” government website. Once you've packaged a lot of content, made wonderful navigation, transformed search, you end up with the place where government spends the real money - transactions (and I don't just mean in IT terms).
Back when I published graphs on how many websites government had, I guessed that there was an easy £250m spent on front ends each year. The figure spent on transactions is many times that - probably ten or even a hundred times that, especially if you add in the cost of fraud, error, debt, call centres, support and so on. That's also where the legacy applications are - and all of the legacy processes that are tied up in complex outsourcing agreements that were written a few years ago and certainly
don't mention agile, iterative or quick. Worse, many of those very same contracts are being replaced this year and next year - and the signs so far are that the contracts will look much the same; though they will be shorter duration and smaller in value (because of the split into towers). They’re not being replaced with the thought that transactions will be fundamentally different and that the user experience will be at the forefront.
 |
| September 2001 |
In building the Government Gateway, we came up against the back end legacy systems. Once you are integrating to those, the complex dance between interlocking systems governs your speed of process - you can change this one here, but that one needs to change at the same time, or you can change this end, but not that end. Change control, version control, security, data protection and all kinds of other constraints become the norm. There's a reason that 10 years on the Gateway is still in place, operating much as it did on day one - it's because it has integrated very well into the engines that drive government transactions as well as the dozens of third party products who talk to it when they talk to government - and when they need to change, it needs to be for a good reason that benefits the customer as well as the supplier of the third party product; most are not in it for charity.
Soon GDS will tell departments that their top transactions need to be re-engineered from policy through to service provision with a clear focus on the user. At that point we move away from the technologists who are attracted to shiny new things and we hit the policy makers who are operating in a different world – they worry about local and EU legislation, about balancing the needs of vastly differing communities of stakeholders and, of course, they like to write long and complicated documents to explain their position having evaluated the range of possible options.
Tackling transaction is both fundamentally necessary and incredibly hard, though most of that isn’t about the shiny front end – it’s about the policy, the process and the integration with existing back end systems (which absorb some 65% of the £12-16bn spent per year on IT in government). There is a sense of “Abandon Hope All Ye Who Enter Here.”
It’s more than ten years since a single website for government was proposed (I know, I was the one who proposed it and wrote it up); it was an idea that was successively endorsed in various reports and strategies. In a couple of years it may even be a reality. There isn’t, though, a vision, let alone an action plan, for how transactions will be delivered – where will they be hosted, how will they integrate with identity providers (and how will the government gateway be retired), how will personal data be managed, how will pre-population take place, what will be done with the transactions that are already out there and working (some with take up of 80% or more).
There is also no proposal for how local government will be integrated into this offering, though many of the transactions undertaken by the average citizen are at a local level (and still with “government” rather than “central government”).
Beyond that, there isn’t a vision for how the need for some transactions will be removed entirely – why should I apply for a tax disc for my car, why isn’t personal tax handled automatically and so on. That would be truly transformational - until we do that, we are persisting two centuries or more (in only some cases admittedly) of process.
 |
| July 2002 |
All of that needs to be laid out – I’ll take bite-sized chunks for now but it needs to be thought through to avoid dead ends.
Reliability, Resilience, Testing, Process, Bureaucracy
When gov.uk turns on - and direct.gov.uk turns off after 8 years of operation it will be different, better, faster, smoother, have nicer fonts, easier search and a thousand more things.
When a site needs to cater for 30m visitors a month and not just a few thousand beta testers who are interested in the technology, the presentation and what’s new on the web, then a new kind of discipline appears. Breaking such a site is a bad idea – it will make news, cause disruption and make life harder.
From tomorrow, a new kind of operational rigour is inevitable. The live site can’t break. It can’t be taken down for a few hours for an upgrade or a database refresh. As transactions are made available, that pressure only increases. Suddenly there are complex windows when services absolutely must be available; freeze dates take over from the previous free-wheeling approaches and lots of people need to be involved to ensure that the end to end process – from the shiny new front end all the way to the ugly, old, legacy back end – works.
It will be interesting how the worlds of agile and operational rigour collide. Things can slow down quite dramatically as regression tests are run and re-run and fixes
are made and then tested again (and not just at the front end, but across the entire delivery chain from new to old). It’s all part of the evolution process but I suspect it will come as a shock to some on the team.
The Vision and the Roadmap
In their seminal article, "the importance of being agile", GDS quote Louis Gerstner (of IBM) who said "the last thing [we] need right now is a vision". I'm making that up but it feels like it could be true.
The first thing the rest of government needs - and is looking for - is a sense of how does this all work in the future. What does it look like and feel like when government has only one (or a few) website(s); how will transactions work when identity is provided from a market of potentially many suppliers; when will sites and services close down; how will service levels work across government; who will pay for what when transactions are put on gov.uk; how will transition from one model to the next work and so on. A million questions, some of which could do with being answered now so that plans can be made.
eDt tried very hard to paint a picture of how we thought it would play out. We got it wrong on almost every count. Progress was neither as rapid nor as far reaching as we expected. Services that we thought would do very well - secure email to support exchange of personal information, payments to government, or SMS services for notifications - didn't do anything like the volume that we expected.
eDt was around in an environment where there were almost no fiscal constraints. Bidding for money was certainly a lengthy process but if you put together a compelling case, you had a good chance of being allocated funding. The Treasury soon got fed up with being hoodwinked by departments who promised huge savings yet didn’t deliver on them and tightened the controls. Today, though, it’s a different world. There
isn’t any money, there aren’t many people (and there are progressively fewer)
and so making a case for investing to save further money will see scrutiny
unlike any time before now. Does the lack of money and the lack of capacity mean, though, that much of this won’t be, or can’t be done? And if it does, how will that be resolved?
Wrap Up
What is happening now has the air of a great science experiment - ironically, that's what GDS call some of the work that they do internally as they test out concepts. Such experiments can go bang of course. Sometimes, or at least once if scientists are right, there is a big bang. That's largely inconsistent with a government approach where requirements are mapped out and delivered over a period of years, fulfilling policy objectives as they are ticked off.
Of course, the historic approach has not worked out so well - we only need look at NHS IT, ID cards, Fire Control and so on to see that a new model is needed.
The question is whether the GDS model is the one that achieves scale transformation right across government, or whether it is another iteration in a series of waves of change that, in the end, only create local change, rather than truly structural change.
It seems unlikely that GDS can scale to take on even a reasonable chunk of government service delivery. It also seems unlikely that enough people in
departments can be trained in the new approaches to the point where they can
shoulder enough of the burden so as to allow GDS to only steer the ship. If we add in the commercial controls, the supply chain and the complexity of policy (and the lack of join up of those policies), the challenges look insurmountable.
None of that is an argument for not trying. Direct.gov.uk is old and tired and needed a
massive refresh; transactions are where the real potential can be unlocked and they need to be tackled in a new way. Much of this has been tried before, painful lessons have been learned and it would be more than a shame if the latest effort didn’t achieve its aims too. The trick, then, is to pick the battles to fight and create the change in the right areas with the aim of infecting others. Taking on too much at once will likely lead to failure.
Perhaps GDS is the new emperor and I am the little boy, or perhaps it is the other way round.
Fingers crossed for tomorrow’s launch of gov.uk then. A successful launch will be a
massive boost. Great feedback from consumers would help create a rolling wave of change that would be sustained by successive iterations of high quality transaction delivery. That would be a very good place to be. It would, though, only be the start.
