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?
Absolutely.
Should it be highly specific on the
deliverables expected from the various providers?
Absolutely.
Is it heading in the right direction
with the way it is mandating BIM?
Absolutely NOT.
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: