Two issues back in this column, we took a look at the confusion generated by the proliferation of mobile devices on construction job sites. One attraction of project management software is the possibilities it offers for field-office communication and for keeping a real-time eye on how jobs are going. But just as we can be compulsive about our private use of mobile devices, it’s become almost knee-jerk to record job site data, whether or not we know how it might be utilized. More inconvenient than catastrophic when it comes to our private data, the practice of recording details digitally and broadcasting them to a wide audience has actually made decision-making more difficult.
The Data’s There, But Where?
Dexter + Chaney Marketing Director Wayne Newitts has described the problem as one of unstructured data—the stuff that clogs our e-mail boxes and hangs around in our cell phones because we don’t have a dedicated place to put it. Locating and accessing data we need when we need it among the gigabytes that come our way has become a major business challenge—homeless text messages, buried e-mails, and details of in-field management that aren’t attached to any application or stored anywhere except in a sea of inboxes. The particularly vexing news is that unstructured data now accounts for 98% of information businesses depend on.
The challenge identified, we went in search of other software developers to see what they had to say. At HCSS, VP of Strategy/R&D Tom Webb thinks the problem starts at the front end and that, ironically, it boils down to people: those who use the devices, the company managers who provide the hardware and apps, and the techies who planned the whole thing in the first place.
“The likelihood that most of the data that sits in your e-mail box—like the pictures that sit in your phone—will end up in the right person’s hands so they can take action is not very high,” he says. “Which means it’s incumbent on companies like us to start building solutions that drive field data into a company’s structured database system. The question we ask ourselves is how to use technology so we’re not sending a bunch of data back and forth that doesn’t really matter.
“Twenty years ago, when we went from paper to laptops in the field, we were using the software to do our daily paper work, like timesheets,” adds Webb.
And, what an efficiency that was. “Less than a decade later, it’s not only the superintendents who have mobile devices—everyone on the crew has a smartphone, and the smartphones are equipped with apps. The question is how to use this technology to help construction companies get a gauge of the data they’re generated.”
And, the Answer Is?
“We’re starting to develop software that gets down to the individual employee level, where a person can take job site photos and make safety observations, for example, and send them into the company’s corporate safety system, where the information becomes structured,” says Webb. (This is what Newitts referred to as context.)
Continues Webb: “We’re seeing more and more of these kinds of initiatives to capture information at the employee level so that the data they generate provides actual feedback to management.
“Unstructured data that comes in any-which-way is difficult to act on,” he adds. “Management loses the opportunity to be efficient based on that information.” Meaning that, in the absence of some kind of magic wand that enables you up to call up something you need but might not know you have, employees should get direction about where data should go, i.e., which system it’s applicable to, instead of leaving them to their own devices” (which means training).
“The key is that we don’t ask people to gather data for data sake, and that we do something with the data we gather.”
It’s a dual obligation; don’t waste management’s time, but management also needs to understand that it has an obligation to act on the data it’s caused to be generated (in other words, planning).
First of all, look at the big picture: follow this with a plan to accomplish the goals you’ve identified and make sure everybody affected has buy-in. “At HCSS, we have an implementation center where we work across an organization to determine what they want to do and why they think what they want to do is going to make a difference,” says Webb. “The idea is to make sure that everyone [office-field, management-crews] is on the same page about the goals they want to accomplish with technology, and that everybody has an understanding about what this or that application actually does.”
He explains that focusing on the field is critical. “For years, Dexter + Chaney focused primarily on the accounting office. HCSS started in the estimating office. But it’s essential to work with the field people to see what they’re actually doing before you start creating solutions for them to use.”
Another caveat is don’t undertake the planning process alone. Partnering with a software vendor has the advantage of knowing the snags and pitfalls other customers have overcome.
Webb also recommends to try before you buy. “Once you get everyone together and decide what you’re after and how you think you’re going to get it—and how all this is going to result in a measureable return on investment—try it out,” he says. “The old strategy used to be you’d develop an initiative you think will work, write an elaborate RFP [request for proposal], send it out to different tech companies, get the answers back, develop a short list, and pick a vendor. Only then did you start planning implementation. A better approach is to pilot test the software you’re considering. Maybe you add a second piece of software that does something similar, and try them both on the job.
“The cool thing about this is that you have generated experience that you can use to make decisions. You can see the value firsthand before you make the decision to roll an application out across the company, and you can tweak it to make it work for you.”
He continues, “The shame of it is when you have 20 different problems to solve, and you end up with 20 different pieces of technology that don’t integrate. We’re addressing that problem by writing software differently in a way to make it easier for people generating the data to plug it into a system, keeping in mind that they may be supporting the system with data from other devices.”
But, We Are Not There Yet
In the meantime, Webb’s best solution is what he describes as a system of record, a concept borrowed from the old days. “We used to use it to refer just to the accounting system. But now we’re talking about the data management system that you know you can rely on to get particular information, where data is likely to be the most accurate because it wasinitially entered there [no sticky fingers in between]—invoices into accounting systems, time, and quantities into field systems.
“Declare yourself to have one or two, or at the most three, systems of record, and work with your software vendors to integrate data you’re collecting in other apps or on other devices. A great example of this is GPS devices. You want to be able to take data from all your GPS devices, regardless of equipment, and feed it through a single system.
“It’s incumbent upon the initiator of the technology change at a company to be very clear on the ROI they’re expecting and to tie it back to value so managers see they’re not just doing this because it’s an initiative to be more techy, but because there’s a clear chance of payback,” he says. “We’re evolving. The key is to make sure that you’re not wasting peoples’ time. Take the time to step back and think through what is it you’re doing, how it’s going to make an impact, and how you’re going to assure that happens.”
Yep, like always, it boils down to people.
