Practical BIM

11

  mais    Próximo blog»

Criar um blog   Login

practical BIM Practical tips on making BIM work. 29 January 2016      Subscribe via RSS

How to define BIM Use For those that don't know, a BIM Use is a task, outcome or deliverable that a BIM model is used for. For example when a BIM model is used for structural analysis, or to create a door schedule, or provide data for an FM system. When talking about BIM Use we mean "Building Information Models" (actual digital models), not as in "Building Information Modelling" (BIM processes). Because of this some call it Model Use, but I shall stick to BIM Use, as there is a world beyond BIM with other types of models.

Subscribe   via email:

Blog Archive ▼  2016 (1) ▼  January (1) How to define BIM Use ►  2015 (8) ►  2014 (6) ►  2013 (16) ►  2012 (18)

BIM Use is at the core of  BIM. The basic concept of BIM is that data created is captured in a form and format that can be directly used as a resource for other purposes.  So doors are created in such a way that a door schedule can be produced directly from those doors. That modelled structural elements behave in a way that allows for structural analysis. Yet there seems to be massive confusion around BIM Use. What should be simple is made incredibly complicated by BIM standards, BIM contract clauses and BIM theorists. I've written before about BIM Use and how it is being applied to LOD, in my posts LOD, are we there yet? and What is the use of BIM Use.  But those posts don't offer a solution. Unfortunately when confronted with something unintelligible and unworkable we tend to avoid the whole thing. But BIM Use can not be ignored. If we are going to really do BIM we have to have a workable way of managing BIM Use.

The purpose of a BIM Use Let us start with the basics. Why have a BIM Use? A particular BIM Use must have a useful real world outcome. It should only be listed as a BIM Use for a project if there is a specific reason to do it; a specific party who will do it; a specific party who will receive the results; a specific outcome that aids the design, building or operation of the project facility. This sounds so obvious yet is missing from most definitions of BIM Use. Discussion always seems to be around what is possible, rather than what is required, let alone practical.

Who employs BIM Uses BIM Use is invariable talked about as the uses of external parties. Typically uses by the BIM

About Me Antony McPhee Registered architect since 1986, I have been a project architect on projects ranging from large commercial and cultural developments to house extensions. Developing CAD systems since 1988, involved in BIM since 2001. Now running a small architectural practice and consulting to architectural practices on IT, BIM and practice management. My particular skill is bridging IT based processes with practice deliverables. View my complete profile

model author are ignored. Apparently if a structural engineer uses the architect's BIM model for structural analysis that is a BIM Use, if they use their own it is not. I suspect this is because no cross­organisation agreement (or demand) is required it is not considered part of "BIM Process". The problem is these in­house BIM processes are then not considered when agreeing on other BIM Uses. This can create problems when externally required BIM Uses compromise, or completely prevent, an author's own BIM Uses. To capture who is doing what it is useful to define BIM Uses against who they are between: 1. Within a discipline ­ e.g. schedules from model 2. Between disciplines within a team (e.g. architect, engineer, QS etc.) ­ e.g. energy analysis 3. Between teams (e.g. design, construction, operation, etc) ­ e.g. asset management 4. Across disciplines ­ e.g. estimates 5. Across teams ­ e.g. clash detection Doing this not only ensures all BIM Uses are considered but also reveals what contractual requirements might be or not be needed for the project.

LOD is not BIM Use For a particular BIM Use to be achievable the BIM model must have certain requirements. Currently these requirements are described via LOD descriptions. Typically an LOD has certain BIM Uses associated with it. This is the AIA [US] approach. From their E203 guide: "The E202's Model Element Table provides a vehicle for defining Authorized Uses, Model element by Model element and milestone by milestone." But in practice how do you define "Authorized Uses, Model element by Model element and milestone by milestone."? Considering there are literally hundreds of different possible "Authorized Uses" are we really expected to list them not only against each Model Element, but against each Model Element at each Milestone? The most practical LOD guide created thus far, BIM Forum's LOD specification, has tried to deal with this stipulation by kind of white­washing it. From their 2015 edition: "Because BIM is being put to an ever increasing number of uses, the group decided that it was beyond the initial scope to address all of them.  Instead, the definitions were developed to address model element geometry, with three of the most common uses in mind – quantity take­off, 3D coordination and 3D control and planning.  The group felt that in taking this approach the interpretations would be complete enough to support other uses."  

But the AIA[US] approach is fundamentally flawed, it is the wrong way round. BIM Uses should be listed with the required LOD against them, not LOD with allowed BIM Uses. What LOD tables actually do is to define the level of development each element is to have as the project progresses, at each milestone. This is a reflection of reality ­ project information progresses at the rate it is gathered, decided and created. You can't make information and decisions magically appear because you need it for a BIM Use, and have put it against an LOD table in a contract. LOD specifications, matrices, tables, whatever you want to call them, need to remove references to BIM Use. It just confuses and complicates them. A proper LOD table is an indication of model progression, when which parts will have what information available, based on what is realistically achievable. BIM Use should be a completely separate list, referencing LOD's to describe what is required for them to be done. By comparing BIM Use requirements with LOD inclusions and progression a realistic assessment of what BIM Uses are feasible, and when they can be

undertaken, is possible. The current process of  using LOD definitions to determine what "Authorized Uses" are possible is delusional, it will never work in practice.

Who decides BIM Uses? Another problem with the AIA [US] approach is that it defines what BIM Uses are "permitted", not what uses are necessary or even desired. Again from E203: "The term “Authorized Uses” refers to the permitted uses of Digital Data" Wouldn't a better approach be to define BIM Uses on a project by what uses participants want to perform? Not what a BIM author says they are permitted to perform? In the E203 guide it states that the "usual approach" is to take the position "because some of the information is not reliable don't rely on any of it". And that their intent in E203 is to change that to "because some of the information is not reliable you can only rely on the information that I explicitly say you can." Now that seems a sensible approach. If an architect tells you the walls in their model are LOD 200 then ignore any materials in those walls. The problem is when LOD 200 also means the architect is saying these walls are suitable for a particular BIM Use by some other discipline. Because then we have gone from the traditional "we provide our information to you at your own risk" to "we will provide you sufficient information for you to perform your professional responsibilities." The result of this can be the BIM author allows no Authorized BIM Uses at all, which is no better than providing it at receiver's risk. Or the author claims information is adequate for an Authorized Use but it is not (and they refuse to rectify it), because they have no idea of what is actually required. Or a third scenario where the BIM author is penalized (or sued) because the model they provided was demonstrably not suitable for an Authorized Use they permitted (or were forced to permit under their contract). Either way those attempting to use the BIM model for a legitimate BIM Use are left in the lurch, and BIM authors are left at risk.

As bad as letting BIM authors decided who can do what is, there is another, worse, (and very common) approach to deciding BIM Uses. That is the assumption the owner should do it. Not only that, but the owner should do it at the very beginning of the project before the various experts required are engaged. Of course it is legitimate that the owner make decisions on their own BIM Uses ­ facilities management, building control etc., and BIM Uses that may effect their decision making and built quality ­ crowd flow simulation, 3D visualization etc. But asking owners to list all BIM Uses for their project is absurd. The reality is the majority of BIM Uses are by the design and construction teams, to assist them perform their work, the work the owner has engaged them to be responsible for. Normally you would expect the owner to select design and construction professionals that have the skills to do the things they would like done. I don't understand why when it comes to BIM the expectation is that by simply listing a BIM Use in a document is will magically be done by whoever gets engaged, no matter what their skills. I know owners are the ones that pay everyone, and so can tell everyone what to do, but that doesn't by definition make them the best qualified to make decisions about all BIM Uses on a project. Expecting them to do so is delusional.

What about Standards For something so fundamental there is a surprising dearth of standards that directly address BIM Use. Maybe it is too much like hard work to be so specific about particular BIM Uses. BIM Excellence.org has started a list of BIM Use definitions, 125 listed so far, although not all have actual definitions. A good start, to avoid duplication and standardize terminology. At first sight COBie could be considered a kind of BIM Use standard. Although it sets out the required output it doesn't directly describe required model progression, and it takes no

account of the LOD concept. For example it makes no distinction between data never applicable or just not available yet ­ any empty fields must contain "n/a" in a COBie deliverable. A real BIM Use standard would set out what LOD requirements are for model elements to achieve the use. The BIMforum LOD Specification is probably the only real BIM Use standard. It clearly sets out LOD requirements for quantity take­off, 3D coordination and 3D control and planning. But it should be renamed the BIMforum BIM Use Specification for: Quantity take­off; 3D coordination; 3D control and planning.

(with apologies to BIM Forum)

As BIM Use is invariably performed by software you would think software vendors would have an interest in establishing standards that optimise their software performance. Although competing software specific standards are not necessarily the best approach. IFC is kind of in this space. MVD (Model View Definitions) define elements required for specific views of a model, which could them be used for a BIM Use. But IFC is really about software standards, not software use or BIM processes performed by humans. I believe some standard definitions around BIM Use would be really useful. Currently beyond asking specific people on my projects I have no way of knowing what is required for a BIM Use I don't participate in.  Although standards can be part of the solution they can never be the only solution. The expectation that every BIM use for every discipline or team for every project will be covered by a standard is delusional. And what do we do while waiting for standards to be authored, discussed and agreed? What we need are processes that establish BIM Use protocols.

Current BIM Use process The process doesn't have to be complicated. Let's think about it from first principles: 1. Someone wants to use something for a specific purpose. 2. They say what that is and what they require for them to do it. 3. Whoever is best placed to provide that is identified. 4. Negotiations occur between the provider and user. 5. Agreement is reached on what processes will be followed.

But in the world of BIM planning the procedure is: 1. An authority figure decides what BIM Use everyone wants. 2. They guess what is required to achieve these BIM Uses  (or use a "BIM expert" to guess). 3. They impose these requirements on everyone. 4. BIM authors, not the owner, decide what specific information they will provide for a BIM Use.

When confronted with the obvious impracticality the usual snake oil response from BIM evangelists is that "the BIM Execution Plan is a living document that can be changed."  That

might be a method to fix impractical outcomes but it doesn't justify why there is an impractical process in the first place.

A better BIM Use Process That said negotiation is still the best method. It not only ensures everyone is doing things they are happy(ish) about, it provides an opportunity for everyone to have their say. But negotiations have to occur in a framework that is realistic. Pretending they can occur before everyone is appointed (or that everyone be appointed at the very beginning of a project ­ as in IPD), or that parties will agree when there is no incentive to do so (when only authors decide what "Authorized Uses" are permissible), is delusional. The owner should be the one to set up the framework, project participants the negotiating. Therefore the process for owner is: 1. The owner lists the BIM Uses they intend to do.  ­ e.g. FM, budget management, etc. 2. The owner lists possible BIM Uses that others may do, and are desirable for the project. ­ BIM Uses that may or may not be used on the project that participants may be called upon to provide BIM models capable of being utilized for.  3. The owner acts as arbitrator in participant negotiations. Then as each project participant is engaged they must have shown the ability to satisfy the relevant owner's BIM Uses, and the capability to satisfy the the relevant possible BIM Uses. As the exact requirements of the possible BIM Uses are unknown, and may not even occur, fees do not need to specifically allow for them, ensuring owners are not paying for something they may never need, or that someone else (the BIM Use recipient) may pay for. As each project participant becomes involved in the project they are required be involved in a BIM Use identification and negotiation process: 1. BIM Use request.  ­ A participant nominates what they intend to use BIM models for (including uses that the owner may have engaged them specifically to do). 2. Define and communicate data required.  ­ For each of their BIM Uses clearly describe what data they require and at what stages. 3. Identify source/author of data.  ­ Based on data required,  and through negotiation, identify who will be generating the data, or who is best placed to create the data. 4. Agree on extent/format/form of data that will be provided.  ­ Negotiate with that party on what data they can provide, and/or are willing to provide. 5. Agree on process to supply data.  ­ Negotiate timing, degree of reliance (LOD) and checking & rectification procedures. The owner may become involved at point 3 if there is dispute over who the appropriate author is, and at point 4 if agreement on extent of data can not be reached. If it is determined extra data is required the provider and recipient can exchange services (you scratch my back, I'll scratch yours); the recipient pays (because it saves them money); or the owner pays (it adds value to the owner and/or project). Or it is not done as there is no measurable benefit.

There you have it. There is obviously a lot of nuance around the detail but the above process is, to me, a more realistic way of approaching BIM Use management. It is not a radical proposal, nothing unfamiliar is introduced to BIM Execution Planning. Indeed most current BIM Planning guides would only require slight adjustment to formalize this approach. Let's take BIM from the theorists and make it genuinely practical.

Posted by Antony McPhee at 16:50 

No comments: 

Recommend this on Google

Labels: BIM Plans, Management, Standards

30 October 2015

Should Owners ask for BIM? There is this idea in the BIM evangelist community that owners, the ones who commission a facility, should specify what BIM is to be used on a project. Not just what BIM will be delivered to them, but how BIM will be used by everyone involved in the project. To me it makes no sense. Do you tell your dentist what instruments to use, your accountant which software (or calculator) to use, your lawyer which case law to take heed of? And I suspect owners are just as perplexed. Why are they being asked whether the structural engineer should use the BIM model for structural analysis, whether the contractor should use 4D, 5D, field BIM? Aren't they paying these experts to make those decisions? Actually I know they are just as perplexed. I've sat in meetings and workshops where the owner's representatives are bombarded with these types of questions, and not surprisingly they don't want to answer them. They're smart people, it not that they don't understand BIM, it is that they don't see themselves as the ones responsible for it. Yet that is how BIM evangelist see it. In their eyes the problem is owners don't understand BIM. After all the owner, as the one with the money, is the only party who has control over the whole team. Therefore, the evangelists surmise, they are the ONLY ones who can enforce BIM on a project. The fact they are unqualified, uninterested and don't see why they should take on that risk are wilfully ignored. Besides the absurd impractically of it, what also bothers me with this approach is the idea that BIM must be enforced. That BIM is only possible if all participants are coerced to engage in it. If that is the case it suggests BIM is only beneficial to a few, that others have to be forced as they gain nothing. This is so far from the truth. BIM processes improve efficiency and effectiveness of all participants. Sure it takes money up front to invest, time to learn new ways. But after that investment you can do more with less effort. As they say, work smarter, not harder. So if you are an owner, should you ask for BIM?

APPROACHES TO ASKING FOR BIM There are a number of ways an owner can approach BIM on a project. The approach used will inform what processes need to be put in place for the project to be successful (in a BIM sense). Ignore BIM Totally ignore BIM, assume it doesn't exist and make no concessions for it to occur. Allow BIM Accept BIM can occur and not stand in its way. Make concessions for it to happen. Encourage BIM Appreciate BIM is worthwhile and actively encourage its use, but not directly engage in BIM processes. Participate in BIM Integrate your own BIM processes into the BIM processes of others. Demand BIM Enforce BIM of your own design on all project participants. All are valid approaches and depend on the particular circumstances of the project and the available people.  But what is critical is that there is honesty in the approach taken. Don't pretend you are encouraging BIM when in fact you are ignoring it, don't demand BIM when all you need is to participate in it. Before deciding which approach seems right let's debunk some myths about BIM for owners.

BIM IS NOT JUST FM

One of the misunderstanding going around (sometimes I think wilfully) is that BIM is equivalent to facilities management. That the only thing BIM means is the use of a 3D model connected to a database to manage the maintenance of a facility. At the extreme end of this view you have people who think that if you get the design and construction teams to use BIM you will have a fully functional BIM FM system at the end of the project. I don't understand how anyone could think this was true. Why would a BIM model created to design, analyse, and coordinate a building, or one to cost and program it be suitable for facilities management? Yet I have had clients say they want our Revit model provided to them, complete with paint modelled, so they can use it directly for facilities management. A lessor, but none the less just as mistaken view, is that the BIM done during design and construction is just there to provide the data for the FM system. And further, that if BIM is not used during design and construction it is not possible to have a BIM based FM system. Lets think about this a bit. To use BIM for facilities management you need a graphical 3D model and a database of information. You could pay someone to create the model and populate the database when you set up the FM system. Or you could get the whole design and construction team to change they way they do their work just so they produce a 3D model and populated database at the completion of their work. Does that second method really sound sensible? Why would you compromise a much bigger process (the design and construction of a facility) to reduce the effort of a smaller process (populate an FM database)? BIM evangelists go on about how much larger the cost of running a facility is compared to building it. But design and construction BIM can only ever contribute to the initial set up of the FM database, it has nothing to do with the ongoing operation. But BIM is not just FM. It is used for much more than that. And once that is realised the benefits can be captured. If design professionals use BIM for their processes, they will have a lot of data, including 3D graphical data. The contractor can utilize this data for their purposes and add data they use. This data won't be structured to suit FM, after all it has been created for other purposes. But there is a fair bit that can be used for FM. The cost of restructuring this data to suit FM is theoretically less than completely recreating it. That is the benefit of BIM.

So don't ask for BIM if the only reason is to provide completed data for your FM system. There may be cheaper ways of doing it. And don't ask for BIM, or BIM deliverables, if you have a paper based rather than BIM based FM system (I know, kind of obvious, but surprisingly common). Do ask for it if you want to access to BIM data created for other purposes for your FM system.

DON'T KILL THE GOLDEN GOOSE

