by Paul Mackay, Technical Lead for the DCLG Local Waste Service Standards Project
After 8 weeks working on the ‘alpha phase’ of our Local Waste Service Standards Project, it’s time for some reflections on what we’ve learned.
In my first ‘working out loud’ blog on this project, I’m going to introduce the things I’ve been building and introduce the following key findings:
-
- the sheer diversity of taxonomies and data structures that we’ve come across so far on our mission to find the best common denominator.
-
- the crucial observation that everyone we’ve come across currently organises their waste service processes around bin colour – something that is notoriously not standard from one district to the next. This means that the software used for 1 authority can’t be picked up and used by another unless it uses the exact same bin-types for the same services.
- Even when our project tries to unblock the barriers to inter-council collaboration, we’ve still had a hard time getting the information we need from the right people in good time…
Standards speak 101
So, first things first. As Linda explained in her last blog, we’re starting with missed bin reporting, because that’s what our partner local authorities prioritised.
Moreover, we’re working on waste service data, on the places where information passes from one team to another, or one computer system to another. The idea is that if we can establish common terms and rules – otherwise known as technical specifications – for how data should move around, all local authorities and suppliers can work much better together, making the service work a lot better for citizens. They can also avoid the huge costs associated with building bespoke systems with bespoke rules for each new waste contract. This will also make it easier for app builders and others to create national tools that integrate seamlessly with local authority waste systems and support council services.
The 4 kinds of things we’re building
-
- Taxonomies: These are lists of standard terms. Our first standard taxonomy for this project has been the ‘missed collections reasons taxonomy’, and there are others that could be developed, or are already being used to support waste services. WRAP, for example, have already developed for things like material streams and container types. So, we’re making sure to avail of existing standards where possible.
-
- Data models: A data model is the foundation for designing a piece of software. It organises and standardises how data elements relate to one another. Our data model will describe a local authority waste service. It will include all the attributes and relationships we need to know about to run the service.
-
- APIs: Application Programming Interfaces are the bits of software that tell computer programmes how to interact. We’re designing a waste API that will enable in cab systems, customer services systems and websites to share missed bin reports in real time. So, the website and the customer services team can know why a bin was missed almost as soon as the dustman logs a missed bin! We’re building the API using a REST style, which basically means that it’s built on common Web technologies. It is the approach used by the majority of APIs being published today and is recommended by GDS.
- Data formats: Typically at the start and end of supplier contracts, data needs to be exchanged. Also some data can be published for reporting and so on. Data file formats describe what that data should look like.
No two taxonomies are the same – unfortunately
The first thing we set out to deliver was a missed collections reasons taxonomy. We started by comparing the taxonomies used by the 6 councils we’re working most closely with. Here, as with many things in local government, there was huge variation, ranging 5 terms to 84!
While it’s easier to modify a taxonomy over time than, say, a data model, we’re still aiming to agree a ‘best set’ of standard terms to start with, and we’re aiming to get all our partner authorities using these terms by the end of the project.
To whittle it down, we asked:
-
- which terms are used most commonly?
-
- why are some of the more specific terms used and are they needed?
- which category terms are essential, and can fit them all on a small screen inside a bin truck (in-cab units)?
It was hard to get the kind of feedback we needed over the phone on our fortnightly sprint. So, last week, we hosted a small workshop for our partner waste service managers and developers, and some key suppliers. You can find the resulting 1st iteration of the ‘reasons for missed collections’ taxonomy, in addition to the other resources we’ve made, here. We’d really value comments from waste service managers in particular.
Important observations
-
- Despite the fact that we did get copies of almost all partner taxonomies, it was very difficult to get the right people on our review call to give feedback. Why? We think it’s because waste service managers are extremely busy and it’s difficult to understand why they should invest their time in something as abstract as standards. To combat this, we’re ramping up our comms and storytelling. We’ll send out some business case material and a video later this week.
- Bin colours are often used in the in-cab units when entering data, which presents a challenge when creating a common taxonomy, as bin colour and size combinations varying hugely from council to council. This touches on our data model plans, which we’ll go into next week. Suffice to say, for now, that we’re proposing to organise data by service rather than colour, which will help. We’re also looking at ways to make the in-cab missed collection reasons map more flexibly to the information for the citizen.
In the next blog: Building a model waste service
My next blog will focus on our data model, what it’s looking like, and why. In the meantime, if you’d like to work with us or learn more, you can find all the information you need on our project page here.