SPEC PROCESS

Preparing class materials for my spring 2012 semester portion of “Codes, Contracts, and Specifications” this weekend, I found myself comparing the old CSI Project Resource Manual to the new Project Delivery Practice Guide.  


In the Project Resource Manual, the product selection process, and by implication the spec writing process, is portrayed in a very neat, orderly, structured, idealized, one-step-follows-the-next, flow-chart-y way.


It would be nice, but a little boring, if the process actually unfolded this way much of the time for me.


Instead, construction document production is usually on such a tight schedule that drawings and specs have to proceed simultaneously, so the spec writing process is anything but a straight line affair. 


In order to edit even some of the simpler spec sections, it’s often necessary to look multiple times at constantly evolving in-progress drawings on the server, ask various members of the project design team lots of detailed questions, wait for answers, and draw inferences when drawings aren’t explicit or when product or design decisions don’t seem to be imminent.  Often it's necessary to go back and delete or add sections when the design takes an unforeseen direction. 


If anything, the trajectory of the process I’ve become accustomed to is less like a flow chart and more like the way a restless canine explores his territory.  


Like my Sheltie, Ollie, in the snow in my back yard this morning.

WHY NOT BE A SPEC WRITER?

Young architects and engineers:  Are you wondering how you can carve out a satisfying career niche in the AE business?


Are you looking for something unusual that increases the likelihood that your services will be in demand in this turbulent economy?


Why not consider becoming a spec writer? Spec writing is a niche job that very few architects and engineers seem to want to do even occasionally, let alone full time. Why?  Beats me.  I think I’ve got the best, most interesting job in the office.
I’m not suggesting you become your father’s spec writer. Not the irascible old guy with all the red pencils and the six-inch scale in his shirt pocket who talks to himself. 

I suggest that you aspire to something more along the lines of a knowledge manager, as the concept is explained by Robert S. Weygant in his new book BIM Content Development - Standards, Strategies, and Best Practices. A couple of passages from Mr. Weygant’s book, which I recommend highly (emphasis in italics is by me):

“Knowledge management is the supply, maintenance and delivery of graphical and topical information related to a project. With the advent of building information modeling (BIM), there has been a considerable increase in the amount of information and collaboration during the design of the project. Because so much information is being passed between so many different parties, a single responsible party or team should be assigned to manage this information to ensure consistency between the plans, specifications, model, and other supporting documents.”


“As construction documents are created and the project manual is assembled, the knowledge manager can organize information based on its specification section and export the information from the model for use by the specifier. In many cases, the specifier is the individual who makes decisions regarding the performance attributes of certain components. Cases such as this lead me to believe that a seasoned specifier may be the most appropriate individual to take on the role of knowledge management. A seasoned specifier is not an individual who simply understands how to edit a form document, but one who understands the differences between products based on their performance values, when to use certain components, and the appropriate methods for documenting them.”

Why spec writing is already interesting and will get even better:

• Spec writing is entertaining. As a full-time spec writer, I get to work on many of the projects in our office. The pace of the work and constant deadlines pretty much preclude boredom, and the wide range of project types and sizes in our office mean I have to be constantly researching and learning.
• The job is way more than just editing master specs. Spec writers help to express the owner’s business objectives in the bidding and construction process.  Owner’s complicated business needs and objectives mean lots of custom writing of bidding requirements, bid forms, and General Requirements.  
• Ditto for projects using Integrated Project Delivery (IPD).
• BIM/spec linkage will require parts of spec production  to switch from  word processing to a relational database approach - another opportunity to add to your specifier’s skill set.

How to get started in spec writing/knowledge management:

