PPRO/004/009/040 - Renewable Transport Fuel Obligation (RTFO) System Development

Tender description

Summary of the work • Enhance existing ROS to meet user needs and new legislative requirements; • Build new system/module for a GHG mechanism; • Enhance development capability for ROS/GHG system(s) - measured by improvedresponsiveness to changes and maintainability. • Work complete when live in production environment. Additional information on requirements at this link. Latest start date 10 April 2017 Budget Range £250,000-£450,000 for Alpha Delivery and ROS system enhancements. The Supplier shall provide a combined overall price for all phases of Delivery through Alpha, Beta and into live, noting that Alpha is capped at £450,000.£250,000-£450,000 for Alpha Delivery and ROS system enhancements. The Supplier shall provide a combined overall price for all phases of Delivery through Alpha, Beta and into live, noting that Alpha is capped at £450,000. Why the Work is Being Done The Renewable Transport Fuel Obligation (RTFO) Operating System (ROS) needs amendment to implement required legislative changes, both to the existing RTFO (due by September, via the RTFO Order) and also to introduce a new greenhouse gas (GHG) mechanism (by January 2018, via the GHG Emissions Reporting Regulations). Problem to Be Solved The current system, which runs the RTFO scheme, (ROS) needs amendment to incorporate changes to the RTFO to introduce new categories of certificates issued, traded and used for compliance, as well as targets and limits on their use. Additionally a new GHG scheme needs implementing (new system build), to issue credits that can be traded and used for compliance. Issuance will primarily be based upon ROS data, though some GHG credit types will use data entered directly. The supplier should indicate how they plan to implement a cost-effective, timely, Agile development (ROS currently has no continuous integration or automated tests). Who Are the Users The users are members of the RTFO Unit at DfT, who use the system to check applications from suppliers and grant certificates if fuel meets the necessary criteria, as well as fuel suppliers who enter data and verifiers who upload assurance reports, which provide evidence for DfT to check applications, and traders who transfer certificates to other users. DfT users need to check suppliers’ compliance with new legislative requirements, targets and limits, and issue certificates and GHG credits where compliant. Current and new non-DfT users need to enter and upload required data and reports, and transfer certificates and credits. Early Market Engagement N/A Work Already Done A Discovery Phase has been carried out to understand user needs and scope options for development. Full details of the output from Discovery will be made available to the successful supplier. Existing Team There is an existing core team of three individuals, comprising a delivery lead (20% of time), a delivery manager (75% of time) and a product owner/ business representative (25% of time). N.B As part of their submission the supplier will need to provide an additional business analyst to oversee the development, reporting directly to the DfT business team and acting as an interface with the development team to communicate user / business needs and prioritise work. Current Phase Alpha Skills & Experience • Demonstrable experience of Microsoft stack (Windows 7 and 10) • Demonstrable experience of Windows server / SQL server 2012 • Demonstrable experience of Internet Information Services (IIS) • Demonstrable experience of .Net version 4 • Demonstrable experience of Crystal reports version 11 • Proven experience of Agile project delivery • Demonstrable evidence of meeting Government security requirements, i.e. Cyber Security standards Nice to Haves • Demonstrable experience of utilising Open source technologies to affect change. • Demonstrable experience in utilising Cloud technologies • Proven experience of delivering upgrade of complex IT systems • Proven experience of delivering new systems development • Demonstrable evidence of a robust Risk management process, including risk identification, mitigations and governance Work Location The development needs to take place in bidder’s offices using their IT infrastructure for development and test. The production environment will be DfT hosting / cloud based. However, as part of the development / deployment, the supplier may need to spend some time working in DfT’s office (Great Minster House, 33 Horseferry Road, London SW1P 4DR). Working Arrangments The project needs to be developed to required timescales, the supplier should propose how to resource the project to best meet these milestones. DfT staff work normal office hours, it is expected that the supplier will fit in with these hours with regard to interactions they need to have with the staff. The team for Alpha delivery will need to work 5 days a week for 6-8 weeks. Any expenses incurred will need to be evidenced and paid in accordance with DfT rates. Security Clearance As a minimum, suppliers will have BPSS clearance in place for each team member identified in their proposal. Suppliers will be required to evidence this as part of their submission. No. of Suppliers to Evaluate 6 Proposal Criteria • Technical solution • Approach and Testing methodology / strategy • How the approach or solution meets Government Digital Service requirements • Estimated timeframes for the work • How they’ve identified risks and dependencies and offered approaches to manage them • Team structure • Value for money Cultural Fit Criteria • Experience of working as a team with our organisation and other suppliers, adjusting their approach to meet the needs of the organisation • Experience of transparent and collaborative decision making • Experience of taking responsibility for their work and resolving problems effectively • Experience of sharing knowledge and skills with other team members at both local and Departmental level Payment Approach Capped time and materials Evaluation Weighting Technical competence 60% Cultural fit 20% Price 20% Questions from Suppliers 1. in the summary of work you mention "Additional information on requirements at this link." should there be a link? Please use the following link: https://docs.google.com/document/d/1rlHOhOMEeQ_iYrOiyk26aQiCZz6cSxlK_pF7SobwOuY/edit?usp=sharing 2. In the brief, it mentions experience of using Microsoft technologies, (Windows 7 and Windows 10). Our expectation was that the new GHG application and the existing ROS applications are web applications delivered through the browser. Is there a desktop requirement for this application? The current application is Web-based and the new one will be, but we need to ensure compatibility with our Web browser: we need to be able to access them through the operating systems in DfT with IE 11 upwards. 3. Could you explain the relevance of the first essential requirement regarding Windows 7 and 10. We have assumed that the existing ROS system is browser based and the new “system/module” will be the same. Further to that we presume non-DfT users may use other operating systems e.g. macOS. The current application is Web-based and the new one will be, but we need to ensure compatibility with our Web browser: we need to be able to access them through the operating systems in DfT with IE 11 upwards. It is anticipated that some external users may use other OS. 4. What is the deadline for the written proposal? The first stage will see suppliers submitting evidence to demonstrate their capabilities in meeting the essential and nice to have skills. Those who pass this stage will be asked to submit their written proposals, case studies, etc. The deadline for this will be Friday 24th March. 5. Thanks for your previous answer about the final deadline. Could you also tell us the timelines for the presentation. Presentations would happen post evaluation and would only be applicable to suppliers whose submissions had met to desired standard. 6. Could you clarify the scope of the work. Is the intention to a) conduct Alpha for both the existing system changes and the new system/module or b) to fully develop the existing system changes and conduct Alpha for the new system/module? Broadly, it’s “b”: we require enhancement to the existing system (ROS) and an alpha phase to design a new (GHG) system. 7. ROS currently has no continuous integration or automated tests”. Are these required? If so, are they required for both the legacy system and new GHG system? Yes for both Legacy and new GHG system 8. With regards to the proposed payment approach being capped time and materials. Could you please confirmed that you intend the work to be performed against a prioritised backlog and accept that some of the less important/non-essential requirements may not be delivered within the proposed budget. We can confirm that the work would need to be performed against a prioritised backlog and that that might have implications for what can be delivered within the proposed budget. 9. Can you tell us whether there is any additional information required at this stage beyond the 100 word matrices? Specifically, you mention that you want a budget in the proposal which we understand to mean that you want a budget at a later stage within a full proposal. At this stage there is no need to provide anything in addition to the 100 word matrices. You are correct in your understanding that the budget will form part of your proposal, which will be requested if successful in passing the initial skills sift. 10. You require "BPSS clearance in place for each team member". Would a DBS check be enough to cover this? DBS would not be sufficient: BPSS clearance is the minimum requirement. 11. Given the detail of the systems aren’t known to potential suppliers providing the requested ‘combined overall price for all phases of Delivery through Alpha, Beta and into live’ will be very difficult. How do DfT propose to score the pricing, and do they expect to work with an incumbent supplier? For clarity, the initial assessment / sift will be against the suppliers capabilities against the pre-defined essential and nice to have skills. To assist suppliers in making accurate pricing within their written proposals, which is the subsequent stage, a redacted copy of the output from discovery will be made available. It is expected that the wining supplier will work collaboratively with the incumbent provider to knowledge share and up-skill throughout the development phases. 12. Does the DfT have non-functional requirements for the new GHS system or will the supplier need to establish these? There are Government security standards which need to be adhered to; other non-functional requirements will need to be established. 13. Please could you summarise the key outputs of discovery, and whether any technology preferences have been established yet? No tech preferences have been identified and outputs from Discovery will be shared to suppliers who pass the Skills assessment. 14. The legacy system was implemented using a Microsoft stack. Do DfT intend to use the same technology stack for the new GHG system? If not, do DfT have an alternative technology stack in mind or any technology constraints suppliers should be aware of? We recognise that we have a Microsoft stack that is not preferred by Government Digital Service who recommend ‎open source technologies. We recognise that there are trade-offs between a homogeneous technology stack compared to having a more varied technology stack that may be better alighted to GDS principles. We leave it to the supplier to recommend in their tender which approach to take and their justification. 15. The legacy system was implemented using a Microsoft stack. Do DfT intend to use the same technology stack for the new GHG system? If not, do DfT have an alternative technology stack in mind or any technology constraints suppliers should be aware of? We recognise that we have a Microsoft stack that is not preferred by Government Digital Service who recommend ‎open source technologies. We recognise that there are trade-offs between a homogeneous technology stack compared to having a more varied technology stack that may be better alighted to GDS principles. We leave it to the supplier to recommend in their tender which approach to take and their justification. 16. Could you please update us on the lead time. Upon selection the supplier shall asses the priorities of the enhancements of the current ROS system and work required for Alpha development. It is possible that focus will be on system enhancements initially, however a parallel approach where both Alpha and enhancement work is undertaken is not out of the question. The proposed timelines for delivery are set out in the published advert. 17. Please could you provide an overview of the maturity of agile practices in-house (e.g. any use of DevOps). We note there is no automated testing or CI in place for the current solution – are there pockets of best practice elsewhere in the organisation that you would like to reuse, and do you have any CI technology preferences? The current maturity of Agile practices in DfT is low.  We are introducing a new Digital Service within the department which will drastically improve our capability in this area and introduce a more dev-ops style approach to identifying, building and running our own services.  This is expected to be in place in July this year, however the services that this new team will focus on have not yet been decided and will be developed over time.  As things stand we don’t have pockets of best practice which we would want to re-use for this project. 18. Please could you clarify high level user numbers and the transaction volumes? There are around 125 users and we’d estimate transaction volumes as 15,000 per year.  This is based on assuming a transaction is pressing a button to approve / reject / submit something etc.