Transport for the North (TfN)

Transport Operator Fares Data Capture, Build, Conversion and Publishing Tool – Alpha / Beta

Incomplete applications

9
Incomplete applications
5 SME, 4 large

Completed applications

4
Completed applications
4 SME, 0 large
Important dates
Opportunity attribute name Opportunity attribute value
Published Friday 15 February 2019
Deadline for asking questions Friday 22 February 2019 at 11:59pm GMT
Closing date for applications Friday 1 March 2019 at 11:59pm GMT

Overview

Overview
Opportunity attribute name Opportunity attribute value
Summary of the work To design, build, support and operate an online Fares Data Build Tool into Beta Public that captures, converts and combines transport fares and schedule data, and publishes it in an open API output in accordance with the UK NeTEx format. The initial contract SOW will be for Alpha requirements only.
Latest start date Monday 17 June 2019
Expected contract length 2 years
Location Yorkshire and the Humber
Organisation the work is for Transport for the North (TfN)
Budget range £300,000 - £500,000 excluding V.A.T. for the maximum duration of the two-year contract.

The Buyer expects the Alpha to cost between £140,000 and £180,000 excluding V.A.T.

About the work

About the work
Opportunity attribute name Opportunity attribute value
Why the work is being done A common challenge facing bus passengers – and cited as a barrier to use - is identifying the correct and best value fare for their planned journey in advance of travel.

TfN’s Integrated & Smart Travel Programme includes an initiative to collate, aggregate, convert to a common standard, and publish bus fares as open data to enhance customer information and facilitate multi-modal pan-northern travel. The open source nature of the data should encourage innovation in the market as well as helping to standardise the data offered.
Problem to be solved Fares and schedule data originate from discrete software systems held by operators and commonly contain insufficient references to enable matching and determination of fare values(s) for given journey legs. Data are held in different formats and are commonly not published as electronic data feeds.

TfN requires a National Fares Data Build Tool which matches fare stages to National Public Transport Access Nodes (NaPTAN), and publishes an open API in the UK NeTEx profile using national referencing. Users of the API will include third party journey planning providers and TfN. National usage of the tool is subject to a DfT decision.
Who the users are and what they need to do The Fares Data Build Tool is a Service for Operators and Local Authorities (who operate their own services) who do not currently have the technical or organisational capability to provide fares data in the UK NeTEx format. Different operators have different levels of technical expertise, so the tool should be cloud based and easy to understand and use via text file upload or API. No additional propriety software should be needed to run the solution.

Ongoing user research will be conducted by TfN to ensure that as the solution develops it aligns to the needs of the stakeholders.
Early market engagement In February 2018, the IST Programme completed market engagement to inform delivery and procurement of Phase 2 services, enabling TfN to understand supplier capabilities before TfN went to market.

Suppliers were invited to return questionnaires to TfN with feedback about TfN’s proposed requirement and their own organisations/solutions. Indicative costings were requested to inform our outline business case.

Representatives from 17 organisations joined the all-supplier ‘Face to Face’ meeting on 19 January 2019, with a further 25 representatives attending the session via WebEx (Market Engagement Session 2).

The focus of feedback was mainly technical and reflected on-going internal discussions about system design architecture, with some feedback on the commercial and procurement approach.

Feedback from the January 2019 market engagement has been used to inform this brief.
Any work that’s already been done A proprietary temporary solution is being developed as a stop gap to allow data to be generated while this system and the UK NeTEx profile are being developed. The supplier will need to work with the industry bodies, partners, and transport operators and be open to learn lessons and work collaboratively.

Further supporting information and detailed specification on the Fares Data Build Tool, follow the below steps:
Step 1: access https://khub.net/transport-for-the-north
Step 2: locate Public Library link at the bottom of the web page
Step 3: search document title: TfN IST P2 Fares DBT supporting information v0.2.pdf , published 15/02/19.
Existing team The Supplier will work with various TfN employees and stakeholders from DfT, Traveline, bus industry, local authorities and other users.

