Department for Transport Connectivity Tool

Description

Work done so far The team has undertaken a discovery phase, and completed its Alpha assessment in February 2024, with amber recommendations that informed our Beta workstreams. These improvements included ensuring the service more fully addressed user needs and requirements. The Tool has subsequently passed its Beta assessment so is in private Beta. After the Connectivity Tool’s launch we are working to embed it in the planning policy landscape. We have a future live assessment planned but don’t anticipate going for this until the service is fully implemented, upcoming development activities are complete, and the Connectivity Tool moves towards business as usual. The service has been developed using the Svelte framework with a combination of MapLibre and PMTiles for the mapping services. It is deployed as a docker image with GCP’s Cloud Run service and interacts with backend Cloud Run hosted Rust/Python APIs to perform more complex services. Which phase the project is in Beta Existing team The supplier will be working with the Connectivity Tool a multidisciplinary project team from DfT planning policy, PMO and data science. Senior Responsible Owner: Responsible for delivery of the project’s benefits and ensuring alignment to Secure by Design principles. Head of Planning Policy / Product Owner: Leading Connectivity Tool team, setting overall goals and objectives, translating these into the Tools specifications and development. Engaging local authorities and the planning industry to embed the Tool into guidance. Delivery Manager: Leading the Tool’s project management, driving delivery, shaping the project management approach and governance. Head Data Analyst: Responsible for the Tool’s data, application in the Tool, sound methodological approach, maintenance and updates. Policy Advisor: Supporting the Product Owner, leading engagement, driving policy application, driving implementation across Local Authorities. Senior Project Manager / Service Owner: Ensuring approvals, reporting, contract management, risk and milestone tracking, budget tracking and schedule management is maintained. Responsible for reporting, planning, contract / supplier management and delivery management. Principal Data Scientist: Lead delivery and maintenance of data inputs to the Connectivity Tool and composition of methodology; back-end development. Software Developer: Responsible for the Tool’s data, clarifying the data supports policy objectives translating policy aims into the Tool’s development; back-end development. Project Support: Project management support, responsible for maintaining project documentation. Address where the work will be done Work can be undertaken remotely however we expect the supplier to work on-site when required (Great Minster House, 33 Horseferry Rd, Westminster, London SW1P 4DR) Working arrangements The supplier is expected to work full-time, 37 hours per week (7.4 hours per day), Monday to Friday. The supplier must be available/contactable during core hours, 10am to 4pm. 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. Provide more information about your security requirements: Baseline Personnel Security Standard (BPSS) Provide more information about your security requirements: Security Check (SC) Provide more information about your security requirements: • All supplier team members whose roles require them to access DfT’s GCP environments must have a valid Security Check (SC) level clearance in place. • Remaining team must have Baseline Personnel Security Standard (BPSS) • Shortlisted suppliers will be requested to complete the DfT’s Risk Ledger Assessment. The Supplier must confirm their solutions comply with the following technical principles and standards:   • DfT Architecture Principles (see uploaded docu-ment) • Technology Code of Practice   • Government Digital Standards   • Government Service Manual • National Cyber Security standards   • Secure by Design • Cloud Security principles   • Open Standards principles   • Web Content Accessibility Guidelines • Understanding accessibility requirements for public sector bodies - GOV.UK Open API specification:  • Swagger  • Gov Restful Open API  • Open-Source Code   • When code should be open or closed Latest start date 2025-09-01 Enter the expected contract length: 2 years Extension period: 1 year Write the term or acronym: Alpha - A phase of project delivery as defined in the Agile Delivery Section of the Gov.uk Service Manual. BPSS - Baseline Personnel Security Standard CD - Continuous Deployment CI - Continuous Integration CT - Connectivity Tool DfT - Department for Transport GCP - Google Cloud Platform Live - A phase of project delivery as defined in the Agile Delivery Section of the Gov.uk Service Manual PO - Purchase Order Public Beta - A phase of project delivery as defined in the Agile Delivery Section of the Gov.uk Service Manual SC - Security Check (SC) is a level of national security vetting (NSC) provided by the Protective Security Centre (PSC) across government SbD - Secure by Design - approach to increase the government’s cyber resilience and improve data sharing between organisations Are you prepared to show your budget details?: Yes Indicative maximum: 4200000 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 has developed a new tool, 'The Connectivity Tool', to enable users to explore how well-connected different parts of England and Wales are. Planning officials in local authorities will be able to use the tool to assess the suitability of potential residential development sites, in terms of how well they are connected to the destinations that people tend to visit. The tool has a simple geospatial interface that enables intuitive exploration of connectivity by different modes of travel and destination. This interface is built using the Svelte framework and deployed in GCP using Cloud Run. This work will encapsulate an important phase of user research and further development to feed into user driven updates and new Connectivity Tool functionalities. Users will begin using the Tool in earnest from Q2 2025 and expected that they will have requirements that they would like to add to the Tool alongside functionality identified during previous phases of development. We will consider and prioritise the development of these asks within a wider framework of delivering new elements through continuous improvements of the tool. Discovery phase to determine feasibility of and inform decisions on new functionalities, including user research to determine the next phase of development. Translating into clear requirements for development, scope design options ensuring user experience and needs are considered and integrated into the service Development of identified new features across the DevOps dev/test/prod pipeline. Delivery management of the supplier project team, delivering to time, cost and quality. Responsibility for development, maintenance and sup-port of the existing functionality that exists within the solution, meeting up-time requirements. Preparations for and taking the Connectivity Tool through the service assessment phases and engaging with DfT digital governance. Working with DfT data scientists to ensure change are aligned with the tools back end methodology Where the supplied staff will work London Where the supplied staff will work No specific location (for example they can work remotely) Why the work is being done Despite national and local planning policy seeking new development to be delivered in sustainable locations, many new schemes are located far from everyday services and in places that are poorly served by active travel and public transport. This is a result of no commonly agreed definition of a sustainable location between land use and transport decision makers. The missing evidence leads to uncertainty in policy terms and undermines both DfT and MHCLG strategic priorities, while creating significant local and national impacts. A metric embedded in policy for understanding how well-connected candidate sites for new developments are would fill this gap, ensuring that development is located in the right well-connected places and connected by the right sustainable infrastructure. This is why DfT has developed the Connectivity Tool. The work detailed in this specification is being undertaken to further develop the Tool to ensure that it continues to meet user requirements. The business problem you need to solve We are enhancing the Tool, focusing on expanding functionality and addressing user needs after the Tool has been launched. To do this we need a wide range of digital delivery expertise to undertake work from engaging users, identifying their needs through to applying these in front end development. Immediately, we are seeking to develop features that define land use, identify walking and cycling routes and will undertake discovery to understand a range of pre-identified functionalities. This ask needs to ensure the relevant roles to undertake this work including but not exclusive to the following functions: User needs – help us to build an understanding what users want, going beyond our core users, that can be used as the basis to inform further design and development; coming up with creative solutions to meet user needs. Connectivity Tool development – taking the user research and designs, developing into the service; applying extensive existing experience of developing geospatial applications. Have the ability to navigate DfT’s cloud infrastructure (GCP Google Cloud Platform), ensure good development processes including managing the Tools and testing environments; central code control, maintaining development standards; automate deployment; development operations (agile engineering / development operations) Ability to navigate DfT’s digital governance to ensure the Connectivity Tool goes through the relevant governance boards and meetings in a timely manner, during the Connectivity Tool’s development. Ensure clear understanding of information security and data protection and how this applies to the Tool and how we work with external organisations to maintain security requirements. Assurance – ensuring developers’ outputs work in the Connectivity Tool as intended Delivery – Responsible for working with product and service owner to define and agree what will be delivered, planning the sprints, *Please see attachments for more info. First user type: Local Authority Policy Planner: - assess connectivity of a potential site for development without training so more of my team can conduct this process Local Authority Transport Planner: - assess different sites against each other so that I can compare sites to find the most suitable one - understand the connectivity of all aspects of a person's journey so that I can understand what improvements need to be made Local Authority Developer Manager: - assess existing sites on various parameters so that I have the full information to make my decision on its suitability - understand how well a place is connected so that I can help decide what development location - communicate with developers the kind of mitigations are required to bring a development up to standard, so that I can ensure all developments are of the right quality Government Planning / Policy / Analysts: - Assessment of potential development sites - Informing cross-government policy and planning policy and strategy decisions - Provision of a common language for connectivity Other: - A range of groups such as academics, developers, interest groups for example who may want access to the Tool in the future. Questions and Clarifications 0. Could you please provide the name of the supplier who has done the Alpha? DfT undertook the Alpha phase, and Triad (with input from DfT) have taken the service to Public Beta. Last Updated: <strong>17 June 2025, 10:12</strong> 1. Regarding Essential skills and experience question #2: please would the authority explain how the 30 marks will be broken down against the following four aspects: 1. Providing demonstrable evidence of experience developing geospatial applications; 2. for transport and planning; 3. using preferred modern mapping technologies such as Mapbox GL, MapLibre, PMTiles or similar; 4. familiarity of the Svelte framework desirable. The 30 marks are allocated to the question as a whole. The 30 marks are not broken down to individual parts. Suppliers will need to evidence all points of the question. Last Updated: <strong>24 June 2025, 12:54</strong> 2. 1) What is the anticipated/available transition period from the current supplier? 2) Is the transition period allowed for in the current programme? 3) How will the transition period be costed for in the following tender stage? 4) Is the supplier expected to develop and create new cloud infrastructure on DfT’s Google Cloud Platform, or use existing infrastructure in dev, test, UAT and prod environments? 5) What Infrastructure as Code (if any) technology is used to deploy infrastructure on GCP? 6) What CI/CD technology is used on DfT’s Google Cloud Platform? 7) Will the supplier have access to and/or support from DfT’s cloud infrastructure and DevOps engineers? 1) We anticipate a 4 week handover period between new and existing supplier. 2) The transition period is considered in the current programme of works but we would expect the new supplier to minimise this period to ensure programme timings continue to be met. 3) Transition costs will not be evaluated as this will result in incumbent advantage. 4) Currently the project uses existing dev/test/prod environments. These will need maintenance and further works as required. We would expect the supplier to go through the required development steps. 5) Terraform/Terragrunt 6) GitHub workflows and GitHub actions 7) There will be limited access to DfT's cloud engineers as needed, f.e. to sort out IAM roles, setting up blank cloud workspaces for us to work in, etc. We would expect the supplier to have their own DevOps for the actual work required. Last Updated: <strong>2025-06-24T12:58:39.73772Z</strong> 3. Could we please confirm that responses should be 750 characters including spaces? That is correct. Stage 1 character count is set by CCS, DfT are unable to change this. Last Updated: <strong>2025-06-25T09:55:32.42218Z</strong> 4. Nice-to-have Q2: Who will be responsible for supporting back-end systems? Nice-to-have Q4: does "data sharing" in this context refer to sharing data within DfT or between users (e.g. Local Planning and Local Transport Authorities) or is it data sharing between DfT and users? DfT looks after the data and inputs that power the back end of the Connectivity Tool. The back-end setup—using Terraform, Terragrunt, and GitHub workflows/actions—might occasionally need input from the supplier. The supplier should take charge of the front-end development and make sure it’s built in sync with the back end, keeping everything aligned as the service evolves. Last Updated: <strong>26 June 2025, 16:59</strong>