Stephen R. Gelman: Lessons Learned in My 40-year Engineering Career (Part 4)

My first piece of advice is the only “rule of thumb” I believe in: Beware of rules of thumb. Every engineering project is unique or has some unique features. So, beware of using any rule of thumb as hard design criteria.

Basis of design

It is difficult to have a successful project if the design basis is not firmly established and agreed on by relevant and knowledgeable parties. The basis of design includes a strict definition of project requirements. How is it going to be used? Operated? Maintained? Under what conditions might it not work? A really simple example is designing a stormwater culvert. What is the basis of the storm it will be designed to work under without flooding? Sometimes the conditions are set — for example, culvert size is constrained by road elevation. Then it is incumbent on the engineer to tell the owner when it will likely flood the road.

The owner must understand and agree to the basis of the design. All parties need to understand the data that will be used for design. Are there adequate data available? If not, who is responsible for getting additional data? There are many other examples. These include material of construction, types and complexity of control systems, redundancy, etc. All of this and more has to be defined in the early parts of the project and often in the proposal.

Another piece of the basis of design is allowing for off-normal conditions. What degree of redundancy do you design in? Different owners and different situations have different needs based on safety and criticality of operation. In some cases, codes will tell you the answer, but many projects require the owner and engineer to decide on the degree of robustness to build into the design. An example could be whether to insulate and heat trace piping for an intermittent industrial waste treatment system in the South, where it does not often freeze, but a single event could cause significant damage. Process designs have many of these kinds of issues where there is no right or wrong (assuming the decisions do not have a safety element).

These types of decisions need to be made and documented.

A decision that may be considered on the basis of design is how the project will be delivered. Will the owner or contractor buy major equipment? Is the project design-bid-build or design-build? And how will the project be operated, which impacts process automation and control approaches? The more of these issues get resolved early in the project delivery process, the more likely the project can be efficiently done.

Average, is just so average

When developing design criteria and basis of design, beware of the use of “averages.” Averages may be useful for figuring out some of the operating costs or quantities, but they rarely dictate the design case. Engineers do not have to be statistics experts, but they need to know enough to understand data variability and the likelihood of more extreme occurrences. Maximums are not necessarily the dictating criteria in setting the design basis. In closed conduit flow, for instance, minimum flows may need to be accommodated if certain velocities need to be maintained to avoid deposition. So, defining all the conditions and ensuring the design “works” for all is critical for a successful project.

Off-normal conditions — not normal, but important

You may think we just covered this subject above, but this is more nuanced. This involves a systematic examination of various fault modes and how the system performs and how you instrument and control it. An example is what happens in a power outage in a process plant. Do valves fail open or closed? And how does the plant function when various units are taken out of service for repair or planned maintenance? What happens if you are near a peak flow condition? Have you properly isolated units with shut-off valves? Is the piping adequate when flows are redirected around units out of service? Another part of this is process safety during power outages. Even with backup power, such as a generator, how do you handle things if backup power goes out? There is no magic answer to dealing with these issues other than engaging experienced people, including the owner, and using a systematic procedure to go through and document findings and implement them in design.

A special off-normal condition is startup or shutdown. Many design conditions are set during startup. Structural systems are most vulnerable during construction when all members are not fully installed. One of my favorite examples was from a client who had a design for a pumped line from a collection point to a holding tank across the plant. They decided to pump over the building and back down to the tank at grade. The static head on the pump at steady state was low since the collection point and the tank were near the same elevation. But getting over the plant required pumping head beyond the head needed assuming the system was at steady state. The pump did not have enough head to get up to the plant roof level. If they had considered that in design, they would have either had a pump with higher head capability or they would have realized that a pump capable of getting over the roof was oversized for the longer-term condition.

Startup conditions can drive issues with electrical design, and structural failures can occur during construction when all bracing is not in place, and the structure does not behave as it would when complete. During commissioning, there may be times when more equipment is running than would be normal. This can place more electrical load than would ever be seen during operation. This is more of a need to carefully plan commissioning activities but also needs to be considered from a design standpoint.

Data analysis

Most engineers will spend some time analyzing data. This can be from field or pilot testing, performance data, design conditions, or many other sources. I never took a course in statistics, but statistical functions are easy to use in spreadsheets. My caution is to carefully study and parse data before blindly applying statistical analysis. This may be apparent from the previous discussion. But fully understanding what was happening when the data were obtained can help sort out data that may skew results. Examples from the design of wastewater treatment facilities are easy to envision. Often we would find an unusual event, such as a spill or an aerator being out of service, that drastically could affect statistical data if blindly included. If spills were common and needed to be accounted for, we would look for separate data on spill types and occurrences and possibly add them to “normal” operating conditions. So, the advice is to understand all the conditions around the data you are analyzing and use good judgment as to what is prudent to include in your analysis.