The Buyer will provide the following staff for Alpha to advise on Service requirements and supplement the delivery team:

PT – 1 x Service Manager
PT – 1 x User Research
PT – 1 x Quality Assurer
FT – 1 x Content Designer

At a minimum the Buyer expects the Supplier to provide the following roles for Alpha in accordance with the GDS Service Manual:

Agile Coach
Security Consultant
Delivery Manager
Designer
Developer
Technical Lead
Web Eng / Dev Ops
Current phase Alpha

Work setup

Work setup
Opportunity attribute name Opportunity attribute value
Address where the work will take place Suppliers can work remotely when developing and testing the solution / service.

The supplier must work at the following TfN offices when required:

Primary Location
- Ground Floor, West Gate, Grace St, Leeds, LS1 2R

Secondary Location
- 2nd Floor, 4 Piccadilly Place, Manchester, M1 3BN

The team will also be required to travel to other locations and agencies as required to meet users, e.g. operator or local transport authority offices.
Working arrangements The Supplier will need to structure and locate its team to deliver the solution within the requisite timelines. The Supplier will be required to attend meetings and to work from the Buyer’s offices from time to time.

The Supplier may be required to attend events or meetings with users around the country. Expenses will be paid in accordance with Framework and TfN policy.

This work is being done on an Agile basis and requirements may change during the course of the project. Changes to delivery timelines and budget in these cases will be agreed between the Buyer and Supplier.
Security clearance BPSS (Baseline Personnel Security Standard) is required at a minimum.

Additional information

Additional information
Opportunity attribute name Opportunity attribute value
Additional terms and conditions The solution will adhere to the Technology Code of Practice, Digital Service standards and will be developed using Agile Delivery as defined in the GDS Service manual.

The government has published open technology standards. These should be used where applicable to ensure greater interoperability.

Intellectual Property Rights (IPR) for the solution will be held by the Buyer subject to the Open Government License version 3.0. If the supplier wishes to use a different license, justification for doing so should be given, particularly when the licence would not be copy-left.

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Skills and experience
Opportunity attribute name Opportunity attribute value
Essential skills and experience
  • Experience of delivering Agile projects, delivering a MVP/proof of concept through Alpha successfully, delivering a robust beta product into 'live' and then handing over the service to a 3rd party.
  • Experience in service design, technical development, end-to-end testing and handover / transition of digital services, particularly in the public sector.
  • Experience of iterating a product in light of researching and working with a mix of user groups and stakeholders at all levels within organisations (ideally within transport).
  • Experience in following the Government’s Technology Code of Practice: good technology choices helping users and saving money. Ideally include coding in the open, and working with open standards and APIs.
  • Experience in delivering digital projects aligned with GDS Service Design Manual, Service Standard, and passing GDS service assessment. This includes Security Health Check, Penetration Testing, Assisted Digital and privacy standards.
  • Experience in robust risk management processes, including risk identification, mitigations and governance.
  • Experience of public transport, including transport data. This must include scheduling / fares across England (outside London) and real time information using standards such as TransXChange, NeTEx, NaPTAN, NOC, NPTG.
Nice-to-have skills and experience Experience of open data policy, the roles of the government and the open data community and the benefits this provides.

How suppliers will be evaluated

How suppliers will be evaluated
Opportunity attribute name Opportunity attribute value
How many suppliers to evaluate 6
Proposal criteria
  • Provide details on how your approach meets user needs including for data providers, local authorities and app developers [15%]
  • Provide details of your team structure, resource plan, and estimated resource days and rates expenditure by key activity for Alpha, Beta Private & Beta Public. CVs included in appendix. [15%]
  • What are the expected risks and dependencies you expect to encounter and suggest ways to manage them? [5%]
  • Provide details of demonstrating value for money, scalability, integration with wider open data and MaaS platforms, and ability to iterate during Live running in light of new requirements [5%]
  • Provide details on your experience designing and developing end to end solutions (including front and back end) through a range of previous work for customers on a similar scale [5%]
  • Provide details on previous project deliveries using the agile methodology [5%]
