Practice Management Member Conversations

I'm formulating some QA strategies that involve checklists for our firm, and the effort is prompting a few questions about strategies for developing and using them.  

Does your firm make extensive use of standard checklists for completion of projects? Or do you rely more on some senior, well experienced staff to guide the project to successful completion?

Do you use one "office standard" checklist, or do you have different checklists based on project type?  

If you have office checklists, what level of frequency do your staff actually use and refer to them?  Every project?  Or do the binders full of checklists sit on shelves collecting dust?  Do you have any formal requirement that staff members must complete and sign a checklist at a project milestone, for instance?  or are they just a guidance tool for staff?

How detailed are your checklists?  Many checklists (published by the AIA and others) are very comprehensive and long, attempting to address everything in cursory terms.  When trying to apply these to projects, I expect most staff would miss half of the nuts and bolts that are required to complete the documents with sufficient thought and detail.  which begs the question, how much detail do your checklists go into?  Do you attempt to spell it all out in specific terms, or touch on the topic (i.e. "coordinate foundations with utilities") and rely on the knowledge, expertise, and memory of the production staff to "fill in the blanks"?

How are your checklists organized?  One large 50 page nonstop list?  Again, many checklists can evolve into one unbroken string of tasks with little logical organization, making them difficult to use and manage.  Organized with tasks by phase? Organized by spec section or division?  

The bottom line - I'm attempting to build a series of checklists that follow the CSI spec sections, and organize tasks within those sections by the appropriate phase.  The idea being that the Job Captain or Project Manager (lead technical production manager for the project) can go through the list of Spec sections, pull out the checklists, and compile them, handing or assigning the appropriate sub-lists to the appropriate  BIM workset modeler (who owns that content) to complete over the course of the project. Tasks are organized by phase, and at the end of each phase the BIM modeler would initial the bottom of the column showing those tasks checked off and confirming the tasks have all been completed.  A benefit of this is that each checklist is relatively short, and specific to the products being used.  I've written many of them, and we've conducted an office "reveal" to the staff going over the content of each one. Prior to the "reveal" training session, staff have been emailed a copy of the PDF file for the list directly.  While we haven't created checklists for all CSI sections that we normally use yet, we've focused on those where the mistakes often happen - like Washroom Accessories of all things.  Accessories often go in at the wrong height, or conflict with grab bars, and when child height dimensions are involved, staff will often not remember the correct heights (or consult the codes and guidelines). The checklists lay all of this information out, in one convenient location with graphics.   Until we have all of our "usual" sections complete, we encourage the staff to use them; but to date, usually the staff don't even remember that we have them to refer to.  Before I expend a signficant part of my life developing more of these, I'm wondering if the checklist black hole syndrome is widespread, or if it's just us, because we aren't enforcing them yet.  

Thoughts?




------------------------------
John Thompson
Production Coordinator
Dore & Whittier Architects, Inc.
Burlington VT
------------------------------

------Original Message------

I'm formulating some QA strategies that involve checklists for our firm, and the effort is prompting a few questions about strategies for developing and using them.  

Does your firm make extensive use of standard checklists for completion of projects? Or do you rely more on some senior, well experienced staff to guide the project to successful completion?

Do you use one "office standard" checklist, or do you have different checklists based on project type?  

If you have office checklists, what level of frequency do your staff actually use and refer to them?  Every project?  Or do the binders full of checklists sit on shelves collecting dust?  Do you have any formal requirement that staff members must complete and sign a checklist at a project milestone, for instance?  or are they just a guidance tool for staff?

How detailed are your checklists?  Many checklists (published by the AIA and others) are very comprehensive and long, attempting to address everything in cursory terms.  When trying to apply these to projects, I expect most staff would miss half of the nuts and bolts that are required to complete the documents with sufficient thought and detail.  which begs the question, how much detail do your checklists go into?  Do you attempt to spell it all out in specific terms, or touch on the topic (i.e. "coordinate foundations with utilities") and rely on the knowledge, expertise, and memory of the production staff to "fill in the blanks"?