Of course you may not have a BIM based FM system, nor intend to implement one. That's a commercial decision for the owner. If you don't need BIM for FM, why have BIM on the project at all? BIM is a tool, a tool to do real world things more efficiently and effectively. It is useful for anyone who uses it properly and for the right reasons. If your design and construction teams use BIM on your project there is an opportunity for the project to be done more efficiently and effectively. You, as the owner, benefits from a project that is less likely to suffer delays, is less likely to spring surprise additional costs, and will result in a building with a higher quality of design and workmanship. So if you want a well run project you will want BIM to be used. But the owner is not responsible for timing, cost overruns and building quality. The design and construction team, via their contracts, have these responsibilities. And if the owner instructs them on how to do their job, how to undertake their responsibilities, the owner takes on some of those responsibilities.

ENCOURAGING BIM The best way an owner can ensure BIM is used is to not dictate, not enforce, but to encourage BIM. How might this be done?

SELECTION The first step in encouraging BIM is to engage BIM capable professionals, to include BIM capabilities in bid requirements. By that I don't mean a description of what BIM processes a bidder must undertake, but a request the bidders provide a description of the BIM processes they already do. In this early period of BIM take up you may extend this to include BIM processes bidders intend or are prepared to implement. The aim is to get them to make an offer, for the use of BIM to be their responsibility. But keep in mind BIM is but one aspect of why you select a particular bidder. Professionals are primarily engaged for their capabilities in their area of expertise, and service performance. BIM is only a tool, it won't compensate for lack of expertise or poor service.

AGREEMENTS & CONTRACTS

The second step is to ensure agreements and contractual arrangements allow BIM processes to work freely. As mentioned above all BIM processes (except facilities management) are between the design and construction teams.  This is a challenge for those drawing up and approving agreements. Traditionally contracts have been designed to be between the person paying and the one doing the work. BIM capable agreements require additional clauses that set out how those being paid will interact with third parties ­ other project participants. Obviously there are a whole raft of issues to consider, and the type of BIM processes undertaken will influence what specific requirements will be. Which is another complication. The owner is not a participant in these BIM processes (with the exception of facilities management), nor are the exact BIM processes known at the beginning of a project before everyone is signed up.  The BIM evangelist's answer is to ignore reality and assume the owner HAS to be a BIM participant, and that everyone HAS to be signed up at the very beginning of a project (as evidenced by the push for Integrated Project Delivery type contracts). But it doesn't have to be this way. Contracts need do no more than ensure the free flow of information in BIM type format. That is, BIM information created by project participants must be freely available to all other project participants. Sounds simple but there is a paranoia about theft of intellectual property throughout the industry. The default position is to withhold information. Contracts need to specifically override this position. Tied in with this is that all information in deliverables must match. That information on drawings and schedules match information in BIM models. And that recipients of BIM models can rely on the information in those models. It must also be specified this only applies to information a participant would ordinarily provide. If an architect includes some ducts in their model for context, that doesn't make them responsible for the completeness and accuracy of those ducts. Contracts could be further extended to be BIM friendly. For example allowing for project participants to do modelling for others participants, whilst responsibility is retained by the requesting party. So the architects might model ductwork for the mechanical engineers (or sub­contractor) but the engineers or sub­contractor must check and approve that modelling work. BIM capable agreements and contracts are in their infancy and no one can predict what their eventual form will be. But I believe if we approach them with a view to encouraging, or allowing BIM, rather than enforcing BIM, we will end up with much more useful agreements and therefore BIM workflows.

EVIDENCE OF BIM  Rather than demanding direct BIM deliverables they will never use owners should look at requesting evidence of BIM. Requesting evidence also means that even if specific BIM is not defined by owners they can still influence the use of it on their project. There is nothing wrong with requesting evidence of BIM processes as deliverables. The owner may not participate in the creation of a BIM Management Plan, but they can include it as a deliverable. They may not attend clash coordination meetings but minutes of outcomes can be requested. However evidence of BIM should never be provided for 'approval'. Not only does this pass some responsibility back on to the approver (the owner) but has the potential to hold up the project. The purpose is purely to ensure what has been promised (see SELECTION section above) is being done. An owner may reject a BIM Management Plan as being incomplete or inadequate, but should never 'approve' it.

REMUNERATION BIM is often touted as 'costing more'. But research has shown overall a project using BIM processes is more cost efficient. It may be directly cheaper and/or quicker to build, or a more complex result is achievable for the same time and money. The problem is that not all participants share these cost savings equally. Which is easy to see when you look at how BIM works. BIM models are created early in a project and passed on to participants through the term of the project. The architect models the building, the mechanical engineer uses that model to do energy calculations, the mechanical engineer's model is passed on to the mechanical sub­contractor who uses it as a basis for shop drawing and CAM, this model is passed to the facilities manager to populate their energy

management system. The further up the chain the more complete the model is and greater the savings in time and effort. And of course the owner is at the top of this chain. Another issue is some participants are required to do more than they have previously done. Engineers traditionally produce diagrammatic drawings and performance requirements for equipment. With BIM they have to model their work accurately and select specific components (otherwise you can't model them). Of course paying them extra to do this work is not the only solution. But someone has to do it, and no one is going to do it for free. BIM also requires more work up front. The mechanical engineer can't do an energy analysis on a half modelled building. If the point of BIM is to create a complete virtual building to test its buildability then it has to be completely designed and modelled before construction starts. BIM may 'cost more' for some, but overall it does not. So it is not necessarily about spending more (although that will certainly bolster use of BIM!). To encourage BIM there needs to be a re­think of where and when money is spent. More money is required at the pre­ construction BIM model creation stage. This may be in the form of extra for design professionals, the appointment of additional professionals, or bringing forward engagements (e.g. services sub­contractors). And within those engagements payment schedules need to be revised. Fees are normally broken up into stages. With BIM more work is done ­ more hours expended ­ in early stages than traditional work methods. I don't believe a similar concession is required at construction as BIM processes bring enormous cost benefits to contractors. In fact I believe owners need to be careful they are not paying for BIM efficiencies that the contractor will pocket. Any BIM from the design team should be treated as an asset that benefits the contractor. 

DIRECT ENCOURAGEMENT And of course owners can directly encourage use of BIM. Not by demanding it, but by having a strong expectation that the team will use BIM processes. Owners don't need to have intimate knowledge of those processes, but they can expect their design and construction professionals do.

CONCLUSION So what is the answer, should owners ask for BIM? As is the case with most questions, that depends. But here are some recommendations.

Ignore BIM Not recommended. If you don't understand BIM or don't want it don't stand in the way of those that do. The fact others use it will not cost you more, nor will it increase your workload.

Allow BIM If you are unsure and don't really understand much about BIM this is a valid approach. It provides an opportunity to learn from others.

Encourage BIM Encouraging BIM is the best approach if the owner does not have a BIM based FM system. It allows the design and construction team to make best use of BIM for their purposes. It also creates a wealth of BIM data. It is not structured for FM use, but can still be mined for useful FM data.

Participate in BIM A truly BIM project has everyone participating in BIM, including the owner. Owners can participate by having their own properly set up FM system that uses BIM. Having skin in the game, so to speak, means BIM deliverables can be properly valued as to their worth. And if everyone is a participant BIM planning can be undertaken with confidence, and result in even greater benefits than individual use of BIM brings.

Demand BIM Not recommended. Unless you are a conglomerate with architects, engineers and contractors all under the same roof you should not be dictating what BIM is done. Even then care must be taken to ensure some participants are not working inefficiently for questionable benefits elsewhere.

Posted by Antony McPhee at 10:48 

3 comments: 

+4   Recommend this on Google

Labels: BIM, Management

29 August 2015

Everyday BIM This month 3 years ago, August 2012, I started the practicalBIM blog. My original intention was to blog about practical ways to make BIM work. But when I started reviewing the literature on BIM I became alarmed at the misunderstandings and direction BIM was heading. It soon became apparent that as well as things that should be done to make BIM work, there are also things that should NOT be done to make BIM work (or at least not more work than it needs to be). It seems to me the misuse of BIM stems from some basic conceptual misunderstandings, (or intentional misconstructions) of BIM. If I believe these people are mistaken, what is my conception of BIM? How and why is it different? So on this anniversary I thought it timely to do a post setting out my views on BIM; not special, world changing BIM, just ordinary Everyday BIM.  First some thoughts on what BIM is not.

BIM is not  A UTOPIA

BIM is a set of processes that manages certain technologies. It is, and always will be, changing. As new technologies become possible new process will evolve. And it will eventually be superseded by a new acronym for a different approach, just as BIM superseded CAD. There is no end, no point in the future where BIM will be perfected and stabilized. Why is this important to appreciate? If you are adopting BIM under the assumption it is a one off exercise that leads to an amazing outcome you will be sorely disappointed. If you are waiting for BIM to reach perfection before adopting it you will be waiting forever. There will be improvements, but the perfection promised will never arrive, and the need for further changes will not evaporate. BIM is not an end in itself. It is a process of continuing improvement.

BIM is not  AN EXCUSE FOR SOCIAL ENGINEERING

There is a myth a particular type of contractual arrangement is required for BIM to work, so called Integrated Project Delivery. This is allied with a work arrangement being called "Project Team Integration". There is nothing wrong with Integrated Project Delivery, its aims of shared responsibility, risk and decision making is laudable. But just as you don't need to use BIM to achieve these aims (e.g. The National Museum of Australia used CAD), using BIM doesn't require IPD. The insistence that the construction industry must move to IPD type contracts and work arrangements for BIM is a naked attempt to use BIM as a driver to improve the way the way the industry works. This is great for bettering the AECO industry but detrimental to BIM adoption. BIM is not the only, and certainly not the most critical, driver in the selection of contractual arrangements. Making the assumption IPD is necessary for BIM leads to BIM not being considered for projects that require other contractual arrangements for reasons other than BIM.

BIM is not  RESTRICTED TO ALL IN ONE SOLUTIONS

There is an underlying assumption that a BIM model must become a single unified 'thing' ("Integrated Data Environment"), and that all BIM processes must be under the control of one entity. This view is promoted by the UK Levels of BIM Maturity (as per the Bew Richards diagram), where 'Level 3' BIM is an integrated web based solution (so called 'iBIM').

The only realistic way this can happen is if all participants use the same platform, or all rigorously comply to the same Standards, (assuming multiple platforms will be able to communicate via data that adheres to Standards). Whilst it is true greater efficiencies are theoretically possible by tight integration of all aspects of design, construction and operation, there are consequences of this approach that are being ignored. Forcing all participants use the same platform will lead to inefficiencies amongst individual parties. Each of us make choices about technologies and processes that are the most efficient at fulfilling our responsibilities. And because of competition the best available comes into common use. These individual actions add up to an efficient and cost effective overall

process. Any 'all in one' platform will never contain the best in breed across all disciplines. The result of  this approach will be the dominance of proprietary software monopolies, a situation all the software houses are currently scrambling to take advantage of.  The requirement for such tight integration will also encourage the ascendancy of large multi­ disciplinary firms and vertical integration into AECO conglomerates. Say good­bye to the bespoke architectural design firm, medium size contractors and specialist sub­contractors. The expectation that iBIM will be possible through the use of Standards is just a fantasy, more on that below. The whole idea of iBIM is analogous to a command economy. In theory a fully managed economy with centralized decision making should be more efficient. But in practice a market where individuals make the decisions is more efficient. Blatantly demonstrated when the USSR collapsed, and more recently the problems in Venezuela. BIM is a set of processes that manages certain technologies. There is no reason those processes can not be tailored to suit ways of working that maintain the efficiencies of a market approach. That is not to say iBIM is not a realistic prospect, nor that it will never happen. The problem is when it is assumed it will be the ONLY future for effective BIM.

BIM is not  A BUNCH OF STANDARDS

There is an enormous expectation that Standards will make BIM not just more efficient, but in the minds of many BIM will not be truly possible until Standards are in universal use. Now, I believe Standards are a good thing, which is why I follow their development so closely. But they are not the panacea they are portrayed to be. And the main reasons are inherent in how Standards are created. Standards take a long time to be developed and agreed. Most work on Standards around the world is done for free by volunteers. The process for approving Standards is also unpaid and requires many people, often from widely dispersed places, to come together. This is particularly pertinent for technology dependent processes like BIM where Standards trail current practice not by years but by decades. Because Standard creation and agreement is largely unrewarded the best and brightest, most experienced, are not attracted to participate. Although it does tends to attract academics, where their participation does bring reputational rewards. They may be the brightest, but lack practical experience and tend to create obtuse documents no­one else but fellow academics can comprehend. So Standards invariably document out of date practices in a manner that can not be understood by those who are supposed to follow them. I don't see how it will ever be possible to entirely rely on Standards and their adherence to deliver BIM. Processes and conventions developed by individual people, firms and project teams will always pay a major role in BIM. Just as proprietary software and formats will always be at the forefront of BIM technology.  Standards development should focus on supporting market driven BIM, not be put forward as BIM itself.

BIM is not  A WAY TO GET OTHERS TO DO YOUR WORK

BIM is often portrayed as a process where some­one will provide some­one else with a product that reduces that persons work. For example a facilities manager who receives a BIM model will gain a record of the constructed building that can be used to manage it. Whilst this is broadly true, this is interpreted to mean that the provider will do the work of the receiver. That if the facilities manager can't directly use the BIM model, use BIM data to populate their FM database, the provider has not done their job properly. This is propagated by the myth that a BIM model can be used for any purpose, even if created for a specific purpose. An architect creates a BIM model to communicate what is to be constructed, not to manage a built facility (in any case they wouldn't know how to ­ architects are not facility managers). And if a BIM model can be used for any purpose, there is no requirement to pay some­one to make it fit for particular purpose. So there is an expectation this work being done on the receiver's behalf is free. I can see no justification for this belief, yet is surprisingly common among owners. It is often a roadblock to BIM adoption. An owner wants BIM, but doesn't expect to pay for it. When a cost is put on it by the AECO participants BIM gets dropped in its entirety. The project becomes a 'non­BIM' project and BIM is actively discouraged.

So what is BIM?

BIM is  A CONCEPT

At its core BIM is a concept ­ the idea that the physical building, systems within it and processes used to realize it are modelled before a building is built. This sounds simple but is a paradigm shift from how most architects and engineers view their deliverables. The norm is to privilege drawings ­ that the firm's output are drawings. Of course their real output, and what everyone else expects, is information. Drawings merely communicate this information, they are nothing more than a tool. When training CAD users to use BIM software the biggest hurdle is to get them to understand that the drawing is not the most important aspect. To get them to stop obsessing over line weights and concentrate on ensuring wall definitions reflect what the wall is to be constructed from. Once people get it ­ that their job is to model, not to draw, everything becomes much easier. And if you don't understand this, you will never use BIM to its full potential.

BIM is  TECHNOLOGY

The degree BIM is possible is dependent on available technologies ­ software and hardware. When I first started using AutoCAD in the 1980's I got excited when I saw you could use layer names to describe what elements represented. Back then that was all we had available, but it was still a form of BIM. It is often said that BIM is process, not software. Whilst this is true BIM is process that manages softwares. Therefore BIM processes are limited to what software can do. It is pointless developing BIM processes and Standards that are independent of available technology. Pointless because no­one can use actually them, or are forced to invent elaborate and time consuming workarounds that mimic those impractical processes. BIM is in practical terms technology. Ignore this fact and you will soon paint yourself into a corner.

BIM is  PROCESSES

BIM is a set of processes that manages AECO technologies. Individual processes that can be linked to and linked from other processes. Processes that work in parallel, branch off and have different outcomes, a bit like they way a molecule is structured. BIM is not one single linear process that will only work if all parts are in use. Any part of the design, construction or operations of a building can use BIM. It doesn't have to be used all the time for every task. While it is true some processes aren't possible if other processes are not being used, it does not necessarily follow that one process justifies the implementation of all its precursor processes. Nor is the fact a particular BIM process is not being used reason enough to not use other BIM processes. BIM entails multiple processes, each of which should be justifiable for its own sake.

BIM is  OPPORTUNITY

The original intent of BIM was that by capturing work in a digital format it would be more useful to those that utilized the results of that work. It was never intended to mean that BIM is a new, additional task that produces the raw data required by others to do their work. That BIM data provided will be structured to suit the work

processes of others. The workflow envisage was that some­one provided their BIM model to some­one else, who then extracted and restructured the information they required. The provider remains responsible for their data ­ that it represents their area of expertise and deliverables, but they are not accountable for its use by others for purposes outside of their responsibilities. A services engineer provides a BIM model of ductwork to the contractor, which the contractor may use to create fabrication BIM. If there is an error in the fabrication model it is not the services engineer's responsibility, but if there is an error in the capacity sizing provided it is. If architects model a building in 3D, and the structural and services engineers do the same, then this provides sufficient information to use software to check for clashes. Providing someone with BIM data gives that person the opportunity to use it for their purposes. It may require validation and adjustment, but it is still usable and useful. What BIM does is provide an opportunity for improved efficiency and quality of outcome through the availability of data. And this is best done  through fostering cooperation and collaboration, not rigid demands, especially from those outside the immediate process. 

EVERYDAY BIM How might this approach be used everyday for real projects in the real world? Some general suggestions:

OWNERS: Restrict BIM demands to things you need directly (e.g. asset management), and to ensure general BIM proficiency (e.g within discipline expectations like drawing and schedules generated from BIM). Don't make BIM data a deliverable if you don't need it yourself, instead include engagement contract clauses that allow for the exchange of data between project participants.

DESIGN PROFESSIONALS: Use BIM capable software in the way it is designed to be used. Document how you structure your data and make both the description and data available to others.

