Schedules, Symbols and Marks

Anyone dealing with a little bit of implementation with Revit has probably heard this one, "Uh, but we show a "delta" for each Revision number in our revision schedule". Second verse same as the first when discussing schedules for doors, windows, motors, VAV's, Lighting Fixtures...the list goes on.

I tell people all the time that with Revit you have one of three answers to any question you might ask:

Yes it can do THAT! (85%)
Ummm...do you have a minute? (10-15%)
NO! Well...not yet! (0-5%)

Yes means there is a specific tool or intentional way to do something. Ummm...means get ready for a work around because a precise tool is missing, an approach exists but isn't obvious or intentional or you must distort an intentional feature to get what you want. Usually the result is still good and in keeping with the larger idealism of Revit and BIM. No means no, but even NO has a workaround. However it usually is so ugly, painful or objectionable that most would run away to hide in order to avoid doing it.

This delta or door tag in a schedule column is a NO, not that can happen easily or automatically unfortunately. At its worst a work around is awful because you are asking someone to place a little symbol on top of every row in a schedule to get the "look" you want with the fairly obvious unpleasantness when the data changes. A slightly better solution is to just place one symbol at the top of the column instead. I try hard to get people to "relax" a bit about this one since they've (they should have) got a symbol legend already that explains what that little delta is all about. Caution though...don't actually tell someone who is tense to relax. Usually quite the opposite will happen! 8-)

Some are quite fierce about these established habits.

My problem is that I spent eleven years, working for a contractor and manufacturer, reading A/E drawings to get equipment, materials and personnel for projects prepared to then install in the field. My primary complaint with documentation was usually the lack of detail for a specific part of the project. Worse a section or detail that was "promised" in a plan but didn't materialize on the sheet it was supposed to be delivered on.

I never ever worried about a symbol or whether the elevation "punched". As long as the symbol was on the legend "up front" I was good to go. Of course there were plenty of symbols with out a match on the legend. When I was estimating a project I usually had about a half hour to make some pretty significant decisions about what our customers would need from us so "pretty" didn't cut it...I needed data.

Make no mistake, some drawings stood out to me, made an impact and caught my attention by being different. Usually these drawings were also "better" not necessarily because they were "prettier" but because such attention to detail tends to continue on into the subtleties of a project. One thing that always made schedules easier for me that is also a NO in Revit is even/odd shading or grouping of rows so there was some visual separation of data. This made it easier to read and find my way through large amounts of information.

After eleven years of that I was in for quite a shock when I started working for an architect who was quite particular about the documentation that left his office. It was an education in the finer points of documentation and design. For that I'm grateful and it has continued to this day every where I go. But once you've had Banana Cream Pie you don't forget...I've seen this issue from both sides and they are both correct...for different reasons.

I try hard to encourage people to not distract our progress with implementation by making a NO issue a "showstopper". I encourage them to contact Autodesk to make sure they (Autodesk) understands what they need done. Eventually they'll get to most if not all commonly requested features.

I try hard to keep moving forward because many of these kind of issues are not likely to turn up in a monetary penalty like change orders or rework. I'd gladly give up this sort of "sacred habit" if I could avoid some costly change orders because one of our staff is not busy putting little symbols on a schedule/sheet and instead catches that big "oops".

The first architect I worked for said in a meeting once that it often feels like he spends 90% of his time convincing people to do things, that they can do things and 10% designing and resolving things. He could only imagine what his work output/quality might be like if he could invert that. Apply that same thinking to documentation. If we spend a disproportionate amount of time doing things that don't add value but just keep us busy we probably are n0t catching significant errers or making better informed decisions.

Good luck with "that"!