How are your checklists organized?  One large 50 page nonstop list?  Again, many checklists can evolve into one unbroken string of tasks with little logical organization, making them difficult to use and manage.  Organized with tasks by phase? Organized by spec section or division?  

The bottom line - I'm attempting to build a series of checklists that follow the CSI spec sections, and organize tasks within those sections by the appropriate phase.  The idea being that the Job Captain or Project Manager (lead technical production manager for the project) can go through the list of Spec sections, pull out the checklists, and compile them, handing or assigning the appropriate sub-lists to the appropriate  BIM workset modeler (who owns that content) to complete over the course of the project. Tasks are organized by phase, and at the end of each phase the BIM modeler would initial the bottom of the column showing those tasks checked off and confirming the tasks have all been completed.  A benefit of this is that each checklist is relatively short, and specific to the products being used.  I've written many of them, and we've conducted an office "reveal" to the staff going over the content of each one. Prior to the "reveal" training session, staff have been emailed a copy of the PDF file for the list directly.  While we haven't created checklists for all CSI sections that we normally use yet, we've focused on those where the mistakes often happen - like Washroom Accessories of all things.  Accessories often go in at the wrong height, or conflict with grab bars, and when child height dimensions are involved, staff will often not remember the correct heights (or consult the codes and guidelines). The checklists lay all of this information out, in one convenient location with graphics.   Until we have all of our "usual" sections complete, we encourage the staff to use them; but to date, usually the staff don't even remember that we have them to refer to.  Before I expend a signficant part of my life developing more of these, I'm wondering if the checklist black hole syndrome is widespread, or if it's just us, because we aren't enforcing them yet.  

Thoughts?




------------------------------
John Thompson
Production Coordinator
Dore & Whittier Architects, Inc.
Burlington VT
------------------------------

------Original Message------

------Original Message------

------Original Message------

------Original Message------

------Original Message------

I just downloaded "The Checklist Manifesto". From the descriptions, it looks promising.

I have been thinking about the challenges we face in managing architectural projects and how effective logistics (call it design logistics, if you will) are one key to effective QA. Firms may start projects without fully considering QA priorities and sharing them with staff and consultants who may otherwise operate with only their own priorities. Where the project work is broken into separate departments, even more upfront QA coordination is needed to make sure everyone understands and respects the same priorities. It's important to remember that there are likely to be many aspects of QA to consider other than accurate construction documents - from space program to aesthetics to building performance and environmental contributions to budget and schedule and more. For some who are involved mainly in developing construction documents or performing construction contract administration, QA may seem limited to achieving near perfection in construction documents, but that is not usually a sufficient basis on its own for an effective QA program, and that kind of QA document is not likely to see much use by designers involved primarily in the early phases of project design.

Back to the question of logistics, we are commonly challenged to develop and implement a sequence of design activities or tasks that can be followed without multiple interruptions and hectic revisions. Although it's possible that project priorities can be established sufficiently near the outset of a project to facilitate a relatively efficient design process, it seems more common that firms launch into design work following abbreviated past protocols without sufficient upfront consideration of applicable priorities for a specific project. Follow-up progress reviews during design are important as checks of actual progress against agreed priorities, but too often the demands of arbitrary deadlines lead to "fast and furious" but inefficient work. Then the responsibility for clean-up falls to the QC crew, and the QC checklists grow exponentially.

The upfront QA logistics should involve all stakeholders to an extent that encourages communication of stakeholder priorities. Needs for special coordination can be considered and discussed as part of this upfront planning. Questions about which comes first - the chicken or the egg - can be put on the table and addressed as part of the upfront planning in order to facilitate efficient progress and minimize disruptions and delays related to unmade decisions or changes. Everyone involved needs to take the discussion seriously and not kick the can down the road. QA needs to be process focused.

------------------------------
Albert Russell AIA
Architect
Albert R. Russell, Architect
Milton VT
------------------------------

