Unless you want to get hopelessly lost all journeys require a road map. Sure you can wing it and see where it gets you, but using a road map means you will not only get there faster, you will also arrive at the correct place, not a place that might or might not be where you need to get to.
BIM is new and still evolving. Pretty much everyone is on a journey to implement BIM into their work practices. We all have need of a road map.
BIM may be a process, but it is a process that is not possible without software. You can’t create models, or extract information from them, without software. So the beginning of any road map starts with the software being used. And you can’t do anything if no model exists, so the obvious starting point is BIM authoring software. Revit is my example, for no other any reason than I know it well. The specifics may differ but any BIM authoring software will require similar milestones in their road map.
Not all software is BIM capable
It may seem obvious, but it is worth stating: Make sure the software you are creating a road map for is BIM capable.
And be aware that BIM authoring software works differently from CAD and 3D drawing programs. For a start many people work together in a single file. What they do will have an effect on everyone else working in the model. Things are shared; where a particular blockwall is required the same blockwall component has to be used by everyone.
The model is also used for more, much more, than just drawing or image production. It is used as a repository for information about the building. A fire rating is given to a wall not just so its tag will be correct, it is so anyone using the model, from fellow designers, other engineers, and contractors, can tell instantly from within the model (or export of that model) that the wall is fire rated.
And because it contains this information the model can be used for checking. Fire rated walls and fire rated doors can be colour coded to check fire compartmentation and that fire walls have corresponding fire rated doors.
If your authoring software can’t do these things then it is not BIM capable. Not all software that do 3D modelling is BIM capable. A BIM add-on to a CAD (whether 2D or 3D) program is unlikely to be BIM capable to any degree of sophistication. Also it can be difficult to get users to model BIM if they have the opportunity to just draw. Don’t waste your time on these softwares.
There is nothing particularly unusual about a BIM software road map. If you use proper BIM software the way it was designed to be used the result will be a good quality BIM model suitable for others to use. Indeed you can do no more than this. We are not software engineers, none of us should be expected to delve into the innards of our software to get a particular result. If that is a requirement it is beyond the scope of design professionals and should be paid for, so someone else can do it.
PEOPLE
I said above any BIM road map begins with software. Not entirely true. First you need the people in place to make the road map and to oversee the journey. No journey is going to happen by itself. Just buying software and making it available is no different from dumping a whole lot of unicycles in the office and expecting people (who?) to ride them (how?) to get somewhere (where?).
First there needs to be someone on the executive team responsible for making it happen. Just reporting to senior management on progress will not work, someone senior has to actively push it.
There needs to be an expert responsible for implementation, usually a BIM Manager.
Project teams need to be restructured.
Every project must have a Model Manager responsible for the well being of project models.
Team responsibility must be adjusted. Individuals must be made responsible for the totality of parts of the building, each being responsible for managing the drawings and schedules their part of the building requires. For example the facade; from window including elevations, details, material schedules, Interiors; walls, including wall types, doors, door schedules.
To assist on-going implementation there should be a component (called Families in Revit) manager responsible for creation and management of component libraries.
And finally there should be a system of “experts”, people who gain expertise in particular aspects of the software and/or BIM processes. Like a stair expert, railing expert, wall expert, etc.
But perhaps the most important issue to do with people is a cultural change across the organisation. The acknowledgement that the task at hand is no longer to produce drawings, pictures or standalone schedules, but to produce a virtual model of a real building. This is why project teams need to be restructured.
Non-users of the software must also change their approach. Rather than asking for a particular drawing or set of drawings, senior architects and engineers should be asking for information about a particular part of the building. If they are seeking to validate or check something ask for that information. Traditional drawings may not be the most efficient way to present it. In the fire rating example above a coloured code set of 3D views will provide more digestible information than a black and white plan with wall tags. Quicker to produce and less tedious to check.
COMMUNICATIONS STRATEGY
After defining who will do what the next milestone is to set a communication strategy. There is no point going on this journey alone, the whole organisation has to come along as well. And the strategy must ensure stragglers don’t get left behind. After all, not everyone wants to move forward.
A communication strategy may tie in with existing processes, so can vary from office to office. But as a minimum there needs to be:
- In-house BIM Software Manual
- Regular Training (at least initially)
- Regular Seminars (where ‘experts’ can shine)
A regular newletter to keep everyone informed, and hopefully interested, can also be added to the list.
BIM Software Manual
The BIM Software Manual must be instantly accessible to everyone, and be searchable. It must be easily updated and added to, and allow users to comment.
The only thing I know of that fits this criteria is an on-line wiki. Word documents printed to PDF are not even close, even if those PDF pages are added to the office intranet. I once worked in an office where the original word file for the BIM manual had been lost, making it really, really, hard to update.
Creating a wiki these days is trivial. It can be done with any of the many web site creation services available. You can lock it down with passwords, or keep it in-house by creating it on your own servers. WordPress.org is a free version that can be installed on your office’s servers. I’ve installed WordPress many times, it is not hard or time consuming. You can probably use a Sharepoint Intranet (don’t use it to ‘share’ word documents as a manual though) if you already have it, although the last time I tried that it was so time consuming I gave up. Maybe it has improved.
If you can’t, or have trouble, getting official permission set up a demonstration wiki on a free web creation service, like WordPress.com, or free hosting service with a wordpress.org install. Just make sure you use one that can export the site (i.e. not Google Sites)
Because a wiki is interactive you don’t have to wait until you have all the information available before setting it up. Just set up it’s headings and progressively fill in the information, in any order. If you already have a CAD manual you might have a whole lot of drafting standards you can immediately put in it. And don’t worry about getting headings right, you can easily change them later on, including their order. It is not like you will have to cut and paste enormous amounts of text within a word document.
What ever you do don’t fall into the trap of “we’ll do when we finished the manual”. The reality is the manual will NEVER be finished. As the office becomes better at using the software processes should be changed, things that don’t work should be revised, and then there is the fact software changes with every new version. You will never get on top of it so just accept that and work with it.
The type of headings you might start with could include:
PROTOCOLS
Protocols for managing Revit
STANDARDS
In-house standards, including naming, to follow when using Revit.
PRACTICE
Explanations and procedures for workflows
GUIDELINES
Guidelines for best practice.
TIPS and TRICKS
Tips and tricks for using Revit.
ASSISTANCE & HELP
Sources of help, specific problems, bugs, and their solutions.
Regular Training
You can’t expect people to be able to use software without some training. Even if they know how to use the software new people will need to be introduced to the way you do things.
For new learners short bursts of training of no more than 4 hours are better than a whole day, or multiple day long sessions. Also no more than 5 to 6 people at a time, any more and some will get left behind. For more experienced users keep sessions to an hour and on specific topics. They will be busy and won’t be able to spare more time than that.
Regular Seminars
Set up regular seminars, with the emphasis on regular so people can plan to attend them. Lunch times are best as you are more likely to get people attending. Provide lunch and even those not that interested will attend.
Newletters or Regular Posts
I have found a good way to keep everyone informed and somewhat interested is a regular email newsletter, or if your organisation uses social media, regular posts. Include things to do with the software and its use, titbits about general IT, BIM and your industry.
So that is the soft start, setting up the framework to make it happen. Now for the hard information you will need.
FOLDERS & FILES
Anything involving computer files requires some way of organising them. Unless you are a brand new start up or moving from paper straight to BIM you will already have a way of organising computer files. But it is worth at least reconsidering the way you organise files to suit your BIM software.
I find many design offices have electronic filing systems based on archival storage, usually following the paper filing system that predated computers. But we also need somewhere to store files currently being worked on – Work in Progress (WIP).
The requirements for WIP is different from archival storage. People are opening, saving and closing files much more often; linking of files makes the location of file and paths critical; long folder and file names become a productivity hindrance.
So it is worth developing a folder structure exclusively for WIP that is not embedded within the archival system.
Another missing part of most computer filing systems is that there is no place to keep current documents. For drawings that is the equivalent of the old project drawing stick set. As drawings change so quickly now it is impractical to rely on a printed set of drawings, so there should be a place in the filing system where the latest drawings can be kept for anyone to access.
Of course if you use a document management system (like Newforma, Aconex, BIM 360, etc.) you will have that functionality and not need it in your files system.
It is also worth putting some thought in to file naming. Because of the way BIM authoring software files are shared and linked together file names can be a help or a hindrance. Overly long file names are a pain for everyone, as are highly codified names. One thing worth putting in Revit file names is the version, but keep it short: R18 somewhere in the name is quite adequate.
NAMING STANDARDS
Unlike CAD and 3D drawing programs BIM software have a lot of things that are named by users. When I say a lot, I’m not exaggerating. Here is a list from Revit 2017:
This list excludes naming and numbering required for normal document production – Sheet numbers, Sheet titles, codes for tags, etc. So you can’t just take your existing CAD manual and “adjust” it.
The important point here is that users should NEVER be in a position where they have to make names up. If everyone is making their own names up with no guidance how an earth can you expect anything other than a massive mess? Where you get things happening like users unable to find what they need (e.g. a wall type) so they create a new one, leading to multiple components for the same thing.
It is critically important that every single thing that can be named has guidance on how it should be named, and that guidance has to be articulated as a standard that must be followed.
But that doesn’t mean naming has to be rigidly defined. Defining a naming structure with guidelines will have more chance of being followed than a fixed list that has to be referred to, or worse, memorised. The same guidelines can even be used for multiple items.
As long as the guidelines are not too ambiguous. I have seen a manual where the naming guideline for components was a prefix that described what it was, typically its category. But it didn’t have a list of standard prefixes so I found casework family names prefixed with Case_, Casework_, Casement_, Join_, Joinery_ & Joineries_. Not very helpful!
I’ve written about naming before (The Nature of Naming), but I’ll repeat the important points here.
- Be literal – names should be understandable to anyone not working on the project
(pb13, not P01 or L13) - Keep name lengths to the minimum necessary to still be understandable, abbreviate and truncate where possible
- Avoid padding
(Line-Xhatch not Line – Xhatch; pb13/stud92/pb13 not pb 13 / stud 92 / pb 13) - Use Major-Medius-Minor name schema
(Glass Clear not Clear Glass) - Define structure but be flexible on specifics
(plasterboard13, plasterbd13 or pb13 are all acceptable) - Consider how names will list alphabetically
(Light, Medium, Wide not Light, Heavy, Medium) - Use CAPITALS purposefully
(e.g. use capitals for views on sheets, sentence for all others; capitals for fixed prefixes.)
There are a few of other points to consider when naming in BIM software.
Names are your purposes only, it is NOT project data:
Names are what I call HUIDs – Human Understandable IDentifiers. They are for the humans creating the model, for everyone else there is the data within objects for them to use.
This means that names must be human understandable. Highly codified naming systems (like using Omniclass numbers or IFC names) defeats the purpose of having names in the first place. It is also pointless because that data can be within the object anyway.
This is why I refuse to follow any outside demand to use their naming scheme, typically from contractors, but also by COBie. Happy to provide a parameter for their name, but names in our software are for our purposes only.
Name what something IS, or name for what it is FOR:
When deciding on a name it seems easier to name it by what it is, (Text 2.5, Solid Grey, Line 05, pb13/stud64/pb13). This is a carry over from hand drafting which found its way into CAD. You didn’t draw using a wall, you used a 0.5 pen. But in BIM software you do “draw” with a wall, and not only that you can name it what you want.
So in BIM software if you want you can name things after what they are for. Instead of naming a wall type pb13/stud64/pb13 you can name it Internal Stud-Typical.
There are a few advantages to doing this. It is easier for users to identify what to use; there is less likely to be duplicates for the same purpose; and it is easier to change later.
Say you have two people working in the same project, one thinks internal walls need insulation, the other doesn’t. One creates pb13/stud64,insul50/pb13 the other pb13/stud64/pb13. The project becomes a mixture of the two types. If the name was Internal Stud-Typical from the start they would have had to fight it out (or actually do some research instead of guessing!) before it got to that stage. And even if they made the wrong decision no big deal. As all internal walls are the same type so just the properties of that type need to be changed. If they each used their own walls some-one would have to find all instances of the wrong walls and changing them to the correct type.
This follows through to annotation objects. Name a Filled Region Clearance-Disability instead of Xhatch Red and it is trivial to change all instances of filled regions used to show disability clearances to something else, just change the parameter values of Clearance-Disability. It also makes it possible to create view filters that only hide disability clearances. To make a change if you don’t do this every occurrence across all views have to be found and manually changed, and forget about using a view filter.
That said it can be difficult to enforce naming strictly based on what something is used for. It can also get messy when projects become complex, particularly during documentation. Indeed some projects end up without a “typical” internal wall at all!
Of course it is possible to have a hybrid – usage and content: INTstud_pb13/stud64/pb13. Or one I use during documentation – code and content: W.S01_pb13/stud64/pb13.
Yes, a bit redundant, and yes, more management as the name has to be changed if the content changes. But remember names are HUIDs, they are there to help users do their job. And if a bit of redundancy, or indeed management overhead, helps, then it is perfectly justifiable.
Published Standards
I hear you all saying about now, “Can’t we just use existing published standards?” Sure, you can try. Firstly they don’t cover everything that needs naming, secondly they have not been created to make your work easier, but so it is easier for others. Remember that names are for your users, not for others, so what is the point following a standard created for some-one else?
That said it may be worth reviewing standards and using the bits that are useful to you, or altering it to make it useful to you.
For those interested have a look at bimblog.house as Dan tries to force his house to follow published BIM standards.
PARAMETERS
Besides all the things built-in to Revit that have to be named, there are things that users create that must be named, such as parameters.
Parameters are used to drive parametric behaviour (Width in a door family), for tagging, (Mark and Type Mark), and scheduling (Width, Mark, Type Mark).
There are Family parameters that are created to work within a family only (typically for parametric behaviour), and Shared Parameters which work across all families and projects (only Shared Parameters can appear in tags).
Not all parameters require naming, like System Parameters which are built-in Revit parameters that behave like Shared Parameters but can not be renamed.
Besides naming there are other things that users require guidance on:
- Parameters have a data type: Integer, Number, Length, Material, etc.
- Parameters are grouped under built-in Parameter Types: Dimensions, Materials, Construction, etc.
- Parameters can be Type driven (different types of things vary), or Instance driven (each item can vary even if the same type).
Managing parameters is beyond the scope of this post, but things that should be considered are:
- Define what built-in parameters are to be used for.
For example Type Mark is tag code, Type Comment is drawing note, Description is schedule description. - Create naming standards for parameter names.
Major-Medius-Minor using CamelCase is popular. Don’t use math symbols in names (like dashes or slashes). - Create a different naming standard for Shared Parameters.
Shared Parameters are seen by everyone who gets the model. It is polite to identify it as your parameter. - Guidance of parameter type heading to be used.
e.g. Dimensions for gross parametric changes, Model Properties for changes to parts, Visibility for changes to object, Graphic for changes to representation. - Guidance on data type.
e.g. dimensions must be Length, array values Integers, when Text may or may not be used. - Guidance on when to use Type or Instance.
e.g. Objects that are schedule by type should use Type parameters. - Guidance on Project Parameters
When should be used, when should instance parameter vary between groups. - Methods for managing Shared Parameters.
Protocols for adding new parameters, location of Shared Parameter file, etc. - Establish standard parameters that are required for schedules.
Review your standards schedules and document which parameters are required to create them.
PARAMETER VALUES
As mentioned above parameters hold values used in tags and schedules. To improve accuracy, efficiency and readability of tags and schedules it is worth revisiting the tag type codes you currently use and how your schedules are structured. Methods used in manually created schedules may be cumbersome in Revit, and there may be things you can now do that were too difficult to do manually.
For example paragraphs of descriptive text are difficult to manage in Revit schedules. Data should be kept concise as possible and separated in to multiple parameters. This is not a quirk of Revit, it is a requirement for BIM. Computers don’t understand descriptive sentences, they only understand precise data. Including the manufacturer, model, colour and supplier address all in one sentence, as one piece of data, will prevent anyone using the advantages BIM brings.
One of the things I find in manual schedules is that there is often duplicates, or close duplicates, in codes within different schedules. For example CO used; as concrete wall; to identify columns; and as prefix for material colours (CO01). Or WB for; masonry block wall; whiteboard; and weatherboard.
It is worth creating a unified list of standard codes for everything to prevent this happening. Now, I realise this is not actually possible, no-one can predict every code that may possibly be used in to the future. But it is possible to develop a naming system that divides up codes so duplicates are less likely.
I use a system that uses a category prefix. The examples above become W.CO, C.CO and M.CO01. W.WB, I.WB and M.WB. (I wouldn’t actually use these codes, but you get the idea).
Another thing I commonly find is a confusion between what is a material (e.g. plasterboard) and what is a construction system (e.g. plasterboard stud wall), as when both the material and wall type are tagged PB in a project. But they are clearly different, and Revit makes it explicit because walls and materials are completely separate things.
To avoid confusion I use a totally different naming schema for materials than construction types (not a prefix as my example above). I also make sure material tags are graphically different from type tags.
LOADABLE COMPONENTS
Components, called Families in Revit, are separate files that are loaded into a project file, like Casework, Doors, Plumbing Fixtures, Windows etc.
Besides guidelines for naming the files there should be guidelines on how they are to be constructed, and how parameters are to be used in them. Families are used by multiple people, so must not be overly complex to use. They also appear in schedules which means the data between families must be consistent.
Creating Families requires quite different skills to working in a project model, which is why I suggested above that a Family Manager be appointed. In fact I would go further and say that not everyone should be expected to create families. There should be a dedicated office family creator, or an elite of family authors (probably more realistic).
Even if handled by experts it is still worth documenting guidelines for creating families. However I see that as a separate Family Creation and Management manual. Of course it should still exist within the office BIM Software wiki, still be searchable, still be commentable. But it talks to a higher skill level than the rest of the office manual.
There are a few standards available on Family creation. The AEC (UK) Revit Standard and ANZRS for example. If you involved in mechanical engineering you should definitely be referring to BIM-MEP [aus].
But as I said above I wouldn’t just absorb them whole, take from them what will work for you.
PRINTING & DOCUMENT CONTROL
To me printing and document control can be a massive time waster. It often takes hours to produce a print set with transmittal, all because there is no work process in place to automate what is an extremely simple task.
So it is really important to have a standard procedure in place for preparing drawings for issue, printing, and transmittal creation. One that any idiot can follow.
I don’t know about other BIM softwares but Revit is crap at managing printing and document control (it doesn’t natively print to PDF, nor can it add revisions numbers to file names when printing). The only realistic solution is a third party add-in to do it for you.
So pick one, make sure everyone has access to it, then document the workflow using your choice of third party software.
PROJECT MODEL PROTOCOLS AND GUIDELINES
Another time waster is reinventing the wheel every time something has to be done. And then there are things in Revit that if not done the right way at the beginning are either impossible to fix (like physically move a model to new coordinates) or difficult and confusing (like unravelling how groups have been set up), or just time consuming (like moving things between worksets).
So it pays to document (and then enforce) best practice workflows, protocols and guidelines for as many things you can think of. As a start I suggest the following:
- Project set up:
Project Base Point, method to set Survey Point, CAD surveys etc. - Managing Linked files:
When to use linked files, what they contain, which files which sheets live in, etc. - Worksets:
Building breakup, which to have closed on loading, etc. - Phases & Phase filters:
What to use phases for, filters to use, Graphic overrides, etc. - View protocols:
When to use what type of view, managing working, management, temporary views. - Category use:
When to use what categories - Group Protocols:
When to use groups, groups and worksets, mirroring groups. - Options:
When to use, when to remove. - Reference Planes:
when to use, how to manage
Keep in mind this will be an unending task. Best practice is something that evolves, and should be constantly challenged. Comments can be valuable here if you encourage users to pitch in with their views (aka bitch and complain) when things don’t work, or could work better. Just don’t take it personally.
BEST MODELLING PRACTICE
It is always useful to have a model constructed as best it can be. This section is where you can set out how to model well, and by extension modelling expectations. Some of the things you might start with:
- Degree of Detail:
e.g. only model what is visible at 1:50. - Simplify – diagram rather than realistic representation:
e.g. use model lines for joints and casework doors & drawers - Hosting:
on Levels or Reference Planes not object faces - Best Practice for all system components:
Walls, Stairs, Railings, etc.
Like Project Model Protocols & Guidelines this section will be forever a work in progress.
STANDARDISING WORKFLOWS & AUTOMATION
Once naming, protocols and guidelines are in place it becomes possible to define whole workflows – what is the best process for getting particular tasks done. And once you know what a workflow involves it is possible to automate all, or at least some of it.
This is when you start reaping the benefits of BIM.
Workflows can involve model checking; for compliance with your manual; for checking completeness and accuracy of the model. Like the fire rating check mentioned above.
They can also involve tasks usually done manually, such as automating room numbering; door numbering; sheet and view creation; management tasks like renaming views.
But you can’t do any of this if your models are not set up in a known and consistent manner, if you haven’t got to your destination, the end of your road map.
Of course the end of your road map is not the end of your trip, you will continue to travel back and forth over that road. Those workflows and automations that are now possible need to be integrated into your BIM Software manual, replacing the old methods.
Indeed this Revit road map is not the whole journey, it only gets you an airport, the beginning of your next adventure that will take you to places you have never seen, or imagined. The journey to true and pure BIM.
The post Use a Revit Road Map to get to BIM appeared first on ConvertBIM.