• Commit to being a lifelong learner; stay informed and relevant because change is constant and inevitable.
• Find a mentor, or maybe a few mentors.  Find someone who knows construction detailing. Find someone who knows the bidding process.  Find someone who knows a lot about construction contract administration.  Listen.  Learn.  Repeat.
• Hook up with a CSI Chapter somewhere.  Listen, learn, volunteer.  You’ll learn a lot about the business and will meet people that will eagerly help you.
• Take the CSI Construction Documents Technologist (CDT) certification exam as soon as you can.  Professional credentials really matter in this business, not to mention the fact that you’ll learn a lot in the process of studying for the exam.  After you pass the CDT, take the Certified Construction Specifier (CCS) and/or Certified Construction Contract Administrator (CCCA) exams.
• Read everything you can find about BIM-linked specs, because that’s the future of the profession.
• Tune in to CSI’s free BIM Practice Group, and Specifying Practice Group, monthly webinars, and every other BIM/spec forum you can find.
• Set up Google Alerts and RSS feeds for BIM and specs to ensure a steady flow of up-to-date information.
• Find and follow every BIM and spec-related Twitter account. Watch the dialog for a while and then join in.
• Become the BIM go-to person in your firm.
• Read Robert S. Weygant’s book BIM Content Development - Standards, Strategies, and Best Practices.
• Read Randy Deutsch’s new book BIM and Integrated Design - Strategies for Architectural Practice.  I’m reading it now.
• Jump on the first opportunity you see to work with BIM-linked specs.  Few others will want to follow, and you’ll soon become the go-to person.
• And if you get lucky, you’ll probably be rewarded with a spec writer/knowledge manager role. 
• Put it all together and you'll be a very sought-after professional.

EYEWASH? BOILERPLATE?

I don’t think I’m especially thin-skinned about my work as a spec writer.

Point out something you want changed in one of my specs and I’ll probably change it, after making sure it’s an informed decision. After all, spec writing is a collaborative profession, integral to the production of contract documents, and I like being part of a smoothly functioning, respectful, team.

Point out an error in one of my specs and I’ll thank you for telling me. Then I’ll promptly make the correction.

Ditto for alerting me to a contradiction between one of my specs and the accompanying drawings. It’s common for production of drawings and specs to proceed simultaneously, and for differences in nomenclature between drawings and specs to be discovered during onboard and final reviews of the construction documents. So I expect to constantly make adjustments to specs in progress.

But I am very thin-skinned about a couple of words and the attitudes they reveal. The two words are “eyewash” and “boilerplate.”  

Eyewash, definition from The Random House Dictionary of the English Language:  “...nonsense, bunk.”.

Boilerplate, from Wikipedia:  “...those parts of a contract that are considered ‘standard language’.”  Even though many provisions in the contract conditions and in the specs may be standard, that doesn’t mean they’re not meant to be part of the contract’s requirements.

A speaker using either of these words seems to me to regard the specs as inapplicable, or only partially applicable, to his role in the current project, and by using them may be signalling his intention to follow the specs selectively, as he chooses.

These words also convey the speaker’s disdain for the size and complexity of the specs.  As I said in my blog post Why is the Project Manual So Big, “...the minute that any of the actors in a construction project need support for a position they’re taking, where do they look?  The spec. If the spec has information that settles the issue, everything’s fine. But if the answer can’t be found in the spec, the spec writer puts on his or her thinking cap and wordsmiths something to make the documents better on the next project.  That’s why the spec book is so big.  We spec writers get a lot of feedback.  And we’re driven by the need to strive for a loophole-proof set of construction documents. The inevitable result of such feedback is more words and more pages in the Project Manual.”

Remember those hilarious Pink Panther movies, in which the antics and incompetence of Parisian police Inspector Jacques Clousseau elicited facial tics, and worse, in Clousseau’s boss, Chief Inspector Charles Dreyfus? Here’s a YouTube collection of scenes of the great actor Herbert Lom playing Inspector Dreyfus.

Calling specs “eyewash” or “boilerplate” will have a similar effect on me, and I suspect, other spec writers.

You wouldn’t want to be responsible for that, would you?

POP QUIZ: WHAT'S A FOUCAULT PENDULUM?

The reason I ask about Foucault pendulums is that I saw one last night here in Rockford at a USGBC tour of Rock Valley College's new  LEED (soon to be) Gold Jacobs Center for Science and Math, designed by Rockford architects Saavedra Gelhausen.  The pendulum is the focal point in the building's three-story entrance/atrium.


I won't even attempt to explain what a Foucault pendulum is, because Wikipedia does such a good job here.


