What does BIM mean to you?

There has been so much written about what BIM means I hesitate to add any more. Yet there still seems to be an enormous amount of variation about what it means to different people.
People may argue there is already a clear definition of BIM, but the reality is everyone has a different version of that definition defined by their own area of expertise.
Let's start with Wikipedia's definition:

"Building information modeling (BIM) is a process involving the generation and management of digital representations of physical and functional characteristics of a facility. The resulting building information models become shared knowledge resources to support decision-making about a facility from earliest conceptual stages, through design and construction, through its operational life and eventual demolition."

Sounds pretty good. A broad, all inclusive description, it includes the 5 'stages' of a facility's life.
But in deeper discussion about actually doing BIM I'm finding the people involved in those 5 stages have differing views on what is important in BIM implementation, and hence their practical view of what BIM means.
Those involved in operations (FM) believe IFC is quite adequate for BIM and don't realise IFC's inability to capture intelligence makes it useless during design. Those involved in design don't appreciate that creating lists and schedules separate from the BIM file adds to the work load of those involved in construction and operations (FM).

There are also some technical confusions in definitions of BIM. One is the myth of the single shared Model. Technically implementation of BIM doesn't require this. Information about a facility can come from multiple models. Yet the Wikipedia description falls into this trap:

"... BIM enables a virtual information model to be handed from the design team to the main contractor and subcontractors and then on to the owner/operator; each professional adds discipline-specific data to the single shared model."

Another is that BIM is only about information. The American Institute of Architects has defined BIM as "a model-based technology linked with a database of project information". But truly BIM software is capable of more than just information, it also has intelligence. It knows a wall is connected to a floor and ceiling, so maintains that relationship even when that floor or ceiling moves. It knows what duct, dampers and AHU unit an A/C register is connected to.

A third area of confusion is defining BIM as the work processes that are possible, or at least easier, to implement when using BIM. The classic is Integrated Project Delivery (IPD), pushed by many as the 'only' contractual arrangement where BIM can be 'truly' utilized. Yet IPD does not require BIM. In the late 1990's I was involved with a project in Australia done under an 'Alliance' contract, effectively IPD. That project was done entirely with CAD. No-one even mentioned BIM as a possibility, let alone a necessity.


So the way BIM is being defined is either too broad, trying to include the many players in BIM; or too specific, including technical descriptions that don't hold in all situations; or about something completely different, that doesn't actually require BIM at all.


So where is the term BIM come from? What did it originally mean?
I won't repeat what has been covered elsewhere, a good reference on the description and history of BIM is at the Architecture Research Lab.
But I have always thought BIM meant the use of the power of computers to hold information, as opposed to  traditional practice where it is held in various people's heads and scraps of paper (called 'drawings').
I used a similar term back in 1998 to describe a method of using CAD to hold information about a building, Using CAD to Model Buildings. I  called this a CAD Information Model (CIM). Utilising standard CAD meant it was very limited, and being for architects and not computer programmers not very sophisticated. It has only quaint historical interest now, but I still maintain that the base thing we are trying to achieve, before any of the other things, is to use computers to manage and maintain information about a building. The only thing I would add is that BIM also includes the managing of relationships between information, the intelligence I spoke of earlier.

So what does BIM mean to me?
I am reluctant to add yet another definition, but to be fair to my readers I feel I should make a clear statement about what I mean. Here goes:

Building information modeling (BIM) describes the use of digital technologies to create a virtual representation of the information and relationships required to undertake the conception, design, construction and operation of a built facility.

I would further contend that the term BIM only be used for what BIM stands for; Building Information Modelling. NOT integrated project delivery; NOT facility management data storage; NOT life cycle design; NOT work processes; and NOT a single repository for all information about a building.

I believe these are all valid and worthwhile purposes, but let's give them their own terms and acronyms.
Let's keep the meaning of BIM simple and to the point, and stop the confusion.

Where's the contractor? BIM Execution Plan for contractors

To be effective BIM needs to be used right from when a project starts. There are already enormous benefits in using BIM during brief consolidation and master planning. Therefore BIM plans need to start at the very beginning so that work done early on can be utilised later. But current BIM guides assume the contractor is a major party in a BIM plan. Why do these BIM guides assume a contractor is on board right from early conception of a project?

Integrated Project Delivery (IPD) is an attempt to get all the players in a construction project together from the beginning of a project. The theory being, if you can do this, BIM processes for the entire project can be worked out in advance.
IPD assumes enough is known about a project at the beginning to do this. That at the briefing stage, before there is a design, enough will be known to select the best and most cost efficient contractor.
It also assumes the owner is willing to pay for participants that won't be needed on the project (besides this BIM 'pre-planning') for months or years into the future. That's if the project actually proceeds to construction - which many do not.

There is a fundamental flaw in this thinking. The Contractor is rarely around at the beginning of a project.
Yet current BIM guides assume they will be.
I've been in a situation like this. We were meeting to put together the project BIM Execution plan, there was no contractor, yet there were clearly contractor driven BIM processes to be included in the document. The client's BIM 'consultant' wanted to use their take on BIM best practice, even though no contractor had actually done any of it to date. Which would mean the design team would be doing a whole lot of stuff no-one would ever use. When we complained the client wanted us, as lead consultant, to determine what the builder would do, what is 'reasonable' as they put it.
As an architect, I don't pretend to know what goes on in the head of a contractor. We try and detail construction in a way that is buildable, but we can't predict what a contractor will actually do. When we cleverly detail a façade so scaffolding is not necessary, they scaffold it anyway. When we design so components can be prefabricated off site, they make them on site. And this is as it should be. They are the experts at construction. There is no way we could predict what BIM an unknown contractor might require.
So the only alternative is to leave contractor requirements blank until one is appointed. The problem with this is all requirements are integrated in a single BIM plan. When you add things in later it is misleading. For example, 4D (construction sequencing) is left blank. A contractor is appointed and wants to use 4D, so the blank is filled in. Now the BIM plan reads as though 4D has always been a requirement, but of course no-one has modelled to suit 4D. You can't add requirements after the fact.
Which brings us back to IPD.
IPD is being heavily pushed as necessary for BIM because BIM plans (based on current BIM guides) only work if IPD is used as a delivery process.
Do we really have to completely re-engineer procurement processes to accommodate BIM? Why not just have BIM plans that reflect what is possible with current procurement practices. Let's use BIM now, not in some utopian future.
For more on my thoughts on IPD read my blog post Integrated Project Delivery: Bad News for Architects?

THE CONTRACTOR NEEDS A BIM PLAN

One thing I do agree on though, is that the contractor should be part of BIM planning. It can't be the overall project BIM plan because they are not around when the project starts. And it is pointless to totally rework a project BIM Plan done for design after the design is finished. Particularly when construction requirements are so different it would require restructuring the plan, not just 'tweaking' it.

My solution is to have a separate document, a contractor's BIM Execution Plan (BXP) to set out how the contractor intends to use BIM. This BXP would be part of a group of documents that form the BIM Management Plan (BMP).
Read my previous posts on the structure of a BMP, and the other plans, the Project BIM Brief (PBP), Participant BIM Plans (PBP), and the Design Collaboration Plan (DCP).

I've called it the BIM Execution Plan because most lay people, including owners, seem to assume a project starts when construction starts, not when design starts. So to most people the BXP is the BIM plan for the project. And in terms of concrete deliverables it is. The contractor delivers a building and information about that building for future management. How the information deliverable would be provided is covered by the BXP.

THE CONTRACTOR'S BIM EXECUTION PLAN

