The FEED-to-EPCI Handoff: Where Offshore Projects Really Win or Lose Schedule
The success of offshore projects is often determined not by the quality of FEED itself, but by how effectively FEED assumptions, interfaces and constructability requirements are transferred into EPCI execution.
Every offshore project team has lived through some version of this story: FEED closes out on time, the model looks clean, the deliverables are stamped and issued — and then six months into EPCI execution, the schedule is bleeding weeks on interfaces nobody thought to flag. The root cause is rarely a single bad decision. It is almost always the handoff itself.
The Illusion of Completeness:
FEED is designed to de-risk a project before sanction, and on paper it does exactly that. But “complete” FEED documentation and “execution-ready” FEED documentation are not the same thing. A pipeline routing study, a subsea layout, or a topsides weight control report can satisfy every FEED gate review and still leave critical interface assumptions implicit rather than explicit — tie-in tolerances, vendor data dependencies, marine spread compatibility, installation sequencing logic. These gaps do not show up as open items in a register. They show up as RFIs eighteen months later, once steel is being cut.
Why Interfaces Get Buried:
In experience across subsea, FPSO, and LNG marine scopes, the pattern is consistent: FEED teams optimize for technical defensibility, while EPCI teams optimize for constructability and installability. Those are not the same lens. A riser configuration that is technically sound in FEED can become a fabrication or installation headache once a contractor's actual vessel spread, yard capacity, or fabrication sequencing enters the picture. If the FEED contract does not force early dialogue with likely execution constraints — even at a conceptual level — those mismatches stay invisible until EPCI mobilizes. The second driver is organizational. FEED and EPCI are frequently different contractors, sometimes on different continents, often with different internal cultures around documentation granularity. Basis-of-design assumptions that are “obvious” to the FEED engineer are not transferred with the same confidence to the EPCI team inheriting the package. Nothing malicious — just an information half-life that decays across the handoff.
What Actually Closes the Gap:
A few practices consistently separate projects that transition smoothly from those that do not: • Joint interface workshops before FEED close-out, with EPCI-side or construction-side reviewers present even if the EPCI contractor is not formally selected yet. • A living interface register, not a static FEED deliverable — carried forward with named owners into EPCI kickoff, not re-created from scratch. • Constructability reviews embedded in FEED, not bolted on afterward. Even a lightweight fabrication/installation sanity check on major structures pays for itself many times over. • Explicit basis-of-design assumptions documentation — writing down not just the answer, but why, and under what conditions it changes.
The Program Management Lens:
This is ultimately a program delivery problem, not a pure engineering one. Technical teams can produce excellent FEED work and still hand over a fragile package if the transition itself is not actively managed as a deliverable in its own right. The organizations that consistently avoid schedule erosion at this stage treat the FEED-to-EPCI handoff as a controlled gate with its own success criteria — not an administrative formality between two contracts. For owners and operators running multiple concurrent offshore developments, this is often the single highest-leverage point to intervene early: not by adding more FEED scope, but by making sure what is in the transferred package are the questions execution teams will actually need answered.