In defense of (good) drawings.
It turns out that my blog post last week about Autodesk’s acquisition of PlanGrid generated a great deal of debate around the topic of drawings.
At the core of my argument was that drawings, as a vehicle for information, have not changed in centuries. The fact that you can view a “digital” drawing in a “digital” device does not do anything in it of itself for the quality of the drawing. In fact, I would argue that the portability of “digital” drawings may have a drawback, like so many misused technologies do.
If you can carry the entire set of drawings for a job in your pocket you may be less likely to curate the contents of said pocket to make sure you have the specific information needed for the specific task at hand.
To put it another way: The advantage of Advanced Work Packaging, breaking down the job into manageable buckets, is not that your bucket will be smaller, but that you will be very deliberate about what you put in the bucket.
However, the point was not to take away from the value of a good set of drawings, digital or otherwise, but rather to wonder what might happen, if we as an industry put more value on the information and data behind those drawings.
Two things became immediately clear:
1. The real roadblock to progress is the contractual nature of this industry. But we knew that, and the issue merits it’s very own blog post at another time, so let us assume we’re not changing the contracts for now.
2. Human nature protects inertia, and those who see their routine disrupted (or those who believe their deliverable to be a set of drawings), quickly reach for the usual protections: We need drawings for the permit. The contract has to have paper and a wet stamp, hand drawn drawings are a work of art worth protecting, and so on.
OK, so that last one is me being an ass, but this is my blog and I can say what I want.
As much as I like vintage drawings for their artistic value, if you are an Architect who does your ‘production’ drawing by hand you pretty much raise to the level of negligence in my view. But then again, you are probably not reading this. All others, put the keyboard away. There is a reason I put ‘production’ in quotes. Sketch and hand render away all you want, just make sure to Google “Standard of care”.
However, the other points are quite well worth exploring.
It might surprise you to hear me say that drawings are actually very valuable. Of course, I see drawings as strictly a means of Input and Output. Mostly Output but we’ll get to some great ways of using them for Input, I promise.
Obtaining a building permit is probably the best, and most clear-cut example of this Output. Yes, there are some jurisdictions that are pioneering the concept of model based code review, and that is wonderful, but in most cases a set of drawings, often in plant-based physical format, is still required.
This is not likely to change anytime soon, but what? Should we as an industry stop? Let us not move any further because of this reality?
No. We should not rely on a mandate of any kind to get us to do things better, nor am I holding my breath for that to happen.
But this is what I mean by drawings being an Output.
If you have good data, and an accurate BIM, then the Output of a set of drawings for the City is just a few clicks of the mouse away.
2D representation is just another view of the database.
And it will be correct.
Most construction professionals will tell you the average set of drawings is riddled with mistakes. Mistakes caused by the drafting inefficiency, or by trying to model something that just can’t be.
In that sense, you should be able to query the database and automatically generate drawings of any part of the building, with any view criteria that you need, for any use you need it for. But, you need a good BIM for that to work, so you have to think of a finished building as your deliverable. Not a set of drawings.
For well over a decade, in fact, long enough that I can’t really recall when it started, I’ve been able to check all my banking activity online. That information is in real-time, and live, but if I choose to, I can specify a transaction type and date range, and produce a PDF report of transaction activity. That is another example of the same thing.
Take a database. Produce Output based on certain criteria. Exactly the same thing.
Which brings us to another point. If a cloud hosted database can be used for managing banking, that same technology can very well be used to track project transactions, so the idea that you can’t write contracts that refer to that database, or that somehow an activity log from a cloud system is not valid in court is simply not true.
In fact, with Builderbox.io for instance, you have a complete audit trail of everything. Which sucks only if you’re doing things wrong…
And yes, pardon the plug, but we are a David among Goliaths, so we have to take every chance to promote our product. How much work do you do for free?
Let us assume then, that you have your BIM up to snuff, and that you are generating some good Output drawings for different uses. One of those uses can be communicating certain aspects of the project to your stakeholders, and collaborating on the project. That is where drawings can also be a great means on Input.
Nothing is a better example of this Input than a Bluebeam Session.
Stakeholders can review and markup the drawings at the same time, while the system keeps track of who created markups and when. That is relevant project data that should be part of the project record.
Now turn those markups into actionable data. Tracking responsible party, due date, and all other context needed to accomplish the task. That’s great project data. And it was captured using a drawing.
Notice however, that I keep talking about drawings and not files. Yes, a drawing probably started life as a PDF file somewhere, although not strictly necessary.
Getting away from the file mindset is the first step towards true digital transformation. And while you may have trouble envisioning this in the context of your daily work, I bet you are already comfortable with this in your daily life:
Do you use iTunes? Then you get it. (Google or Amazon Music applies too)
When you listen to your favorite album thru iTunes, you don’t necessarily care where the .mp3 file is, right? It’s there somewhere, but you don’t have to care. You can search the database by genre, or by artist, composer, etc. Maybe it’s part of a playlist you defined.
Not only it’s easier to hit play on the desired track, but if you’re online, iTunes will also automatically play a higher quality version than the one on your hard drive if it happens to find one on the server. So all those old CDs you ripped years ago with lower quality audio codecs now sound as good as new.
Or as good as something inherently analog can sound when limited to right angles… don’t get me started, so help me! I digress.
The same applies in the database environment. An RFI may contain some attachments for context, but you don’t have to care where they are. Just find the RFI in the log with your criteria based on contractor, spec section, work package, author, etc. Try that with a folder that looks like this:
The “Single Source of Truth” is not file based.
Ultimately it would be even better to have a process that makes RFIs a thing of the past, but going back to item 1. that’s for another day, but much as with the example of the requirements for permit: Don’t wait until your contractual situation has changed. Start finding efficiencies now. There are ways.
In fact: Don’t wait for the perfect project, or the perfect team. Those things don’t exist and you’ll be waiting forever. Start taking small steps on the work you are doing now, and let it grow. It’s much easier than trying to do it all at once.
We can help. Other vendors and consultants out there can help. And if you’re so inclined, you can do it on your own too. The technology exists, and this is not rocket science.
The one part we haven’t quite figured out yet is how to tie back to the database once you have printed something to actual paper, but as they say… hold my beer.
