IT Managers: How not to support BIM

During the early stages of a large infrastructure project I was involved in circa 2014, it was decided to deploy Revit Server to support the team of 50+ architects and engineers developing the models for the project. As the company’s offices were split between 2 buildings in the same location, a Revit Server host was located in the main server room in the head office while an accelerator was deployed in the main project office.

This was necessary as there were teams working on the models located in both offices, and the trunk line connecting the two was only 100Mbps, which doesn’t support the traffic that would be flowing on the project, and corrupt Revit files would have been a huge risk. An order was placed to upgrade the trunk line to 1Gbps, but it would take a couple of months so the Revit server solution was essential.

Just getting approval for Revit Server was blocked by Global IT as they favoured the use of ProjectWise that was being rolled out across the business, and they tried to convince us that splitting the models into tiny worksets which individuals could check in and out of ProjectWise would be the best solution. BIM Managers from 3 countries were flown to the UK to be browbeaten into accepting this disastrous workflow, they even brought in one half of the team that came up with the BIM Wedge (it was his idea) to argue with us that using ProjectWise like this was a great idea. The reality, as ever, was that politics were at work and several of the IT bods had hung their careers on getting ProjectWise enforced across the company, and they strongly asserted their authority to stop us from using Revit Server, that they considered a threat to their positions as technical leaders.

Which one do you think it was?

On returning back to the other side of the world, I pleaded our case for Revit Server with the PM, and he escalated up to the regional CEO, who told the Global CEO in no uncertain terms that we were having Revit Server installed, whether the IT goons agreed or not. We won.

Anyway, after a few months of project operations, with multiple models being worked on by the team, we arrived one morning and nobody could access the models, the Revit Accelerator wasn’t responding. The local IT guys, who were not the sharpest bunch reported that there had been a power failure in the server room at the project office, and our server had abruptly stopped, corrupting all the files on the server. “What about the UPS?” I asked the IT guy, he said it had done its job and kept the server running for an extra 30 minutes. “And you were not able to access the server and shut it down remotely after getting the alert from the UPS?” I asked. “Well no, we bought cheap UPSs which didn’t send a power failure notification to the sysadmin”.

Yes Colin, they really are that dumb

This was bad enough, but the next cock up was a classic. The Revit Server installation was on a dedicated PC, and during routine checks the IT guys found that the hard drive was getting full, so had a look at the file system and deleted the folder with the most data, our Revit Server model store… It was a cock up of epic proportions, thankfully we were able to restore the models from local copies on people’s hard drives, otherwise we would have been screwed as we later found out they were not routinely backing up the server.

A lesson learnt, don’t trust IT people to do their job, they often don’t.

Autodesk are taking the piss

One of the most frustrating things about working with BIM tools is how pathetically bad they are, especially tools from Autodesk. Take Revit for example, it was the love child of an old, but smart, for its time, architectural tool called Pro Reflex which had its roots in the 1980s, and parametric mechanical CAD with its constraints and relationships. Its developers maintain that there is no Pro Reflex code in Revit, despite taking the source code with them when they left PTC to establish the Charles River Software, later renamed Revit Technology Corporation.

The guy who sold Pro Reflex to PTC, and therefore knows what he’s talking about, disputes the Revit developers’ claim that no code carried over into Revit, and has documented proof that there are definitely traces of 1980’s Pro Reflex code and design in Autodesk’s flagship BIM tool.

Whatever the merits of both of these claims, the fact is that as a parametric mechanical CAD tool, it is primitive and slow when compared to the modern ACIS 3D kernel from Spatial or Siemens’ Parasolid engine. And as an architectural tool, it does not allow architects to develop the buildings they want to design without resorting to developing special tools to make Revit do what they have asked Autodesk to make it do, but they have refused to spend any money on it. This, and price gouging on licenses, led to the Letter to Autodesk from prominent UK architects demanding action from Andrew Anagnost, Autodesk’s CEO, and covered in detail by Martyn Day in AEC Magazine. Things have got so bad that HOK, who are a Revit house and BIM pioneers, abandoned their Enterprise Agreement with Autodesk and are evaluating alternatives to replace Revit.

