Humans are a fickle bunch. We moan and gripe about the way things are and throw riots when things change. It’s never really about the “old way” and the “new way” - it’s that interim change period that mucks things up. The old way is comfortable and the new way may be better, but getting there takes effort and compromise. Often, it’s easier for people to convince themselves that the way we’ve always done things is the best way rather than putting in the effort to adapt and learn.

The adoption of new technology is often a struggle in the construction industry. With FHWA promoting the adoption of e-Construction solutions through their Every Day Counts initiatives, more leaders are trying to find ways to create organizational buy-in and train their staff. Even when new tech is adopted, longtime field personnel may be resistant to the change their supervisors are pushing. Despite the ease e-Construction platforms introduce to common processes like daily reporting, quantity management, and fund track tracking, any and all change is met with resistance.

Usually, the problem isn’t with an intuitive interface or training; it’s with philosophy. By shifting how you approach e-Construction implementation, you may find it easier to overcome dissenting voices and bring excited team members on board. In this article, we’ll share some of the tips we’ve learned from conducting software implementations over the past few decades. For further research, we also recommend looking into the Florida Department of Transportation’s” e-Construction How-To” guide, which provides an overview of six obstacles and how they tackled them.

1. Sell Small Change

Upgrading from spreadsheets or pen-and-paper to construction administration software is exciting. It enables teams to be more efficient, decisive, and cost-effective when completing projects. But in the face of individual team members worried about their day-to-day, those are just words.

It’s important not to present the upgrade as a monumental shift or a new era for your company. Chances are it’s just an improved way of doing things you’re already doing - and should be presented like that. If you treat it as a minor shift in the day-to-day operations, it’ll be accepted as such. Don’t shrug things off - acknowledge any discomfort you sense about the change. Since your new platform will likely save time and make the field team’s work easier, it will be easy to address these concerns. But if you try to sell people upfront on a major improvement, it’s possible they’ll reject it as administrative posturing.

Infotech recently hosted an e-Construction webinar with the Director of Public Works for Meriden, CT and one of their consultants from VHB. The city began testing an e-Construction platform for construction administration and inspection as an easier way to maintain their required Four Volume record-keeping process. Because they introduced the new software process as a streamlined version of the current process instead of a new one, introducing the new tech to their team was a non-issue.

2. Test Small Groups

After announcing the move to a new construction management software, take volunteers for a small team interested in performing an initial test run with the product. One of our clients, Smith Seckman Reid, Inc., takes a similar approach by selecting their more “tech-centered” engineers to learn the software first and then transition jobs forward in a phased approach. This process will help with implementation in a number of ways:

• It creates an aura of exclusivity around the software and excitement when it goes live to the entire company. 

• It allows you to deal with issues and concerns as they arise in a small beta, rather than putting out company-wise complaints. 

• It increases word-of-mouth interest in the new software as test team members share their findings with their coworkers.

• It allows you to form concrete expectations on how teams will use the software before distributing to the entire organization.

However, the greatest advantage of a small group introduction is in creating the next wave of trainers on your team. Previously, we mentioned the City of Meriden’s project-by-project approach to large-scale software implementation. Introducing their new software to a small group made it easier to introduce future team members to the software:

“Now that we have a group that has successfully implemented e-Construction tools such as Appia®, and is comfortable using it, guiding other members has been much easier.” - Josh Eannotti, Transportation Engineer, VHB

3. Teach Small Functions

When organizations adopt new technology, there’s often a dreaded company-wide training session that feels a lot like a school assembly. The biggest flaw in assemblies is that the information presented is only partially relevant to the audience. People start to zone out when the presentation isn’t relative to their role and may miss out on crucial information.

Instead of bulk training sessions, consider hosting smaller sessions that pertain to specific key team roles. Our own implementation team often breaks our onboarding training sessions into “Functions for the Field” and “Functions for the Office” so that personnel only have to attend meetings that are relevant to their roles.

The City of Meriden and VHB are taking a similarly gradual approach as they introduce the concept of digital project delivery to their teams. By limiting the functionality of their new software on their initial test projects, they are able to get their team comfortable with the basic functionality before introducing new processes:

“Our team has introduced many of the Appia tools on a project-by-project basis. During our pilot project, and on the projects since, we’ve utilized many of the tools for daily reporting, tracking quantities, etc. but have not used the software for generating payments or documenting change orders. We’re currently working through this process and will continue to use more tools as we become more comfortable.” - Howard Weissberg, Director of Public Works, City of Meriden

4. Assign Small Roles

After you’ve beta tested your new software with a small group, take what you’ve learned and see how it relates to large-scale implementation. How did your test group handle their specific responsibilities when using the software? Who was responsible for what? Most importantly, do you have a champion user?

A champion user is someone who is passionate about improving your organization and works with your software solution vendor to establish a rollout plan and specific roles and responsibilities for your team. If you can establish roles, responsibilities, and processes before widespread adoption, it will create a greater sense of ownership among field staff. Team members won’t see themselves as responsible for operating this newfangled technology. They’ll understand their responsibility in relation to the project and the software.

Eventually, your team’s familiarity with your software solution will enable them to expand their roles and even train others once they’re completely comfortable, but segmented responsibilities can be a great start to implementation. We typically see teams with the following structure, similar to how an organization operates before introducing a software solution:

• System Administrator: Responsible for controlling access and selecting program settings to match their process.

• Project Managers: As always, PMs oversee inspection reports and a team of inspectors.

• Inspectors: These folks capture data out in the field and may have to adjust to using tablets and smartphones instead of field books.

• Project Stakeholders: Composed of owners, auditors, and other project stakeholders, this group should have a specific rollout plan established at the beginning of a project so they can stay up-to-date without the need for training or data manipulation.

5. Create Small Goals

You’ve achieved organizational buy-in and your project stakeholders are all comfortable with the functionality you’ve introduced. What’s next? The worst thing you could do for your newly trained team is take a big leap forward. This chunk-sized implementation process should be cyclical, so you can tackle your next tech goal in the same methodical way. If you initially introduced a web-based system for construction project management, examples of your next steps could include:

• Introducing mobile apps that can be paired with your construction project management system for real-time data collection in the field

• Integrating your construction management system with other data collection technology like rovers and drones

• Pairing your construction management system with a tool for paperless contracting or online bidding to go completely paperless

Here’s how the team at VHB and the City of Meriden are expanding their use: 

“From an engineering standpoint, we're constantly trying to push this closer and closer to design. The transition between final design and construction is still a little bit uneasy. I think the next step is utilizing existing Infotech software for the bidding purposes, but also figuring out if there's a way to incorporate the final design, plan specs, and estimates into Appia prior to going out to bid. The goal is to capture as much project information as we can from project initiation to project completion electronically.” - Howard Weissberg, Director of Public Works, City of Meriden

Despite initial resistance, we’ve found that field teams ultimately love using modern e-Construction solutions like Appia once they’ve overcome the learning curve. By using these tips, you can vastly shorten the learning curve for your team (with the added benefit of squashing out gripes and grumbles). Project management will be more efficient, cost-effective, and collaborative in no time.

Want to explore this topic further?

Watch the webinar.

Read the case study.

For more information on Infotech, Appia, and how we help teams implement construction administration software, visit https://www.infotechinc.com/appia.