Being a wizard in Revit and Dynamo and composing Macros and Plugins like BIMozart on steroids is all well and good, but one has got to get paid for that eventually. And to be paid “eventually” one needs to have agreed on that payment beforehand. And let’s be honest, as inspiring and amazing our leaders are – directors aren’t famous for keeping on top of technology, and the documents are getting more and more technical. That is all ok though, because here is great opportunity for an even more collaborative process.

This need for technical involvement in contracts combined with the BIM Standards renewal gave us the inspiration to create a series of blogs starting to tackle the monstrous glossary that comes with contracts and standards for BIM Projects.

For more information on the new standards, please see here.

Very excitingly the PASS 1192 suite of documents created in the UK is being translated in a new international standard – BS EN ISO 19650, the first two parts of which are coming out at the end of this year –

  • BS EN ISO 19650–1 Organization of information about construction works – Information management using building information modelling – Part 1: Concepts and principles
  • BS EN ISO 19650-2 Organization of information about construction works – Information management using building information modelling – Part 2: Delivery phase of assets

So back to the new vocab – if you search you can get really good BIM Dictionaries online. I will let you pick a favourite one yourself. But you can’t just pick up a dictionary and memorise it – it just doesn’t work like this. I am also sure there are many amongst you that will always campaign for the use of plain language. Because of that, what I will be trying to do in this article is defend the need of, let’s call it train language, you know because it’s not plain, and because it can hit you like a train at the beginning. Then we will move on to digestible and accessible chunks of BIM vocabulary every few weeks.

BIM is a new method that has not been previously used and it needs its new language. Experienced professionals often seek the comfort of plain language, because it is intimidating to have to face something like that after you had just spent 10-15 years getting comfortable and confident, and stop trying to call apples… I don’t know – dragon fruit. We should be used to this by now, our industry goes through those shifts quite often – just like everyone wants to call Revit components and functions with AutoCad terms – a personal pet peeve of mine – and before that people wanted to call AutoCad things … I don’t know what was before AutoCad – cave drawings? Sure some things always stick around, that is why we still use a floppy disk as a symbol for “Save”, even though probably most people that have hit “save” across the globe since you started reading this article, have never seen a floppy disk or know what it is. But the fact is there are new concepts around and it is inaccurate to call on them with old words, and what I am doing here is trying to call on some vanity to make you think it is really cool to know all the new lingo.

After this longer than anticipated intro, let’s just ease into it with 3 key and super basic abbreviations:

BIM – Building Information Modelling – we have got to start with this, but if you don’t know what it is, “OMG show me the rock you have been living under” is actually not what I would say to you, because it seems that even though it is on the lips of literally everyone connected in anyway to the industry, often the concept escapes people. BIM is a set of technologies, processes and policies enabling multiple stakeholders to collaboratively design, construct and operate a facility in virtual space. It is a PROCESS. It is the whole shebang – 3D modelling is NOT BIM, specific software that is used in the process in NOT BIM. Yes indeed the full and federated models at the end of the construction process are the heart of a BIM project, but BIM pre and supersedes them. It is Building Information ModelING not ModeL – it is not just the what we make as designers, but how we make it, how we collaborate in the process (or really the fact that we MUST collaborate live) and then how our digital products are used to run a building. In slightly harsher words – if a practice has finally stumbled into purchasing two Revit licences, this does NOT mean they “do BIM”.

EIR – Employer’s Information Requirements. This is fundamental – the definition goes – A document clarifying the employer’s requirements during services’ procurement. Employer’s Information Requirements may include levels of modelling detail, training/competence requirements, ordinance systems, exchange formats or other employer-mandated processes, standards or protocols. Employer’s requirements or specifications for what, when and for whom the data and models are to be produced. What may happen here is, if an employer – client – does not have great understanding of the BIM process they may cover this in sweeping statements and you may end up having to produce large amounts of information, that the employer did not intend you to and doesn’t really need. Worse things may also happen, the contract may require BIM, but you may not even get EIRs at all, or get them half way into stage 3. At this place of BIM adoption in the industry, you may have to chase and beg for those, and even write them yourself. Every Technologist starting work on a BIM project should ask for those and be able to read and understand them.

