By: Lars Hofman
When a shipyard brings in external engineering capacity, the focus is usually on progress. Work needs to be completed, internal capacity is limited, or a project needs more support than the team can currently provide. For many project phases, that works perfectly well.
But not every engineering scope is the same. Some work packages are clearly defined. The discipline boundaries are clear, dependencies are limited, and the impact on other parts of the project is easy to manage. Other scopes behave differently. In those cases, the challenge is not the number of engineering hours, but the number of disciplines affected by the same technical decisions.
And that is often where the difference between providing capacity and delivering multidisciplinary engineering becomes clear.
Not the size of a scope determines the risk
I still see many teams assess a scope based on hours, planning, or the amount of drawing work involved. That makes sense, because capacity needs to be planned and progress needs to be measured. However, the size of a scope does not always tell the full story about its impact on the project.
A relatively small package can create significant pressure when it affects multiple disciplines. Think of a change that impacts routing, structure, maintenance access, and supplier information at the same time. On the other hand, a larger package can remain manageable when the interfaces are clear and the discipline boundaries remain stable.
One practical question often provides more insight than a long analysis:
If this scope changes tomorrow, how many disciplines will be affected by it?
If the answer is one discipline, the scope is usually quite easy to define and manage. But if the answer is three or four, the challenge is probably not just capacity. It is about alignment and interaction between disciplines.
At HOFF, we always work with a multidisciplinary view, whether the scope is small or large, because that is where we can make a real difference for the shipyard.
A lot of revision work starts when dependencies become visible too late
When a scope requires more and more coordination during a project, people often assume there is a capacity problem. In reality, it is often an interface problem. The number of dependencies simply increases.
Supplier information becomes final. Spaces become more crowded. Routing, structure, outfit, and mechanical engineering move closer together. Decisions that made perfect sense within one discipline start affecting other parts of the vessel.
This is the point where revisions begin to move through the project. A routing change requires a structural review. A foundation update affects available space. A supplier component needs more maintenance access than originally expected.
Most of this rework happens because dependencies only become visible after other disciplines have already moved forward.
A scope becomes more stable when interfaces are clear before the detailed solution
Projects often create pressure to move quickly towards solutions. That is understandable, especially when schedules and production requirements are driving the engineering phase.
However, it often delivers more value to first understand where disciplines interact.
Which space must remain available? Which routing spaces should not move later? Which supplier information is still uncertain? Which decisions directly affect structure, outfit, or maintenance access?
The detailed solution does not always need to be fully defined straight away. But the interfaces between disciplines should be understood early.
When those interfaces are clear, disciplines can continue working more independently. There is less reinterpretation, less rework between disciplines, and less risk that a later detail will force earlier decisions to be changed.
A large part of the value of Basic Engineering comes from exactly that.
Not every external partner looks at a scope in the same way
Many external engineering partners are hired for a clearly defined discipline. There is nothing wrong with that.
However, some projects are challenging because of the interfaces between disciplines.
In those situations, it helps when engineers consider how their decisions affect other parts of the project while they are working on their own scope. Not because they are responsible for every discipline, but because they understand the consequences certain decisions may have later in the project.
That does not prevent every change.
But it does help create solutions that fit better within the vessel as a whole.
Why shipyards often involve HOFF in these types of scopes
HOFF is usually not brought in because a shipyard has no engineering capacity. More often, the need arises when a scope affects multiple disciplines and the impact of decisions extends beyond the boundaries of a single work package.
The foundation remains engineering. In some cases, we also support more from a project management perspective.
We route, model, develop, and detail engineering solutions. The difference is that we do this with continuous attention to the impact on structure, piping, mechanical engineering, outfit, and the next phases of the project.
That requires engineers who are used to looking beyond the boundaries of their own discipline while carrying out the work.
For our clients, that is valuable. Not because the knowledge is missing internally, but because the same engineers are often responsible for many different aspects of the project at the same time.
In those situations, it helps when an external partner provides more than capacity alone and delivers engineering that connects smoothly with the rest of the vessel.
You often recognize a good scope only afterwards
I often say that the best engineering scopes are the ones nobody talks about during the project.
Not because there were no challenges, but because other disciplines can continue their work without major interventions. We work within the shipyard’s standards, systems, and way of working. There is less noise in the project.
Routing remains stable. Maintenance access is preserved. Supplier information fits the existing design basis. Detail Engineering does not need to revisit earlier decisions again and again.
That makes both the project and the project team more stable. And that is often where the real value of multidisciplinary engineering can be found.
For more information, contact Lars Hofman via:
(+31) 085 06 04 633
Or through LinkedIn
HOFF • Partners in Engineering
Stationspark 950
3364 DA Sliedrecht
The Netherlands




More articles