This is an HTML version of an attachment to the Freedom of Information request 'Project in relation to Freedom of Information and Subject Access Requests'.


 
Hackney FOI/SAR Discovery Project 
January 2018 
 
This document is intended as a brief summary of mySociety’s understanding of and approach to the 
Hackney Freedom of Information (FOI) and Subject Access Request (SAR) discovery project. It outlines 
the relevant background, the purpose of the project, the different research questions we will try and 
answer and how we plan to approach answering them, including a proposed timeline. 
Our intention is that following this first Discovery process we shall make recommendations for taking 
forward aspects of our proposed solutions towards an additional Public Beta development project 
before the summer. 
Background 
This document has been created following introductory meetings with 
 and 
 that explained how our work fits into a larger set of activities and where we can contribute 
most value. 
Hackney Council receives around 1,800 FOI and EIR requests per year and about 150 subject access 
requests. These requests (which are distributed unevenly across the Council’s services) are of variable 
quality. Some are for information that has already been published and some require back and forth 
communication before it is clear what information is being sought. 
Hackney Council are already working to improve the internal process of managing a FOI request and 
are in the process of procuring a new piece of commercial off-the-shelf (COTS) software to support 
this. 
Project objective 
The purpose of this discovery and prototyping project is to explore the potential to create a new 
digital service for Hackney Council to help members of the public find the information they are 
looking for when attempting to submit a FOI or SAR request and subsequently, when a request is 
complete, have the ability to publish non-personal requests and responses. 
 
From our discussions we are assuming that the process of creating a response is beyond the scope of 
this project as the COTS solution you select will cater for this 
 
