The client asks for your recommendation.

You investigate four possible concepts. Then a fifth appears during the analysis. Each option has different implications for cost, weight, installation, maintenance and technical risk.

So you keep engineering.

You add another calculation. Check another assumption. Improve the comparison table. Perhaps one more analysis will reveal which option is objectively best.

But the client is still waiting.

Not because you have done too little technical work. Because no one has turned that work into a decision they can make.

This is a common tension in engineering projects. Engineers are trained to investigate, verify and avoid unsupported conclusions.

That care protects quality.

But a client rarely needs every technically possible answer.

They need to understand:

• which criteria matter;

• how the realistic options differ;

• what you recommend;

• what remains uncertain;

• and which decision is required now.

More analysis is useful only while it materially improves that decision.

After that point, another option does not create more clarity. It creates more choice.

And more choice can make the decision harder.

The technically best option does not exist in isolation

Engineers naturally look for the best technical solution. But real project decisions are rarely based on technical performance alone. The strongest concept may:

• exceed the available budget;

• require a longer lead time;

• create additional installation risk;

• depend on data the client cannot provide;

• be difficult to maintain offshore;

• conflict with an existing interface;

• or solve a problem the client does not value enough to pay for.

That does not make technical quality less important. It means quality is one decision criterion among several.

The right recommendation is therefore not necessarily the option with the highest technical performance.

It is the option that best fits the agreed purpose, constraints and acceptable risks.

That is a business skill. And it belongs inside engineering work, not somewhere beside it.

Why engineers keep developing options

Continuing the analysis can feel safer than making a recommendation. There are understandable reasons for that.

1. The decision criteria were never agreed

The client asked for “the best solution”, but no one established what best means.

Lowest CAPEX? Shortest installation window? Lowest lifetime cost? Minimum technical risk? Maximum performance? Easy maintenance?

Without prioritised criteria, every option can be defended and challenged. The engineer is left trying to optimise several conflicting variables at once.

2. Uncertainty feels like incomplete engineering

Engineers often want enough evidence to close every technical question before recommending an option.

That is appropriate when the remaining uncertainty could change the safety case or make the chosen solution unworkable.

It is less useful when the missing information would only refine a number without changing the preferred direction.

You do not always need zero uncertainty. You need enough certainty for the decision in front of you.

3. Presenting options feels more neutral

“Here are the alternatives” sounds objective.

“This is what I recommend” feels more exposed. Someone may disagree. New information may emerge. The selected option may later encounter a problem.

But neutrality has a cost. If you understand the technical consequences better than anyone else in the room, withholding your professional judgement does not make the decision more objective. It simply transfers the interpretation work to people with less technical context.

4. The engineer does not know what they are authorised to decide

Sometimes the problem is not communication. It is governance.

Can the lead engineer reject an option? Can they recommend additional scope? Who accepts residual risk? Who approves a change in budget or planning?

If that decision space is unclear, engineers often respond by doing more analysis. Work continues while ownership remains unresolved.

5. No one has defined when the analysis is complete

Technical work expands easily when the stopping condition is vague.

“Investigate the options” is not a useful stopping condition.

“Compare the three feasible concepts against the five agreed criteria and recommend one for client approval by Friday” is.

The difference looks small. Operationally, it is enormous.

Options do not create a decision by themselves

A technical options matrix can be excellent and still fail in the meeting. Imagine presenting five concepts with scores for structural performance, fabrication, cost, installation and maintainability. You explain the engineering behind every score. The discussion is technically sound. Then the client says:

“Thanks. We will discuss it internally.”

No decision. No owner. No date.

The meeting ends and the project team waits.

What was missing?

Usually one or more of these:

• the criteria had not been prioritised;

• the consequences were explained technically but not connected to the client's project;

• all options received equal airtime, including options that were no longer realistic;

• no clear recommendation was given;

• the remaining uncertainty was not framed;

• the exact decision and deadline were not stated.

The problem was not the quality of the engineering.

The decision architecture was missing.

A practical method: Criteria → Trade-offs

→ Recommendation → Decision

Use this structure when a client or internal stakeholder needs to choose between technical options. It does not replace the engineering analysis. It turns that analysis into something others can act on.

Step 1: Agree the criteria before optimising the solution

Start by clarifying what the decision must achieve.

Useful questions include:

• What must the solution do?

• Which requirements are non-negotiable?

• Which constraints can be traded?

• What would make an option unacceptable?

• Which matters more if two criteria conflict?

• Who will use, install, operate or maintain the solution?

• Who accepts the final technical and commercial risk?

Separate three kinds of criteria:

1. Must-haves

An option fails if it does not meet these. Think of regulatory requirements, safety limits, essential interfaces or minimum performance.

2. Decision drivers

These determine which feasible option is preferable. Examples include installation time, total cost, availability, maintainability or operational flexibility.

3. Preferences

These are valuable, but not at any cost. Treating preferences as fixed requirements is a reliable way to over-engineer a solution.

Then confirm the priority. For example:

“Before we develop the concepts further, I want to confirm how the decision will be made. All options must meet the load and interface requirements. Between the feasible options, installation time is the primary driver, followed by lifecycle cost. Is that correct?” That question can prevent days of analysing the wrong optimum.

Step 2: Explain the trade-offs, not every technical detail

A trade-off explains what the client gains, what they give up and why that matters.

Compare:

“Option B has a utilisation ratio of 0.71 instead of 0.63.”

with:

“Option B has less structural margin, but still meets the agreed design requirement. It reduces fabrication weight and can stay within the current installation method. Option A provides more margin, but requires heavier lifting equipment and adds cost.”

The first statement is technically precise.

The second makes the precision useful.

You are not dumbing down the engineering. You are connecting it to the decision. A strong trade-off statement contains four parts:

1. Technical difference — what changes?

2. Project consequence — what does that affect?

3. Relevant risk — what uncertainty or exposure remains?

4. Decision implication — when would one option be preferable?

For example:

“The alternative material reduces weight and shortens installation, but the supplier lead time is less certain. If protecting the offshore window is the priority, the standard material is the lower-risk choice. If weight is the limiting constraint, the alternative remains worth investigating.”

Now the client can see why the choice depends on their priorities.

Step 3: Give a recommendation

Do not hide the recommendation at the bottom of slide 34.

State it early and support it.

A useful recommendation sounds like this:

“Based on the agreed priority of completing installation within the current campaign, we recommend Option B. It meets the technical requirements, uses the available equipment and has the lowest schedule risk. Option A provides more performance margin, but that extra margin does not justify the additional fabrication and installation impact for the current operating conditions.” This gives the stakeholder:

• the recommended option;

• the basis for the recommendation;

• confirmation that it meets the technical requirement;

• the main trade-off;

• and the reason the alternative was not selected.

If uncertainty remains, name it precisely:

“This recommendation assumes the client confirms the interface loads by 12 September. If those loads increase beyond the stated range, we need to reassess the connection design.”

That is not weakening the recommendation. It is defining its validity.

Step 4: Ask for the exact decision

Do not end with “Any questions?” End with what must happen next.

For example:

“We need approval of Option B by Thursday at 12:00 to release the design for the planned review. Can you confirm who gives that approval?”

Or:

“There are two viable directions. Choosing lower installation risk means accepting the higher material cost. Is the project prepared to make that trade-off?”

Or:

“We cannot close the design until the allowable downtime is confirmed. Who owns that decision, and by when can we expect it?”

A decision request needs four elements:

• what must be decided;

• who owns the decision;

• when it is needed;

• what happens if it is delayed.

Without those elements, the next project delay is already quietly forming.