Original Message:
Sent: 09-28-2017 17:45
From: Donald Henke
Subject: Use of Checklists for Q A

I would suggest you read "The Checklist Manifesto: How to Get Things Right" by Atul Gawande.

The point is not to place everything you can think of in a checklist, but to do what pilots and surgeons do, and make a checklist of the most critical items or items that are typically missed.

Donald Henke AIA

 

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 | dhenke@tcco.com

 

Original Message------

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.

p: 415.383.7011

c: 415.717.2755

Michael@StrogoffConsulting.com

www.StrogoffConsulting.com

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.

 

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.

------------------------------
Albert Russell AIA
Architect
Albert R. Russell, Architect
Milton VT
------------------------------

Original Message:
Sent: 10-09-2017 15:27
From: Albert Russell
Subject: Use of Checklists for Q A

I just downloaded "The Checklist Manifesto". From the descriptions, it looks promising.

I have been thinking about the challenges we face in managing architectural projects and how effective logistics (call it design logistics, if you will) are one key to effective QA. Firms may start projects without fully considering QA priorities and sharing them with staff and consultants who may otherwise operate with only their own priorities. Where the project work is broken into separate departments, even more upfront QA coordination is needed to make sure everyone understands and respects the same priorities. It's important to remember that there are likely to be many aspects of QA to consider other than accurate construction documents - from space program to aesthetics to building performance and environmental contributions to budget and schedule and more. For some who are involved mainly in developing construction documents or performing construction contract administration, QA may seem limited to achieving near perfection in construction documents, but that is not usually a sufficient basis on its own for an effective QA program, and that kind of QA document is not likely to see much use by designers involved primarily in the early phases of project design.

Back to the question of logistics, we are commonly challenged to develop and implement a sequence of design activities or tasks that can be followed without multiple interruptions and hectic revisions. Although it's possible that project priorities can be established sufficiently near the outset of a project to facilitate a relatively efficient design process, it seems more common that firms launch into design work following abbreviated past protocols without sufficient upfront consideration of applicable priorities for a specific project. Follow-up progress reviews during design are important as checks of actual progress against agreed priorities, but too often the demands of arbitrary deadlines lead to "fast and furious" but inefficient work. Then the responsibility for clean-up falls to the QC crew, and the QC checklists grow exponentially.

The upfront QA logistics should involve all stakeholders to an extent that encourages communication of stakeholder priorities. Needs for special coordination can be considered and discussed as part of this upfront planning. Questions about which comes first - the chicken or the egg - can be put on the table and addressed as part of the upfront planning in order to facilitate efficient progress and minimize disruptions and delays related to unmade decisions or changes. Everyone involved needs to take the discussion seriously and not kick the can down the road. QA needs to be process focused.

------------------------------
Albert Russell AIA
Architect
Albert R. Russell, Architect
Milton VT
------------------------------


Original Message:
Sent: 09-28-2017 17:45
From: Donald Henke
Subject: Use of Checklists for Q A

I would suggest you read "The Checklist Manifesto: How to Get Things Right" by Atul Gawande.

The point is not to place everything you can think of in a checklist, but to do what pilots and surgeons do, and make a checklist of the most critical items or items that are typically missed.

Donald Henke AIA

 

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 | dhenke@tcco.com

 

Original Message------

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.

p: 415.383.7011

c: 415.717.2755

Michael@StrogoffConsulting.com

www.StrogoffConsulting.com

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.

 

------Original Message------

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.

------------------------------
Albert Russell AIA
Architect
Albert R. Russell, Architect
Milton VT
------------------------------

------Original Message------

------Original Message------

I'm formulating some QA strategies that involve checklists for our firm, and the effort is prompting a few questions about strategies for developing and using them.  

Does your firm make extensive use of standard checklists for completion of projects? Or do you rely more on some senior, well experienced staff to guide the project to successful completion?

Do you use one "office standard" checklist, or do you have different checklists based on project type?  

