Born in 1900, in a block of cheese, Bim Weasel has had to struggle from day one. After eating his way out, bursting forth, like some kind of pasteurised Alien alternative, he began trading nuts and seeds before moving on to complex financial derivatives. After making his first million at the tender age of 13 and three quarters, he diversified into commodities. The outbreak of the First World War saw his fortunes rise yet further, as now the owner of copper, bauxite and iron mines in Papua New Guinea and Australia, and rubber plantations in the Dutch East Indies, his holdings shot up in value.
The next decade saw Bim spend his fortune on women and fast cars, whilst the rest he just wasted. By the outbreak of World War Two, Bim was destitute and living as a tinker and shoe repairer in a coastal village in Sulawesi. Despite not being a Dutch national, his love of the colour orange saw him interned by Japanese Imperial forces. He was sentenced to execution and only saved at the last minute by a young Jedi. In gratitude Bim joined the Rebel Alliance and saw action on the forest moon of Endor, frozen Hoth and arid Tatooine.
Upon his return to earth, with laurels upon his brow and feted as a war hero, he wanted nothing more than to return to nature and work the land; a simple agrarian lifestyle, far away from conflict. He kept a low profile and slipped from the public consciousness, his past largely forgotten and his true identity unknown to those few mortals who met him on his occasional forays into urban areas in search of cheap thrills and rice flour.
He may have remained forgotten and unknown, wandering Southeast Asia as a vagabond, had he not overheard a conversation in a bar one night whilst on one of his jaunts into civilisation. A pair of businessmen were talking in hushed tones about a new disruptive force, sweeping all before it and trampling all over norms and customs the world over. No, this was not a US presidential candidate, but an American software developer called Autodesk, and in particular a product called Revit. Intrigued, Bim sought knowledge and found a ready source of pudgy, pallid and poorly dressed men from the damp isles of Britain; a cold and windswept outpost on the extreme fringes of Northern Europe. A destination even the all-conquering Roman legions decided to abandon due to its inhospitable climate, arcane traditions and warm beer. However, it turned out that living in fog and drizzle for three hundred days of the year also accelerated creativity and the ability to generate a seemingly endless number of Microsoft PowerPoint slideshows, as well as memes. Bim immediately felt comfortable in this land of sunlight starved and sexually repressed Gollums, and within a short time he had established himself as a purveyor of some of the finest slideshows, Yammer posts and memes. Bim travelled the world, expounding eager audiences with tales of 15-20% efficiency gains, whilst providing little or no hard evidence. It was like a dream come true for Bim, having felt that he had discovered his true calling! The rise of Bim has since been vertiginous, with almost all nations, states, principalities and fiefdoms seeing the benefits Bim brought, but with one stubborn exception; Hong Kong. Seeing it as almost his divine duty, Bim took it upon himself to conquer that semi-submerged volcanic caldera in the South China Sea. He has been there ever since. Hong Kong still stubbornly refuses to accept Bim, yet still he persists.
Now entering the third decade of his second century of existence, he feels sufficiently knowledgeable to be able to pass on some of his experiences, here in this blog.
Read on, brave adventurer!
It do be like that; you’re just minding your business, doing some stuff, and then suddenly you’re an investigative journalist. Well, that’s exactly what happened to the BIM Weasel recently.
An article popped up on local media regarding a ceiling collapse at Central MTR station. I didn’t think much of it at the time, other than it looked like another reason for the media to beat up the MTR corporation again. Shortly thereafter, and entirely unprompted, the “evidence” just fell into my lap (although in a considerably less exciting way than a train station ceiling).
Sometimes things do fail. Stuff does fall over from time to time. However, it doesn’t look great when a report published 10 years ago would appear to have forewarned against exactly the incident covered by the local press. On this occasion, no one was hurt. Central station can get very busy, and would undoubtedly have been busier were it not for current Covid pandemic conditions. What would the response have been if there was a serious injury, or death?
So the cover page tells you what the report would be about, and when it was published.
So it would appear that proposed remedial measures, listed below, were not followed particularly closely, or possibly at all. Water ingress will lead to corrosion and premature failures. This may manifest itself as bits of subway ceiling falling down…
So the solutions suggested involved some disruption to traffic on Connaught Road, or none at all. The author provided a range of possible responses, including electro osmosis primarily to prevent rebar corrosion. If structural reinforcement corrodes too much, that’s when things fall down. Particularly ceilings and that kind of thing…
So, in short, the recommendations were to get it sorted before it gets worse and something lands on someone’s head. Ten years is plenty of time for water ingress to go to work on the embedded reinforcement. More to come, or will the MTRC finally address the issue?
Caveat: it is assumed that the problems highlighted in the report have not been fully addressed, although it is not know for certain. To the author’s knowledge, there has been no major renovation work of the type described in some of the recommendations (such as digging up Connaught Road to inject grout) in the past 10 years.
It is true that BIM is a niche filled to the brim with acronyms. In rather an overuse of the things, it is often necessary to include an entire appendix section just to cover them all. Wondering what your MIDP has to do with a RACI, or unsure whether you need LOD or LOIN? There are so many acronyms in use, that it is inevitable that you will get one or two instances of disagreement about what it really stands for. Level of Development, or Level of Detail? Well one meaning that “everyone” has been in agreement with for some time is that BIM = Building Information Modelling. Apart from the odd amusing misuse, such as BIM = Building In Mistakes, or Budget Is Massive, there is a consensus of opinion that spans industry disciplines, geographical regions, cultures and languages. At least, to my knowledge, it has been that way until now.
I have recently been receiving some exciting emails. I could hardly contain myself when, one Monday morning, I should be informed that “our evaluation panel has shortlisted to feature BIM Weasel BIM Consulting (BWBC because acronyms rule of course) as one of the Top 10 BIM Service Companies in APAC”. Finally, our hard work had been recognised and we can make a show of our undisputed BIM chops, or so I thought. Of course, if something looks too good to be true, that’s usually because it is. Back to the email and soon enough came the sentence, “the reprint rights of BWBC’s single-page profile is US$3,000.” Ah. I see. So we were legitimately shortlisted, and this sum does cover the cost of a “Certificate of Honor” (sic), a single page “color Adspace” (sic), and circulation is “55,000 print qualified subscribers” along with “85,000 digital qualified subscribers”. So Construction Tech Review is quite a big thing, is it? Well respected within the industry? I was curious to find out more.
For the sake of argument, and to spare any blushes, let’s call the author of the introductory email Jonathan Malibu. Well, I did the usual due diligence by checking out the author, via LinkedIn, and visiting the website of the publication. LinkedIn found only one Jonathan Malibu, but with an incomplete profile, as well as a Nigerian chap called Malibu Jonathan. So far, so good. Maybe he’s such a successful businessman that he’s too busy for LinkedIn? But what do you suppose I discovered when I visited the website? Hold on to your socks because what you’re about to read is in danger of knocking them right off!
He has been a persistent fellow, this Mr Malibu, so you’ve got to give him that at least. Very keen indeed. Three times now, he has reminded me about his initial introductory email and wants to schedule a call to discuss our well earned reward. I have not replied once. Pardon my lack of enthusiasm, but I am sceptical of any worthwhile source of industry knowledge that refers to BIM as Business Information Modeling. Yes. Eyebrows raised. The very first BIM article I looked at, valiantly railed against collective industry-wide perceived knowledge by changing the meaning of BIM! It has absolutely nothing to do with building anything, apparently.
Once I had recovered my composure, shocked as I was that we had all been using the term BIM incorrectly all these years, I checked out the rest of the article. It was an absolute shitfest of poor grammar, misinformation and vaguely worded bullshit. In fact, a little bit like a UK government statement on how the unrestricted flow of road freight will occur post-Brexit, only without the grammatical errors.
I moved on to another article, entitled How Will the BIM Models Work Efficiently to see if I could glean anything useful, but it was the same sorry story. Poorly understood copy-pasta, not a source of useful information. I would like to think that the entire edifice of Construction Tech Review will get outed and shown the door by the wider community. But then, who should I see pop up with an article in their name? Only industry veteran, knowledge repository and generally nice guy, Richard Kuppusamy. Eyebrows raised again. Unsure as to whether this was original content (pretty sure it’s not), but a quick Google search was briefly put off when I was hit by this cheeky message:
Despite the fact that the text appears to be a transcript from a presentation Richard made back in 2017, I can’t copy-pasta because it’s copyright? No problem Mr Malibu. Such utter horse shit. Anyhow, needless to say, I shall not be taking him up on his offer to pay US$3,000 for some dubious publicity puff-piece which may or may not even appear on a seldom viewed website, or in print.
I was recently fortunate enough to find myself invited to a webinar/workshop where I was introduced as an “expert” and mentor. Now I’m fairly happy for people to call me whatever they like, so long as it’s not too rude, but expert is not something I have ever felt comfortable with. When it comes to the niche world of BIM there are, in my honest opinion, rather too many “experts” around. After all, not everyone can be an expert in their field, surely? Where are all the “enthusiastic journeymen” or even “keen amateurs”? In fact, the term is so overused as to be in danger of becoming rather meaningless. It has become like the “Celtic arm ring” tattoo equivalent, that looked great in Bali in the 90’s when no one else had one, but is so mainstream these days that it can be more of a talking point NOT to have a tattoo.
So if we are not to introduce all knowledgeable BIM peeps as “experts”, then what should we be introducing them as instead? Well, here is a suggestion; although it is only a suggestion. How about we just do away with all the guff about how “Mr So-and-so was the first person in the world to export an NWC file”, or “Ms Blah-de-blah is frequently invited to perform parlour tricks to government ministers” and let the audience judge the value of the content for themselves? Why? Because it is my considered opinion, having sat through a few of these things in my time, that the true “experts” of any given BIM situation spend far too much of their time attempting to unravel the Gordian Knots they frequently confront on their projects that they simply haven’t the time to fanny about with putting fancy Powerpoint slideshows together. You are as likely to find genuine expertise in the audience at such events as on the stage talking about it.
So back to where I started with this. A webinar thing. What with the COVID-19 apocalypse, the industry, which previously comprised of a calendar filled with copious networking events, seminars, lectures and summits, culminating in the “Burning Man festival of BIM” that was Autodesk University with its annual pilgrimage to Las Vegas, was completely wiped out. If there was any silver lining to this great, black cloud of the pandemic, it is that far fewer people have been subjected to the merry-go-round of unrepresentative award ceremonies, snake oil salesmen soapbox events and theory lacking in practical application that has been a feature of the growth of BIM. Many senior IT/CAD/BIM/digital whatever saleswankers have been prevented from attending their annual get togethers on the company Dime. And, guess what? Has the push for BIM upskilling and usage fallen behind globally by a whole year? I guess we will know for certain as 2021 progresses, but something tells me that this whole experience, as painful as it has been for so many people due to furloughs and staff cuts, it should have become abundantly clear that the parasitical relationship between software vendors via the preferred vectors of IT/CAD/BIM/digital departments, is not only unhealthy but entirely superfluous to meaningful progression and uptake of BIM throughout the AECO industry.
Something we can all do though, and something that does add value and meaning, both to teacher and pupil, is mentoring. If all of those “enthusiastic journeymen” and “keen amateurs” were to each find a suitable BIM professional mentor to take them under their wing, and those mentees were to go on and do the same once suitably experienced, the whole upskilling and knowledge cock-block that is the most frequent accusation foisted upon BIM advocates as the reason why “Design Department A doesn’t do BIM” would be progressively overcome.
But do remember one thing; it’s mentees, not manatees.
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.
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.
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:
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.
BIM Weasel has the dubious honour of being nominally “in charge” of the BIM on a very large waste management project. This involves the storage and processing of large quantities of solid municipal waste, mostly domestic, and naturally requires several large waste bunkers within the design. It is an enormous incinerator, situated on over a dozen hectares of reclaimed land, situated in prime porpoise and dolphin feeding grounds. It will generate large quantities of highly carcinogenic dioxin containing bottom ash which must be disposed of by shoving it all into a large hole in the ground and hoping that the laws of physics somehow change over time, or no longer apply, if you leave it for long enough.
One day, a door appeared in the corner of one such waste bunker. Access for humans was required, and since household waste is such a harsh environment to work in, it was considered unsafe to use cat ladders or similar methods to access the “giant bin” from the top. The answer, it would seem, was an access door towards the base of the structure. Not right on the bottom, of course, since rubbish disposal is not a dry business and involves quite large quantities of leacheate, otherwise known as “bin juice”. Otherwise a perfect environment for a many tentacled trash compactor monster to live. Still with me? Good.
Now it wasn’t immediately apparent to me at the time, but the realisation crept up slowly and then suddenly jumped out in front of me, Spanish Inquisition style, during a meeting. All it took was a few scribbles and a Navisworks Saved Viewpoint and voila! What you see below is the result of my extraordinary creative genius.
Above: the trash compactor from Star Wars Episode IV, A New Hope. Below: a Navisworks Saved Viewpoint showing the access door, plus creative genius. You think I have the descriptions muddled up? No, that’s the problem. The two are so alike you simply can’t tell them apart. Much.
I had realised that I was, in fact, no better than the millions of drudgeons responsible for the construction of the planet destroying weapon, the Death Star. The trash compactor may well have been inside a Star Destroyer, a mere few kilometres of cheese wedge shaped and oddly bad at aiming weapons, but I know I’m not the only one who questioned the sanity of anyone who would have worked willingly on the construction of a planet sized super weapon on behalf of an evil empire. Did the workers have trades unions? Was the design team in on the ultimate function? Was it all assembled from modular components and did they use BIM? Such a giant undertaking would surely have comprised of some serious coordination meetings. Did anyone on Alderaan become suspicious when the Empire started excluding the planet from its cloud storage data sovereignty agreements? There are so many points when you think that such a monstrous thing would simply be impossible, either a long time ago in a universe far far away, or indeed more recently and closer to home. There are simply too many points of failure for it to remain feasible.
After all, Darth Vader was only ever seen roughing up senior officers in the Imperial Navy. Did he also visit the Death Star canteen occasionally and loose his shit when the penne al’arrabbiata he ordered wasn’t hot enough? Queue foreboding and doom-laden Empire music…
When reality becomes science fiction; building the Death Star in Hong Kong. Is it Digital Twins or should it instead be attack of the Digital Clones? Tired of the lazy scattering of overused science fiction tropes? From now on you shall address me as Grand Moff Tarkin, and you may fire when ready.
Foreboding and doom-laden Empire music grows in intensity…
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?
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.
“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
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.
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.
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?
From: BIM Weasel Sent: Friday, 24 April To: Important BIM Project Manager (IBPM) Cc: Gary Subject: Monthly report – example
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.
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).
From: BIM Weasel Sent: Tuesday, 5 May To: IBPM Cc: Gary Subject: RE: Monthly report – example
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?
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.
From: BIM Weasel Sent: Tuesday, 5 May To: IBPM; Cc: Gary Subject: RE: Monthly report – example