A few weeks ago we asked for your feedback on the new Technology Code of Practice. The standard for government technology. Outlining how technology should be designed and purchased and acting as a key benchmark for the Standards Assurance process.
We have been thrilled with your response!
We’ve had numerous comments, emails and conversations where you have highlighted things you thought we’d done well and things you thought we hadn’t got right.
As part of this we’ve had some great Twitter conversations, ran a roundtable event with technology suppliers hosted by TechUK, we even posted a copy of the Code on the walls of Aviation House for colleagues to scribble their ideas and comments on.
The thoughtful, engaging feedback you have provided has been invaluable in pulling together the next draft, which we’ll be releasing for further review very shortly.
Before we do that, I wanted to pick out some of the interesting areas where people have provided feedback, and talk about what we’ve done to tackle those areas.
Who is this for?
While people who wrote to us broadly agreed with the content of our draft, lots of you pointed out that it wasn’t entirely clear who the intended users of the Code are, and that we hadn’t done a very good job of explaining what the point of the Code was. This was a really crucial point. If we can’t explain the point of the Code well it’ll be hard for people to use it well!
We hope lots of people will read and understand the Code, but it’s really aimed at people in charge of technology programmes and projects around government. Product owners. Project managers. They should be able to use this Code to make sure that their teams are making good strategic, commercial and technical decisions.
In the new draft, you’ll see that we’re specifically identifying the intended users and how and when they should be using the Code.
How will this help?
Many of you asked what we thought the benefits were to following this Code. Is it a way to make your business more efficient and effective? To exploit technology that is more flexible, cheaper and better for users? Or is it a way for departments to understand what to do to get approval to spend money?
The answer (predictably!) is that it’s all of these things.
We realise projects and programmes team across government want to know that they’re headed in the right direction for the beginning. By understanding this, and what good looks like, the approval of spend should be smooth.
So despite the long-term goal being all the wider benefits of building efficiency and flexibility mentioned above, the short-term goal is that the Code should allow a team to know what good looks like, and to get approval to spend, and our new draft is clearer on that.
Of course, a team that builds the principles of the Code into their project from the start will find it easy to get approval to spend AND build best in class technology that meets user needs. It isn’t a choice between short-term and long-term benefit!
Accessibility
During Accessibility Week in May we blogged about our desire to put accessibility front and center in the Code. Lots of people expressed support for this, but we did get some really useful feedback that the wording we’d used was a bit confusing, making it sound as though you didn’t always need to consider accessibility when designing technology.
The feedback we got on this from the Consumer Communications Panel included some substantial suggestions for wording changes (which made our job a lot easier!) which we were very happy to accept, and which are included in our new draft.
When is open not open?
Another common piece of feedback, both from inside and outside government, was around the ‘Make things open…’ section of the Code.
Interestingly, many respondents felt that there is already a lot of confusion about how open source and open standards are different and how those two separate issues fit together. The suggestion was that including them in the same section could make this confusion worse.
To avoid any confusion here, we’ve pulled open standards into a new, separate section which focuses on interoperability, leaving open source and open data together. We hope this will help people understand the difference between using open source code and building to open standards.
What happens next?
We’ll be publishing another draft of the Code soon. This time, based on feedback we received about how we asked you to contribute last time, we’ll create a document that you can directly comment on, rather than asking you to email us your feedback.
In the meantime, thank you again for all your contributions, it’s been great to see how much interest there is out there in what we’re trying to do and helping us do it right.
If you have any comments or thoughts more generally on how we’ve run this consultation, or on where you think GDS could benefit from more of this approach, please comment below!