Those of us that work in large firms know how hard Autodesk are squeezing the balls of their EBA customers, the price of a usage token has risen over 70% in the past 3 years to more than 1.10 USD (Revit is 6 tokens a day), which has focussed the minds of CFOs and COOs in the tier 1 companies, many of which are formulating strategies to teach Autodesk a lesson. Autodesk University meetings will be very frosty this year.

Navisworks is another Autodesk product not developed in-house, but by a company in Sheffield, UK called Lightworks, that developed Navisworks to allow 3D models from multiple incompatible vendors to be combined in a single application. It was acquired by Autodesk in 2007, and has been a cash-cow ever since, receiving minimal updates and new features. Another example of Autodesk taking the piss. iConstruct wouldn’t exist if they weren’t taking the piss out of their customers, and remember that Navisworks Manage was one of the most expensive tools they sold.

But my biggest beef with Autodesk is that they have all these tools and products, and rather than making sure that they are able to be used collaboratively as a priority, few products are able to be used together except on a very basic and limited way. Revit’s monumentally stupid coordinates system for example is the cause or more lost unproductive hours than just about any feature on any piece of professional software.

Revit’s coordinate system will take it’s toll on almost every project, no matter how well you craft the execution plan or provide templates and strict instructions on how to link models together. On a recent project, the architect created his initial model, from which all other models in multiple applications (Revit, Plant3D, Civil3D and Bentley tools) took reference for the location of the model. A couple of months into the project, the architect decided to lower his his model by roughly 300m as they fucked up the original coordinates. As a consequence, chaos ensued and many many manhours were spent accommodating the fuckup by the architect, in some apps this meant starting again from scratch.

Autodesk’s cloud BIM collaboration platform is not much better. Trying to get models uploaded has brought document controllers to tears on one project, and the latest model collaboration integration with Navisworks promises much but doesn’t deliver. Want to collaborate models from other applications than Revit, sure they said, you can use IFC. What they don’t tell you upfront, is that it will only accept IFC models generated from 4 applications, and 2 of them are Revit, and MagiCAD for Revit.

Want to link in a Plant3D reference into Revit? It’s a horrible kludge of a process. Link an IFC model from Bentley Open Buildings into Revit? Not possible. Navisworks into Revit? Useless. Open a Revit model in Formit? Not a chance. Infraworks? Inventor? 3DS Max?

Autodesk is a $3+ Billion company that acts like a snake oil salesman, peddling tools that promise much but deliver little in the way of value of compatibility. It will soon discover how much is customers hate them.

Tools of Dubious Productivity

So when you’re against the clock working to complete a task, how much of your time should be spent massaging the ego of a recalcitrant software package? How much should the average user need to know about stability, memory leaks and the like? Looking back on it, a very significant portion of an operator’s time is spent corralling the code in a particular direction, working with the various foibles and “features”, well aware that autosave is not always there to save you, erm, automatically. This is totally off the top of my head, but I reckon that a good 20-50% of your time working on any given “productivity tool” is actually spent working within the limitations and boundaries set out by a Russian programmer called Petr. Or Vlad. Whilst my claim is no more accurate than a certain outgoing president’s claims of electoral fraud, unlike electoral fraud a loss in user productivity is really important. This is largely because large organisations like to make decisions based upon perceived percentages of productivity gain, versus sticking with existing legacy solutions, often sold to them by some vendor’s overzealous customer relations managers. Bold improvements in productivity are often trumpeted on marketing bumf but seldom is it mentioned that a certain proportion of that percentage improvement will be lost to “fucking about whilst the little beachball thing spins around”. Go to any busy design studio tomorrow and you can guarantee that at least one user has popped off to take a dump instead of sitting watching a percentage bar crawl across the screen.

