Digital Builder Ep 146: Why the Best AI Initiatives Start With Problems, Not Technology

Construction has no shortage of new technology but making it useful in the real world is a different challenge altogether.

At DevCon, I sat down with Josha van Reij, Product Manager of Data & AI at Arcadis, to talk about bridging the gap between emerging technology and project delivery. We explored how Arcadis approaches AI, standardization, and software implementation, plus practical strategies for driving adoption in the field. Josha also shares why listening to project teams (not pushing tools) is often the key to meaningful innovation.

Watch the episode now

On this episode

We discuss:

  • Why AI and automation efforts should start with real project challenges, not technology trends
  • How Arcadis builds AI assistants using connected data, project context, and internal standards
  • Why standardization is essential for better data, stronger workflows, and more useful AI
  • How listening to project teams can reduce resistance and improve technology adoption
  • What to consider when deciding whether to buy, customize, or build software

A commitment to improving the way teams work

As a product manager who focuses on data and AI, Josha works at the intersection of technology and project delivery.

His path towards his role actually started with frustration. Early in his career, he worked closely with project teams and saw how much time people spent on manual tasks and repetitive processes.

Too often, work was done a certain way simply because "we're used to doing it that way."

That experience pushed him toward a role focused on data and AI, where he now helps connect project teams, clients, and technology. His goal is simple: make tools practical.  

“I'm really trying to make tools become practical for real-world use cases. And that's also actually what makes me excited,” he remarks.

Using AI to solve real problems

AI may be generating plenty of buzz, but at the end of the day, these solutions should serve actual team needs.

When evaluating new tools, he starts with a simple question: "What challenges do you currently have, and how could we solve them?" From there, the focus shifts to finding technology that can deliver measurable value.

According to Josha, too many organizations start with the tool and look for a use case later. His team takes the opposite approach. They identify the challenge first, then determine whether a particular solution can help. "This tool might solve your challenge and thereby really deliver value," he says. The goal isn't to implement AI because it's new. The goal is to make work easier and outcomes better.

That same mindset carries over to how Arcadis approaches AI assistants. Josha says the most effective assistants aren't powered by AI alone. They're powered by the right data and context. "You only get half-baked answers" when an assistant is connected to a single system or limited dataset. Instead, Arcadis focuses on connecting assistants to multiple data sources, including project information, internal policies, and company standards.

Just as importantly, the assistant needs to understand the job it's supporting. It should know the project context, what's happening on the project, and the client's requirements. When those pieces come together, the assistant can provide more relevant answers and deliver far more value to the teams using it.

Managing resistance to change

Many leaders encounter resistance to change when introducing new processes or tools. Josha’s experience is unique in that he found people were generally willing to change, provided they could clearly see how the change would help them do their jobs better.

For him, most resistance wasn't about the technology itself. It was about how it was introduced. "I expected a lot of resistance, a lot of people saying, 'No, I don't want that,'" he says.

But that reaction often happens when teams try to push a tool on people without first understanding their needs. Josha takes a different approach.

He starts by asking, "What are your challenges?" Then he shows teams how a specific solution can help solve their problems. When people see a tool addressing a real problem, they're much more open to change.

The importance of standardization

For Josha, standardization isn't about creating rules for the sake of it; it’s about making projects run more efficiently and creating the foundation for better data, better decisions, and better outcomes. So much so that he believes standardization is a prerequisite for getting real value from AI. But the key is approaching it from the perspective of the project team.

"A project doesn't want to standardize because they have to standardize," he says. The better question is: "What does this standardization bring to me?" Teams need to understand how a standard will make their work easier, not just satisfy a corporate requirement.

That can be a challenge, especially when standardization feels like extra administrative work. Arcadis addressed this by focusing on the bigger picture.

“If you can show the value, what standardization brings, that will definitely help the teams on the ground,” Josha adds.

How to get started with standardization

Ready to kick off your standardization efforts? Josha’s main tip is to start small.

“Don't try to directly standardize too much. I think that's something that happens a lot. People make very big policies and create files that explain in 40 pages what the standards and policies are.”

He continues, “Try to make it small and also implement it within the systems. So if you let the systems help you with the standardization, that will help a lot for the project teams.”

Deciding whether to build or buy new software

“Build vs. buy” is a classic debate that many firms face when evaluating software. For Arcadis, the answer starts with understanding the problem, not the technology.

Josha says the company once built much of its own software, investing heavily in developers and architects. Today, the approach is different. The team first identifies the challenge they're trying to solve, then looks at off-the-shelf products that might meet the need. From there, they evaluate cost, integration possibilities, and whether a low-code customization could bridge any gaps.

Building a custom solution is typically the last option, reserved for situations where existing tools can't meet specific client requirements.  As Josha puts it, the team believes in "trying a lot, but failing fast."

If a solution isn't helping them reach their goal, they move on and look for a better fit.

And if you’re evaluating different tools and want to avoid red flags around vendor demos, Josha offers classic advice: if it looks too good to be true, it probably is.

“If it looks too perfect, it's not true. A lot of demos make it seem like the process from beginning to end is very smooth. You put in a little bit of data, and you get the perfect answer. It's never the case.”

In other words, don't be afraid of an imperfect demo. Vendors that openly acknowledge limitations and show how their product handles real-world issues are often more trustworthy than those presenting a flawless experience. Construction projects rarely have perfect data, so it's important to evaluate how a tool performs when conditions aren't ideal, not just when everything goes according to plan.

New episodes every week

Digital Builder is hosted by me, Eric Thomas. Remember, new episodes of Digital Builder go live every week. Listen to the Digital Builder Podcast on:

or wherever you listen to podcasts.

Eric Thomas

Eric is a Sr. Multimedia Content Marketing Manager at Autodesk and hosts the Digital Builder podcast. He has worked in the construction industry for over a decade at top ENR General Contractors and AEC technology companies. Eric has worked for Autodesk for nearly 5 years and joined the company via the PlanGrid acquisition. He has held numerous marketing roles at Autodesk including managing global industry research projects and other content marketing programs. Today Eric focuses on multimedia programs with an emphasis on video.