Reuse of designs — not the best thing to recycle

There are two parts to this. One is when an engineer has something they used in the last design and decides to “reuse” it on the next project. This may be a cost-effective way to cover a design element. The caveat is that you need to make sure that the conditions are the same or close enough to apply the same design. And you need to know that what you previously designed was built as you designed it and that the operators are satisfied with the design. Many engineers skip one or all of these steps—particularly the last one, since they may not be involved with the operation of the facility. Repeating solid, workable designs is prudent. Duplicating mistakes is not. And some subtle differences between the two situations can often render a good design less than ideal.

The second part of this is when an owner reuses your design without your knowledge and without considering the caveats above. One way to deal with this is to explicitly communicate with the owner (via contract term) that this is not allowed contractually, and the engineer is absolved of any liability. The owner may do so at their own risk. There is not much else the engineer can do if the owner insists on reusing a design, but it is not a good practice.

Google engineering — stay in your lane

Obviously, Google would have been foreign to me when I first entered the field. But misuse of internet resources has become an issue that is quite risky and dangerous. This involves an engineer (or non-engineer) going to Google or another source and thinking they can operate outside of their discipline and expertise. Google may be a good place to get conversant in a subject so you can talk to an expert, but it is not the place for a civil engineer to try to become an electrical engineer— or even for a civil engineer who has expertise in water quality to try to hone his or her structural engineering skills that he or she may have had a few courses in as a student.

This may sound obvious and trivial to some. But it needs to be taken seriously. If you are in a position of responsible charge, it will fall to you to ensure that you do not have rogue team members wandering out of their areas of expertise. The internet is invaluable for certain uses, but relying on Wikipedia as your technical reference is not one of them. So even in your area(s) of expertise, use reliable technical references and competent people who have the proper expertise.

Multi-discipline

Most projects require several engineering disciplines as well as architecture and science specialties, depending on the project. That is part of a “normal” project. Often, some of the best and most innovative solutions involve collaboration among different engineering and science disciplines. One example is natural wastewater treatment systems. Plant biologists and agronomists understand soils, plants, and the characteristics of different types of systems. Engineers typically are needed to deal with water flow, distribution and waste characteristics that may not fit the scientists’ experiences. Working together, these teams can develop unique solutions far better than either could do on their own. Design is a collaborative process where all the disciplines need to align on what works and is optimum for the ultimate user. The best designs involve the disciplines early, even when their work may not be early in the schedule. And it is advisable to bring construction-savvy people to engage throughout the design. Ultimately the project must be built, and contractors have ideas from experience that can affect layout, materials, or methods. I once did a project with a waste pond relined with a bentonite-soil mixture. I consulted contractors on how they would best mix the materials rather than just specifying a method and tying their hands or facing a change order.

Geography matters

It is important for the engineer to recognize the differences in solutions and approaches in different geographies. These involve not only local customs and preferences (e.g., concrete v. steel pipe) but also the differences that climate can play even in selecting a solution. For instance, “zero liquid discharge” systems from power plants and some other facilities are feasible in the West, where evaporation can greatly exceed rainfall. These systems can be cost-effective if brines can be discharged to a “solar pond” for evaporation. However, solar ponds do not work in the Southeast, where rainfall greatly exceeds evaporation. Cooling and heating options greatly differ across the US and around the world. Also, how we heat and cool buildings or processes vary according to the local climate. All of this is before we even consider climate change, and climate change will only make the issues more dynamic.

Local knowledge is critical in dealing with soils and geotechnical issues. It is critical to engage local resources or resources with local knowledge in these parts of the project.

Models are great — but understand their basis and limitations

Much of design and analysis is done using models. It is incumbent on the engineer to clearly understand the theory behind a model and to understand its boundaries and limitations. Ideally, you will have an alternate method to check any results. Most companies have licensed CAD and CAE systems that have proper documentation and validation. Assuming you understand the basis and limitations, these models are best for use in design and analysis. For many other calculations, you may use models from legitimate and referenced sources (see the above section on Google engineering). Many have built-in assumptions. There is simply no substitute for experience to understand the reasonableness and accuracy of a model output. And there may be vendor models online or a co-worker’s model. These need to be checked and understood before using the results. A model without documentation is not of any value from my perspective.