The contractor's BIM Execution Plan would use the pre-existing BIM plans as a starting point. These plans will provide information about what type and quality of BIM information is available, and in the case of the owners BPB, what is required. If a Contractor has a BIM manual for their own standard BIM processes this would also go into the mix.
Even if the contractual power exists to do so, there is little point forcing the design team to adopt the contractor's standard BIM processes. Most of their work is already done. Getting the design team to redo their work to the contractor's requirements will take extra time, be likely to introduce errors, and be met with demands for extra payments. It is far more realistic for the contractor to utilise what is available the best way they can. That said, there will be be areas the design team can do things differently, but they need to be assessed against what is realistically achievable and the what actual benefits will be attained.

The process to create a contractor's BXP might look like:

• Refer to BPB to define owner deliverables.
• Refer to PBPs and DCP to ascertain receivable BIM  data from designers.
• Refer to contractors BIM Manual for desirable BIM construction practices.
• Work out processes required to turn receivable BIM data into owner deliverables.
• Work out processes that will utilise BIM receivables for BIM construction practices.
• Negotiate changes to DCP, and possibly some PBPs, to help those processes.

WHO IS THE AUTHOR
The Contractor, or a BIM consultant engaged by the contractor.

WHEN IS IT DONE
As soon as the contractor is engaged for the project.
It could be requested as part of the bid process if all other BIM plans for the project were made available to all bidders.

HOUSE KEEPING CLAUSES
Definitions.
How this BXP fits into the overall BIM Management Plan (BMP) as defined in the BIM Project Brief (BPB).
Purpose and uses of this BXP.
Who is author / responsible for this BXP and key people on the project.
Contact information for these people.
Record of revisions to this BXP.
Meeting & review timetable.

BIM REQUIREMENTS
Contractor specific BIM objectives.
Contractor only specific BIM uses.
Sub-contractor BIM Plan requirements (for shop drawings).
Minimum modelling requirements for each discipline & sub-contract, either:
- general description;
- specific description;
- LOD table.
File deliverables and schedule.

BIM PROCESSES
Clash Detection.
Construction Sequencing.
Cost Control.
RFI and Variation (change order) management.
As-Built document creation.
FM data capture.


Like the design team's Participants BIM Plans (PBP), contractors should develop their own standard BIM Manual that can be used to inform BXPs they do for individual projects. It is always better to start with what you want, not what others demand.
But I think it unrealistic to believe this BIM Manual could be used to create every project BXP, as each project will have owners with different BIM deliverables, and design teams with different BIM capabilities.
Perhaps this BIM Manual is hierarchical. A series of stepped scenarios. If we get 'X' BIM information from the design team we can do 'A' construction BIM processes and deliverables, but if we get 'Y' we can only do 'B' processes and deliverables.

But I might be getting a little ahead of myself. I'm an architect, part of the design team, so I have to admit I'm guessing a little bit here about what are realistic construction BIM processes. I hope those better experienced in construction will get more involved in this BIM Plan debate, and not leave it up to us so called BIM experts, and certainly not to the BIM evangelists.

This was my last post on my take on the different plans that should make up an overall Project BIM Management Plan. After setting out the logic and philosophy behind this idea, now to see how it works in practice! If you are giving it a try, I'd be interested in how you get on.

Collaboration or Coercion: The Design Collaboration Plan

There is a lot of talk about 'collaboration' in BIM guides. In my mind collaboration means voluntary co-operation. But the requirements of current BIM guides read as enforceable obligations, more like coercion than collaboration. You WILL provide a model suitable for 4D, you WILL use IFC to exchange data. Where's the love?

Until I started studying the BIM guides out there I assumed collaboration meant the team got together and negotiated mutually beneficial work practices.
We'll create some specific views the mechanical engineers can use to put our model into their Navisworks, if they create some reflected ceiling plan views in their model with the settings we want.
We'll ensure all structural elements are modelled separately (particularly walls) in our model, if the structural engineers will commit to accurately placing (within the millimetre) their structural components.

But I struggle to see where these types of arrangements fit into current BIM guides. If it is the intention to allow for them (and they say it is), why are things that are agreed indistinguishable from BIM requirements and deliverables? Part of the problem is deliverables are expressed as work methods rather than actual deliverables, a topic I explore elsewhere.

My solution is to have a separate document, a Design Collaboration Plan (DCP) to record these co-operative types of arrangements. This DCP would be part of a group of documents that form the BIM Management Plan (BMP).
Read my previous posts on the structure of a BMP, and other plans, the Project BIM Brief, and the Participant BIM Plans.

DESIGN IS DIFFERENT FROM CONSTRUCTION

I call it the Design Collaboration Plan because this type of collaboration occurs during the design phase of a project. To be specific, it is about collaborating to create the Design Intent BIM.
During design a lot of changes happen to the model, and a lot of iteration happens. We start with no building and end up with a design for one.
During construction there are less changes to the model, and those changes are less dramatic. We start with a building design and end up with a record of what was built.
Even on Design and Construct projects where documentation and construction proceed closely together, it is still the design team that is doing all the investigative work in the BIM model. The contractor wants it when it is resolved, not before.
The extent of change during design, and the pace it proceeds at, requires a lot of cooperation amongst the design team. Anyone who has worked on a project where that cooperation was less than optimal will know what I mean.

THE BIM PANEL

Most BIM guides talk about the BIM process being run by a Project BIM Manager, usually assuming they are appointed by the client. Obviously there needs to be someone to take responsibility for things running smoothly. But an alternative approach is a BIM Panel, with a chairperson, or Leader.
The panel would be made up of project BIM managers from each of the design team firms. The BIM Leader  could be elected (or coerced), the idea being that person is the one with the best BIM knowledge and experience. So rather than a Project BIM Manager dictating to everyone what will happen, there is a group of experts making agreements.
A BIM Panel may not always be practical, but either way, dictator or democracy, the Design Collaboration Plan can still be created and enacted.

THE DESIGN COLLABORATION PLAN

The idea behind the Design Collaboration Plan (DCP) is to coalesce the individual Participant BIM Plan (PBP) intentions into a single cohesive document. The DCP will obviously be different to a PBP because it won't contain information that is only relevant to one participant. In fact is should only contain information relevant to cooperation.

The process to create a DCP might go like:

• Agree on project BIM Objectives by reviewing participant BIM Objectives from all the PBPs, along with the owner's from their BIM Project Brief (BPB).
• Agree on project BIM Uses by reviewing participant BIM Uses from all the PBPs,  along with the owner's from their BPB.
• Agree on project Level of Development by reviewing participant Level of Development from all the PBPs.
• Agree on a project File Exchange Schedule by reviewing File Exchange Schedules from all the PBPs.
• Negotiate software specific agreements.
• Review the plan to ensure it aligns with the client's BIM Project Brief (BPB).

 It might take several meetings to get agreement on everything. It might be necessary to renegotiate or add further agreements as the project proceeds. Once a contractor is appointed further changes might be required to satisfy the contractor's BIM requirements. So the DCP is a live document that may be revised quite often.
I'd recommend the DCP be an item in regular project consultant meetings, even if restricted to just highlighting the need to make changes to it (so triggering a BIM meeting). On smaller projects all DCP issues could be resolved at regular project consultant meetings, particularly if people with other roles are moonlighting as BIM Managers.

As with my previous posts the description I offer below is not definitive. The contents and structure of Participant BIM plans and requirements of the BIM Project Brief will go a long way to inform what is required  for a particular project.


WHO IS THE AUTHOR
The appointed project BIM manager or BIM Leader of the BIM Collaboration Panel is responsible for creating the DCP, but the contents of it comes from the results of meetings.

WHEN IS IT DONE
Once all major consultants are engaged for the project. If project consultant meetings are being held then it should be possible to start the DCP.

HOUSE KEEPING CLAUSES
Definitions.
How this DCP fits into the overall BIM Management Plan (BMP) as defined in the BIM Project Brief (BPB).
Purpose and uses of this DCP.
Referenced individual PBPs.
Who is author / responsible for this DCP and contributors from each consultant group.
Contact information for these people.
Record of revisions to this DCP.
Meeting & review timetable.

