What is “Stonehenge Syndrome”?
Of all the challenges we face and hurdles to overcome in implementing BIM, there is one that is becoming more and more prevalent, one that seems to be raised more often than any other. It doesn’t have a simple term to describe it, so recently I’ve been calling it “Stonehenge Syndrome”.
Stonehenge Syndrome is the ambiguity left behind when something is not described well enough. I use Stonehenge because Stonehenge is a monument to… what? There are theories, ideas, concepts, but no definitive, documented proof of its purpose or aim. It is a point of continued debate, but no-one has a verified answer. The builders knew, but that doesn’t help us understand. Its purpose becomes subjective interpretation (with a little bit of scientific evidence thrown in to support the various claims).
Where does Stonehenge Syndrome occur in the construction industry? Everywhere. It is a symptom of our industry’s desire to keep pushing the boundaries of what is possible, proving continued value, but also a symptom of a lack of interest in completing a task comprehensively. It starts with the lowest task and can be found all the way through to business strategies and even government mandates. As an example, consider a design query raised in a coordination review. It’s discussed fully, and understood, but isn’t minuted because it is assumed everyone understood. Which they did. At the time. Only when one team returns to their office, they remember the decision made but they can’t recall why. Without clear minutes they have nothing to refer to that explains the reasoning. Of course, the solution is simple: call the decision maker and ask them again. Unfortunately, that doesn’t always happen; people infer their own reasons. And that is where risk begins to develop. Subjective interpretation is only one party’s perspective & isn’t always formed with the complete understanding.
That’s a major problem when the industry is widely dispersed and somewhat fragmented, when it is reliant on a handful of experts to define the protocols and procedures to which it is expected to follow. That’s a major problem when one party inherently understands their own deliverables, but do not ensure their recipients understand them also. It’s why, at pretty much every BIM conference, all we hear is the debate over how paragraph x.y.1 of standard z should be executed, and how there is “lack of guidance” for EIRs, CDEs, BEPs, AIMs, etc.
There are always excuses for Stonehenge Syndrome – budgets, time constraints and lack of competency – but very rarely are these actual reasons. More often than not it’s because the focus has shifted: job done, time to start the next one. It’s caused when a presumption is made that a definition is clear to understand because the person defining it understands it. Our industry is very good at defining principles but not good at explaining them so they are easy to understand and implement. The only way we’re going to fix this is to be far more thorough in ensuring our message is understood. That will take more time and effort, but the results will be exponentially better. With all this push for “plain language questions”, isn’t it about time that the whole BIM concept was questioned whether it is itself built on “plain language”?
Whatever your responsibilities in the industry adoption of BIM – writing the next draft of a BS, preparing a company strategy, defining the contents of a BEP, writing the implementation guides for your project CDE, annotating a drawing – read it again and ask yourself whether it is as clear as it could be. Then go back and re-write it regardless and ask yourself will you understand every word and every reasoning in two years’ time? And then go and ask someone else to read it and, not comment on it, but explain it to you. You’ll be surprised at what you’re told. Don’t correct them, but use their (incorrect) interpretation to iron out your own ambiguity and lack of clarity. Don’t walk away allowing your legacy be an esoteric conversation topic. Make sure you know that they know what you meant.
Right, I’m bored now. Time to move onto the next job…