Vendor relations

Vendors are critical parts of most design projects. Equipment and materials are procured through vendors via dealing directly with a supplier or going through a vendor representative, depending on how a company presents itself to the market.

It is not uncommon for vendors to do part of the design for self-contained components. Another option is that the engineer presents the technical need and design constraints and gets a recommendation from a vendor. Finally, you may give the overall output needed and have a vendor recommend a turnkey solution. In any case, the engineer needs to understand the problem and the approach and recommendation by the vendor, assuming the engineer has the ultimate responsibility to the client. As in the model discussion above, you should have your own calculation of what you expect the vendor’s recommendation to be. Simple examples are pump sizing and power demands, aerator or mixer sizing, etc. The vendor has models to make these calculations and select products from their product line. By talking to several vendors, you may find some have very close to what you need, and others may need to under-or oversize to fit their product line. They could undersize (more likely provide less safety factor rather than something that does not work) for competitive reasons. Or if they are too close to the edge, they may have to oversize.

It is incumbent on the engineer to know whether they are getting comparable recommendations from different vendors. Often there are differences in materials of construction or instrumentation type and quality that can result in large cost differences. One area I have less concern about is letting the vendor recommend materials for integral parts, such as gaskets and elastomers, as well as overall materials of construction. The engineer should still know when you use stainless steel and the reasons for the different alloys, and ideally, the engineer will be in-house expertise to help.

Often vendors of equipment or materials do laboratory testing as part of their service. It is advisable, at a minimum, to have an independent laboratory validate the results. Ideally, there should be independent testing in lieu of or in conjunction with vendor tests. You may have the impression that I do not trust vendors. The reality is that most often, the engineer has contractual responsibility for the project and is entrusted by the client to be independent and act in the best interest of the client. Overall, vendors want their products or services to be successful, so they act in good faith. But they do have a different motivation than the engineer, and that is to make a sale. One positive approach: When you find excellent vendors, stick with them. Successful working relationships with vendors are a valuable asset for the engineer and the vendor.

Another vendor-related issue is that I do not like “black box” technologies. Vendors may not want to divulge what their system does or how it works. It is important to be able to ensure that the chemistry, physics, and thermodynamics make sense. As a general rule, vendors should be willing to give the engineer technical details to allow an independent assessment of their technology. If they are worried about disclosing confidential material, it is quite common to agree to a non-disclosure agreement to protect their intellectual property.

Another issue that some believe offers protection is a warranty on the equipment, process, or material provided. These, like most warranties, are very tightly established and difficult to enforce. There is no harm in seeking the best warranty you can get, but it is not prudent to believe this ensures anything of much value to the client other than typical defective parts and materials clauses.

Materials and coatings

I mentioned materials of construction in the previous section. This is an area where you likely get little or no training or experience and need to rely on others. It is a critical part of many projects and includes metallurgy issues such as type and grade of steel, coatings and paint, especially in difficult applications, and elastomeric or polymeric parts that are common in much rotation equipment. My advice is once again to know what you know and seek advice. Your company may have in-house expertise, you may rely on the vendor, or you may need a consultant for a particular project. Many specialty coatings are sold and applied as a turnkey process because application technique is critical to success. This is not usually paint but epoxy and specialty coatings for floors, concrete slabs or walls, and tanks. The consequence of poor paint and coatings can be an area of claims since it can impact the operability or aesthetics of a project. Seek help where you need it.

New and innovative technologies

There is often a tension between the tried-and-true technical approaches and technologies versus new and innovative technologies. From a consulting point of view, this tension needs to be resolved and endorsed directly with the client. Some clients are forward-looking and are willing to invest in the testing and development work for newer technologies. Others want something they already have or that has had multiple applications that they can see and understand. Some clients are willing to develop and patent new technologies. So, it all comes down to good communication with the client and understanding their needs and appetite for new approaches and technologies.

On the intellectual property side, most of what consultants have is know-how. They typically do not own technologies. Some have licenses and sell the technology to companies more suited to marketing and manufacturing. Successfully owning technology and profitably applying it is a fundamentally different business from providing design and construction related services. Before you patent something, you should have an end game in mind. Holding patents past a one-year provisional patent requires continual investment, and without a plan to monetize them, they can be a nuisance. On the other hand, manufacturers and companies that have strategies to own technology usually have robust processes and capabilities to work with the technical staff to deal with these issues.