BIM4Housing - Design Working Group Meeting- Notes & Actions-20220629

ANDREW De SILVA ‘DAS’ talks about focusing on 3 questions that they have already done some work on, then to go into a workstream and do further work on them, working towards an ideal workflow. He’s collated the feedback about the questions. If the questions are all refined and ready then they have to work out who should be involved in the workstream that follows.

The first one was the Project Delivery Program. Marc Bradfield made an important point about the engagement of specialists at the PCSA stage. MARC says that the problem with engagement is that people tend to be in sales mode - for him it’s about the actual design. DAS: zonal requirements have to be agreed on as early as possible, though even when they are agreed this can change due to financial and/or product constraints/changes. MARC says if you’re talking about engaging with specialist subcontractors to unlock specialist information, from their point of view there are two elements to the price: the design, and (the much larger cost) installation. There’s a problem if you don’t end up procuring through that specialist subcontractor because there is not always one answer to a problem.

PAUL MCSOLEY agrees with MARC that if you change products the things that would have been the issue in the first place actually, if you didn’t have a product in the first place, you’ve still got the same problem no matter what. So, you need the specific product to unlock it all because the wall is a system of ducts, dampers, doors etc and there are different requirements to install each products - one thing effects another thing. MARC says as a client he wants to minimise his exposure and push his cashflow to the other side of that line, but in reality, to do the job right, that cashflow needs to be earlier.

ANA MATIC considers that it’s not just to do with cashflow, it’s to do with risk. Most clients opt for D&B because they want to de-risk their side of things. There is a commercial and design risk reason why suppliers are not brought on early because, firstly, you might pay for something that you are not going to use. You might also make early decisions that end up redundant because the whole thing has changed. Early supply chain only works if you can specify an entire prefabricated system. In this case you can bring your suppliers on board at stage 3. Everything else, there is no point bringing suppliers in early because they might do loads of work and eventually you change everything.

GEORGE says it’s not just commercial risk. On compartmentation, by leaving the procurement of the selection of M&E products later in the process there is much greater likelihood that the penetration seals are going to be in the wrong place. The cost risk is mitigated but the safety risk and the risk of quality is going to be increased. JAREK thinks the client needs the client side consultant engaged early to be responsible for checking what assumptions and constraints been made and whether they are being followed, and if not flag them up so it can be actioned.

MARC agrees with JAREK and, possibly controversially, says that when he picks up a so-called spatially co-ordinated stage 3 design, where you would assume those assumptions have been applied, it’s not unusual to find that as you further develop your building services you will find those assumptions were wrong. Or, to be frank, that something has just been manipulated to present itself as a stage 3.

PAUL says MARC is absolutely right. He’s not sure that ‘specialist’ is the right terminology, it’s a combination of the construction of the actual core, the material that’s been used and its performance. You end up with designs that come out that structurally work…looking at ‘specialist’ if an architect has drawn everything out with a services consultant but it’s not based upon products they have probably got no hope in hell of getting it right in the first place because the rules are just not generic - it’s all based on the services being tested in the supporting construction that was appropriate in the test.

JIM CREAK says that a minor discrepancy in the planned ceiling height can cause a lot of trouble on site with attempts to fix this potentially leading to non-conformance. JAREK replies that the biggest problem from his practical experience is that no one is actually responsible, no one actually checks and says ‘this is wrong or right’. He thinks its linked to the lack of competency of the advisers as all of these things can be established early (as the science doesn’t change, it’s all predictable). Architect JOE STOTT shared his view via chat: ‘Totally agree - Design Rulebooks need developing and agreeing. This is what pre-fab brings by default, but these rules need developing for all designs’. He thinks the idea of developing a rule book at the start of the design always pays dividends later on down the line. When projects don’t have that framework to refer back to it’s a bit of a free-for-all. If a design change comes about that will break those rules it has to be agreed upon and everyone (particularly the client) should be made aware that it’s happened.

Some designers like rules and some do not.

MARC says it brings it back to the topic of standardisation. You are standardising the things we are doing day in day out rather than the facades etc. (therefore architects still have some creative freedom). JOE, looking at car design, notes that the rules are established but there is still design in that process. PAUL MCSOLEY says that one of the things is we don’t really understand standardisation in the first place, we don’t understand that if you change something (away from the standard) it actually goes into ‘other’, you can still do it but you have to identify it, you have to do something different and test it.

LIAM WHEATLEY compares the situation to the car industry and how they know that there are a particular number of variants to chose from, this could be replicated in the building industry e.g. a bath would measure up to a certain limit.