For more detail on the Jacobs Center, Rock Valley College's extensive sustainability efforts, and the design and construction team, click here.


This new building is a great place to be, as well as a great place to learn.


Here's what the pendulum looks like.

BLOGGERS SHOULD READ ZINSSER'S "ON WRITING WELL"

Scanning my bookshelf a few days ago, I came across "On Writing Well" by William Zinsser.  I bought the book several years ago. I read and enjoyed it at the time.


I'm reading it again, and I strongly recommend it to bloggers.


Here's why. Internet addict that I am, I follow many interesting blogs, mainly on construction, architecture, and spec writing.  Many are well written and interesting.  Others are interesting but not so well written.  I have to work harder to understand the writer's point. Sometimes I lose patience before finishing a poorly written item, and navigate to something else on the Internet. 


We bloggers want to persuade or to inform, or we wouldn't be going to the effort of blogging.  This book will help us to write good blog posts.  I had several essay/posts in progress when I started reading  "On Writing Well", and the lessons I learned in the book have triggered a serious rewrite of all of them. Who knows when I'll finish them, but I know that they will be clearer and more persuasive as a result.


"On Writing Well" isn't some dry collection of rules about writing.  It's an interesting and amusing book about the craft of writing.  How to be clear, how to keep the reader's interest by putting yourself in her shoes. How to build ideas the way a good lawyer builds his case. 


It takes a master wordsmith to write an interesting book about writing and Mr. Zinsser has done it.


Put "On Writing Well" in your library.  Here's one place to get it.

TIME FLIES

It seems like only yesterday that I was a young architect in the office of C. F. Murphy Associates in Chicago.  


The office was busy, and one of their premier projects was the new FBI headquarters building to be built in Washington, D. C.  I didn't work on the drawings for the FBI building, but I watched a large and dedicated team of people labor for many months to produce the drawings.


Today I came across an article in Huffington Post  citing a report by the GAO, casting doubt on the future of the building, which has reached the ripe old age of 36 years.


Oh, well.

CONFESSIONS OF A FLIP-FLOPPER

I admit it.  I’m a flip-flopper on the subject of integrated project delivery (IPD).

Some days I’m a pollyanna.  Some days I’m a cynic.

The pollyanna in me wants to believe that the age-old conflicts between AEs and Contractors can be suppressed to the point that we can devote more attention to getting the design right and the documents clear, and less time practicing defensive architecture. 

The cynic in me wonders whether the long, contentious history between AEs and Contractors can be neutralized any time soon.

My inner pollyanna whispers to me that maybe I’m dwelling too much on that history and that I’d be better off focusing on the present, and concentrating on my positive mental attitude.

Things usually work better on design/build projects than on design/bid/build projects because the contractual ties between AE and Contractor have a way of settling issues while the construction documents are in progress.  Thus things don’t get out of hand after it becomes expensive to make changes.

The tortured history between AEs and Contractors arises mainly out of design/bid/build projects, where the interests of AEs and Contractors diverge because of their differing stakes in a project.  Here are a few of the viewpoints I see:

●      Contractors:

○      frequently assert that drawings and specs are riddled with incompleteness,  errors, and contradictions; and that when a hapless contractor finally forces an AE to deal with a mistake or contradiction, the AE blames the contractor and says the contractor failed to draw the proper “inferences” from the construction documents.

○      complain that AEs take too long to review submittals.

○      think the AE’s design is too sophisticated (read: expensive) for the project at hand, and complain about it to the owner.

○      think that AEs are too inflexible and suspicious of Contractors.

●      AEs:

○      sometimes see Contractors as mercenaries who place a low priority on the project owner’s interest.

○      suspect Contractors of blithely ignoring the requirements of the contract documents and of trying to sneak quality compromises under the radar rather than getting the explicit informed consent of the owner to make a change.

○      suspect Contractors of shamelessly front-loading the payment process, to the owner’s financial detriment/risk.

○      think that Contractors sometimes shirk their contractual responsibility to coordinate the work, and instead view themselves as essentially purchasing agents with little inclination to coordinate the work.