GENERAL COLLABORATION AGREEMENTS
Project specific BIM objectives.
Project specific BIM uses.
Level of Development of overall Design Intent Model (i.e. all models combined) that matches BPB minimum modelling requirements, either:
- general description;
- specific description;
- LOD table.
File exchange schedule.
Project Base Coordinates.

SPECIFIC COLLABORATION AGREEMENTS
Software Names & Versions used.
Sheet Naming Schema.
Agreed Categories and their uses.
Shared and/or common components.
Views for others to use.
Clash Detection Methodology.

Next post I'll look at the contractor's BIM Execution Plan, the last plan in my suggestion for a BIM Management Plan structure.

Utilising Your Office BIM Manual: Participants BIM Plans

One of the problems with a single project BIM Execution Plan is that you end up with different BIM standards and requirements for every project in your office. Potentially different naming standards, shared parameters, modelling requirements. How is an office supposed to develop best practice and train staff under this scenario?

In a previous post, Single project BIM Execution Plan: a good idea? I set out my views on how BIM Execution plans should be split in to separate BIM plans to create an overall BIM Management Plan. My last post was about the owner's BIM Project Brief. This post is about how an essentially in-house BIM manual can be utilised to form a Participant BIM Plan (PBP), which becomes part of a project's overall BIM Management Plan (BMP).

PURPOSE

The purpose of the Participant BIM Plan (PBP) is to explain how you are going to set your model up for the project. This is not only  important to those working on the project in your office, but also informs those outside members of the project team that will be receiving your model.
Providing this information:
- helps others navigate your model;
- allows others to assess what uses they can put your model to;
- makes explicit what BIM skills a participant actually has
   (as opposed to what was in their bid submission);
- exposes practices that can be discussed and negotiated between project team members.

Each team member's PBP informs what is possible when the Design Collaboration Plan (DCP) is created.
There is little point using the structural engineer's floor slabs in the architectural model if they will not model set downs. If the QS has no intention of using Revit to schedule costs why including costing parameters?

PBPs can also be used to verify that processes are in place to meet the deliverables and requirements of the owner's BIM Project Brief (BPB).

But perhaps the best purpose of PBPs is that it forces all participants to think about how they will do BIM on the project. I have sat in too many meetings trying to get a BIM Execution plan up and running with blank looks and no input from other players. Where things are agreed to when I know they have no idea how they can be fulfilled.

KEEP IT UP TO DATE

The PBP is a document that can be, and is expected to be, revised during the process of the project. Changes may be required because:
- the model needs restructuring for the next stage of the project
    (e.g. between Concept and DD);
- improved work processes are introduced;
- another team member's PBP exposes opportunities to improve work practices;
- negotiations during creation of the Design Collaboration Plan (DCP);
- changed requirements when the contractor's BIM Execution Plan (BXP) is created.

For this reason it is important a schedule of reviews are established as part of the plan, along with good record keeping of revisions. As one of the PBP purposes is to keep all team members informed it is important there are clear processes for informing everyone of revisions, and providing access to the latest revised PBP.

WHAT IS THE PROCESS?

The idea is to create a standard office BIM manual that can be tailored to suit specific projects.
Set out how you would like to do things, then only make changes where forced to, or where it helps your office. That said, as with any in-house manual your standard BIM manual should be regularly reviewed and updated to introduce better practices. Don't be too rigid as sometimes the changes you make for a project may be worthy of permanently adding to your office BIM manual.

1. First step is to align your standard PBP with the client's BIM Project Brief (BPB) and/or your consultant agreement with them.
2. Next review how you will set the project up. As the PBP can be revised, you can start with general information. If you don't yet know the exact files you will be creating and using, put in a file naming schema in the PBP.
3. As other team members are appointed and issue their PBP you may want to discuss issues with them that benefit both of you. There is no need to wait for a formal collaboration plan to start working together more efficiently.
4. Once the Design Collaboration Plan (DCP) has been created further changes may be required to your PBP so they align.
5. Further changes may be required if the DCP is revised, which may happen when the contractor produces their BIM Execution Plan (BXP).

PARTICIPANT BIM PLANS

As each PBP is based on different offices standard BIM manuals I would expect quite a variance between them. I don't see a problem with this. What is the point in forcing everyone to follow some graphic standard just so the BIM Management Plan looks nice. The end product is a building, not a BIM Management Plan (despite what some think).
Their contents may vary quite a bit as well, particularly if different softwares are being used. And there may be quite a bit of information that is not relevant to everyone, perhaps even no-one but the author. I also don't think this matters. I'd rather look through the actual document being used in-house by my consultants than some document just created for my (or the client's) benefit.

So the description I provide below is really just a sampler. There may be sections you consider vital that I've left out, there may be more sections than you think you need. But the idea it is YOUR document - make it to suit YOUR requirements.

WHO IS THE AUTHOR
Each project participant authoring BIM resources. Generally this will be the Design Consultants - Architect(s), Engineers, QS, etc.
Sub-contractors providing BIM shop drawings could also be required to create a PBP, although its structure and contents will be a little different from what I include here.

WHEN IS IT DONE
As soon as each is engaged for the project.
A draft PBP could be requested as part of bid processes for engagement (which would essentially be the office BIM Manual).

HOUSE KEEPING CLAUSES
Definitions.
How this PBP fits into the overall BIM Management Plan (BMP) as defined in the BIM Project Brief (BPB).
Purpose and uses of this PBP.
Who is author / responsible for this PBP and key people on the project.
Contact information for these people.
Record of revisions to this PBP.
Meeting & review timetable.

COLLABORATION INTENT
Participant only specific BIM objectives.
Participant only specific BIM uses.
Level of Development of participant's model that matches BPB minimum modelling requirements, either:
- general description;
- specific description;
- LOD table.
File exchange schedule.
Project Base Coordinates.

SOFTWARE SPECIFIC (using Revit as an example)
Software Name & Version used.
Folder & File structure (incl. names of files).
Workset Naming.
Level Naming.
Grid Naming.
Phase Naming.
Project Parameters.
View Types description.
View Naming Schema.
Sheet Naming Schema.
View Templates.
View Filters.
Revit Categories and their uses.


There is no reason your office couldn't do a standard Participant BIM Plan now. If you are a lead consultant and the client demands a BIM Execution Plan (but is not specific about what that is), put your own and other consultant's PBPs together and call it the BIM Execution Plan (or call it a BIM Management Plan, different but equivalent to a BIM Execution Plan). That is a lot less work than creating one from scratch, and likely to create a much more realistic, and therefore usable, BIM plan.
If you are not usually a lead consultant do one anyway. You can use it to make clear to your client what you will and won't be doing for your fee, and use it to negotiate what you will and won't do at BIM Execution Plan meetings.

Next post I'll look at the Design Collaboration Plan, where participant's PBPs are used to negotiate where and how they can help each other.

BIM for Owners: the BIM Project Brief

I have been critical in past posts about assumptions BIM evangelists make about owners and their role in the construction process. In a general way in A REVIEW: BIM IN PRACTICE -BIM Management Plans and specifically in the O1 - Educating Clients section of  A REVIEW: BIM IN PRACTICE - BIM Outreach.
But my criticisms relate to specific circumstances. Current BIM guides are all based on the premise the owner has expertise in construction and is willing to direct the construction process. This type of owner does exist; for example large government or statutory bodies like health facilities, educational providers and the military. Bodies that operate and manage their properties as well as have them constructed. And there will be more owners going down this path, but they will still be organisations that build and operate.
I don't believe BIM is only suited to these types of projects and clients. BIM has value for all projects, no matter how small, or how little direct use BIM might be to an owner. How can we manage BIM on these projects when owners have no or little interest in BIM? We need a way where an owner can put in as much or as little BIM requirements they feel comfortable with.

SEPARATE BIM PLANS

In my last post I described how a single BIM Execution Plan could be divided into separate BIM plans matching the stage and participants current involved in a project. The first BIM plan is the BIM Project Brief (BPB). The intention of this document is to set out the requirements of the owner or client, and set the parameters for subsequent BIM plans.

The reasons this is made a separate document is that it:
- can be done early in a project before everyone is engaged and at the table;
- can address the client organisation's specific requirements in a language they understand;
- can avoid unnecessarily interfering with how the construction professionals will deliver the project.

DELIVERABLES ONLY

A BPB should only be about specific deliverables. Deliverables relevant to the owner. These may include the way information is provided to the owner (e.g. 3D walk throughs); demonstrations that criteria have been met (e.g. thermal performance); information required for operating the completed project (e.g. FM data).
The owner should never specifically specify what BIM processes are to be used, only the results of BIM processes. The software to be used should not be specified, but the software format of deliverables can be. Construction 4D should not be specified, but 3D visual representation of staging can be.
Timing of deliverables should be related to when it is required. If FM data is not required at design why specify its delivery? It is an unnecessary cost and delay to the project.
Delivery of BIM plans and/or files in acceptable format could have monetary implications. Some USA contracts link a percentage of the fee with satisfactory delivery of specific items.

OTHER BIM PLANS

Although it is inappropriate for an owner to direct how construction professionals go about their work, it is acceptable for them to ask for evidence that they have processes, and that they are being followed. A BPB should set BIM plans as deliverables. It should also set out the minimum topics those plans cover. And I mean minimum, not every possible conceivable item that pad out current BIM guides. If it is not important don't include it or over elaborate it, leave room for the authors to put some effort in. Consider a must have list and optional or suggested list.

 A BPB should also establish what evidence is acceptable to show compliance, and when that evidence is required. Things like BIM plans should be submitted for 'acceptance' rather than 'approval'. As owner you don't want to become responsible for the contents and consequences of other's BIM plans.

THE BIM PROJECT BRIEF

The overriding premise of a BPB is to provide a framework for construction professionals to show they are competently performing their work.
Once the owner starts telling professionals how they are to do their job not only will they have their hands out for extra money, liability can flow back to the owner. For example, if specific software the design team is not familiar with is forced on to them it reduces their individual efficiencies and opens the owner to be blamed for any deficiencies of that particular software.
Construction professionals are engaged because they are experts. Let them work out the best way to achieve owner deliverables.  For example forcing the whole team to carry FM data throughout the entire design and construction process will lead to inefficiencies in other processes that the owner is unaware of. Often the most efficient way for the project as a whole is to create that information out of the design intent and/or construction models at the end of the project.

So what might a BIM Project Brief look like? I can't show you a real one due to confidentiality (and they don't quite exactly follow my current thinking). But I can go through how I think a BPB should be constructed.

