E2 | Predictive Maintenance, Lifecycle Thinking & AI in Public Infrastructure

Simon Davidoff brings decades of experience from AECOM and Siemens to a wide-ranging discussion on AI in transportation. He and Jim explore how lifecycle fragmentation, procurement processes, and organizational silos slow down innovation in public agencies. The conversation highlights incident response as a powerful use case for AI, emphasizing safety, ROI, and measurable impact. They also examine the tension between CapEx and OpEx, and how total cost of ownership thinking can unlock better decision-making. Finally, the episode considers how AI is transforming consulting firms and pushing the industry toward deeper lifecycle integration and predictive maintenance.
‍

Timestamps:

‍02:03 — Where the Transportation Lifecycle Breaks Down

‍02:28 — Digital Twins: Vision vs. Real-World Feasibility

‍03:07 — Why Incident Response Technology Is So Fragmented

‍04:06 — Procurement Barriers in Government & AI Adoption

‍07:01 — Piloting as a Strategy to Accelerate Innovation

‍09:18 — Business Case, ROI, and the Economics of Safety

‍12:37 — Measuring the Impact of Congestion & Incident Response

‍15:58 — Agile Deployment vs. Traditional Procurement Cycles

‍17:28 — Why Software Is Hard Inside AEC Firms

‍18:47 — AI’s Impact on Consulting Business Models

‍20:33 — Expanding into Operations & Maintenance Across the Lifecycle

‍22:21 — Predictive Maintenance & Real-World AI Use Cases

‍24:30 — Organizational Silos: CapEx vs. OpEx Challenges

‍26:16 — Executive Strategy, Total Cost of Ownership & Long-Term Thinking

‍

Jim: Welcome to At the Intersection. I’m your host, Jim Anderson, and today I’m joined by Simon Davidoff, former Global Digital Leader in Transportation at AECOM and former Head of Digital Services at Siemens. He has spent his career at the intersection of transportation and technology, which should make for a lively conversation. We’re also thrilled that Simon is an advisor to Beacon, and grateful to have his guidance as we build. Simon, welcome to the show.

Simon: Thanks, Jim. Great to be here.

Jim: I like to start things out quickly, so let’s do a lightning round. I want one- to three-word answers to a few questions. Favorite place you’ve traveled in the past year?

Simon: Puglia, Italy.

Jim: What age did you know transportation would be part of your path?

Simon: Thirty years old.

Jim: Favorite hobby outside of work?

Simon: Road cycling.

Jim: Red wine or white wine?

Simon: Red.

Jim: Title of a good book you’ve read in the past year?

Simon: The Waterman.

Jim: Finish the sentence: AI is blank.

Simon: Sustainable.

Jim: Alright, let’s move on. You and I have talked a lot about life cycles—both in your AECOM and Siemens days, and in transportation more broadly. DOTs talk about life cycles all the time: you plan, you design, you build, you operate, you maintain, you retire. Where does that thinking fall apart in practice? Think across your career, and then let’s hone in on transportation.

Simon: Where does it fall apart? I think the connection between design and operations and maintenance is not very clear. It’s becoming clearer with digital threads and digital twins, but the desk-bound design stage and the real-life operating stage are still somewhat disconnected.

Jim: Let’s talk about digital twins for a second. I love the concept—who wouldn’t? But in a world where we can’t even reliably get as-built drawings, is it realistic to imagine we can create a high-fidelity digital twin of the physical world? Can that even be done?

Simon: I think it can be done, Jim. It will take a lot of effort, innovation, and willpower to put into practice, but yes, it can be done.

Jim: I like your optimism. Let’s go do it.

Simon: One thing people sometimes overlook is the business case behind it. Do we really need a digital twin for, say, a bridge?

Jim: That’s a great point. One reason we don’t have good as-built drawings is that at the end of a project, there’s not much immediate economic value. Someone 20 years from now might wish they had them, but if I’m wrapping up the project now, it’s not a priority. That’s a helpful lens. Let’s talk about systems. When someone looks at incident response, the technology stack often treats it like 10 or 12 separate problems—ATMS, Google Maps, radios, phones, email, and so on. How do we end up with that kind of fragmentation? And what do we do about it?

Simon: We need interconnectivity between platforms and use cases. I think I know where you’re going—TMC React pulls together that fragmented set of knowledge bases. That’s why it’s so crisp and effective.

Jim: That’s a great answer. You mentioned the business case, and I’ll add procurement. You’ve worked with government agencies for most of your career, and procurement is a big piece of the puzzle. If you can’t procure it, it doesn’t matter how good it is. Talk to me about how much of the fragmentation is driven by procurement constraints versus technical limitations. Let’s try to bound the problem.

Simon: That’s a big question, Jim. Let’s take a transit agency. They are highly regulated in how they procure, and they often have to specify a solution in great detail before moving forward. That’s part of the problem. If AI-enabled SOP assistance is new, how do you define it in an RFI or RFP? It’s a challenge just to understand it, let alone specify it. So we come back to education—engineers and procurement teams need to work together to understand the problem before they can describe it and attract vendors.