Can an IPD agreement really get AEs, Contractors (and Owners, too, by the way) to play together nicely?  I sure hope so.  Under the right circumstances, and with the right players, it can probably work well.  Just look at the success of design/build projects, where AEs and Contractors are collectively responsible for the design.

Wouldn’t it be nice if we could all just get along? 

We’re in the midst of our first project designed under an IPD arrangement.  In a year or so, I should be able to say that I’m no longer a flip-flopper about IPD. 

CONVERGENCE

At CONSTRUCT 2011, CSI’s Joy Davis opined that social media are converging. That’s not all the convergence that’s going on.

Convergence of TV and Internet:  Google TV and Apple TV will soon turn TV and the Internet into one experience.

●      Old way with separate media, and separate apparatus.

●      Future, with access to both TV and Internet through TV sets. Apple and Google have both been working on this for years now, and it’s just a matter of time until one or both of them finds the right way to make it a hit with consumers.

Convergence of Spec Writing, Word Processing, and File Management:   This has already happened.  These tasks used to be performed by separate people. Now spec writers need all three abilities in their skill set.

●      Old way, with spec writers doing the editorial work via hard copy markups, secretaries doing keyboarding and managing files.

●      Current way, with spec writers responsible not only for editorial and technical content of specs, but also for  word processing production and file management. For me, file management has been particularly challenging, what with multiple reviews, multiple bid packages, addenda, and issued-for-construction sets.  In addition, most of us now are responsible for turning spec word processing documents into bookmarked combined PDFs for distribution on CDs and/or the Internet.

●      Future:  See below.

Convergence of Specs and Drawings:  Specs and drawings will eventually converge into the BIM model.  Since I haven’t yet had a chance to work on BIM-linked specs, I don’t have a clear picture of what’s possible or practical.  I’ve got a lot to learn about here.

●      Old way: Separate people produced drawings and specs, using separate production tools and separate production tracks. Users (builders, and then owners) have to refer to sets of drawings and volumes of project manuals to learn about the buildings they build and own.

●      Present and near term future: Software interoperability used mainly (I think.  Please correct me if I’m wrong) as a coordination aid in producing specs and drawings.  Linking software (at least BSD’s Linkman-e) isn’t part of the deliverable construction documents.  It doesn’t appear that there’s an industry consensus yet about how much specification data really belongs in the model. 

●      Future:  Hard to say exactly how it will work out, but as a minimum, graphic files and data files will be linked for ease of use by builders in building, and later to aid owners in managing the buildings.

And if that’s not enough convergence for you, check out futurist Ray Kurzweil’s fascinating website Accelerating Intelligence and his book The Singularity is Near, in which he posits (I think) the eventual merging of humans and machines.

Hang on. Everybody in the AEC business is in for a wild ride the next few years.  We will NOT be bored!

FRANK LLOYD WRIGHT’S S. C. JOHNSON ADMINISTRATION BUILDING

Last Saturday, several of us from Larson & Darby in Rockford went on a trip arranged by the employee committee to Racine, Wisconsin to see Frank Lloyd Wright’s 1939 masterpiece, the S. C. Johnson Administration Building.

Like every architect, I had seen still photographs of the Johnson Wax building countless times.  I read accounts of its design and construction and Wright’s tussles with the building code officials.  I reread the passages about its design and construction in Friedman and Zellman’s fascinating book about Wright, The Fellowship.  I viewed videos of the building on YouTube the day before the trip.

None of that prepared me for the real experience of being in the main open office area of the building, the great space where all the dramatic photos are taken. 

The space Wright created in the Johnson Wax Administration Building is sumptuous and complex.  High ceilings, low ceilings, balconies, custom office furniture, the richness of Cherokee red brick, kasota stone, and that gorgeous glass tubing!  The room is breathtaking.

The character of the light flowing through the glass tube-glazed clerestories and skylights is unlike anything I have ever seen elsewhere.  It glows and sparkles at the same time, however improbable that may seem.  It also provides great lighting.

The SC Johnson Company deserves lots of credit as a patron of the art of architecture. It can’t be easy or cheap to maintain such a unique 70+ year old work of art, but the Johnson Company keeps the Administration Building in pristine condition, with no discernable alterations to Wright’s design.

