Building the Future Council
My recent post about the future council gained a lot of attention, so I thought I’d share more of the thinking that I’ve done so far. What might it look like when you re-orient a council around people and places, rather than services?
This thinking started with a question from a council chief executive a few years ago, but was actually refined through work with a medium-large (£250m turnover) corporate. Despite being very different organisations on the outside, once you got under the skin their problems were very similar. All of this work combined now forms the Stratification framework that is part of the Applied Futurist’s Toolkit.
Fundamental units
The first thing to identify in the council’s case was that the fundamental unit of organisation was services. The whole organisation had been assembled by bolting services onto the side of the existing organisation, and even the radical transformations driven by austerity had not really changed that architecture. As long as it persisted, there would be massive ‘parallelism’ in the way the organisation operated, preventing efficiencies but more importantly, fragmenting data and adding friction to service, analysis and communication.
As I wrote about in the last post, the first and most important step was to re-orient the organisation around the citizen rather than the service. But we also had to recognise that this didn’t cover everything: a significant proportion of the council’s work is also place-centric, with granularity ranging from a single bin, to a building, to a whole street or park.
Hence we were left with two fundamental units that could be cross-indexed: people, and places.
Unifying the customer interface
With the citizen at the centre of the organisation, it was clear that we needed to unify the customer interface. The multiple touchpoints of the old architecture were highly inefficient, creating confusion, cost, disparate data and a governance nightmare, with little oversight.
A unified customer interface means a common written language style, with content written to the appropriate standard for the majority of the audience. It means ensuring that there is a single answer to each question, not multiple, conflicting answers. It means using a common design language to help those with limited English or poorer vision to understand information, whether presented in a face to face, written, digital or video context.
A unified customer interface means a coherent view of that experience across communications channels, using insight from contact centres to drive digital development, and vice versa.
Ultimately it led to the proposal of new internal agency, equipped with the skills and resource to handle these tasks, where previously responsibility had been distributed across multiple teams.
Creating coherent service units
Behind the unified communications layer sit the services, the core propositions of the council: education, public health, adult social care, environmental services, highways, revenue and benefits — obviously these will vary depending on the type of council.
I don’t pretend to be an expert in the delivery of any of these services. But one thing was clear when looking at them and their interactions inside the organisation: it was hard for them to understand each other’s work and for leaders to really understand their performance.
As organisations grow and develop over time their activities often become more complex on the inside and opaque from the outside. Complex isn’t inherently bad: these teams are dealing with challenging issues. But the lack of transparency makes many things harder: partnering with other teams, reporting success, analysing failure, inducting new staff.
We created a template to help these teams revisit their understanding of their core processes, their inputs, outputs and key metrics so that the could be more easily communicated to others. Sort of a paper ‘API’, that described how you might interact with them. Ultimately, it would be good to turn paper into code.
A common data layer
Underpinning the unified customer interface and more transparent interaction between services is a shared data layer. Once you acknowledge that there are only two fundamental units that the organisation deals with — three if you count numbers (finance) — it’s clear that the council needs many fewer software systems and databases than it has acquired under a service-oriented architecture (not this SOA).
The realities of the current estate, data protection legislation, and security choices may mean that you don’t actually condense everything down to a handful of systems. But as a notional vision, a unified data store of people and places is valuable because of the business value it can drive. Most people have few interactions with their council, and those they do have are relatively mundane — even automatic. But for those people who need more intensive support, more coherent information can drive much more effective intervention: earlier and more targeted, meaning better for the citizen and cheaper for the council.
External interface wrapper
The nature of the post-austerity council is that much of its work is commissioning, either to third parties or to its own services companies. Streamlining these interactions is less important than streamlining the customer interactions, but nonetheless valuable. Building a largely-digital wrapper that allows the two way flow of information for commissioning, payments, the sharing of data, and the monitoring of SLAs, would speed the flow of information right through the organisation, and ideally improve the delivery of services.