The requirement for Level 2 BIM on all centrally procured public sector projects is looming – from 2016 it will be mandated for all such buildings and infrastructure.
To help industry move to this level the government commissioned RIBA Enterprises to develop a tool to provide step-by-step help to define, manage and validate responsibility for information development and delivery at each stage of the asset life-cycle.
The toolkit, which had more than £800,000 funding from Innovate UK, is intended to be the chosen way of delivering projects to meet Level 2 BIM requirements, but how well does it work for the wider building industry?
To assist RIBA Enterprises in the development of the BIM Toolkit the CIBSE BIM Group tested out the nascent online toolkit (phase 2 beta) in the early part of the summer. Their findings and RIBA Enterprises’ responses are summarised below.
Testing the BIM Toolkit
Two teams of senior industry practitioners drawn from the CIBSE BIM steering group – representing designers, contractors, building operators, maintainers and clients – created a ‘project’ using the BIM Toolkit as a ‘client tool’. One group was set up as client/design team, testing from stage 0 to 4, and the other as a contractor/sub-contractor team considering stages 4 to 6. The aim was to use the tool in a realistic scenario using a hypothetical project for a small junior school.
Both teams had a shared concern about the ambiguity in the Toolkit of the terms ‘task’ and ‘deliverable’. These appeared to be interchangeable, with ‘task’ applied to design stage outputs and ‘deliverable’ to physical entities for incorporation in the project works.
A 3D model in NBS BIM Toolkit
In normal industry parlance a task is an activity while a deliverable is a ‘thing’ that is provided – and not all tasks result in a deliverable. In response, RIBA Enterprises has acknowledged the distinction and intends to add further explanation to the Toolkit.
Similarly, the CIBSE teams noted that the tasks in the Toolkit are not linked to a timeline; in the real world a task is required at a certain point and a project cannot move forward with tasks incomplete. RIBA Enterprises said the Toolkit is not intended as a substitute for detailed project-programming tools.
The CIBSE BIM steering group felt that, irrespective of the above, the fact the Toolkit did not provide a check of ‘deliverables issued’ was a missed opportunity for a client to measure stage progress/completion and to flag-up incomplete works before allowing other things to move forward. This was less of an issue of programming than of precedence- scheduling and ensuring delivery.
The group believed that integrating further information processes, such as those defined in the BSRIA BG6 Design Framework for Building Services, would provide a more rigorous, and usable, pathway through the ‘project’ with the Toolkit . RIBA Enterprises said that publishers with related content would hopefully create this in the Digital Plan of Works (DPoW) format and distribute it to their members/customers for use. It is its intention – or hope – that private clients will do this as well as publishers.
The steering group said the Toolkit will not allow a deliverable unless it is defined by Uniclass 2015. ‘Documentary’ deliverables were notably absent from the beta version. For example, the Toolkit ignored the need for some statutory documents required by the Building Regulations, such as: logbooks; commissioning certificates; air tightness test reports, and the like. RIBA Enterprises said that classification of more documents was in progress and that the CIBSE BIM group’s support would be well received.
RIBA Enterprises acknowledged that the ability to add custom deliverables and custom properties would be valuable to cover the possibility that something unusual is needed as a deliverable in a project.
The CIBSE BIM steering group was bemused by the Toolkit’s ‘product data templates’, which, unlike the official Product Data Tempates (PDTs) – currently being developed by the cross-industry collaborative user group through an open source, consensus, peer-reviewed process – did not follow the same skeletal structure and confused both general and project-specific information. To avoid further confusion, it recommended the Toolkit should adopt a different name for its product schedules, since they follow neither the format nor the process used by genuine PDTs. It suggested the term ‘Property Sets’ – as used in the DPoW brief issued by the BIM Task Group.
RIBA Enterprises said it hoped the BIM Toolkit’s level of information (LOI) would be used as a base by others intending to extend them, and that the Toolkit’s PDTs only provided a consistent language and core of minimum requirements to support the exchange of digital construction information.
The group considered that the beta version has some way to go before it will be able to deliver the promised efficiencies and opportunities for the whole industry
This response misses the steering group’s point, which is that the official PDTs are created only to be one part of the property sets in the Toolkit (or other version such as COBie). PDTs were intended only to capture general product data in a digital form for direct-inputting to a BIM. (Currently such data must be input manually). By misbranding PDTs, the Toolkit confuses the distinction between general and project-specific data and the difficulties of sourcing general data in digital form that the PDTs were invented to resolve.
It was noted by the steering group that the Toolkit allowed LOIs and levels of detail (LODs) that were not required to harmonise with work stages. For example, the DPoW allowed LOI 5 and LOD5 deliverables to be required at (say) work stage 2.
While the BIM steering group understood that the need for such arrangements arose where, say, a client always uses the same product and thus can specify it as a brief requirement. But it was still concerned that in the hands of ignorant compilers of a DPoW, ‘advanced’ LOIs and LODs may be specified that demanded detail that was neither appropriate nor indeed possible to provide, and which would add cost and complication. The steering group recommended the Toolkit should flag a warning where advanced LoIs and LoDs are specified, to allow inappropriate or reckless use of this facility to be challenged.
RIBA Enterprises acknowledged CIBSE’s observation that there were gaps in Uniclass coverage – for example, in the particular exercise undertaken by the review team there is no classification for school or commercial kitchens, only residential or recreational; no school toilet, only residential or women’s public, and so on – and they advise that further work on Uniclass is in progress.
The steering group considered that a ‘lay’ client would be unable to complete the project in the Toolkit without professional help – a point acknowledged by RIBA Enterprises.
The group observed that the Toolkit offered overly detailed scope descriptions at initial brief stage when outcomes and required performance would better define requirements and enable practitioners to help the client form the ‘final brief’. The Toolkit ignored this well-proven step to the genesis of good project briefs. The CIBSE team had a further concern that assembling the scope in list form would result in omissions that would be costly and disruptive to address later. RIBA Enterprises noted these points.
Summary
The steering group considered that the Toolkit process was extensive, but felt the end product was not as useful or detailed as existing, more user-friendly, project tools in defining roles, outputs and deliverables. They were particularly critical of the absence of wide-ranging schedules of tasks/deliverables.
They were concerned that unless the Toolkit is accessible and useful enough to be embraced by all those involved in a project, it will come to be seen as further bureaucracy and will not enable the efficiency, clarity and ultimately collaboration that are at the heart of the BIM mission. And since the Toolkit was designed as a ‘client-tool’, they saw that omission of delivery, operational and maintenance data as a critical and fundamental flaw in the beta version.
The group was complimentary of the RIBA-Enterprises team for producing so much good material in so short a time. The group recognised that RIBA-Enterprises
had insufficient time to properly incorporate the various suggestions from other stakeholders or to move far from the formulations of its existing NBS products in developing the Toolkit.
That said, the group considered that the beta version has some way to go before it will be able to deliver the efficiencies and opportunities for the whole industry, and especially the MEP sector, that the Government’s BIM mission promised.
The Toolkit comprises open fields that one independent commentator reckoned to involve 200,000 decisions to complete, yet, once done, still lacks the granularity to be as useful as established process systems, such as BG6. Further, it missed and, indeed, obfuscated the opportunity to embrace other valuable inputs, such as the industry-produced PDTs, which enables digital data to be more easily inputted.
The group remains keen to provide further input to the development of the Toolkit to help future iterations more fully accommodate the needs of the whole building community.