More specifically, we should explore how the service can: 
●  help users to submit clear and valid requests 


 
●  integrate the submission form with other sources of information (including with a disclosure 
log) to try and prevent unnecessary requests 
●  integrate with a new case management system to enable automatic submission of new 
requests into the system, and automatic publishing to a disclosure log after a response is sent 
to a requestor 
●  use information from previous requests to speed the allocation of a particular request to a 
specific Council service 
●  support compliance with current legislation, and pre-empt forthcoming changes (GDPR). 
Success criteria 
Together with the implementation of the system that we are scoping, this work is aiming to meet the 
following success criteria. 
For FOI requests, we are aiming to: 
●  increase the quality of FOI requests submitted through the website 
●  reduce the number of duplicate or unnecessary requests submitted through the website 
For subject access requests, we are aiming to: 
●  increase the quality of SARs, in particular to reduce the back and forth needed at the start of 
the process to establish identity and consent. 
Research questions 
Organisational goals and drivers 
●  What do different stakeholders think the project should accomplish? 
●  What do different stakeholders think the drivers of this part of the FOI/SAR project are? 
Request submission 
●  What different kinds of people are there who submit a formal request for information? 
●  What proportion of people start off knowing they need to submit a formal request, as opposed 
to just knowing they want information? 
●  For those that aren’t aware of the formal processes, what language do they use and where do 
they go to ask? 
●  Are people any good at describing what they’re looking for? 
●  What proportion of FOI requests are for information that is already available? Are there any 
patterns to these requests? 
●  Are there particular requests that are asked repeatedly? 


 
●  What other common issues are there with the quality of the initial submission and the 
clarification process? 
Data sources 
●  What other council data sources are available (registers, lists, open data portal, publication 
scheme)? 
●  What formats are they in and can they be searched easily? 
Initial allocation 
●  What proportion of requests arrive via each of the different available channels? 
●  How are requests currently allocated to services and what are the issues with this? 
Current website 
●  How well do the current web-based submission forms perform? 
●  How do people find their way to the page? 
●  What other FOI-related pages to people read/interact with? 
Technical 
●  Can this be SaaS? If not, where does it need to be deployed? 
●  What is the most effective way to reuse styles from Hackney Council’s website? 
●  What coding/technical/security standards will we need to comply with? 
●  What integration capabilities does the intended new case management system provide? 
●  What other services, such as Verify for SARs, might we need to integrate with?  
Activities 
In order to answer the questions above, we are planning to conduct the following activities, organised 
into five phases. 
Data review 
●  Review web stats: look at available analytics on data protection / FOI pages and request 
forms to understand usage, traffic sources and effectiveness of current forms. 
●  Review FOI stats: look at available aggregate data on FOI requests to understand distribution 
across services, common types of request, commonly repeated requests and distribution 
across channels. 
●  Review FOI sample: look at a representative sample of FOI requests to understand the types 
of request people make, where they come from and the language they use. 
●  Analysis and write-up: write a brief document summarising findings. 


 
Interviews and observation 
●  Stakeholder interviews: interviews with 3-4 key people with responsibility for or interest in 
the project to understand what they think the purpose, drivers, opportunities and potential 
pitfalls of the project are. 
●  Workshop with IG team: a one-day workshop with the IG team to map out the process of 
receiving and allocating FOI requests and SARs, what common problems they encounter in 
this work, what different types of user there are and where they think the opportunities for 
improvement are. 
●  Champion interviews: interviews with 2-3 people who manage the FOI response process 
within a service to understand how requests are received, reviewed and allocated, what 
different types of user they think there are and how the submission process could be 
improved.  
●  Observation and interview with IG team member: 2-3 hour interview and observation with 
one member of the IG team to observe how they receive, review and allocate new requests 
and to ask any detailed follow-up questions following the previous interviews and workshop. 
●  Master data team meeting: brief meeting with the master data team to understand what 
other structured information assets Hackney Council has that could be made use of within the 
service. 
●  Web team meeting: an initial discussion with your web and IT teams to determine the broad 
outline of hosting and web standards that may need to be followed. 
●  Analysis and write-up: write up notes and findings from the interviews and meetings. 
Initial design and prototyping 
●  Review of other approaches: a brief review of how other councils approach FOI/SAR. 
●  Design workshop: a full-day workshop with key staff from Hackney Council to review the 
findings to date, present any interesting ideas of how other councils approach this problem, 
and then collaboratively explore design ideas for a new submission form and possibly 
disclosure log. 
●  Prototyping: create a first set of prototypes building on the work done in the workshop. 
●  Integration: discussions with COTS supplier for integration with case management service. 
●  Presentation and iteration: present prototypes to Hackney Council staff, gather feedback 
and make any necessary changes. 
Testing and iteration 
●  Usability testing: test prototypes with up to 6 representative users who have previously 
submitted FOI requests to understand whether users can successfully interact with them and 
to identify improvements in structure, design or language.  
●  Revise prototypes: make changes to the prototype in light of findings from the usability 
testing. 


 
 
[Potentially repeat this step ^^ for a further iteration to improve prototypes and increase fidelity] 
Reporting 
●  Write discovery report: write a report summarising the work done, findings from the 
research and presenting the prototypes and suggested next steps. 
●  Presentation and discussion: meet with key staff from Hackney Council to discuss the report 
and next steps. 
●  Recommendations: for next steps towards a Public Beta development phase. 
 
Indicative Timeline 
●  W/B 22nd January: project kick off and data review 
●  W/B 29th January: finish data review, run first workshop and start interviews 
●  W/B 5th February: finish interviews and run design workshop 
●  W/B 12th February: -- break for half term ? -- 
●  W/B 19th February: prototyping 
●  W/B 26th February: testing and iteration 
●  W/B 5th March: reporting 
●  W/B 12th March: final presentation and report delivered 
 
 
Costings 
 
The delivery of this proposal will require 40 days at a day rate of £600 per person.  
A total fixed fee of £24,000 + VAT. 
 
This will  include; 
 
5 days:  
Initial research into existing processes, challenges and expectations 
15 days: 
Co-design process (user research → prototype → user research → iterate and 
repeat) 
10 days: 
Internal integrations investigation and recommendations 
5 days:   
Final prototypes, documentation and recommendations 
5 days:   
Contingency and presentation 
 


 
This process would result in clear recommendations on which tasks need to be carried out in which 
order going forward and enough detail to begin a series of sprints to deliver the key 
recommendations.