Don’t bring in tech just for the sake of it, bring it in to solve a problem. And while tech has much to offer the construction industry, in many cases the answers can be found by – perhaps less glamorously – improving collaboration and planning, argues Dan Rossiter FCIAT.
More and more often I am seeing the most fantastic technologies being applied to construction projects to improve productivity and certainty, including 3D printing, laser scanning, generative design, and augmented reality.
However, despite the use of these technologies we are still failing to deliver projects on time and on budget. Research from KPMG and Oxford Global projects shows that construction projects more often than not fail to achieve target deadlines and budgets.
Historically in the UK, myriad government reports (Never Waste a Good Crisis and Modernise or Die, to name two) have highlighted lack of collaboration as the cause of our performance shortcomings. In response, many have looked towards digital technologies to facilitate this collaboration but have taken a blanket approach.
There is a trend to view tech as a panacea for all construction ills and look for ways to bring in tech generally (which ironically, can cause problems) rather than introduce it to solve distinct problems. Time and time again we see technological innovations attempt to disrupt the built environment, but as a solution looking for a problem.
A more fruitful approach would be to bring in tech when there is a real-life specific issue that needs fixing. And true change will only come once we recognise that design and construction is a process and articulate its activities and their interrelations clearly.
‘True change will come once we recognise that design and construction is a process and articulate its activities and their interrelations clearly.’
You’ll be unsurprised to learn I read a lot of British Standards. One that I reference, a lot, is ISO 22263, which outlines a framework for the management of project information. It establishes a construction project as a process, with sub-processes: inception, brief, design, production and demolition. With each sub-process (effectively a work stage) having its own inputs, outputs, controls and agents. Through this line of thinking, dependencies and a critical path can be established.
This is done by mapping processes and their respective activities process modelling techniques such as Business Process Model and Notion (BPMN), specified within ISO 19510, and Unified Modelling Language (UML), specified within ISO 19505-1and ISO 19505-2.
These processes can also be further specified with the information to be exchanged using an Information Delivery Manual, specified within ISO 29481-1.
For example, a process model could be used to express that an architectural designer would need to know the expected occupancy of a room before they could establish the clear width of a door. Similarly, the design process could indicate the need to engage with an accessibility and inclusion consultant to ensure that factors like level access are considered. These processes maps can be used in many scenarios, from complex workflows to something as simple as ordering a pizza.
While it may be unrealistic to notate all project processes, there would certainly be value in notating repeated processes as well as processes common across multiple projects such as spatial coordination reviews, and quality control checks. Such process models could be derived from sources such as BS 8536-1, BS 8536-2, the RIBA Plan of Work and the work of the Get it Right Initiative (GIRI).
So, before you or your organisation looks to embrace the next new technological innovation, I ask that you first consider what your organisation does and the role that technology can play in improving your productivity, sustainability, resilience, and reducing errors. You may find that to meet your goals and objectives technology is not always the answer…
Dan Rossiter is sector lead (digital transformation) at BSI
