CIBSE BIM Steering Group. Feedback. NBS BIM TOOLKIT (Beta Phase 2)

Transcription

1 CIBSE BIM Steering Group Feedback on NBS BIM TOOLKIT (Beta Phase 2) Ref CIBSE TR Rev 01 Date 30 th June 2015

2 Contents: 1. Introduction 1.1 How to use this report 1.2 Background to study 1.3 Objectives 2. Methodology 2.1 Literature search 2.2 Consultation with industry 3. Feedback 3.1 Edit Project Details Section 3.2 Details Section 3.3 Tasks Section 3.4 Deliverable Section 3.5 Export 3.6 General 4. Conclusions and recommendations

3 1. Introduction 1.1 This report has been put together on behalf of CIBSE BIM Steering Group to support RIBAEnterprises in producing a workable BIM methodology usable by the industry as a whole. The NBSBIM Toolkit phase 2 beta launch was open for comment 11 th May The CIBSE Steering gave prior commitment to RIBAEnterprises following the informal feedback to the soft launch during phase 1 (March 2015). 1.2 Two teams of senior industry practitioners drawn from the CIBSE BIM Group representing design, contracting, FM & client sides met to create projects from new. This was carried out in two independent groups and their findings are merged here. 1.3 This report is based on the observations of the various practitioners who have contributed. As far as possible their observations have been included verbatim without editing, and the report has not been edited to a consistent style, in order to allow the observations of the contributors to be more fully and clearly expressed. The following individuals constitute the working parties who have challenged the NBS toolkit Beta site and have recorded their comments via this document to share with RIBAEnterprises. Michael Bartyzel BuroHappold Carl Collins Arup Paddy Conaghan Hoare Lea Les Copeland WSP Group Jose Fandos - BuroHappold Martin Howe Shepherd Engineering Services John Sands - BSRIA Dhan Tagie Cofely FM Richard Vincent - Arup With support from - Hywel Davies - CIBSE

4 2. Methodology 2.1 After first inspection of the NBSBIM Toolkit (phase 2 beta) the CIBSE working group agreed this report should be against the NBSBIM Toolkit in its intended use as a client tool with the overarching aim that Public Sector projects will be to a minimum of Level 2 BIM by This report has been prepared by two independent teams of experienced practitioners, who each worked together in a manner similar to a project team meeting, developing a project within the RIBA Enterprises digital Plan of Work. The projects are based on a realistic example building. Group One - a Client/Design team testing from stage 0 to 4 Group Two a Contractor/sub-contractor from stage 4 to 6 This methodology was adopted to try to provide a realistic test of the tool for each project team. The working group also considered the type of project to be used, due to time scales and the basic appearance of the Beta site, backed with what the group considered as a likely candidate to use the NBS BIM toolkit following its full and formal release, the group agreed on a public sector type work, small in scale and very common across both the industry and regionally. The following parameters where set out for both groups to build a project. The project. Junior School Acorn School Acorn Road, Little town, Northshire. Client Northshire County Council 6 class rooms (for 30 pupils each class) 1 main hall (for 200 occupants) for dinning and to be used as a PE space 1 commercial type kitchen. 1 Toilet Block 1 staff room 2 staff/visitor toilets 1 1 st Aid room 1 head teachers office 1 open plan entrance area / reception / library area. 1 play ground 1 playing field 1 car park for 20 cars The building will be single story of basic brick and flat roof construction. Lighting, small power, LTHW (mix of UFH and radiators, fed via heat pump plant), domestic water services, mechanical ventilation to the toilets and kitchen (natural ventilation to all other areas), PVs on the flat roof.

5 3. Feedback The following sections are comments arising from the groups when they tried to create two project in real time on the NBS BIM Toolkit Beta site; the comments have been grouped in to each TAB on the NBSBIM Toolkit. 3.1 Edit Project Details There are no test reference projects which can be reviewed as a benchmark for input data for the BIM toolkit? Could NBS provide this? You are only able to log-in as an individual via your address, rather than as a company or project wide team. Under additional information, Function is difficult to find unless you are familiar with Uniclass D. A search facility would be useful. Modelling units should be set by default for UK projects. This page has a Save details button. Why is there one here when there isn t one for the rest of the site? 3.2 Details Ability to copy details from other stages is useful Ability to set current stage is useful 3.3 Tasks There is some ambiguity between what constitutes a Task and what is a Deliverable? Terms we use in our day jobs are defined very differently. There, a Task is an activity while a Deliverable is a thing that s provided. So this vocabulary is strange. Task and deliverable terminology is strange and confusing! From our brief discussion with Stephen Hamil on 24 th June, it appears that a Task is an activity that relates to preparing documentary information in early stages while a Deliverable is used at later stages and relates to artefacts within the Project which may also involve associated activities (like design & specification) rather than just procurement, assembly or the like. We wonder if the distinction between Task and Deliverable would be apparent to a lay client using the Toolkit, Could we ask NBS to provide clarity by defining ALL the terms within the Toolkit? We observed that the Toolkit Tasks only referenced documents to be delivered through associated task descriptions (e.g., prepare / provide document X ) but that it doesn t automatically list them or summate stage deliverables (in the way it does for tasks), other than those entered manually. Since checking deliverables issued is a more reliable means for a client to measure stage progress/completion than assessing tasks completed, this would seem to be a missed opportunity particularly as stock deliverables are explicit in each stage s stock tasks and such lists could readily be formed by linkage to the task lists. Tasks are not given any time and/or gateway status. Surely if a task is required at a certain point then a project cannot move forward leaving tasks incomplete? We are not