WHO IS THE AUTHOR
The owner or owner's agent. Owner's agent could be either of:
- Project Manager;
- BIM Consultant (possibly with FM expertise);
- Lead Consultant (e.g. Architect).

WHEN IS IT DONE
At a minimum it needs to be done before BIM software starts to be used on the project. If the intention is to use BIM for area calculations it needs to be before concept design. There is no reason it could not be done before any design professionals are engaged. Then it can form part of bid documents for consultancy engagements, so scope can be costed and if necessary negotiated during bid process.

HOUSE KEEPING CLAUSES
Definitions.
Overall explanation of BIM Management Plan (BMP) structure:
- overall purpose;
- list each separate BIM plan and its purpose.
Who is author / responsible for this BPB.
Contact information for these people.
Process for revising this BPB.
Contractual Implications of this BPB, including sign off by relevant parties.

BPB CONTENTS
Owner only specific BIM objectives.
Owner only specific BIM uses.
Minimum modelling requirements, either:
- general description;
- specific description;
- table (e.g. like an LOD or USACE M3).
Method to validate that minimum modelling requirements met.
Party responsible for validating, which may be:
- owner (or agent);
- lead consultant;
- author / responsible party.

BIM plan requirements:
- list of BIM plans and authors / responsible parties;
- timetable (relative to other events);
- minimum requirements for process of revising BIM plans;
- minimum contents (headings) for each BIM plan.
Evidence BIM plan requirements met.
- draft to be provided of each;
- all revisions to be provided;
- submissions to include description of how compliance with BPB achieved;
- time frame for submissions;

Acceptable software formats for owner deliverables.
Other specific requirements for owner deliverables.

It looks like quite a long list, but my intention is that each may be as short or long as necessary. By judicious use of reference documents I'm sure it could be a one page document.
For example an owner may have no BIM objectives or BIM uses themselves, then the minimum modelling requirements could be a general description something like "Adequate to achieve the BIM uses listed in other BIM plans of the BIM Management Plan". Then a very short list of BIM plan requirements, perhaps offering one or more of the many BIM guides around for guidance (but not compliance). Like the NatSPEC National BIM Guide; AEC (UK) BIM Protocol for Autodesk Revit; USACE BIM PxP Template to name a few.
Or an owner may have very specific FM requirements and a massive minimum modelling requirement table like the the NatSPEC National BIM Guide BIM Object/Element Matrix Manual, with very specific IFC deliverables, and very specific BIM plan requirements.


After writing this post I see an example BPB would be instructive (a picture is worth a thousand words). But I'll leave that for another post. Next post I'll explore what sort of document Participant BIM Plans (PBP) should be.






   

Single project BIM Execution Plan: a good idea?

Construction projects always evolve over time. As it evolves the deliverables and personnel change. Not everything that needs to be done is known, nor the people who will do it. Yet BIM Execution Plans are structured as if all information is knowable at the beginning of a project.

WHAT THE BIM GUIDES SAY

For example the NatSPEC National BIM Guide (p2) says:
"After the requirements for using BIM on the project have been defined and before the project formally commences . . .".
When have all of the requirements (whether BIM or not) of a project ever been defined before it starts?

Most BIM Guides make lip service to this reality by stressing the BIM Execution Plan requires continual updating.

The Pennsylvania State University "Building Information Modelling Execution Planning Guide", (Chapter 1, section 2):
"The BIM Plan should be developed in the early stages of a project; continually developed as additional participants are added to the project; and monitored, updated and revised as needed throughout the implementation phase of the project."

The new draft AIA Document E203™ – 2012, Building Information Modelling and Digital Data Exhibit also makes this assumption, one of the many clauses this is mentioned:
"3.2.3 The Parties, together with the other Project Participants, shall review and, if necessary, revise the Digital Data protocols at appropriate intervals as required by the conditions of the Project."

Which creates a legal problem (p19, draft clause 102):
". . . enforcement of the protocols may ultimately turn on the ability of a Project Participant being able to prove that the other Project participants agreed to the protocols. Accordingly the Project participants should develop an acceptable process through which each project Participant can manifest their receipt and/or agreement to each version of the protocols. Such a process would then ensure against a Project Participant ultimately alleging that it never saw or agreed to the latest version of the relevant protocols and is therefore not bound by them."

Remember they are talking about a single plan covering everyone in the project. Any change requires the participation and agreement of everyone - even if the change doesn't materially effect them.

The RAIA/CA BIM in Practice document P3: How should you prepare & apply a BIM Management Plan? discusses this at length on page 4. In fact it states:
"You can no more formulate a detailed, definitive BIM Management Plan in the first week of the project than produce a set of working drawings before doing a sketch plan."
Which I wholeheartedly agree with. It then goes on to say:
"All of this suggests that the most sensible approach is to plan for a series of BIM Management Plans which represent progressive iterations of the initial plan."
A  "series of BIM Management Plans" is an interesting idea. But what they actually mean is the same plan revised multiple times. Like most other BIM guides they still treat the BIM Execution Plan as one document.