CONTRACTORS: Take advantage of the BIM data available on a project. Foster BIM processes, along with cooperation and collaboration across project participants.

TRADES: Embody BIM processes in supply chain and work management. Tailor those processes to take advantage of available BIM data. Allow others to use the data you produce.

FACILITY MANAGEMENT: Develop FM solutions that take advantage of available BIM data. Become involved before facility handover so you can make your requirements known to others.

Notice I haven't mentioned Standards. That is not because Standards are never useful or don't have a place. It is because Standards should only be used if they are beneficial; if they assist in achieving the underlying aims. The decision to use Standards has to come from project participants, the ones who create and use BIM data, the only ones who can assess their usefulness.

I hope you find these general suggestions helpful, even if they are perhaps too brief to be

truly practical, something I will aim to ameliorate in future posts.

Posted by Antony McPhee at 13:14 

4 comments: 

+13   Recommend this on Google

Labels: BIM, Management, Standards

28 July 2015

Procuring BIM ­ PAS 1192­2 and acif PTI I feel sorry for owners and managers who need to make decisions about BIM on a project. The information available is vague; it is hard to extract practical advice that can be acted upon. And confusing, mixing up BIM issues with management practices that have nothing to do with BIM.

PAS 1192­2 I recently worked my way through the UK PAS 1192­2:2013. Full title: Specification for information management for the capital/delivery phase of construction projects using building information modelling. It is a "Publicly Available Specification", which are documents created for a sponsor by the British Standards Institution (BSI). In this case the sponsor was the UK Construction Industry Council (CIC). Not that the BSI do all the work. The PAS is done via consultation and a number organizations have been involved (24 are acknowledged). It was published in February 2013 and is 68 pages. Its audience "includes businesses and those responsible for the procurement, design, construction, delivery, operation and maintenance of buildings and infrastructure assets." What interested me is that PAS­1192­2 is an attempt to holistically capture BIM processes from beginning to end of a construction project. It is one of the few examples which tries to proscribe how to commence a BIM project, how to create a BIM brief.

acif BIM & PTI The other documents I recently slogged through were a series on BIM by the Australasian Construction Industry Forum (acif ­ they prefer lowercase), a peak body of peak bodies, including the likes of The Property Council, Engineers Australia, Master Builders, Facilities Management Association to name a few. The BIM documents are authored by the Strategic Forum for the Australasian Building and Construction Industry, a body within the acif that that "brings together key stakeholders".

Documents include: A Framework for the Adoption of Project Team Integration & BIM, published December 2014, acknowledges 11 participants, and is 60 pages. Building and Construction Procurement Guide: Project Team Integration and Building Information Modelling (BIM), published June 2015, acknowledges 8 participants, 56 pages. These documents essentially cover the same ground, with the later one containing marginally more specific 'advice'. The first "is designed to guide and assist industry stakeholders in the adoption and implementation of PTI and BIM." The later "is to provide asset owners and project procurers with an outline of potential procurement practices, processes and steps which might be followed in developing effective procurement strategies for implementation of Building Information Modelling (BIM) and Project Team Integration (PTI) on specific projects within the built environment." There are also two documents on Project Team Integration (PTI): The Case for Project Team Integration and Project Team Integration Workbook Despite their titles and self descriptions all of the acif documents are more BIM and IPT sales pitches than practical advice or structured workflows.

It is interesting to look at these documents side by side as the UK is heading for mandatory BIM, whereas Australia is, well, on its own. The current federal government doesn't believe anything needs to be done about global warming, so BIM is way too avant­garde for them to even comprehend, let alone mandate. But governments change, and what the acif is spruiking may end up in the form that PAS­ 1192­2 takes, or indeed the wholesale implementation of an unchanged PAS 1192­2. So how do they stack up?

AN EASY READ? In a word, no. PAS 1192­2 is acronym city. I had to spend a lot of time memorizing the myriad of abbreviations: BEP, TIDP,  MIDP, RM, PlM, PIP, SCCS, SMP, CPix, EIR, Capex, Opex, CDE gates, RACI, WIP, AIM, CDM,  and not only LOD but also LOI. Although PAS 1192­2 has a glossary, not every acronym is listed. It wasn't until page 13 that I found out what PAS stood for.

Terminology varies to a frustrating extent. You kind of expect some variances, particularly as PAS 1192­2 is from the UK, acif documents from Australia. But the authors seem to revel in creating their own unique terms. The Owner is called "Employer" in PAS 1192­2, "Project Sponsor" in acif documents. acif have invented a new term for Integrated Project Delivery (IPD) ­ "Project Team Integration" (PTI). They explain that PTI is a more generic term, IPD being a form of contract rather than a description. I don't see it. IPD is already a term in use in Australia, and perfectly adequate. Why invent a new one? PAS 1192­2 is a document you study ­ take notes, reread sections, draw your own diagrams, google a lot (to find out what the acronyms mean). Just reading it will leave you confused and be of no practical benefit. A lot of thought has gone in to it, but golly, does BIM have to be this complicated? The acif documents are easier to read ­ if you can stay awake. The same things are constantly repeated, not just within documents, also across documents. There is really no point reading the Framework document, the same information is repeated in the Building and Construction Procurement Guide. But to be fair all documents of these types are tedious to read. Both sets of documents are extremely well structured, have good contents pages, glossaries and definitions. And unfortunately repeating information is de rigueur for these types of reference documents.

REALISTIC WORKFLOWS, OBJECTIVES? PAS 1192­2 describes workflows, the acif documents really describes objectives, and now and again, if you know what to look for, actions to achieve objectives. Generally both have a good grasp of BIM, with inklings of evidence there are at least some people involved with direct experience. But there are some areas that I believe push the bounds of practicality. 

PRE­TENDER BIM PLAN The requirement for a pre­tender BIM plan in PAS 1192­2 is unrealistic. I don't see how this is even possible unless the tender process is severely limited to only seeking bids from consortiums. A BIM plan needs all parties to get together to agree on a plan. How can this be done at tender or RFT stage when multiple parties are bidding for the same work? If it is enforced it sets up an environment where collusion could run rife. All those tenders getting together and just discussing BIM? Unless, that is, PAS 1192­2 really means something other than a traditional BIM plan. I searched for this possibility but could find nothing that suggested otherwise. But I smell a rat. Although PAS 1192­2 explicitly states it is suitable for all contract types the underlying assumption that comes through is that only IPD (Integrated Project Delivery), Alliance and other combined risk contracts are suitable for BIM. This assumption is also explicit in the acif documents. Their introduction of a new acronym ­ IPT, (Integrated Project Team), and the time spent extolling its virtues belie their underlying intent. More on that below.   

GATEWAYS OR BLOCKAGES PAS 1192­2 includes "Gateways", where BIM data is approved before the data is released for use by others. This is not a new invention brought about by BIM, many QA processes already contain such procedures. Hold and review points are good in theory, but if not structured and managed carefully can end up being blockage points instead. In my experience the reality does not always match the intent: Adding review points should extend the program, but this never seems to happen (what owner volunteers to extend the completion date for the sake of a technology?). Instead work programs are condensed to unrealistic levels to the point that work continues into the review period, leading to poor work and inadequate checking. Owners, or more usually the poor sods they appoint to oversee all this checking, don't want to take any additional responsibility (nor workload) so refuse to, or drag their feet in officially signing off on anything. So work continues on, as it has to, using unapproved deliverables. Your boss sees checking as a non­productive use of time, so if some­one else is

doing it why are you doing it? Leading to unchecked documents leaving the office.  Any review point is an opportunity for designers to "tweak" the design, leading to rushed reworking.  These problems can be addressed, but PAS 1192 seems ambitious when it comes to sign off at Gateways (which it admits may be difficult for "some contracts").  The problem in PAS 1192­2 is sign off is assumed to mean a shift of responsibility from author to approver. Any mistakes become the fault of the checker for not picking them up. Which means the checker must have expertise in the area they are checking. So an owner needs to appoint a second architect to check the primary architect's work, structural engineer, services engineer etc. Not very efficient. There is a trade off between mistake free documents and project progression. To ensure comprehensive and mistake free documents takes considerable time at each check point. A more practical approach would be to check only for completeness, the professional risk still being carried by the author.   

VOLUMES PAS 1192­2 has a concept it calls "Volumes". The idea is that the project is broken up in to a number of volumes (3D spaces) that are allocated to different project team members. The example of a rail tunnel is illustrated with linear volumes for different services.

