Since we first talked about updating the Service Standard, we’ve run workshops up and down the country and been through a number of drafts. All of this has helped us get to what we’ve just published: the updated Service Standard. You can download a poster of the updated Service Standard here.
The updated Service Standard comes into force at the end of June. From this point anyone starting a new discovery will need to work towards it.
At some point we think it makes sense for services that are already in progress to transition to the updated Service Standard. We’ll be consulting on this, but in any case it’s unlikely to happen before early 2020.
The start of something exciting
We’re really proud of the impact the Digital Service Standard has had. It’s contributed to the growth in digital maturity across government, to the extent that the best government services are now among the simplest, most accessible services around.
But we think things can get better still – and that the updated standard is the first step on an exciting journey to making that happen.
It’s the start of a conversation about services that cut across departmental boundaries and work brilliantly no matter which channel you use to access them. And, where relevant, help to solve an underlying policy problem – as well as working on their own terms.
That’s better for users because they get the thing they need without having to understand the structure of government or a department’s internal processes. And it’s better for government, because it means we spend more time helping people and less time dealing with problems caused because it’s not clear what we’re asking them to do.
We’re already seeing teams across government doing really interesting work in these areas: we hope that the updated standard will help make that the norm.
Now it’s for everyone
Another exciting aspect of the standard is that we’ve written it with the wider public sector in mind.
The standard might have started life as a tool for central government teams working on public-facing transactions, but now you can use it if you’re, say, working in a local authority – and we’ve made it easier to use with internal or non-transactional services too.
You can read more about how and when to use the Service Standard.
You’ll recognise lots of it
It’s worth saying that, despite the exciting new stuff, the updated standard isn’t a grand departure. In fact, the vast majority of the underlying intent is the same.
We still care about things like building services iteratively, delivering value to users as quickly as possible, open-sourcing your code and using common platforms.
And the trigger for assessments hasn’t changed: you’ll still need to come and talk about the digital service you’ve built, but you’ll be asked some extra questions about the wider landscape around it.
That wider ambition reflects commitments in the Government Transformation Strategy, as well as recognising the increased digital maturity and capability across government.
Drawing on the expertise of others
Some of those extra questions will relate to things that aren’t within a digital service team’s direct control. For instance, you might be asked about the offline parts of your service when you come in for assessment.
We’re not asking digital teams to take responsibility for these things: we’re asking digital teams to make sure they’re talking to the right people, and for the organisation as a whole to support those conversations.
Operational experts probably have more direct contact with users than anyone in a digital team – so you should be talking to them and encouraging them to play a full part in shaping the government services of the future.
Maintaining services in a sustainable way
Government runs a lot of services. Developing those services so they meet user needs and are fully accessible takes a lot of work, money and people. We know it’s not realistic to expect you to commit those resources over the entire lifetime of every service.
Instead, we’ll be asking you to keep the performance of your live services under review and come back to them periodically to improve and iterate them. Which is why we’ve put more emphasis on running a service and published some accompanying guidance on working out where to allocate your limited resources.
What we’ll be expecting from service teams
It’s important to point out that we’re not expecting you to start building completely joined-up services that work seamlessly on all channels overnight.
That should be the long-term aim. In the meantime, you should take reasonable steps towards those goals.
For example, you should absolutely start small by focusing on a particular touchpoint or transaction, getting a version of that transaction in front of real users as quickly as possible and iterating as you learn. As long as the transaction is scoped so it makes sense to users.
Not all services are part of a wider journey for the user. But if yours is, you should have a plan to iterate towards an end-to-end service that solves a problem the user would recognise.
You can read our guidance about the alpha phase to see how you might approach some of these issues.
What we’ll be doing to support you
We realise teams will need support transitioning to the updated standard. We’ve published lots of new Service Manual guidance, which should help address a lot of queries.
We’ll also be giving people the chance to ask questions and talk about the things that matter to them.
It’ll take us a while to get to everyone, but we’ve mitigated against that by talking to assurance leads across government. They’ll be able to deal with lots of your queries.
And there’s a Google group if you need help with anything. The group is for people working in government or for government and you'll need to join using either your government or corporate email address.
Watch this space
The updated Service Standard is a signal of things to come, and of a government that works as one organisation, across channels and departmental boundaries, to provide great services to users.
4 comments
Comment by M Mitchell posted on
Hi there,
Having had experience of working with GDS on two projects using two different tech stacks I wanted to mention the following observations:
Can you confirm whether development can participate in and during the alpha stage? An external contractor, we had working for us, mentioned that the official line is there shouldn't be any coding done at this stage. I would argue, given unrealistic timelines, that it is essential to at least perform spikes and create technical prototypes at the very minimum.
If this is the case then I am finding it hard to understand how a typical six month alpha phase is akin to agile ways of working? It's no different to waterfall.
Generally, the guidelines are sensible and most of them would be applied to digital projects whether we are following GDS or not. However, they could be viewed as too pre-prescriptive. It should really depend on the type of project and organisation in terms of culture, process and tools. For example, agile only gives real value when the project is greenfield or has many unknowns and works best in small teams. A revamped service where the data model has been worked on for a long time, and perhaps driven by legislative requirements may not necessarily benefit from a pure agile approach.
Regarding open sourcing our code, it would be interesting to find out just how much of that code is being reused by other government departments and organisations. Again, it should be pragmatic rather than enforcing a blanket rule.
It should also be worth pointing out that the traditional polarized view of open source vs proprietary software is far less conspicuous. In the context of Microsoft, they are now moving towards an open source model with the introduction of their NET CORE platform, Azure DevOps and Visual Code IDE. Open Source platforms also have a risk of high support and maintenance costs. In our experience they are far less robust and stable and often have less labour resources with the relevant skills such as Drupal 8.
Comment by Ben posted on
I disagree that agile is only appropriate for greenfield development.
Agile is useful when you’re dealing with a complex problems, and the answers are unclear until you start working on them. This includes pretty much all government service development, because the context of government is complex. Nothing has clear owners, policies are rarely unambiguous, processes are hard to change, budgets are tight, organisations are huge, users are diverse (and all have to be catered for).
Something the Service Standard has always required people to do is to base the design of their services on user needs. Teams can't ignore legislative and legacy constraints, but they shouldn't be the starting point. That means that even teams revamping services should be wading into that complexity - the data model should follow the need, and teams should be ready to do extra work to change it to make things simpler for users.
You also mentioned coding in the open. Anna Shipman has blogged about some the benefits: https://gds.blog.gov.uk/2017/09/04/the-benefits-of-coding-in-the-open/
Reuse isn't even on the list!
Comment by Meryn Cutler posted on
I am really hoping some of your great work with the service standard will get fed down to the DWP. Specifically with Access to Work applications. The whole ATW system is impossible for people with Learning Disabilities to navigate. This results in them missing out on funding that they are entitled to receive in order to access employment.
Comment by GDS posted on
Hi Meryn,
Thank you for getting in touch. If you've got any feedback for the team working on the Access to Work service, you can share it by clicking on the 'Is there anything wrong with this page?' link towards the bottom of this page: https://www.gov.uk/access-to-work.
Many thanks,
GDS