PPD Examples

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

Author Message Ronald L. Geren, AIA, CSI, CCS, CCCA, SCIP Senior Member Username: specman Post Number: 611 Registered: 03-2003 Posted on Thursday, January 24, 2008 - 05:28 pm:    I teach construction documents at Arizona State University using the PRM and CDT as the course materials and exam, respectively. I want to push the use of preliminary project descriptions (PPDs) hoping some will take it to their new jobs when they graduate. I like to show examples of actual documents in my class rather than just trying to explain what they should be like, and PPDs would be no exception. But, none of my clients really use them (yet). Does anybody have an example they'd be willing to share with me? I'm looking for one that follows the brief guidelines presented in the PRM, but anything close would be greatly appreciated. Thanks! Anne Whitacre, FCSI CCS Senior Member Username: awhitacre Post Number: 704 Registered: 07-2002 Posted on Thursday, January 24, 2008 - 07:43 pm:    Ron- we use a Uniformat listing and setup for our PPDs and we write one for EVERY project. What's more amazing to me is that whatever gets into the PPD ends up being pretty close to the final design direction for the project, and I use them as ongoing reference for the DD and CD specs. I'm not certain that ours follows the PRM guidelines... Ronald L. Geren, AIA, CSI, CCS, CCCA, SCIP Senior Member Username: specman Post Number: 612 Registered: 03-2003 Posted on Thursday, January 24, 2008 - 10:27 pm:    Anne: The PRM does recommend UniFormat, so what you're doing is exactly what I'm looking for. Are you willing to share one with me? George A. Everding, AIA, CSI, CCS, CCCA Senior Member Username: geverding Post Number: 395 Registered: 11-2004 Posted on Friday, January 25, 2008 - 10:31 am:    Is there not an ongoing effort at CSI to produce a PPD "format", similar to Page and Section formats? Marc C Chavez Senior Member Username: mchavez Post Number: 275 Registered: 07-2002 Posted on Friday, January 25, 2008 - 11:24 am:    Oh please God, not another format! We as an organization need to make a choice. Are we ASTM's younger brother, Standards, standards, standards or, its doddering middle-aged secretary, spending our days minding the margins, gutters, headers, footers, outline numbering systems et cetera? I would argue that we are an organization uniquely situated between the Owner, Contractor, Supplier and, Designer, that can help these four parties create better buildings. Note I did not say documents. In the very near future all the stuff we do will be in databases and the format of the presentation will vary depending upon the question being asked. Omniclass, Masterformat, Uniformat (our version not the silly version(s) currently at ASTM) are useful because they add capability to words, especially English words, that have multiple meanings as used in the construction industry. Use the numbering system and format the document however you wish. Let’s talk about the process of building, not the process of outlining Thank you all for putting up with this rant, I feel better now. Bob Woodburn Senior Member Username: bwoodburn Post Number: 224 Registered: 01-2005 Posted on Friday, January 25, 2008 - 11:44 am:    After this round of format revisions, perhaps CSI will finally get around to establishing standards for ParagraphFormat, SentenceFormat, WordFormat, AbbreviationFormat and PunctuationFormat (the latter addressing, among other things, the apparent tendency of master specifications systems not to hyphenate terms that probably should be hyphenated...) Ronald L. Geren, AIA, CSI, CCS, CCCA, SCIP Senior Member Username: specman Post Number: 613 Registered: 03-2003 Posted on Friday, January 25, 2008 - 12:11 pm:    I understand the concern of saturating the industry with standard formats, but everyone should understand that these are "voluntary" standards. PageFormat for years had a limited number of ways to format a specification section; but, how many different page layouts have you seen over the years? People are looking for examples as a means to develop their own documents, and CSI fulfills that need. As provided in the latest draft (and soon to be released final) copy of PageFormat, the document has provided much more flexibility for users. Marc C Chavez Senior Member Username: mchavez Post Number: 276 Registered: 07-2002 Posted on Friday, January 25, 2008 - 12:29 pm:    Yes, but we as an organization spend a lot of time and energy developing them. Then, we get into the "sell the standard" race to try to create capital with them. I'm getting way off topic. Formats are fine but they should not be an end in themselves and to often they have become such or at least appear to me to be. Anne Whitacre, FCSI CCS Senior Member Username: awhitacre Post Number: 705 Registered: 07-2002 Posted on Friday, January 25, 2008 - 12:30 pm:    I agree with Marc on this one. I think a document such as PageFormat is a complete waste of time, and makes CSI look like a bunch of people counting peas and moving them from one bag to another bag. it would be more useful to have a way of distinguishing a good spec writer from a bad one, than to have some document that talks about margins and indents. as an example, just look at how the specifications awards have been judged in the past: for conformance to Page and Section format. the project manual can be completely incorrect, irrelevant to the project and factually wrong... but if it meets conformation -- like a prize pig -- it can win. Sheldon Wolfe Senior Member Username: sheldon_wolfe Post Number: 296 Registered: 01-2003 Posted on Friday, January 25, 2008 - 01:42 pm:    Right on, Marc and Anne! And by extension, I'm sure you will agree there is no need for drawing standards. We should be able to use or not use line weights as we see fit, use really small scale and omit space between details so we can get more of them on a sheet, arrange drawing sheets in any order that seems interesting at the moment, use cursive fonts that may be a bit difficult to read but what the heck, put all of the drawing stuff on one page and all of the labels on another, use a different direction for north on every page, use creative labels for products, and so on. And look at the ridiculous way building designs are judged: by how cool they look, without regard to constructability, the effect of gravity on water, reasonable use of materials, or usability... The design can be completely incorrect, irrelevant to the owner's needs, virtually guaranteed to leak, but if it's cool, like lipstick on that prize pig, it can win. ;-) Ralph Liebing, RA, CSI Senior Member Username: rliebing Post Number: 779 Registered: 02-2003 Posted on Friday, January 25, 2008 - 01:53 pm:    Ye talks reality, Sir Sheldon! Good read for some of this--ARCHITECTURE OF THE ABSURD, by John Silber Anne Whitacre, FCSI CCS Senior Member Username: awhitacre Post Number: 706 Registered: 07-2002 Posted on Friday, January 25, 2008 - 01:56 pm:    Sheldon: the point of construction documents is to communicate information to the people who need the information. the examples you cite clearly don't do that. (unreadable fonts, etc) Page format doesn't discuss content or the arrangment of content, it discusses MARGINS. It doesn't discuss using language that makes sense, and I've seen a lot of specs that are nonsensical, too complicated and convoluted to be useful. I think "page format" should be along the lines of "can you read it?" "can you find information the second time?" and "can it be quoted for changes?" there are drawing conventions, but I don't know many offices that use them, and the arrangement of drawing sheets often does vary. However, a sheet index helps clarify that, as does a project manual index. I still think we should be concentrated more on content than on "what it looks like", and CSI has a tendency to get really wrapped up in "what it looks like". Sheldon Wolfe Senior Member Username: sheldon_wolfe Post Number: 297 Registered: 01-2003 Posted on Friday, January 25, 2008 - 04:52 pm:    Marc: CSI is not in the business of producing or updating standards to make money, but there is a cost in keeping them up to date. Are you suggesting we should no longer update them? Yes, we do make some money off them, but not much. It takes money to run an organization, and we must either have something to sell, or continue raising membership dues. What's your choice? Unfortunately, we don't have a captive audience like AIA, who somehow has convinced my firm (and all others) that because I am a registered architect, my firm should send them money, even though I am not a member. We don't have general conditions that gather royalties thousands of times each week (talk about a goldmine!). If you are respecting their copyrights, you are paying AIA a fair amount of money for use of their documents, which are regularly updated. Of course, that doesn't matter, because you have to pay each time you use them, whether or not they get updated. ASTM makes a big deal out of the fact that they update twenty percent or so of their countless standards each year, and what they charge makes CSI's selling price inconsequential. As a specifier, it is your responsibility to know each reference standard you use, so you should be shelling out at least $1,300 per year for ASTM, plus whatever it takes for ACI, ICC, NFPA, and all of the others. Although you have an obligation to purchase those references, no one is forcing anyone to buy what CSI publishes, and it's an unreliable source of income. Believe me, CSI is not getting rich off document sales. Sheldon Wolfe Senior Member Username: sheldon_wolfe Post Number: 298 Registered: 01-2003 Posted on Friday, January 25, 2008 - 05:34 pm:    Some specification writers feel a document on Page Format is not necessary. A few argue it is not even desirable, considering the various forms of typing. Nonetheless, whether a manual, automated, or computer print-out system is employed, each demands this discipline. When the Division and Section Formats were introduced, arguments against uniformity were heard. In each case the arguments failed as widespread use of the Formats brought acceptance. Specification practices have been upgraded through the uniformity provided by widespread use of these formats. The first concern of the Page Format is an improved and clearer presentation of the construction message. The second concern is to provide a format which can be used with equipment existing in most offices as well as with currently available computer equipment. In the resulting design of this Page Format, maximum density without obscuring the construction message or hindering rapid reference became the major consideration. The writer and the reader were put before the typist, the printer, the equipment manufacturer, but without placing unreasonable demands upon any of them. The Page Format should then exhibit a reasonable amount of text density, providing visual recognition of the Parts and lesser levels, and arranging the subject matter in a logical, efficient and versatile page." – excerpts from the CSI Manual of Practice, June 1974 I couldn't have said it better. What too many specification writers forget is that specifications are intended to be read, and formatting to make them easier to read is more important than the little extra time it might take to help the reader. I agree that the point is to make it readable. I do not agree, however, that the examples I used have no effect. How can you say an unreadable font does not interfere with communication? When I preach the PageFormat, I use drawings to make the point; for some reason, people more readily recognize what makes a drawing easy to read. You could use a single line weight for all drawings, but is it not easier to understand if you use multiple weights? If I crowd the details with notes, does that not interfere? What if I use a dense poche that obscures information, or weird fonts, or fonts that are too large or too small? What if I rely on color and not everyone has a color printer? "Those are all obvious!" you say, yet you do not see the similarities in standards for printed text. Unfortunately, many people have no idea what makes text readable. It looks fine on their monitors, or it looks "nice" when printed, and that's all that counts. I have seen specs with 8 point fonts, no white space between paragraphs, no indents, and less than half-inch margins. Each of those things, as well as line length, font selection, use of bold, italic, and uppercase, has an effect on reading and comprehension. Just as you try to make your drawings clear and easy to read, so too should you make the specifications as easy to read as possible. Anything less is interfering with communication. The publishing industry has developed good guidelines for readability, and I have long argued that they should be the basis of PageFormat. Do we actually need a PageFormat? Perhaps not, but if we're going to have examples of what constitutes readable text, why not have our own guideline that speaks to what we do? It may not be as important as a system to organize construction information, but it does have value. We could do away with MasterFormat, too, and simply tell people to file information alphabetically by product or system or work result. Basic font: Ornate fonts seem to be an obvious no-no, but I have seen them used. Even more "normal" fonts can interfere with reading if the x-height is too small, if letters are tilted, and so on. Some of them are considered more elegant, and they may be beautiful to look at, but they can be more difficult to read. Today, with text appearing printed, on screen, and faxed, font selection is more important than before. Italics and bold usually decrease readability. Font size: Too small and you can't read it (and this becomes more of a problem with age); too large can have the same effect. Line length: The number of words in a single line affects readability. Depending on writing style, the same text may be more readable in one or two columns. Uppercase: Government agencies, in particular, seem to believe that text in uppercase has more impact, but it is much more difficult to read. White space: Judicious use of white space can make it easier to find text and to easily see text grouping, and will produce a higher text density without reducing readability. Margins: Yes, they are important, if only in printed material. If you're holding a page, and your thumb covers some of the text, that's a problem. If you don't use a gutter, the binding can make it difficult to read text on the bound side of the page. "Those are all obvious!" you say. Maybe to you, but there is overwhelming evidence that is not the case. As Marc said, all the stuff will soon be in databases, but even then the format in which it is presented will be important. The importance of readability apparently is not obvious to most. How many websites have you seen that have a tiny font, or black font on blue background, or other "features" that make them unreadable? Same question goes for manufacturers' literature, on paper, pdf, or any other medium. To me, it's clear that the basic rules of presentation are not well-known. When they are, we'll do away with SectionFormat. Until then, it would serve many specifiers well to take another look. Sheldon Wolfe Senior Member Username: sheldon_wolfe Post Number: 299 Registered: 01-2003 Posted on Friday, January 25, 2008 - 05:53 pm:    Thought I was done, did ya? Another thing that affects comprehension is the writing itself. Despite all the claims to believe in and use the MOP, many specification writers continue to use long, complex sentences, and I am amazed at how many still use the "the contractor shall" style. Many also seem to lack an understanding of basic grammar and punctuation. Yes, punctuation is important - but I'm not suggesting a PunctuationFormat - especially if you're writing long sentences. Colons, semicolons, commas, and periods have specific functions. Of course, if you write in short, direct sentences, punctuation can be reduced to commas and periods. Most specifications have an address system, either the outline format or numbered lines. Even so, I have seen may specs in which the address was inexplicably left off some paragraphs, meaning a reference might become "the paragraph after 2.01A" rather than "2.01A.1". I also agree that the way we have judged specifications in CSI competitions has been next to meaningless. (That's not sour grapes; I have a couple of awards.) Other than conformance to MasterFormat, SectionFormat, and PageFormat, about the only thing that has received serious consideration is the coordination of Division 01 with mechanical and electrical specs. I don't know if there is a way to judge specifications in a reasonable amount of time. To do so would require knowledge of the project, a full set of bidding documents, addenda, change orders, RFIs, and so on. The size and complexity of the project should also be a factor. One year, the entries included a very small addition to an existing building. It was fairly well done, but how could it possibly be eligible for what amounts to the same award as a project manual for a thirty million dollar hospital? If you have suggestions for a meaningful specifications competition, hang on to them. A committee soon may be formed to investigate a new specifications competition. Marc C Chavez Senior Member Username: mchavez Post Number: 278 Registered: 07-2002 Posted on Friday, January 25, 2008 - 06:24 pm:    I'm sometimes to blunt for my own good. I look forward to a flexible PageFormat that lets me do what I need to do and keeps my document readable! I'm glad that CSI has the ...Formats. Your comments on PageFormat from several years ago were very good and I hope to see the new PageFormat reflect them AND the changing face of production. In brief and probably too bluntly; as the formats go down in scale my (and most others) adherence to them also goes down. MasterFormat: Absolutely, Uniformat: When needed, SectionFormat: You bet, PageFormat: If I can. The readability items you mention are on the top of my list! . Pageformat is perhaps more of a design discussion than a document template. Give us design guidelines and then leave it, don’t make it mandatory for the specs competition or a litmus test. Likewise the NCS is not a complete standard and cannot be “adhered to” slavishly and I don’t. The second reason I like the …Formats, including the NCS, is that I can beat the architects over the head with them. Architects will redesign the zippers on their pants given half a chance. No really they would. My job is to stop them, direct them with the statement “this has already been figured out. Now go back to your desk and product documents that the contractor can build a building from remember you’re being paid to design a building NOT your zipper!” sometimes it even works. The standards territory is very well carved up and if we spend time on standards let us spend that time on the changeable and changing world of database input AND output format. Omniclass, the Lexicon and other things like them are great. Unfortunately they are not as concrete and easy to promulgate as a new standard for glass, thus they are harder to sell. BUT this is where we need to be spending our time. Remember Moore’s law; we need to be designing for the (construction) world out in front of us not the one we see today. CSI as an organization needs to be focused on the process of building, and providing education and $$$ making activities that engender that goal AND we are particularly well suited to do it. I would never advocate throwing the baby out with the bath water. But let’s stay focused on the point -construction. Bathe the baby so she can be healthy and grow into a beautiful and smart young woman. Who belongs to CSI OK now I'm flag waving and singing "God bless America" like Kate Smith Sheldon Wolfe Senior Member Username: sheldon_wolfe Post Number: 300 Registered: 01-2003 Posted on Friday, January 25, 2008 - 08:12 pm:    Marc & Anne: Ain't this fun? It was a lot more fun in the committee days, when we were sitting in a comfy lounge with a couple of short ones to lubricate the discussion. Not that this group ever needed social lubricants... Ah, for the good old days! Mark Gilligan SE, CSI Senior Member Username: mark_gilligan Post Number: 26 Registered: 10-2007 Posted on Saturday, January 26, 2008 - 01:09 am:    If you are the prime design consultant you can customize the page format for your project. The problem is that your consultants who are providing specification sections for the project manual then have to reformat their sections to meet your criteria. This often thankless task typically falls on the secretaries in your consultant's offices. Remember we work with multiple Architects each of who does it differently. The closer you abide by the CSI PageFormat the easier it is for your consultants to match your criteria. I agree with Marc's suggestion that when working on a project we should focus on designing the project, not the format of our specification sections. John Regener, AIA, CCS, CCCA, CSI, SCIP Senior Member Username: john_regener Post Number: 366 Registered: 04-2002 Posted on Saturday, January 26, 2008 - 06:02 am:    Mark: I agree that when consultants are forced to deal with multiple formats it can be burdensome. Standardization of the page format helps. But isn't this also a problem when dealing with title blocks and sheet layout in the Drawings? A "plain vanilla" page format is easier for consultants to deal with. But we spek riters have strong opinions about the page format (see discussion above about readability). So, I consider my page format pretty staightforward but with some subtle sophistication --- perhaps like "French vanilla." Mechanical and electrical engineers seem to have the sophistication and working knowledge of word processing programs to deal with the subtleties of varying page formats. It's door hardware consultants, roofing & waterproofing consultants, equipment consultants and (Lord deliver us) LEED consultants who seem to have the greatest difficulty. I'd like to hear about "styles" and "templates" and how they help. John Regener, AIA, CCS, CCCA, CSI, SCIP Senior Member Username: john_regener Post Number: 367 Registered: 04-2002 Posted on Saturday, January 26, 2008 - 06:08 am:    A sample PPD is included in my book, Construction Specifications Writing: Principles and Procedures. It also has a sample Outline Specification and a sample shortform Division 1 - General Requirements. Sheldon Wolfe Senior Member Username: sheldon_wolfe Post Number: 301 Registered: 01-2003 Posted on Saturday, January 26, 2008 - 11:41 am:    The only time I require the same page format throughout a project manual is when the owner dictates what it will be. We work with a variety of structural, landscape, civil, M&E, and other consultants, all of whom work with a variety of architects; forcing them to change formats for every architect does seem an unnecessary burden. If everyone used the same format, the project manual would look better, but, going back to previous discussion, the intent is communication, not appearance. As long as the consultants' specifications are readable, the only thing I require is that their headers and footers are the same as ours. That consistency is a clear benefit to the owner, contractor, and others who use the project manual, as the first information they look for - section number and title, page number, and project title, are in the same place. Once they get where they're going, the content is what they're after. I don't think changing page format is a problem, especially if you use styles, but I am amazed at how many of our consultants have problems. Especially surprising is how many administrative people, whose primary job is using a word processor, have mastered nothing beyond word wrap - and some don't even understand that; I get documents from one source that contain carriage returns within paragraphs! I get specs from consultants and manufacturers who use spaces and tabs used to align text, a mix of automatic and manual numbering, and hard page breaks. Even when styles are used, individual paragraphs are often forced into the form of a different style. To further complicate the problem, some consultants are not consistent within their firms; some sections appear to have been keyed in by someone who knew how to use a word processor, while others obviously were done by a two-fingered hack. This lack of knowledge is one reason I don't ask our consultants to change their page format. Given the combination of more complex projects and reduced delivery time, I'd rather they concentrate on getting the content right. Another reason I don't force our format on consultants is writing style. I'm of the SpecText school; I firmly believe that a terse style is superior to the verbose style used by many specification writers and MasterFormat. I use short sentences and sentence fragments, which make it possible to use two-column format. All of our consultants use specs that are in a more narrative style - with lots of "contractor shall" phrases - which does not work well in two columns. Another common practice that requires a single column format is the use of many outline levels. The deeper they go, the greater the indent, and the less text you get on a line. Our specs are based on a template, so when an owner does require a specific format, all I have to do is change the styles in the template and all of the specs automatically change to match. A little tweaking still is needed in each section, but all sections can be tweaked in just a few minutes, even less if a macro is used. I began using a two-column format about ten years ago. After reading a few books about publishing, I tried several combinations of margins, fonts, and outline structure, and settled on one that worked well (maximum density without obscuring the message or hindering rapid reference). Within a few months, anecdotal evidence suggested I had made a good decision; I started getting comments from contractors and suppliers, who said they found the specs easier to read. With a terse style and two columns, more information appears on a single page. For the "sustainability" crowd, the number of pages in a section is often reduced. That sounds good, but the effect is not as great as it first might appear, as a section with an odd number of pages still needs a whole piece of paper for the last page. I wonder if anyone makes single sided paper. ;-) Mark Gilligan SE, CSI Senior Member Username: mark_gilligan Post Number: 27 Registered: 10-2007 Posted on Saturday, January 26, 2008 - 01:49 pm:    Our firm has minimized the hassle by rigorous use of styles ad by the development of some Visual Basic code that allows us to update the files. If we were provided with a sample specification section that was organized in a similar manner life would be easy. The reality is that not all specification writers are sophisticated in the use of styles. As a result we have to create and edit a special .dot file for the project. Other offices where I have worked did not have the knowledge to pull this off, thus the secretary was given the task of making it look right. As long as it looked right nobody worried how this was done. Many of our clients are less flexible than Sheldon and while some clients will begrudgingly accept specification sections with a different format this is not something we find acceptable. If our format differs it often creates a negative impression by our client. We have found Styles as implemented in Word, to be poorly documented and difficult to edit. Thus few individuals know how to create and edit styles. The more we are asked to differ from what is shown in the PageFormat the more time it takes. Requests to change style of writing and sentence structure would cause us a lot grief. I imagine a two-column format would present us with a steep learning curve. There might be a point where we say no can do, but this is not something we want to say. The reason I keep coming back to PageFormat is that it is the common origin of all customized formats. If we did not have it, life would likely be exponentially more difficult because the variations would be greater. It seems the tendency to use customized page formats is inconsistent with the push for interoperability and the need to work with a common BIM files. I hear the arguments how the formatting of specifications can make them easier to use. In the days when we did our drafting with pencil on vellum we composed the detail and used subtle variations in line width to make the drawings read. Some of these drawings were works of art. With the adoption of CAD and BIM this ability to compose our drawings has effectively been lost. The world sometimes changes in ways that require us to give up preferences in order to achieve other benefits. Phil Kabza Senior Member Username: phil_kabza Post Number: 298 Registered: 12-2002 Posted on Monday, January 28, 2008 - 09:01 pm:    So ... back to the PPD. Word is, a Task Team is setting forth to work on this. For years, all we've had is the UniFormat book in hard copy or in a (why, I don't know) Word Help File electronic format. So we may now actually start seeing the PPD emerge as the useful tool it promises to be. Can anyone say "BIM?" A UniFormat-based body of design data that can serve project communications and approvals as it develops, then evolve into MasterFormat-based contract documents: Priceless. Marc C Chavez Senior Member Username: mchavez Post Number: 280 Registered: 07-2002 Posted on Tuesday, January 29, 2008 - 10:47 am:    Revit has Uniformat (kind of) numbers embedded in the element properties. For example, The Exterior CMU Insulated Wall from the basic wall group is B2010144 I dont know where the 144 came from but the 2010 is correct. So they are trying. I'll dig up where they got the 144 But its not an abbreviation of either 042200 Concrete Unit Masonry or 042219 Insulated Concrete Unit Masonry. Now If drawing in Revit, AND your draftsmen (or women) are thinking about the wall types. You should have a pretty good list of assemblies at the end of the day. Marc C Chavez Senior Member Username: mchavez Post Number: 281 Registered: 07-2002 Posted on Tuesday, January 29, 2008 - 10:51 am:    I was a premature poster! It appears that Revit is getting it's Uniformat from R.S.Means. Louis Medcalf, FCSI, CCS New member Username: medcalf Post Number: 1 Registered: 01-2008 Posted on Thursday, January 31, 2008 - 03:50 pm:    I can confirm the rumor Phil mentioned, as I am chairing the PPD task team. We are just getting organized and are collecting examples of PPDs to find out just what people are actually doing. The basic goal is to produce a new stand-alone guide that is more detailed and more helpful than the information in the PRM. Practicality is the watchword. In our first conference call meeting there was general agreement that the ultimate product should not be just another paper document, but some sort of electronic file that people can start using. Of course, it will have to be flexible not only for appearance variations, but also for practice preferences. I have used a couple of different formats myself. My favorite, which I have used since the early 90s is a two-column table with the element number and name in the left column and a brief (terse!) description in the right. I have had good success in getting designers to fill in the blanks of a Word template, which I then edit for technical content. Because UniFormat can function as a checklist, some designers have positively responded to using this form to clarify their own thinking about the project. One of the issues for which we want to give some guidelines that the present PPD info is how to describe multiple wall types or structural systems in a single facility. For example, my previous firm did a lot of resort hotels in which the guest room tower had post-tensioned floor slabs, but the low-rise support and entertainment areas had concrete slabs on form deck. We are also interested in the possibility of the element descriptions being directly linked to the objects in object-oriented CAD and BIM. That is, each object, whether large or small, or simple, complex, or multiplex, would have an entry in the PPD and vice versa. Schematic drawings could even use UniFormat numbering as keynotes. I’m not sure how this would work with MPE elements. Please feel free to send me full or partial examples of PPDs for use by the task team. For my friends who have not yet heard the news, I have moved to Nashville for family reasons and am now working at Gresham, Smith & Partners. (Unregistered Guest) Unregistered guest Posted on Friday, February 01, 2008 - 06:27 pm:    Louis, Please send me your contact information to wayne.yancey@callison.com and I will send an excerpt from on I did. Wayne Anne Whitacre, FCSI CCS Senior Member Username: awhitacre Post Number: 714 Registered: 07-2002 Posted on Friday, February 01, 2008 - 07:08 pm:    I've been running into problems with PPDs for multiple-building projects, which is sort of an "extended version" of Louis' issue. we not only have multiple wall types, we have multiple versions of them, because our project is 8 buildings (one of which is a basketball arena) plus landscape, and a subway station. However, I think most of the formats out there fall down when you get to really really big projects, and the data management gets to be a discipline all its own. Even a relatively simple office campus: office buildings, parking structures; cafeteria plus conference space; and associated landscaping. the PPD needs to be expandable and compressable. I've found that a PPD is used more often on large long range projects -- it may be part of a financing pro forma (for example) and the information has to be discernible to a variety of audiences.