FEED in Engineering: What It Is, Stages, and Deliverables

Understand what FEED is in engineering, how it relates to FEL and Basic Design, which deliverables make up the package, and how it prepares investment decisions and EPC or EPCM contracting.

Check it out!

FEED (Front-End Engineering Design) is the engineering development stage that consolidates the selected solution and produces the technical basis required to estimate, approve, contract, and prepare the implementation of a project. It reduces the uncertainties that remain after feasibility and conceptual development, before the project advances to detailed engineering, procurement, or construction.

In a well-structured FEED, business requirements, field data, design criteria, key sizing calculations, interfaces, risks, costs, schedule, and contracting strategy are developed in a coordinated manner. The result is not merely a set of preliminary drawings, but a technical definition package for the project capable of supporting decisions and making proposals more comparable.

The role of FEED should be understood within the project life cycle and the FEL — Front-End Loading process. Terminology varies among companies and industries; therefore, the maturity level, required deliverables, and the decision the package must support are more important than the name assigned to the phase.

What is FEED in engineering?

FEED stands for Front-End Engineering Design. This stage transforms a conceptually selected alternative into a technically characterized solution, with requirements, criteria, documents, estimates, and interfaces developed sufficiently to guide the project’s progression.

FEED normally takes place before the Detailed Engineering Design and implementation phases. Depending on the methodology adopted, it may be part of the final Front-End Loading phase, be referred to as basic engineering, detailed scope definition, or design development. These expressions may overlap, but they are not equivalent across all industries.

FEED objectives

A FEED may have the following objectives:

• consolidate the selected technical solution;
• confirm requirements, capacities, and performance criteria;
• develop key architectures and sizing;
• identify interfaces among disciplines, systems, and contracts;
• increase the reliability of capital cost and schedule estimates;
• address technical, operational, regulatory, and implementation risks;
• define supply and execution packages;
• prepare documentation for an RFP, bidding process, or EPC/EPCM contracting;
• establish the basis for detailed engineering;
• provide evidence for a decision gate or final investment decision.

FEED is not merely a preliminary design

A set of conceptual drawings, by itself, does not constitute a complete FEED. The stage must integrate engineering, costs, planning, risks, requirements, contracting, and governance. The documentation should demonstrate not only which solution was selected, but also which assumptions support that choice, which interfaces need to be controlled, and which elements remain to be developed.

FEED also does not eliminate all uncertainty. Its role is to reduce uncertainty to a level compatible with the decision and the contracting model. Vendor data, permits, field investigations, or detailed development may remain pending, provided they are identified, classified, and assigned to responsible parties and treatment plans.

Maturity matters more than document quantity

A package may contain dozens of drawings and still remain weak when requirements are undefined, field data are insufficient, or interfaces lack assigned owners. Quality should be assessed by information maturity, multidisciplinary consistency, and the package’s ability to support the intended decision.

Where FEED fits in the project life cycle

FEED sits at the transition between conceptual definition and detailed engineering. It takes as inputs a structured need, a selected alternative, and sufficiently consistent assumptions to allow deeper technical development.

Previous studies and pre-FEED

Before FEED, a project may go through diagnostics, a site survey, due diligence, feasibility study, requirements gathering, alternatives analysis, and Conceptual Design. When the available data are still insufficient, a pre-FEED may be carried out to complete surveys, compare configurations, or confirm the selected alternative.

Pre-FEED should have a clear objective and exit criterion. It should not be used merely to move forward with a project whose definition remains insufficient.

Relationship between FEL and FEED

Front-End Loading is a broader maturation and governance process. It structures the progression from the initial opportunity through feasibility and alternative selection to the level of definition required to authorize implementation.

FEED may form part of the most advanced stage of this process. In some methodologies it is associated with FEL 3 or detailed scope definition; in others it appears as a stand-alone phase after conceptual development. The Construction Industry Institute places front-end planning between feasibility, concept development, and detailed scope definition, while recognizing that terminology varies among organizations.

Accordingly, it is not correct to state that every FEED is automatically FEL 3. The correspondence depends on the gate system, maturity criteria, and deliverables adopted by the owner.

FEED, Conceptual Design, Basic Design, and Detailed Engineering

Stage	Main question	Expected outcome
Feasibility study	Should the project move forward?	Assessment of alternatives, risks, costs, and feasibility
Conceptual Design	Which solution will be adopted?	Concept, architecture, assumptions, and selected alternative
FEED	Is the solution sufficiently defined for approval and contracting?	Design basis, sizing, documents, estimates, and implementation strategy
Basic Design	Is the scope sufficiently characterized for estimating and contracting?	Scope, criteria, quantities, specifications, and an estimate compatible with contracting
Detailed Engineering	How will the solution actually be implemented?	Detailing, coordination, assembly, installation, and execution documentation

