Total Pageviews

14 March 2016

10 tips for future-proofing gov.uk against mistakes it made before

GDS Logo The UK Government Digital Service (GDS) has just had a reboot.

However will it be value for money and deliver its objectives?
Will the Budget 2016 changes be implemented efficiently and effectively?
Read on to find out more.


Background

First of all, some background and context about where the Government Digital Service (GDS) came from and why it's building Gov.uk and doing it in an agile way.

In the beginning Government used to do waterfall projects. The seven stages of a waterfall project are usually as follows

System Requirement, Software Requirement, Analysis, Design, Coding, Testing, Operation
Waterfall, the original model


However after a large number of high profile expensive IT failures, the seven stages often unfortunately looked a bit more like this. It wasn't always this bad, but sometimes it did feel like this!


Perfect Plan, Wild Enthusiasm, Total Confusion, Death March, Search for the Guilty, Persecution of the Innocent, Promotion of the Incompetent
Waterfall, when it goes wrong


Add in the hugely expensive and long procurement process, the massive documentation few people actually read, the lengthy complex contracts and change control process. All in, you can see this is not one which embraces flexibility, speed, quality for the citizen and value for government. Projects were frequently late and significantly over budget. By the time the product was delivered, the requirements were out of date. This was a culture dominated by meetings and paperwork rather than working software and value for money.

There was a groundswell in support for Agile following the Agile Manifesto in 2001 and Government sought to embrace the agile movement to minimise the likelihood of more big IT failures. This led to agile values being part of the 2010 transformation of Directgov into GDS - The Government Digital Service. Agile is about following the values in the agile manifesto which are valuing

  • Individuals and interactions over processes and tools, 
  • Working software over comprehensive documentation, 
  • Customer collaboration over contract negotiation and 
  • Responding to change over following a plan.

Although there is value in the items on the right, there is more value in the items on the left.

GDS - The 2010 launch

Shortly after the Conservative / Liberal government took office in May 2010, a report was commissioned by Martha Lane Fox on the then DirectGov service and this resulted in the report revolution not evolution.  Within 6 months, alphagov had launched (May 2011). 9 months later (Feb 2012) the beta was launched and the full service went live in October 2012. It was great to meet up then with my former colleagues and commemorate the previous 8 years.  The past had achieved progress, but better progress was to yet come.


GDS - 2012 - 2016

This is what agile in government feels like sometimes.

Rocket powered snail on skateboard
Lipstick on a pig gets a new look


The government is trying really hard to be agile but is often hampered by the slow waterfall behaviours of ministers, politics and some third party suppliers. A slow body (government) trying to move quickly with a speed-up rocket being the proverbial silver bullet. This is not only potentially dangerous, but when you get there, it's still a snail. This is doing agile rather than being agile.

If Henry Ford had asked his customers what they had wanted, they would probably have said faster horses. It took one visionary, not a democratic consensus to think of the mass market car. If Steve Jobs had asked his customers what they wanted I doubt they would have come up with the iPod (ridiculed at launch) or the iPad (who would have thought of that?). Doing things right is a combination of not only understanding the market and end users but also strategic vision and being able to launch in a relevant time-scale.


What went well at GDS?

Before I look at what didn't go so well, it's important to reflect on what went well. Overall GDS has made a great start. We have:

  • A far more usable website than the one which preceded it
  • Much easier to use services
  • Cost savings
  • A standard to aim for  
  • A better way of working.

What didn't go so well and what needs to be fixed

