9 April 2019
After reading the recent blogs of our Delft-FEWS Product Manager and a Delft-FEWS Software Developer, I can imagine you might like to read some more about the role of the Delft-FEWS project managers. As Subject Matter Experts (SME’s), hydrology in my case, we have a specific role in our Delft-FEWS related projects at Deltares.
In an operational forecasting project, an important activity of a project manager is to make the project team understand what the client wants and what role Delft-FEWS can play in the clients Ways of Working (WoW). It is therefore important that with new Delft-FEWS developments, the software developers understand how the new to develop functionality will be used by the client. This is most often an iterative process where functionality is discussed with the client and where developments are released through prototypes; an agile development process.
In this blog an example is presented of a trip we had some weeks ago to Birmingham. Delft-FEWS is currently being implemented as the Core Forecasting Engine for the National Future Flood forecasting System (FFFS). The FFFS is the new consolidated nationally standardized flood forecasting system for the Environment Agency in England, integrating eight regional systems into one. The system supports both flood forecasting services as well as Bathing Water Quality and Hydromet services.
One of the key functionalities in the FFFS project is to make more efficient use of thresholds and integrate these within warnings sent out in CAP format by the Flood Warning System (FWS). These threshold functions will be developed within the FFFS project, but the Bureau of Meteorology is also involved through a Memorandum of Understanding. One of the objectives of the MoU with the Bureau is to look at synergies in the flood forecasting system and the service development and to build plans for tangible functionality that both the Environment Agency and the Bureau of Meteorology will benefit from.
For the Deltares team to understand how thresholds are used in the current forecasting and warning systems, and what the future ideas are, the EA was so helpful as to organise “A day in the life of a Monitoring and Forecasting Duty Officer”. The team consisted of Ian Clayton (EA), Simon Pierotti (BoM), Erik Pelgrim (Deltares software developer), Martijn Kwant (Deltares SME) and myself.
The team at the WMD SWWM Fradley Incident Room (from Ian Clayton, EA)
We spent the morning with the Solihull Centre Flood Forecasting Team sharing how flood forecasts are generated and provided to the customers now and in the future. This included the role of thresholds and scenarios and how they are communicated and fed through to National and Area Incident Rooms. In the afternoon we spent time in the WMD SWWM Fradley Incident Room, sharing how the flood forecasting service supports ConOps and Incident Response, and how Flood Warnings are issued to customers including the decision making processes.
Next day, Simon presented the Bureau's new ideas on Automated Alerts for Fast Responding Catchments or Fast Responding Waterway Automated Alerting. The Bureau currently provides warning services for quick response catchments and wants to improve their service with Risk-Based Alerts and Response messaging. One result of this project is the need to build a risk response matrix in collaboration with SES for each location. For Delft-FEWS this means that observed and forecasted rainfall and water levels need to be combined within the threshold crossing functionality.
Graph of the relation between threshold crossing and alerting (from Simon Pierotti, BoM)
For the Deltares team members, the most important “disappointing” learning experience was that flood forecasting does involve more than only Delft-FEWS. Delft-FEWS is used to provide some of the information in the incident communication process. A threshold is not only an icon on the map or a line in the graph, but used as a trigger for further actions. Communicating the urgency and certainty of threshold crossings is of great importance as well as receiving feedback from the warning systems where warnings have been sent out to the customers. This all leads to very interesting ideas for new functionality that will drive efficiencies in functionality for users.
It is now up to the Deltares team to prepare a new FFFS prototype for next month’s workshop. This will include integration of the Delft-FEWS Peak Height (level correlations) functionality with threshold displays in graphs, and feedback from imported warning CAP (Common Alerting Protocol) messages with threshold crossings in the threshold display. All of this configured efficiently in a national system, where a display of national overviews is as important as registering the exact time of individual or combined threshold crossings for post-event analysis.
Going back to the title of my blog “A threshold is not a horizontal line in a graph”, as a project manager working with Delft-FEWS for 20 years in operational flood forecasting projects, I can say there is still an important role for us SME’s. We make sure that the ways of working of the Delft-FEWS community users is integrated into the Delft-FEWS software. This makes Delft-FEWS not a collection of software features but an efficient software tool in the users daily work. It's this combination of agile software development that makes Delft-FEWS such a unique product.
Marc van Dijk