If you have office checklists, what level of frequency do your staff actually use and refer to them?  Every project?  Or do the binders full of checklists sit on shelves collecting dust?  Do you have any formal requirement that staff members must complete and sign a checklist at a project milestone, for instance?  or are they just a guidance tool for staff?

How detailed are your checklists?  Many checklists (published by the AIA and others) are very comprehensive and long, attempting to address everything in cursory terms.  When trying to apply these to projects, I expect most staff would miss half of the nuts and bolts that are required to complete the documents with sufficient thought and detail.  which begs the question, how much detail do your checklists go into?  Do you attempt to spell it all out in specific terms, or touch on the topic (i.e. "coordinate foundations with utilities") and rely on the knowledge, expertise, and memory of the production staff to "fill in the blanks"?

How are your checklists organized?  One large 50 page nonstop list?  Again, many checklists can evolve into one unbroken string of tasks with little logical organization, making them difficult to use and manage.  Organized with tasks by phase? Organized by spec section or division?  

The bottom line - I'm attempting to build a series of checklists that follow the CSI spec sections, and organize tasks within those sections by the appropriate phase.  The idea being that the Job Captain or Project Manager (lead technical production manager for the project) can go through the list of Spec sections, pull out the checklists, and compile them, handing or assigning the appropriate sub-lists to the appropriate  BIM workset modeler (who owns that content) to complete over the course of the project. Tasks are organized by phase, and at the end of each phase the BIM modeler would initial the bottom of the column showing those tasks checked off and confirming the tasks have all been completed.  A benefit of this is that each checklist is relatively short, and specific to the products being used.  I've written many of them, and we've conducted an office "reveal" to the staff going over the content of each one. Prior to the "reveal" training session, staff have been emailed a copy of the PDF file for the list directly.  While we haven't created checklists for all CSI sections that we normally use yet, we've focused on those where the mistakes often happen - like Washroom Accessories of all things.  Accessories often go in at the wrong height, or conflict with grab bars, and when child height dimensions are involved, staff will often not remember the correct heights (or consult the codes and guidelines). The checklists lay all of this information out, in one convenient location with graphics.   Until we have all of our "usual" sections complete, we encourage the staff to use them; but to date, usually the staff don't even remember that we have them to refer to.  Before I expend a signficant part of my life developing more of these, I'm wondering if the checklist black hole syndrome is widespread, or if it's just us, because we aren't enforcing them yet.  

Thoughts?




------------------------------
John Thompson
Production Coordinator
Dore & Whittier Architects, Inc.
Burlington VT
------------------------------

​Based on 30+ years of practice I believe that checklists can be a useful reference tool for staff and teams to utilize at all stages of the typical design & construction project. For junior staff the office checklists can be an outline of tasks and workflow for them to learn from and follow. For project architects and managers checklists can be a handy reference as they develop their "work plans" of what tasks and documentation need to happen when and by whom.

