Last month was a really important one for the Digital by Default Service Standard. We launched our beta for one thing. Just as importantly, the Digital Leaders network - the people responsible for driving the digital agenda across government - agreed to the standard and the governance process for assessing services against it.
Not just tick boxes
Mention the word ‘governance’ and you can guarantee that most people will switch off. And with good reason. It usually means tick boxes, bureaucracy and lots of meetings. Too often, these kinds of process are inflexible, incoherent and opaque.
But we mustn’t ignore governance, because there has to be a fair and consistent way of answering the question ‘Has my new or redesigned service achieved the standard, and can it go on GOV.UK?’
As part of the beta Government Service Design Manual we published a couple of weeks ago, we included a draft version of the standard. This was a list of all the things new and redesigned services processing over 100,000 transactions per year must do before launching. It will formally apply from April 2014, but is already being used to help improve services ahead of them going live. The agreed standard will be included in the updated manual we’re launching next week.
We’ll include more detail about how the standard will be awarded in the manual very soon, but for now here are the three things we’ll be keeping in mind as services are assessed.
Consistency
The same standard applies to every service in scope. People see government as one unified entity, so we need services to be consistent.
To make it workable for a huge variety of different services, we have struck a balance between being making the standard definitive (on exactly what we mean by certain performance measures) and flexible (such as what it means to be ‘agile’).
But if a service is being redesigned, it’s public facing, and it processes over 100,000 transactions, the standard applies.
Common sense
Secondly, it will be applied with common sense. The standard represents a big change to how government builds and runs services, and that’s not going to happen overnight.
Some services being launched next year will have started their redesign process before the standard existed. Some are working with lots of legacy systems or old contracts. It may not to possible to meet every requirement to the letter on day 1 of a service. But the point of the standard is to get great services on GOV.UK that can be iteratively improved very regularly. If a service proves it can do that, and constantly improve from a good basis after launch, then the standard has done it’s job.
Openness
Finally, progress should be made in the open. As part of meeting the standard, every service team in government will have to produce a public, regularly updated record of how they’ve have gone about meeting it throughout the lifetime of the service.
That’s really important, because it helps government share ideas and information and gives the public - the users of those services - the chance to see how we’re building them.
We’ll be publishing more detail about the specific process services will be going through as part of the manual soon, but we still welcome your comments on the beta.
6 comments
Comment by Jennifer posted on
Openness and transparency is key, and usually not the government’s forte. I hope this project will be different and bring the various governmental systems in tune with each other.
I am curious about the 100,000 transaction per year rule, why would you not be interested in getting even smaller systems standardized over time?
Comment by adgreenway posted on
Hi Jennifer, thanks for your comment. The 100,000 threshold was set for a couple of reasons. The first is that for smaller services it may not be cost effective to transform them in a way that fully met the standard, simply because they do not cost that much to run in the first place and there aren't as many benefits to gain for users.
The second is that is over time, we hope to develop platforms that provide similar services (such as getting a licence, or making a type of payment) with almost ready-made solutions. While it may not be cost effective to individually transform 20 similar services processing 50,000 transactions a year, it probably will be worth building a single platform that can handle those million transactions in one go. However, this is some way off for now, as we're focusing on the exemplar projects with departments.
Comment by David Chassels posted on
AH! Common Sense.....? Well that implies you start with knowing what suppporting technologies can do to deliver customer centric apps and orchestrated the valuable data in legacy into an adaptive future proof investment that can readily cater for change. You should know what technologies I am talking about if not - back to Common Sense....?
Comment by adgreenway posted on
Hi David, thanks for your comment. By common sense we mean recognising that every service redesign will be a bit different - so having a one size fits all solution was not likely to be helpful for anybody. What we've tried to do with the standard is capture the things that every service can and should do; putting users first, improving iteratively using data and feedback, making appropriate technology choices, and so on, to produce something that gives clear direction without forcing perverse or unrealistic outcomes. We need to see how that performs in practice, and will keep it under close review.
Comment by Jon Sundby posted on
Thank you, again!
Your project, with your openness, a year ahead us, is a huge gift to us! Like a remote mentor, or powersource!
Comment by adgreenway posted on
A pleasure! Do let us know any feedback you have on it - especially if you're using the manual or the standard in practice. We'll be continuing to update iteratively over the months and weeks ahead.