Cultural fit criteria
  • Provide details of examples where you have transferred knowledge/skills to Civil Servants [5%]
  • Provide details of your experience with working with stakeholders with low technical expertise [2.5%]
  • Provide details of your experience with working with Government bodies [2.5%]
Payment approach Capped time and materials
Assessment methods Written proposal
Evaluation weighting

Technical competence

50%

Cultural fit

10%

Price

40%

Questions asked by suppliers

Questions asked by suppliers
Supplier question Buyer answer
1. The requirements appear to be in opposition to an agile, iterative delivery, is this intentional? The 'Alpha' requirements in the supporting docs indicate that Alpha = Beta – Reporting, i.e. all functionality complete except reporting to be developed in the initial 3 months. Your budget also supports this, i.e. £180K in 3 month for build, which pays for a 4-man digital team for months. An additional £315K (£495 total) allows for £15K per month for 21 months post-development support and hosting of the completed build. Do you intend any development after the initial 3 months? The functionalities of the solution listed in the Supporting Information are core functionalities. TfN expect these core functionalities to form part of the Alpha prototype and ongoing iterations. As per GDS Service Manual, subject to Alpha criteria being met the prototype of the solution will be developed (including the stated TfN core functionalities) in beta phase.
2. The requirements appear to be in opposition to an agile, iterative delivery, is this intentional? The 'Alpha' requirements in the supporting docs indicate that Alpha = Beta – Reporting, i.e. all functionality complete except reporting to be developed in the initial 3 months. Your budget also supports this, i.e. £180K in 3 month for build, which pays for a 4-man digital team for 3 months. An additional £315K (£495 total) allows for £15K per month for 21 months post-development support and hosting of the completed build. Do you intend any development after the initial 3 months? The functionalities of the solution listed in the Supporting Information are core functionalities. TfN expect these core functionalities to form part of the Alpha prototype and ongoing iterations. As per GDS Service Manual, subject to Alpha criteria being met the prototype of the solution will be developed (including the stated TfN core functionalities) in beta phase.
3. Regarding the 'spreadsheet template' that will be provided to smaller operators, with the intention of those users filling in the spreadsheet template, and then uploading to the fares tool – has this spreadsheet template already been defined/designed, or do you intend the winning supplier to define and design the spreadsheet template? TfN expect the winning supplier to define and design the spreadsheet template in collaboration with advice and guidance from users (e.g. operators, partners, industry bodies).
4. Referencing Appendix C user story "I turn my paper fare table into a spreadsheet using the supplied template.. This is easier than I had feared as it’s quite clever.. matching of my route information to the fare table for me". Is the intention that the tool offers an interactive web-driven experience to users building their route information, or is the online tool merely an online gateway through which to upload a completed spreadsheet file? Or is the interactive element of validating a user's entries intended to only happen within an offline spreadsheet via spreadsheet macros etc? The solution needs to meet user needs, and that these will be validated during delivery. At the momenet TfN expect that the solution will offer (1) a web-driven experience enabling users to match fares to route and timetable data; and (2) an offline template/spreadsheet that users can use to upload fares information validation and matching to routes.
5. Referencing the detailed Input requirements, please confirm that you expect the tool to allow for the input of 7 different input types (3 currently undefined/format to be agreed, and 4 pre-existing input types), all within the initial 3 month development stage? Formats-to-be-agreed – 1: Spreadsheet upload template, 2: Existing operator fare tables, 3: In browser dynamic input. Pre-existing formats – 4: NaPTAN dataset, 5: ational Public Transport Gazetteer (NPTG), 6: Routes and timetable in TransXChange (TXC), 7: Import National Operator Codes (NOC). Are all the above import types to be implemented in the initial 3 months? As an absolute minimum requirement, Alpha should be one of the undefined (e.g. fare triangle csv) plus NaPTAN and TransXChange. This should be enough to demonstrate core functionality that can meet user requirements. Addtional operator inputs could be added during Beta. NPTG and NOC finishing touches (could potentially already be inferred from TXC and NaPTAN).