SC Johnson’s company history, and incidentally their business commitment to sustainability, is showcased in another great building on the campus, the soaring and exquisitely detailed LEED Gold Fortaleza Hall, designed by Norman Foster and finished recently. 

The SC Johnson tour guide personnel are super knowledgeable and passionate about the buildings.   

If you appreciate great architecture, you owe it to yourself to experience the Johnson Wax campus.  Make plans to visit Racine soon.

FROM PUNCH CARDS TO BIM, ALMOST

Recently I’ve tuned in to several of CSI’s excellent BIM Practice Group webinars.  Last Friday’s session, which featured two experts from Autodesk explaining their Autodesk Seek product/service, got me to thinking about how much construction document production has changed during my time as a spec writer. And about how much more it’s destined to change in the next few years.

Contrast BIM’s intriguing interoperability with the way specs were prepared at the time of my first job as a spec writer.

Bill Lohmann, one of the finest people I’ve ever known, gave me the opportunity to work as a spec writer in his department at C. F. Murphy Associates in Chicago in early 1973. 

All the major AE firms had begun using some sort of word processing by then, and the routine at CFMA was a multi-step process consisting of the following:

• Spec writers marked up hard copy of firm master specs.  There were three of us at the time, Bill Lohmann, Paul Tiffin, and yours truly.
• Word processing was performed by three secretaries using key punch machines.
• After they punched the cards, two secretaries proofread the cards, out loud.
• They then took them to the firm’s mainframe computer on another floor in the building.  Hours or days later, the draft printouts were ready.  Since the spec drafts were printed on continuous form paper, they had to go through a burster, a loud machine that pulled apart continuous form paper at the perforations into 8-1/2 by 11 pages.
• The burster was prone to jams which tore or wrinkled the paper, prompting consternation, muttered expletives, and usually reprinting.
• Secretaries proofed the hard copy against the punch cards before it was released to the spec writers.

Seems almost comically redundant to our 2011 sensibilities, right?  It was more or less state-of-the-art at the time, though.

I haven’t yet had an opportunity to use any of the BIM-enabled specification systems, but I can’t wait to get started.  BIM’s potential for better, faster construction document production seems fabulous to me. I don’t have a clue about the details of construction document workflow in a BIM-enabled spec system, but I’m trying to absorb as much about BIM-specs as I can until I get a chance to work with it. 

Some in the specorati have expressed concern that linking BIM and specs will make spec writers obsolete, primarily because some of the specification system marketing claims will probably leave naïve AE executives with that impression.  I don’t think spec writers will disappear any time soon, though, and here’s why:

• Most architects using BIM will still need assistance with specification/product matters.  I know some extremely able and productive architects, but it’s too much to expect that they can deal with what’s already on their overflowing plates, and be responsible for all of the embedded spec choices in the model.
• Architects are fascinating, creative, resourceful problem solvers, but most of them are much less comfortable with words, writing, than they are with graphic means of expression, drawing.  This often manifests itself in their avoidance of reading text, seemingly on the ground that if something is typed neatly, it must be correct. Somebody has to be responsible for the fine print in the model and how it meshes with specs, and I think spec writers will claim a considerable share of that work.

In ten years (or maybe sooner) when BIM-enabled specs have become commonplace, my MS Word spec processing routine will probably look as primitive to us as the punch card system of the 1970s looks now.

SPEC WORD PLAY: WHEN IS A DRAWING NOT A DRAWING?

The answer seems to be “when it’s a sheet.”

The strangest little things irk me, and one of them is the use of the word “sheet” to refer to “drawing.”  You encounter “sheet” everywhere in AE conversation and writing.  Even the “Drawing List” on drawing cover pages is often titled “Sheet List.”

I confess that I’ve never heard of a problem arising out of the use of the word “sheet” on a construction project.  I’m probably the only person that’s ever noticed it.  I commented on this in a recent Northern Illinois CSI Specification Roundtable teleconference, and judging from the silence on the other end of the teleconference, the rest of the participants were decidedly underwhelmed by my concern.