Jim: That helps explain why government moves slowly. Not only are procurement cycles long, but you also have to wait for the space to stabilize enough to define it. In fast-moving areas like AI, that creates an impedance mismatch—one side is moving fast, the other isn’t built for that speed.

Simon: Exactly. So how do you shortcut that mismatch? I’ve seen agencies use piloting to de-risk procurement. Engineers can test solutions in controlled experiments, sometimes even asking providers to run pilots at no cost. That can open the door faster. AI requires experimentation, and piloting may help shorten the RFI/RFP process.

Jim: That’s interesting. But in AI, talent is expensive. If you’re running free pilots, you need funding to support that. It pushes you toward well-capitalized companies that can absorb those costs and recover them later. Fair summary?

Simon: Yes, it’s fair—and frustrating. It puts risk on the vendor or startup, which may feel unfair. But in a risk-averse sector, I don’t see another path right now. Over time, as AI solutions mature and become better understood, that may change.

Jim: From the private sector, we learned that people value what they pay for. Free pilots can sometimes lead to low engagement. That’s not ideal for collaboration.

Simon: True, but free pilots can at least open the door. Also, safety use cases are treated differently. If your solution improves safety, procurement has a different tone. Agencies care about ridership, experience, and above all, safety. If you align with that, it resonates strongly.

Jim: That makes sense. If you reduce incident response time, you improve safety. Crashes attract secondary events, so faster response reduces overall risk. And the ROI isn’t that hard to quantify once you understand the impact.

Simon: Exactly. You can measure reduced response times, fewer secondary accidents, lower emissions from congestion, and even the economic value of lost productivity. That should be eye-opening for decision-makers.

Jim: The Atlanta Regional Commission estimated congestion costs the region billions annually. People feel that intuitively. And frustration in traffic can lead to risky behavior, which compounds the problem.

Simon: There are many ways to tackle congestion and safety. You have one piece of the puzzle, but there are others—vehicle connectivity, road condition monitoring, and more. It will be interesting to see how these technologies interoperate. Agencies need help understanding how to combine them for greater impact.

Jim: People often think incident response is about how fast vehicles arrive, like ambulances. But much of the challenge is after that—clearing the scene, coordinating resources, rerouting traffic. It’s a massive information problem under real-time pressure.

Simon: It’s not easy. But we need a systematic approach—evaluate what works and keep practical deployment front and center.

Jim: And speed of deployment matters. Getting something running in 30–90 days is very different from an 18-month procurement cycle. It reminds me of “premature optimization” in software—don’t over-engineer before proving value.

Simon: Exactly. Start small, learn quickly, and make strategic choices.

Jim: You’ve spent a lot of time in consulting. Why is software so hard inside AEC firms?

Simon: They’re not set up as software product companies. They have strong IT organizations, but software development isn’t their core competency. They’re better at adopting and integrating tools than building them from scratch. Writing code isn’t where they should focus.

Jim: It’s also a different business model. Software is built once and sold many times, while consulting is billed hourly. That creates tension, especially with AI reducing hours.

Simon: Yes, and that’s what the industry is wrestling with. AI can free up time for higher-value work or new revenue streams. Firms are exploring whether to do more projects or expand into new areas, like operations and maintenance services.

Jim: That’s an interesting shift—moving beyond design into lifecycle support.

Simon: Exactly. Instead of just designing assets, firms can provide intelligence and tools to help operate them more efficiently.

Jim: That’s a helpful distinction.

Simon: I was reading about AI predicting vehicle failures. It’s the same idea—anticipating issues before they happen. It raises business model questions, though. If you prevent failures, what happens to traditional revenue streams?

Jim: That’s a real tension.

Simon: One area that doesn’t get enough attention is maintenance. At Siemens, we used machine learning to predict failures in train doors by analyzing current spikes. That allowed operators to address issues before they caused delays. It’s a clear, practical use case for AI.

Jim: That’s a great example. Maintenance is often undervalued or under-resourced.

Simon: Part of the challenge is procurement and organizational silos. Operations and maintenance are often separated, with different budgets—CapEx versus OpEx. That fragmentation makes it harder to optimize across the lifecycle.

Jim: So what’s the approach?

Simon: You can pitch at the executive level or focus on total cost of ownership. Instead of just the upfront cost, show the long-term value over 30–40 years. It’s a classic strategy, but not always easy to execute.

Jim: That makes sense. Leadership needs to reconcile competing priorities, even if short-term incentives dominate.

Simon: In transportation, procurement often focuses only on CapEx. Operations and maintenance are treated as someone else’s problem.

Jim: This has been a great conversation, Simon. We’ve covered a lot of ground. Thanks for joining.

Simon: My pleasure, Jim. It’s been great.

Jim: This is At the Intersection. I’m your host, Jim Anderson, and today we spoke with Simon Davidoff, former Global Digital Leader in Transportation at AECOM and former Head of Digital Services at Siemens. Stay tuned for more episodes where we talk with leaders shaping the adoption of AI in transportation. Thanks.

‍

‍