To the nearest zillion, how many of these do you think Autodesk receive every quarter, filled with expletives?

I would be very interested to know what the actual percentage productivity gain there is from, say Revit 20xx, versus all the time lost to discovering new and wonderful bugs in this the latest iteration. Rather than always rushing to regurgitate the latest juicy morsels to the impatient hungry chicks, why not slow it down a bit? Mummy and daddy bird could eat together and stop off at the shops on the way home to pick something up for the kids. They could even get some groceries in and prepare something fresh using the cookery book by that fashionable celebrity chef when they get home. Exactly how this applies in the context of software development I’m not sure, but the point is that software development is so frenetic that there is barely a window of stability long enough when everything stops moving around for anyone to measure whether all these new, whizzy patches and add-ins are really helping as much as the vendors claim.

Now of course the image of a garden bird in chefs whites presenting Jamie Oliver style to mums wanting to improve their kitchen repertoire, is absurd. But then they were saying that about a Donald Trump presidency, and look what happened to that? Slow down the product cycle, I say, and aim to provide a competent core product that suits the majority of day to day users, instead of chasing some BIM panacea that so far has largely failed to materialise. Then, the true productivity gains can be gauged over a longer term, in a stable and reliable way, without all the bluster of the bestest and latest update muddying the waters. Also, I like the idea of little birdy chefs.

The Detail is in the Devil

Rule 1, on page 1 of the book of war, is: “Do not march on Moscow”. Various people have tried it, Napoleon and Hitler, and it is no good. That is the first rule. I do not know whether your Lordships will know Rule 2 of war. It is: “Do not go fighting with your land armies in China”. It is a vast country, with no clearly defined objectives.

Field Marshal Bernard Law Montgomery, House of Lords, 30 May 1962

Someone should come up with a similar quotation for all the BIM Lords out there, who battle vainly, usually on a daily basis, with superiors who insist on committing the equivalent BIM blunders as marching on Moscow or fighting with land armies in China.

One such BIM blunder is of the over-promise-and-under-deliver type. It is all too common for clients unfamiliar with the nitty gritty of BIM to believe the hype and think that just “because BIM” they will have a beautifully resolved and fully coordinated design. That “because computers” the design solutions presented to them will be of the highest calibre, unique, beautiful and hopefully award winning to boot. Simply put, that a blind faith in technology is the answer and will somehow overcome all the obstacles that still exist, and will continue to do so since nothing else has materially changed apart from using some fancy new software, is sure to disappoint. For example, the following question is taken from a masters level paper on algorithmic graphical environments:

Remember: resistance IS NOT futile…

The answer, in case you did not know it, has been helpfully highlighted in red. The blue grammar wiggle worms, although not deliberate, are actually helping to literally underline the pertinent points; that difficulty provides a clue and that maybe the problem did not exist in the first place. Furthermore, as item d) alludes to, machines are certainly not perfect because the humans designing them are not perfect. Flawless repetition should not be mistaken for perfection; repeating a mistake consistently one thousand times is still a mistake times one thousand! Confused? Ok, time for an analogy then.

The African Shoe Salesmen

Two friends, who happen to be shoe salesmen, go on holiday to a small African nation. One day they are being shown a local area by their tour guide when the first shoe salesmen suddenly remarks to the other, “We should open a shop here immediately! Think of the sales! Everyone has bare feet!” to which the second shoe salesmen says with a wry smile, “Don’t be foolish. We wouldn’t sell a thing. Nobody here wears shoes…”

What’s that? Still confused, you say? Not a clue what I’m gibbering on about? *deep breath* Fine. I’ll make it as simple as possible for you then.

Computers should be used for the tools they are. No more, no less. They should be used to assist where humans are weak (repetition, consistency) but not so much where humans are strong (creativity, originality). There is no magic. No secret sauce. There is input, there is output. The use of computers and fancy software, like Revit and Dynamo, is not in and of itself the solution to all our cost and productivity woes. In some ways the use of such tools is solving a problem that did not exist. Just like the shoe salesmen. It is adding complexity where none previously resided.

