Welcome to part three of our blog series detailing the highs and lows of the network lifecycle. In the first installment, I shared my experiences supporting a nationwide fiber-to-the-home (FTTH) buildout with the West Coast Company (WCC). While, in the second installment, I dove into the significance of strategic planning.
As for engineering, where to begin on this one?
Engineering is one of the most difficult items to address as companies consider building at-scale. The primary stumbling block we have is primarily attributed to people. Prior to my coming to work for 3-GIS my entire career was focused on supporting engineering companies and workflows.
Before joining 3-GIS, I supported engineering services related to limestone exploration, permitting, railroad bridge design, electric and gas modeling, superfund site permits, civil/site design, and stormwater permitting to name a few. Interestingly, all these experiences influenced how we approached WCC’s project, especially as we focused our efforts on ensuring the engineering output aligned to what was needed for both engineering and construction.
Generating a design via 3-GIS innately means that we create the designs inside of a GIS database powered by Esri. I have been working inside of Esri-based technology for almost 3 decades. Given my historical experience working for engineering companies, I know there would have to be a compromise in terms of detail in the final output.
Those working in the engineering field are accustomed to creating network designs using CAD-based technologies. While these technologies offer the ability to create incredible detail as it relates to the drawing, the common drawback is that most of these designs are stored in a file-based system, and, at the time, there was not a robust, web-based technology that allowed for global collaboration.
We had to overcome the challenges associated with this “difference” with design users of the system, but, more importantly, the users of the output. The typical users relying on the output (paper drawings) included contractors, field technicians, and permitting authorities. Getting buy-in from the output’s stakeholders posed our biggest challenge to date.
For the contractor, we had to establish a format that was consistent with the packages they were used to seeing generated from CAD-based technologies. This required some convincing, both in terms of communicating a new way to read the drawing to ensure they understood what and where to build and the necessity to use the output by work type.
Underground crews received specialized drawings, while the overhead crews received a different format entirely. The goal was to match the output to the work being performed and provide those details necessary to complete the task. The permitting authorities we certainly challenging at first, as each municipality, state, and national permitting agency had varying requirements in terms of submittals.
Once we understood these requirements and could properly document the network elements to be permitted, these authorities became some of our biggest proponents! Surprisingly, they began to appreciate the consistency we could generate from the design database as opposed to receiving individualized CAD drawings that took on the personality of the drafter. This led to faster approvals and ultimately to more timely mobilization for construction.
Engineering may be a challenging step in the network lifecycle, but its importance cannot be understated. Recognizing the interoperability between the stages of the network lifecycle, engineering is another stage that must be appropriately synthesized in a project and handled efficiently. While it does not complete the process, engineering offers another route for optimization that companies can embrace as they seek to expand.