DAS really likes the rule book idea. Maybe project by project there could be a rule book that covers all offices or all schools etc, however on some projects there may be other specialist elements of the design which actually does need specific input. The lead co-ordinator/architect may say to the M&E engineer ‘do we not need something like this? maybe we need some input’ - maybe that’s the way to be less generic and more specific and therefore help explain that to the client in terms of their cash flow and risk management. Also, apart from the designers, he finds it really useful to get input from the installing maintenance teams because it’s easy to get things to fit digitally in a model but to get it installed in real life and the things you need for that/maintenance adds another layer of tolerance and zonal requirement which the designers themselves may not be aware of.

MARC wonders if they are only repeating what they should all be doing anyway. Maybe this is us trying to take it to the next level as we respond to the question. He asks everyone in an absolute (unachievable) perfect world do they agree that as a basic principle it would be far better to complete the design before you started building?

ANA MATIC says you can’t compare something that comes out of the ground with something manufactured in thousands of units (referencing the IKEA products Marc mentioned). A lot of architects are already working on platforms (calling them that rather than individual projects). Let’s say there are 2 or 3 platforms each to build housing and schools. All the suppliers and contractors plug into those platforms and everyone knows what they are doing. At every single stage as soon as something changes everything else has to change to adapt to that: that is design. It’s very hard to design that out. Realistically, there are gateways and we need to fix ourselves to those gateways and try and fix only those things that are being questioned at that specific gateway.

DAS, replying to MARC’s question, says he thinks there is an agreement that the design should be completed by the end of stage 4, because that is what the gateway is asking for. In terms of standardisation platforms, the more we can create assemblies that are repeatable that’s great. How to we get the input we need from other parties which are not part of the core team at the right time? Using gateway 2 as a hard stop to identify to the client the reason why a certain input is needed by a certain specialist to enable us to complete the design by the end of stage 4. Is the question that we are really asking input from the other working team/s about their internal discussion about how much can the procurement route change, are clients willing to spend potentially more money to meet the requirements of the gateway.

JIM asks, regarding the rule book, are they really talking about real prescription? He supports prescription because he thinks it's the way to achieve the objectives, but in the standardisation process there are currently loads of choices. GEORGE thinks one of the issues with standardisation generally is because there are so many different stakeholders….as a community we can say, to achieve the objectives, we should work in a more prescriptive way. JAREK says the modular approach to design is causing things to become less prescriptive. He thinks it would be handy if they linked the gateways to lessons learned to show the client specifically that if X is not done then Y is most likely to happen. Regarding the rule book, he doesn’t think it’s another standard, it’s more a practical link to lessons learned. Asset information requirement is often missing from projects and that should be part of the rule book.

PAUL talks about the difference between descriptive and prescriptive. JIM thinks you have to go back to basics on the difference between a sleeping risk (descriptive???) and a standard risk (prescriptive???).

GEORGE has learnt this week from a conversation with a door manufacturer that the details of the circumstances of test standards are not available to the client or maintenance because it is commercially sensitive. He asked if you swapped out some components would the test not be valid? The door manufacturer said yes. The concern is that one of their competitors could see what type e.g. hinges they are using and therefore that could be used against them. With standardisation the data needs to be standardised. it’s surprising that the information that seems to be safety critical is secret. PAUL replies that there is a problem with manufacturers having their R&D stolen.

DAS says the second question is about the Change Management process. Change shouldn’t be happening after the design is complete at the end of stage 4, but inevitably sometimes there will be changes. It would be useful to know the output of the workstream regarding being clear about what is a major what is a notifiable change so that can be managed. MARC says they can’t run the scenarios as they don’t know what constitutes a ‘major change’. PAUL says a major change is going to be something structural e.g. a change in principle of smoke control or evacuation. The minor changes will be the wrong type of damper or wall etc. There is some debate about when gateway 2 ends.

For PAULA CHANDLER, Gateway 2 is a milestone not a duration. MARC agrees that it has to be a milestone because it’s what allows you to commence on-site. PAUL says there is no way anyone would submit a completed stage 4 where every element is completely designed out when you haven’t got product, so then it would be a phased approach. This change process, which is still part of gateway 2, is going to be a nightmare when it comes in. MARC and PAUL discuss about what constitutes a major change and a minor change. Regarding timescales, MARC thinks that a Major change is four weeks and a notifiable change is fourteen days. He can’t remember is anything is defined as ‘minor’ or not.

In terms of transitional arrangements, MARC was of the mind that if a project had already started you could go through to gateway 3 even though gateway 2 had not been signed-off, but this may now not be the case. JIM CREAK considers that everyone is right to say the Fire Safety Bill applies to every building.

