Session 2 - Design Delivery

Next Page | Previous Page

Consensus
Process
  • Design Review Meetings - It is very difficult to appreciate everybody’s challenges. Everybody “must get into the same room” and discuss delivery of the project. It was also suggested that meetings should continue as “mini live meetings” even changing models live in this meeting if people can drive the tools fast enough.
  • Contractor and QS Involvement - See notes from Session 3, Construction and Operation.
  • Collaborative Process
  • Site Coordination Responsibility At Outset - While it was accepted that the responsibility would be project specific, it was agreed that site coordination has to occur. This should be agreed at the outset of a project. It should be agreed clearly who is responsible and how this should be set up.
Suggestions
Process
  • Design Review Meetings Should Be Technical - It was suggested that the wrong people are often attending the design review meetings for the project set up. It was a comment that attendees should be the BIM Coordinators who have a technical understanding of their organisations capabilities including their software and design capability as well as process including information management and resource. They can convey that to the others in the design team, who in turn need to do the same. It was suggested that often the people attending are not technical and may agree (or not agree) to tasks that they assume are achievable, leading to risk. However it was also suggested that the meeting should be more focused on talking about design. “If we take away the BIM process, you are still left with the Design Review meeting.” It was suggested that while we need to appreciate some intricacies, that we should “not forget that we are delivering buildings here. This is not all about software - that's a distraction at the moment.”
  • Ownership
  • Volume Strategy Needed - This includes a clear understanding of who owns what in terms of space (or volume) within a building, “particularly the MEP”. The process for this would likely be the building services define their spaces and pass it to the Architects.
  • LOD Plain Language Answers - There needs to be plain language answers to LOD questions posed in the Employers Information Requirements. For example, what data you understand will be delivered next to the employers expectations at each data drop stage.
  • Matrix of Responsibilities - Responsibilities established in the Design Review meetings should be regularly reviewed and kept up to date in a Matrix of Responsibility.
  • Collaborative Process
  • Model Validation - Currently peer review only are acceptable for some. This includes validating the model against the 2D deliverables. For some it was 2 levels, first being a software model check, checking of the elements, such as a column being vertical and spliced correctly and then an information check of data within those elements, such a column size, material, and cost. Some suggested that software such as Solibri Model Checker should be utilised.
    Main Challenge Areas
    Collaborative Process
  • Who Owns The Stairs? Object Ownership - There continues to be little understanding of how to share multidiscipline elements within different models effectively without reverting to wasteful duplication, which could also lead to error and lack of coordination. It was suggested that the BIM Execution Plan has a part to play, this was illustrated by the comment that we need to “Understand the usage expectations of the model before we start, as part of the BIM Execution Plan. This includes factors that affect ownership including project type, stage, object type, contract type, client type and supply chain. “ It was stated that not having a clear idea on this could cause issues including inefficient wasteful workflow and duplication including in exports such as IFC/NWD and COBie. There was no industry protocol suggested to deal with this issue, and no guidance either formal or informal. It was suggested regardless of our aspirations to reduce waste here, other than getting everybody into a room to “thrash it out” on each project there is no scope for a solution.
    Please see appendix for notes on suggested solutions to the scenarios stated at BIM4Real
  • Object Ownership - Software Limitation- It was suggested that at least part of the reason for this is the lack of ability was in fact due to software limitations. The issue has a little more clarity when a single software platform is present, leading to the debate if it is reasonable to stipulate a software package on a project. One client stated this is exactly what they do currently. It was suggested that some of these issues would be resolved by moving to shared cloud hosted modelling solutions which would allow for a more effective workflow when it came to sharing elements in models.
  • Level 3? - Some questioned if in fact being able to establish shared element workflow was in fact BIM Maturity Level 3. This was contested.
  • Workflow Bottlenecks - There are concerns regarding “people having to sit on their hands” in some collaborative workflows while they wait for the release of the information. Communication and protocols regarding the frequency and manner of model exchange seem to be a clear priority in efficient workflow.
  • Trust - The issue of trust of information remains an issue. “Our Civil’s guys will not trust any information”, “Our structural guys do not trust the architects setting out”. Clear and agreed quality control procedures seem absolutely essential for the workflows to work.
  • Roles and Responsibilities
  • Additional Coordination Responsibilities - “It didn’t feel my team were comfortable with some of the additional requirements”. Collaborative BIM requires coordinated models. There was no consensus of who would naturally be responsible for this and indeed there were comments that people would be “uncomfortable” with the requirement to maintain a coordinated model with the other disciplines.
  • Confusion on Interference Checking Responsibility - It was debated if interference checking was required at all. The suggestion was that if standards and protocols are followed that it would not be a requirement. This was felt naive by some. If it is required where it comes to federated model checking, it was unclear whose responsibility it is and what process should be used.
  • Standards and Protocols
  • Level of Definition Protocol No Consensus - The protocols included in PAS1192-2 were not accepted by the group, and became branded as too generic. Indeed protocols produced by the American Institute of Architects (AIA) E202 document were preferable for some as they list LOD by discipline objects. “LOD’s need to be derived from client requirement at each stage for each model system”

Next Page | Previous Page