Session Recap: What Owners Need to Get Right with Project Controls Technology

During the Project Controls Expo USA 2026 in Washington, DC, ProjectTeam's VP of Product, Josh Witmer, moderated a panel with owners and construction managers. They discussed how to implement project controls technology successfully and shared lessons learned. Continue reading to learn Josh's takeaways from the session.

This past week, I had the chance to moderate a session at Project Controls Expo called “The Owner’s Checklist: Implementing Project Controls Technology That Delivers Public Value.” I wanted the panel to cover the full picture, so it included people from the owner side, the CM/consultant side, and the vendor side:

• Cassandra White, Program Financial Accountability Officer at DC Fire and EMS. She oversees the agency’s finances, contracts, and process improvement, and she has rolled out a system at two different agencies.
• Omar Stephenson, President and CEO of Cube Root Corporation, a 60-person CM firm that has worked for owners like DC Water, DDOT, DGS, and GSA.
• Brian Rothery, VP of Professional Services at ProjectTeam. He’s a PMP who has led implementations for hundreds of clients.

Why Implementing Project Controls Technology That Provides Value Matters

Fewer than 1 in 3 digital transformations succeed. In most cases the software isn’t the problem. What breaks down is everything around it. The problem isn’t clearly defined, the system doesn’t fit how people actually work, users get involved too late, or nobody keeps improving the system after go-live.

Fewer than 1 in 3 digital transformations succeed, and it’s rarely because of the software. Source: McKinsey & Company 

So we built the session around a five-item checklist for owners who want to be in that 1 in 3. Here’s what the panel had to say about each one.

Project Controls Technology: Owner's Checklist

1. Start with the problem, not the product

Cassandra has implemented ProjectTeam twice, first at DC DGS and later at DC FEMS, and the two projects looked very different.

DGS was a huge effort. It meant supporting a capital budget of more than $3 billion, migrating over 10 years of data from a legacy system, and bringing in external stakeholders from across the DC area. It touched everything.

FEMS was more internal. The focus was on financial tracking and budget approval workflows more than traditional construction management, so the work centered on configuring the system to fit the agency’s specific needs.

Same platform, very different goals. Being clear about what each agency was trying to solve shaped everything that came after. Omar added that from the CM side, it’s much easier to work with owners who come in with a clear problem statement and are willing to work through the right solution.

2. Make sure the system fits your process

I asked Omar how his team handles needs the standard setup doesn’t cover. He pointed to a recent example on the DC PLUG project. The owner already had a system in place, but it couldn’t be configured to track inspections and reports the way the project required. Instead of forcing the team to work around it, they added ProjectTeam alongside it to fill that gap. The lesson: your process should drive the tool, not the other way around.

3. Bring people in early, don’t wait until go-live

Brian talked about the value of building a group of “champions” early on. These are the people who help define how the system should work, based on real day-to-day use cases. He also stressed understanding the range of technical comfort across your users, since an implementation that works for your most tech-savvy people can fall flat for everyone else.

We also talked about phased rollouts. Start with the projects and teams that are most eager to try something new, use them to prove out what’s possible, and work out the early wrinkles before expanding to the rest of the organization.

4. Treat implementation as a project

Brian has seen hundreds of rollouts, so I asked him what a structured one looks like. Beyond the checklist items, he made a point I think owners don’t hear often enough: some of the responsibility sits with the vendor. An owner’s RFP usually captures the high-level needs. Getting to a successful implementation means digging deeper than that, and it takes an experienced implementation team and a flexible product to adapt as those deeper needs come out.

5. Keep improving, or risk starting all over

This one turned into an open conversation, and each panelist brought a different angle from their side of the table. The common thread was that go-live isn’t the finish line. Systems that don’t keep evolving with the organization tend to get abandoned, and then you’re back to square one.

A word on AI

We closed with a quick discussion on AI, and the three perspectives were a good snapshot of where the industry is right now:

• Cassandra said DC FEMS has been slower to adopt AI, but they’re eager to keep learning. Given the sensitivity of the data they track, security has to come first.
• Omar is all in. He’s excited about the use cases ProjectTeam’s AI capabilities can address, especially for some upcoming projects his team has planned.
• Brian said he leaves the final call to each client. His role is to show them what’s possible within the right security boundaries, with the goal of making each user’s job easier, not doing AI for the sake of it.

After the session, we invited attendees to a ProjectTeam AI demo where we walked through several real use cases. Thanks to everyone who stuck around for that.

Owner's Checklist panelists from left to right: Josh Witmer (ProjectTeam), Cassandra White (DC FEMS), Omar Stephenson (Sube Root Corporation), Brian Rothery (ProjectTeam)

Thank You to Our Project Controls Panelists

A big thank you to Cassandra, Omar, and Brian for sharing honest, practical experience, and to everyone who attended and asked questions. If you’re an owner planning a project controls rollout and want to talk through any of this, feel free to schedule a demo.