The NatSPEC National BIM Guide nearly gets there. It divides the BIM Execution Plan into two documents, the "Project BIM Brief" and the "BIM Management Plan". The Project BIM Brief is a short document (6 pages) that purports to only define client requirements. Yet it reference things in the BIM Management Plan, so can only be done if a BIM Management Plan has also been done.

The NatSPEC National BIM Guide also talks about a "Design BMP" and a "Construction BMP". Once again very sensible. Unlike many other BIM guides it recognises that during design, before a contractor is appointed, it is pointless to include BIM matters concerning construction in a BIM Execution Plan. The NatSPEC National BIM Guide has a good general description of what Design and Construction BIM Management Plans should have in them (p4-5). But then the rest of the guide ignores the specific requirements of these two different documents and reads as if it is talking about a single BIM Execution Plan that covers everything.

PROBLEMS WITH A SINGLE BIM PLAN

What's wrong with a single document that has all things BIM in it as the project BIM Execution Plan?

Because current BIM Execution Plans include everything, right up to FM, nobody takes them seriously at the start of a project. As an Architect I would like a usable  BIM Execution Plan when concept design starts. And before that I would like to know what BIM deliverables the client wants. Yet on most projects you are lucky if you are allowed to do one at the start of Design Development. Usually it is not until the client is considering the contractor's appointment that all hell breaks loose and and a BIM Execution Plan is demanded. Which is way too late.

