The Weather Ledger project set out to prove that distributed ledger technology, smart contracts and internet of things sensors could be used in tandem to bring value and solve problems in the construction industry. So far we have proved these technologies can be used together in a system, and that that system can add value to the industry, however it appears that the problem we originally set out to solve was not as simple as we had initially thought.
That however has not deterred the consortium from striving to break down norms and use the learnings to create new ways for problems to be solved in the industry. The following article outlines what we have done so far and what we have learned.
Weather affects almost every project in the construction industry, and is responsible for, on average, 21% extensions to deadlines. This is serious as it decreases a contractors profit margin and pushes back the date when assets can become useful and revenue generating for Clients.
In the NEC contract weather risk is shared, through a simple (or so they said!) mechanism. If a weather event occurs more frequently than once in every 10 years, then that risk is the contractors, if it occurs less frequently than the 1 in 10 year value then it is the client’s risk. It appeared that many many disputes occur due to disagreements in data, in how impacts are calculated and how people interpret this rule. Although it is probably about 5% of disputes that are linked to this, this is still hundreds of millions of pounds of legal costs that could be avoided.
Our understanding of weather risk as a problem and the way it is linked with a variety of interlocking risk management tools; contracts, planning and insurance, evolved so much over the first few months of the project and continues to evolve.
Lesson 1: the problem is never that simple.
Month 1
The project started in pretty uncertain times, with lockdown being imposed on the UK and little understanding of the outcome. Nonetheless research started into the crux of the problem, looking at the contract itself and the surrounding procedures. This deskbased portion of the project laid the groundwork for the work to come and included research into the different blockchain technologies that we were to deploy once the smart contract implementation began.
Month 2
Once we had scoped the problem we started interviewing a large number of staff. This allowed us to dig down into the actual day to day of the problem. Digital Catapult held interviews to focus on the high level problem and our interviews focused on discovering where and how we could fit our solution in. There are too many names to list and thank them all here, but for those that took part, your contribution was absolutely invaluable. (Thank you!)
By this stage we decided to start creating wireframes to get ahead of schedule and test the directions the product could go in. It was initially assumed that this tool would encompass a number of different contractual elements, including the issuing of early warnings and the calculation of the impact of an event. However the first problem was already solved by another piece of established software and the second problem seemed too challenging to be tackled during the grant period itself. So we settled on just helping collect the weather data and automate a few parts of the contractual process.
The key piece of information learned during this period, which kept nagging in our minds, was: “the problem isn’t that the process around making a compensation event payment is broken, it's that the party does not wish to make the payment at all”.
This came up a number of times and eventually led to the project introducing expanded scope, which we’ll elaborate on in this article and in future articles.
Lesson 2: users don’t always know what they want. What if the best solution is in fact a complete step change from the norm?
Months 3-6
Construction companies worked hard to put in place safety protocols on social distancing to allow them back onto construction sites. Working with Peter Karney from the Digital Catapult we were able to create some IoT setups and deploy them to sites. We used Atmos 41 Sensors with LoraWan gateways and solar panels to trickle charge the batteries. This setup appeared to give us enough power and uptime, but later we found that the solar panels weren’t pulling as much power as the manufacturing guidance stated, causing issues of data loss.
We launched a basic app which site level users could use to see weather impacts forecasted as well as access the sensor data and contractual thresholds. Over summer this had varying levels of use as the weather was particularly kind, however the feedback was incredibly useful and saw several iterations of the app deployed.
Lesson 3: british winter offers too little sunlight for a totally off grid IoT setup.
Months 7-9
The key deliverables of the smart contract code and the DLT were deployed early and were confirmed to be up and running, even after some data loss issues from the Oracle solution we had built to ensure the signatory of the data was certain.
The app continued to add value through some early warnings of bad weather and by alerting the site team to the fact they had breached their thresholds. However the barrier to further rolling out of the smart contract solution was the cooperation of the clients. After very promising early chats with several people within the client organisations that we had been testing the solution with, there was a slow down. It is crucial for the success of smart contract solutions that key commercial people from both client and contractor are engaged. If they can jointly understand the benefits as well as agree that there is joint value and therefore a benefit to installing nodes on their servers, then the main hurdle to further rollout can be taken down.
For the solution to truly be a distributed ledger with proven operational smart contracts we needed to have the EHAB setup installed on computers owned by the two separate parties. We have made the setup of this as easy as downloading and installing any other piece of software, but it does take a coordination of a set of people (commercial and IT) who perhaps don’t usually formally work together.
The consortium will continue it’s work into 2021 and will publish a full set of reports and results around April, when the grant will officially come to an end.
We have so far set out to solve one problem. All the feedback and interest from those we have been talking with and interviewing have pointed us in another direction. So for the product EHAB is building we have learned that:
-- Avoiding risk is much more beneficial than optimising the reaction to it.
-- Current risk management processes can’t be fixed with one small automation, they need to be rethought entirely if there is to be any serious commercial adoption.
Other lessons learned:
Lesson 1: the problem is never that simple.
Lesson 2: users don’t always know what they want. What if the best solution is in fact a complete step change from the norm?
Lesson 3: british winter offers too little sunlight for a totally off grid IoT setup.