DfT - Local Authority and Transport Operators Data Collection System

Tender description

About adding context and requirements test Pre-market engagement There has been no early market engagement. Which phase the project is in Discovery Existing team The appointed agency will be expected to work closely with members of the statistics and policy teams in DfT, in particular those working on buses and local transport policy areas. Address where the work will be done The majority of the work will be conducted at the supplier's own site (or other chosen location) though conducting of user research may require travel around the UK to interview respondents at their premises or chosen location if not conducted virtually. Occasional meetings with DfT in their office in London. Travel expenses must align with DfT Travel and Subsistence policy, with no expenses incurred within the M25 corridor with all other proposed travel approved by the buyer prior to mobilisation. Working arrangements Suppliers to provide preferred approach. The exact milestones will be agreed with the supplier when appointed. Weekly status updates (teams meeting, email) detailing achievements of key milestones and issues that may impact timescales and cost should be provided. It is expected that the research questions should be fully answered in a final presentation and report. Discovery should be completed in line with the GDS Service Manual: https://www.gov.uk/service-manual. Provide more information about your security requirements: Baseline Personnel Security Standard (BPSS) Provide more information about your security requirements (optional): All contractors’ personnel should as a minimum be cleared to authority security level of BPSS and must be available to begin work with immediate effect following contract award. CVs including security clearance evidence are required for resource to be assigned to project and will be evidenced at written proposal stage. Latest start date 2023-11-13 Enter the expected contract length: 3 months Extension period: 1 month and 15 days Write the term or acronym: DfT Write the term or acronym: LA Write the term or acronym: GDS Explain the term or acronym: Department for Transport Explain the term or acronym: Local Authority Explain the term or acronym: Government Digital Service Are you prepared to show your budget details?: Yes Indicative maximum: 70000 Confirm if you require a contracted out service or supply of resource Contracted out service: the off-payroll rules do not apply Summary of work DfT would like to explore a new data collection service to enhance and modernise an existing process deployed on both an ad-hoc and routine basis with local authorities and small transport operators. Anticipated functionality for DfT includes user-led design, collection, ingestion and storage of existing and future surveys and data collections, including both quantitative and qualitative data. Anticipated functionality for respondents includes data input, user management, notifications, data validation and ability to access previously supplied information. Currently DfT statisticians use two main survey tools to collect data from around 300 local authorities and approximately 500 bus and other transport operators. We are aware from internal use and discussions with data providers that the current tools have numerous issues and restrictions for both internal and external users. We seek to run a discovery phase in line with GDS Service Manual criteria and DfT Architecture Standards and Principles to identify and understand user needs, identify constraints and opportunities and provide recommendations/options for Alpha/Beta phases including solution design suggestions. We want to explore a new solution for collection, ingestion and storage of data to tackle existing issues, as well as others identified during discovery, and seek to discover if a more modern, efficient process could be used to meet the needs of all parties. Any examination of existing data analysis processes, including statistical production, is out of scope. Such processes are already established in Google Cloud Platform, using a combination of native database architecture and virtual machines hosting Microsoft SQL Server. Where the supplied staff will work London Where the supplied staff will work No specific location (for example they can work remotely) Who the organisation using the products or services is Department for Transport will be the owner and key users of any solution, with data providers being in local authorities and transport operators, who will use the service to provide data to DfT. Why the work is being done Data needs to be collected from LAs and other operators for both research and statistical purposes. The data is used for the production of National and Official Statistics (e.g. those available at https://www.gov.uk/government/collections/bus-statistics), as an evidential foundation for policy development, to respond to Parliamentary Questions, as well as research, queries from academics, journalists, and the general public, and forms a legal record of an incident. It is important that DfT has an efficient method to collect this data, whilst minimising the burden on data providers. There is often a legal requirement for data providers to provide the required information, however the Department is not able to require or indeed resourced to develop direct and/or automated data exchange between it and the data providers. Consequently, the Department relies on having an efficient system that can operate user-led surveys, with functionality that incentivises the user to complete the survey promptly and accurately, avoiding barriers that might cause delay or poor-quality responses that require follow-up actions. We currently use two main solutions to collect data for around 12-14 surveys from local authorities, bus and other transport operators each year; some of which are run multiple times each year. These include a bespoke product as well as SmartSurvey, which is a survey tool also used by wider DfT. The collections that are currently in scope and collected via these systems include: • Public service vehicles survey • Quarterly bus fares survey • Bus punctuality survey • Concessionary travel survey • Bus service operators grant survey • Taxi and private hire vehicle survey • Light rail and tram survey • Winter resilience survey • Highways inventory survey • Highways maintenance self-assessment • Road condition surveys Some examples of the questionnaires from these surveys are published online: • https://www.gov.uk/government/publications/bus-statistics-data-collection-forms • https://www.gov.uk/government/publications/taxi-and-private-hire-vehicle-statistics-information • https://www.gov.uk/government/publications/light-rail-and-tram-statistics-guidance All existing surveys will be required to be moved onto the new system by the statistical team that oversees the current approach, alongside the ability to collect new data collections in future. It is not uncommon for the Department to need to react promptly to an emerging policy need (for example a severe weather event) by issuing a new bespoke survey to respondents at notice of days, or possibly hours. Consequently, it is imperative that statisticians can independently create a new survey, issue it, and immediately start monitoring responses at pace. Similarly, the demand for data in the Department is growing, so it is possible more routine surveys will be required in the future, leading to a need for a solution that scale to meet that demand. The existing solutions and their lack of integration with DfT cloud infrastructure (hosted on Google Cloud Platform) are known to have a number of issues and limitations in their use, so we are keen to explore a new solution with enhanced capability compared to existing solutions available. The aim is to replace legacy systems and develop new solutions which will improve efficiency and better meet user needs. However, further understanding is needed to better understand user needs (both data providers and data users) and what technological and accessibility considerations there might be in adopting a new approach. It is essential that any new solution helps reduce the burden, both for the people supplying data to DfT as well as analysts managing and processing the data. The business problem you need to solve Whilst the process differs slightly for each survey, an example of a current high-level process is set out below: 1. A statistician will create a new survey or amend an existing survey on SmartSurvey. For surveys on the bespoke system, requests for changes to existing surveys and the creation of new surveys are submitted to implement. 2. Where applicable, usernames and passwords are manually created by DfT for each respondent using the bespoke system. These are then shared by email so login details can be set up with respondents so they can use these to provide data 3. An email is sent to a distribution list via email (maintained separately in Microsoft Excel by the team), including a link or details of the survey as required. If current contacts are no longer valid, the team will have to try and track down an alternative contact via any means possible. 4. Data providers complete the survey via the link provided (or log into the bespoke system using unique login details). 5. Statisticians download a Microsoft Excel .xls file from the bespoke system/SmartSurvey to the local PC drive. 6. Statisticians then use a SQL script to pull and transform the data into a database or read the data directly into R from the local drive. 7. Scripts are run to check the response rate and run some initial data validation. 8. For missing responses or large anomalous results spotted, the team will manually chase data providers. For example, for the 2022/23 public service vehicle data collection the team flagged 280 operators for a validation review, requiring emails and/or calls to discuss returns and request revisions where necessary. This level of follow up is also similar across the other collections. 9. Where edits are required from data providers, they log back into the system and make edits to their previous submission. 10. Steps 5 to 9 are repeated until the ingested data is to a satisfactory point. 11. The data should be in a complete state to allow further validation and analysis of the data. This process has many known difficulties, but there will likely be more that should be captured and considered as part of the discovery process. Known difficulties include: 1. Data currently collected is labour intensive to transform into a useable format for analysis. 2. It is labour intensive to monitor response rates and returns for surveys. 3. There is limited client-side validation. a. The level of validation currently differs depending on which software is used. SmartSurvey has no validation, whilst the bespoke system has some built in validation in the system. However, in all cases, the “true” final figures to compare against will be stored on separate DfT systems (hosted on Google Cloud Platform). 4. Users currently have limited ability to see past survey responses, which increases the burden on data providers. 5. There is no direct integration with any of DfT systems or cloud infrastructure (Google Cloud Platform). 6. Differences in organisational structures as well as staff churn can make it difficult to maintain the correct contacts to supply data for each survey. There is limited incentive for respondents to maintain up-to-date contact details and little to remind them that this is important beyond manually produced emails from the team. 7. No capability to visually demonstrate to users where data entered is obviously anomalous or out of step with recent trends at the point of entry (e.g. an ability for both parties to see how values compare against previous returns) We need to explore user needs, constraints and opportunities for a new solution to address these issues and develop a replacement to the existing software that is currently used. It will need the ability to collect and store data for existing surveys as well as any new data collections required in future. Both data providers and collectors require additional features and functionality than that provided by current solutions (e.g. to ensure compliance with the latest accessibility standards). It is essential that burden is minimised for all parties, so we need a clear understanding of these needs to test in future stages. First user type: Internal Statisticians First user type: Internal Policy official and other Analysts First user type: Internal DfT digital services and architects First user type: External Users Enter more details about this user type: Statisticians and others who work alongside them need to be able to have administrative rights to any potential solution. They need an accessible user interface that includes the ability to design and create new surveys as well as amend, view and delete existing surveys on the system. They need a mechanism to easily monitor the response rate for each survey, as well as integration with DfT cloud infrastructure to store historic and new data in a structured database for analysis. They need an ability to define validation rules that help the user enter the correct data first time. They also need a way to easily manage a list of responsible contacts for each survey with a model that looks to address the current issue of staff changes making it difficult to track down the correct people to respond to each survey. Enter more details about this user type: Policy officials and other analysts may require a way to access cuts of the clean and processed data to inform their evidence base for transport planning and policy initiatives. They will expect data to be submitted accurately first time and want to understand which operators/authorities have not submitted information. They will expect data to be easily linked to existing dashboards, for example those hosted in DfT instances of Power BI or R Shiny, and where relevant expect the information to update in near-real time. Enter more details about this user type: DfT digital services and architects will require demonstration that the solution meets architecture standards, principles and provide assurance that standards for digital projects have been met. Enter more details about this user type: External users include the data providers, which currently includes local authorities, and transport operators, but should have the capability to add new data providers if required in future. Different organisational structures within authorities means that it is likely that more than one user within an authority will need to be able to submit responses for any one survey at a time so user management will be required. They need an accessible user interface that allows access to an account where they can input data for new and existing surveys created by DfT. They should have the ability to review and edit previous entries submitted for surveys. Respondents need to know when a survey is launched, and deadlines are approaching. They additionally need sufficient information and/or prompting within the system to ensure that they understand the information that needs to be submitted (e.g. they understand the units required, or the method for deriving the metric of interest). If they accidentally enter a response that is fundamentally wrong (e.g. enter a text-based answer when a number is required) then they would expect to be directed to this error before submitting the final survey response. The data collected through these surveys is also of key interest to officials in other government departments. It is currently difficult to share validated data with other teams both within and outside of the department, particularly at pace.