Service design consultant Sarah Prag shares some final thoughts on the approaches we’ve taken to delivering the project and how these might be applied more widely in local government.
One of the aims of this project has been to demonstrate some service design principles and techniques. This was partly to help us deliver our own project objectives, but it was also an opportunity for collaborators to experience some approaches they might find useful elsewhere in their work.
I’m referring to “principles” as well as to “techniques” because I think this is about more than just the tools we use (some of which I’ll describe below). It’s also about something less tangible – it’s about how we think about council services, how we collaborate and communicate, and how we keep delivering positive outcomes in a rapidly evolving environment.
Principles
Although we didn’t write down a formal set of principles at the start of the project we had a clear sense of how we wanted to work. This grew out of what we knew (and, more importantly, what we didn’t know!)
- We knew we weren’t subject matter experts so we were going to have to learn from people who were, and from our users (in this case council digital and waste service teams and their suppliers).
- We knew that we had to understand and meet their needs – otherwise there would be no take up.
- We knew we had to develop and test some real solutions – but we didn’t know at the beginning what these would be.
- We knew there were going to be a lot of stakeholders and interested organisations to listen to and to bring along with us.
Plans
We therefore needed to design an approach that could be clearly communicated up front, but which was also sympathetic to all the unknowns, and would allow us to work our way towards the answers.
We drew on the GDS approach to service development – with its Discovery, Alpha and Beta phases – and created a roadmap for our project (captured down the side of the project page). The roadmap showed what we aimed to achieve in each phase without having to specify all the details up front. This gave us and our collaborators and stakeholders some structure and context, but also allowed us to be genuinely open to learning as we went along and iterating towards solutions.
Techniques
Rather than list all of the techniques we used I’ll pull out a few highlights – the things I feel were particularly useful.
- Discovery process – I’ve already shared some reflections on how we did this in an earlier post, but it’s worth mentioning again how fundamental it was to the project to invest in a Discovery process. It got all the relevant people in a room sharing their insights and needs and was a great way to get the core project team up to speed. It was a big collective exercise to identify and prioritise the problems (or “epic” needs) that would be taken into development, so it also helped build a shared sense of ownership across our many collaborators and stakeholders.
- Taking an end-to-end view of services – Even though the scope of the project was fairly narrowly focused – on data standards and how they could be used in waste services – we needed to look at those services in their entirety in order to spot opportunities. This was an important part of the Discovery workshops – where we mapped out user needs from trigger to goal. Although this was quite a light touch version of journey mapping it still led to a few eureka moments, and also allowed people from across council teams to build up a shared view of the services they all work on. Taking an end-to-end view was also really fundamental to building up the business case as I wanted to show that there could be savings all the way from tendering through to customer services through to the back office.
- Iteration – We took an iterative approach to all of our deliverables – from Paul’s taxonomies to my business case and even to the videos that formed part of our communications. From my perspective it was really liberating to be able to come up with an initial Alpha business model, share this work-in-progress with collaborators to test my thinking, and then build on that experience and their feedback to produce a Beta and a final version. I didn’t need to pretend I had all the answers up front and it was a genuinely open, collaborative and iterative process.
Beyond this project
While some of these service design practices are already in use in some councils (including several of our collaborators) they’re not yet widespread in local government. Working on this project and learning about the challenges faced by council teams and their suppliers it became clear that there could be real benefits to applying these approaches more widely.
One unexpected area where this is true is in the procurement of waste services, where a lot of cost and frustration seems to stem from the up-front specifying of detailed requirements all packaged up into very long contracts. When we dug into this in a workshop at our Beta showcase there was a strong sense that taking a more needs based approach, and going through a Discovery process might help with prioritisation, and encourage greater innovation and iteration. I’ve written up more of these findings here.
Now more than ever?
In this project the focus has been on bringing together the different bits of technology that enable a service, and getting them to work together more effectively via data standards. It’s been about better integration – about the things that glue services together.
Arguably the delivery of all council services is also increasingly about integration – in a broader sense. It’s increasingly about seeking out solutions from a range of partners, collaborators, suppliers and co-designers and bringing those together into a coherent end-to-end experience for citizens.
Getting this right is going to mean a lot more collaboration and communication, a lot more identification and prioritisation of common problems, a lot more testing and iterating and openness, and a lot more boldness and innovation. To me that sounds like a perfect opportunity for a lot more service design!