Many industry practitioners argue that the structure of a collaboration system should follow the traditionally “paper-based” model of information sharing on a project wherein essence you only see what you have been sent.
By labouring this argument, we’re almost admitting that we believe “paper-based” systems work best and we have no need for improved efficiency in our processes. Traditionally we didn’t have collaboration software, so management teams were unaware the complex and rapid flows of information which delivery teams have to contest with on a daily basis. Having the ability to understand these information flows, plus interdependencies of the various design and construction disciplines give us much better ability to make informed decisions in a timely and proactive manner.
Collaboration systems are now available to us, designed to improve efficiency and improve communication, and thus enhance collaboration between project team members. We should be embracing the fact we now have an abundance of (software) tools that allow us to manage, share and develop very rich libraries of asset information, and not be sacred about it; instead embrace systems, because ultimately they will enable us to develop and deliver a much better quality of end product to the client.
The collaborative effect of BIM
This collaborative aspect becomes very relevant particularly with the emergence of Building Information Modelling (BIM) in our industry, which is all about integrating teams, engaging operators and facilities managers into the design and construction process to produce a more fit for purpose end product and a more productive operational building.
With BIM, we’re actually talking about creating better design and built solutions, assets that operate effectively the way we expected them to operate and at the right cost and efficiency levels.
Procurement, access rights and ownership of data
When it comes to the selection of a collaboration system for a project, the decision is one of paramount importance, but also one that’s frequently based on the past experience of the project team members and/or cheapest price.
Responsibility for procuring the system is usually left to the main contractor or the lead consultant, as software is often viewed as an overhead (rather than an investment), and therefore gets built into their fees for other cores services. There are of course clients who do recognise the value of such systems, and will lead the initiative, but far too often the final decision is based on the lowest price tendered. Rarely are decisions based on critical issues such as who has ownership and custody of the data, or to ensure that the proposed systems conform to the contractual terms that need adhering to when engaging with clients.
In the UAE market, most consultancy and construction appointment contracts are non-standard and are usually client specific. These contracts are also driven around the concept that the client is “king”.
Take an example of a design consultant; they may design the building and own the Intellectual Property (IP) rights to that design. However, the agreement entered into often gives the client the ‘license’ to reproduce that building in the future, without the need to necessarily secure his services again. Much of this is to do with the way that the contracts have been written, where the client keeps hold of all the rights to the data as their projects come to end. Although when selecting a collaboration solution, the ownership requirements of the client is often not considered up front.
Those of us who work on construction projects are usually delivering to a single party whether it be the main contractor, or the client; ultimately this is the one who’s paying our bills and who we’re contracted to. As mentioned earlier, it’s this party who in the main owns everything.
As construction teams work on a many different collaboration platforms, there’s a bit of schism as different systems (and their inherent licencing arrangements and architecture), might mean that the many parties involved could own different piece of data. As such, one of the key issues that we want to talk about and explore further is who does own the data.
The data produced during the design and construction of a project doesn’t always go along with the asset once the project completes. Collaboration platforms over time end up holding huge amounts of valuable asset data with detailed audit trails. It’s our view that this rich library of information gathered should always be passed to the client or ultimate future owner.
A point also worth noting is that the owner of a project may change. A project could begin with the developer who later sells on the asset to an owner occupier, who could potentially sell it on to a further owner or operator who may be is responsible for running that asset. All of these owners and stakeholders need access to the historical project data library for the running of the asset, as it’s this valuable information that plays a part in significantly reducing their future refurbishment and maintenance costs.
Again it’s really about addressing whether people understand the importance of this information at the start of a project and realising the benefits of reusing this information at the end of the delivery phase so that it becomes part of the built asset and has real value.
It is true to say that not all collaboration tools are the same in terms of who owns the data and who has access to that data.
Where does the data reside?
A critical feature of hosted systems relates to data; where is it hosted and how it is managed. When using Software as a Service (SaaS) solutions for the first time it’s important to understand if your data is being hosted locally or in a foreign country which could be a major deciding factor on which solution to adopt.
A couple of very key additional points to consider are: –
- Is the data and the solution hosted in a relatively simple, generic data storage environment?
- Or is data hosted in a business critical environment, managed and supported 24/7 with the appropriate data security standards, available from wherever and backed up by a Service Level Agreement which doesn’t compromise your business.
With the maturing of the market for hosted solutions, many clients are quite happy that their data is managed in a very effective and efficient way, by a third party in a fully controlled and audited environment and delivered to them as a service.
There is alternative scenario, where some clients believe it’s important for software to be procured and managed locally (self-hosted on their premises) and if that’s a requirement then that’s something that needs to be addressed. This type of approach will no doubt reduce options for collaboration offerings, as a main characteristic for this software is that it’s hosted and delivered as a service to projects by an independent third party vendor.
At the end of the project where does that data go?
Clients should set about with a minimum expectation that they will to be delivered a full set of structured project data at the end of the project so that it can be reused readily by themselves, their maintenance teams and/or future owners.
This is far more challenging to achieve in practice as not all collaboration solutions share information in the same way. There are certain collaboration platforms whereby all the information that resides in that platform is only owned or accessible by the organisations that produced it or that received it, that’s it! On the other hand these are other solutions which are more open and (as the name suggests) collaborative allowing the organisation that has procured the solution to retain control of all of the project information.
In our view, what’s really important about the latter type of platforms is that the client has all of the auditability and reasoning behind why certain decisions were made in the design and construction process to create the building in the way it has been delivered. Ultimately it’s about giving our Clients an efficient operational building that runs at a cost effective rate….and access to the historical data is a big part of this.
What should be discouraged is selectively hiding information in the system from the client due to the fact it was not directly issued to them. The simple rule should be that if it’s been submitted on the client provided platform, then it should be available for them to review and proactively report upon. By having a solution that is quite constrained in the client’s visibility of their own data, somewhat defeats the object of having a collaboration platform in the first place.
On that note, I do think sensibility should prevail and that we are reasonable about what it is the client should expect from us, as service providers to them.