However GDS has often been busy singing its own praises without reflecting openly on where things didn't work so that the wider sector benefits from this knowledge. In agile, you deploy early then inspect and adapt. You fail fast and when things do go wrong you move forward having not expended a fortune finding out what doesn't work. You learn about what works and what doesn't. You have retrospectives which allow an open opportunity to reflect on what works and what doesn't - these are absolutely not a blame game but instead an opportunity to learn from previous work in a productive and constructive way. The bad news is sadly not very apparent on the GDS blog, which does seem rather self-congratulatory, instead the press have been left to pick it up. Here's a selection:

  1. Users shun new digital service and full digitisation plans were withdrawn.
  2. Up to £180m in fines per year due to a botched examplar service and again here. Perhaps in future an examplar would be defined after launch and be dependent on what people think of it? How do you know it's an examplar before you build it and people use it?
  3. All the great expertise built up in GDS will not be deployed to help local government  despite this being a good idea and a local government remit being announced in March 2015.
  4. Turf wars where GDS stepped in as the "police" to fail an already successful site. Following a standard should not be at the expense of creating user dissatisfaction.
  5. Failing to meet the standards. All services must publish performance statistics.  However all the data stops in September 2014.  Where is the more recent data?
  6. GDS puts services live that don't pass. GDS prefer to call a fail a "not-pass". Here's the data of all live services including those that not-passed (failed) and went live anyway. 
  7. Some services have had an embarrassingly low number of users. Dozens of services are listed on the dashboard at less than 100 users per year. Is this really a good use of money?
  8.  £1.3Bn needs to be spent on improving HMRC's Digital IT.  How do you even begin to spend that much money in an agile project? If this is the Minimum Viable Product, then what is the full spend?
  9.  Universal jobmatch is the most used service but still looks like a 1995 horror story with usability to match and jobseekers are compelled to use it rather than better designed competitor sites. If I was looking at user needs, I'd have tackled this one early on. It's thought to be necessary to track job applications - what if applicants actually get jobs without applying? What if the job is just on LinkedIn? Why is the most used service still so appalling to use and why do I need a government gateway ID? This has been designed for civil servant needs, not end users.
  10. Sometimes it's so bad, even the BBC were calling for the site to be rolled back to 2009.
After all the issues it's now been announced that GDS admits it’s not as good as it could be. It took 4 years to find this out? That sounds like waterfall deluxe, not agile. Agile is about fail fast, not 4 years later and have a £450m budget.  Look at the site for a moment, this cost £58m in the last year. Sure it's saved money but at a cost of £58m a year?

Retrospective lesson: no one's going to be perfect, but as part of being agile you should be open and accepting about your problems early on rather than having the press do the job for you. 

Bored computer user
Stock photo models want more from GDS too!


GDS - The 2016 reboot

On 9th March 2016, a reboot was announced of GDS. Ironically, the slides are also available in PDF format which is something that we really should be doing without in the mobile age.

The aims are now

  1. provide coherent services that are easy to discover and use
  2. make government participative, open and accountable
  3. help government communicate with authority and trust
  4. make great digital and user-centred publishing easy
  5. make government content easy to re-use and build on


10 top tips to take the reboot even further

  1. Optimise government too. GDS assumes people want easy to use services. It isn't actually about services and it isn't about easy to use. The ideal service is one I don't need to use at all.  GDS needs to work with government and feedback where government itself can be simplified and a simplified government becomes a strategic objective. Government needs to simplify. Just doing it at the digital level is missing the point. Legislation is too complex. Services are too complex. Simplifying it at the digital level is not feeding back to government to optimise the root cause of the complexity.
  2. Optimise the speed of delivery. There's nothing in the objectives about being lean and fast or time to market. At the rate GDS is migrating the old directgov estate, the technology will have moved on so fast it will have overtaken what GDS is really trying to do. In the 1960s we filled in forms and sent them in. In the 1990s we filled in forms and contacted a contact centre who filled in forms. In the 2000s we filled in online forms. In the 2010s we fill in user friendly online forms. We already have the technology to say to our mobiles "hey Google, tell me my tax due to HMRC". Automated voice recognition, available now. Automated ID verification available now. No forms, no website. A computer in the background just making life easy for me. "Hey Google, tell me how much money I owe HMRC and pay it to them so it arrives on time". Isn't that a better future than a website only focus? Digital is a platform; websites are just a service on that platform for when a written interaction is necessary. GDS themselves put an alpha live, now you need to complete an alpha and an internal beta. This means you're not learning early on in service about what large numbers of users need or even if the service will be usable for them - farmers probably don't want a digital service if they don't have access to broadband for instance.
  3. Ensure there is a clear demand and this influences priority. How about users voting for what service they need most and GDS implementing it? An open backlog where we can see the pipeline of work? GDS has made a start, but ironically for an organisation oriented towards user needs not really in a way that makes sense to end users.
  4. Ensure there is genuine value for money. Don't spend money on services people don't use or which aren't cost effective.
  5. Think about the citizen first. The new GDS aims look like they were written more for government's benefit. Customer centric organisations put the customer at the centre of all they do.  When you do this, then the government will benefit from it. 
  6. Fix the worst bits first. The  pain points, such as Government Gateway ID and people not having a memorable login, for universal jobmatch need to be addressed especially as this is the main service for citizens. 
  7. Use the best tools to help people. If want to get more people using website services then provide video tutorials to help people and then let them try things out in a safe environment to practice. That way fewer people will need to call contact centres for help.
  8. Only relevant content. Please personalise Gov.uk. I live in Scotland and so I should be able to tell you this and not get content which is for England only. If I'm a Welsh speaker, prioritise content in the Welsh language as well.
  9. Truly embrace agile. Stop doing big projects with no flexibility and public dates which are infeasible. Start small, prove the concept and then grow so no more universal credit type failures. Figure out the minimum viable product and think like a start-up.
  10. Learning is two way. Up to now, GDS is being seen as the "gov.uk police" and the centre of excellence. This is great but as time passes this should become more federated. Departments such as HMRC and DWP are setting up centres of excellence and as they are closest to the citizens they serve they might find out things that would not only benefit them but GDS and wider government. Command and control is not an agile concept and GDS should collaborate and learn from government departments and be prepared to listen and adapt.