FEED and Basic Engineering Design may overlap significantly, especially when both are intended to prepare the contracting of implementation. However, they should not automatically be treated as synonyms. Projeto Básico has a specific legal and technical meaning in the Brazilian context; FEED derives from project development methodologies and should be defined by its maturity level and contractual deliverables.

The article on Basic Design vs. Detailed Engineering examines in greater depth the difference between defining the scope and detailing it for execution.

How FEED is developed

FEED is a multidisciplinary and iterative process. Decisions in one discipline affect capacity, implementation, costs, maintenance, safety, schedule, and the performance of others. The work should not be split into independent documents without central coordination.

Consolidating the design basis

The first activity is to verify whether the inputs are sufficient and consistent. The following may be consolidated:

• business objectives and owner requirements;
• program of requirements, URS, OPR, or equivalent document;
• survey data, topography, records, and existing installations;
• demand, capacity, and expansion studies;
• operational, maintenance, and continuity requirements;
• applicable standards, permits, and constraints;
• safety, quality, availability, and efficiency criteria;
• implementation, phasing, and transition assumptions;
• scope boundaries and interfaces with third parties.

Missing information should be converted into survey actions, complementary studies, controlled assumptions, or formally recorded risks. FEED should not proceed with critical gaps treated as if they were confirmed data.

Documents such as the OPR, URS, and Basis of Design help maintain the relationship between need, requirement, and technical response. The article on Basis of Design, OPR, and URS presents this traceability chain in critical infrastructure projects.

Technical development and comparison

Even after conceptual selection, configuration decisions may still require validation. Development may include calculations, simulations, capacity studies, and analyses of redundancy, availability, reliability, efficiency, constructability, maintenance, safety, integration, and life cycle.

Residual alternatives need to be compared using explicit criteria. The choice should not be limited to the lowest CAPEX. Operability, OPEX, risk, schedule, equipment availability, expansion, standardization, internal capabilities, and impacts on existing systems may also change the decision.

Multidisciplinary coordination and interfaces

Coordination verifies whether the assumptions, documents, and boundaries of each discipline are compatible. In critical infrastructure, power, cooling, telecommunications, automation, security, fire protection, architecture, and operations need to be developed as parts of a single system.

Interface management should identify:

• inputs and outputs among disciplines;
• scope boundaries;
• responsibilities for data, designs, and approvals;
• dependencies among packages;
• integration and interoperability requirements;
• physical and operational clashes;
• test points and acceptance criteria;
• interfaces with utilities, authorities, and existing assets.

When a project involves multiple packages or suppliers, Engineering Consulting for Capital Projects can integrate requirements, disciplines, decisions, and progression criteria within the same governance framework.

Costs, schedule, and implementation strategy

Technical development feeds the cost estimate, schedule, and contracting strategy. Quantities, major equipment, productivity, logistics, phasing, intervention windows, long-lead items, and field constraints should be reflected in these analyses.

The high-level schedule should not show construction alone. It also needs to consider complementary engineering, approvals, permitting, manufacturing, expediting, FAT, mobilization, implementation, commissioning, training, and operational transition. The Project Controls service makes it possible to relate scope, schedule, costs, risks, and changes throughout this evolution.

Review and decision gate

At the end, the package should undergo technical, multidisciplinary, and executive review. The decision to proceed considers maturity, residual risks, estimates, contracting strategy, and execution capability. Open items may remain, but they need an owner, due date, impact assessment, and defined treatment.

The stage-gate process in engineering projects helps distinguish document issuance from effective authorization to commit capital or begin execution.

Main FEED deliverables

There is no single list applicable to every project. Deliverables should be defined according to the asset, the intended decision, and the subsequent contracting strategy. A typical package includes the following groups.

Design basis, requirements, and governance

• Basis of Design or design criteria;
• owner requirements and functional requirements;
• assumptions, constraints, and exclusions;
• requirements and traceability matrix;
• responsibility matrix;
• technical decision log;
• risk register and response plan;
• interface list and coordination points;
• development plan for the remaining engineering work.

Engineering studies and documents

• survey and existing-condition characterization reports;
• study of the selected alternative;
• design narratives and key calculation reports;
• block diagrams, flow diagrams, and system architectures;
• general layouts, site plans, and preliminary arrangements;
• single-line, logical, functional, or interconnection diagrams;
• sizing of systems and major equipment;
• operating, control, redundancy, and maintenance philosophy;
• preliminary equipment, point, and material lists;
• integration, automation, and telecommunications requirements;
• constructability, phasing, and intervention studies for existing assets.

In process industries, the package may include PFDs, P&IDs, balances, datasheets, and line lists. In Data Centers and technology infrastructure, it may include the OPR, Basis of Design, redundancy architectures, electrical diagrams, layouts, routes, point matrices, integrations, and commissioning strategy.

