The Practice Management Knowledge Community (PMKC) identifies and develops information on the business of architecture for use by the profession to maintain and improve the quality of the professional and business environment. The PMKC initiates programs, provides content and serves as a resource to other knowledge communities, and acts as experts on AIA Institute programs and policies that pertain to a wide variety of business practices and trends.
My experience has been that the only people who use the checklists are generally the authors and they are the least likely candidates to need them. Otherwise, the checklist gets sent to everyone, filed into folders, and forgotten. When they are pulled out, the person using it checks off most items without actually checking the drawings, but rather going off of their memory of what they think they included.
REBECCA CALBERT, NCARB, LEED AP
CALBERT DESIGN GROUP, LLC
2950 Cherokee Street, NW
Kennesaw, GA 30144
We started using RediCheck Review System in house many years ago. In the days before BIM it made a great improvement in the quality of documents and reduced field issues and claims. We strongly believe that RediCheck and our own checklists make a significant difference.
Any QA/QC system needs to be diligently applied to be effective.
RICHARD SPEICHER AIA NCARB
PRINCIPAL / TREASURER
As a starting point, you may want to check out AIA document D200 Project Checklist. The version I have is about 26 pages long. I think Rebecca Calbert raises a good point. How do you create a document that will actually be usable and used? Trying to document in detail the thousands of steps/decision points in a project can get overwhelming very quickly. I think usability has to trump thoroughness.
Right now, I'm reading "Making it Happen" by Mackenzie Kyle. He advocates for having an established process/methodology, but not trying to create detailed procedure manuals. Balance that against Michael Gerber's "The E-Myth Revisited". Gerber believes that you should think of your business and its processes as if it were the prototype for a franchise that will be duplicated 500 (or 5,000) times. How would you approach QA in such an instance?
Kendal W. Perkins
Architect, AIA, MBA
Apex Architectural Services, LLC
177 Shamard Drive / Natchitoches, LA 71457
Tel: (318) 581-3237
Isn't GOD Good?
As Albert Russell suggested, you might also consider checklists that are process, results and QA focused rather than comprised of extensive tasks and deliverables. Staff who are qualified, resourceful and intellectually curious tend to be more motivated by goals and objectives than by detailed, mandated checklists.
Michael Strogoff, FAIA
Strogoff Consulting, Inc.
ownership transitions . mergers & acquisitions . practice management . leadership development . talent placement
This message is sent by Strogoff Consulting, may contain information that is privileged or confidential, and is intended exclusively for the person(s) to whom it is addressed. Access to this email by anyone else is unauthorized. If you have received this message in error, please notify us immediately and delete this message from your system.
Donald C Henke, AIA, Assoc. DBIA, LEED AP | Design Manager
Turner Construction Company | 10100 N.Central Expy, Suite 600, Dallas, TX 75231
mobile 469-321-6946 | firstname.lastname@example.org
Here are a few observations from reading the first few chapters of Atul Gawande's "Checklist Manifesto".It's interesting to see an example of someone from one profession (medicine in this case) looking at operating concepts in a different profession. Gawande commits a few errors in the terminology of his reporting on the building industry (or his tour guide may have given him those errors), but he cites checklists that most architects may take for granted without thinking of them as checklists. Gawande cites a contractor's progress schedule and a submittal schedule as checklists, and he is right; imagine the chaos if projects did not have those checklists. There are so many other checklists that we employ: drawing set "mock-up" lists and specifications "mock-up" tables of contents are checklists for the preparers of those documents, and general notes on drawings are checklists for contractors. The standard forms we publish for RFIs, shop drawing submittals, substitution requests, applications for payment, Change Order Proposals, and on and on and on are all checklists of one form or another. Project Agreements are full of checklists of responsibilities. Project specifications in their multitude of sections and parts and paragraphs are checklists for bidders and contractors. All of these checklists have been developed to keep projects and project participants on track, and they can do that...IF the project participants pay attention to the checklists. If you look around your office and at your team and consultants and contractors and subs, it's easy to see how checklists are everywhere and are used daily in the design and construction industry.Although Gawande's treatise is enlightening, I think it's worth noting that his stated understanding of building failures is lacking. He equates failure narrowly with structural collapse only, and he expresses a degree of excitement that so few buildings have thus failed. Following Gawande's logic, any building that has not experienced structural collapse is a success. Imagine using that argument to explain an extra cost change order or schedule delay to a client: "I know it's going to cost a lot more and be completed later than expected, but you should be very happy, because the building has not collapsed."Gawande's reporting on the success of the building industry misses the mark on a few things but makes some good points. His description of a digital walk-through is inaccurate in its terminology, but an architect working today can probably make the terminology corrections mentally and also fill in the blanks about the 3-D modeling software used for the digital walk-through. One thing it brings to light is that disciplines who are not using that software to develop their drawings are more likely to produce interdisciplinary coordination conflicts that won't be seen by a clash detection application that sees only elements modeled by disciplines who use the same software. So, for example, if you're looking for potential coordination issues on a project designed using Revit, you might look first at those few disciplines that are not using Revit software to see how their designs are coordinated with the disciplines that are using Revit and relying on Revit's clash detection applications.Going back to the existence of so many checklists that can be followed, we need to consider the reasons why some project participants (design staff, consultants, contractors, and subs) either reject or ignore the checklists. One reason might be lack of awareness, especially in the case of a new hire. Another reason might be pride or arrogance - "I don't need a checklist; I know what to do." Or, "Checklists are for checkers;" they can check my work when I'm done. A perceived lack of time is another reason - "I don't have time to go over a checklist; I'm already late." With all the checklists we already have in place, it looks like firm management owns the challenge to make sure that project participates learn to appreciate and make use of the checklists.These are my reactions to the first part of Gawande's book based on my experience. I recommend the book to others as a source of QA inspiration.
Excellent point Justus about a "preflight" checklist at the beginning of each phase. And I suggest another preflight checklist that a firm gives to and discusses with their client outlining information needed, decisions needed and when, input points, etc. This is often combined with an action-focused schedule. Nothing better to keep a project moving and enhancing quality than ensuring that clients meet their obligations and contractual requirements.
Your post hits upon one of the areas of responsibility I direct at Centerbrook Architects. I have spent a significant part of my life developing the type of checklists you mention, and more!
Centerbrook has developed a rigorous QA program that includes start-up meetings, QA reviews of project documentation, closeout meetings, and post-occupancy follow-up. We track and schedule all of this activity at our weekly management meeting. Reviews for energy modeling/lighting and BIM clash detection are also tracked. The process we have put together allows us to avoid the "black holes" by actively managing each project throughout its life. Each meeting or review has a specific checklist, meeting agenda, or resource list that is available to our project teams on the intranet and used during the meeting or review.
With regard to the types of QA checklists you mention, I review each project at every phase (SD, DD, and CD), and often include review of conceptual/preliminary phase documents and Issued-for-Construction (IFC)/conformance sets. Our checklist is currently 74 pages long! The same version is used for most projects, there is a residential version used for single-family residences, a short-form version for quick or interim reviews, and version organized by project phase. The document is divided up into sections that relate to the architectural and engineering disciplines, and includes additional sections and appendices to cover general information, contracts, code compliance, project manual format, interior design, building envelope compliance, and IBC plan review. The sections for the architectural and MEP/FP/TD discipline are organized to reflect the organization of the drawing set. We use the UDS Drawing Set Organization list of disciplines as a guide. The checklist covers both drawing and specification information. Each section is divided into phases The reviewer indicates an "X" for Yes, No, or Not Applicable in the checkboxes-- a No response leads to a written comment from the reviewer which are recorded at the end of the section and on the drawings.
The thrust of the checklist is to make sure that the project documents include the necessary content that describes the materials and methods to be used in the construction of the project, that the disciplines and are coordinated not only within themselves, but also with other disciplines, and that the construction documents demonstrate that the project is constructable in the manner that the designers intended. One emphasis we have placed on is to identify the minimum information required by our cost consultants in preparing estimates for the project. Another emphasis is toward the integration of BIM procedures in the production of the construction documents-use of BIM execution plans, workset organization, and modeling conventions.
Once I have completed going through the documents and checklist I schedule a meeting with the project team, including the principal-in-charge, to go over the comments. The drawings are scanned and sent to the consultant engineers.
We update the QA checklist periodically to include recent "lessons learned," building code and accessibility changes, and points of emphasis-- issues that recur in multiple projects. Often, comments from the QA reviews result in topics for staff training and continuing education sessions.
We believe our QA process has resulted in the firm's ability to produce complete and coordinated project documentation, better information for cost estimating, and more reliable documents for use in constructing our projects.
James A. Coan, AIA, LEED AP BD+C, CSI
Senior Director, Architectural Practice and Building Science
Centerbrook Architects and Planners, LLP