The construction industry loves using acronyms to measure business and project performance.
We’re talking ROI.
EMR.
CSAT.
TRIR.
DSO.
TLDR (okay, this last one was just for fun).
All these construction metrics measure the performance of a business on a day-to-day basis. But there’s no single key performance indicator that captures the time and effort required to implement new construction software.
Or is there?
I was recently listening to Episode #377 of The ConTech Crew with Dylan John, where Dylan introduced the idea of “Return of Implementation.”
It made me stop and think about my own career: How would I gauge the success of the software I’ve helped roll out?
The way I’ve started to think about “Return on Implementation” (the other ROI) is as a metric of metrics. It’s a mix of qualitative and quantitative metrics captured before, during and after software implementation like employee satisfaction, time savings, and more. As part of that, companies need to identify:
But I wanted to pressure test this idea of return on construction software implementation. In this post, I’ve asked two of my industry peers—Ariel Castillo, Innovation Director at Miller-Davis, and Brad Buckles, VP of Technology & Innovation at Charles Perry Partners, Inc.—to join me in exploring the topic of return on implementation, and how companies can set up their new construction software deployment for success.
My take: The first step is to fully understand the problem—or problems—you are trying to solve. At PENTA, we wanted to solve multiple problems. There were the technology problems, like how to consolidate multiple point solutions and enhance data analysis. But there were also the relationship problems, like how to streamline collaboration with trade partners and design consultants. from streamlining collaboration with trade partners and design consultants.
But we knew our “why,” which helped us define why tackling these problems was worth it. At PENTA, we recognized the benefits of having BIM software integrated with model coordination to facilitate connected building.
Brad Buckles: When adopting new construction software at CPPI, it has to pass a simple litmus test. It must improve productivity, reduce costs, and/or improve project outcomes. If it cannot accomplish one of those three pillars, then it’s a pass.
Ariel Castillo: When making the business case for adopting new construction software, it's essential to first identify the specific challenges and inefficiencies facing your company. Examine the processes that are problematic, lead to bottlenecks, or don’t add significant value. This analysis of current workflows encourages you to ask "why?"—a crucial step that fosters open discussions about how to advance the company's operations.
My take: While your end users may not be responsible for procuring the software, every construction software implementation should be to add value to the project and benefit the end user. And end users include your external partners as well.
On our previous field collaboration platform, we realized that it was harder for design consultants and clients to collaborate on the files they needed to, and was more geared toward our internal teams. For every internal and external team member using the software on a regular basis, you need to make sure it’s something that’s easy for them to access and use.
Brad: Key stakeholders such as project managers, finance, IT, and the Field should be involved to ensure alignment with business goals and requirements.
Ariel: While open dialogue as well as engagement and support from top management are vital in this endeavor, don’t lose focus of your end-users; their daily experiences with the software will ultimately determine its success. It's crucial to make sure that the ideas you explore aren't just theoretically sound but also practical, leading to real improvements in daily tasks. If you nail all the above, and the case for adopting new construction software nearly makes itself.
My take: It's a running joke in our corporate tech groups that people hate change. Initially, there was some internal resistance to the switch, but we knew that people go through different emotional stages when adopting something new.
What helped was focus on our people. We tailored learning and communications to what worked for each individual. We took the time to listen to their specific needs, recognize their diverse backgrounds, and understand their pain points. We empathized with the frustration or confusion team members might feel, and provided inclusive environments that let team members express it through the channel that felt most comfortable (one-on-one, group sessions, and even lunches).
Brad: To get teams excited about using new software, highlight its benefits in terms of efficiency, collaboration, and improved project outcomes. Clear communication, demonstrations, and involving team members in the decision-making process can help foster excitement and buy-in. Setting up training sessions, offering support resources, and recognizing early adopters can also contribute to the success.
Ariel: Sparking your team’s enthusiasm for new software begins by pinpointing their preferences and aversions within their roles. By addressing individual job duty dislikes and demonstrating the tangible benefits software offers, you effectively personalize the solution; Software now becomes more than a tool. For instance, it becomes a means to streamline tasks like RFI processing, enabling team members to potentially recoup time for non-work endeavors—family, hobbies, etc. This approach also showcases the transparency of project information flow, helping to dismantle silos and disjointed operations to foster a more integrated work environment. You can further engage reluctant team members by illustrating the software's ability to reduce tedious paperwork, allowing them to focus on more rewarding aspects of their jobs.
Pinpointing preferences, demonstrating tangible benefits, and showcasing transparency are ongoing, two-way processes. It is critical to allocate sufficient time for team members to familiarize themselves with the software and to provide active feedback. Remember, the goal is to enrich the workday, not complicate it. Ensure the software adds value to daily routines and overall project outcomes and success will follow.
My take: Measuring your “return on implementation” starts with showing the progress and success. Are our teams using the software efficiently, does the new software improve our team’s productivity, does it improve workflow and is it providing value to our clients?
In addition, getting all the relevant data in one place is important. You cannot measure assumptions you must measure facts. For instance, you can’t map how your new cost management tool is saving you money if you don’t know how much revenue was leaking before.
At PENTA, one of our major focuses was reporting. We worked with our internal teams to push data from ACC Connect and the Data Connector into a database. With all the data in one place across the variety of platforms we use across our business, we can track how an improvement in one area might lead to improvements in another.
Brad: This can be very tricky and oftentimes subjective. Measuring the ROI of new construction software involves assessing various factors such as cost savings, productivity gains, improved project timelines, and enhanced quality of deliverables. Quantifying these benefits against the initial investment and ongoing operational costs can be very difficult in many cases when trying to recognize the software's impact on the organization's bottom line. Regular performance monitoring and feedback collection from users is the best and most pinpoint way to understand its ROI.
Ariel: Calculating the return on investment (ROI) for new initiatives can be complex, particularly when viewed solely from a financial perspective. Consider taking a holistic approach that also involves identifying and measuring metrics that reflect the company's values and strategic plan. It's important to establish mechanisms for tracking metrics, which might include employee satisfaction, efficiency gains in document processing, improvements in client interactions, and the enhancement of quality of work. This broader perspective of ROI allows you to capture the full spectrum of benefits from your investment in addition to monetary gains.
What is the one piece of advice you would give to teams implementing new construction software?
My take: Prioritize the people and teams that will be impacted by the new construction software. People, Process and Technology frameworks is a great rule of thumb.
Also, remember that construction software won’t fit your company out of the box. The software will need to adapt to the people as much as the people will need to adapt to the software. You may need some customization at the outset to get things the way you want them, like establishing which direction(s) data should flow and what certain data fields should be called.
But also remember that you’re not starting from scratch. While implementing new software isn’t as simple as “slotting it in” to where an older platform used to be, you likely already know which teams need access to the platform, what workflows are top of mind for them, and what systems your new software needs to connect to.
Brad: My advice for teams implementing new construction software is to prioritize thorough training and ongoing support. Investing time and resources in proper training can significantly increase user adoption and mitigate potential challenges during implementation. In addition, it is critical to properly plan the implementation and thoroughly test during a Pilot Project.
Ariel: While I wish I could offer a single piece of advice, the truth is that success comes from a blend of strategies.
First, embrace innovative thinking and question established practices.
Many procedures in use today were developed during a time without current technological capabilities or the rapid pace of information exchange.
Secondly, don't fear failure.
This doesn't imply a lack of concern but suggests adopting a flexible, agile methodology that allows you to quickly identify effective and ineffective strategies, informed by your team’s ongoing feedback loop.
Lastly, cultivate patience.
We often overcomplicate things. The intricacies of human psychology and industry dynamics can sometimes impede progress. To avoid this, try to drill down to what really motivates and drives the behaviors of your team to make meaningful advancements forward.
Conclusion
Like construction itself, measuring return on implementation is both an art and a science. As you can see from Ariel and Brad’s responses above, you’re going to need to look at qualitative and quantitative metrics to see if your implementation is succeeding.
But if both quantitative and qualitative feedback are on the rise following your rollout of a new platform…well, then that’s return on implementation FTW.
