In order to really think about how we can put change into motion, we have to start opening-up areas of conversation that will alter the way we think and work as an industry. Amodal has spoken previously on how resistant the construction sector is to change; with this aversion comes a scepticism for anything that would actually improve the industry’s outdated processes – which are also prone to making things more complicated than they should be. When it comes to status codes (these define the suitability of information within a document on a CDE (common data environment)), the industry overcomplicates their very simple use. But why is this the case and what can be done to drive towards change?
Generally speaking, status codes are used by all members of the supply chain to make information traceable and visible. Part of the international BIM standard, ISO 19650, there are specific status codes for a document’s purpose, meaning that these codes change as a project progresses into another period. Statuses S0-S4 are generally used by architects, structural engineers, and consultants who are involved in the design stage of a building project. The latter stages, S4 and up, are typically used during the sign-off phases at the end of stages and pave the way for construction.
Status codes let stakeholders share information that isn’t ready for the authorisation stage yet needs to be communicated to the relevant parties, to ensure greater collaboration between those involved in the design stages.
It should be one of the simplest things to know what a document is used for, particularly when they help stakeholders to build a picture of a project through information. But whilst the allure of status codes is for many of us appealing, for others it represents a culture change that they just aren’t ready for. Some industry professionals for instance don’t understand the point of assigning and updating status codes, and this could be for many reasons including the fact they might not be sure why they’re doing it in the first place.
Status codes serve a very important function. From S4 (where the authorisation processes begin), stakeholders can follow the file status to learn when they can begin construction (typically at A5). Without the status being updated and approved, however, how else will they get the greenlight to go ahead?
Unfortunately, whilst this should work in theory there are some practical elements which hinder the efficiency of the status codes. Even though these codes play an important role in marking the development of a piece of building information, the process doesn’t do the codes justice.
The current ‘double-dip’ system is really letting the industry down. When we say ‘double-dip’ we are basically alluding to information that has been uploaded and then re-uploaded as a new revision purely because the status codes have changed (this most frequently happens with S4 and A5). It is super frustrating to see a document reach one of the final stages and still need to be manually changed and then re-uploaded. It’s an inefficient, burdensome task that in today’s technological climate could be easily ironed-out.
In order to further prevent the likelihood of double-dipping, it would also be beneficial for the approver to set the status and not the originator, but this can’t be done with current the technology. Architect creates a document and shares it for information (S2). Then after several months they revise the status so it can go for approval (S4). When approved it needs revising again, as approved to a number relating to the stage. The contents of the document may not have changed, but two revisions have needed to be created to update the drawing block. Is this necessary or can technology be the answer?
Amending a document’s status code without any manual, complicated effort should be easy as we are just changing two characters. We can ask Siri and Alexa to tell us the weather next week in Hong Kong, yet it’s strange that there currently isn’t a way to automatically update a document’s status code. Instead of having all this metadata, the alternative would be to utilise the technology at our disposal to ensure the data is continually updated. This approach will remove the current inefficient, error-prone process and all the double-dipping that leaves an unsavoury taste in our mouths.