BEP – BIM Execution Plan – that’s a Russian doll of an abbreviation isn’t it! The BIM Execution Plan is developed by suppliers – typically pre-contract to address the Employer’s Information Requirements (EIR) – and defines how the information modelling aspects of a project will be carried out. A BIM Execution Plan clarifies roles and their responsibilities, standards to be applied and procedures to be followed. A BEP collates/references a number of other documents including the Master Information Delivery Plan (MIDP) and the Project Implementation Plan (PIP) – details on those in BIM Dictionary Part 2. Currently there is a “Pre Contract BEP” which sets out the response to the EIRs, i.e. it is akin to Contractor’s Proposals. There is then a “Post Contract BEP” which sets out the agreed, contracted details of this delivery of the BIM aspects of the project. There is some discussion on some aspects of the BEP, however I would say it is the Technologist’s Holy Grail – it is HOW we do things. Since the BEP is a document that is revised it seems impossible for it to be a contractual document, however there are those in the industry who are working towards making it one.

As written on the face of the promotional T-Shirts we’ve got (together with a ‘TRUST ME, I’M A H4C1<3®’ sign on the back), Forge Rocks indeed! I was able to assert that (see what I did there) after spending a week in one of the Forge Accelerator events, this one held in Barcelona between 11-15 June. First of all, the weather in Barcelona was great at that period and the temperature was just right for a week of intense training. Just to give you an idea of what it was like, here are some photos from the weekend after the training, once that the pressure was off and I could enjoy the beauty of the city.

The Forge training took off on Monday and after a brief introduction from the organizers (hats off to everyone on the team that made the experience so rewarding), we dived straight in. Or should I say – I nose-dived while the rest of the 20 something attendees went on to polish their already great looking applications. See, the thing is that I had no past experience with Forge and even though I knew about its potential and spent a full week trying to deploy the most basic implementation of the Viewer following a tutorial by Augusto Conclaves a year prior to this event, I was pretty much a greenhorn. Thankfully, there is a growing body of step-by-step tutorials that guide you through those initial phases and I was able to accomplish in a couple of hours what took me a week of work before.

Coming to the Accelerator, my plan was to complete a proof-of-concept revolving around a workflow that I’ve discussed with a client. I was able to identify the resources that I used as a starting point fairly quickly (shout-out to Jamie @AfroJme and Philippe @F3lipek), so I finished day 1 writing code till the wee hours with a sense of hopeful enthusiasm. By the end of day 2, this hopefulness was replaced by cold desperation. For those of you thinking of picking up Autodesk Forge – you guys and you girls, you’ll simply need JavaScript. No matter how you spin it, there’s no way you’ll get around the fact that Forge needs js. Now, I love learning computer languages as the next guy and I have a good grasp of C#, Python, HTML, CSS, Processing, but picking JavaScript in 3 days, that was simply too much for my poor brain. It’s a functional language, it’s a front-end language, everything is asynchronous, there are Promises to keep, events to track, functions to nest, it’s just too much. Now I understood why pretty much everyone else in the room was a web-developer in some capacity.

No matter, with a lot of testing, trying, huffing and puffing and a little help from my new friends Roman, from Ukraine (to my right) and Sven, from Germany (to my left) and the ever-vigilant Philippe, I was able to put the final touches of my now working prototype. Day 5 is the presentation day and is the time when everyone is given the opportunity to demonstrate their Forge application. For me, that was probably the most important day of the whole week. The Forge apps I saw that day were nothing short of impressive, and I mean each of them. With a bit of an overlap between some of the teams, probably the two major themes were IoT and CDM.

For me, though, one team shone above the rest – the young guys from Moicon really stood out with their sleek, modern, fully functional application. Although fringe to the AEC industry (their first customer was a Cake factory in Norway) their product was innovative and super smart. One could really see how their customers were gaining value from every aspect of the design. In short, they’ve created a 3D representation of the factory floor that shows all important aspects of the everyday work through objects with associated (real-time) metadata. The objects beep, blink and change color in order to attract attention when needed, you get the gist. We had a chat with Torbjorn Grimstad, Moicon’s manager and visual strategist (as per his business card) and I was impressed by his clarity, foresight, business acumen and practical use of concept like gamification. Cool stuff. Moicon have a stand at Autodesk University in London which is held right now – if you have the chance, go say hi and see their product, you won’t regret it!

I really enjoyed the Forge Accelerator and I think Autodesk Forge has a huge potential that is already being realized by many companies out there. I am eager to present our working prototype very soon and hopefully introduce it to the larger public. Most of all, I enjoyed meeting some amazing people, making some great memories and coining future collaborations. Here are a couple of snippets from those moments.