No one goes into a career in architecture because they love to crunch numbers or deliver hard data.
But once initiated into the tribe, it has increasingly become a reason for many to stay.
This is where we find ourselves today: instead of surviving on our wits – we’re surviving on analytics.
Practicing an art and a science, architects naturally run both ends of the spectrum. Some consider themselves artists first and foremost, unconcerned whether their designs ever see daylight. These paper architects, updated for the conceptual age as digital architects, perform primarily in pixels.
And give architects their not always positive reputation as artists.
At the other extreme are architects for whom it is all about the hard evidence.
For them a day at work is more CSI: Crime Scene Investigation than CSI: Construction Specifications Institute.
Feeding on constraints and ever-changing regulations, design for them is a matter of looking-up and plugging-in information that’s required and, if necessary, trimming off the excess – literally in the trim command, trim tool or by way of value engineering.
So when BIM came along, these hardscrabble architects pounced on it. They love the plug-‘n-play apparatus. They devour the dialog boxes and cannot feed enough information into them.
Rather than being exhausted by the umpteenth request to provide information they’re energized by it. As though to say, hit me with another question.
It’s not that BIM has done away with RFIs; they’re now embedded in the program.
These are the people who grew up watching game shows and love to answer trivia.
I’ll take Creating New Types and Templates for $1000 and Instance Properties for $1500.
The reality is that we need both types of architects. I have argued here that in the best of worlds the two would reside in the same person. Others have argued elsewhere that it’s good for project teams and organizations to have both types of people, to provide flexibility and agility, and to serve as a checks and balances function to assure the work stays in line.
But how much information is too much?
Could there be a fear of too much information (TMI) – too much I in BIM?
For that is the crux – to know how much information is needed and when it is needed.
And while this has been addressed, particularly in some of the better contracts, it’s a mindset and skillset that needs to be developed that we’re talking about here.
It’s like when a sales rep calls on you at an inopportune time – say on your way into a design presentation and you unadvisedly or unwittingly took the call. It’s not bad information that they want to impart – it’s just not the right time for it. A week later that same information may come through for you and help you get your design approved. Just not now.
This ability – to gauge how much information is needed and when – is not a new skill but it’s just never been more important than it is now for individuals, teams and firms to acquire.
It’s not only a matter of knowing where to hit the hammer, it’s a matter of recognizing and acknowledging the context so you can nail the the question: of the project phase, who will use the information, what they will use it for and when they will need it.
And this ability is age-related: it is easier for senior team members than still emerging talent to see the bigger picture.
Malcolm Gladwell in Blink called this ability to see information in its wider context: coup d’oeil or court sense or “giss,” the power of the glance, the ability to immediately make sense of situations.
Information Intelligence (II)
Call it Information Intelligence (II) the uncanny ability to gauge when, how and to whom to apportion information.
Developing this ability in your staff – and hiring for Information Intelligence or II skillset – will save more time, fee and headaches than any other single move you could make right now.
It takes an understanding of the technology, as well as how buildings come together.
But the higher science of this knack is a people or social skill: understanding how people receive information, how much of it they can consume at one time, what the best format for the information is so that it finds its highest and best use.
We have all had the opportunity to work with people who have the II gene. They possess the uncanny ability to gauge and deliver just the right information, at the right time, to the right person, in the right way.
When LOD becomes LOL
I am not asking here whether you can get to level of detail (LOD) 300 in Revit or ArchiCAD without working in 2D or whether these tools are ready to take-on LOD 400 for fabrication (they’re not.)
While important to know, what we’re discussing here is a higher order matter.
In an interview for my book, BIM + Integrated Design: Strategies for Practice, a BIM manager and project architect described the process thus:
The process should be like an onion where you’re building an onion backwards. You’re putting on the overall scope and slowly putting in each layer inside until you get all the way down. It’s very difficult to do that in BIM because the first time you put in a wall it asks you how thick is your drywall?
What’s the least amount of information that is needed at this moment to get the design intent across?
What’s the role of “hard facts” and just how hard are they?
Owners see data this way: the facts, pure and simple.
Constructors and design professionals know better, because they know more.
This is where things get more complex and uncertain.
Contractors put their own spin on the data when they indicate other contributing factors to consider – adjacencies, impacts to schedule, availability of labor, codes, etc. They see the data within a larger context.
Architects are wont to bring up the sociological impacts, the social impacts, psychological impacts and not mention the equally important aesthetic impacts of the decision-by-data point.
Death by Data Point
Statistics are definitely in. Evidence the evidence-based everything.
The New Yorker’s June 7 2010 issue lists the top jobs for the coming decade. Most involve information, metrics, data analytics or statistics.
But last time I looked architecture remains an art and a science.
And while it is foolhardy to justify subjective, aesthetic predilections by any other means than by invoking hard data – it will make you this much, it will improve quality, it will get the project done on time – it does nothing to stop an underlying and critically human need for subjective, aesthetic predilections.
Still, there’s a point when TM is definitely TM.
Just as “Death by PowerPoint” is a criticism of slide-based presentations referring to a state of boredom and fatigue induced by information overload during PowerPoint presentations, Death by DataPoint is the state we feel as design professionals when relegated to feed the beast by plugging-in infinite streams of information.
So let’s put an end to TMI and work towards just enough, just-in-time information.
Start with Seven Simple Questions
Before imparting our infinite wisdom, before sharing or over-sharing, start by asking these seven simple questions:
- What do I need to know?
- How can I get this information?
- How reliable is it?
- What do they need to know?
- When do they need to know it?
- Can I help them get this information?
- How can I best communicate this?
By doing so we’ll do everyone, including ourselves, a favor.
11 responses to “When is BIM TMI? or Death by DataPoint”
In the LinkedIn group: BIM for Owners, Jess Pettit, PE left the following comment:
I have had the responsibility of “corporate memory” and “just-in-time information”. What I have concluded from working with organizations with 50-200 people on constructed environments is:
● 10% of the information based on number of discrete files is accessed by 90% of the users. Focus on the 10%.
● 1% of the information is routinely accessed based on total file volume size
● The successful and satisfied users routinely access the information
● Actual users are a small portion of the candidates that could benefit based on polls
● 3% of the routine users contributed to the creation and maintenance of the information
● Non-users routinely search unproductively for available information from other sources and pay to reobtain the information
● Non-users who are not comfortable with the information or interface, do not have confidence in its information
● Non-users routinely create, maintain and disseminate their own (mis)information
● Branch or satellite offices are less likely to archive, access and maintain information than a central office
Questions we asked in information management:
● What do we need to know?
● What sources do we have for this information?
● How reliable or current should it be?
● How frequently do we need to access it?
● How do we most appropriately archive it?
● How do we best communicate the information available to the user?
● What is the preferred format for the majority of customary users? The preferred format is the one which helps foster subsequent decision-making by the user.
Thanks Jesse for sharing these excellent insights and questions!
Great post as managing the I in BIM is often the most complex and challenging aspect of the design and construction process. The one rule I live by and impress upon junior designers is “put in, only what the project team is going to pull out.” There is always the oppurtunity to build in more detail, more information, more attributes later on but educating the team on what the Owner and CM are using it for is critical to knowing what to put in.
Thanks Jason for your comment – and for sharing that great rule of thumb. A helpful reminder that all of us can benefit from.
Philosophically, I am 100% with you on trying to limit information content in early project stages. I could do that with a pencil and paper, and even with CAD.
But, when I am trying to decide how much to model today, the biggest dilemma I encounter is not what to put in or leave out, but what to leave incorrect. Drafters are often left with little choice about what to put in or leave out.
Much of the info in an immature BIM is default (or assumed) values, indistinguishable to a user from those carefully designed for a specific case. For example, I may only wish to indicate that I think there will be a beam which bears on two walls. I know its span (for now), but its exact location and size is not known. But our BIM software practically forces us to model it with a precise size and location. I know of no fuzzy dimensions, objects, or parameters built into BIM software, but would love to see them.
A preliminary estimate, or constructability assessment will be based on what is in the model – at whatever ‘LOD’. If beam (and footing, column, joist, pipe, etc.) sizes are not given at least some consideration in initial modeling, … well, you see the problem.
Furthermore, projects may go on hold for weeks or months. There is rarely budget for a complete ‘mothballing’ process. Unless great discipline (I would say an unrealistic level of it) is applied to model development, good, bad, and hypothetical information are indistinguishable to the team picking the project up when it comes back to life.
Piecemeal workarounds – some slapdash, some cumbersome and time consuming, and none comprehensive or even very effective – seem to be the best we can do. So we are constantly mining the model for problems – sifting and reviewing, editing and verifying, to ferret out assumptions made without due consideration. On paper, unconsidered information wasn’t there. In BIM, its usually there, considered or not.
The BIM paradigm acknowledges that some decisions need to be (and can be) made earlier, but it also forces decisions that are not intended to be decisions at all, with no way to identify them as such.
To me, this is the most glaring omission in the whole paradigm. In our quest for precision, we have left no room for ambiguity. That’s great for a finished set of CD’s, but crummy for developing designs.
Thanks for your thorough comment – some excellent insights here. Perhaps none more than your last paragraph.
“we have left no room for ambiguity” – that alone is deserving of its own post.
I have written elsewhere that despite being characterized as perfectionists, one of the design professional’s core competencies is their comfort with ambiguity – and believe that BIM does not allow us to act on what we are, deep down, best at.
Best to you,
My friend Peter Janko left this wonderful comment at the Linking CONSTRUCTION discussion. Thanks Pete!
“Personally, I would be more concerned with a different TMI (the Missing Information) and TWI (the Wrong Information) rather than TMI (Too Much Information). The other TMI and TWI can result in disastrous consequences as occurred at yet at another TMI (Three Mile Island).. Your TMI on the other hand usually just wastes time but fortunately, your TMI should be filterable down to, as Joe Friday would say, “Just the facts ma’am” or JTFM if you are into acronyms.”
Pingback: 107 Reasons Why You, Architect, Matter « Architects 2Zebras
sorry to get into this so late, but along with the comfort of ambiguity, a lot of architects have to learn to be comfortable with delegation — delegation to much more experienced subcontractors and fabricators. The 3D model should provide parameters for the fabricator to extrapolate off of; and then their data points fed back into the model so that it is useful for all of the other consultants/suppliers. Just because the software allows us to locate every fastener, that capability does not mean that locating every fastener is the job of the architect, unless of course, the fastener pattern is part of the design criteria.
Part of the task of the architect using this technology is to understand when it is more appropriate to properly vet the subcontractors than it is to over-detail the building.
Pingback: 107 Reasons Why You, Architect, Matter | Myblog's Blog
Pingback: 107 + 1 REASONS WHY ARCHITECTS MATTER | RY Arquitectos, architects & engineers
Pingback: 107 107 REASONS WHY ARCHITECTS MATTER | urbanizedworld