How it started
The story of XForms Cx began around summer of 2018 when the great folks at Bluewater met up with the great folks at a very large Ohio-based utility in the energy sector. At the time, we had already developed and deployed a custom XForms solution for the utility’s Construction Quality Assurance (QA) Department, wherein XForms Mobile was used to track the quality of construction by subcontractors building, adding, updating, and improving power plants. We had also previously built a project startup metrics software application for their Commissioning and Startup department using an earlier generation platform called Adesso.
The timing of this meeting was great. At the time, we were looking to narrow the focus of our generic product to a more specific vertical niche. One where we could leverage some of our industry knowledge and experience gained over the years building bespoke commissioning software for two major utilities in the US energy sector (serving a combined total of 13.7 million customers in the USA), and where we could apply our generic mobile forms platform—a very “horizontal” product—to solve a specific problem not otherwise solved very well by existing software tools.
Before XForms Cx, Bluewater had custom-built their own commissioning software system using a combination of Microsoft Excel and Microsoft Access. Their system had the ability to import device lists, assign form templates to devices, and print pre-populated commissioning forms for use in the field for data capture. While it worked great for many years, it lacked the ability to work on mobile devices (they were still using paper forms in the field), and they started hitting scalability issues due to the nature of the MS Access database engine powering it.
Initial design of the system
An initial meeting was conducted in Acworth, Georgia in late August 2018 to meet with the Bluewater team, review their existing system, its pros and cons, feature wish list of a new system, and core jobs-to-be-done by the software tool. I met various folks, including Mike Arrigo, Bret Bernhardt, and others.
After contractual documents were hashed out, design work was initiated using a low-fidelity wireframing tool called Balsamiq. A meeting was then set for September in Boston to review the initial designs, iterate on those, and get started building.
I first met with Bret Bernhardt in Boston at a WeWork coworking space for two days in late September, where I presented the intial mockups to him, and where we discussed the designs in detail. For the most part, the initial design seemed to fit well with Bret’s expectations. A few things here and there were modified, a better understanding of various workflows (like commodity curves) was captured, and additional needed functionalities were recorded.
I found an old picture I took of the WeWork space we met at.
Here’s a few screenshots of the initial designs we hashed out in that WeWork office space:
This is the original dashboard design. It conceptualized having both column charts and progress curves on the same screen. This design didn’t quite work because of screen size issues, so the column charts and progress curves were separated out into their own pages, and in the end, this “dashboard” was replaced with our current higher level dashboard screen.
This is the original design for how a device would be assigned a System Code, form templates, and % complete weights. The live version of this design looks similar in functionality.
Here’s a couple of original designs of the mobile app. While the features are roughly the same as the current implementation, the original design for the user interface is quite different from the live version in use today.
Lots of conversations and mockup iterations continued throughout the next few months. Around March 2019, another in-person meeting was set, this time in Waterville, Maine. I met up with Glenn Legacki, Aaron Civiello, and Bret Bernhardt for two days, with the main purpose of the meeting to review the updated design mockups, continue dialogue on system expectations, limitations, and priorities. This trip was a critical element in getting the system design fully mapped out before diving in too deep into the development cycle.
On that trip to Waterville, I flew into Portland, Maine, rented a car, and had lobster and beers with Glenn Legacki at this cool little joint.
I also made a few new friends. Here’s one of those new friends, Charlotte (Bret had a few dogs):
And I managed to do a drive-by of Colby College, which was nearby. A friend of mine from my days at Duke University, Tracy Gionfriddo, went to undergrad there, hence the curiosity to see the place. It was a brisk winter day…
It took longer than expected to roll out the first beta version of XForms Cx to Bluewater. It happened around the summer of 2020, right in the middle of the COVID pandemic, after many regularly-scheduled Zoom meeting with Aaron Civiello.
As with any beta software tool, bugs came up pretty quickly:
- Offline sync was problematic
- % complete calculations weren’t accurate and didn’t refresh quickly enough
- Photo capture didn’t work on newer versions of Android OS
- Printing pre-populated blank forms (for users not wanting to use a mobile device) didn’t work well enough and kept crashing the server side of the platform
- Importing device lists didn’t skip duplicate records
- Cloning a project caused problems with the device type hierarchy of the target project
- User permissions were too tight and needed adjustment
- Commodity curves only displayed monthly progress, not daily progress
- The punchlist feature was weak
During the rollout phase, communication with Aaron was accelerated. We had weekly Zoom meetings, with several phone calls and emails in between. Typically, we would try to roll out a new version of a particular problematic component of the platform by Monday morning each week, discuss and show the modification over a Zoom or MS Teams call with Aaron on Monday, have them test it in the field, and report results and issues before Friday. You could call these interations “weekly development sprints“.
Active debugging, real-world testing, ongoing weekly or bi-weekly meetings, and continuous software releases were completed over the next 9-12 months. Documentation was also created, and training sessions were performed.
By spring of 2021, the system was mostly operating at a relatively stable level, and Bluewater began deploying the system on real-world projects. Additional quirks and issues were resolved, and additional improvements were made, including an improved high-level dashboard.
By summer of 2021, other organizations started using the platform and requesting missing features, like for example a secondary % complete gauge, a form history feature, and a signature approval workflow. Field formatting and valid value improvements were also added to the form template designer tool.
Lesson #1 – Find an external team that has deep domain knowledge in the vertical space you are working in, and who have the patience to go through the pain
Building a product from scratch takes money and time. Especially time. Lots of time. Which is an opportunity cost for everyone involved. If your team doesn’t have the time or the patience to go through the fire of software development cycles, the product will not develop into what it could be.
Watching software mature from a beta product into a viable and marketable product that actually solves something well is like watching sausages being made in a factory: it’s pretty ugly, and not everyone can go through with it.
But the Bluewater team did just that. I cannot say enough good things about the Bluewater team and their dedication to spending the time necessary to see this product come together. Were it not for the following folks, XForms Cx would not exist:
- Perry Novak – Bluewater founder/owner
- Mike Arrigo – Approved the work order
- Kris Larouche – Facilitated the paperwork
- Bret Berhhardt – Designed the MS Access system, deep domain knowledge, assisted with the design of XForms Cx
- Glenn Legacki – Operations
- Aaron Civiello – The main man, who was patient with our development cycle, provided most of our bug review and testing, and who we worked with on an almost continous basis for more than 2 years and counting
- Kyle Fine – Field tester extraordinaire, critical in resolving form template and PDF formatting issues
- Les Zigler – Field tester
Lesson #2 – Get your product out into the real world quickly, and iterate often
If you want to truly debug something, you need to get it out into the field, with real field crews, on real projects. You can only go so far testing a product yourself and/or internally.
The Bluewater team started by testing the beta version of the system internally first. This allowed them to provide feedback quickly on the main issues without impacting real projects. After a substantial number of iterations and testing on “fake” projects, the Bluewater team felt good enough about the product to test on a real-live project. And even after tons of internal testing, when the software was deployed on a real project, things invariably went wrong. People tapped and clicked on things in a way that no one—not even the internal testers—had predicted.
Because now Bluewater was using the product on real, live projects for their own customers, the timing of bug fixes and completion of feature request was uber-critical. Product roadmap features were pushed aside and the focus was to quickly resolve issues for the Bluewater team.
Lesson #3 – Communicate
This lesson should be obvious. Always communicate in a timely manner with the folks spending their valuable time assisting with the progression of the product. Always. Always. Always. There’s a level of respect now between Aaron and I because we always communicate and always put ourselves in the other’s shoes when looking at the problem at hand. In fact, Aaron sent me these ah-mazing craft beers for Christmas last year.
Lesson #4 – It always takes more time than expected
Invariably, things happen, and your anticipated timeline for going live is tossed out the window. For us, we underestimated the effort involved with creating algorithms to calculate % complete, and the time needed to develop the mobile app and the underlying APIs, which had to be able to assign form templates to devices, and handle pre-population of the forms and assign % complete to them. That, and the offline sync component, which now had to handle the ability to sync specific device types flagged by the field user. We also had to spend an inordinate amount of time and effort on the pre-populated blank form templates, something that in the original designs was mostly an afterthought, but in the real world, became a very important feature because of the initial fear by the field teams of using mobile devices.
Oh yea, and then there was COVID.
Building a complex product like XForms Cx is a journey, not a destination. It’s something that is continually developing over time, not something fixed and static. So make sure you pick a fun team that will go on that journey with you, one that understands there will be bumps in the road, and that also understands the value of what you are building together. For us, we are glad that that team is Bluewater.
If you want to learn more about Bluewater, visit their website: https://bluewaterenergyinc.com/
Want to learn more about XForms Cx?
Tap/click on the button below.