A task I have often performed is to peer review other projects. In addition to checking for project progress and adherence to firm standards, the primary purpose is to catch issues and prevent them from developing further in the model and documents or making it to the field.
In one occurrence a large building addition was well into the construction drawings phase. During the mid-CD peer review I noticed the thickness of insulation used in the EIFS wall system was well less than the what the manufacturer called for. I knew this as I had recently researched and used a similar EIFS system on a project. Speaking with the project architect, his truthful response was - "well I thought the insulation thickness was enough". My answer back was that it did not matter what he thought, but rather what he knew.
I have encountered this often enough that it bears talking about. There can be negative implications to giving the same weight or authority to "what we think" as to what we know. During the design phases we address subjective issues necessitating the use of judgement and opinion and a certain freedom is needed to pursue and test ideas. When producing contractual documents, addressing issues of constructability or verifying egress requirements, a different approach is called for. We must know what truly works as opposed to what doesn't, and that is usually based on comparison with recognized standard. Projects require a blending of both approaches during their development and it is important to know when to apply each.
When we identify and deal with a problem is key
Referencing the earlier project, after review of the EIFS manufacturer's requirements, it was necessary to increase the insulation thickness. This required multiple document changes to exterior walls and details as well as checking for design implications. Work had to be "undone" and then redone. From the Lean perspective, we identify this as "waste". From a practical standpoint, it was lost profit.
Research done early to understand building systems requirements and to ensure compliance with codes and standards can pay a dividend downstream simply by not having to recreate our work. The architect’s efforts are not linear and there will always be some 2 steps forward, 1 step back - the point is to minimize that and not make the same mistakes again.
It was important to communicate the idea that for many aspects of work, opinion is not what is needed nor necessarily relevant but rather actual knowledge.
The effort expended to research and acquire knowledge by itself serves to embed it in our minds, in this case the capabilities and constraints of a product, i.e., we learn. Additionally, the discipline that develops from doing this repeatedly (when you aren't sure or don't know) brings a recurring benefit as it becomes part of our nature and approach to working.
The detail on the left is from the mid 1980’s and the one on the right from 2019. Knowledge gained over time dictates a larger airspace behind the masonry and new techniques and products to manage water that gets into the cavity.
Some of what we know changes over time
Stepping back into the project architect role after years of absence taught me two things:
Knowledge is iterative and increases over time. Some things that I knew have changed and are no longer good practice.
The discipline to check and make sure what one is doing is correct proves its value over and over again.
Conclusion
Some effort is required to understand the issues affecting design and the models and documents that describe it. Said before, it is always better to prevent an error from being built into a project than to expend time later to find and then make corrections. The later an issue is uncovered and a change is made, the greater number of drawings and model elements that are affected. Worse yet is having to deal with errors or omissions during the construction phase where they can lead to change orders or adversely impact the schedule.