6 recommending that the Toolkit be used as a programme to drive the project, but it should flag up incomplete works before moving forward? [The Toolkit] requires the ability to set a date for completion, tick box for task owner to state that the task is complete and a tick box for the project owner to confirm that the task has been completed satisfactorily Surveys appear in the Systems table. This doesn t seem to make sense other than perhaps this has been a short term measure pending the publication of an Information classification table. It is the view of the whole review team that given the widespread use of BG6 in the MEP sector, there needs to be a greater connection between the BIM toolkit and BG6 3.4 Deliverable We were particularly concerned that no deliverable, whether product, system, document or other thing, can exist in the Project if it doesn t align with something covered by Uniclass Documentary deliverables are especially absent from Uniclass 2015 (although a few feature, somewhat strangely, in the Systems table). We felt this approach is not workable since there will always be the possibility that something unusual or novel will be needed as a deliverable in a Project - which realistically the compilers of Uniclass 2015 could never anticipate. This is an observation that CIBSE representatives have made on several previous occasions. Would a separate wild card project-specific table defeat the tenets of a classification system? There is also the issue of the need for statutory documents required by Building Regulations, such as Logbooks, to be addressed in some way, such as logbooks, commissioning certificates, air tightness test reports and other statutory reporting requirements to BCOs. Given that the whole purpose of adopting BIM is to enable Better Information Management, then it is essential that these sources of key operational data are firmly embedded in the tool We and the wider industry are bemused by the Toolkit s Product Data Templates, which, unlike the official PDTs being developed by an ever-expanding cross industry collaborative user group through an open source consensus peer reviewed process, do not follow the same skeletal structure and confuse both general and project specific information. As this is causing unnecessary confusion in the industry, we recommend that the Toolkit adopts a different name for its product schedules since the product schedules follow neither the format nor the process used by genuine PDTs. We recall that NBS at one stage referred to these schedules as Property Sets (which is a more accurate description) and we therefore suggest that name is reintroduced in the Toolkit. Since the wider industry has come together to create PDTs in a collaborative and noncompetitive manner, it is essential that the digital Plan of Work recognises and adopts the PDTs. Otherwise, providing product data into the dpow will become an additional task, defeating the object of PDTs of developing a cross industry consensus based open source agreement on peer reviewed data formats for product data. Deliverables are not given any time and/or gateway status. Surely if a Deliverables is required at a certain point then a project cannot move forward leaving Deliverables incomplete? We are not recommending that the Toolkit be used as a programming tool to drive the project, but it should flag up incomplete works before moving forward. While we recognise that there needs to be scope to uprate LoIs and LoDs from the stage defaults (eg. to accommodate multiple repeat projects which always use the same

7 products), we fear that in the hands of ignorant compilers (that abound overseas), LoIs and LoDs can be specified that demand detail that is neither appropriate nor indeed possible. Hence the selection of alternative LoIs and LoDs begs a health warning that can be used by those responsible for delivery to challenge inappropriate or reckless use of this facility. Search and filtering user interface works well We noted that the sample LoI for one product we reviewed included manufacturer information at Stage 4. Stage 4 is a detailed model that employs generic products. As manufacturer data would ordinarily not feature until Stage 5, these fields should be removed from LoI 4 parameters. LOD and LOI drop down boxes do not display numbers properly. Several issues with gaps in Uniclass coverage. If it s not in Uniclass you can t add it as a deliverable; eg no school or commercial Kitchen (only residential or recreational), no school toilet (only residential or Womens public) Dimensions for a space Useable height is in m 2? Search can only be by description eg Toilet, not Uniclass code may be helpful if you could search by code. Searching for WC doesn t return anything Sometimes there is no display for LOD or LOI at all is this a bug or just that it has not been defined yet in the software? No Uniclass Space for Entrance, Atrium or Library Can t put a null value in for useable height when this value is not relevant eg for a playground We added Spaces and Systems at Stage 3 but were not entirely clear how much should be added at each stage some guidance would be helpful When using the with definitions filter, this doesn t work - because some of the items displayed after applying the filter don t have definitions. Searching for LTHW only displays 2 products towel rails and underfloor heating How will deliverables that aren t part of the model be verified? eg for a Classroom at stage 2 LOI

