Recently in Business Practice Category


The July 1st CSI Specifying Practice Group meeting focused on how to collect project data required to write specifications. Group members Louis Medcalf, FCSI, CCS of Gresham, Smith & Partners and Patricia Gallup, RA, CSI, CCS of PSA-Dewberry, and group leader David Stutzman all shared examples of tools they have used and discussed the benefits of each. The sample documents will be available for download at the CSI blog. Here is a summary.

Louis Medcalf showed a table of Project Decisions by Phase. The table includes a column for pre-design, and each design phase for a construction project. Most interesting is the row in the table titled "Design Purpose." Each of the table entries relates directly to the phase purpose. And a goal is stated for some table entries at various design phases. Imagine the cost management goal for DD phase is to have sufficient information to establish a GMP. The corresponding construction information goal is to complete all product decisions affecting cost.

Noble goals, indeed! And consistent with the AIA Owner-Architect Agreement documents. Medcalf noted the table is used to help manage projects and the information that is created and documented at each phase. Stutzman interjected that recently it seemed that CD phase definition has changed. Instead of Construction Documents, it seems to be Continue Designing. Medcalf indicated delayed design decisions can be costly especially when significant design revisions are required as projects near completion.

Stutzman demonstrated a project table of contents in Microsoft Excel format that Conspectus creates when proposals are issued and then refines as projects progress through design. The table of contents includes a description of what is believed to be included in each spec section. Additional information, such as that found in basis of design documents, is included in separate columns as it become available. The file is distributed to the architects with notes about what data they must furnish. The architects use a separate column to respond to comments and questions and to add product selection data. The contents is a master document that uses Excel's auto filter function to quickly "edit" the file to show only the subject that are appropriate, without deleting any information.

Patricia Gallup showed a checklist in Microsoft Excel format that she uses with PSA-Dewberry's project architects. She explained the form is 21 pages long, and there are many selections to be made to complete the form. She has used the form successfully as a starting point to begin drafting the specifications. However, Patricia did report there is some reluctance to completing the form. Patricia is considering revising the form so it can be completed more efficiently as an electronic document.

Stutzman demonstrated a second checklist using Microsoft Word. The checklist was created for a client that builds a single building type at many locations. The file is actually a form using checkboxes, fill-in-the-blanks and drop-down menus added to the file using the Forms toolbar. The owner required the project architects to complete the checklist electronically. Having the owner make the demand of the architects ensured the form was completed for every project. Once completed, a macro is used to compare the form to the default status. Changes the architects make are displayed as red text to ensure the changes are easily found. This allows the client's standard specifications to be edited quickly to mach the checklist.

There seems to be no single answer to the question of how to collect project data or what tools to use. There are multiple approaches and various degrees of success. The right approach seems to depend on project circumstances, the people involved, and how much influence the specifier can exert.

Join your colleagues in discussing current issues by joining the Specifying Practice Group. The group meets the first Thursday of each month from 3:00 - 4:00 PM eastern time. The group meeting topics are for everyone who must read or write construction specifications.
What do you use to describe your design projects? Will owners, lenders, estimators and others understand the design intent? Traditional methods rely on design narratives and outline specs to supplement drawings. Each design team develops their own method for presenting the written information. As a result, sharing the information among various teams and building a library of design descriptions for use with future work is difficult.

Louis Medcalf, FCSI, CCS and Chair of the CSI PPDFormat Task Team explained to the CSI Specifying Practice Group how Preliminary Project Descriptions (PPD) can simplify collecting and sharing information for the benefit of current and future project teams.

The CSI Specifying Practice Group meets the first Thursday each month. Everyone that reads or writes specifications is welcome to join the group and share ideas.

PPDs are not widely known nor widely used even though the concept first appeared in the CSI Manual of Practice in 1989. CSI created the PPD Task Team in 2009 to write a new publication to describe how to prepare PPDs. As a result, PPDFormat was published in May 2010 and is available from CSI. Now the industry has a guideline to help structure PPDs and the information they contain.

The PPD structure provides a systematic checklist to help ensure all the appropriate subjects are discussed. The checklist is UniFormat, the construction classification system for building systems and assemblies. UniFormat was designed for cost estimating. So, PPDs are coordinated with published cost estimating systems, allowing parallel presentation of design data and cost data.

The PPD structure allows each system and assembly to be discussed by description, function, and component. This structure enables analysis and effective comparison of various building systems used to perform the same function. Multiple solutions may be presented as potential design options without the need to show each system graphically. This approach allows options to be analyzed for aesthetics, life-cycle costs, durability, and other factors without investing significant time to document each option.

Documenting all information in a building model is not practical. PPDs provide the opportunity to describe what is required for each assembly that is represented by a model object without inserting the data into the model. Model the major building elements and rely on PPDs to describe the secondary and accessory components that complete the major assembly.

PPDs are useful at every project design phase. They can serve as the Schematic Design project report, the Design Development outline spec, and the Construction Documents quality control tool. They can record the decisions, the rationale, and the design at each step during the process. PPDs are a valuable resource throughout all stages of the design process.

Read the meeting notes and view the PowerPoint presentation slides at the CSI Blog.

Why should you consider an independent document review?

 