However, in just the same way that the internet has not entirely replaced the need for libraries, it has made researching and finding sources of knowledge (like this fine blog, for example) so much easier. The playing field has been levelled and opened right out. But public libraries are no less a source of knowledge than they ever were before. The contents of the books on the shelves was not suddenly devalued overnight by Sir Tim Berners-Lee.

So back to where this post started. Details and BIM blunders. A huge mistake, often made, is to somehow expect software to be the answer and for it to fix your difficult project. However, by adding an additional layer of complexity, I would argue that difficulty will only increase, costs are only likely to creep up further, and quality and timeliness will stubbornly refuse to improve. What it leads to are fancy shapes and fancy geometry but not necessarily better outcomes.

How to Avoid Fighting With Your Land Armies in China

The answer is, of course, to make information management central to all your processes. BIM is just a database and the same level of care and attention to detail should be applied to every input, just as it would be if you were filling out a phone contacts list. Would you double check the number you just entered and write the correct name and contact information, or would you just multi-copy-paste and assume everything went to plan? You’ve never copy-pasted and had unexpected results, like in, say, Excel? Never accidentally copied erroneous data from a header or footer, or missed a few lines of your target content? Never? Really? You surprise me. Are you a computer? Yes, of course you are, because that is exactly the kind of task that should be automated unless you want mistakes to creep in the nearer you get to 5pm on a Friday afternoon.

How to Polish a Turd

The deadline is fast approaching, I have an angry PM glaring at me and telling me to hurry up, my wife is waiting for me in the restaurant and I’m still not done with my sludge digester. What to do?

“I know”, thought Mr Wong of multinational engineering consultancy beginning with the letter A, “I’ll pop in some illustrations of Japanese paper folding and add dimensions. No one will ever even notice!”

Mr Wong completed his task, left the office and made it to the restaurant on time. Hurrah! A win win championship result of results, surely? Well not quite, and don’t call me Shirley. The story of the deadline beating Mr Wong is pure fiction, but the methodology is not. The assumption here is that someone was in a real hurry and decided to fill up some drawing sheets with any old nonsense. So how do you get your project information out the door on time, every time? How do you make a silk purse out of a sow’s ear? How do you polish a turd?

The answer to all your problems, if you are not aware, is folding. Paper folding, to be precise. In fact, to be even more precise, lots and lots of dimensioned origami birds on a drawing sheet. Alles klar, as they say in Deutschland? All right? Well, you may as well be in Germany or anywhere else for that matter, because it is not only paper that is being folded but the fabric of space and time itself. Or at least that was how my head felt when I first witnessed the madness of A1 drawing sheets, all properly entitled and set up, checked and signed by the PM, but with nothing shown but origami paper cranes. Howsaboutthatthen?

There were several different paper crane “designs”
Birdy go tweet tweet
A typical unrolled polished turd
Only design intent, not something really accurate? Phew! Thank goodness for that.

So, just like the origami solution, it turns out that the Japanese had the answer all along; dorodango. The same technique applied to night soil has the same effect.

Ye Olde BIM

“In days of old, when knights were bold, and toilets weren’t invented, they dug a hole and did a roll and went away contented”

BIM Weasel, May 2020
Sorry, I fell asleep on the bog. Did I miss something?

Specifying BIM workstations is, for want of a better term, a movable feast. Constantly changing software offerings from vendors, myriad file formats, inevitable interoperability issues, a plethora of hardware choices; all this before you even enter into the human operator realm, being all squishy and organic and capable of errors and glitches completely lacking in consistency. And we haven’t even mentioned budget yet…

