The shifts over the last several months have many people rethinking the necessity of face-to-face work. While we all miss people, companies across the country are reconsidering the work that has been done in person just because “that’s the way we’ve always done it.”
In some ways, we have been working remotely for decades. For example, nearly all of our programming is done off-site from the customer. We have even tuned PID loops remotely, even as far as working with customers overseas without travel. Remote startups are a different case.
Remote startups are on the riskier end of remote work. There are three main risks to consider.
Limited Information
Even with all the technology of conference calls and video conferencing, some things just cannot be replicated virtually. For example, a valve that is not functioning properly makes a particular sound that is noticeable to someone with the right experience if they are standing nearby. However, that same sound may not come through over a conference line. The person who is on site may not be aware of what the sound is or how to communicate it. Of course, a valve problem could have a small sound, but cause a large problem, including safety issues.
Communication
Virtual communication can leave gaps. There are very literal caps (“What’s that Jim? You’re breaking up every third word!”) and gaps in non-verbal communication (The words say “Yes, I understand” but the side glance says “No, I don’t.”)
Good startup teams should function like a championship team in the final. Each player should be able to work together and read each other’s moves. Smooth teamwork is essential when mistakes are costly and time is of the essence. When communication is limited – even slightly – by technology, it can increase the risk of mistakes.
Cost
At a quick glance, it may seem that remote startups are a cost-saving alternative. No flights or other travel fees. However, when remote startups are not absolutely necessary, this move is penny-wise and pound-foolish. The time spent completing a startup are highly leveraged hours. The production line is offline and there are many resources spending their time on that project and not attending to other things. If a remote startup takes even 10% longer than a typical startup, the cost of being out of production could easily outweigh travel costs.
A RECENT REMOTE STARTUP
With all these risks in mind, we nonetheless completed a remote startup earlier this year. It was an exceptional situation that happened right at the height of the coronavirus lockdowns. Our customer was implementing an upgrade including BCI CORE™, and they had timed it to coincide with a corporate-wide ERP migration. The facility was still running and the ERP migration would move forward – but interstate travel and strict no visitor policies would prevent the Bachelor Controls team from going onsite. Here is what we did to make the remote startup a success
Capable Onsite Resources
We have worked with this customer frequently in the past and were very familiar with their onsite staff. It is a larger facility with very capable technical resources. It is impossible to overemphasize how critical it was to have knowledgeable, technical resources in person at the startup. They need to be able to fill in the gaps if the conference line lagged for a second or two.
Multiple Virtual Platforms
Our team was also working remotely, not in one conference room. We used Teams Meeting to communicate between our own team and a WebEx meeting to interface with the customer. Because of our long term relationship with this customer, we already had VPN access to their platforms.
Planning and Procedures
Completing a remote FAT ahead of the startup with the same team members was crucial. We built a checklist for the startup jointly using BCI’s usual documentation and the checklist items that came out of the remote FAT. Having a “rehearsal” of sorts and a grounding document to work from made the process much smoother.
Expertise
In addition to very capable onsite resources, some of the most experienced engineers at Bachelor Controls worked on this remote startup. This was a complex project happening in a very complex situation – it was not the time for a new engineer to try their hand at their first startup. We had a PLC expert engineer, and HMI expert engineer, and our lead BCI CORE™ programmer all involved as part of our team.
This remote startup, thankfully, went well and was a success. However, when one of the remote startup teams was asked if he would do it again, he said, “I don’t recommend it!”
So, when are remote startups a good idea? In most cases, they’re not. But in very exceptional circumstances, with the right expertise, it can happen.
