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

May 22, 2023

Over the next few days, the Bagley College of Engineering will be publishing Stephen R. Gelman's "Lessons Learned in My 40-year Engineering Career" in multiple parts.

Join us as Gelman imparts wise advice and lessons from his many years in engineering.

Gelman is a two-time graduate from the BCoE, graduating with his B.S. in civil engineering in 1973 followed by an M.S. in civil engineering with a concentration in environmental engineering.

Some Other Topics

Contracts, Insurance and Legal

When most engineers graduate with their bachelor’s degrees, they probably never envision needing to know about contracts, insurance, and legal issues. But if you manage projects, write proposals, or run elements of a business, you will need to have a basic knowledge of these areas. What you need to understand is that engineering is typically less than 10 percent of the total project construction budget and likely to be in the three to five percent range. Decisions made by the engineer can be costly to the owner, and if you are not protected, you can easily lose more than your profit and your total fee.

What proved invaluable in my career was a course my firm required us to take called “Untangling the Web of Liability.” I believe our insurer gave us a break on rates if we had engineers in responsible charge take this course. I could write a book on this subject and the book would be the course we took, so I will try to give you some key points to clarify the importance.

First, most engineers have standard contracts that, if well-written, take care of the major issues. But often, industries and governments require their contract terms. The biggest sticking point is that the engineer needs to be responsible for their errors and omissions, while many contracts try to hold them to all errors, including the owner’s, even if they are only slightly or partially responsible. And the engineer needs to limit their liability to something reasonable in relation to their compensation. The classic example is when an engineer does a flood study, and ten years later, there are floods, and the client and landowners want the engineer to pay for all the damages. In this case, the engineer will need to seek some indemnity (if possible) so the client protects them from third-party lawsuits. Generally, a fair deal is that a client is entitled to the engineer redoing work at their cost to correct an error. And the term “betterment” needs to be understood. If the engineer did not specify a drainpipe, but if they had not made the error, the owner would have had to pay for the pipe anyway, then the engineer should not have to pay the entire cost of the pipe.

The prelude to much of this is insurance. Claims for errors and omissions are covered in a professional liability policy. Many clients assume they are covered in a general liability policy like you have on homes or automobiles. Professional liability insurers are quite specific about what they cover and what they do not cover. You may agree to something in your contract that your insurer will not cover. For instance, they will not cover you if you agree to be responsible for the owner’s errors (and many contracts will ask you to do this). Clients can give you data, and you can use it and then find out it was wrong, yet they may want you to correct errors that resulted from you using their data.

Without going too deep on this, the key point is that you are providing a service to a client, and they are the ones who will benefit from the project. So they need to not burden you with undue risk. And you must be prepared to walk away from bad contracts.

Part of knowing your client is knowing how to deal with these issues during negotiation or after the project is going on. Often lawyers or contract specialists on each side carry on the discussion. But ultimately, the businessperson must engage. They have to evaluate what risk they are willing to take, how much they need the work, and whether the project is of significant importance to the geographic or strategic goals of the firm. The lawyers can lay out the risks, but ultimately someone with business responsibility must make the final decision. If you are in that position, do not wait until the end to get engaged. Often a call to the businessperson on the client side can resolve an impasse in a fair manner.

If you are in engineering long enough, you may face litigation over a project or over personnel or contract issues. It is not uncommon. If there is one thing to remember is that everything you put in writing will show up in the discovery process. So be careful what you write. Here is an example. There is some litigation over an electrical issue on a project. Plaintiff claims you made mistakes, and they are entitled to some compensation. During design, the project manager wrote a blistering email to the lead electrical engineer telling him one of the engineers was inexperienced and was screwing up. The email is read to the project manager during the trial. There is no defense they can offer. Always be professional in your written and oral discussions. If there is a real problem, pick up the phone or have a face-to-face to resolve it. If you have to put something in writing, remember to get your point across in a way that you would not mind being discoverable. This applies beyond litigation. You cannot undo what you write.

Another piece of advice I once got on personnel litigation: keep your values but do what gets you out of the situation for the lowest cost. Litigation is expensive. So even if you think you are right, you should consider settling if it’s less costly than litigation which still can find you liable even if you are positive you are not. There are cases where you do not want to set a precedent by settling, so this is not a blanket recommendation. But the big picture is engineers are not helping their company if they are not on their day job and are being deposed and in court. There is no substitute for good legal advice mixed with sound business decisions.