Given all these potential complications, the sensible choice would be to do some basic research to establish the most common hardware configurations from leading workstation suppliers, keep abreast of computer infrastructure industry developments, and trace a line back from the “bleeding edge” to a more affordable place on the graph. Essentially, you want your best “bang for buck” coupled with an element of future proofing. Anything too fresh is untested and likely to cost you an arm and a leg, whilst anything too old is likely to run into compatibility and support issues before long. You want your new machines to survive at least one project before upgrading, right? Well, you’d think so.

Apparently there is another train of thought out there that I have chosen to call “Ye Olde BIM” in that it has more of a medieval approach to technology adoption. After all, if it ain’t broke, don’t fix it, yeah? Yeah. Sure thing my liege.

Excerpt of BIM scope for a project in the month of May in the year of our Lord 2020. Yes. Quite.

The example above is taken from a project tender specification for a development in 2020. The year 2020. Weapon of choice; Autodesk Revit 2011. So for a project that may take a couple of years to complete, it makes absolutely perfect sense to specify software and hardware requirements that were looking long in the tooth at least 5 or 6 years ago. But surely by now all those bugs would have been fixed, right? Well, yes but actually no. That just isn’t how the industry operates.

Yeah, but no, but yeah, but…

It is only the latest iterations that get the latest productivity enhancements incorporated into them, along with introducing all the new and exciting bugs, as the product moves forward. Older versions are left behind and eventually no longer supported. Cast adrift, as it were. The development of complex software, like Autodesk Revit, needs to be carried along like a boat on a river of license fees. Actually more of an ocean of license fees. Software development is expensive! To extend the analogy to the example above, specifying 2011 software for a project starting in 2020 is the equivalent of clinging on to a fancy wardrobe that fell overboard during a storm en route and assuming that you’ll still get to your intended destination in a timely manner. Sure, you can do that, I suppose, and you’ll probably reach the shore eventually, but don’t expect to have quite the same experience as the paying passengers in comfortable cabins, being served fine wine by Autodesk waiters, leaving you behind in their wake…

Coming up in the next thrilling instalment of BIM Bollocks; how to generate complex geometry with the use of just an abacus. I jest of course… Or do I?

BIM skills 101: AtTeNtIoN tO dEtAiL

Email #1

From: BIM Weasel
Sent: Friday, 24 April
To: Important BIM Project Manager (IBPM)
Cc: Gary
Subject: Monthly report – example

IBPM,

In response to your previous comments on our monthly report, would the attached be more aligned with your expectations? I have copied in Gary to keep him informed.

Regards,

BIM Weasel


Email #2

From: IBPM
Sent: Tuesday, 5 May
To: BIM Weasel
Cc: Gary
Subject: RE: Monthly report – example

Hi BIM Weasel and Gary,

Went through your attached document a couple of times, we are unsure of which previous comments of ours were you referring to.

As the file name suggested, it is a comparison report between two reference projects (Project A and Project B), and appears to be showing:

Quality checking of BIM model (The report says the quality check of the BIM model by comparing it with some other reference projects.) and

Summary of improvement, regarding modelling and drawings generation, the combined model or individual models of different disciplines can be made (mainly those generalized in Section 2, with examples under Section 4 in the report).

Cheers

IBPM


Email #3

From: BIM Weasel
Sent: Tuesday, 5 May
To: IBPM
Cc: Gary
Subject: RE: Monthly report – example

IBPM,

Sorry to give you the run around, but I thought that I made it clear that what I sent was only an EXAMPLE and is actually taken from another project (with sensitive details redacted). Since your previous comments majored around your opinion that the monthly report was more of a plan, the point of sending an example was to get your response on the general approach and tone before reconfiguring our monthly report. I think that some parts of our report are still relevant (such as the referencing of monthly meeting minutes, to show the actual issues that were discussed), but the format and content could be rearranged more inline with the example I sent you and Gary.

Bearing in mind the above, is my example more or less aligned with your expectations?

Regards,

BIM Weasel


Email #4

From: IBPM
Sent: Tuesday, 5 May
To: BIM Weasel
Cc: Gary
Subject: RE: Monthly report – example