Bringing it all together into a strategy

  1. Develop a strategic vision. What is the GDS of the future? What's the vision for how citizens, visitors and businesses will interact with government - how about as simply and easily as possible? Where's the GDS Start with Why?
  2. Develop a target operating model. Realise that people would prefer to interact with government less, and optimise towards this. 
  3. Ensure Digital by Default makes sense. Realise that Digital is only a channel and might not always be the most appropriate, easiest or most cost effective. For the nature of the service, the most appropriate channel should be chosen rather than assuming digital by default. 
  4. Join up government. Government as a platform needs to extend to local services and join up. The UK government created the Council Tax, so why doesn't the UK government build a platform for collecting it rather than 300+ councils building 300+ solutions. How does that make any sense at all? When I change my address, I want to tell all government services at the same time - I don't care if they are provided by central government or not. Think about government as a platform across all of government, not just central government.
  5. Use standards appropriately. Realise that one size fits all doesn't always work. Standards and processes should only be used to make things better, not worse.
  6. Think beyond the service. Allow the user to connect with the relevant content which matters to them with the least possible effort. This includes personalisation, geo targeting and filters 
  7. Simplify for the citizen. Do the complex behind the scenes work necessary to shield users from complexity. Users want simplicity. The renewal of the Car Tax disc - great! Let's have more clever thinking like this. Join up the legislative process and government thinking with what user needs are telling you so that there is optimisation all the way from top to bottom.
  8. Measure, improve and optimise. Keep evolving quicker. Decrease your cycle time so that we don't have to wait 4 years for a review. Measure your service deployment time from discovery to launch and work out how to do it quicker and cheaper for the same quality.
  9. Look for big wins not just incremental improvements. Look for the 10x improvements which Google embodies. Start there and think about applying this to government to enable huge efficiency savings.
  10. Keep up the great work! It's not all bad really!

Four things you can do

  1. Please feel free to share this article on social media  using the links below
  2. Please comment on the GDS blog if you want to feed back direct to GDS
  3. Please respond to the survey.
  4. Comment at the end of this article.

Keep calm by focusing on simplicity mug

About the author

Craig Cockburn has worked across the public sector as a freelance Digital Consultant including Direct Gov, The Department for Work and Pensions, The Scottish Government, The Public Prosecution Service, The Department for Business, HM Revenue and Customs, The Scottish Tourist Board, The CIO Council and Southwark Council and gives his views here on whether the GDS reboot will be a success both for government but more importantly for the citizen. Finally, if you feel I can help you with related Digital Transformation work, please feel free to contact me via LinkedIn or by email on craig@siliconglen.com.

Many thanks,
Craig.

View Craig Cockburn's profile on LinkedIn


No comments:

Popular Posts