'Being Foreman-Friendly' - is it enough?
'Be foreman-friendly' is a phrase I heard at a recent Construction Tech conference . It means essentially that construction applications should be designed with the foreman (or supervisor) in mind. Seems obvious doesn't it? So, why is it not usually the case, how do we fix it, and is that really enough?
The information needs for the construction industry have increased exponentially over the last 20 years due largely to increased requirements for safety management, compliance, quality records and risk management. We are now in a more litigious society and one of the side-effects of this is a greater focus on record keeping. In addition, projects are running with ever-tighter margins so the focus on commercial management is also driving increased focus on data - 'you can't manage what you can't measure', as they say. Finally, the transition of back-office systems into the 'electronic age' has increased the volume of data that can be collected; there are just more data points to fill.
Unfortunately, front-line processes have not kept pace with this change, constrained largely by the availability of data networks and mobile devices. It was only 10 years ago that I was implementing field productivity management systems with Palm Pilots that supervisors would mash data into during the day then return to the office to plug-in and sync at the end of the shift. It's only 5 years ago that mobile phones were still banned from some sites for safety reasons. Now smartphones are ubiquitous and the data networks are ever-extending their reach. Tablets also provide the form factor that enables entry and consumption of richer, more useful information.
The result of this two-paced change has been that many software systems have been designed top-down. Design driven by the question 'What data do we need to feed our reports?', then secondarily, 'How do we collect it?'. In other words, how do we feed the beast? Supervisors are at risk of becoming data entry clerks in the quest to achieve an 'enter once, use many times' data model. In response to this crisis, the admin support resources have increased to provide this service, thus increasing the overhead costs for projects. But this doesn't solve the problem.
We now have the opportunity to turn this model upside-down - to design our systems with the front-line at front of mind. This is where the money is made and lost, this is where safety management matters. Systems must effectively serve this audience. But how? I think we need to focus on two key questions.
First, 'What's important to me today?' A question for the supervisors. What information do I need and what do I need to collect, focused on the 'now'. In my last role, we designed a native iPad-based site diary with this question in mind. It collected progress, issues and timesheets and provided short-cycle feedback on productivity. It was a good start to solving this problem and was well used by site staff. However, it still required too much data entry - plant and material usage data, for example.
So the second question is 'How do we collect the data at its source?' rather than at its aggregation point. This landscape is changing rapidly with more and more workers now carrying smartphones and more and more machines being enabled as 'Internet of Things' devices. The next generation of field applications must collect data from the many, both people and plant. Supervisors and field engineers will be responsible for validation, not data entry. They will have the information they need to manage the job safely and productively, rather than feeding data into various systems, mobile or otherwise.
Thus, our construction applications need to be more than 'foreman-friendly', where appropriate they need to be 'worker-friendly'. It doesn't have quite the same ring to it, but it will unlock information efficiency in a way that has not yet been seen in the construction industry.
Mark is the CEO and Co-Founder of Docketbook, the universal docket exchange for the construction industry