Remote is dead. Long live remote. Lessons learned from running an innovation project from the home office.

Nicolas Waern - Digital Twin Specialist https://www.linkedin.com/in/nicolaswaern/ https://twitter.com/BuildWhisperer Contributing Editor

[an error occurred while processing this directive]

Late from the beginning

My company WINNIIO won this innovation tender a year ago where a municipality wanted someone to create something that didn’t necessarily exist yet. The intent was to reduce the CO2 footprint for three schools with an innovative product for radiator control.

The project was supposed to start at the end of January, but started in Late April. We were already late coming out the gates. And we were supposed to come up with a new product before the summer so that we could ship it to the three schools and install it before the winter season started.

This of course didn’t happen. I’ll spare you of some of the earlier the details and focus more on the lessons learned. This was a completely new product that was put together with pieces from different parts of the world with teams dispersed on 3 continents.

“Get out there on site and work from room to room to room, to get everything done with remote teams working alongside people in the building. Not in 30 minutes per day, make sure to get the whole system up and running directly. Take the time.“

The stakeholders

-        WINNIIO as the solution provider.

-        Customer, real estate owner

-        Founder of an IoT company with an open source IoT-tool kit, 20 patents in smart grid areas
(Based in California)

-        3^rd party Intelligent District Heating platform

-        OEM of actuators for radiators

-        Energy advisor

-        Users of the schools (principal mainly)

-        Local fibre optics company

The story

This was during peak Covid, so we did not have that much choice but to start off with remote ways of working. I did not really see this as a problem, and we met in teams once a week but of course worked in between the meetings. This was not that much of a problem in the early stages of the project, but all the lag time between stakeholders was building up to a problem at the end.

-        We vetted about 4 different wireless/IoT options and were about to go with one of them. But a person close to the project had said that this specific project was a pain to work with so that was disqualified based on those reasons. Good or bad, but it’s never good to start in an up-hill battle.

-        Since I am a big Digital Twin fan, we turned the drawings into 3D models

-        We then chose the actuator model based on the actuators that was already on the radiators

-        We chose the wireless mesh stack because of its edge capabilities. I personally knew the founder from before and having installed the tech in data centers.

-        We sent the actuators to the US to create a new product from scratch

-        The actuators were BACnet/Modbus compliant and originally designed for larger valves, not radiator valves. But this was an innovation project, so we used them for its ability to troubleshoot more granularly than what was common.

-        The founder of the IoT company went out of his way to design a new product, find housings, and test this at their test bench with a couple of samples.

-        We made it work and had to source everything during peak Covid and get it delivered to the smallest school to try it out

-        Meanwhile the developer who was supposed to work on getting to know the stack during summer couldn’t get it done so we were also behind on that front
(in all fairness, it was an impossible task for one person to do, and at a junior level)

-        After a lot of back and forth, with multiple trips to FEDEX to coordinate things between the OEM and California we had a prototype.

-       
We installed the prototype at the smallest school and if this worked, we were going to scale

-        it up and out to the two other schools, starting with the largest first.

-        We had just started with a new dev team, with a new stack, modified to work with NODE-Red, with a new project, completely distributed. It was a recipe for… success, but with a lot of pitfalls.

-        The head developer assured that everything looked great and we could start rolling it out

-        We got the sensors, the new smart hub, the whole IoT-solution 3 days before installing it

-        The end customer hired local installers who installed everything based on installation instructions that were far from stellar

-        We didn’t test the system when they were there because I thought it would just be plug and play (it wasn’t).

So far so good. But when everything was installed, it proved to be a challenge to correct small problems in the building.

-        The customer did not have dedicated people to work with us on this, so they had to take time from people who had regular day jobs, albeit focusing on technical asset management and IT related areas

-        New stack, new developers, new everything lead to a lot of small problems

-        We thought we had everything up and running from the first small school, but we did not

-        The instructions on how to pair the actuators with the radiators to the correct Modbus ID was everything but simple

-        The instructions from the OEM on how to pair it was lacking information and we had paired everything with wrong ID’s. Which meant that we couldn’t control the radiators

-        Innovation - Everything was shipped directly from factory which meant that some of the products were not working correctly (5%).

-        Working with wireless Modbus was great in theory, but for a dev-team that has never worked with Modbus, it was challenging at first to get an understanding of what needed to be done

