By Don Talend, Contributing Editor
Change orders, which can throw projects off schedule and cost contractors money, are just part of the business. Or are they? EYA, a Washington, D.C.-area builder and developer of luxury townhomes and communities, is analyzing trends in its project management system to reduce change orders in future projects.
Better visibility into project profitability
Pete Zafros, EYA’s director of technology, came aboard in 2013 and oversaw implementation of the Procore project management system soon afterward. Its inherent project data centralization empowers project managers to manage budgets, assess potential change orders and be aware of the status of all in-process change orders in real time with an eye on maintaining target profit margins.
Zafros says that integrating EYA’s accounting enterprise resource planning system into the process was the final piece needed to achieve inter-company collaboration. Now, project managers can track their projects’ profitability in real time as well as forecast upcoming costs in later phases, giving them more decision-making insight.
EYA compares the cost data with its budgets, makes design changes based on project profitability and uses Procore to communicate with its subcontractors, the sum total of which comprises a value-engineering process.
Focus on eliminating reasons for change orders
Real-time access to costs is particularly valuable to EYA when the project manager is aware of pending major changes to structures. This real-time visibility helps the project manager decide whether or not the latitude exists to make additional changes, according to Zafros.
But even more importantly, he says, EYA can now analyze historical project data and pre-empt some change orders on future projects in the first place.
“Procore has recognized that change orders are symptoms of a change event—they’re not the root cause,” Zafros says. He adds that every change event in the system has a change reason such as the specificity of EYA’s drawings or jurisdictional code changes.
“That helps us to focus on where we can prevent changes from happening in the first place, or at least be more aware of the costs and not have as many of them,” Zafros says. “We’re focused on the construction changes and the design activities that drive change—not contracts and change orders, as the industry has been for a long time.”
Contractors have the ability to document change events, categorize the reasons underlying the events and create customized change event reports in Procore. Through categorization, they can identify trends and take corrective action. For example, if drawings are the cause of most change orders over a particular period or on a given project, the contractor can address the issues with the drafting department.
Implementation via knowledge cascade
During Procore’s implementation, Zafros facilitated a cascade of knowledge throughout EYA by having employees with greater aptitude and motivation to learn the system do so, then share their knowledge with others who were further behind the curve. An implementation manager from Procore determined which system tools would give EYA the quickest “time to value” and trained the trainer – Zafros – on how to use them.
“We really focused on our field-centric capabilities – our drawings, RFIs and specifications to really make sure the guys in the field had the proper information to do the best job of constructing a building,” Zafros says. In just a couple of months, he says, field crews got used to accessing key project information on their iPads and iPhones and the payback was immediate. By the end of the year, the system was fully incorporated into operations.
Zafros used the “technology adoption curve” from Everett Rogers’ Diffusion of Innovations as his guide for implementing Procore. The technology adoption curve groups adopters of an innovation according to their willingness to try them. Typically, “Innovators” who like trying out new things for the inherent enjoyment of doing so learned how to use a tool, then cascaded the knowledge to “Early Adopters,” who were more selective and therefore well respected. One by one, the “Early Majority,” “Late Majority” and “Laggards” were trained on how to use a given tool.
“I think that, many times, people get focused on the hardest part first—that’s not always the best way to roll out new software and changes,” Zafros says. “You want to focus on getting some victories and prove value and you have to remember that every person is different. If we treated everybody the same, we were not going to have the success we wanted.”