GEORGE is in touch with Steve Coppin who is being very helpful, so if he can get a summarised set of questions he will run through those with him. Also, if he can get a summary of the questions MARC was asking he can put those to several different lawyers.

For the last twenty minutes of the meeting DAS wants to look at the final questions around the idea of some of the documents in there and about aligning - how do you go around aligning the responsibilities of the team. He’s noticed the disconnect in various contractual documents which are not very clear, they are not using a baseline standard or classification system to define it e.g. the scope is not aligned to the BIM, execution plan not aligned to the design responsibility matrix. He doesn’t know of any good examples of how that’s been realigned. Also, the as-built or final record drawings that MARC has commented on…

MARC says it’s a big deal that they now actually have to provide an as-built drawing and somebody needs to consider how to get enough confidence through that build process for an individual/organisation to sign it off ‘this is as built?’. DAS says he doesn’t know if there are templates which have been issued for Fire Statement/Construction control plan/As-built etc - these are phrases that were extracted from the guidance. We may ask the building safety regulator if they are going to provide some kind of structure around these. PAULA thinks they need to work backwards from what they need to establish a) whether the building is working safely for them and b) if not, what other information is required. Is KOBE data (currently used) the format that it needs to be in? We need to look at it from the end user point of view and then adapt accordingly.

GEORGE is working with asset management companies and is looking at how the new Fiery information can be delivered in a way that it’s part of KOBE. George has a slide about this and may be present in the future if people are interested. GEORGE says to PAULA that the FM team is as a similarly complex group as the construction team - there are so many different stakeholders with many different needs and we need to make sure we can accommodate all of them. PAULA says they also have a wide range of competencies spanning digital to old drawings, how do we up-skill and identify that level of competency on a project-by-project basis and appeal to the middle ground?

JIM wouldn’t mind seeing what the definition is of a fire and emergency files and then he may be able to help in that regard. The idea is to change it to a QR code so you can scan it and have access. If it takes 3/4 hour to go through a control box to find out what you want (in order) during an emergency, it’s a really detailed thing. Most fire and rescue deployment officers, turning up with a complete set of plans, wouldn’t actually know where to start.

JOE, regarding as-built and KOBE information, wonders when exactly it should be collated and handed over. Even if we get that record 100% right at handover the odds of it being 100% right 12 months later are extremely slim. Therefore, even with our best efforts, that data is potentially out-of-date. MARC says there is a need to continue with the safety case going forward beyond gateway 3.

GEORGE says to JOE that you need both data drops: they need that handover data set early, then at the end of the defect period that should be a version of…that’s a revision probably…JOE wants to push his service beyond handover, an aftercare period. GEORGE says that post occupancy evaluation is often put into schemes and it always gets struck out. DAS says that installing a door which e.g. is 60 minutes rather than the required 30 minutes starts to change the entire baseline design that all future changes should be assessed against.

MARC will send GEORGE an explicit set of questions to ask the lawyers.

PAUL, regarding change control process, says understanding how that process is supposed to work in legal terms kind of makes it a bit easier to understand how it’s going to work with the regulator. Both the regulator and the client’s lawyer may take action against you if it all goes wrong.

DAS asks MARC id he is doing anything to recheck the alignment of these kind of documents? MARC replies, DRM, absolutely - that’s an ongoing process. On the BIM side the big discussion is about transitioning properly over to 19650 and embedding Uniclass into everything. DAS says working on something to tie the 3 main documents together where there are often variations is a good idea: the DRM, the scope, and other documents.

PAUL says that, for the all the architects in the room, the fundamental issue with DRMs is that fi you’ve drawn a building out generically without any products then you go into novation to a contractor and they say ‘here’s all the products, go ahead and re-draw it’, you’d say ‘our fee doesn’t cover that, you have already spent the money’.

DAS says that, where possible, the goal is to reduce ambiguity - the more it’s reduced the better it is for everyone, as it can typically lead to heated discussions.

ADDENDUM

COMMENTS VIA CHAT

Stewart Bailey

I believe architects will either embrace the opportunity to design with standard parts or stay completely bespoke. In our world, I believe those that don't work with standard parts will find their market shrinking.

As we develop a Lego kit for DFMA / MMC architects deciding to ignore that will become niche

VW/Audi can build 4 million variations of cars off 3 standard platforms - we need to do the same

Joe Stott

Is a Major change something that breaks the established parameters in the Rule Book?

Marc Bradfield

On the 'Fire Statement' and thinking about templates worth looking at the list of items that have not been correctly considered in Gateway 1 applications to date.

Paul McSoley

Building Safety Bill: factsheets - GOV.UK (www.gov.uk)

Building Safety Bill: factsheets

These factsheets provide more information about key provisions in the Bill.