What’s a hiker to think? You can see the summit from here, the hiking trail guidebook says the trailhead is up here somewhere, but the street signs don’t match the road names on the maps or in the guidebook, and now you see these conflicting signs on what you’re pretty sure is the right road. The green sign at the beginning of the road says “Private Property Beyond This Point, No Trespassing,” which usually means that one should not proceed. End of story, right?
Well, there’s another sign, farther away, up this same road. That brown sign says “Respect Private Land, Stay on Main Road,” which implies that it’s actually ok to proceed up this “No Trespassing” road, but only if you don’t veer off the road. Then, of course, there’s that little tacked-on “No Parking” sign, which implies that it’s ok to drive up this road, but only if you don’t park on it.
I’m a rule follower, so these conflicting signs confound and paralyze me. Surely we’d never create anything as confusing as this in the construction industry, would we?
I did a whole bunch of invoicing last month, because I had a ridiculous amount of work in April. I took a good, hard, look at my time on one of those projects, and confirmed my suspicions that I’d gone waayyy over my budgeted hours on this lump-sum-fee project. Wow, what a deal my client got, right? All those extra hours spent making the specs perfect? Well, not exactly.
Every few days while I was working on the project, I was sent a digital pile of information by my architect-client, who received stuff from the owner team. Many of these documents conflicted with each other, sometimes giving as many as 3 different conflicting instructions for one thing. I spent a lot of time trying to reconcile all the different directives – time that I actually needed for other things, like product research for the project, coordination for the project, work on other projects, family time, and sleep.
As most of the info was related almost solely to the specifications, and it came from the owner team, who should have known what they wanted since this wasn’t their first one of these buildings, the architect didn’t spend too much time reviewing it before forwarding it on. So my questions about this info were confusing to them, and, for some reason, some were unanswerable by the owner.
I’ve never been on the contractor team for a project, but I think I know how estimators feel when the architectural drawings say one thing, the structural drawings say something different, and the specs say a third different thing. An estimator may want to just take the risk of pricing what makes the most sense, and hoping it’s right. Asking questions during the bid period is sometimes an inefficient use of time, and experience may show that some answers aren’t worth the time spent. Perhaps this is why the design team sees surprises when submittals come in.
Back to that hike. As it turns out, if you can get to a place where you can receive a strong enough cellular signal, and you can look at a satellite view of the area with the conflicting signage, you can figure out whether or not you were on the right road to the trailhead.
Or maybe you skip that research, you just take that risk of trespassing, and you drive up that road. It’s a rutted 4-wheel-drive road, so you are hoping it’s the right road because it’s going to be a rough ride.
Turns out the trailhead and parking area are a half mile up that road! Apparently, you just have to ignore that first sign.
What a terribly inefficient standard operating procedure for communications of any type. Issuing conflicting instructions to a group requires multiple parties to either all risk making the wrong guess (and risk losing time or money), or all spend time doing the same research to figure out which of the conflicting instructions is the intended one. Whether the group you’re trying to communicate with is hikers, bidders, or your design team, isn’t it best to just issue clear, concise, correct, and complete information the first time?
Or maybe we could just shoot for non-conflicting.
Comments From a Spec Writer 
Excellent post Liz and absolutely on point.
Thanks!
Yes, excellent post. It takes less time to do it right the first time instead of returning to the task for repairs and repeated efforts.
Thanks!
From a reader who emailed me:
Your last “blog” or whatever you call it “Mz.” Liz got me to thinking. I felt your tension. Every day on my way to work I experience a dread that is almost inexplicable. It has to do with this love/hate relationship I have with being a “specifier.” The hate part has to do with how amazingly hard, difficult, time consuming, etc. the process is. Is that just a perception? Or is it the reality? I think it’s a little of both? Don’t you?
A friend at work many years ago told me that preparing a decent spec for a project takes twice as long as sitting at the computer tapping keys, scrolling, clicking you finger on buttons and moving your hand to and fro. My experience has led me to believe that’s a fair description of the process. If I’m preparing a specification for a project I know nothing about, I need some time to study the drawings, talk to whoever the person is on the team that gives a rat’s ass for … excuse me, the person assigned to the project to prepare the project manual, maybe a different person or two assigned to the various technical sections, someone to do Divs. 00 & 01. (Am I dreaming?)
Having described the shell of the process, then one can assign an economic model to it. I thinks it’s fair to say that most proposals put out on the market by most A/E firms break “specs” out as a single line item, probably for the various phases of the project – P, SD, DD, CD and so on. I don’t believe that the way the model is budgeted quite fits the process model.
So. There’s still room for improvement in the A/E industry. Still ways to improve productivity on the technical side of design and profits too.
Mike
R N L
Liz,
You are spot on with this process. It not only impacts the Spec Writers and Estimators but also the construction management team. The management team then spend countless hours chasing RFI’s, and Change Orders in order to finalize the project submittals and material procurements. Which adds another burden to the design team reviewing the additional documents asking for clarification. The end result is delays to the project delivery.
Keith Holle, CDT
Glass and Glazing Professional
Perhaps these extremely basic communication issues have something to do with the construction industry’s lack of growth in efficiency and productivity over the years, as compared to other industries.
I think that everyone except the A/E part of the AEOO equation has moved forward. Too many “old-style” Architects (in control of operations and in managerial positions) want to cling to the old methods of producing a set of Construction Documents no matter what the technology is doing to advance our methods, and how new delivery systems are impacting them. They think they are artists, not in a business at all. I have to beat design teams with a stick to read the Procurement and General Requirements. They don’t have a clue what they mean or how they relate to the technical sections.
Hi Liz. I’m a new spec writer in New Mexico. Do you have any tips for how to keep my work on individual projects organized? Should I develop a spreadsheet? There are so many pieces to these massive projects and so many people involved. It’s very challenging keeping everything straight. Thanks!
Hi, Tom, I organize my projects in my computer files pretty much the way I organized projects while I worked as an architect. (A folder for each project, different folders within it, one for drawings, one for other info, one for old submissions, etc. Within the drawings folder, there may be a folder for SD, one for DD, one for CD, one for construction.) When the project is finished, the project folder goes in a folder with other completed projects from that year.
I’m not sure that spending the time developing and maintaining a spreadsheet would help much, unless there are specific pieces of info that you want to track from project to project and need to stay on top of.
I do best when I work in bursts on one project at a time – rather than spend some time each day on several projects, I spend nearly all day on one project, then work on the next when it’s more pressing. This keeps one project, and all its various moving parts, at the top of my mind.
I keep a project directory in each project folder so I know who the team players are.
I rely heavily on the Table of Contents that I develop and edit along the way – if a section that I know we need for a project isn’t complete or included at a progress set, it still shows up in my TOC, but with a note that it’s not complete or not included in the set. I include notes in my spec sections, too, highlighted in yellow, so everyone knows if there’s an outstanding issue in that section.
I rely a lot on Outlook’s great search function for email, and I organize projects in Outlook, too – after an email’s content has been dealt with, it can go in the folder for that project.
I use a time tracking app, Harvest, to track the time spent on each project.
I hope this helps some, and if you have more specific questions that you think I may be able to help with, feel free to post!
Thank you, Liz, that’s very helpful. I’ve got another question for you. At the beginning project design stages, do you use a specifications checklist as you meet with A/E’s to determine which specs will likely be included on the project? Is there a particular product out there that meets this need? It seems there should be a simplified checklist method that should be used for every project.
Thanks!
Hi, Tom, regarding your question about a specifications checklist, I almost always prepare a preliminary table of contents with my fee/services proposals. I use that preliminary table of contents, along with the latest drawings, and responses from the architect to my questions as a guide when I prepare the first progress set of specs. I use MasterSpec, so I use the latest table of contents from MasterSpec to prepare my preliminary table of contents. Many other specifiers have developed their own checklists that they use for their initial meetings with the architect. Here’s one in-depth discussion about that, and other processes, that people use: http://discus.4specs.com/discus/messages/7463/5179.html The discussion group on 4specs.com is a great resource.
Thanks again, Liz. I’m 3.5 months into this career, having worked as a copy editor and writer for consumer publications for most of my career. I’m getting the hang of it. The most interesting part of this work is being able to support such a talented group of professionals.
Good luck with the new work! CSI Albuquerque has many wonderful members, so get involved, meet some of them, go to meetings, if you haven’t been already. Hang out with other people who write specs. Many specifiers in the US got their start in something other than a design profession.
Tom, one more thing – this just popped into my inbox – a free webinar from CSI on checklists, in the Specifying Practice Group. https://attendee.gotowebinar.com/register/1116247674098686722?_cldee=bGl6QGxpem9zdWxsaXZhbmFyY2guY29t&recipientid=contact-df1125367007de11bd100019b9e160b2-427ec25aee0a4d3e9f1f9673289f4db4&esid=f718d402-32e3-e611-ae31-00155dc6a703 It’ll be on February 2, 2017.
Cool, thanks Liz. That looks perfect. I just registered.