Flood Guidance Statement Next Generation Development

Description

Summary of the work Exciting project to re-imagine the software and infrastructure that supports a service aimed at creating and communicating Flood Risk Forecast information and data. It will support circa 16 Hydrometeorologists (Hydromet/s) in the UK to efficiently create and disseminate reports and data to a specified range of people and systems. Expected Contract Length New solution needs to be available for Dec 2016 at the latest Latest start date 04/07/2016 Budget Range Development budget is between £200,000 and £400,000 exc. VAT Indicative ongoing/support budget is between £10,000 and £80,000 exc. VAT Why the Work is Being Done Since the launch of the Flood Guidance Statement (FGS) in 2009, we've experienced many significant flooding events which have shaped and changed some of our customer requirements. During these floods our customers have highlighted that the FGS needs to include additional information to allow the flood risk situation to be presented more effectively using the PDF and also be available via a wider variety of channels and integrations. Key Drivers: • Minimising waste and workload in the production and dissemination of the FGS • Improvements in the communication of key information to responders • Modernise for ease of enhancements Problem to Be Solved This project is to replace the existing systems and infrastructure. The current FGS production tool is inefficient with Hydromet time being wasted on production instead of assessing the flood risk. Improve and modernise the FGS production tool, Flood Guidance Statement (FGS) in PDF, dissemination via email, voice and SMS and preferences management to meet new customer requirements. A key element is managing the solution sophistication to cost effectively deal with the future proofing and interface transition phasing. There are 4 existing system interfaces (across different organisations) that will need to be established as well as a further 3 new interfaces. Who Are the Users Discovery found we have the following user needs; • Hydrometerologist user need • Responder user need • Responder Preferences management user need • Customer Engagement Advisor user need • 3rd party data consumer need For further information on the user needs please follow this link ; https://tenders.metoffice.gov.uk/procontract/metoffice/supplier.nsf/link?OpenAgent&CONTRACT-A9WF-JYRZGN Work Already Done • Establishment of a backlog of user stories and categorised in to Must, Should, Coulds c200. • Created a solution architecture boundaries overview • Identified key discrete areas and deliverables Potential Phase 1: Dissemination of FGS data/information, FGS Production tool (including pdf report presentation). Potential Phase 2: Dissemination of FGS report, Analytics and preference management. • Created the as is business process and identified areas targeted for automation • Solicited and prioritised user group feedback. • Established project governance and FFC team. • Other product development occurring that we will need to ensure we align with to minimise cost duplication. Existing Team Project Exec, Project Sponsor and Snr Product Owner, EA Solution lead. All other roles to ensure successful delivery to come from supplier. Supplier to list roles Current Phase Alpha Skills & Experience • In mapping products • Creating mapping overlays • Leading on Technical, Solution and Infrastructure architecture • Working using Scrum and iterative development • User Interface design credentials and experience • Creating analytics capabilities • Business process re-engineering and automating workflow • Software development and integration • Testing (Automated and Manual) • Hosting and providing service capabilities as per ITIL framework • Familiarity with GOV.UK's design patterns and style guide - which we should follow • Driving overall delivery and liaising with other parties to ensure success • Hosting ability via a G-Cloud available partner • Industry standard technologies used Nice to Haves • Training and Knowledge Transfer • Experience of implementing the ability to draw curved lines as overlays to mapping software Work Location The team's primary location must be OFFSITE due to limited space within the Met Office. Working Arrangments The delivery lead to be onsite 1/2 days a week with other roles travelling to site/stay overnight as needed for workshops. Security Clearance Security clearance is not essential, but 'Baseline Personnel Security Standard' would be desirable for those team members required to travel to site. BPSS clearance may be requested at a later date if required. No. of Suppliers to Evaluate 5 Proposal Criteria • The proposed approach and methodology • How the approach or solution meets user needs • The proposed technical solution • Value for Money of the proposal Cultural Fit Criteria Work as a consistent team with our organisation, other stakeholders and suppliers Payment Approach Time and materials Evaluation Weighting Technical competence 60% Cultural fit 15% Price 25% Questions from Suppliers 1. Hi The DOS process is pretty new and not really well established yet. Are you looking for suppliers to provide a written response by the May 30th deadline or just answer the tick box questions for now? If you are looking for the written response by the 30th what format should this take as usually you provide a template? Will submission be like usual via the Met Office procurement portal? If not how? We are looking for suppliers to provide the answers to the "tick-box" questions for the 30th May. When the shortlisting has taken place, we will be in a position to provide the relevant information and any documents required for the written proposal. We anticipate that the proposal will be submitted via the Digital Marketplace portal. 2. Hi When this was originally tendered under DSF2 a number of additional documents were provided including the requirement backlog, will this be re-issued for this tender? There is a link provided in the requirements which has some additional documents which were not able to be attached via the Digital Marketplace. At this time we are reviewing our requirements backlog and would not wish to release it at this time. 3. Hi This notice appears to be for the Alpha phase but talks about solution delivery in December 2016. Are you only tendering for Alpha now, with others phases to follow, or is this tender to cover all phases between now and delivery? This notice is for the work between now and delivery in December 2016. The "alpha" section in the notice is indicative of the phase of development that we are currently at. 4. Hi When this was originally tendered under DSF it excluded the infrastructure which was to be purchased through G-Cloud. It looks likes this tender now include infrastructure, please can you confirm. In addition assuming it is included how many years during Live operation should suppliers quote for and what are the required service levels? DOS doesn't allow us to procure infrastructure directly through the framework, however we would like to have an indication of what running costs we might be expected to incur throughout the running of the solution. It is worth stressing that this is an indication of running cost and would not be evaluated. 5. Are you looking for suppliers to include disaster recovery/backup estimates? The requirements mention that there is currently a replicated system and if that was to malfunction, there is a manual solution in place. Will this be a requirement for the new system? Yes we require disaster recovery and business continuity to be considered as part of service. We hope to remove the need for the manual solution. 6. Is this building the system from the scratch or some parts are to be used? Is there anything reusable? The new system is required to be built from scratch. 7. Industry standard technologies to be used? What industry? Weather forecasting or IT? If weather - what are those standard technologies? Acknowledged and respected IT standards with no bespoke technology languages used. 8. Is "three days forecast" information (where open API is available) a subset of FGS information? If yes - how much more data and what kind is in the FGS? The 3-day forecast is a subset of FGS. It is extending to a 5-day forecast in the next couple of months. It is only the thumbnail maps from FGS and a small portion of text written specifically for the 3 day forecast that gets published. The FGS contains much more text and Area of Concern maps that do not get published via the 3 day forecast. 9. Mapping Tool - We would like more information about what it should be possible to draw on the map - what is the minimal set of features it needs to have The minimum features would be; 1. Overlays of annotations and symbols - including text, arrows, symbols, pictures, flood risk matrix. 2. Drawing - curved polygons and curved lines. 10. Category 1 and 2 responders (both group are not general public) - what is the difference? Any logic or rules on which reports to send to these groups? Category 1 and Category 2 responders can be treated the same. 11. What are responder preferences exactly? Currently responders (customers) can set preferences for how they want to receive the FGS (e-mail, SMS, VMS), which counties they wish to receive the FGS for, and whether to receive every day or when the FGS is yelllow or above (for their selected counties). 12. Is the responder site a separate site to production or can it be done on the same site? There isn't currently a responder site. 13. 3rd parties integration; We would like more detail how this should be done. Is it enough to just expose the API? Or should we keep some FTP files, emails etc? Do we have to it our API to existing systems or can we redesign it from scratch? Are we responsible to implement any of the 3rd party systems too? Can we have examples of existing integration files/protocols/APIs (JSON, XML, PDFs, etc). We require the new system to expose an API and keep producing legacy files. This project is not responsible for implementing the 3rd party systems, but supplier will be required to liaise and align thinking with the 3rd parties. 3rd parties have a mixture of capabilities (see solutions boundary diagram as part of brief) - some need legacy files and some will use the new API. There is no existing API, so it will need to be designed from scratch. Examples of existing files will be shared with those suppliers who are shortlisted. 14. Concurrent editing; Please could you provide us some use case for concurrent work scenario? As a Hydromet, I want to be able to edit the text at the same time as a colleague edits the maps. Or for both of us to be able to edit different sections of text at the same time. This will save time during the production process. 15. Task Launcher - What is this tool functionality? In relation to the FGS, this opens the file path on the MO drive where FGS files are saved from within the production tool. We open these files and then send them through a dissemination manager. 16. On the Production Tool attachment - there are some un-described tabs (FGS Timeline, FGS Report, PTRF Archive) - what do they do? PFRF archive - can view 3 day forecast text by issue date. FGS timeline - creates a composite document containing the 5 day images from every FGS issued between selected dates. FGS report - displays the current breakdown of FGS county colouring by source of flooding. I.e. the highest flood risk for each county for each source of flooding for each day 1 to 5. Used occasionally as an extra check that counties are coloured correctly when there are lots of polygons on FGS, prior to sending. 17. Are there any desired technologies? Or just web based front end built in any tech and any tech backend? There is no proposed technology and we require tenderers to propose relevant technology (but please note answer to question 7 - no bespoke tech language) 18. Supported devices - Do you require just responsive web app or any native mobile app ? We don't envisage working with an app - customers have expressed no interest in using an app to access the FGS. They will access FGS via 3rd party systems; e-mail (with pdf attachment); sms and audio messages. 19. Legacy System; Is it required to have both (old and new) systems working concurrently at the same time? Is data migration required? Is any backwards compatibility required? We require both systems to dual run for a suitable period (1 to 3 months). No data migration or backwards compatibility is required 20. Is it required to keep archive FGS reports and/or other files? Yes. Existing archive channels should be maintained, in addition to the consideration of how to store new digital data. 21. Can we have a look into current backlog stories ? Due to the sensitive nature of this information it will be shared to those suppliers who are shortlisted. 22. What are you expectations towards User Research, and UX/UI Design approach of application? Who is responsible for the usability aspects at the moment, and what kind of collaboration and working process you envision within the team regarding this area? User research and UX/UI design needs to be appropriate to the solution. Collaboration/user research will be with the FFC project team (& wider team when appropriate) and a small customer focus-group. 23. Are there any existing wireframes, application prototypes, sketches,  that could support our understanding of the design and user flow of new application? We do not have any wireframes etc and require the suppliers to develop new process / workflow automation / data digitisation as part of their solution