Department for Levelling Up, Housing and Communities
Developing a playbook, made up of a self-assessment tool and guides for FOI service delivery, so that FOI managers and practitioners can identify approaches for improvement.
One of the key unmet needs across local authorities discovered in the alpha project was the ‘10,000ft problem’ – a way to give FOI teams a means of assessing their service and identifying approaches for improvement. While the case management technology in place can have a dramatic effect on performance, it’s only one part of the overall system and might not be the best place for some authorities to focus effort. This project looks at the system as a whole, and aims to give context-specific advice to improve the overall FOI service in local authorities.
The prototype we developed validated the concept that a playbook, made of a self assessment tool combined with guides based on the collected experience of central teams, FOI managers, service champions and information holders would add real value to the practice. This project would allow us to collaboratively create the content that would allow it to reach a wider audience and meet a broader range of user needs.
With this single intervention we have the opportunity to gradually introduce a light experience of collaboration to FOI teams in multiple authorities, as a precursor to deeper collaborative work. Working across organisational boundaries, we’ll source content for the Beta while learning of the challenges faced by local authorities trying to share knowledge both within the organisation and across practice groups in neighbouring authorities. Using this knowledge, we’ll experiment with models of updating the content to aim to find a sustainable approach to continue to grow the service as it moves from Beta to Live.
We’re confident that once there’s a wider awareness of the tool, adoption will be successful, as the model of a single service means that councils using the tool can do so at very little invested time and risk, with the potential that at least some of the councils using the tool would make changes in their approach that would result in significant benefits. It also means that other authorities with a duty to respond to FOI requests can use the tool in a straightforward way.
We’ll need to do research in multiple areas in order to make this beta successful. Firstly to identify cases of significant service improvement that we can use to develop guides and work with staff to turn their experience into useful guide content. We’ll also need to validate the matching of users to guides that are relevant to their situation, to ensure that the service as a whole is usable and accessible to everyone who would benefit from using it. Finally, we’ll need to do research and experimentation to develop a model of collaborative maintenance and improvement of the content that will work.
The overall problem we’re addressing is that of improving the FOI service delivery in local authorities. The existence of a playbook will improve the user journey of council staff seeking to make their FOI service more efficient by providing practical advice that is specific to their situation.
The original brief of the discovery/alpha project was to prototype a technology solution to improve the management of FOI and SAR. Initially we were thinking of technology only in terms of case management systems. However, during our user research we proposed that there are three elements of an FOI service: People, Process and Technology.
What we found in our partner councils was that a range of problems existed across these three elements. This was further validated during conversations at Local Digital Roadshows. There’s equal importance of addressing problems in each of these areas and taking a full-system view of the issues.
The impact on FOI professionals is that they often know that their performance could improve but either don’t know where to start looking, or don’t know which problem to tackle first. There’s expertise in other authorities that’s difficult to access. This project aims to assist that decision making process by sharing prior experience from others that have faced the same issues. We will distil our research in to a simple public tool for all authorities to benefit from what we learned in discovery and early prototyping.
A well thought-out playbook, with a questionnaire that asks the right questions can make available clearly-defined, tailored content that is domain-specific. This means that the user doesn’t need to work hard to apply generic advice to their situation, nor untangle clumsy metaphors. Playbooks solve the problem of ‘how do you know what you don’t know?’, with tried and tested solutions to known problems.
The alpha prototype uses Jekyll – a popular Ruby-based static site generator – and JavaScript, so we’d base the beta project on the existing codebase. It also uses the GOV.UK elements styling and the GOV.UK frontend toolkit, both of which we found easy to work with and we would like to carry through those principles into the beta. However, the frontend toolkit has been replaced by the GOV.UK design system with significant accessibility improvements, so we will need to transition the project to use that instead.
We’ve assigned budget to further research and improve accessibility (specifically around colour coding of scores) and browser compatibility to a level appropriate for a beta service. A simple backend may also be required to meet accessibility and browser compatibility requirements. We’d likely build this as a small API service with transient server-side storage.
Some data entered by users concerning their assessment of their service is stored temporarily to calculate the self assessment scores, but the beta won’t hold any sensitive data, so the entire codebase can be hosted publicly on GitHub.
Operational support should be minimal. The applications would require minor library updates, and content would initially be updated via GitHub pull requests. Repository and deploy permissions could be distributed across the project partners. How this works in practice is something we’ll need to test through the course of the project, perhaps involving IT teams at one or more authorities.
We plan to use an off the shelf analytics platform to monitor usage and completions of key goals. Our success metrics will be based on the 4 mandatory KPIs in the GDS service manual. We could estimate cost per transaction by estimating a service cost and recording the number of transactions completed. Each page will include a feedback mechanism to measure user satisfaction, possibly integrating with the content contribution system. Completion rate will be measured by recording journeys through the self assessment. We can’t easily compare digital take-up against an offline metric, so we’ll estimate this by general traffic growth to the service. We’ll use further user research sessions to uncover service-specific KPIs and iterate on the success model as we learn throughout the beta.
The success metrics should be complemented by case studies of satisfied users, which will be reused to encourage adoption of the service.
We’ll use tools that worked well in the first round alpha project – short weekly calls with all partners, using a conference line that everyone can access. We’ll focus on progress made during the preceding week, and on planning the approach for the next week. We’ll prepare weeknotes in advance to structure the call but keep a relatively free form approach otherwise so that we can talk honestly about how things are progressing. As with our previous project, our goal will be to have something to ‘show’ each week, whether it’s a prototype or the results of some user testing or research.
We’ll combine remote collaboration tools, such as the calls and Trello board with more intensive periods of in-person user research and testing, working with the team from mySociety. During the project we’ll continue to grow our networks and increasingly explore methods of large-scale, small effort collaboration across local authorities in order to find a sustainable update and maintenance model for the content in the guides. For example, we’ll test how well the appropriation of GitHub for curation applies in a less technical, local authority context, and use the lessons from this to influence future experiment iterations.
As a collaborative team, we’ll aim to get decisions by consensus amongst the project team, but failing that, the single point of decision making will be the project lead from Hackney.
Ultimately, this project will require a little input from a lot of people in order to succeed in the long term.
We’d like to cast the net as wide as possible to get a large range of experiences to form the guides in the playbook. Local Digital could help by using its network to connect the project team to others with an interest in the subject matter. We’d also appreciate any insights from MHCLG and DXW on their research around collaboration in local authorities as we work to find a working model that allows a wide range of authorities to collaborate on maintaining and updating the service.
During the project we want to test our work in progress. Some of this testing will be online, but an intense collaboration session – perhaps at a Roadshow event, if those continue – would help us gather lots of information in a shorter amount of time.