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

May 3, 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.

Client - Relationships and management — more than schmoozing!

Types of clients

I have found that you can have clients that fall into any of three categories as far as technical input based on competence and/or available resources in a particular area. The first type of client is one that has very strong engineering capabilities but lacks either the specific knowledge or staffing required to complete a project of any scale. These clients can give you great insight and will have definite ideas on technical approaches, specific equipment preferences, and other details such as materials of construction. They will also review and comment on your work and will probably have some rigorous design standards and processes. Major industries and larger municipalities typically fall into this category.

The second type of client has some technical competence, though you may not deal directly with an engineer as you probably would with the first client type. They will know their systems and have ideas, but they will need expertise and staffing to do projects of scale. An example of this is a utility that has an engineer or a smaller industry that has a plant engineer, but they do not have the resources to do a full design or many studies themselves, although they know enough to give guidance. A plant engineer may have a broad knowledge of electrical, mechanical, and control systems but not know much about environmental issues. They will have some comments on your work but probably not the degree of detailed review that you see in the first client type.

The third type of client is the owner who has little technical expertise but has an engineering need. This could be a homeowner or a small-town city manager. They will use your work processes and give very little technical review. They just care about the final product and do not particularly care about how you get there.

The point I want to make here is that as you go down from Type 1 to 3, the client likely needs more of you and your team to make key decisions. If you present Type 1 with some ideas and options, they will have definite opinions and probably no problem deciding on an acceptable or preferred approach. By the time you get to Type 3, they will depend almost completely on the engineer to make the recommendation. A simple example is backup power. Type 1 will have definite input into location, capabilities, tying in the control systems, etc. In contrast, a homeowner with no expertise at all will go with a vendor’s recommendation and may only use cost as the decider. In this example, Type 2 would likely be closer to Type 1.

There is another way to classify clients: how they deal with money and contract commitments. Remember that I am writing primarily from a consultant’s point of view. Some clients understand the scope and complexity of the project you are engaged in and are very fair in understanding the effort you intend and how to deal with uncertainties, etc. These clients often take the lead in asking you about the schedule and budget and will work with you to deliver the effort and cost you agreed to. They are also open to changes for legitimate reasons. The other extreme in client attitude is to be unbending, and they may use the contract as a hammer. They believe any scope or cost creep reflects poorly on them in the eyes of their management and will put the burden on the engineer to deal with uncertainty and scope creep.

For a consulting engineer or any service provider, customer relationships are key to successful projects and work in general. While those reading this may think it applies only to consultants, every service provider and every company has customers who must believe they are getting good value and service. This applies to any engineer, though some parts will apply more to those selling directly to outside customers.

For the most part, in any project, there is some tension between the scope of work and the cost allowed to do the work. How much tension depends on how the project was envisioned and estimated to start with. Often in a desire to win work, an engineering team may underprice a project in the proposal stage. On the client side, the engineers may have told management that something can be repaired that, in fact, needs replacing. In either case, there will be some tension in the project that is not necessarily bad but is part of doing the work.

All situations are not ideal. Sometimes a customer will say what they intend to spend, and you will back into the scope and effort. This approach can work, but it requires open and honest communication so the customer knows how you plan to deliver and where you may spend less effort than you think is optimum. An example can be a feasibility study where you may have to limit the scope to two or three alternatives rather than following a desire to look at broader solutions.

The best rule for dealing with customers on cost, schedule, and problems is to be up-front, timely, and honest. I have found that problems do not get better by delaying or ignoring issues. The best clients I ever had started every call or meeting with, “How are we doing on schedule and budget?” The other rule is to be realistic on Day 1. If the schedule really needs to be three months, don’t agree to do it in two months and try to explain it on the last week of month two.

A good goal is to know your customer. Good salespeople pride themselves in knowing the birthdays of the customer’s family members. I am not that interested in that. What I mean by knowing the customer is more inclusive of business terms. For example, how is the client’s company organized? Where does my client fit in with the organization? What authority do they have? How is the project funded? How do they and their organization view change? Have they ever done projects like this before?

One of the best tools I have seen and used for feedback and communication is a periodic qualitative and quantitative review of the project by both the client and the engineer. The process is to agree on a set of criteria, such as schedule, quality of deliverables, staff responsiveness, etc., and to grade them. What you get from this is a chance for each party to communicate expectations and performance and to identify any issues early (rather than when the final product is delivered). A side benefit is that this approach can help in the mitigation of claims. The client goes on the record, and if they praise you for 80 percent of the project with specific comments and scores, it is hard to say later that they were dissatisfied. You can even tie compensation to the score. Par performance delivers the agreed fee, and fees may be adjusted up or down by the agreed-on score.

Much of client relationship management boils down to good (and frequent) communication and being honest with them. Listening skills are imperative. Always ask clients what constitutes a successful project to them. This is the area where the formal periodic review should yield the answers. It is always advisable that your organization have relationships at several levels in the client’s organization. Feedback and input from multiple sources are helpful.

Many technical people do not like discussing money. Project budgets are important, even if the client has not specifically said so. Start your discussions with where you stand on budget and schedule. Most of these communication issues can be laid out in the project charter with the client. How do they like to be communicated with? How often? Written, by phone, or both? The more sophisticated the client is, the more processes they will have and ask or require you to adhere to.

It is not uncommon for different departments of a client to have different ideas on the project. Sometimes early on, an engineer can be hired by an environmental group, and when the project transitions to detailed engineering, it moves to an engineering department. In industry, there can be differences in how a corporate group sees an issue versus the plant. In most industries, I have found the plant manager has the final say and can trump corporate. The point is you need to know these things. One thing to know: It is very difficult to take on trying to align an organization that is not aligned. Your scope needs to be clear in terms of who gives you guidance and making sure they get internal alignment and buy-in.

If a client has been working with other engineers and suddenly chooses your firm instead, don’t hesitate to ask them why they changed and what they liked and did not like in working with the other engineer. Most of all, clients need the engineer to perform and deliver. It is hard to have a strong relationship if you don’t do that.

Join us tomorrow for the next installment of “Lessons Learned in My 40-year Engineering Career”!