In engineering, what really matters?
What do you do when your project has features outside of the normal specs?
I sometimes wonder if the specifications we create are really any different than the bricks I’ve seen used as doorstops from time to time. I also sometimes wonder what is relevant, what is related, and whose job is it, and would (should) we, as engineers, do things the same way and with the same passion and integrity even if no one is watching? The answers I come up with are usually the same: Everything we do is relevant, it is all related, and having two sets of standards is dangerous, confusing, and unethical. After all, we are engineers, not politicians. But I digress.
Contract documents are comprised of a set of design drawings and project manuals. Project manuals include general and supplemental conditions of the contract along with various specification divisions. Engineering sections were confined to CSI MasterFormat Divisions 15 and 16 years ago, but are now more frequently included in the newer CSI format of Divisions 21, 22, 23, 26, 27, and 28. Many engineering firms have a master specification for each section that includes normally specified materials and items. Some firms develop these in-house while others use specification software created by third-party companies. All good so far.
One of our tasks as engineers is to create specifications that match our project design. How do we do this? Usually by editing the master specification sections to include necessary components. But what do you do when your project has features outside of the norm? Perhaps you need stainless steel pipe or type 316L welded ductwork. Do you just call it out and hope for the best or actually add it to the specifications? What should you do? Do what is easiest and deal with it later, or do what your client views as your obligation?
Some engineers create their own “master specification” by project type from a past project and use it again because the new project is exactly like the old one. Why start from scratch (master) when a specification is already created? As I recall, projects are similar, but not exactly alike. This practice is dangerous as it avoids paying attention to the new project’s actual needs or other jurisdictional requirements.
We all gain knowledge and experience from projects we complete, but is it better to gain 10 years of experience once, or 1 year of experience 10 times? Do we enjoy making the same mistakes over and over just because it is in the master or because we know the answer when the request for information (RFI) comes? Or do we strive to correct the past and focus to avoid spending additional contract administration time? Our contractual obligation is to prepare specifications to the best of our ability to match the project while leaving the means and methods to the contractor. It is an effort to do so, but for me, so is getting to work some days.
Generally, engineering specification sections have a reference to Division 1. How often do we actually read Division 1? Are we sure the information we seek is really there, or do we use it as a catchall to say “not my job” with the notion that if it is in the master, it must be correct. Again, our obligation is to write, review, and coordinate clear, concise, and project-specific documents. Can we do that if we do not read what we reference?
I have noticed that master specifications can be intimidating and can create a sense of “read, but do not modify” in young engineers. Convincing them otherwise can be a chore, but we must remind them that a properly prepared and coordinated document is the better alternative.
Now, back to my previous digression. Everything we do matters. It is all related and relevant, and our reputation and integrity are at stake. We should do it because it is expected and is the right thing to do. It is our responsibility, not just our job. We are not perfect and do not try to be; however, if we fulfill our obligation, our moms would be proud. What’s better than that?
Banse has more than 35 years of experience in the consulting engineering field with the past 30 years in healthcare design and engineering. He is a member of Consulting-Specifying Engineer's Editorial Advisory Board.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.