Many different data sets are required to plan, design, construct and operate a building: such as Client Requirements, Functional & Technical needs, Construction data etc.
A recent dRofus webinar on ISO 190650
Coordinating and consolidating all of this is a big challenge. dRofus aims to provide a solution, but processes and workflows out of the control of the software require good standards and guidance, which is where ISO 19650 fits in.
ISO-19650 is an international standard for managing information over the whole life cycle of a built asset using building information modelling (BIM).
It contains all the same principles and high-level requirements as UK BIM Framework and was born out of PAS-1192.
ISO 19650 currently has 5 parts, and this blog focuses on part 2 (ISO 19650-2) which relates to the “Delivery Phase”, and describes the workflows and tasks required of project teams during design and construction – right at the sweet spot of a typical dRofus deployment.
In recent times, the conversation has moved on from more BIM, more BIM, to the collaborative production of Information. What information needs to be produced? who should produce it? when and how?
By adopting the standard, we are starting to talk a common language. People are aware of Asset Information Requirements, Levels of Information etc. Clients – or the Appointing Party - are required to be much more informed and much more involved (a challenge in itself).
Another issue we face is the reality that there are probably more BIM standards, from around the world, than there are people that are using them consistently. Which has been the big problem in the industry over the last 15 or so years. As BIM has evolved, so have the concepts and approaches, standards haven’t always caught up. Plus, every company has developed their own company standards out of necessity for project delivery and are reasonably well entrenched. But what we are seeing now is that many governments around the world are aligning their own requirements to the ISO, which is fantastic!
If you upskill your organisation in order to understand the ISO and what it means in terms of your responsibility and deliverables, you can work on projects around the world, whilst limiting your risk or exposure. As we all know, what has often happened historically is that the person signing the contract doesn’t always understand what they’re agreeing to from a BIM perspective. ISO 19650 will not totally eradicate this, but it does provide a more consistent base for working.
The list of definitions in the standard is extensive to we highlight a few which relate back to the operation of dRofus.
Information requirements – what when, how and for whom information is to be produced. This will involve dRofus as data will be exported in the form of reports, schedules etc
Project Information Requirements – related to the delivery of an asset. Again, certain deliverables will come directly from dRofus, such as the Accommodation Schedule, Room Data Sheets, Bills of Quantity etc.
Asset Information Requirements – relate to the operation of an asset, here properties such as the Unique Asset Identifier, make, model etc. will typically be authored or stored within dRofus.
An Information Container – a named persistent set of information retrievable from within a file, system or application storage hierarchy. So, in those terms dRofus is certainly an Information Container. Also, some of the exports that come out of dRofus (schedules and reports) are also Information Containers or sub-containers of information.
Common Data Environment (CDE) – defined as an agreed source of information for collecting, managing and disseminating each information container through a managed process. Arguably dRofus could be viewed as a Common Data Environment, but we feel this would be confusing in an already confusing area so best to say we are not for now but can take that discussion further on another day!
Some common misconceptions about CDE’s are that is a Single Source of Truth, a single software program etc.
Our understanding of ISO 19650 is that it could relate to several systems. In fact, there is a buildingSMART initiative to develop a CDE API, an open standard way for them to communicate.
Level of Information – in dRofus we can define the extent and granularity of information, plus relate this to user permissions.
ISO 19650-2 also talks about Information Management in the context of creating registers, risk assessments etc. But it also describes the need to be able to answer “business questions”. This also is not a totally new concept, but highlighting it’s significance and the need for it to be continually updated is interesting. Typically, this might be included in an early Scheme Design report, but often this information is forgotten shortly after
What now follows is a high-level review of the steps and processes described in ISO 19650-2. Within sections 5.1 (Assessment and Need) to 5.0 (Project Close-out) there are 8 key stages and 40 processes.
For high-level assessment we have reviewed these key tasks per stage and categorised 3 discreet status for dRofus: No direct role (red), Supporting Role (yellow) and Central Role (green).
If we start with “the red’s” – those which do not really involve dRofus. For example,
5.1.3 Establish the Project Information Delivery Schedule & Milestones. This is not a task you would do within our software
5.2.4 Compile Invitation to Tender Information. Technically we can store documents within our software and our Enterprise Customers could use this as a method of distributing information to Tenderers But this is not really what we claim the software does and typically this happens in specific Tendering Systems.
Next, we have “the Yellow’s” – where dRofus plays more of a supporting role, or is perhaps noteworthy.
5.1.1 Appoint information management function – this could be someone from the Client organisation, or the lead appointed party, either way this person needs to have an awareness of dRofus software
5.2.1 Establish appointing party’s EIR – how will the OIR, AIR and PIR’s be exchanged. This involves information within dRofus, or exported from dRofus so will need to be factored in.
5.3.2 Establish delivery team’s BIM execution plan – most of you will know what a BIM execution plan is, well we often see sections dedicated to dRofus or even a separate dRofus Management Plan created as part of the suite of BIM documents for the project. At dRofus,we have created several of these in the past for clients, generally when there is a strong need for capturing Asset Data and transfer this from the Project Team, to the Operations / FM team.
5.3.3 Assess task team capability and capacity – this generally takes the form of a survey or questionnaire, again we are seeing dRofus appear in these. For example, how many staff has been trained? Have you used dRofus on past projects?
5.3.5 Establish delivery team’s mobilisation plan – this requires testing information exchanges, developing and delivering team training so again dRofus will need to be factored in
5.3.6 Establish delivery team’s risk register – no-one particularly enjoys thinking about risks, or where a project can go off the rails but just like any technology that will be used to help deliver a project there are a number of risks around the Delivery Team’s capability, what happens if there is a failure?, information gets lost etc. Thankfully dRofus is built on a very robust infrastructure, everything is automatically backed up, we have a detailed log of all user changes, granular permission levels – but nonetheless the risks and the risk reduction or avoidance measures may need to be documented.
5.3.7 Establish delivery team’s tender response – a previous point mentioned about creating the BXP, but this often has sections for the Delivery Team to fill in, who will do what, when etc. so this would also involve defining things like whether dRofus is an agenda item for BIM coordination meetings, whether there is a separate dRofus / Data Coordination meeting. Who from each organisation is responsible for overseeing the use of dRofus and production of deliverables??
Finally: ”the Green’s” are where dRofus plays a core role.
5.1 Assessment and Need - As we know a CDE consists of several Information containers. dRofus is in itself an Information Container and also produces various outputs that are information containers.
5.2 Invitation to Tender - This task involves sharing information about project initiation, information from previous project stages and so part of this relates to the project Brief. The list of rooms and requirements will typically be developed within dRofus. There may be support documents also uploaded into our software. Plus, key client requirements. If this is a note within a PDF document, it can often get lost or forgotten about. Whereas if it is a property in dRofus, it is far easier to retain and can potentially be measured against the design.
5.4 Appointment – Many functions here can be delivered via dRofus
5.4.1 Confirm delivery team’s BIM execution plan – within the nominate dRofus software you can nominate individuals, decide how the information will be produced
5.4.2 Establish delivery team’s detailed responsibility matrix – with dRofus confirm what information will be exchanged between whom, which task team is responsible, information dependencies
5.4.3 Establish lead appointed party’s EIR – record Appointing Party’s needs e.g. briefed area and level or information
5.4.4 Establish task information delivery plan – collaborative processes, i.e. Architect must do X, before Engineers can do Y, and vice versa
5.4.5 Establish master information delivery plan -in dRofus factor in production, review, dependency etc
5.6 Collaborative Production of Information – again these tasks are very much in the wheelhouse of dRofus . And they can occur several times, as there is typically several issues of information
5.6.1 Check availability of Information and Shared resources – speaks for itself as a key dRofus deliverable
5.6.2 Generate information – there are several deliverables typically produced from dRofus such as Accommodation Schedules, Room Data Sheets, Finishes Schedules, FF&E Schedules etc. Likewise there are many workflows that might involve dRofus, such as the coordination of codes that appear on drawings
5.6.3 QA well a key feature of dRofus is the ability to check / validate of what has been modelled vs client requirements
5.6.4 might involve reviewing information within dRofus rather than an export and the ISO also requires capturing if the review is successful or not. In other words, you might have to record the reasons, which might take the form of a comment or note within dRofus that is included in the final export of the report/schedule.
Finally, 5.8 Project closeout where dRofus can assist with such as Rooms closeout, Equipment commissioning, Model validation, Document capture, Handover data-set, archiving dRofus database, Use completed database for next project.
We trust this overview gives some insights into the tasks and processes of ISO 19650-2 and how dRofus can manage your delivery expectations with the standard.
In conclusion, we would state that there is no doubt that to continue to be successful, the construction industry has to shift towards the collaborative production of lifecycle information. dRofus is excited to be developing a solution that will truly connect the value chain. Enabling Building Lifecycle Intelligence. Watch this space for further developments!
Navigating ISO 19650-2 and want to understand more about the role dRofus can play? Let's chat!
COMMENTS