Introduction
This document describes the prototypes built to address the user needs identified in the discovery phase of the ‘Better case management of FOI and SAR requests' project, funded by the Local Digital Fund. The prototypes were developed by mySociety in partnership with Hackney Council, Cornwall Council, Suffolk County Council, Stevenage Borough Council and East Herts District Council in early 2019.
Three main prototypes were developed:
- A self assessment tool for FOI service managers, to help provide a clear path for understanding and improving the service they're responsible for;
- An example guide that defines the problem of time-to-allocate, and provides suggestions for measuring and improving it;
- A demo install of the Ministry of Justice's open source Correspondence Tool — an existing open source FOI and SAR case management system that could form the basis of a fully featured case management system suitable for local authorities.
We partially investigated two other user needs, around delivering concise tasks to Information Holders to help reduce their time spent on information requests, and around the insight available from existing systems' reporting functionality. However, we opted not to build dedicated prototypes for these as the progression into beta would be best served through alternative options.
Oversight: the 10,000 ft Problem
The ICO's target states that 90% of requests to authorities should be answered within the 20 day timeline, but there's little guidance on how to do that. Our research findings expressed the issues faced by the FOI Manager as a user story:
As an FOI Manager I need to know how to operate the FOI Service so that I can meet the obligations of the FOI Act.
I know it is done when I have a clear path for understanding and improving:
- the skills of the people,
- the processes that guide them,
- and the technology to make tasks easier,
in the organisation.
There isn't a clear guide for the operation of a successful FOI service. Many other domains and industries have high-level guides, and we think there is a clear need here, just as GOV.UK has its service manual, productivity has ‘Getting Things Done' and many, many design agencies have documented their approach in ‘playbooks'.
To address this need, we prototyped a Self Assessment tool that helps FOI Managers assess the strength of their authority's FOI service in order for the tool to present a high-level overview of strong points and areas for improvement. Based on the results, it then presents relevant guides that can help them make targeted changes in order to iteratively and effectively improve the performance of their FOI service. We see the guides as being a living, collaborative document of the collective knowledge learned from organisations running an FOI service, presented in a plain language, easy to understand manner.
The prototype has two major component pairings: 1. The Self Assessment Questions and the Current Overview, generated from answers to the questions. 2. The Problem and Guide combinations that help FOI Managers make the next most impactful improvement to their service.
There was not enough time in the alpha phase to cover a wide range of Problem and Guide combinations, so we used the Allocation Problem as a basis to demonstrate in sufficient depth, a template for future work to expand the range of resources offered by the tool.
The Self Assessment Questions guide an FOI Manager through a short survey, asking them to rate their level of agreement with each statement as a number, from 0 (least agreement) to 3 (most agreement)
The questions are grouped into four sections; Context, People, Process and Technology.
Our first version of the questions proved too simplistic, as they were tool-based, rather than outcome-based, so we refined them to make them less about the specific tools or processes local authorities have in place, and more about the observable behaviours across the organisation. We also changed the answer format to be less of an overall ranking per section and more of a scale per question.
We also had feedback from early paper-based testing that the simplistic overall scores led to the tool being used as a ranking system between our participants, which we felt was a negative consequence. When we revised the question and scoring we aimed to remove any hint of competition or ranking, and instead focused on prioritisation of next steps.
On completion of the Self Assessment Questions, a Current Overview page gives a broad overview of the authority's FOI service, based on the answers supplied by the FOI Manager.
The radar chart visualises their results to help an FOI Manager understand the strength of each element (People, Process, Technology) of the FOI Service. In the discovery phase we observed an authority who was heavily weighted towards Technology: being presented with an illustration of this helped them see that issues of People and Process were overlooked and due extra attention. By including visualisations we hope to enable such insights for future users, providing an at-a-glance overview of the results, as shown below.
For each element, the results of the questions are shown together, colour coded by score so that it's easy to spot the lowest ranked issues and infer a priority of each. This colour coding is critical as it's often hard to know how to prioritise areas for improvement when they all seem equally important and may appear unrelated. The three elements provide a framework for reasoning with this complexity, and help FOI Managers make iterative improvements to gradually improve their baseline scores.
The listed problems help FOI Managers gain a full understanding of the Self Assessment results. The Problem definitions help to explain the details of the problem, and when and why solving it will improve efficiency. Based on the lowest-ranked answers for each element and the context of the authority (organisation complexity and request volume), relevant guides are shown. These help answer the question of "How do I improve the service I'm responsible for?" The prototype isn't capable of making intelligent suggestions, but further work would develop an algorithm to display guides that, if followed, would aim to have the biggest impactful improvement.
- The SICO has a self-assessment toolkit, but it covers more of the "what", rather than the "how" that we're aiming to help with.
- The ICO has some nice Data Protection self-assessment tools that highlight "next steps" based on your answers to their questions.
- Atlassian's Health Monitors have an appealing interactive format for rating key team attributes and suggesting relevant guides.
- The Madison Public Participation Playbook allows user generated content in the form of highlight comments.
- Thoughtbot's agency playbook clearly groups guides into understandable sections.
- The GOV.UK Service Manual established the case for playbooks in government.
- The U.S. Public Participation Playbook allows readers to contribute thoughts and suggestions on individual pieces of content.
- The Digital Services Playbook has clear format of Problem Definition; Checklist; Key Questions for each guide.
The Allocation Problem
In our research findings we detailed the allocation problem, where we found that getting a request to the right information holder, and quickly, is a critical part of meeting FOI performance goals. The user stories that apply here are:
As a Central Team, I need to get the correct information from the Information Holder, so that I can respond to the Citizen on time.
I will know it's done when I respond with the information within the 20 working day limit.
.
As a Service Champion, I need to promptly allocate requests to the correct Information Holder, so that I have enough time to receive the information and compile an approved response.
I will know it's done when
- I get requests allocated to me within 48 hours.
- I allocate requests to the information holder within 48 hours.
While many agree that the allocation problem is critical, we found in discussion with our partners that few had seen the problem in its entirety. Their primary concerns focused on the first part, allocating to the right person, rather than on the time to allocate, so we wanted to address the issue as a whole within our prototyping phase.
In summary, there are two key goals for request allocation: getting the request to the correct person, and getting it to them quickly. We found the existing tools lacking when it comes to this part of the FOI process, neither assisting in discovery, nor recording any useful metrics to use to ensure correct future allocation.
Solving this problem requires an authority to have documented their knowledge and hold data at the right level of detail; and having the maintenance and upkeep processes in place to ensure it remains current. In a small authority where changes are minimal this is less of a problem, compared to a large, complex authority, where restructures and shifting responsibilities are commonplace. As a result this is more of a process problem than a technology problem — but that doesn't mean that technology has no role to play.
The MOJ correspondence tool attempts to solve this issue through its ‘assign case' process, whereby each ‘business unit' has an ‘areas covered' property that describes the areas of responsibility and people responsible. This would assist a staff member in assigning requests to the right part of an authority, but doesn't solve the problem alone, as the larger challenge is in collating these areas of responsibility, and ensuring they remain up to date.
A further software improvement could be to learn from previous allocations and use that information to assist in the future. We envision some intelligent suggestions based on a request content (eg "This looks like a request about housing repair"), or software that intervenes when it thinks a bad choice has been made ("Housing repair rejected the last three requests that were similar to this one — should we try rental services instead?").
We call this Time-to-allocate and in our prototype Problem definition and Guides it informed part of our Self Assessment tool. We researched and workshopped with partners to create a written guide to understanding and solving slow time-to-allocate.
To begin this guide we combined our research findings with some practical exercises. At a workshop with our project partners we generated approaches that could be taken to reduce time-to-allocate.
This resulted in a time-to-allocate problem guide comprised of three parts: a problem description, to assist in diagnosing whether a council has this problem; and two written guides, on how to measure time-to-allocate within an established request process, and how to reduce it.
As well as demonstrating a software-independent solution to the time-to-allocate problem, this approach allowed us to trial and evaluate the written component of our self assessment tool.
MOJ Correspondence Tool
During the discovery phase we were approached by a development team at the Ministry of Justice who have been working on an open source case management system in use at the MOJ for handling FOI requests and non-offender SARs. We decided to evaluate this tool in the context of local councils as part of the alpha phase of this project.
The Correspondence Tool does not automatically ingest cases through a web frontend or email address. Staff manually triage emails and re-key them in to the Correspondence Tool.
The form presents appropriate fields depending on the case type selected (FOI, SAR or ICO Appeal). In the case of SARs, proof of identity is uploaded alongside the case record.
Cases can be ‘linked' to other cases, for example an Internal Review request can be ‘linked' to the original request case record. This functionality may also be useful for handling multi-department requests, by chunking the questions in to individual cases to be assigned to different responders.
After creating a case, it must be assigned to a responder — a role equivalent to that identified in many councils as a Champion.
The tool helps to locate the appropriate responder by presenting an easy-to-navigate organisation structure with areas covered clearly listed within the tool. This approach builds organisational knowledge in to the system to help reduce time-to-allocate.
Once the case is assigned, it must be accepted by the chosen business unit. This seemingly trivial step appeared to be a major omission from other software we saw in the discovery phase. Time-to-allocate is a key performance indicator that should be monitored and reduced, but can be extremely difficult to track and understand if the software does not record it.
Filtering by "To be accepted" allows the Central Team to step in when cases haven't been allocated in an acceptable time to ensure that Information Holders get enough time to extract the requested information and receive approval to respond.
The Correspondence Tool does not include capabilities for staff to collaborate on responses within the tool, nor does it handle sending the response to the requester. In this respect, it is limited compared to some of the commercially available case management systems we've seen.
Responders write and collaborate using external software, which has the advantage of allowing them to use familiar and best-in-class tools for this part of the process. The downside is that the drafting and response phase of the case is opaque. Hackney in particular noted that bringing the response drafting in to their case management system had a noticeable impact on improving response rates.
The completed response is manually emailed to the requester, and uploaded to the correspondence tool to preserve a record of it. Many commercial systems handle all correspondence with the requester. This functionality is more complex to implement, and likely most appreciated by larger authorities with a high request volume or larger number of staff triaging requests.
Comprehensive filters and search are available to view cases.
Alongside filtering capabilities, the Correspondence Tool includes built in — and user editable — reports. The simplicity of generating these reports would be a great advance compared to authorities compiling the same statistics manually.
The MOJ's Correspondence Tool is Open Source, allowing for modifications and additions to be made to the code to provide extra functionality. Here we identify such possibilities and describe the potential additions that could be created.
Once the case record is created and assigned to the correct person to answer the information request, that person must extract the data from various systems and compile a response to the original requester. Currently the Correspondence Tool requires this to be done outside of the tool, probably using a standard desktop word processor.
The downside to this is that the response creation phase of the process is completely opaque to everyone else. It doesn't easily allow another responder to pick up where the original assignee left off — in the case of sickness for example — or for Champions to monitor progress of requests they're responsible for.
The upside is that Information Holders can use best-in-class tools that they're already familiar with to collaborate on responses. It also minimises their interaction with the case management system if responding to requests is only a small portion of their role. This reduces training overhead and allows them to spend their already limited time focusing on extracting the requested information, rather than remembering how to use the case management software.
Were we to develop this tool further, an approach that could be taken is to offer three levels of integration for creating responses: 1. The current "PDF Upload" functionality — most useful for first-time case management system users. 1. Incorporate a simple built-in editor — most useful for users transitioning away from an in-house or commercial case management system. 1. Integrate with commercially available editors — most useful for larger organisations that already make extensive use of cloud-based document authoring and management systems.
Image: Currently there’s no integrated editor. Responses are written in a separate tool (probably Word) and uploaded as documents.
PDFs are created outside of the Correspondence Tool and uploaded on completion of a case so that a record of the response is retained.
Image: For smaller councils, we could provide a built-in editor that covers the basics. The collaboration would be more limited than in Google Docs, but probably fine when most of the time you only have one person working on a response at any one time.
A simple editor is integrated with the tool in place of the "Upload Response" button. This would allow non-real-time collaboration — useful for smaller authorities with fewer people likely to be available to work on a response at the same time. Once the response is finalised, it could be converted to a PDF to send to the citizen and retained as a record.
Image: "Cloud" Editor – could be Google Docs, Office 365 or similar. Creating a response takes you out in to the configured tool of choice, creating the document in the correct folder. The external document is always linked in the Correspondence Tool.
Many cloud collaboration tool providers give access to APIs that could be integrated with. More advanced authorities, instead of creating an internal response draft, could create a document in their existing document management system — possibly from a template — that could be collaboratively worked on in a familiar environment. The Correspondence Tool could ensure the response is created in the correct location in the document management system and maintain a link to the draft response alongside the case record without the need to manually keep track of these links. Once the response is complete, the tool could convert the draft into a PDF to record the final response sent to the citizen.
While commercially available editors may have best-in-class features for word processing, they do not come with FOI-specific tooling that can be included to an all-on-one FOI case management system. Fortunately, leading commercial platforms allow the development and use of add-ons so that this missing functionality can be integrated.
An example tool that could be created and integrated as an add-on is an exemption template tool. Responders could search a list of exemptions by terms understandable to them (e.g. "cost limit", rather than "Section 12") and click to import the template text to their draft response. The add-on could also provide in-line guidance for how and when it is appropriate to apply the exemption.
Image: Mockup Google Docs add-on for applying template exemption text to an FOI response.
Commercial information request handling software often has the ability to automatically create a case in the case management system on receipt of an email to a specific address. This saves time and reduces the risk of error or even missing requests entirely. The MOJ Correspondence Tool doesn't have this ability. If built, it would also have to consider follow up replies to ensure they're recorded against the correct case. Similarly, the more advanced commercial software handles sending the final response to the requester from within the system.
The chunking problem
In almost all cases, FOI is only a small part of an Information Holder's responsibilities. Our discovery research found that Information Holders frequently had to spend significant time understanding the whole request and picking out the parts relevant to them.
As an Information Holder I need to receive well-formed FOI requests so that I can get on with my other responsibilities.
I will know it's done when I am presented with clear questions that I can answer.
We saw effective use of "chunking" — where individual questions are extracted from the parent request and assigned to individuals — by a Champion in Hackney Council, who credited it as being a significant part of his service area's good performance. However, the case management software in use at Hackney had no built-in support for this, so the Champion was relying only on text formatting to create "assignments". This rudimentary technique didn't offer any additional workflow benefits from the software. There's an opportunity for software to assist this process and help it become a more common practice.
The principle would be to allow each request to be broken up by Champions into individual question elements that can be assigned to different Information Holders. This would provide a much simpler entry point in to the case management tools for Information Holders, and allow them to quickly understand the information they need to extract and respond with.
As each chunked question would have its own workflow, the reporting granularity would increase, giving Champions better insight on progress of information requests they are responsible for, and more opportunity to take action sooner on problematic cases.
While we were confident we could design a solution, we didn't progress with the chunking problem. An independent tool could be produced to help speed up the process of question chunking, where the output could be copy-and-pasted back in to the case management system with the special formatting to illustrate chunked questions and individual assignments, but the project team felt that significant value would only be created when integrated with the council's existing case management tools.
We felt an independent tool would face a much lengthier adoption process, and the full benefits of chunking would be missed due to the lack of integration with the case management system. Integration would require commercial software providers to implement the solution within existing tools. Had an extendable or open source case management system been in use at one of the partner councils, the prototype could have been integrated into the tool to test its value under real-world use.
The insight problem
Although we didn't investigate this directly as part of our prototype phase, an outstanding issue that is ill-catered for in FOI software is reporting. Specifically: customisable, on-demand reports that allow staff of all levels of seniority to get a picture of the service as is, that they can use to monitor, diagnose and solve problems.
As an FOI manager, I need to get reports that are aware of statutory deadlines, so I don't have to calculate them manually
As a service area manager, I want to understand the performance of my team within the FOI process so that I can ensure compliance with the law
We've seen through our investigation into the MOJ Correspondence Tool that reports such as these are technically possible to build, but this need doesn't appear to have been addressed well by commercial software providers. While some reporting was available to the authorities we partnered with, an excessive amount of manual work was required to produce useful reports from the raw data exports.
We faced similar challenges to the Chunking Problem in attempting to add significant value in this area. While we could demonstrate examples of good operational reporting capabilities — like those provided by the MOJ Correspondence Tool — there would be a reliance on commercial software vendors implementing them in their products.
There's also the consideration of higher level service metrics. How do FOI Managers know whether the service is operating cost-effectively? Or whether the new case management system has provided efficiency gains?
Conclusions
In the course of this discovery and alpha project, we have prototyped several different solutions around the key user needs identified in user research around the case management of FOI requests and SARs. We started this discovery and alpha project with the intention of prototyping transactions in an end-to-end open source case management system. As the project developed, we made two significant findings.
Firstly, that one of the key unmet needs across local authorities was the ‘10,000 ft problem' – the requirement for a broader focus on assessing a service and identifying strategies for improvement. We created the self assessment tool prototype to address this need.
The second finding came thanks to an approach by a development team at the Ministry of Justice who have been working on an open source correspondence tool. This answers some of the case management needs we identified as not well met by commercial options, and could serve as a base for further development.
In the Benefits Case we will discuss the next steps for the project, options for continuing this work, and costs and savings in doing so.