Trends in Drawing/Specification Coord...

Log Out | Topics | Search Moderators | Register | Edit Profile

Author Message Andrew Wilson New member Username: awarchitect Post Number: 1 Registered: 08-2005 Posted on Wednesday, August 03, 2005 - 07:41 pm:    2 topics I'd like to throw out for feedback, experience, thoughts, potential obstacles, lessons learned, etc., regarding the coordination of drawings and specifications: Topic 1: The role of project architects in preparing their own project specifications. Background: Many offices are encouraging PA's to edit (notice I did NOT say "write") their own project specification sections from masters prepared an maintained by trained and experienced specifiers in lieu of depending upon in-house specialists or out-of-house consultants to prepare project specifications. The theory is that doing so will both reduce the amount of drafting (and overdrafting) time and improve the coordination between the Drawings and the Specifications, and by extension the overall quality of the Contract Documents as a whole. Question: Is this a good idea? Does this approach actually improve the coordination of the Contract Documents as intended, or does having the project team prepare their own specifications create more problems than it solves? Topic 2: The role of future software trends in the practice of preparing specifications, or as I like to call it, the "If your only tool is a hammer, then all of your problems are nails" discussion. Background: Software manufacturers continue to pursue the aim of creating software that effectively links the electronic drafting tools and specifications editing tools to a common drawing/specification database file. This seems to be trend for the near future. Questions: Is this a grail quest or a reality on the horizon to be addressed? Will architects by necessity (because of the changes in software) be forced to learn more about editing specifications? What will the role of the specifier be when specifications are generated from data in the drawing file database? Will it be necessary for specifiers to re-acquaint themselves with drawing tools and crossover into a larger production role? These are topics I think about nearly every day on the job. Would love to hear feedback, war stories, theories....anything on topic you'd care to share. Thanks! William C. Pegues, FCSI, CCS Senior Member Username: wpegues Post Number: 439 Registered: 10-2002 Posted on Thursday, August 04, 2005 - 12:54 am:    Andrew, I think if you browse some of the other threads here you will find these topics pretty well discussed. Not that doing them again is a bad thing, but you can see how some of the discussion has evolved over time by the date of the posting. William Anonymous   Posted on Thursday, August 04, 2005 - 08:42 am:    Topic 1-- The alternative to having the Leads edit the masters is to "download" project information to the spec writer; time consuming and may not catch or reflect all items and latest changes in scope, materials, details. The Lead is the person who best knows the project and ALL of it nuances and details. Editing can act as a checklist for those folks as well as triggering spec changes which might otherwise be missed. Further, the Lead usually is the person [perhaps with others] who makes product/system selections that are appropriate to the project circumstances. Also allows spec writer to engage more heavily in other aspects of specifications-- legal, data collection, wording, numbering, product research and correct provisions in masters. Anne Whitacre, CCS CSI Senior Member Username: awhitacre Post Number: 230 Registered: 07-2002 Posted on Thursday, August 04, 2005 - 12:27 pm:    I might note also that these "trends" have been around longer than I've been alive. (and I'm over 50 now). When I first started working, the architects in my office used this "self-editing" spec package that allowed them to cross out and highlight sentences that were sent to a typist. We used some transparent coversheet that could be marked up so that the master wasn't marred in the process. And the drawing/spec software --- go back 25 years to ConDoc, which was supposed to be the answer to coordination problems. it wasn't. In general, every project needs two types of people, and they typically can not be the same person. 1) one person knows the project inside, outside, backwards and forwards. 2) one person has a wider view of industry trends, products, editing, codes and the like. Information has to go from one to the other. I think project architects editing their own specs is a bad idea except on very small projects -- the drawing crunch and the spec crunch occur at the same time and no one can do both. I think a spec writer brings more to the table than simply "specs". But, as has been said, that discussion ... has been discussed. Andrew Wilson Junior Member Username: awarchitect Post Number: 2 Registered: 08-2005 Posted on Thursday, August 04, 2005 - 02:02 pm:    I don't question the specifier's role (that of specialist) or the general need for such a specialist, whether in-house or retained as a consultant; nor do I underestimate the experience, viewpoint, breadth of scope or focus a specifier brings to any project, large or small. Anticipating discussions similar to my post were thoroughly covered by other threads, and not wanting to re-tread well-worn paths, I discussed my thesis with the moderator prior to posting. And having read a few initial responses, perhaps I misidentified my topic and should clarify: The thread I was hoping to start was a little different, so please allow me to expand by rephrasing. 1. Presumably other threads have covered the idea of having architects edit or write their own specification sections - and the predictable limits of the resulting conversation were most likely either that it IS a good idea, or it IS NOT a good idea. If, in fact it IS NOT a good idea, then the result is self-evident: retain somebody to do so for the architect either internally or on a consulting basis. Since we are all aware of our self-worth as in-house specifiers and out-of house specification consultants, further discussions in this area merely affirm what we already believe. Time can be better spent on other pursuits. But for the sake of argument, let's suppose it IS a good idea, that there IS inherent value in this course of action, both to the project and to the profession of architecture. (Clearly there are people who continue to think this approach is not only a good idea, but also necessary given today's ever increasing time and budgetary pressures, else these trends would have died long ago.) In such an environment, what roles would we then play as specialists? What approach should we take with the project teams in helping transition them into preparing their own project manuals? For people who have tried this, what were some of the obstacles encountered and how were those obstacles destroyed? Or were they never overcome? This is the discussion and feedback I was looking for when I made my post. 2. Ditto for technology. In an era of de-centralization, distributed networking and "mass personalization" (i.e., podcasting, tivo, etc.), I cannot understand why, technologically speaking, there is a push in our industry to go the other way and rush to put everything into one basket. But there is; and taking into account my view that the tools available for us to utilize help to frame the way we solve our problems, my interest is one of exploring how this centralization trend in our industry shapes the way we view going about our work as specifiers. Someone out there thinks things like architect's generating their own specifications from a database of information shared or linked to a parametric 3-dimensional database which in turn is also linked to drafting and drawing tools, and ever increasingly, to additional data post-processing outputs (stereolithography, advanced manufacturing and even GPS-based building layout) is a good idea. So much so that they are spending millions to promote the idea, create the tools and bring them to market. And we as design professionals and consumers are stuck with what is available. Though (and experience has shown this to be valid) we can be skeptical and deny these trends and go about our business, confident they have never gotten traction in the past, and probably never will, I was hoping, again for the sake of argument, to assume for a moment these trends have taken hold. How would we help ourselves during such a transition period? If we are following good leadership and management advice, how can we "train our replacements" when the nature of our own role is changing? Can our role change? Should it change? How? Would really love to have an exchange on these sorts of issues if you'd care to post. If with this most recent post I am still covering ground that is well trodden, I’ll remove myself from posting on this topic and spend my time sifting through the discussion board for the answers I seek. Thanks again! T.J. Simons, CSI, CCS New member Username: tsimons Post Number: 1 Registered: 08-2005 Posted on Thursday, August 04, 2005 - 07:47 pm:    Andrew: I am in a unique position, having been on both sides of the fence, so to speak. For ten years I was a dedicated spec writer in a couple of large firms doing institutional work (said firms ended up blending into one about 18 months ago). Since then, I have joined a small (30 persons total) firm, where the Project Managers/Project Architects (including me) are responsible for editing project specs. Because of my background, I also have primary responsibility for development and maintenance of the office master. I can see benefits and drawbacks to both methods, and I think I have a pretty good handle on how an experienced specifier can work in both scenarios. Regarding the BIM systems and spec-drawing software links, my experience is limited, but I do have some thoughts which I'll share. More info in further posts as time permits. Kenneth C. Crocco Senior Member Username: kcrocco Post Number: 29 Registered: 04-2003 Posted on Tuesday, August 09, 2005 - 01:31 pm:    I would like to make a couple of observations regarding presuppositions before actually addressing your two topics. Topic 1: Project architects developing their own specifications. There are two questions: Is the architect capable of performing this service; and does the project architect have the time necessary to devote to this service. If the answer is no to either question, the project architect is cheating the client. I have seen elsewhere on the discussion boards the concept of finding ways to save time and fee dollars in the performance of our professional duties. I wish my lawyer would do the same, however, I don't wish that my doctor would think that way. If I were building a building and my architect told me I can save you fee dollars by having a project architect do double duty, I would hire someone else who could devote proper talent to the proper service. The point about having one person perform these two services to improve coordination is not persuasive to me. The best coordination occurs when a capable project architect works closely with a capable specification writer; each one an expert in their respective role. Topic 2: Software systems have a way of getting us away from the main purpose, which is to design a building for a client within their available resources. When we stand back and look at the building or walk through the building, we know how successful we've been. I am old enough (and that is not too old) to have seen paper drawings with pencil written specifications typed by a typist; transition from those forms to cassete recorded specifications, partial CAD and partial manual drafting, to total CAD, hand editing of specifications with dedicated word processing, transition to full word processing. The point is we've been transitioning for 27 years (1978 beginning of desktops). If you remember what the preacher said, "There is nothing new under the sun." In terms of what our service is, nothing of essence has changed in terms of roles. Getting to your question of roles: there have been talented artistic designers and talented technical consultants since the beginning of our profession. I have seen some abuse of the word processing and CAD software systems we now have due to the neglect of the primary roles: artistic designer and technical consultant. It's not as important how the project is delivered as is the performance of these two fundamental roles for a successful architectural project. I know this is straying from your question, but these are my presuppositions. For electronic technology to be considered a good idea, are you saying it is a good idea for architecture or a good investment idea. The people investing millions in these trends believe it will sell. I believe they will sell and will help produce great architecture in the hands of great architects. Unfortunately they will also help produce poor architecture in the hands of poor architects. From a marketing point of view it may be a good idea, because at least it will sell. The electronic technology is the "equalizer", but it emphasizes the difference in talent and skill: the talented are able to reach greater heights while the untalented cause greater problems. We need the talent and the time to do the job with the available tools. J. Peter Jordan Senior Member Username: jpjordan Post Number: 106 Registered: 05-2004 Posted on Wednesday, August 10, 2005 - 10:29 am:    One of the underlying concepts behind some of the more advanced computer software developed for the AEC market is that it captures skill and knowledge. Many of you may remember spending hours learning to hand letter and then your first one or two jobs you got (or didn't get) because of your lettering. CAD/D supplants that skill with software that creates beautifully "leroyed" or "hand lettered" annotations. The knowledge it takes to select which note to use or to create the note in the first place is the next task. Office design standards and those provided by clients encode such knowledge, externalizing both the knowledge and the rule base by which it is applied so that it can be used by those with very little training. Some of you may remember one of the allures of "cut-n-paste" drafting was that a "drawing" could be assembled by a graphic arts technicial instead of an experienced draftsman. I have found the research in this area very interesting, but have rarely seen useful applications. The basic rule of automation/computing is GIGO "garbage in; garbage out". A corollary I came up with 20 years ago is when you automate a mess, you get faster messes. In my experience, few architects are able to externalize a knowledge base to where it can be automated; there are too many pieces and too many rules. There is also a bias on the part of many architects that if and when you can automate design process or some aspect of the process (like writing specifications), that part is no longer "valid design." It's the same argument that many designers make about computers, "You can't design with a computer." If you can externalize knowledge and rules, maybe design isn't magic after all. Project architects are the in the best position to produce a good specification for the project. They should know the project inside and out, the visual quality and the technical functionality; even the parts that have not yet been drawn. Unfortunately, they have some of the same scheduling problems that all of us have--too much to do and too little time. Moreover, most of them are more oriented toward graphic information, not toward verbal information. They have little understanding of the forms and formats of specifications, and little inclination to learn. They are frequently only dimly aware of some of the fundamental concepts and are not sure what goes in and what stays out. When combined with scheduling problems, the product is frequently lacking. The Project Architect's response when caught is usually not to improve the specification, but to put more information on the Drawings (which sometimes is what caused the problem in the first place). So we help the Project Architect by automating the first part of the process by having a computer routine which will assemble a 1st draft of the specification. The success of this largely depends on how complete the Drawings are and how accurate the annotations are. Will the software be "knowledgeable" enough to know that Sheetrock, gyp board, gypsum wall board, and gypsum board are the same product? Does the Project Architect know that there is a difference between lightweight concrete and lightweight insulating concrete? Although encoding all of this into standard notes and specifications sounds good and can be efficient in a well run practice, I have observed that it hinders some of the transfer of knowledge between the "silver foxes" and the "young guns." There is an advantage to drawing and redrawing a standard base flashing detail at a parapet (even on a computer). I learned a lot about materials by copying a freehand sketch detail and then drawing it over and over. It's not the same to copy a whole block into a drawing. I have also learned a lot by editing the same section 2 or 3 times a year. The more we automate, the more we bypass this traditional learning method which is one of the fundamental building blocks of apprenticeship/internship. Experienced architects and specification writers have the responsibility, in my view, to transmit a range of information and knowledge. It is frustrating to have to transmit the same basic information over and over again without getting to a more sophisticated level, but it has to be done if the design profession is to survive. I don't believe that simply automating a task or a series of tasks is the answer. I recognize that there are immediate benefits, but I am leary of the long term consequences. Dave Metzger Senior Member Username: davemetzger Post Number: 124 Registered: 07-2001 Posted on Wednesday, August 10, 2005 - 11:26 am:    Back in the days of hand drawings and hand lettering, you could look at a detail or a shop drawing, and have a pretty good sense of the technical quality of the detail based just on the graphic quality of the drawing. Computer drafting and lettering has changed that--computer drawings generally all look good, and you have to dig deeper into the detail to see if it really works. I suspect that the same will be true of automated drawing-specification coordination. On the surface, the 50-60% automated spec may appear OK, but it will still take someone with experience and judgement to go into it in detail and really craft it into a project-specific section that is coordinated not only with the drawings but also with the other specification sections. Fore example, if multiple components of the project (storefront, entrance doors, windows, skylights, louvers) all have the same PVDF finish, is it better to specify the finish in a single section which is cross-referenced with the sections for the individual components? Or to specify the finish multiple times, ie in each component section? There is not a single answer, and software can't make that decision. Richard Howard, AIA CSI CCS Senior Member Username: rick_howard Post Number: 54 Registered: 07-2003 Posted on Wednesday, August 10, 2005 - 11:43 am:    There is an article in AIArchitect on the evolution of drawings from hand-drawn to CAD that has some interesting observations of how that has changed practice. http://www.aia.org/aiarchitect/thisweek05/tw0805/tw0805bp_risk.htm John Bunzick, CCS, CCCA Senior Member Username: bunzick Post Number: 392 Registered: 03-2002 Posted on Wednesday, August 10, 2005 - 11:53 am:    I agree with Peter on the limitations of time for a project architect to produce their own specifications--there just isn't enough. The same logic could apply to many design tasks: the PA is in the best position to draw all of the wall sections, because she understands what all of the components are intended to be. Obviously the PA can't do it all, just because they have the most comprehensive picture (or at least are presumed to). This is where "management" comes in, since there will be many people who are involved in putting together the project. The PA, or PM depending on how the team is organized, must spend the time to make sure that the information is properly flowing. Usually the more successful approach is one that utilizes in-place systems to make sure that this happens, whether the systems are formalized in a quality assurance manual, or whether it's just part of the culture of the organization. Furthermore, everyone on the team needs to be inculcated with the understanding of how the decisions they are responsible for affect the overall project and the work of other members of the team. If the person designing the restroom interiors decides to change from ceramic mosaic to thin stone flooring, but fails to inform the specifier and the person preparing the finish schedule,... well, you get the idea. Architects (of which I am not one, by the way) seem to be taught and expected to be very good at just about everything related to designing a building. How can this be? Doctors have specialized areas of practice. Even attorneys have specialized areas of law. Architecture firms need to figure out--especially the middle sized ones, since I suspect larger ones already have--how to organize themselves with this in mind. So, specification preparation is one of those specialties, as could be argued is contract administration. The "master architect" is an unsustainable model, in my opinion, and this is what's expected of one who must do their own specs. Wayne Yancey Senior Member Username: wyancey Post Number: 42 Registered: 05-2005 Posted on Wednesday, August 10, 2005 - 07:49 pm:    Peter, I agree with everything you said. Must the Hawaiian experience. The "hang-loose" frame of mind. Before I learned the craft of being a specifier, I was trained as an architectural draughtsman (draftsman). I have used lead on paper, ink on paper, ink on linen, ink on mylar, Leroy, Lettraset, Kroy, systems drafting, pin bar drafting, etc. I have performed as a grunt draftsman, a job caption, a project coordinator, specification writer, singly and in combination, and contract administrator. My favorite projects were those small enough where I am the CAD drafter, specifier, project coordinator, consultant coordinator, and finally contract administrator. I go like hell on the drawings and then go like hell on the specs, coordinate, then wrap it all up. Some drawing tasks are assigned to others, such as exerior elevations, interior elevations, architectural woodwork. I took ownership of the building sections, wall sections, plan section details, vertical section details, floor plans, roof plans, RCP's, door opening schedule, window opening schedule, louver schedule, and room finish schedule. It amazes me how some people can screw-up a clear and concise schedule. I had project Architects who gave me design intent with clear hand drawings. I solved the technical issuses. At the end of the day I have a well coordinated set of bid documents with consistent terminology. Not perfect, but close as damn is to swearing. But I ramble. My recent experience has been others dabling in specs or performing CA who are grossly inadequate in their knowledge of what is in the project manual and where to find it. On Monday, a PM could not find the portland cement plaster section in division 07. I shook my head and told the PM to look in the table of contents if all else fails. People who should know better never cease to amaze me. Take them by the hand a lead to the chapter and verse. It pisses me off. My condecending attitude pisses them off also. The older I get the less I suffer fools. To quote Shakespeare "Thou damned trip-visaged rascal" or how about "You scullion! You rampillian! You fustilarian! I'll tickle your catastrophe!" Wayne Wayne Yancey Senior Member Username: wyancey Post Number: 43 Registered: 05-2005 Posted on Wednesday, August 10, 2005 - 07:51 pm:    Peter, I agree with everything you said. Must the Hawaiian experience. The "hang-loose" frame of mind. Before I learned the craft of being a specifier, I was trained as an architectural draughtsman (draftsman). I have used lead on paper, ink on paper, ink on linen, ink on mylar, Leroy, Lettraset, Kroy, systems drafting, pin bar drafting, etc. I have performed as a grunt draftsman, a job caption, a project coordinator, specification writer, singly and in combination, and contract administrator. My favorite projects were those small enough where I am the CAD drafter, specifier, project coordinator, consultant coordinator, and finally contract administrator. I go like hell on the drawings and then go like hell on the specs, coordinate, then wrap it all up. Some drawing tasks are assigned to others, such as exterior elevations, interior elevations, architectural woodwork. I took ownership of the building sections, wall sections, plan section details, vertical section details, floor plans, roof plans, RCP's, door opening schedule, window opening schedule, louver schedule, and room finish schedule. It amazes me how some people can screw-up a clear and concise schedule. I had project Architects who gave me design intent with clear hand drawings. I solved the technical issuses. At the end of the day I have a well coordinated set of bid documents with consistent terminology. Not perfect, but close as damn is to swearing. But I ramble. My recent experience has been others dabling in specs or performing CA who are grossly inadequate in their knowledge of what is in the project manual and where to find it. On Monday, a PM could not find the portland cement plaster section in division 07. I shook my head and told the PM to look in the table of contents if all else fails. People who should know better never cease to amaze me. Take them by the hand a lead to the chapter and verse. It pisses me off. My condecending attitude pisses them off also. The older I get the less I suffer fools. To quote Shakespeare "Thou damned trip-visaged rascal" or how about "You scullion! You rampillian! You fustilarian! I'll tickle your catastrophe!" Wayne T.J. Simons, CSI, CCS Junior Member Username: tsimons Post Number: 2 Registered: 08-2005 Posted on Friday, August 12, 2005 - 10:03 am:    My thoughts on PA's/PM's writing specs: First, not everyone can do it, even some folks who are pretty experienced. Some people in our profession are so heavily graphic-oriented in their thought process, editing a lot of text is overwhelming and intimidating. I've also noticed that some architects have serious difficulty doing what I call "taking the project apart in your head"-in other words, thinking in terms of assemblies and systems, which to me is immensely helpful in editing and coordinating the Project Manual. Any firm expecting their PA's or PM's to produce specs must commit to providing some training in spec editing, across varying skill and experience levels. You can't just turn them loose with MasterSpec. Regardless of the source doc, the office master should be even more "user-friendly" than one used by experienced specifiers. The master should be appropriate to your practice, of course, but consider limiting the editing options in certain Sections-this will limit inappropriate choices. Also, editor's notes should be very clear and specific. I am doing quite a bit of work on ours to beef things up in those areas. There are a lot of benefits to this approach, which have been addressed in other posts, so I won't repeat any of that. I think the biggest quality issue when doing it this way is consistency between projects, and I'll let others on the forum with more experience in that area speak to those issues. My personal (and very subjective) opinion is that this is more easily done in a small (35-40 people or less) office. In a larger firm, I think a dedicated spec writer (or group of spec writers) is usually the way to go. More on that another time. John Regener, AIA, CCS, CCCA, CSI, SCIP Senior Member Username: john_regener Post Number: 221 Registered: 04-2002 Posted on Friday, August 12, 2005 - 11:32 am:    Like Wayne Yancey, I've had similar experience. Early on in my career, I wrote specifications for my projects. They were "shortform" specifications and were in the form of 8-1/2 by 11 inch pages assembled into a book. You know, "book specs." Just this week, I received a request for proposal that was based on the project owner requiring a "book spec" for the project. The architect did not feel competent to do a "book spec" so I was contacted. It's the nature of the architectural profession currently to be ignorant about written construction contract documents. And specifications are commonly an after-thought, started late in the CD phase of a project. The automated specification programs (Linx and SpecLink) can expedite and even guide the specification production process. They are production tools. And with the development of e-Specs and other linked programs between the drawings and specifications, the process will be more expeditious. Yet, there is the GIGO factor (garbage in - garbage out). One must still know how to write construction specifications to most effectively use the automated programs. There are user-generated revisions, to reflect regional construction practices, code requirements and products that are not included in the information of the program. Add to this the value of project managers knowing what needs to be done and being able to provide directions and information necessary for production and coordination of the bidding and contract documents. Sure it is possible and even beneficial to have a dedicated specifier produce the specifications, whether that person is in-house or out-sourced. But the idea that some incomplete drawings can be dumped on a spec writer who will whip out a huge volume of words in a couple of days (say, over the weekend before the project has to issued to bidders) is absurd and unprofessional. Part of the solution is raising awareness of the value of well-prepared (technically competent and suitably coordinated) specifications. Another part is demonstrating how the intent of the design is better achieved with well-prepared specifications. This, in my opinion, should be the highest priority of CSI. And it should be evangelized to architects, engineers, facility managers, construction managers and constructors in a way that makes it clear that it is good business practice to be committed to requiring well-prepared specifications. I must confess a underlying bias. When I rewrote Harold Rosen's book, Construction Specifications Writing - Principles and Procedures, it was with the intent of addressing architects and engineers who produce specifications themselves and especially project engineers edit or write construction specifications for their projects. Few engineering firms, in my experience, have staff who are assigned the specialty task of specifications writing. The same is true for facility managers with architectural and engineering staffs who produce specifications for small projects. These need training in construction specifications writing. I make my living as an out-sourced specifications writer but I think there are members of the project design team, such as engineers, who produce both drawings and specifications and who need to be encouraged and trained to produce competent and coordinated specifications to accompany the drawings for their projects. Mark Kalin (Unregistered Guest) Unregistered guest Posted on Tuesday, August 16, 2005 - 09:54 pm:    Someday I'll remember my password and not be an 'unregistered user' However: I believe the future holds what the present creates. If a spec consultant can write a spec in a day, its because they know their master and know what's in the project. They learn what's in the project based on a conversation or a checklist. Then the project architect can review scope and products and leave the spec writing part alone. To link a master like Masterspec to drawings would include over 75,000 links on the spec side, and a bit of assigned attributes or artificial intelligence on the drawing side (i.e. telling the elevator section that a side-opening door is shown on the drawings). The drawings would need to be 90 percent finished to get an accurate draft, but who can wait for a spec that long? We're producing full specs at the end of design development as the only way for an estimator to know if the owner can afford the building the architect has drawn. The advantage of the large firm is that it can develop experts in-house who can set up systems for the 'closed universe' of the firm, let the project architects participate more or less as they determine, and produce the best product for the amount of resources spent. Such is the wisdom of the small firm who uses a spec consultant in the same fashion. When someone asks me to write a spec in an hour, I tell them they will get the best one-hour spec. It may not be the best spec, but I wasn't responsible for scheduling .... and its better than no spec. (The contractor will have plenty of time to ask questions). The parable of the spec writer and the anesthesiologist: When you have to go to the hospital for an operation, you want the best anesthesiologist to be there by your side - not the fastest or the cheapest. Their job is to put you to sleep, and assuming you wake up, you probably never want to see them again. Such is the architect's attitude toward the spec writer. Handwritten master specifications were used in 1852 in NYC offices; published books on masterspecs in 1898; in the 1920's the American Architect Specification Manuals were published, in the 1930's there was the American Specification Institute with regions around the country and who recommended specs that were 'clear, concise and correct,' in the late 1940's CSI was created and picked up on all that came before. For over 100 years architects and spec writers have been complaining that there's too little time and too many uneducated professionals. Since that's not going to change, we're going to have to let the computers help. If we get nowhere faster, so be it. Most believe we will get faster and better and faster and better. Mark Gilligan SE, CSI Senior Member Username: markgilligan Post Number: 28 Registered: 05-2005 Posted on Wednesday, August 17, 2005 - 03:00 am:    There are two reasons for caution regarding computer systems that promise the world. 1) They are typically on the bleeding edge. I suggest waiting until the rough edges are worn down. Can it deliver? What are the limitations? 2) They are likely not to be economical. Is the savings in time currently sufficient to pay for the added time to create the models, the added hardware and software, and the training on how to use it? Show me somebody who has a demonstatable record of making money as a result of using the new system and I will get interested. Dave Metzger Senior Member Username: davemetzger Post Number: 126 Registered: 07-2001 Posted on Wednesday, August 17, 2005 - 05:35 am:    Every new technology is on the bleeding edge, and initially at least, is uneconomical. But which of us today would go back to the old scissors and glue-pot method of preparing specifications? That old technology is now the one that is uneconomical. In 1973 I worked for a firm named Perry Dean & Stewart, in the very early days of CAD. Computer output (plans, elevations, wall sections) was on an 11 inch wide electrostatic printer; we had to tape the paper sheets together and send them out to have washoff mylars made. That was less economical than traditional hand drawing, but we had a pilot project for the Corps of Engineers (for a real project, an officers quarters at Ft Lee, VA, that was built) to demonstrate the capabilities of this then-new technology. Look at the capabilities of CAD software and hardware today, and the advances that have been made in the past 30 years. Even the smallest firms today use CAD. (How many people today know what Leroy lettering or pin bar drafting are; Wayne, your comments brought back memories). Will automated drawing-specification coordination be accurate and economical? I expect so, probably, eventually. But right now the systems are at the pilot demonstration project stages. Give it time. But remember that no system is a panacea, and we will still need folks who know what they are doing and can ask the right questions. Kenneth C. Crocco Senior Member Username: kcrocco Post Number: 31 Registered: 04-2003 Posted on Wednesday, August 17, 2005 - 01:04 pm:    Many of the posters to this discussion have been though the CAD evolution and computerized spec evolution. Can I write specifications more accurately and faster now than I could 15 years ago? Yes. And as Dave says I agree that automated drawing specification coordination will result in greater economy and accuracy, given a time. One of my personal challenges is to specify the correct products and materials that will result in a well designed building for the resources available. I believe this discussion should drift away from issues of production to issues pertaining to "better" design rather than "faster" design. This is the old "value added" argument. Accurate coordination is not better per se. It is only better if both specification and drawings agree and they are correct. I have plenty of spec/drawings out there that are well coordinated, but do they always have the right products and materials. Are they energy efficient, within the client's budget, available, sufficiently durable, biddable, compliant with codes or perhaps exceed codes where they need to? Automation needs to address all these questions. PA's need to address these questions as well. All our clients are becomming much more sophisticated with automation as well. The demand is much higher than 20 years ago. They don't want any moisture accumulating in their buildings. I still see "older?" masonry cavity wall details, drawn very nicely with CAD and specified quite accurately and coordinated. This is no improvement and at times an embarrassment to our profession. The design/analysis function of architecture is significantly more important than in the "pin bar" days. Automation can help here. Specification writing is more a function of design with automation: resolving the design technically so that it can be described, priced, and built. Design decisions are made all along the process to achieve the products (instruments of service?) of drawings and specifications. The two topics that started this thread, I believe, presume "production" is the issue rather than the "design function" for architects and specifiers. PM's in their role, PA's in their role and specifiers (for lack of a better label) in their role with automation can create better designs. Chris Grimm, RLA, CDT, MAI, CSI Senior Member Username: tsugaguy Post Number: 6 Registered: 06-2005 Posted on Tuesday, August 23, 2005 - 11:11 am:    My 2 cents worth regarding Andrew’s questions: 1. PEOPLE: Our firm uses a combination of 1) design professionals in each discipline to tailor specs to the project -- with a certain level of experience and training, 2) a manager of specification masters, regulatory information, product data, and in-house education (that's me), and 3) a team of Quality Managers and a CAD Analyst. There are roughly 100 people total in our firm. I think this model works well for us because we only employ exceptionally talented people who are committed to lifelong learning. The challenges really are getting everyone to start specs early enough and getting them to submit proposed new master content to me for addition to the library for review and easy reuse. Somehow the common sense message that it is unrealistic to hope to pump out massive volumes of correctly specified content in a few days late in a project needs to be passed up the line, ultimately all the way to the Owner/client if needed, until adequate time and resources are consistently allocated. Don’t underestimate the value of educational programs from the industry professionals who are knowledgeable and offer a reasonably unbiased Lunch & Learn presentation, as well as CSI educational programs at your local chapter and beyond. 2. TOOLS: Ken: How about better, and faster too while we are at it. Ultimately that is what CAD has done for us. As Dave mentioned, integrated specs tools will get there. Companies who have the opportunity to invest time and energy and some $ in piloting these tools will help it get there sooner and help themselves be better positioned for the future. GIGO will dominate early attempts for those not fully committed. Emphasis on the investment of TIME. Our firm has just begun to pilot e-SPECS. It allows tremendous opportunity for customizing the behavior of links to paragraphs deep into the spec based on what is present in your drawings in either AutoCAD or Revit. (No I am not getting paid to promote InterSpec.) All this means a significant investment of TIME spent making those decisions about the behavior you want those links to have as the system will begin to mark up your master for use on the project. This effort must be done by those experienced with specs, preferably in-house if such staff is available. InterSpec has professional spec writers on staff to assist companies who need this done for them, or who want their spec writers to take the first pass at it. Whatever time is spent on this is spent wisely if you are in it for the long haul. Would like to hear from anyone else who is also piloting e-SPECS or ADS. InterSpec press releases have indicated that SOM and other major firms have been using the product. http://www.e-specs.com/press.html (maybe it is a closely guarded secret???) Thanks for starting a great topic Andrew, and if you haven't already seen it, you might read the related one Brett Wilbur started on "Kwality Control" -- great for a few laughs, too. Andrew Wilson Member Username: awarchitect Post Number: 3 Registered: 08-2005 Posted on Tuesday, August 30, 2005 - 06:28 pm:    Thanks to all who have taken the time to post. I have enjoyed reading your responses and would like to summarize what I have learned to date in my own words: With regards to Architects preparing their own specifications. 1. There are 2 fundamental and distinct tasks necessary for the preparation of specifications: what I’ll grossly simplify into two terms (which we can all argue about later): the content task on one hand and the preparation task on the other. 2. Of the 3 sensory channels used in filtering and communicating information (auditory, kinesthetic and visual) there is a split (either real or perceived) between those with a natural predilection for the visual (graphically-oriented) and those with a natural predilection for the auditory (verbally-oriented). 3. By and large, Architects historically consider themselves visual; the mechanics of preparing written specifications is a primarily auditory (verbal) task and therefor seen as less desirable by a more visually-oriented person. 4. Based on her first-had knowledge of project requirements (regulatory requirements, functional requirements, performance requirements, sustainability requirements, aesthetic requirements, constructability requirements budget requirements, etc.) the Project Architect is in the best position to perform the task of providing content. 5. Based on her training in the forms and formats of specifications, her specialized writing skill and experience (knowledge of manufacturers, code requirements, industry standards, installation requirements, product characteristics, maintenance characteristics and in some cases cost information, etc.) the Specifier is in the best position to perform the task of preparing specs based on content provided. 6. The weakness of the specifier in the role of preparing specifications is that she may not be intimately involved in the decision making process. The weakness of the Architect in the role of preparing specifications is a lack of time and the specialized skill necessary to produce specifications. 7. The role of the specifier is to assist the architect in externalizing and recording the decision-making process through the life of the project; the role of the architect is to assist the specifier by communicating adequate project goals, and by providing adequate information and adequate time for the specifier to ply their trade. 8. My conclusion? As a specifier I shouldn't be insular or territorial. I cannot afford to be. My proper role is that of coach: persuade the Architects to get off the "design reservation" and engage the full spectrum of the design and documentation process by encouraging them to maximize their involvement in preparing their own specifications. Not all will do so of course, and each will have their own level of ability to participate, but I should help train and mold the skills of those who do show aptitude or interest and in doing so I am participating in perpetuating the knowledge of our craft to the next generation. With regards to the trends in technology and their effect on how we as specifiers do our job 1. The limitation of technology is that is favors the preparation task over the content task. No amount of automation can replace the instantaneous judgment exercised by someone with many years of experience. 2.Understanding this limitation, I believe technology should focus on the following 4 areas: a. Short-term information transfer – Methods for specifiers to share information in a way that architects understand; ways architect’s can communicate first-hand knowledge of the project in ways specifiers understand. b. Repetition – For architects participating in the process of preparing specifications, automation needs to take place in a way that preserves some level of the repetitive task of doing. Repetition is the key for learning: for example, a specifier sees more projects go across his desk in a year than most architects see in 10 years. This is why the average specifier has an experience separate and unique from the average architect. c. Edification – Lessons learned need to be integrated into the structure of automation so that knowledge can be transferred over time during the routine course of doing business. d. Long-term information transfer – If we as specifiers can utilize those architects who are willing and able to participate in our process, we should then utilize technology to leverage our experience and add value in other areas over the life of the project. The roles of both the architect and specifier in any office are changing; I for one am excited about the possibilities and engage my work remembering the words of Mark Twain: “Keep away from people who try to belittle your ambitions, small people always do that, but the really great make you feel that you too, can become great.” Thanks again to all for you time. AW Anne Whitacre, CCS CSI Senior Member Username: awhitacre Post Number: 237 Registered: 07-2002 Posted on Wednesday, August 31, 2005 - 01:02 pm:    I think (as a specifier) one of the important strengths that a specifier brings is also their volume of work. What may seem like a "new issue" to the project architect will often be the "same old issue" to the specifier because the specifier has had the same discussion on 4 other projects in the past two months. I've had a lot of instances in which the project manager sees a conflict with the contractor as being job specific, and as a specifier I know that the conflict is industry wide. I personally think that this industry perspective is the single most valuable thing I bring to a job. a good administrative assistant can do more with formats and good project manual preparation than I can. I can help strategize bid packages; counter the contractor's claims of various material availability and usefulness (or concur with them); work consistently with product reps for better subcontractor performance; and coordinate specs and details office wide, not just on one project. I think this wide perspective is where a specifier truly brings value to the office. And just as a note: there is one additional learning style: "cognitive" in which the brain does not translate a word to either a visual, auditory, or kinetic mode before interpeting the word symbol. Its not very common, but for people who deal with words all the time, it does show up. Doug Brinley AIA CSI CDT CCS Senior Member Username: dbrinley Post Number: 100 Registered: 12-2002 Posted on Wednesday, August 31, 2005 - 02:24 pm:    Anne, thanks for the word 'cognitive' in this context. 'Cognitive' is exactly the right word.