This may work for simple infrastructure but I don't see how it works on a even moderately complex building. Different services often share the same space (e.g. ceiling space). Allocating specific space for different purposes is possible, but is generally not the most efficient way to design a building. Further "all members of the design team shall agree volumes as fully as possible at the start of the project". How can you do this before designing the building? The allocation of space is a huge part of design, most of what an architect does. Does PAS 1192­2 assume the architect's work is complete before BIM is started? It wouldn't surprise me. There is a pervasive belief that BIM only starts once a contractor gets involved. Part of the absurd push for IPD (aka PTI): that BIM is only possible if the contractor is involved during design. How about the acif documents? These documents are mostly 'motherhood' statements with a sprinkling of useful advice. For example on page 31 of the Framework document out of 15 objectives; 3 are general statements ("the dismantling of traditional barriers or silos of effort") 3 are not relevant to a project but to the industry as a whole ("further development of national  templates, content and Standards") 2 are repeats of issues already stated.

So just over half are not useful. One wonders why they didn't have two lists of objectives, one for industry and one for practitioners. Recommendations made years ago reappear, like "undertaking pilot projects to display the benefits of BIM." Not more pilot projects! How many more BIM events must we sit through where all you get are syrupy presentations of (apparently) extraordinarily successful BIM projects. And there are contradictions. Under Asset Management "Proposed Activities to deliver on Objective" one 'activity' suggests another is not possible. How can: "A contractual obligation (clause) binding on all parties from initiation of a built project for the development, transfer and maintenance of an asset register across the asset life cycle." be achieved until: "The asset/facilities management industry must define data sets and information asset register outcome requirements to enable the transition from design and construction to operation in a BIM environment." It is a classic chicken and egg situation. How can AEC team members provide something that is undefined?

THE COST There is quite a bit of extra work for owners ("Employers") in PAS 1192­2. From being responsible for proscribing the entire BIM process to checking it has been complied with. To follow PAS 1192­2 owners will have to beef up their project management teams, not just in training and expertise, but in bodies on the ground to do the additional work. PAS 1192 also introduces a raft of extra requirements for tenders. Although the owner may not directly pay each tenderers for the additional work, the industry as a whole will need to recoup those added costs. COBie deliverables and assignation of Uniclass classification codes are mandatory, even though there may be no­one using these on the project. Why provide COBie if an FM solution is part of the construction contract and data can be placed directly into the chosen FM system? Sure, preference COBie and Uniclass coding where FM data and cost coding are required, but only if team members have no viable alternative. As I have written in earlier posts, both of these imposts create additional work. Work that needs to be paid for, whether directly paid for by the owner or as a cost to the industry as a whole. Sure BIM may bring savings elsewhere, but strict compliance to PAS 1992­2 will be an additional cost. Therefore be wary of statements like "must comply with PAS 1192­2". Owners making statements like this are adding possibly unnecessary costs to their projects, others with it in their contracts need to make sure they have allowed for the extra work in their bids. The acif documents are not proscriptive enough to identify where there might be additional costs. As they are primarily about introducing BIM the most obvious cost is in education and training. Although the implicit assumption throughout their documents that owners must take a bigger role in BIM is a potential additional cost for owners.

DOES BIM DRIVE THE FORM OF CONTRACT? Building contracts are structured to achieve many outcomes, and attempt to create agreement on many issues, BIM is only one, and is by no means the most important. Yet both PAS 1192­2 and the acif documents assume that BIM processes can only be achieved under one contractual arrangement. Interestingly both PAS 1192­2 and the acif documents specifically state that they are contract neutral, acif documents even warning that owners ("Project Sponsors"): "... need to be careful that changing contractual arrangements for BIM doesn't lead to a degradation of other aspects ­ like design, innovative construction, innovative engineering solutions." But when you read the documents as a whole it becomes obvious the only way the

requirements (PAS 1192­2) and objectives (acif documents) can be met is with an IPD type contract. In the acif framework document there is a good description of different contract types, including existing "traditional" contracts. Then there is a table comparing contract types with their effect on BIM Implementation. Except they lumped all existing contract types together and compared them to alliancing ("partnering") and consortium ("financing") contracts. What would have been far more interesting, and actually useful, would be to compare BIM implementation between each of the existing contract types (Construct, D&C, Managed Contract, Construction Management etc.). l don't understand where this idea comes from that only certain types of contracts are suitable for BIM.  Any contract type can use BIM. The truth is (as mentioned, but contradicted elsewhere in acif documents) the form of BIM is set by the type of contract, not the other way round.

BIM AS SOCIAL ENGINEERING As mentioned PTI (Project Team Integration) is a substantial part of the acif documents. There is talk of  PTI Protocols but I couldn't find anywhere that lists or describes what these protocols are. There is a list of their purpose, and why they are important but not what they are. Are they talking about specific existing protocols, future protocols, a protocol, or a series of protocols? I got excited when I found the acif Project Team Integration Workbook. A workbook, something practical, something that should tell me what PTI is. Sadly I was mistaken. It is a series of 18 tables of generic project management topics, like "Environment and Culture", "Project Leadership", "Wasted Effort". Each is divided into 5 colour coded columns, red is bad, blue is exemplary.

You guessed it, existing contract types only appear in the red column, PTI type contracts dominates the blue. Amazing, doing PTI (whatever that entails) will miraculously make everyone a better manager! Choose PTI and your project goes from    "This is the worst project I've ever worked on in 30 years"  to        "This is the best project I've ever worked on." from   "We're at war. The client's the enemy" to       "We have the greatest respect and admiration for our client. He leads without interfering." Hallelujah, praise to the god of BIM. All management sins will be washed away by accepting the wisdom of PTI.

WHAT IS THIS PTI? In the acif Framework document section headed "Agreed definition of PTI and BIM" it states: "PTI is a process to facilitate integration and encourage collaborative behavior ..." But what is this process? It also states:

"PTI is a project delivery approach that encourages clients to engage a team (including design consultants and building contractors) at the earliest stages of a project to enhance the level  of integration between them." OK, the team gets together early. But what explicitly do they do that is different, to make it PTI instead of business as usual? Besides more motherhood statements like "reduce waste" and "optimise project outcomes" there is nothing about what specific procedures constitutes a "process". The give away is the word "collaborative". This is nothing more than another version of the "we must collaborate" myth I have written about in other posts. I do not know, and have been searching for, what I should be doing beyond what I, and the people I work with, already do to achieve this "collaboration". The only logical thing I can get a firm grip on is the idea that we should be providing additional information for others to use, which I call for what it is, exploitation, not collaboration. But I don't believe that is what is behind the acif documents. I think they are under the impression they can foster a revolution in the quality of construction project management through the adoption of BIM. My suspicions were reinforced when I read the acknowledgements in the acif PTI Workbook document. There are no practitioners of BIM mentioned, and it is based on a 2001 publication by two academics:  "Projects as Wealth Creators". I'm sure their ideas for better project management are fantastic and worth adopting, but they are trying to hijack BIM to push for unrelated issues. Using a new technology to justify a call for social change, otherwise known as social engineering. BIM is not going to change the way people behave. An owner who tries to squeeze everyone's prices and goad them into extra work is still going to do that. This is already happening with BIM in the attempts by owners to get the AEC team to provide FM data in a format of their choosing at no additional cost. And it simply won't work. No manager thinks what they do is poor practice. When they read something like BIM requires "a well informed client who knows what they want" they never think it applies to them. Statements like that achieve nothing. What should be explained is that anyone can utilize BIM, it is just that better managers will reap better rewards. That those who are open to adjusting their management style will benefit more than those that don't. To say to a manager you must throw out how you have done things in the past to use BIM is not only untrue, but counterproductive.

SUMMARY To summarize my main criticisms:

PAS 1192­2 EMPLOYER (Owner) ­Assumes all is known about the project before it starts. ­Expects employer to define how professionals conduct their business. ­Expects employer to have expertise to check and approve professionals work. PROCESS ­Assumes design team all engaged at same time. ­Assumes RFT from consortium ­ how else does a "pre­contract BEP" get done? ­Assumes IPD type contracts (even though says it doesn't). ­Assumes building has been designed (e.g. expectation of "volume" definitions) DELIVERABLES ­Insists Uniclass codes allocated to BIM objects even if not used by the project team. ­Insists on COBie even when there may be no reason to use COBie

acif DOCUMENTS ­Doesn't explore how BIM can be used on existing contracts. ­Mixes project specific objectives with industry wide objectives. ­Many objectives are not actionable. ­No decisive description of PTI protocols. ­Inconsistent: advice is often contradicted by other parts of the document. 

CONCLUSION You may, by now, have noticed this post is not a precis of the documents reviewed, but a critical review that carefully avoids spoilers (sorry, you are going to have to read them yourself). But having read them I believe both PAS 1192­2 and the acif documents are worthwhile additions to BIM literature. My criticisms are born of a frustration, that they are so close but miss the mark. My belief is that there is enough knowledge out there to create useful, practical BIM guides. The reasons why this rarely happens lie elsewhere. You can literally see the tussle between the BIM practitioners and BIM evangelists as you read the acif BIM & PTI documents. A good edit cleaning out the myths and rearranging the truths would do wonders for these documents.  I believe all PAS 1192­2 needs some time in the real world getting practical experience to see what works and what doesn't. Some parts probably need to be watered down but the underlying logic and workflows are sound.  So my advice is to make use of PAS 1192­2; for guidance on setting up a BIM procurement process, and the acif documents; for an overview of possible BIM procurement methods, with some gems of  practical advice. Just don't ever mandate that PAS 1192­2 'shall' be followed, and approach the acif documents with a dose of skepticism, mine it for the gems and leave the tailings behind.

Posted by Antony McPhee at 16:14 

5 comments: 

+21   Recommend this on Google

Labels: Management, Standards

26 June 2015

Classification ­ not so Easy I have written about adding classification numbers to Revit before. Back then I thought it good practice to include them, even if you didn't have a specific need for them. That was before I did some digging and found it is not as simple as it sounds. Before you get bored and go back to looking at kittens on YouTube or BIMporn, I appreciate you are probably not interested in classification systems. I certainly am not. So I'll put the practical  information first, then at least you might know something useful before your eyes start glazing over.

HOW TO DEAL WITH CLASSIFICATION QUESTION THE NECESSITY FOR CLASSIFICATION Classification codes (see here for a description) are promoted by some as a panacea for all BIM uses. The truth is they are mostly used for costing and specifications. They are not that useful for Facilities Management as a classification code might tell you a thing is a door, but it doesn't tell you where the door is. If you do estimating and will use classification codes (they are not the only method to identify components) then yes, they are necessary. If you use them for specification purposes then they are also necessary, although again, they are not the only, or even most common, way of managing specifications. If you don't do estimating and are requested to include classification codes in your models ask why. Are you doing it so the cost consultant or contractor doesn't have to? If so why are you doing it and not them? Who will pay you to do their work?

If there is no specific reason, if it is explained as "necessary for BIM", or simply "good practice", put a price on it and see if it is still a requirement. Or pose a series of questions about the specifics of what it is they require (read to the bottom of this post for ammunition). As a last resort, if they still insist, be comforted in the fact that they have no idea what they will be receiving, will never use it, and will never know if you have done it properly or not (whatever "properly" means).

DEFINE YOUR SCOPE If you can't get out of providing classification codes, and you have no clear direction on what is expected, you need to define what you will deliver. 1.  Which classification system will be used. If you are in the USA or UK the answer will be obvious, possibly even mandated. In other countries (like Australia and many Asia­pacific countries) it may not be so obvious. If it is not clear use whichever one is easiest for you to access and use. 2.  Which version will be used. Classification systems are pretty much constantly under review, and every now and again a new version is released. As there are legacy work practices and softwares that rely on old versions these old versions tend to still be in use well after a new version is released. Also draft versions exist for years and may be used on real projects as they are the only option available (as Autodesk did ­ see below).  Keep in mind whoever you are providing classification codes to may not necessary require the latest version, or may require you to use a draft version. You could offer to provide the version most convenient for you to accomplish, which is not necessarily the latest (more on that below). However if whoever you are providing it to has not stated what they require you may have trouble arguing that an old version is 'fit for purpose'. Best practice is to ask which version is required. If that is not possible explicitly state which version you will provide. 3.  Which tables will be used. Omniclass has 15 tables, Uniclass2015 has 11, you don't want to commit to providing relevant codes from every table to all objects. Offer to provide codes from one table: Omniclass Table 21 ­ Elements, or Uniclass2015 Table  Ss ­ Systems. 4.  Number of Codes per object. Classification tables describe different things that might apply to the same object. Also our BIM objects often contain multiple things that might attract a classification code (e.g. a door has many components ­ locks, handles, closers, hinges etc). Restrict your offer to a single code per object, that is, a single classification parameter per object. 5.  Depth of Codes. Omniclass Table 23 is 7 levels deep, Uniclass2015 Table Ss is 4 levels deep. The deeper the level the more specific the information. The more specific the information the more objects required in your model. If you provide codes down to the level of door locks, you will need an object for each lock to hold the code (as opposed to a door parameter that describes the type of lock). Only offer to provide codes to the first level of the classification system.

Now, all this sounds complicated, but can be captured in one sentence:

Omniclass: We [normally/can/may/offer to/will] provide a single classification code to each appropriate object in our models conforming to Omniformat 2012, Table 21 ­ Elements, to a level of detail equal to Level 2.

Uniclass: We [normally/can/may/offer to/will] provide a single classification code to each appropriate object in our models conforming to Uniclass2015, table Ss ­ Systems, to a level of detail equal to Sub­group. You can of course provide more than this, that is your commercial decision. My recommendations are a base line, a minimum that is reasonable. The point is to place a value on providing classification codes for others to make use of. Classification data entry takes time and effort and should be paid for.

WORK OUT HOW YOU ARE GOING TO DO IT Before embarking on the task of assigning classifications, including pre­populating component families, establish the methods you will use. Poor choices and decisions can turn the task into a job that eats up hundreds of man hours. Don't assume anything. Test every step, and verify every result. In particular make sure you are aware of the abilities and limitations of the software you intend to use. I've only investigated Revit (which I will go into more detail below). Amongst other things I found that: The default Omniclass Table 23 ­ Products data in Revit is WRONG (kind of, see below). The default Omniclass Table 21 ­ Elements data in Revit is OUT OF DATE This doesn't mean you can't, or shouldn't, use Revit. These issues can be resolved. But only if you know about them. Software vendors never take responsibility for the results their software produces (read any T & Cs), so don't trust files provided by vendors containing data you are responsible for. Check they are correct.

THE BORING DETAILS If you really don't care about classification systems you can stop reading now. Perhaps come back when your client or boss requires you to become a data entry operator plugging in classification codes.

WHAT ARE CLASSIFICATION SYSTEMS? By classification systems I mean Omniclass from the USA, and Uniclass from the UK. There are other non­english classification systems which I am not familiar with, nor ever hope to be. There are also various standards, but I'm not going to go there either. Classification systems are hierarchical numbering systems (although some contain letters) that attempt to provide a unique number for everything that needs to be described in the building process. An example from Omniclass Table 21 ­ Elements: 21­03 10 30       Interior Doors 21­03 10 30 10  Interior Swinging Doors 21­03 10 30 20  Interior Entrance Doors 21­03 10 30 30  Interior Sliding Doors An example from Uniclass2015 Table Ss ­ Systems: Ss 25 30            Door and window systems Ss 25 30 20       Door, shutter and hatch systems Ss 25 30 20 16  Collapsible gate and grille doorset systems Ss 25 30 20 25  Doorset systems Ss 25 30 20 30  Frame and door leaf systems Ss 25 30 20 32  Frameless glass door systems

Both systems are made up of a number of tables. Uniclass has 15, although Uniclass2015 has 11 (maybe 10 now ­ see below). I counted 15 in Omniclass but the last one is numbered 49. I don't know if this is because there are yet to be release tables, existing tables have been deleted or the numbers are just not sequential.

Some tables come from pre­existing classification systems, Omniclass Table 21 from Uniformat, Omniclass Table 22 from MasterFormat. Oh, and there are two Uniformats, plain old Uniformat and Uniformat II. And there is Uniclass, Uniclass2 and Uniclass2015. Uniclass is the original developed before BIM, Uniclass2 was going to be the new version with better integration between tables. That partially complete system has now been re­branded as Uniformat2015 by the UK NBS who are working on it as part of their government contract to create a "BIM Toolkit". Which classification system is best? Who knows (or cares). If an article from the UK NBS: Omniclass: a critique is anything to go by Uniclass2 is better structured for BIM than Omniclass. Except Uniclass2015 (remember, Uniclass2 is now called Uniclass2015) is incomplete, only four tables are available (I hesitate to say 'published', they are still draft), so may or may not be usable, depending whether the bit you need is sufficiently complete to be useful. It seems that most tables grew from cost estimating requirements, with the exception of the Work Result tables which seem to come from specifications systems. Omniclass Table 22 is based on MasterFormat, and Uniclass Table  J (Table WR in Uniclass2) is based on CAWS (Common Arrangement of Work Sections for building works) classification. Except that Uniclass2015 Table WR has now been withdrawn. Apparently is is redundant as "it has become clear that this table is confusing (why have objects got two near­identical codes?), redundant (objects only need one code) and unnecessarily restrictive on the other tables (the number of levels was limited in every case)." I suppose they know what they are doing.

WHO USES CLASSIFICATION CODES? As mentioned above historically classification codes have been used for cost estimating and specification writing. Sometimes they are used for classifying product libraries, or naming systems in CAD and BIM software. Attempts at the latter are rarely successful. Not many people know that 21­03 10 30 means interior door, but every knows what "Door­Interior" means. I have seen the sad remnants of misguided attempts to introduce naming based on opaque classification codes in a number of architectural offices. So it is the cost estimators who mainly use classification codes, working for the owner, the contractor; or as a consultant to owners, design professionals, or contractors. Classification codes may possibly be used for specifications but they are the providence of design professionals, there is no need to pass that information on to others within a BIM model. Classification codes are hardly information that is required by all participants within the AECO work chain.

ARE CLASSIFICATION SYSTEMS NECESSARY FOR BIM? When computers started to be used it was found classification codes and their tables were not as logical as everyone assumed, hence all this reworking and new versions. But there seems to have been a knee jerk reaction that classification systems are necessary, even critical, for BIM to work. I don't see it. BIM software brings its own structuring of data that can be utilized for costing and specifications. I don't see that it is absolutely necessary to add another layer of information that duplicates existing data. Particularly when existing classification systems do not provide enough coverage. The Uniformat codes produced for Autodesk (see below) have an extra 3 levels of numbers. Presumably because Uniformat did not have enough codes to cover all the things that Revit can model. And where does IFC fit into all this? IFC is a 'schema', it not only identifies objects but also locates them in relation to other objects. So IFC not only knows something is a door, it knows which wall it is in, which rooms are around it, which lock it has. Which raises the question of why have IFC and classification? Or why can't classification codes be built into IFC? Match IFC attributes to classification codes within IFC software so

users don't have to manually enter them. Of course it is not that simple, or more precisely, practical. Whilst Uniclass2015 has a whole lot of codes for door hardware, there are no definitions for door hardware in IFC. Both are incomplete, but in different ways. And the logical structure is different. Classification system grew from a system designed for humans to use, IFC is for software to use. Is the effort to make them align worth it, will it produce a practical result? Something that will actually achieve useful outcomes in the real world? I'm not advocating that classification systems be abandoned altogether. It is just that they are 'nice to have' rather than a necessity. Don't be fooled into thinking they are critical part of BIM.

ADDING CLASSIFICATION CODES Apparently it is really simple. You just add the appropriate classification code to parameters attached to objects in your BIM model. To put this in perspective, the appropriate code from a choice of 6,905 codes in Omniclass Table 23;  a choice of 6,470 in Uniclass2015 Table Pr. Added to parameters in each of the thousands of objects in a typical BIM model. But, I hear you say, we use BIM, the software will do it for us. Yes and no. I'll restrict my discussion to Revit, because that is what I use. And because I couldn't be bothered re­spending the time I wasted discovering how things don't work in Revit on other softwares. Revit has two built in places for classification values, and a third that can be re­purposed to do it. The fourth way is to manually create custom parameters. Each family file (components like doors, furniture, etc) has a file based parameter called Omniclass Number. This is for Omniclass Table 23 ­ Products. When this parameter is selected Revit provides a dialogue box where you can select the appropriate code from a drop down list that can be sorted by Revit category. So if you are in a Door family only codes appropriate to Doors are offered for selection. Revit also fills in the Omniclass Title parameter automatically. Nice. All types of objects also have a parameter called Assembly Code. This is not file based so categories that don't exist as separate files, like walls, floors, ceilings, roofs have this parameter. It works the same way as the Omniclass parameters, the user is offered a selection from Omniclass Table 21 ­ Elements that only applies to the category of the object. Revit automatically fills in the Assembly Description parameter. The third way is to use the Keynote parameter. All types of objects have this parameter. When Keynote is selected a user defined tab delimited text file is read that lists the code opposite its title. The user selects from the list. Some organisations have created Keynote files for use with their classification systems. In Australia NatSpec has done so for their specification codes (get it here). Note that the one that comes with out of the box Revit in Australia is not the latest version.

The Omniclass Number and Assembly Code values also come from tab delimited text files (although formatted differently). Omniclass Number values are in OmniClassTaxonomy.txt. This file is located in bowels of windows on each users local computer at %APPDATA%\Autodesk\Revit\. Assembly Code values are in a file called UniformatClassifications.txt. A copy can also be found in the bowels of windows, but you can change the path to this file, and even path to a different file. The command to do this can be found under the Manage tab > Additional Settings > Assembly Code. In this command there are a number of ways the definition file can be pathed, one of which is relative the Library set in Options. It seems AutoDesk assume Assembly Code values may be associated with particular component libraries. The path and file to the Assembly Code definition file is set in each file. So individual projects, and individual family (component) files, can be linked to different Assembly Code definitions.

The automatic assigning of Assembly Description (and Omniclass Title) only happens if the correct files are associated with the file you are in. Revit also provides a keynote file based on Omniclass Table 22 ­ Work Results (aka Masterformat). Because Revit uses separate text files it is possible to replace those files with different ones; a different classification version, or completely different classification system. As long as the files are formatted correctly. Which is sort of great. Except to replace OmniClassTaxonomy.txt you need to replace it for every user on every individual computer. And it will then apply to ALL projects and family files used by that user on that computer. It is an office wide change, not an individual project change. And you will need to do it every time there is a new version of Revit. You can't change the filename either, it has to be OmniClassTaxonomy.txt, which makes it hard to identify what the file contains. UniformatClassifications.txt is a little easier. As described above you can change the path and filename via a menu command. Although it is a bit tedious if you want to associate a different definition file to family (component) files, as you have to open, make the change, and then save every individual family file.

ALTERNATIVE CLASSIFICATION FILES Why would you need to change the files? Obviously if you need to use Uniclass (more on that below), but also if you intend to use Omniclass.

OMNICLASS As mentioned above the default files that come with out of the box Revit are not correct. The default OmniClassTaxonomy.txt is based on a 2006 draft version of  Omniclass Table 23 ­ Products. There are valid historical reasons for this, Autodesk are not being belligerent. They introduced Omniclass for families files so they could use it to classify them in their web based component library AutoDesk Seek. It was never their intention to support Omniclass for general users. A newer version based on Omniclass 2012 is available from Autodesk at Update OmniClass Taxonomy File. However the new file doesn't associate Omniclass values with Revit categories. I'm not sure why, there is no technical reason it couldn't. I'm also not sure why Revit 2016 still ships with the draft version of Omniclass. If you use the Omniclass Number parameter it is important you make a decision, because Omniclass values for the 2006 draft are DIFFERENT from Omniclass 2012. Default Omniclass ­Interior Doors:  23.30.10.00 Omniclass 2012    ­Interior Doors:  23.15.11.15

The default UniformatClassifications.txt file is a modified version of Uniformat II. It was created for Autodesk by RSMeans, a USA costing data provider. They modified it by adding up to an extra 3 levels for a maximum depth of 7 levels, whereas Uniformat has a maximum of 4 levels. Autodesk now also provide with out of the box Revit the UniformatClassifications_2010.txt file. This is an updated version of Uniformat. Again, there are differences in the numbering between the two versions: UniformatClassification.txt           ­ Interior Doors:      C1020 UniformatClassification_2010.txt ­ Interior Doors:      C1030 You could also make your own OmniClassTaxonomy.txt or Assembly Number definition file from publicly available excel files of Omniclass tables. Although you will have to reverse engineer the file structure from Revit's files.

UNICLASS I couldn't find any Uniclass equivalents of  OmniClassTaxonomy.txt  or  UniformatClassifications.txt. I did find some people who have created their own, so it is possible, although you will have to reverse engineer the file structure.

Some Uniclass 2015 tables are available as excel files from the NBS BIM Toolkit site (scroll to the bottom of the article). But there is a deeper problem. Uniclass 2015 is not complete, it is still being developed. Admittedly the tables you are most likely to use, Ss ­ Systems and Pr ­ Products are more developed than some other tables. But no­one will guarantee they won't change. In fact the downloadable excel files have a suffix of 'latest'. Doesn't exactly instil confidence. I wonder if they don't finish this year they will still call it Uniclass2015.

CONCLUSION Classification systems are probably useful, to certain people in certain circumstances. But they are not a requirement for BIM to work. Although my comments about the lack of completeness may have come across as captious, my view is that it is always worthwhile making improvements. The process is disruptive but if we don't constantly strive to improve we will be stuck with impractical systems. Imagine having to use the Roman numbering system! I encourage those working on updating classification systems to continue their good work. But there appears to be quite a way to go. Not only do we need the the classification systems to be BIM friendly, complete and stable, they need to be available in a consistent and durable way so that software houses can access them for integration into their softwares. To be honest, I don't see how anyone can take them seriously until this happens. The journey I had to take just to identify which codes I should apply to our in­house component library has been ridiculous. Time in my life I'll never get back.

If you have managed to get down to here, well done. You now know a bit more about classification systems. Not everything mind you, there are even more boring things you could be abreast of. And of course everything I have explained may not be 100% correct. If you see anything wrong, or misinformed, please comment. I'm quite happy to be proved wrong, but don't expect me to care.

Posted by Antony McPhee at 13:46 

1 comment: 

Recommend this on Google

Labels: Management, Standards

Home

Older Posts

Subscribe to: Posts (Atom)

Awesome Inc. template. Template images by moorsky. Powered by Blogger.