8 Will there be a proposal for standardising LOI data fields in a model? LOI data doesn t necessarily correlate with COBie. How has this been defined and can we have access to the LOI definitions? COBIe definitions are not really apparent until LOI 6 for products Copying deliverables from stage to stage with incremented LOD and LOI is very useful My main concerns with the Toolkit are that LOI, LOD at Stage 6 appear to exclude technical data for the asset, that maintenance requirements are missing from Stage 6 and its limitations of only admitting deliverables/tasks based upon Uniclass Could we nudge NBS in the direction of BG6 in order to define these parameters, particularly with its use of a responsibility matrix and clearly defined tasks? The fan coil unit object doesn t have any performance data at Stage 6 LOI. It only includes information to let you buy another one, not to understand the performance of the existing unit, meaning you can only buy the same thing again and not look for an equivalent unit from an alternative manufacturer (as would be necessary if the original model was obsolete). I suspect this may be a similar situation for all equipment in the Toolkit. Deliverables cannot be added if they don t already exist as a classified thing. This is an issue where the deliverable is not an object or system. LOI can be selected at Concept design providing detailed information from the classification system is this correct? NBS to provide a sample of the product in use to clarify any misunderstandings. To fail to have a comprehensive schedule of duties /deliverables in a central resource like the Toolkit is a massive lost opportunity for the industry.

9 3.5 Export Function is easy to use and useful for Task and Deliverables COBie export some fields are completed automatically - eg. Install date , but others are not - eg. description which is n/a 3.6 General If X is correct about the absence of maintenance data at Stage 6, this is a serious omission! When the Verify component is functional will we be able to check a COBIe.xls against LOI deliverables? Require the ability to set permissions for Participants such as read/write, etc. Would be useful to have notifications of when tasks are due. Functionality is currently let down by incompleteness of Uniclass Document Management Classification including O & M Manuals, CDM files, etc;.need to be referenced and searchable. There is also a need to consider such things as commissioning certificates, building logbooks, air tightness test certificates, which are all statutory requirements under the Building Regulations. 4. Conclusions and recommendations The above commentary comprises anonymised verbatim quotes from respondents which we have attempted to group coherently. It can be seen that respondents repeatedly make many of the same observations. We were very aware that members of our working group panel are major project people while the Beta Toolkit is a work-in-progress and inevitably would lack the granularity we would have anticipated. Hence the groups selected a relatively small scale model project for testing purposes, attempted to behave in assembling the Project as the sort of lay client typical in those circumstances and finally to judge the outcome based on the fairly simple needs of the model project. This approach however, raises a number of issues and concerns: I. A lay client could not complete the Project without professional help. II. We did not understand how scoping is to be undertaken but considered that the front end (Stages 0 &1) would benefit from the sort of scope lists used in professional appointments; specific enough to identify to participants what the building is expected to comprise and to assign them elemental responsibilities but sufficiently generalised to not preclude optioneering. At present, the Toolkit appears only to offer quite detailed elemental scope descriptions that should not sensibly be addressed until Final Brief Stage 2.

10 III. A further concern about the way scoping is assembled is that it admits the real possibility of unforeseen omissions. While neither of our working groups actually completed all entries for a Project we are mindful of the blog by Arup s Casey Rutland, that compilation might typically involve 200,000 decisions. Certainly, we formed the view that the process was extensive but the end product was not as useful or granular as existing, more user-friendly, project tools in delineating roles, outputs and deliverables. True, we come from an industry that routinely depends on BSRIA s BG6 which far exceeds anything used elsewhere! But we consider the Toolkit s stated tasks are too simple and intuitive fare. They lack the breadth and detail of those that the CIC Group came up with in 2013 under Rob Manning s direction (examples of which we ve sent to RIBA-E). To not have comprehensive schedules of tasks /deliverables in a central resource like the Toolkit is a lost opportunity for both clients and the industry. While we understand that the Toolkit is now held out as only a client tool, we fear that, unless it is useful enough to be embraced by all parties involved in a project, it will come to be seen as further bureaucracy that defeats the goals of efficiency, clarity and ultimately collaboration enshrined in the BIM mission, articulated by Francis Maude in However, we also believe the Toolkit offers real scope to develop into a methodology that all actors will want to use. In particular, if the toolkit is developed to embrace BG6 and to adopt genuine industry produced Product Data Templates, it would have the potential to make a significant contribution to the delivery of projects in the public sector and beyond. Our conclusions here do not reiterate our comments in earlier section even though some are very important. But recognising that it is client-focused, we would highlight the Toolkit has not addressed the delivery operational & maintenance data, this needs more attention prior to the next NBS BIM Toolkit release. Finally, we applaud the RIBA-E team for producing much good material in so short a time and for helping to set the datum for all of us involved in BIM use on projects. We believe that the Toolkit offers opportunities for the whole industry that the Beta version does not yet address, which we would be most willing to discuss in the coming period.