But correct usage matters, especially in writing.  My schoolteacher mother and my attorney father convinced me of that.

In a conversational setting it’s fine to refer to drawings as sheets, but formal AE project communication should use the term “drawings.”

Why?  In AIA A201 – General Conditions of the Contract for Construction, the definition of the contract documents includes “drawings”, not “sheets.”

I just did a word search for “sheet” in A201. Result: zip.  The word “sheet” doesn’t cut any mustard with the wordsmiths at the AIA.  Searching for “drawing” resulted in many hits.  I stopped counting somewhere in the twenties.

I rest my case.

REVIEWING MY ANDROID PHONE

Aaron Chusid’s blog post a while back about the impact of smartphones in general, and his iPhone in particular, got me to thinking about my Android smartphone. It’s an HTC Desire from U. S. Cellular. I’m still learning how to use it. 

Although I’ve had cell phones for years, the HTC Desire is the first smartphone I’ve ever had. Years ago, In 2005, I opted Instead for a PDA, a Hewlett Packard iPAQ (sans phone) which has a pretty good calendar and to-do list, so-so document generation using Windows Mobile, clumsy synching with my PC, mediocre email functionality, and clunky internet access. Solitaire’s pretty good on it though. I used the PDA daily until I got the Android, and I just about wore it out.  Its screen is now as faded as a twenty-year-old TV.

I can’t tell you that I did an exhaustive analysis of features before I settled on an Android phone, but I considered all the possibilities for several months. I looked at and admired the iPhone, but I didn’t want to switch cell phone carriers. I also considered a Windows phone, but I didn’t want any of the older versions of Windows Mobile, and I didn’t want to wait several months for a phone equipped with the latest Windows Mobile. I was also pretty bummed out about the clumsiness of Windows Mobile on my PDA. I like Google products and iGoogle is my home page on my home desktop.  That tipped the balance toward a Google Android phone.

Since this is a personal phone, I rarely use it for business calls. Almost all of my phone usage is personal. Probably 95% of my overall usage is for time management, email, Internet browsing, news, weather, etc.  I have downloaded many apps, discarding some and retaining others.

So here are the strengths and weaknesses of this Android smartphone as I see them:

• Phone calls:  Works well.  No dropped calls. Speaker phone works great.  Easy, intuitive screen for dialing.   

• Email:  Excellent.  I use it to access my work email, personal gmail, and home email.  Attachments come through fine.

• Messaging:  Excellent.  Makes it easy to send and receive messages. 

• Internet:  A great experience.  Easy to navigate, fast, visually stunning screen.  HTC’s built-in bookmarks don’t work, though, so I downloaded an app called ChromeMarksLite which gathered the hundreds of bookmarks I’ve accumulated over the years.  The quality of the Internet experience on this device has made me even more of an Internet junkie than I was before.

• Calendar/Time Management:  Pretty good, but not as good as my old PDA. I’m determined to integrate my to-do lists with my Google calendar.  I just downloaded an app called Shuffle to help with this and I will learn how to use it soon.

• Typing:  Tiny keys on the HTC Desire's virtual keyboard make typing laborious.  The predictive text and my occasional failure to correct the Android when it assumes the wrong word, result in some hilariously incorrect words.  I almost wish I had waited for a device with a slide-out physical keyboard.

• File Management:  I’m still struggling to understand file management on this thing.  I downloaded Astro on the recommendation of a colleague at work, and I’ve been too busy or distracted to sit down and learn how to use it.  I seem to spend an inordinate amount of time managing the apps to “clear data” and “clear cache” so incoming messages don’t get blocked.  Maybe I’m just lazy, but it seems to me that this should be automatic. 

• Battery Usage:  The Achilles heel of the Android. I use this thing constantly, and it will rarely go more than 14 or 16 hours without a charge even when most of that time is just standby. I downloaded and use an “app-killer” to turn off the apps when the phone is on standby, but even so, I’m constantly checking to see how much juice is left.  Blog commenters seem to be saying that some of the battery use problem is also due to Google and the app developers constantly turning apps on to data-mine users’ location and Internet activity for purposes of targeting advertising.

