The construction industry is slow to change. We are not early adopters, nor do we tend to be technology leaders.

The implementation of computers on construction sites was a long, long way behind their adoption in other areas such as manufacturing, law and the world of business and commerce. Law and resolution of construction disputes remains remarkably similar to procedures undertaken as far back as the 16th century. It is fair to say we are comparative dinosaurs. Whilst labour input on sites is gradually being eeked out by mechanisation (no more hod carriers now!) and certain site elements such as reinforced concrete are highly labour intensive, it is clear that we are, due to the fragmented nature of what we do, probably most in need of the collaborative technology that has been steadily growing a presence within the industry for some years.

I should perhaps amplify what I mean when I use terms such as ‘collaboration,’ or ‘collaborative technology.’

Partnerships, or alliances, or PPP or PFI-type procurements, do constitute collaboration and there is a growing trend for more collaborative contracting arrangements based around target cost and pain/gain sharing, inter alia. The New Engineering Contract options along with the base conditions provides a good example of this. This form of contract is widely used in the UK but has a limited presence in NZ and Australia. It does, though, generate a different way of thinking and I am a long-time user and proponent of it. It came out of the 1994 Latham Report, itself a forerunner of Egan and Rethinking Construction and has, in my view laid the platform for the next generation of collaboration that is awaiting us.

It has been said that collaborative behaviours (or confrontational behaviours) will exist regardless of the form of contract and although that is true, the NEC is designed to be collaborative. It is analogous to taking the family Saloon rallying – it might get around the course, but that’s not what it was designed to do. My belief it that it does generate collaborative behaviours on projects. That though is only one element of what is a broad process.

Collaboration tools are typically web-based, hosted systems, such as Aconex, Causeway, Citadon, 4Projects and so on. They are systems that enable the distribution, storage, review and exchange of project data. Most of these tools have built-in ‘workflow’ functions that enable the replication of contractual and project management processes for approval of designs, issuing instructions and agreement of variations and payments, methodologies and proposals. Some – Conject for example – now comprise full-blooded project management and collaboration in one, and in the current instance is aligned to the NEC form of contract with in-built NEC processes and timescales.

Most major projects, certainly in the UK and in my experience, in the UAE, utilise such tools, implemented to varying degrees. Having worked on two projects in excess of $1 billion, I find it inconceivable that a client on a large scheme would consider anything else.

There are, I believe some tangible benefits as outlined below, in using these tools rather than managing in the ‘paper world.’

They provide an irrefutable audit trail for the issue of documents, drawings, minutes and the like. Items are automatically numbered and response and re-response are shown and can be tracked.

Reports on a host of variables, can be generated, allowing review and reporting of a number of areas of the project and of the timeliness (or otherwise) of inputs and actions on a discipline, company or individual basis. Someone, usually the PM, will have view rights for all of the project team and can determine where problems are occurring, allowing the client clear visibility of remedial actions required or the possible need for additional resources.

Storage space is not an issue, and posting, copying, fax and courier, are no longer required. Most applications include a native viewer allowing, for example, DWGs to be reviewed when within the system, even though the actual technology used may not have such functionality.

The instantaneous distribution of project data is particularly useful when the team is disparate, spread across cities, states or even continents. But as with most technological tools, it is not  a substitute for common sense, and there are some pitfalls for the unwary to fall into when undertaking the most critical phase of the implementation, which is structuring the communication paths.

There are some key issues to determine based upon the main difference between the use of the tools and the paper and post world that still predominates.

Most important is the realisation that with collaboration tools, the message does not go directly to the user; it goes to the system and a notification is then issued to the recipients stating they have a communication to action. This is unlike a letter landing on one’s desk, although the outcome of any inaction is the same; should it not be looked at or actioned, then nothing will happen.

Somehow this invariably gets lost on some of the team members.

The other key determination is to structure the tool to ensure that each communication is seen by and actioned by the right party, and in so doing there is a great temptation to distribute everything to everyone. That wastes time and energy and is the one area where collaboration and more normal practices align.

However, the distribution for a live project will invariably for the most part lie with the contractor and it is a judgement call as to who is copied in to what. Common sense tells us that electrical queries and submissions go to the electrical engineer, but what of those issues that cross disciplines? The reality is that it won’t always be the right call and there has to be a co-ordinating presence ensuring that responses and approvals are comprehensive.

There is also a danger of creating, by virtue of communications on the tool, a quasi-contractual relationship between the designers and the contractor. That has to be guarded against. Wording on communications should be explicit and direction should come only from the party with the appropriate contractual authority.

Revision of drawings needs to be rigorously undertaken and this can be complicated by third parties outside the bounds of the collaboration tool, such as local authorities or client bodies. Invariably, not all parties to the project will be linked to the tool and that reality just has to be managed. The other area of concern is potential incompatibility between client processes and the needs of the project. I have seen such conflicts and I can only say that serving the needs of a $5 billion project must come before compliance with internal processes laid down years before such tools even existed. No doubt though, that solution and stance won’t work every time.

I have to say that through the use of four different tools, I have yet to find one that does not provide very reliable up time and with improving technology and web access, that is only likely to either get better or stay the same.

BIM, Building Information Modelling, is one tool that is growing in popularity which can be used as a common platform for the design process from planning and design through to construction. It enables efficiencies to realised through the project life-cycle and will, I believe, provide improved benefits as technology advances. It is particularly when it is integrated with other platforms, but should that integration not occur, I can see BIM being left in the wake of other 3D advances.

The use of collaborative tools and methods is now more common, but they are still the exception rather than the rule. However, I see a future that will make them more useful, more user-friendly and probably more affordable, and that future comes by way of virtual reality, or augmented reality.

Whilst it’s been a while coming, there is now a wave of competing systems (most, admittedly, aimed at the gaming market) that will provide a greater degree of collaboration than was even considered possible only a few years ago.

Microsoft has now ‘distributed’ its Hololens solution to academia in the US and Canada. Oculus Rift driven by a $2 billion acquisition by Facebook is also a front runner. Sony has Morpheus and there are tools such as Vive and Google Glasses.

These are big players and this is a wave that’s breaking rather than forming. Whilst gaming is the main target market, training, self-instruction, and construction/engineering are going to be major clients.

Imagine sharing a 3D platform with engineer, builder, client and architect viewing the same issue in a virtual environment from different countries with a 3D representation of the building/structure before them, able to view the services behind the structure and foundations below it and to make instant changes to, colour, size, shape and position.

The contractor will, I’m sure, be able to virtually build the building before committing to the construction reality, something that could reduce tender prices and highlight clashes before costly on-site rectification. This is now the sharp end of the technology, and an important precursor to the eventual documented collaboration that these design interactions will produce.

The costs are not yet finalised but signs point to them costing less than $1,000 (US). Compared to the cost of a laptop or desktop or even mobile phone and given its usefulness, that is readily affordable by both companies and individuals. As ever, cost will go down as consumption goes up.

Whilst, as I stated earlier, construction is not an early adopter, I see this as being the likely exception to the rule.

There are significant benefits that have yet to see the light of day, and won’t until these tools are in use and are developed, but there are simplistic yet powerful benefits to be realised immediately for construction based upon what we do and how we do it.  There is little point waiting and I can see our industry leading rather than following when this technology hits the streets in earnest.

I, for one, can’t wait.