8
ON THE MOVE DFI ANNOUNCES NEW CHAIR OF DRILLED SHAFT COMMITTEE Deep Foundations Institute announces David Graham, P.E., has been named chair of DFI’s Drilled Shaft Committee. He succeeds Paul Axtell, P.E., D.GE, Dan Brown and Associates. Graham is a senior engineer with Dan Brown and Associates in Chattanooga, Tennessee. He has more than 14 years of experience in the geotechnical engineering and construction industry. He has consulted on deep foundation design, load testing and construction
for many major bridges throughout the U.S., including several Mississippi River crossings and the Gordie Howe International Bridge currently under construction between Detroit, Michigan, and Windsor, Ontario. Graham is a licensed professional engineer in nine states and the District of Columbia. An active member of ASCE and DFI, Graham holds bachelor’s and master’s degrees in civil engineering from Auburn University. The Drilled Shaft Committee’s mission is advancing the state of the practice or
state of the art in design, construction, and quality verification of drilled shaft foundation systems. DFI is an international association of contractors, engineers, manufacturers, suppliers, academics and owners in the deep foundations industry. The organization’s multidisciplinary membership creates a consensus voice and a common vision for continual improvement in the planning, design and construction of deep foundations and excavations.
customer service, we would not increase software costs as our company grew, we could build something internally that could interface with QuickBooks, and we would be in control of our own data. Building an internal solution was our best option. 6. Financial considerations. What are the known costs associated with the solution? Can you break out hard and soft costs? Do you have a margin of safety built into your analysis? Understand the opportunity cost associated with the timeline. Example: The fixed costs of the status quo were easily quantified, but it came with substantial costs of putting our data to work. The costs of building an internal system became integrated with our internal IT team. By building a solution internally, we would eliminate yearly subscription costs and reduce the ongoing burden of per-user fees as we grew. 7. Postmortem. Once implemented, review the decision and process with your team. Has the problem been solved and is it still the best solution? Be sure to revisit this decision annually and be open to new opportunities. Example: We have been using our internally built system, RYZE, for five years and it has served us well. We saved tens of thousands of dollars by not paying subscription fees, and have used the data within our system to improve our business. Ryze works in parallel with QuickBooks, which has greatly reduced friction with our accounting team since it’s a commonly used program. We accomplished the switch without too much disruption to our existing systems and processes. Technology never stands still, and five years after our last big technology revamp, we find ourselves back at step one. Our company has grown significantly, technological factors have changed, and our internal capabilities have expanded. We are revisiting our current system and identifying a new set of problems to solve. I’m confident that by following the process we’ll be successful again and I would encourage other firms to try it out the next time they’re faced with such questions. Jesse Fortune, P.E., is CEO at Eclipse Engineering and is headquartered in Missoula, Montana. Connect with him on LinkedIn.
JESSE FORTUNE, from page 7
Example: Along with our accounting, leadership, and IT teams, we identified several possible solutions: Do nothing. Choose different proprietary software. Return to QuickBooks, which had been used before, with self-generated reports. Develop our own software. 3. Engage the logical brain. From the creative list, what solutions have the best chance of success? Which has the least risk? Balance the upside with the potential risk and identify your risk-adjusted return. Example: Making the software switch within an accounting system takes a tremendous amount of time, has a high level of risk, and is never as smooth as advertised. Change is clunky and data is not easily transferable. With change comes uncertainty which can be disruptive to business operations. The option to develop internal software was alluring as it would give us more control over our data, and we could focus on the specifics of the problem we were trying to solve. The risk could be quantified and if we were successful, our product may be useful to firms like ours. 4. Time. What is the time frame needed to find a solution? Can the timeframe be phased? Is this a short-term issue or do you have time to develop a permanent solution? How long will this solution be in place? Example: We had flexibility with our time requirement, since we were functioning with the current system and had no short-term time constraints. Therefore, we enjoyed the freedom to develop something internally. 5. Check your work. Is the solution identified solving the original problem? Meet with your team and confirm the solution meets the needs originally identified. Example: Developing our own solution came with some risk, but it posed real benefits: we would be our own
© Copyright 2023. Zweig Group. All rights reserved.
THE ZWEIG LETTER DECEMBER 18, 2023, ISSUE 1517
Made with FlippingBook flipbook maker