This is a guest post by Richard Pope who we’ve been working with on the affordable housing monitoring service with Southwark Council. This is the fourth and final blog post about the next steps for this service.
Back in November, I joined the Southwark and dxw team working on affordable housing monitoring for a two day workshop. The aim of the workshop was to spend some time documenting and discussing different approaches to developing the work beyond alpha. The alpha team had also been thinking about how cooperation between local authorities could work and the potential for reuse.
Helping other local authorities with the same problem
Affordable housing monitoring is interesting from the angle of collaboration. Not only are the user needs clear (know how many affordable homes were promised, how many were built, and what happened to them after that), it’s also a relatively greenfield area. That’s because, as the team mentioned in their final report, it falls between two existing systems in local authorities – building control and planning – and most local authorities don’t actively monitor affordable housing. During the workshop, Daria also emphasised the importance of housing data as a tool to ask questions and understand policy outcomes at a national level, and how this is almost impossible today.
So, the question we set ourselves for the workshop was this: taking the alpha as a starting point, how might we develop it into something that other local authorities could make use of? Then, based on that, are there any lessons that we could generalise to other local government systems? The purpose of this blog post is to share some of what we came up with in response to that question.
But first, a bit of wider context.
Finding the right way to work together
Local authorities are beginning to build their own digital teams. 2019 has seen great digital teams being built out in Croydon, Hackney and Essex, and the further development of established teams like Adur and Worthing. This can only be a good thing. In turn though, it raises the question of how best to cooperate in a way that reduces duplication of effort, without the dilution of local variation and innovation.
Intuitively, and as many others have suggested before, the answer feels like a set of shared platforms that different local authorities can make use of. Failing that, a shared codebase at least. The problem is that, as yet, there are few good models for operating such things. At the workshop, we identified the following models:
- a private company develops software and resells it multiple times
- a local authority develops software and licenses it to other authorities
- central government operates a shared platform for local authorities
- an open source project forked by multiple local authorities
Finding what works best for local authorities
However, all of these have issues associated with them. Ownership by a private company or central government means the needs of local authorities may, over time, become secondary. Local government may struggle to build and continuously fund a team to operate a platform on behalf of other authorities. Finally, open source projects without good community management and a functioning contribution model can be fragile things.
That’s not to say that the above models are inappropriate in all situations. There are many examples of local authorities buying software-as-a-service, and the use of GOV.UK Notify by local authorities shows central ownership can be a huge success when it comes to a commodity based platform. But none of these felt right for something like affordable housing monitoring. This is due to the primary internal users being based within councils (planning and building control officers) and the policy being locally devolved and political (for example, the definition of what’s “affordable”).
A new model for cooperation?
We discussed options for a new model which allows for the needs of different local authorities and central government to be balanced. It also has to allow for long term investment in a team to operate and improve a shared platform.
The model we thought could work is one where the service is spun out as a separate legal entity, but it’s owned, paid for, and managed cooperatively by multiple local authorities (and possibly other stakeholders).
Making it sustainable
The legal entity itself could be quite small, but, importantly, it would have a clear mission to set standards. It could also hire and maintain the team needed to operate and iterate the service in line with the needs of local authorities. At a minimum, the legal entity would employ someone to act as a product owner, who would be at liberty to either employ a team directly or outsource development to a commercial organisation. We can also look to efforts to make open source software sustainable and projects like the Foundation for Public Code and the Software Freedom Conservancy.
However, it’s not enough to just come up with a model. There’s a clear risk of trying to turn a service into a shared platform prematurely. The harder problem is providing a route to get to something more platform-like. One that’s replicable for different projects and political contexts. We discussed how this could work for a service like affordable housing monitoring which has had a successful alpha and is looking to move into beta.
We thought the initial priority must be to get additional local authorities using the service, initially using a fork of the alpha/beta code (see the above risk of premature optimisation). Only once there are several local authorities using the service is it appropriate to think about creating a new legal entity. Although they may need some assurance upfront that it’ll happen at the appropriate point.
Applying the iterative approach of agile to organisations
Once the team developing the service are content that they know enough about how the needs of local authorities might differ, there’ll be some overhead in creating a shared platform for different local instances. We thought the funding for this should come either from the founding local authorities or from central government seed funding. cc2i.org.uk and the Local Digital Fund provide useful models for these. If the money comes from the founding local authorities, there may need to be some way of repaying their investment at a later date. We can also learn from the work Unboxed have done setting up a Community Interest Company around some of their projects.
Over the two days, we only came up with a high level sketch of how this might work in practice. The main takeaway for me (other than how much the team had achieved in such a short time) was this: it’s time to apply the iterative, emergent approach of agile development of software in step with an iterative, emergent approach to creating new organisations to operate those services. It’s not enough to design new services, we need to design new collaborative organisations to operate and iterate them too.