The project deadline is looming, you are working feverishly to make that final bid issue deadline. You know there are areas that are not fully coordinated because of last minute changes, and you sent a bullet point list of these items to the entire team. You have been working on the project for months and are confident other parts are well coordinated by each lead designer. No structured interdisciplinary review was completed. So, why add even more stress to an already stressful situation?

 

Because, each uncoordinated item has the potential of generating another dreaded RFI or Change Order. Because an independent document review reduces construction costs, saves design team construction administration time, and reduces stress. . . That's why!

 

Here is an example:

 

We just completed reviewing drawings and specifications for a university interior renovation project. The project consisted of two similar, not identical, multi-story dormitories. There were a total of 260 drawings 30 x 42 inches in size. Each building had its own set of drawings. One project manual (spec book) served both buildings.

 

The review was completed over nine calendar days, including two working weekends. A total of four staff contributed over 150 hours to complete the review, slightly more than 1/2 hour per drawing. In that short time, the review team marked the drawings and specs with over 2,000 comments about coordination and constructability issues. Granted, some of these comments are essentially duplicates. Coordination issues were noted on each drawing contributing to the problem. For instance, when toilet fixture locations on the architectural plan did not match the locations on the plumbing plan, a comment was made on both drawings to identify the same issue. This duplication is intentional to ensure each affected design discipline is aware of the issue so the correction will be coordinated.

 

The number of comments is great. Some comments such as correcting a detail reference have little, if any, impact on the project cost and schedule. However, columns in the middle of glazed openings, insulated pipes that do not fit within designed chases, utilities extending the length of the building without regard for building expansion joints, powered equipment without an electrical circuit, and hard ceilings without consideration of access panels to service mechanical equipment discovered during the review can have significant cost and schedule impact when found during construction.

 

When presenting the results of our reviews, I always have some trepidation about how the comments will be received. Some designers become defensive, but most receive the comments in the spirit intended: to produce a better set of documents and a better building. We strive to help design teams and projects to be successful.

 

Finishing our review by presenting our comments in a meeting with the entire design team leads to valuable group discussion of the primary coordination issues and often results in an agreed solution. This last presentation was well received by the entire team. The MEP engineers were especially grateful the review found items that everyone had grown accustomed to seeing, and therefore assumed were correct and clear.

 

During our meeting, the mechanical engineer was able to explain a code provision as the reason why fire dampers were not shown for a dryer vent shaft. This was something I was happy to learn. Today the same engineer called to discuss our comments about louvers. I was pleased to have the opportunity to explain louver construction and why drainable blade designs are not well suited for semi-circular louvers.

 

The purpose was served. Everyone learned something for the next project, and this project will have far fewer RFIs as a result. As for the owner's perception of this design team compared to others? Guess!.

Today, even small design and construction projects can have large design teams with many contributing consultants. Managing the work of so many people and coordinating the result has become a herculean task. So how can this burden be relieved while ensuring all participants remain aware of the project progression so high quality documents are produced every time?

 

For the past 18 months we have relied on Basecamp, a web based application from 37Signals. Basecamp is an intuitive tool that provides great flexibility in managing data. We offer our subscription for this service to all our clients and their entire design team because we believe so strongly that it significantly improves collaboration and raises the quality of the resulting design.

 

Initially, we tried Basecamp for selfish reasons. Project schedules changed regularly, sometimes daily. We kept a paper calendar showing project deadlines. Because we were delivering up to 250 projects each year, just imagine the number of deadlines on the calendar. As the schedules changed we could not find all the previous schedule dates to void the entries. This created some tense moments with near panic when we turned the calendar and discovered an outdated completion date.

 

Basecamp allowed us to view the delivery milestones by specific projects. So when schedules changed, we opened the project and easily made all the adjustments at once. Ad every change was instantly available to our entire staff. At first, this feature alone was justification for using Basecamp. No more panic attacks!

 

However, we had an epiphany. We invited our clients and all their other consultants to use Basecamp with us. We found that Basecamp allowed us to collect all the project communications in one location, essentially replacing email. All communications are visible to everyone on the project. And automatic email notifications of Basecamp posting are sent to everyone directly involved in the issue. But wait! There is more.

 

To Do lists allowed team members to assign tasks and completion dates to others, for work that was required to coordinate the project and incorporate the latest design changes. Everyone on the team can view the lists for everyone else. What an incentive! It is embarrassing to open the project and discover your unfinished To Do list is the longest. The embarrassment factor worked. Things got done and in a much more timely manner.

 

What about project files, you may ask. Well Basecamp helps there too. There is a simple file upload feature similar to an FTP site, except multiple versions of the same file can be posted. The latest file is always on top and the previous versions directly below.

 

We are still only scratching the surface of what can be accomplished with Basecamp. It seems we find new ways to manage the work flow, nearly daily. The built-in flexibility allows us to try new ways to accomplish traditional tasks.

 

Now we use Basecamp for every project. We encourage our clients to start the project on Basecamp at day one and to include the entire team as welcome participants. There are no limits on the number of users. So there is no need for anyone to be excluded.

 

The cost to our clients? None! The value to the project resulting from participation far outweighs the subscription fee.

 

We encourage you to take the Basecamp tour to see for yourself: http://basecamphq.com/tour

Reblog this post [with Zemanta]

About this Archive

This page is an archive of recent entries in the Business Practice category.

Code Requirements is the next category.

Find recent content on the main index or look in the archives to find all content.