Here are some key points:

  • Contracts need to be fair to both sides. Beware of one-way clauses.
  • You are not an insurance company, and you cannot get your insurer to cover other parties’ errors, omissions, or negligence.
  • If a contract has a standard of care, it needs to be what the industry generally provides. I have seen many contracts that ask for the highest” standard of performance. That is a standard that cannot be met.
  • You should always seek a limitation of liability in your contract. Any limit is better than no limit, but ideally, it is limited to your fees (refund total fee — that is about what you would expect on a bad appliance).
  • Third parties are not covered by a contract between the engineer and the owner. This really has more to do with project selection and risk management than with the contract. But if there are already third-party suits or rancor, you can ask the owner to defend and protect you from third-party activities arising from your work. You will likely not get them to agree to this but ask. And this goes to the next point.
  • Discuss in detail terms that concern you and why. Many times, an owner includes clauses that they have a specific worry about; if you tell them what you are concerned about and listen to their concerns, you may be able to come to an agreement on a modification. We had an owner who had very broad language about what they were not responsible for. It turns out they did not want our employees suing them if they were injured on their site. Since we rarely had this happen and we had other ways to help an employee who was injured, we said we would protect them from this and were able to narrow the language. It pays to talk things out.
    Text Box: Deliver Results	Ultimately will not work out with company	Coach and develop to increase delivery or they will not work out.
	Why are they still here?	Work with to improve performance
	Embrace the values
  • The language on the back side of a material purchase order is almost never suitable for performing professional services.
  • The contract language is important but much litigation is dictated by existing case law as to how various terms are interpreted in a particular jurisdiction. Engage attorneys when needed.

Price and cost

These terms are often used interchangeably, and they should not be. Price is simple. It is what you pay for goods and services or what you charge for something. Cost is a very different concept and depends on how you count costs. Price may be related to cost in “cost-plus” contracts, or it may be unrelated (fixed price or lump sum). I will not dwell on this but realize that if you do cost-based pricing in government-compliant contracts, you are required to verify real costs, and the government entity will audit you to determine what they consider costs. Timekeeping becomes much more complicated. You can use cost-based pricing with private or commercial clients as long as you define costs up front and they accept them without audit. It is expensive to be audited, and you do not want to be audited after the fact and give back money. There are really two points here. One is for non-government work pricing; you can consider costs but should also factor in risks, uniqueness of offering, and other items that may allow you to get more margin. The second point is to be fully aware of what is involved in government contracting, as it may add a new layer of accounting and compliance that you need to consider in your business ventures.

The simplest type of fee arrangements for both customer and engineer are fixed prices with clearly defined milestones (deliverables) and earned values for each milestone. Produce the deliverable and invoice the agreed amount for that deliverable. You can do this on projects where deliverables are clear and the effort and cost to get there are reasonably well defined. You need both. But I have found that many customers treat a reimbursable contract as a fixed price. You cannot simply say, "It took more effort than we planned, so pay us more just because we did it.” Your estimate at the proposal level needs to be pretty good. This gets back to the concepts in project management discussed earlier. Change management and the ability to work with a customer on the scope and where you are, are critical to being covered for work not budgeted.


No matter what you do with your engineering degree, you will end up in many meetings, live or online. There are lots of articles on how to have effective meetings. Here are the things I have found:

  • You always need to assess why you are meeting, what you hope to accomplish, and who should attend. Many meetings are scheduled far in advance, and the agenda is made up later. Meetings where there is a real need are more effective and invigorating.
  • The single most important factor in a successful meeting where you hope to make decisions is to do the necessary staff work in advance to prepare. This includes giving attendees important material in advance so they can study it, develop questions and form opinions. Many meetings present a lot of information and expect meaningful input all at once.
  • Do not ask a group to provide input to a decision that has already been made.
  • I developed a set of meeting guidelines that I gave at the beginning of meetings that had to do with meeting behavior. Examples: No sidebars; speak for yourself; make sure you understand what someone else is saying before objecting; phones off; honor agenda and breaks; etc.
  • I have seen two approaches to sticking to an agenda. One is to get through the issues even if they take longer than planned. The other is strict adherence to the timeframe. If you do not get to closure, wrap the topic and deal with it later. It is probably best to have a hybrid. If you go with the former, there are times when you could be in for a 12-hour meeting. The latter can leave people frustrated. One way to take a hybrid approach is to revisit the agenda midway through the meeting time and, if necessary, cut some agenda item that is not as pressing and try to stick to the original schedule.
  • When a group of people who are not familiar with each other meets to address some issue or to start a project, it is a good idea for each participant to express what they bring to the table and what they need others to bring. You can find out a lot about people’s experience and skill sets that you may not have realized, and you could also find gaps in what the team needs.