Contracting and procurement documentation

• contracting strategy and package breakdown;
• technical scopes and supply boundaries;
• specifications for equipment, materials, and services;
• technical requisitions and datasheets;
• RFI, RFP, or Terms of Reference;
• qualification and technical bid leveling criteria;
• supplier requirements;
• inspection, expediting, and FAT requirements;
• contractual responsibility matrix;
• measurement, testing, acceptance, and performance guarantee criteria.

Technical Procurement uses this basis to qualify suppliers, level proposals, review submittals, and control technical compliance.

Estimates, planning, and controls

• quantities and major equipment;
• CAPEX estimate and, when applicable, OPEX;
• basis of estimate, contingencies, and assumptions;
• master schedule and major milestones;
• identification of long-lead items;
• implementation, phasing, and mobilization plan;
• preliminary expenditure curve or cash flow;
• cost and schedule risk analysis;
• technical baseline for the next stage.

Commissioning and operational readiness

FEED should anticipate how performance will be demonstrated. The following may be defined:

• commissioning philosophy and strategy;
• test levels and sequence;
• responsibilities for pre-commissioning and commissioning;
• FAT, SAT, and integrated testing requirements;
• performance and acceptance criteria;
• training, manuals, and spare-parts requirements;
• as-built documentation and turnover dossier;
• conditions for handover to operations.

Defining these elements only at the end of construction increases the risk of incomplete testing, unclear responsibilities, and acceptance without sufficient evidence.

Maturity, estimates, and contracting

FEED quality should be assessed by the maturity and accuracy of the information, not by the volume of documents. The contracting decision needs to consider which gaps remain and how they will be allocated among the owner, designer, suppliers, and contractor.

Assessing scope definition

Tools such as the Project Definition Rating Index — PDRI help assess the completeness of project definition before detailed design and construction. The objective is not merely to obtain a score, but to identify weak elements, record mitigation actions, and verify whether maturity is compatible with the next gate.

The PDRI type should correspond to the project. Industrial facilities, buildings, and infrastructure have different definition elements.

Cost estimate class

FEED generally allows more mature estimates than those prepared during feasibility or conceptual development. However, the estimate class should not be assigned solely because the work has been labeled FEED.

AACE International Recommended Practice 18R-97 relates estimate classification to the maturity of the definition documents and the purpose of the estimate. Exact application depends on the industry and the practice adopted; an incomplete FEED does not automatically produce a reliable estimate.

The basis of estimate should document quantities, prices, productivity, base date, exchange rates, taxes, contingencies, exclusions, risks, and the expected accuracy range. The article on project cost management examines in greater depth the relationship among estimating, budgeting, baseline, and control.

FEED as a basis for EPC and EPCM

Under an EPC contract, the contractor assumes integrated engineering, procurement, and construction responsibilities within defined boundaries. The less mature the reference engineering, the greater the likely exposure to price contingencies, exclusions, scope interpretations, changes, and disputes.

The U.S. Department of Energy states in its FEED frequently asked questions that the study can demonstrate readiness and provide critical inputs for EPC contracts. This does not make FEED a universal requirement, but it illustrates its function as a basis for technical and contractual assessment.

Before contracting EPC, the owner should verify whether the package can:

• characterize the scope and supply boundaries;
• quantify the main systems and capacities;
• establish performance requirements;
• identify interfaces and existing conditions;
• define responsibilities for permits, data, and approvals;
• compare proposals on a common technical basis;
• establish guarantees, testing, and acceptance criteria;
• record the risks retained by the owner and those transferred.

Under EPCM, the owner retains direct supply and construction contracts, while the EPCM company coordinates engineering, procurement, and implementation. FEED remains relevant for defining packages, interfaces, estimates, and execution strategy.

Owner’s Engineering can review the FEED, verify proposal compliance, and oversee subsequent engineering development on behalf of the owner.

Brownfield projects and modernization

In expansions and modernization projects, survey quality is as important as the design of the new solution. Outdated documentation, concealed installations, access restrictions, operating windows, interfaces with live systems, and temporary conditions can significantly affect cost and schedule.

Brownfield FEED should give particular attention to records, field investigation, transition strategy, contingency, sequencing, operational safety, and recommissioning criteria.

When to commission a FEED

FEED is appropriate when a project already has a selected alternative but still requires technical development before final approval, bidding, EPC/EPCM contracting, or the start of detailed engineering.

Typical situations include:

• implementation of a new asset or facility;
• capacity expansion;
• modernization of operating infrastructure;
• preparation for EPC or turnkey contracting;
• division of the project into multiple packages;
• need to improve cost and schedule accuracy;
• consolidation of multidisciplinary interfaces;
• preparation for financing or an investment decision;
• independent review of a solution developed by third parties;
• projects with significant technical or operational risks.

How to define the contracting scope

