Object detail versus cost detail
An important aspect to consider is how the designed objects integrate with the required cost detail. Taking the example of a concrete slab, if the costing document being used simply provides a line item for a slab there is little point in modelling a detailed build-up of all associated elements. However, planning for this requires collaboration to potentially save time in both the modelling and costing phase. Continuing with the slab example, if there is a detailed breakdown of all the elements specified combining the known depth and the area of the slab, one can calculate the volume of the slab and the other elements using the same object.
Including more designed objects and detail than the costing document requires, possibly due to the requirements of other applications of the model, will almost certainly be less of an issue than not producing enough detail within the model to complete the required cost plan. These issues were noted with regard to internal doors; for example, where there are different specifications of doors there are not always enough families created to cover all of the different variances and associated costs. Where internal doors have been grouped into one family and type, including both single and double doors, these cannot be separately identified and therefore specific rates cannot be applied to these objects. The model then needs to be updated to reflect the difference in detail, which adds time to the overall process.
This demonstrates the importance of getting the initial execution plan – specifically the LOD and level of information – correct in conjunction with the naming protocols agreed before the start of any design to avoid unnecessary delays, and particularly to let the design team have an understanding of the required costing detail before developing further objects.
When the NRM formal cost plans become more widely used and object libraries become more developed this will be less of an issue, but while this process develops it will be key for the project team to be proactive.
Coordination of design detail
During the process of the design it is important that all of the designers collaborate towards an amalgamated design in order to avoid abortive work and to minimise clashes within the final model.
As BIM is a collaborative process it is imperative that regular design coordination meetings take place, out of which an updated, clash-free, amalgamated model should be produced. The quantity surveyor, if they feel it beneficial, will carry out a quantity measure of each updated model and undertake a quality assurance check. It is important to run a quality assurance report that checks how the data have been used. This allows the quantity surveyor to provide specific feedback on naming protocols, LOD, level of information and any missing objects prior to the following coordination meeting, for incorporation within the designers’ models. This prevents delays towards the end of the design period as problems are identified earlier.
Coordination and benchmarking with the client’s existing cost model
One can appoint the ‘blueprint’ principles for design and cost, so they can benchmark and drive efficiencies within their business. Therefore, an added complication of working with this existing data had to be dealt with. Due to the detail of the existing cost model, it was felt that it was not appropriate to use the same detailed document for contractor pricing on a design and build procured project, where the existing contractor base was more familiar with producing simple cost tender returns.
It was agreed that using NRM as a standard was a suitable way to proceed for pricing, despite the contractor base not being familiar with it. Setting up the NRM database was straightforward within the costing software; however, there was the additional requirement of being able to benchmark back to the existing ‘2D cost database’.
The costing software has the ability to add extra detail against each cost line as required. Therefore, an additional column was added to the client’s specific coding system. Once data were exported from the cost software to the external spreadsheet software, it was possible to sort the information and benchmark back to the client’s existing cost database.