It is noble that you are developing your own custom BIM and CSI aligned checklists and there are some examples out there if you search the web, including old AIA D200 checklists published 20 years ago (have not seen recent AIA checklists?). Our A/E firm has developed a set of checklist by discipline and phase (e.g. architecture, structural, MEP // for PD, SD, DD, CD, and CA).

I recommend that you use checklists that are clear and concise, and avoid making your checklists so long and detailed that staff avoid them or fail to see the most critical "forests through the trees" (i.e. the most critical and common pit falls).

I also recommend against adopting an airline pilot type checklist sign-off and filed documentation record for your QC checks. More than one attorney and liability and risk advisor has pointed out that well intended "filed" QC checklists, with records of checked work that did not get into the construction documents can be used against design professionals in claims discovery.

So by all means develop and use checklists as a reference tool, have a structured QA/QC process which gets used for all projects, but do not over do it and create a complex and bureaucratic set of checklists and procedures in design practice.

Good luck,


------------------------------
Ronald Weston AIA, LEED AP
Vice President and Principal
PS&S
Warren, NJ
------------------------------

Original Message:
Sent: 09-25-2017 12:16
From: Justus Pang
Subject: Use of Checklists for Q A

Have you looked into the Checklist Manifesto by Atul Gawande.  He's a surgeon / healthcare rockstar wonk, but its a really interesting read with ideas that may be applicable to what you are doing.

Personally I am doing a grassroots series of checklists for the draftsmen under me, but tackling one item at a time, so I don't have much to add to the discussion, but am definitely interested in this issue.

Regards,

JUSTUS PANG, AIA, LEED AP Las Vegas | Long Beach | Chicago 1200 South 4th Street, Suite 206 Las Vegas, Nevada 89104 O 702.839.1200 | M 510.301.8721 justus@aptusgroup.com | www.aptusgroup.com

Original Message------

I'm formulating some QA strategies that involve checklists for our firm, and the effort is prompting a few questions about strategies for developing and using them.

Does your firm make extensive use of standard checklists for completion of projects? Or do you rely more on some senior, well experienced staff to guide the project to successful completion?

Do you use one "office standard" checklist, or do you have different checklists based on project type?

If you have office checklists, what level of frequency do your staff actually use and refer to them?  Every project?  Or do the binders full of checklists sit on shelves collecting dust?  Do you have any formal requirement that staff members must complete and sign a checklist at a project milestone, for instance?  or are they just a guidance tool for staff?

How detailed are your checklists?  Many checklists (published by the AIA and others) are very comprehensive and long, attempting to address everything in cursory terms.  When trying to apply these to projects, I expect most staff would miss half of the nuts and bolts that are required to complete the documents with sufficient thought and detail.  which begs the question, how much detail do your checklists go into?  Do you attempt to spell it all out in specific terms, or touch on the topic (i.e. "coordinate foundations with utilities") and rely on the knowledge, expertise, and memory of the production staff to "fill in the blanks"?

How are your checklists organized?  One large 50 page nonstop list?  Again, many checklists can evolve into one unbroken string of tasks with little logical organization, making them difficult to use and manage.  Organized with tasks by phase? Organized by spec section or division?

The bottom line - I'm attempting to build a series of checklists that follow the CSI spec sections, and organize tasks within those sections by the appropriate phase.  The idea being that the Job Captain or Project Manager (lead technical production manager for the project) can go through the list of Spec sections, pull out the checklists, and compile them, handing or assigning the appropriate sub-lists to the appropriate  BIM workset modeler (who owns that content) to complete over the course of the project. Tasks are organized by phase, and at the end of each phase the BIM modeler would initial the bottom of the column showing those tasks checked off and confirming the tasks have all been completed.  A benefit of this is that each checklist is relatively short, and specific to the products being used.  I've written many of them, and we've conducted an office "reveal" to the staff going over the content of each one. Prior to the "reveal" training session, staff have been emailed a copy of the PDF file for the list directly.  While we haven't created checklists for all CSI sections that we normally use yet, we've focused on those where the mistakes often happen - like Washroom Accessories of all things.  Accessories often go in at the wrong height, or conflict with grab bars, and when child height dimensions are involved, staff will often not remember the correct heights (or consult the codes and guidelines). The checklists lay all of this information out, in one convenient location with graphics.   Until we have all of our "usual" sections complete, we encourage the staff to use them; but to date, usually the staff don't even remember that we have them to refer to.  Before I expend a signficant part of my life developing more of these, I'm wondering if the checklist black hole syndrome is widespread, or if it's just us, because we aren't enforcing them yet.

Thoughts?




------------------------------
John Thompson
Production Coordinator
Dore & Whittier Architects, Inc.
Burlington VT
------------------------------

Hi John,

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

Centerbrook, CT

------------------------------
James Coan AIA
Senior Director, Architectural Practice and Building Science
Centerbrook Architects & Planners
Centerbrook CT
------------------------------

Checklist are only as great as the checkers. 

We employ a "SCRUB" method that has worked well for our project types and sizes.  Nearing completion of a CD set (or perhaps a DD set of a larger project) we gather into one room all of the critical project players. If not possible to physically gather we do it via internet.  Our Project Architect and our Consulting Engineers are the key folks.  Plans are reviewed by all for major aspects of coordination, completeness and clarity. The exchange is usually lively. Result is a checklist of items required to wrap up the work.  This method has helped the entire team focus on quality and it establishes a key completion timeline for all.  Plus - its more fun to check a project in a group setting...so it gets done better.

------------------------------
Glenn Angelle AIA
Angelle Architects LLC
Breaux Bridge LA
------------------------------

------Original Message------

Checklist are only as great as the checkers. 

We employ a "SCRUB" method that has worked well for our project types and sizes.  Nearing completion of a CD set (or perhaps a DD set of a larger project) we gather into one room all of the critical project players. If not possible to physically gather we do it via internet.  Our Project Architect and our Consulting Engineers are the key folks.  Plans are reviewed by all for major aspects of coordination, completeness and clarity. The exchange is usually lively. Result is a checklist of items required to wrap up the work.  This method has helped the entire team focus on quality and it establishes a key completion timeline for all.  Plus - its more fun to check a project in a group setting...so it gets done better.

------------------------------
Glenn Angelle AIA
Angelle Architects LLC
Breaux Bridge LA
------------------------------

I apologize for not having read thru this entire conversation, so my comments may echo others.  I have been involved with checklist programs for the 40 years or so of my career, so I offer this:

A favorite book of mine is "Team of Teams", General Stanley McChrystal.  Somewhere in there he describes the difference between something that is *complicated* versus something that is *complex*.  Breifly, complicated things can be handled with checklists; complex things cannot.  For example, your typcical plan reviewer at an AHJ will work off of a checklist.  His/her job as a plan examiner is complicated:  different building types, different locations, different structural systems.  But his/her job is not complex, because the AHJ is not the architect of record.

Our work as architects is nearly always complex because we add the elements of the customer, the climate, site orientation, cost versus dreams, schedule constraints, etc.  Our success revolves around process, which is a different paradigm than "products".  I saw the word "scrub" somewhere in this thread.  I would have said "scrum" in my work, but I think it is the same thing.  Getting the experts together in the same room and going thru the project a critical phases.  There is not a checklist that can help with our kind of complexity.  The term "scrum-agile" comes out of the software development world.  Frequent critical meetings, 15 mins in length, lead to a final design and lead to solutions to problems.

Does this make sense ?

------------------------------
William Adelson AIA MBA
Owner
Elevated Solar Performance, Inc.
San Diego, CA
------------------------------

Original Message:
Sent: 09-26-2017 18:36
From: Albert Russell
Subject: Use of Checklists for Q A

Checklists are usually built on lessons learned, looking back at projects (design docs, CDs and/or CA). Those are really QC checklists. QA needs to be forward looking, considering the design process, which is rarely if ever a straight line that could easily adopt a checklist approach. QA needs to consider individual and team interests and motivation. The team might be goaling toward a perfect project, and a checklist might be translated into a guide for getting there, but a typical QC checklist doesn't seem likely to answer the QA need.

Original Message------

Checklist are only as great as the checkers.

We employ a "SCRUB" method that has worked well for our project types and sizes.  Nearing completion of a CD set (or perhaps a DD set of a larger project) we gather into one room all of the critical project players. If not possible to physically gather we do it via internet.  Our Project Architect and our Consulting Engineers are the key folks.  Plans are reviewed by all for major aspects of coordination, completeness and clarity. The exchange is usually lively. Result is a checklist of items required to wrap up the work.  This method has helped the entire team focus on quality and it establishes a key completion timeline for all.  Plus - its more fun to check a project in a group setting...so it gets done better.

------------------------------
Glenn Angelle AIA
Angelle Architects LLC
Breaux Bridge LA
------------------------------