The technical work was completed. The calculations were correct. The deliverable matched the agreed specification. Then the client said:

“That’s not what we expected.”

Few sentences create more frustration in an engineering project.

The engineer thinks: But this is what we agreed.

The client thinks: Surely it was obvious what we needed.

Both may be acting reasonably. Both may even have approved the same proposal or meeting notes. Yet they started the work with different pictures of the result.

That is the problem with client communication for engineers: agreement on words does not always mean agreement on meaning. Terms such as complete, optimised, ready for installation, practical or as soon as possible sound clear until people have to make decisions based on them. The engineer hears a technical requirement. The client may hear a business outcome, an operational solution or a promise about timing. If that difference stays hidden, it will surface later as rework, scope discussion, delay or disappointment.

The best time to solve it is before engineering starts.

“The client agreed” is not enough.

An agreement can still contain assumptions. Imagine a client asks for a concept design that is “ready for internal approval”. The engineering team delivers a technically sound concept with key calculations and open points clearly listed.

The client expected a polished decision package they could present to senior management, including cost implications, planning consequences and a recommendation.

Was the engineering work wrong? Not necessarily.

Was the client expectation unreasonable? Perhaps not.

The two sides simply used the same phrase for different deliverables.

This happens because clients and engineers view the project through different lenses.

The engineer focuses on questions such as:

• What technical problem must we solve?

• Which requirements and standards apply?

• What information is still missing?

• What level of analysis is justified?

The client may be thinking:

• What decision can I make with this?

• What do I need to tell my customer or management?

• Will this protect the schedule?

• Can operations use it?

• Who takes responsibility if something changes?

Neither perspective is better. A strong project needs both.

Good engineering project communication connects them before assumptions turn into project problems.

Where client expectations usually diverge

Misunderstandings are rarely limited to one badly worded requirement. Expectations tend to diverge in six areas:

1. The result: What does the client need at the end?

A calculation, drawing or report may be the formal deliverable. But what must the client be able to do with it? Select a concept? Obtain approval? Purchase equipment? Start fabrication? Convince another stakeholder?

The required technical output depends on the decision or action it must support.

2. The scope: What is included, and just as importantly, what is not?

Clients often describe the desired outcome without seeing every activity required to produce it. Engineers may define scope through tasks and deliverables but leave interfaces implicit. That gap creates familiar questions later: “Isn’t that normally part of the design?”

If an exclusion matters, putting it in a proposal is not always enough. Discuss it.

3. The priority: Every project wants quality, speed and cost control. But when they conflict, which one wins?

An engineer may spend additional time improving accuracy because quality appears to be the priority. The client may prefer an earlier, lower-confidence answer to keep another workstream moving.

Without an explicit trade-off, both sides make their own sensible decision. They may not make the same one.

4. The quality level: Words such as detailed, robust and fit for purpose need context.

Is this a first screening, a concept selection, a tender package or a final design? Which tolerances, review steps and verification requirements apply? What remains provisional?

The technically best answer is not automatically the most useful answer for the current project phase.

5. The timing: “We need it by Friday” can mean several things.

Does the client need a final checked deliverable? A preliminary conclusion? One critical value? Or enough information to update management?

Clarifying the purpose behind the deadline often creates more options than debating whether the full task is possible.

6. Responsibilities: Who supplies input?

Who reviews? Who decides? Who coordinates the interfaces? And what happens when information arrives late or changes? Projects stall when responsibility is shared in theory but owned by nobody in practice.

Why engineers move to the solution too quickly

Engineers are trained to solve problems. Give them a technical question and their mind starts modelling loads, constraints, interfaces and possible solutions.

That is a strength. It can also make the first client conversation too solution-focused.

A proposed method or concept creates something concrete to discuss. It feels productive. Asking more questions can feel slow, obvious or even slightly uncomfortable. There are other pressures too:

• The client wants a quick answer.

• The proposal has already been signed.

• The engineer does not want to appear difficult.

• Commercial agreements are seen as the project manager’s responsibility.

• Everyone assumes someone else has clarified the context.

So the team starts.

Later, new information appears. The client’s real priority becomes clearer. An interface was not included. The expected level of detail turns out to be different.

This is often labelled a communication problem. More precisely, it is a failure to test assumptions before committing technical effort.

The answer is not a longer kick-off meeting. It is a better one.

Six questions to clarify client requirements

You do not need a thirty-question checklist. You need a small set of questions that expose the assumptions with the biggest project consequences.

1. What must this work enable you to decide or do?

This connects the technical deliverable to its purpose. Instead of only confirming that the client wants a report, find out what happens after the report is delivered.

“To make sure we provide the right level of detail: what decision will you make based on this analysis?”

The answer may change the structure, timing and depth of your work.

2. What would a useful result look like to you?

Do not ask only whether the scope is clear. Ask the client to describe the result in practical terms.

“When you receive the deliverable, what information must be immediately clear for it to be useful?”

This reveals expectations that may never appear in a technical specification.

3. Which constraint or priority should guide our trade-offs?

Technical work always contains trade-offs. Surface them early.

“If we have to choose between additional accuracy and an earlier answer, which matters most at this stage?”

You are not lowering quality. You are aligning the engineering approach with the project need.

4. What is explicitly outside this assignment?

This question is valuable even when the proposal contains exclusions.

“We understand that the structural verification is included, while the installation method and temporary works are not. Is that also how you see the boundary?”

State the boundary in relation to real activities. Legal wording alone rarely creates operational clarity.

5. What inputs, decisions or people do we depend on?

Technical planning often assumes that information will be available when needed. Make those dependencies visible.

“Which client inputs do we need before we can complete the analysis, who owns them and when can we expect them?”

This prevents a missing input from quietly becoming your delay.

6. What could make you say, “This is not what we expected”?

It is a direct question. That is why it works.

“Before we start, what would make this deliverable unsuccessful from your perspective, even if it is technically correct?”

The response can reveal internal stakeholders, formatting needs, unspoken sensitivities or previous bad experiences.

Not every client will have an immediate answer. The question still prompts useful thinking.