• Document Generation (Writing):  Decidedly worse on the Android than the HP iPAQ, which has a virtual keyboard and a stylus.  I had hoped that the Android would work well with Google Docs, but alas, it doesn’t.  I’m using Google Docs and QuickOffice, which are both clumsy, and together with file management issues, have me rather frustrated.

• Camera:  Still camera is excellent, and works well with Google’s Picasa.  Video recorder is mediocre.

• Blogging:  Haven’t tried posting to my blog with the Android yet, but that’s on my to-do list. 

• GPS Navigation:  I attach the phone to a cell phone mount on the car’s dashboard. Maps, graphics and directions are crystal clear for a driver’s viewing, but the audio directions are kind of wimpy and hard to hear even with the audio all the way up.  Directions are pretty reliable except when the destination is in a strip mall or on a side street the GPS doesn’t recognize.

Bottom Line:  I’ve had the HTC Desire Android phone for about five months now and I give it a B-.

LINKS EVERYWHERE

When the Northern Illinois Chapter of CSI was founded 28 years ago, the Chapter newsletter was named the CSI LINK.

Richard Ray, one of the founding members of the Chapter, said in a talk with Chapter members last May that the newsletter name was chosen to reflect the links between professional and industry members, i.e. members working as design professionals, and members working on the industry or product side of the business.

Rich and his colleagues really got the name right. Their objective of emphasizing the links between professional and industry members was laudable. (For a view of how the professional/industry dialogue is playing out now, click here to read Sheldon Wolfe’s articles about the upcoming ballot proposition dealing with CSI membership classifications.)

In addition to the links the Chapter founders had in mind 28 years ago, other links abound in the AE business.
• Drawings are inextricably linked to specifications to form construction contract documents.
• Soon it will be common for information in project spec files to be linked to project drawing files with interoperable software, and combined in the Building Information Model (BIM).
• Integrated Project Delivery contract arrangements seek to deal with the age-old adversarial relationships between Owners, Contractors and Design Professionals by linking the principals together in a cooperative agreement.
• The CSI LINK newsletter itself is now distributed primarily as a PDF document. When each issue is ready, our electronic document Chair Pete Dinschel sends out an email message with a link to the newsletter.
• Many industry magazines and newsletters keep us informed by sending out emails with headlines and brief synopses of articles which the reader can fully access by clicking a link.
• Et cetera, et cetera, et cetera, as Yul Brynner’s character the King of Siam said in The King and I.

Searching for an appropriate metaphor for these links, I first thought of a chain with links. Linear, simple, one link fastened to the next.

But the more I thought about it, I realized that the linkage we’re dealing with now is multi-dimensional, sort of like the structural members of a geodesic dome or a space frame of some kind.

MEANINGLESS FILE NAMES: DON’T GET ME STARTED…

How many times have you received a file with a nonsensical name?  It’s usually sent to you by someone who doesn’t take the time to put much information in the email subject line, either.

Something like:

• digitalimager@xyzncdksjhuhg.com_20101110_1030745*
• or supercallifragillisticpro.doc

 What can it possibly be? 

• A spec section from a consulting engineering firm?
• A PDF including several spec sections?
• A PDF including several drawings of the food service equipment for that cafeteria remodeling you’ve been working on?
• The geotechnical report for your new hospital addition?
• A manufacturer’s guide spec for a product you want to specify?
• Meeting minutes for an upcoming project?
• The Magna Carta?

Please have a little consideration for future users/readers of the document.  Choose a file name that reflects the contents of the document.  It’s not hard to rename a document, I promise.

If you don’t, I probably will, especially if the document is to become part of one of our Project Manuals.  Most of our Project Manuals are now being distributed in combined PDF form as well as hard copy.  We enable bookmarks in the combined PDF to make it easy to navigate through the document, so it’s important that each document have a name that makes sense, and that enables it to be put in proper order corresponding to the Table of Contents.

AND NOW FOR SOMETHING COMPLETELY DIFFERENT

As a colleague and I at the office were discussing the trials and tribulations of being architects, he reminded me about the Monty Python architect sketch. 

Whatever you do, don’t view this just before an important presentation to a potential client.