The other side of the coin is the client who demands a BIM Execution Plan (usually based on some one else's BIM Execution Plan) be done that includes a whole lot of things unknowable at concept design. This is aggravated by the fact the client doesn't understand the BIM Execution Plan they demand we mimic because it is so complex and technical. We end up getting caught between a rock and a hard place. Either we leave it out and not get the BIM Execution Plan approved, or make something up that may or may not happen, and end up being held responsible when it doesn't.

And then there is the issue of who authors a BIM Execution Plan.
By having a single massive BIM Execution Plan it requires some one with a lot of expertise. From knowledge about every software used on the project to contract law. But those responsible for enforcing a  BIM Execution Plan rarely have even a small part of that expertise. So we end up with a situation where the  BIM Execution Plan is left in the drawer, either too hard to do, or done by an underling with no authority. Or even worse, a BIM Execution Plan done by an outside "BIM consultant" with no responsibility for its effects on the project (you know, the thing we are actually building), and ends up being a millstone around everyone's neck.

SEPARATE BIM PLANS

Wouldn't it be better to divide up the traditional single BIM Execution Plan into separate BIM plans that cover only the participants and material relevant to a stage of a project? That only talks about things relevant at that stage, in a language that the players at that stage understand?
A series of plans that get progressively more intricate and complex as the project progresses. A series where each plan sets up the parameters and requirements for following plans.

What might this series of plans look like? What would be the individual plans that make up the overall project BIM Management Plan (BMP).
As a start my suggestion is for the following BIM plans:

BIM Project Brief (BPB)

• by client, or lead consultant (as a return brief). 
• short, high level document. 
• created before project starts (ideally included in consultancy bid documents)
• sets out BIM deliverables only, avoids describing how. 
• describes required content of DCP & CBP.
• should never need to be revised (contractual implications if it is).

Participant BIM Plans (PBP)

• by each member of design team.
• created as part of consultant bids, or immediately after each consultant appointed.
• describes methods that will be used to satisfy BPB.
• software specific. Doubles as in-house project manual. 
• describes how BIM model will be constructed, including what will be available to others & what is required from others.
• provides basis for DCP.
• may be revise due to agreements in DCP.

Design Intent Collaboration Plan (DCP)

• by design team
• created after design team appointed.  
• similar structure to current BXP guides .
• refers to, rather than duplicates individual consultant PBP content.
• describes what will be available to CBP.
• may be revised due to new participants, and requirements of CBP.

Construction BIM Plan (CBP)

• by contractor.
• created as part of contractor bid, or immediately after contractor appointed. 
• similar structure to current BXP guides.
• describes methods that will be used to satisfy BPB.
• describes what is required from DCP.
• describes what will be available to FM & As-Built. 
• should not need to be revised, but could be if necessary.

For this series of plans to work as the project's overall BIM Management Plan all plans must be freely available to all project participants. If there is any information that is required to be controlled, it must appear only as a reference, available only on request where appropriate.

ADVANTAGES OF SEPARATE BIM PLANS

What are the advantages I see of this structure?

• Direct users of each plan are responsible for its creation, so that each plan is in the hands of those best placed to create something meaningful to them, and to enforce it within their organisation.
• The client can define their requirements without interfering with how they are delivered. Any (gasp) BIM consultant engaged will have their influence limited to the BPB. 
• PBP can be based on each consultant's in-house office BIM manual, avoiding the situation where every project requires a custom written BIM plan (and manual).
• Plans can be requested as part of bid processes and so become part of the selection process, or alternatively mandated as part of service delivery. 
• Each informs the requirements of the next, but can stand alone as a useful document, and be enforceable in its own right.
• Only the middle plans, PBP and DCP, may need revising to ensure they align with subsequent plans. And as these only involve the design team should be easier to revise.

What do you think?
I've listed the advantages, what are the disadvantages.
Have I left any BIM plans out?

I've purposely not talked about specifics in each BIM plan, but in my next post I'll have a go at the BIM Project Brief (BPB).

Managing Detail in Revit Families

In my previous post Too much Detail: why is my computer so slow? I explored the problems of over-modelling in Revit. In this post I describe an approach to creating Revit families that deals with this problem.

The original authors of Revit actually recognised the problem of over-modelling and provide a method to deal with it: Detail Level settings of Fine, Medium & Coarse. Yet these are rarely used to their full advantage. 

REPRESENTATION LEVEL

One way to conceptualize how to use Detail Levels is to think of models as possessing a representation based on their level of detail:

2S  - Symbolic or simplified 2D. Plan 2D representation only, using Symbolic lines
           and Masking regions. Only appears in plans.
2D  - Full 2D. Plan 2D representation only, using Models lines.
            Appears in plans and 3D views.
3S  - Simplified 3D. Block 3D model. Used in plans and elevations.

3D  - Full 3D. Realistically modelled. Used in 3D views only.

You model to one of those representation levels, and assign elements to the appropriate Detail Level  (Coarse, Medium or Fine) when making the families. Anyone can then control which one will be visible in a view within a project by selecting the appropriate Detail Level (refer red squares in image above).

To create this level of control select elements in the family file and change Family Element Visibility Settings.

How might you use this on a project?
By setting the Detail Level to Fine in a rendered 3D view you get it in glorious detail (as 3D rep), set to Medium in a room elevation and you see a simplified representation (as 3S rep), set to Course in an overall 3D view and the location of furniture is shown (as 2D rep) but doesn't clutter the architecture.

FAMILY CREATION

Now you could create different family files for each representation of the same object. But if more than one family for the same thing is used in a project you will start to get management complexity I'm sure you could do without. Someone needs to make sure all versions are captured in schedules. If it is required to change the object, either its appearance or scheduled parameters, someone has to ensure all versions get changed. Both in the project and within the family library.

But there is no reason why there can't be ALL representations in the same family file. If Detail Level settings are created correctly only one representation will be visible at a time once the family is in a project.
Although putting them all in one file can make creating families a little more complex, my view is every extra  minute spent on making a family better saves every person (and there may be many) who uses that family at least 5 minutes.
If this process is built into office practice it becomes less of a chore (as there is a clear process to follow), and leads to other benefits:

• If it is mandated families are always initially modelled as 3S Rep the temptation by anyone to try and create a realistic representation is removed. It also drastically shortens the time to get a usable family.
• Family templates can be created that have a parametric box already modelled, along with other parameters for scheduling. A new family can be instantly created by simply saving the template, unchanged, under a new name. It can then be placed in the project straight away, being visible both in drawings and schedules. When there is more time, or the office family maker gets to it, it can be updated with a more detailed family.
• Poorly modelled manufacturers content can be used without all the editing usually required to make them useful. Open the manufacturers family, make sure everything is on a subcategory (i.e. not 'none'). Put all elements on to Fine Detail Level. Then copy and paste them into a family containing a 3S rep. Obviously this won't work for manufacturers families that are parametric, but most are not (one of the reasons they are poorly modelled). And generally for a 3D rep you want a realistic model, not necessarily an absolutely dimensionally correct model.

WORKING IN THE FAMILY FILE

But how do you create two models in the same file?

Although you can set the Detail Level of views in the family editor, hidden elements are made half tone rather than invisible. A way around this is to use subcategories. These can be made invisible in family editor views.

Subcategories for representation levels:

2S  -  Plan Rep

2D  -  2D Rep

3S   -  3S Rep

3D  -  descriptor subcategory (e.g. Chairs).

All elements must be on a subcategory, never on None (which is same as Category). If you turn off a Category in a view Revit turns all subcategories off as well.

I use descriptor subcategories for 3D rep because I might want to assign materials via subcategories. 3S rep doesn't usually require a material as it is not used in coloured views, but in elevations & sections. However, you can still assign a material to the 3S rep elements by assigning its material to a material parameter.

You may come up with other subcategories. The point is every element needs to be on consistent  subcategories reflecting their representation level. 

To manage subcategory visibility create views in your family file for each representation level. I have done it to my family templates so they are always available when I make a new family.

There is further control via Family Element Visibility Settings. You can change which view type an element will be visible in. But only up to a point, everything but Symbolic lines and Masking regions are always visible in 3D views.

Note also that objects not exactly parallel to an elevation or section will display as if they are in a 3D view,  Left/Right and Front/Back settings are ignored.

Family Element Visibility Settings for 2S elements.

(note only Detail Levels are available for Symbolic lines and Masking regions)
In this example the chair doesn't appear at all in plan views set to Coarse Detail Level.

Family Element Visibility Settings for 2D elements.
In this example a 2D representation only appear in 3D views set to Coarse Detail Level.

Family Element Visibility Settings for 3S elements.
In this example 3S rep elements only appear in elevations, sections & 3D views set to Medium Detail Level. Symbolic Lines (2S rep) are used in plan views so you don't want 3D elements to be visible in plans.

Family Element Visibility Settings for 3D elements.

In this example 3D rep elements only appear in 3D views set to Fine Detail Level.
They don't appear at all in elevations or sections.

If the realistic view is simple, use the same elements for both 3S and 3D rep.
One element can appear as both 3S and 3D rep by ticking both Medium and Fine in its Family Element Visibility Settings, and making sure Front/Back and Left/Right are also ticked.

A word about nested families.

If you set any of the Family Element Visibility Settings to elements within the nested family those elements won't appear in your family views when you place the nested family. For example if an element in a nested family has display in Plan/RCP unticked, you won't be able to see it in any plan views, which can make it nearly impossible to place it. Also if any of the Coarse, Medium or Fine settings are unticked you won't be able to use the nested family for both 3S and 3D representations in your family.

Apply any Family Element Visibility Settings to the whole nested family after it has been placed.

So there you have it. It may appear a bit complicated at first, but once you get into the habit of making families this way it is pretty straight forward. Good family templates takes a lot of the work out of it.

And you end up with highly flexible families, so people can spend more time on the project and less time making families. Or as I think of it, more time to concentrate on the architecture (or engineering).

Too much Detail: Why is my computer so slow?

As BIM gets used on larger projects one on the most common complaints is how slow, and hence frustrating, working in Revit becomes. Using a more powerful computer only helps up to a point. There are metrics on what specifications a computer should have (which I won't go into in this post), but even an adequate computer won't make working on a large project the pleasure it should be.
Many people blame large file sizes, after all Revit project files of 400Mb are not uncommon.
Those that still think the CAD way believe that splitting a project into a number of linked files will solve the problem.
But if  Revit is to do all the things BIM is useful for, everything needs to be instantly accessible. Therefore  everything has to be in one file, or if in several linked files all those files need to be loaded in to your computer at once.
The reality is file size in itself, whilst an indicator of underlying problems, doesn't have a huge impact on working in Revit. The worst it does is slow down opening and saving the project file (which can still be a pain).
A greater culprit is graphic complexity, or geometric density. The more 'stuff' Revit has to deal with the longer it takes to do anything. Geometric density effects Revit in two ways: view regeneration and constraint calculations.

SLOW VIEW REGENERATION

The slowing of view regeneration is caused by the complexity of calculating hidden line removal.
I can appreciate this because back in the late 1980's, when AutoDesk released AutoShade, it would take 36 hours to do a hidden line image of a pretty simple office building. Which was longer than it took to manually trim out the hidden lines.
You may notice that software that is faster than Revit at showing 3D, like Navisworks, always uses a shaded view, no lines. In fact you can speed up 3D views in Revit by using Shaded visual style with Show Edges unticked. Try it on a large project.

When I say 'stuff', I mean detail. Every extra line that has to be calculated adds to the load.
The company logo on the Blanco cooktop family adds 136 lines that Revit has to deal with. And Revit doesn't know it is just a logo and not important.

Besides the number of lines, curves also present a calculation challenge. The line Revit draws to represent the edge of a curved surface is not based on a fixed location. Its location has to be calculated based on the angle you are viewing it from. The more curved surfaces, the longer Revit takes.

SLOW EDITING

Everything is connected in Revit, the more complex the things the object you are working on is connected to, the longer Revit takes. I had a situation where it was taking just under a minute to draw a wall in a car park. We racked our brains, ransacked google, but to no avail. Then we noticed it took no time at all to draw the same wall outside the car park floor. After some help from AutoDesk we worked out it was the Room placed in the car park that caused the problem. The car park floor was large with complex edges, and had a single Room element placed in it. Whenever a new wall was placed Revit was recalculating the Room area, (and whatever else it calculates), causing the delay. This is an extreme example, but the lesson is Revit does a lot of calculating on the fly. And although this may not be noticeable on smaller projects, it become significantly noticeable on large projects that are over-modelled.

OVER-MODELLING

I see this all the time. From the mechanical drafter creating photo-realistic fan units no-one will ever see, the new Revit user modelling a walking stick to place in a hospital project, to every family I have ever looked at provided by a manufacturer (a sink that included the bolts, wing nuts and brackets to install it is my favourite). And not just families. Existing conditions that are to be demolished modelled as if they are going to be rendered, curtain wall mullions modelled to shop drawing detail standard. The list goes on.

Here is an example of a chair in an elevation view. The simplified version shows the geometric extents of the chair without all complexity that the realistic model shows. To represent how many extra lines there are I printed both to separate PDF files. The realistic model file was 2.7 times the size of the simplified model file. When there are 10 chairs it goes to 4.5 times larger, and the time to process the realistic model file was noticeably longer.

Why do people do it?
Why do all that work when it will never be seen in any of the 1:50 to 1:200 scale drawings they appear? It wasn't such a problem with CAD, why is it a problem with BIM?
Because they can.
Revit has the tools to do exquisitely realistic modelling. And they are not that hard to use. Learners are the worst culprits. They think they are doing a good job (and they are if the task is to produce photo-realistic renders), but are completely unaware of the consequences. Other culprits are contracting BIM 'experts' who don't stick around to see the consequences of their work,  design architects who rely on photo-realistic images because they lack the imagination to visualise their design, and those who don't use the software but direct those who do, like project architects and directors.

I really see this issue as one of the biggest facing BIM use at the moment. Hopefully in the future as people become more familiar with BIM and computers get more powerful it will diminish. But for now it can't be ignored.

HOW TO AVOID OVER-MODELLING

The first step is to define the scale everyone needs to model to.
It is a simple metric that is easy to imagine and test. For example specify that only elements and detail that can be seen on a 1:100 drawing be modelled. It is easy to calculate the size of the smallest elements that can be modelled. Assuming a 0.25mm line thickness is used, anything smaller than 25mm will appear as a single thick line on a 1:100 drawing.
Specifying 1:50 (which is probably more realistic), anything smaller than 12.5mm will appear as a single line.

There is little point modelling to suit construction details. It is not possible to produce readable detail drawings from a realistic model. Things are too close together.
Flashing is a typical example. Steel flashing is 0.6mm thick. On a 1:5 drawing that is 0.12mm. By convention flashing is drawn using a thick pen, say 0.5mm, 4 times thicker than the flashing. And flashing is placed between, or on, other elements along at least one edge. Add in the pen thickness for those other elements and the full extent of the flashing is no longer visible on the drawing, there is just one thick blob.
Construction details have to be 'faked', things drawn further apart than they are so they are readable on a drawing.


SUGGESTED WORK PRACTICES:

• If it is intended the model you are working in will be used for documentation treat it as if you are documenting, even if at schematic design stage. Only model sufficiently for documentation. (Depending how clean the design process was, sometimes it is better to discard a schematic design model and start a new one)
• Keep in mind the fact that high levels of detail are only ever required for parts of the project, not everything in the project. An external view doesn't need the inside to be detailed, a view of one room doesn't require every instance of furniture in that room to be highly detailed across the whole project, a window sill detail is of only one window, every window doesn't require that level of detail.
• If additional detail is required for a particular part treat it as a separate task, don't alter your main model. Create new views rather than edit existing views, place one off families rather than replace an existing one with a more detailed one, create new easily identifiable materials, etc. Then these can be deleted from the project when no longer required, and removed when providing to other consultants (who also struggle with your huge files).
• Don't try and put everything into your project files. Consider making copies of the project file if radical changes are required to achieve a one off deliverable (e.g. an alternative design for discussion). Using Design Options is not always the most efficient path.
• Using different families of the same thing to show different levels of detail isn't good practice. Schedules won't be correct, counting numbers becomes complicated.
• Swapping out families is also not good practice. Unless carefully controlled parameters can be lost or altered, dimensions deleted and schedules completely messed up.
• If you want to use this method do it in reverse -  make a copy of the BIM project for rendering, swap out families ONLY in this copy.
• If Detail Levels aren't adequate use custom shared parameters and filters to control visibility in individual views. But be careful you don't make it so complex others receiving your model (or others working on it in your office) don't understand what you have done.

MODELLING TIPS:

• make use of Fine; Medium; Coarse Detail Level settings in families.
• simplify shapes; avoid curves. Particularly rounded corners and edges you won't see in a drawing.
• turn off visibility of model objects in plan and use Symbolic lines (2D lines) and Masking Regions. But don't use symbolic lines in elevation. They won't be visible in section and elevation views that are not exactly perpendicular to those lines. Use Model lines (3D lines) instead.
• use Model lines (3D lines) for very thin objects (e.g. wire shelf) and joints (e.g. where drawers, cupboard doors meet).
• use fill patterns instead of modelling (e.g. meshes).
• keep it simple. Model what everyone needs to know, not what the object looks like.   

Ultimately it comes down to training and oversight. Everyone working on your project must be aware of the consequences of over-modelling, and be familiar with the methods to avoid it.

Next post I'll offer a strategy for creating families suitable for both realistic views and documentation drawings.

Which direction is Depth?

Using family components from different sources is always a pain. Not just because some are made so badly, but because everyone seems to create them differently. One such point of difference is names used for  dimension directions.
In English I count 7 different ways to describe linear dimension directions:

breadth

depth

height

length

long

thickness

width

But we only need to describe 3 directions, sometimes 4 if we want to include a material thickness.

Until BIM it didn't really matter. We used context to decide, usually the context of convention. But in BIM a lot of this context is lost. Schedules is an obvious example. For a start if there is no consistency you end up with 7 columns instead of 3. And the height of one component may be the same direction as the depth of another.
Another context lost is the region, country, and/or industry. Components are available world wide over the Internet. The convention in one region, or industry in one region, may be the opposite of another.

When I bring this problem up, no-one is interested. I haven't found a standard that addresses it (AutoDesk and ANZRS are silent). People say it doesn't matter. And it doesn't. It doesn't matter which definitions are used. What does  matter is that the SAME definitions are used.  And the most effective way to do this is to come up with simple rules that can be applied in any situation.  That shouldn't be too hard. Or is it?

THE PROBLEM

The basis of the problem is, as I mentioned, humans understand direction names by context. Ignoring any particular industry conventions, the two common types of context are proportional and orientation.
Proportional is when you define the longest dimension as length, next longest width, smallest depth. This the way most people normally think.
Orientation is when you define each direction by its orientation in respect to a reference direction. This could be the person looking at it (height is up/down), an absolution reference plane like the ground (height is forward/back), or a coordinate system (height is Z axis).
There is a very good investigation of this in the NatSPEC BIM Portal, under Workshop, Describing the dimensions of BIM objects.

SUGGESTION 1

Neil Greenstreet of NatSPEC, who authored Describing the dimensions of BIM objects, came up with a schema that tried to address how most people treat direction naming. A full description is on the NatSPEC BIM Portal, but in essence it is:

For unfixed materials, use a proportion-based schema:
1. Use length, width and depth for cuboidal forms.
2. Use length, width and thickness for linear or planar forms.

For installed (or ready to install) elements, use a mixed orientation-based/proportion-based
schema:
1. Use height, width and depth for cuboidal forms.
2. Use height, length and thickness for vertical planar forms.
3. Use width, length and thickness for horizontal planar forms.
Note: The difference between cuboidal forms and planar forms would need to be defined by
an agreed aspect ratio.

My feeling is this is too complicated. There are too many different rules. Also a proportion based schema will never work where components are parameter driven. You can't change the label of a parameter when its value becomes the second longest instead of the longest.

SUGGESTION 2

Thinking about this problem I believe the best approach is to use the idea of orientation only. The orientation that works in the majority of situations is based on standing in front of the object.  You need no other context than the object and your (imagined) self.
This rule works for most objects:

DEPTH   =  FRONT to REAR
WIDTH   =  LEFT to RIGHT
HEIGHT  =  BOTTOM to TOP

An alternative could be:

WIDTH     =  FRONT to REAR
LENGTH   =  LEFT to RIGHT
HEIGHT    =  BOTTOM to TOP

It doesn't really make much difference, but I stuck with the first rule as Revit uses these names in the casework template.

But some objects don't fit this rule. Objects like beams, ducts, floors. Although hard to precisely define, these types of objects could be described as having a horizontal orientation - dimensions parallel to the ground plane vary the most.
When standing in front of these objects the rule becomes:

DEPTH    =  BOTTOM to TOP
WIDTH    =  FRONT to REAR
LENGTH  =  LEFT to RIGHT

By defining 'Front' as the cross section (cut through smallest dimensions) the rule becomes:

DEPTH    =  BOTTOM to TOP
WIDTH    =  LEFT to RIGHT
LENGTH  =  FRONT to REAR

Which is a little closer to the first general rule.

Thickness deserves its own rule:
THICKNESS is distance between two faces of single material  (or component made of materials permanently fixed together).
e.g. door panel, plasterboard, steel beam, duct insulation.

This is simpler than the NatSPEC way, but is it simple enough?

SUGGESTION 3

If direction rules are based on where 'Front' is, another approach is to have separate rules for where 'Front' is located. The advantage of this is that only one direction rule is required.
If we think of horizontally orientated objects as objects we have to bend to look down at, or to look up at, we could describe them as objects that are above or below. For example when looking down on a bucket or sink, or looking up at a beam or ceiling, Front to Rear becomes Depth in respect to the viewer.

So if we have one direction rule:

DEPTH   =  FRONT to REAR
WIDTH   =  LEFT to RIGHT
HEIGHT  =  BOTTOM to TOP
for objects above & below length is used instead of height:
LENGTH  =  BOTTOM to TOP

And two orientation rules:
GENERAL RULE
FRONT is side accessed by a person standing on the ground.
ABOVE & BELOW RULE
FRONT is top or bottom of object, bottom is cross section or end of object.

DIRECTION ORDER

An allied issue is the order of direction descriptions when naming objects.  As this is not as critical I would term this a 'convention' rather than a standard.
The AutoDesk Family guide recommends WxDxH (page 27).
In the Australian home construction industry windows are alphabetical (in English) HxW.
Australian steel uses DxW, timber sizes use DxB (for breadth, which is same as width).
I tend to use DxWxH as depth is lest likely to vary, width more likely, and height (or length) most likely. For example in a set of cupboards for each depth you have a range of widths and heights.
ANZRS recommends adding a letter after dimensions (e.g. 300d x 600w x 700h), which is eminently sensible whatever convention is used. But ANZRS don't make a recommendation for the actual order, which would be helpful.

CONCLUSION

I must admit, I don't feel I have come to a definitive answer. Perhaps there is not one. Maybe my 'rules' are really only useful as conventions, to be applied in the absence of clear definitions.
What do you think? What conventions do you use?

A REVIEW: BIM IN PRACTICE - EDUCATION

It is a scandal how far behind teaching BIM is at the majority of academic institutions.  I though academia was supposed to be leading innovation, not trying to play catch-up. Doing research on BIM is not the same as teaching it.  We don't need any more dry, out of date, utopian, and ultimately irrelevant, papers about BIM.  We need building professionals with a good understanding of BIM and the skills to make it work.

This is the fourth and last post of my comments on the Australian Institute of Architects and Consult Australia group of documents under the title "BIM in Practice". My first post was A REVIEW: BIM IN PRACTICE - Legal & Procurement, the second A REVIEW: BIM IN PRACTICE - BIM Management Plans, and third BIM PRACTICE - BIM Outreach; advice to the various players in BIM projects.

All documents are available from  BIM/IPD[AUS] (http://www.bim.architecture.com.au/).

The documents are really discussion papers, and pretty much represent current thinking about BIM by BIM experts in Australia.  These posts are not so much about what is in these documents, as what is wrong (in my opinion) and what is missing. But please keep in mind that I agree with the vast majority of what they contain, and that my aim is not to denigrate this outstanding effort.

E - EDUCATION

Clearly written set of documents that, unlike the other workgroups, suggest a way forward.
And something really needed. Whilst those doing BIM are learning by experience, there needs to be some thought put in to how that knowledge can be passed on to future BIM users.

Three areas of approach are clearly articulated:
 - teaching of BIM concepts
 - teaching of BIM methodologies
 - teaching of collaborative practice

An issue not touched on is the danger of BIM education straying outside the area of expertise of those being taught.  Whilst it might be beneficial to teach architects how a structural engineer uses BIM to do their work, you don't want to encourage architects to actually do, and take responsibility for, structural analysis. Even if it is as easy as Autodesk is telling everyone when you use their cloud analysis service.

E1 - BIM EDUCATION & BIM LEARNERS

Separating out the different types of BIM learners is useful. Convincing a CEO to adopt BIM is a different task to making someone proficient in BIM tools, as is teaching project leaders and managers how to manage BIM teams and projects.

It is NOT clear "that shared BIM database servers will play a more significant role in supporting collaborative processes".  Another example of the single unified database fallacy.
The danger is by making this assumption problems that exist now are put aside as not being important as they will be solved "when everyone moves to a single model".

A discussion on specialisation within BIM tasks may have been worthwhile.  The range of skills and knowledge required across all BIM competencies is beyond a single human being. Even using BIM software like Revit it is not possible to be competent at everything it can do. Particularly when some tasks might only be done a few times a year, or once a project.

E2 - BIM LEARNING PROVIDERS

Good points are made about academia. It seems academia is just like any other large, conservative organisation. Those at the top don't understand BIM and have no interest in it.

Anecdotally (mainly from students) BIM teaching in academia is disappointing. It would be interesting to see a comparison study of which institutions are doing what with integrating BIM into their courses.

IPD and single shared BIM databases solve a lot of the problems encountered while using BIM. But if that is all learners know they will have no skills in how to overcome those problems when they end up on projects in the real world that don't use these technologies.
This exposes the issue that only teaching future BIM users what is considered desirable is not going to help the industry. Nor is relegating BIM to post-graduate research projects "about the future".

New roles bring new expertise and specialisation. Managing large amounts of digital data is new to the building industry and not currently considered a skill required by building professionals. Perhaps building professionals are not the appropriate ones to take this role on. But some-one has to, it can't just be ignored.

BIM involves those from cost control through to building product suppliers, to facilities management. It is important education policy captures all players, not just some.

The role of reference sources is not discussed.  It is unrealistic to think that once you "teach" someone BIM they will know everything about what they will be called to do.  In CAD this was possible. The skills to draw a stair are the same as drawing a window. But in BIM software there are different tools to construct stairs and windows. There may even be more than one tool to model windows.  The role, creation, maintenance and accessibility of reference sources must be integral to all training.

E3 - BIM LEARNING SPECTRUM

Very good dissection of the issues and clearly articulated (being an architect, I'm a sucker for a good diagram).

A national framework for BIM competencies is suggested, with an on-line "BIM Learning Hub" that centralises it all. And that this be done by a newly created "National BIM Institute" (NABIMI)?.

If it is set up with just another government grant with no on-going funding (like all BIM initiatives in Australia so far) I don't see it doing much. It might work if picked up by one of the academic institutions or professional bodies.  After all, it could generate income if used by enough BIM education providers.
An ambitious, but an interesting idea, worthy of further discussion.

CONCLUSION

BIM education has a lot of catching up to do.
A National BIM Institute setting a BIM education agenda is a worthwhile idea.  Particularly for those who don't know where to start (and there seems to be many).

In thinking about academic institutions it is hard to see how BIM can taught if students don't know how to use actual BIM technologies - which means softwares.
One of the problems I see at a number of architecture schools is that it is considered not their role to teach what they call "the tools of the trade".  Not as a part of the core course anyway. Their view is it is up to the students to learn whatever they deem appropriate. The argument given is that they are teaching architecture, and it is not their place interfere with what tools students use.  The result is students have a mish-mash of softwares they use, often using 3 or 4 different programs on one submission (e.g. Rhino, AutoCAD, Photoshop, MS Excel). And of course different students have different skill levels, from each other and within the softwares they know.
I would of thought, if you are concerned about teaching architecture, a better approach would be to restrict them to one software. After the initial learning period students would spend less time wrangling software and more time on the architecture. Product from students would also be more uniform, making it easier to identify good architecture from merely good IT skills.

I understand it is even worse in engineering schools, where it is considered below an engineer's dignity to be involved in drawing, which in their view includes 3D modelling.

And then there is collaboration. Students work in teams within their facility, but rarely with students from other facilities.  It would be great if this happened more often, as a matter of course rather than one off research "pilots".

I could go on. Maybe in a future post.

But perhaps I'm wrong. Let me know if I am.
If you have a view please add your comments to my blog, or go to BIM/IPD[AEC] (http://www.bim.architecture.com.au/) and put your comments there.


This is my last blog on the BIM in Practice documents.