The FEED Terms of Reference should establish:

• the objective and the decision the work must support;
• documents and data provided by the contracting party;
• field activities and complementary studies;
• included disciplines and systems;
• required level of development;
• deliverables list and minimum content;
• review, approval, and maturity criteria;
• third-party interfaces and responsibilities;
• cost, schedule, and risk methodology;
• contracting, commissioning, and acceptance requirements;
• file formats, revisions, and technical records;
• exclusions and activities reserved for the detailed engineering stage.

Errors that reduce FEED value

The most frequent problems are:

• starting the stage without a selected alternative;
• working with insufficient surveys;
• limiting the scope to drawings;
• failing to coordinate disciplines;
• omitting contractual interfaces;
• using quantities without a traceable basis;
• defining costs without documenting assumptions;
• postponing testing criteria until after contracting;
• requiring a generic percentage of completion without defining deliverables and decisions;
• closing the package without recording open items and residual risks.

Completion criterion

A FEED is complete when it enables the intended decision to be made with known risks and documentation compatible with the next stage. This may mean authorizing investment, issuing an RFP, contracting EPCM, starting procurement of critical items, or advancing to Detailed Engineering.

The central question is not “how many drawings were issued?” but rather: is the project sufficiently defined for costs, schedules, responsibilities, and performance commitments to be assumed consciously and verifiably?

Conclusion

FEED connects the selected alternative to the investment decision and implementation contracting. Its value lies in integrating requirements, design criteria, sizing, interfaces, costs, schedule, risks, procurement, commissioning, and responsibilities into a coherent technical basis.

FEED is not automatically synonymous with FEL 3, Basic Design, or basic engineering. Terminology varies; quality depends on the actual maturity of the information and on the package’s ability to support the next gate.

When properly defined, FEED reduces ambiguity, improves proposal comparability, anticipates implementation risks, and establishes more objective conditions for developing, executing, testing, and accepting the project. When treated merely as a set of drawings, it transfers uncertainty to stages where changes are more expensive and disputes more likely.

Technical references

[1] CONSTRUCTION INDUSTRY INSTITUTE. Project Definition Rating Index (PDRI) Overview. Austin: CII.

[2] CONSTRUCTION INDUSTRY INSTITUTE. PDRI: Project Definition Rating Index — Industrial Projects, Version 5.0. Austin: CII, 2019.

[3] UNITED STATES DEPARTMENT OF ENERGY. Title 17 Frequently Asked Questions — Front-End Engineering and Design studies.

[4] AACE INTERNATIONAL. Recommended Practice 18R-97: Cost Estimate Classification System — As Applied in Engineering, Procurement, and Construction for the Process Industries.

[5] A3A CONSULTING. FEL (Front-End Loading): project maturation, feasibility, and definition.

[6] A3A CONSULTING. Basic Engineering Design: scope, criteria, sizing, and estimating.

Frequently asked questions

What does FEED mean in engineering?

FEED stands for Front-End Engineering Design. It is the stage that develops and consolidates the selected solution before detailed engineering and implementation, producing design bases, sizing, estimates, risks, and requirements for decision-making and contracting.

Is FEED the same as Basic Design?

Not necessarily. The two may overlap significantly when preparing contracting, but they belong to different frameworks. Projeto Básico has a specific meaning in the Brazilian context, while FEED is defined by the maturation process and the contracted deliverables.

Does FEED correspond to FEL 3?

In many methodologies, FEED is part of the most advanced Front-End Loading phase and may be associated with FEL 3. However, the equivalence is not universal and should be confirmed by the phase system, gates, and maturity criteria adopted by the owner.

What are the main FEED deliverables?

They may include a Basis of Design, requirements, risk and interface matrices, design narratives, calculations, diagrams, layouts, specifications, equipment lists, quantities, CAPEX, schedule, contracting strategy, and testing and acceptance criteria.

Is FEED required before EPC contracting?

There is no single rule, but a mature FEED reduces uncertainty and provides a reference for defining scope, responsibilities, performance, interfaces, and acceptance criteria. Contracting EPC with insufficient definition increases contingencies, exclusions, changes, and disputes.

Who should participate in FEED development?

The team depends on the project, but normally includes multidisciplinary engineering, operations, maintenance, safety, environmental, cost, planning, procurement, contracts, and owner representatives.

Additional technical materials

Planning and maturation

• FEL (Front-End Loading)
• Project Life Cycle
• Stage-gate in engineering projects

Engineering development

• Basic Engineering Design
• Detailed Engineering Design
• Basic Design vs. Detailed Engineering
• Basis of Design, OPR, and URS

Contracting and implementation

• Technical Procurement
• EPC
• EPCM
• Owner’s Engineering
• Project cost management

A3A Consulting solutions

• Engineering Consulting for Capital Projects
• Project Controls