Hi BIM Weasel and Gary,

Your intention of the example is noted.

Generally, presentation using tables make reporting effectively, easier to track and lives easier for all. Any particulars can then the written and described, and things like meeting notes (sic – such attention to detail here too – BIM Weasel)

I am sure that there are reference samples which George might be able to share with you as references, of course with any sensitive matters should be redacted where necessary. George, please kindly look into this.

Please draft out a table of content for the Monthly Report to get things moving. In terms of the “tone” or “polishing needed” of the report, George should be able to help similar to that of your draft R to C on the BIM Plan.

Please feel free to call and discuss with me on this matter.

Many thanks

IBPM


Email #5

From: BIM Weasel
Sent: Tuesday, 5 May
To: IBPM;
Cc: Gary
Subject: RE: Monthly report – example

Thank you IBPM, Gary,

Just one question; who is George?

Regards,

BIM Weasel

Get me the turds/hour analytics, STAT!

Sometimes you wonder if the people writing project BIM requirements are taking the piss. I can excuse the LOD 600 requirement that was included in an RFP a while back as plain ignorance, or even an affectionate Spinal Tap tribute. But when Toilet Data is included in the list of requirements for future property management in the BMS system, you have to wonder why?

The befuddled BIM hero who sent in this contribution suggested a potential use “I can imagine the top management wanting live dashboards giving them Tph (Turds per hour) metrics, so they can fine tune the thickness of the canteen sandwiches…”

Digital Twins – The new, unwanted buzzword

First there was “Virtual Building“, a Graphisoft trademark they use to differentiate between ArchiCAD and what was referred to as “Flat CAD”, the 2D drafting board analogue from Autodesk, which was launched the same year as the visionary Hungarian BIM tool’s first iteration, Radar CH.

Next there was BIM, Building Information Modelling, coined by Autodesk in their 2002 white paper, attributed to Phil Bernstein.

Software vendors love a hype wave to follow, re-branding their tired old products with the latest buzzword to try and shift more licenses by scaring customers into thinking they will miss the wave and lose out to competitors. “SuperDuperCAD-X, the market leading CAD/Virtual Building/BIM/Level 3/VDC/Digital Engineering/DfMA authoring tool is now leading the way in Digital Twin capability!”

For years they were banging on about BIM will reduce costs by 50% but all that happened was a “BIM Team” was created in the business, and then treated like “drafters”, glorified tracers (if you don’t know what is a tracer, ask one of the old guys in your organisation). As there was zero engagement between the engineering teams and these BIM jockeys, designs being done in 2D, even drawn up in 2D CAD before handing over to the BIM guys to do their stuff. You might as well have thrown money down the toilet.

BIM added costs without benefits. And now there is Digital Twins.

The thing is, we already have digital twins, in scenarios where it makes commercial sense and add value. A digital twin of a building is just bollocks. The cost of setting up and maintaining a digital twin with all the sensors and stuff is significant, and to be honest, you don’t really need a fully detailed BIM model to make use of it. Just some floor plans, PDFs.

The CAD companies promoting Digital Twins will be really pissed when the market decides they don’t need all that BIM modelling bullshit and just need dashboards and databases.

When is a Questionnaire not a Questionnaire?

Consulting for the lazy

Hong Kong’s Construction Industry Council (CIC) are tasked with implementing the government’s BIM initiatives and have employed US bean counter led engineering consultancy AECOM to drive the development of a case requirement study for 3D and BIM Data.

Never one to spend a dollar on a task if they can get someone else to do it, and gain an unfair advantage at the same time, AECOM have basically asked the BIM people invited to make up their own questions, to provide them with valuable data that would allow them to bid for and win future projects more efficiently.

Tell us what you know about BIM, so we can do it better. Example 1

Not content with finding out what you know, they also want to find out what would make their bids more effective for future projects by identifying gaps in the current processes they can exploit and wow the clients with their boundless knowledge and BIM chops.

All your base are belong to us