-        And the only reason the developers needed to know about Modbus was because the IDs of the radiators weren’t configured correctly so we spend weeks thinking it was a software issue (we looked for errors in all the wrong places)

-        Wiring was not necessarily correct at all times

-        Batteries that were supposed to be infallible were in fact not working all the time

-        API integration was easy from one side, but because other 3^rd parties were not using standardized frameworks of integration that side took a lot longer than necessary

The right people, with the right information, in the same room

Everything is of course easier in hindsight. We have learned a lot. The most valuable lesson would be to get out there on site and work from room to room to room, to get everything done with remote teams working alongside people in the building. ALL the major stakeholders need to be there at the same time. Not in 30-minute intervals. Make sure to get the whole system up and running directly. Take the time.

à More on that here:
Digital Twins and the Metaverse

The thing is that if you can take 20 hours each from 10 core people that equates to 200 hours, over three days of install and testing. Do it.

The alternative could be 1 hour each from 10 people in a series of events, totalling 400 hours over the span of months. This is not covering actual software development work, but to get to that point where all the data is flowing.

-        Have a communication plan to get the right information out to the right stakeholders

-        Put the right people, with the right tools, and the right information together as fast as possible and work together

-        Take meetings, and only use emails for information about decisions being made in meetings

-        If you know what you should do, don’t wait to do it

-        Time is everything. Get it installed, and working, whatever it takes.

-        Get out there on site and work from room to room to room, to get everything done

-        of wasting time checking too much, exchange it for a new one that works and figure out why it’s not working afterwards

-        Ockham’s razor strategy in testing everything, and testing fast, which infers simple and direct explanations first.

-        Continuous communication and do not over-sell the project early on. Especially if it’s an innovation project.

-        One throat to choak. Take care of the install and minimize the amount of hands-on deck as much as possible.

-        Open is not necessarily amazing if it’s not interoperable.

-        The customer wants stuff that works. No one cares about taxonomies, ontologies, AI, machine learning, wireless mesh etc etc.

3-2-1…. Conclusion

Innovation is not easy. Especially not during a pandemic.

But it’s worth it. Being out on site. And telling a developer on the other side of the world to send a command to open the valve of a radiator in front of you. Through wireless Modbus.

And for them to count down from 3…2…1… open valve! And to see the orange light turn on at the same second on the actuator. And to feel the heat of warm water flowing into the radiator.

That is as hot as it can be.

It has not been easy. But it has been worth it. We are now able to control 100s of radiators in real-time to open close, check return temperature. And for the context of CO2 sensoring, motion detection, windows open and closed, temperature/humidity to tell us what to do and when.

The benefits across the 3/30/300 are immense. And together with self-learning aspects and a digital twin approach, I think this will be something interesting for the owner to work with.

Being able to do things remote at any given point in time is a prerequisite for successful solutions today. But it’s important not to lose sight of the work that has to be done in the real world. Physical presence was a key factor here, and it’s a combination of remote teams, working with boots on the ground that will be a winning combination. Most likely, assisted with modern tools, used in just the right order.

If you want to know what the future will do in a week, a month, a year from now? Subscribe to Beyond Buildings and find out. And if you want to create the future before everyone else? Reach out to me and we’ll make it happen!

Sincerely,

Nicolas Waern
CEO & Founder at WINNIIO Consulting

Ceo@winniio.io

Nicolas Waern is the CEO, Strategy & Innovation Leader, and a Digital Twin Implementation Specialist at the consulting firm WINNIIO. He is a firm believer that the Real Estate Industry needs more of a lifecycle focus where we need to go Beyond Buildings and come back with an understanding what tools and technology we could use. And to solve the jobs to be done, together, with an open mindset.

Nicolas is working with leaders in several industries to understand how they can succeed in the age of AI. Predicting what the world will do in a week, a month, a year from now and to best utilize strategies and solutions that pass the test of time. He does this through a Digitalization- on Demand approach for anyone that needs to change before they have to.

Nicolas is also a Podcast Creator & Newsletter Editor for Beyond Buildings
Thought Leader regarding Smart Buildings & Building Automation for AutomatedBuildings
Speaker and Influencer Event Streaming Platforms as the Holy Grail for Industry 4.0 Applications
Subject Matter Expert Real Estate Digitalization Proptech Digitalization Expert
Active Member of Digital Twin working groups Digital Twin Subject Matter Expert