When a person has been working with BIM for a long time – s/he is likely to develop the habit of extensive use of allegories.
Having also fallen a victim to this phenomenon, I can only explain its lure as a less painful alternative to trying to describe relatively complex-concepts, over-and-over again, relying purely on the badly defined and highly limited field-specific jargon that is on offer.
For example, when I explain the difference between ‘informative’ and ‘instructive’ DRAWINGs I usually still get somewhere…
but, when I try to apply the same concept to digital models – I almost always draw a blank.
So, here is my analogy I use on ‘informative’ and ‘instructive’- digital models:
I ask people to visualise an expertly prepared, high quality dish!
(say a ‘Grilled Salmon in Grape Leaves with Tomato-Raisin Relish’);
This, then I say, is the equivalent of a fully defined design for a building
(i.e. the client – via the designers knows exactly what the dish will need to look like, taste like, smell like, feel like etc. etc…)
If this client then provides to an ‘unrelated chef’ a representation of this dish (building design) for the purpose of obtaining a proposal for the preparation of a dish equivalent to the ‘designed’ one this process is pretty similar to an AEC tender;
The representation can be a picture (2D) with labelled explanations on what is what, a 3D digital model of it with metadata included on each component (3+Ds) or a copy of the dish itself…
And no matter how good a quality these representations were, without a recipe, these would be ‘just’ ‘informative’ models or drawings/pictures and offer no certainty that the replica will indeed be of the same condition.
A recipe accompanying this dish (again can be in many formats, written, drawn, recorded as a Youtube video) is what will turn the ‘informative model’ into an ‘instructive’ one, making it much more straight forward to scope-, price-, plan for.
Not a guarantee for quality but a contractually much safer bet for the client.
In the 1990s AEC environment ‘explicit instructions’ were out of fashion ‘performance specification’ was the norm;
The promoters of the approach claimed, it was best to leave everything to contractors to figure out, pricing and then building jobs from loosely drawn concept designs.
They validated their approach by identifying contractors to be the ones to best know their ‘means and methods’, i.e. the true masters of their trades!
One can argue similarly, that in the dish-proposal, COMPETENT chefs would just as easily figure out what needed to be done, how and when and should be unnecessary as well as counter-productive to constrain them with overly ‘prescriptive recipes’.
Yet practice shows that this is unlikely to work – ambiguous scopes, lose instructions lead to paralysed projects more often than not. Imagine 2-3 subcontractors working from performance specifications trying to simultaneously install wall/facade/joinery systems that have no clear, unambiguous ‘skeletons’ given to them to work from. Even preparing shop-drawings would easily turn into a never-ending game of chasing each other’s tails, let alone work on site.
On the other side, it does not need to be all-or-nothing, between whether clients should prescribe or describe.
Offering ‘chefs’ (or in the AEC equivalent contractors/subcontractors) the option to come up with ‘as good/or better’ work alternatives that will still match the specs of the desired outputs by drawing on their own specific knowledge can be extremely useful for all.
However, substitution needs to be carefully managed and preceded by clear, clean, unambiguous recipes forming an explicit baseline to work from.
The company VICO has long ago figured out that ‘recipes’ can be useful to describe the non-graphical qualities of the metadata in their AEC projects.
While their recipes were initially created for the purpose of time/cost scheduling by the contractor there exists the possibility to expand them further into including ‘other instructions’ like directives on manufacture or installation.
This is at least one toolset that is able to be developed to meaningfully serve ‘instructive models’ should there be a real demand for them and I know of attempts made by various other software vendors.
So, it is safe to assume that mandating for standardised, ‘instructive models’ by any AEC client is a totally valid and in time practically feasible idea!
In line with that thought, looking again at the UK Government’s initiatives I ask again:
Should the UK Government, as a large building owner prescribe how its buildings are designed and created?
Should it be highly specific on the deliverables expected from the various providers?
Is it heading in the right direction with the way it is mandating BIM?
To close off my argument I’ll return to the ‘dish’ analogy:
The UK Government is currently prescribing the spoons, the knives, the spatulas its ‘building chefs’ must use.
Oh yes, and the kitchens they are to operate in, down to the floor tiles and the specs of the ovens.
But, no word on the need of ‘instructive models’ or simply called: recipes.
As if assuming that those tasked to build-off these ‘mandated’ (information) models could easily reverse-engineer the information without the need for the instructions.
An extremely brave assumption, that is.
Understanding the difference between ‘informative’ and ‘instructive’ DRAWINGs and mandating for the second NOW would be a good first step and definitely a prerequisite to dabbling into a highly ambitious BIM approach.
Note: in this post I ignored the many challenges that the process of ‘getting a viable design together’ – or if you like, defining the ‘dish’ (building) poses in the first place, not because this issue is less relevant to the topic but because in the scheme of things, it is still less damaging:
i.e. consultants are generally still more capable to design and describe their buildings then meaningfully instruct others on how to build them.
(Design & Build schemes have their own ‘extra’ flavourings to bring into this picture too, I left them out to keep the argument as simple as possible);
Sample recipe from: