Entenda o que é FEED em engenharia, como se relaciona com FEL e Projeto Básico, quais entregáveis compõem o pacote e como ele prepara decisões de investimento e contratações EPC ou EPCM.

Confira!

O FEED (Front-End Engineering Design) é a etapa de desenvolvimento da engenharia que consolida a solução selecionada e produz a base técnica necessária para estimar, aprovar, contratar e preparar a implantação de um empreendimento. Ele reduz as incertezas que permanecem após a viabilidade e o conceito, antes que o projeto avance para detalhamento executivo, suprimentos ou construção.

Em um FEED bem estruturado, requisitos de negócio, dados de campo, critérios de projeto, dimensionamentos principais, interfaces, riscos, custos, cronograma e estratégia de contratação são desenvolvidos de forma coordenada. O resultado não é apenas um conjunto de desenhos preliminares, mas um pacote de definição técnica do empreendimento capaz de sustentar decisões e tornar propostas mais comparáveis.

A posição do FEED deve ser compreendida dentro do ciclo de vida do projeto e do processo de FEL — Front-End Loading. A nomenclatura varia entre empresas e setores; por isso, o nível de maturidade, os produtos exigidos e a decisão que o pacote deve suportar são mais importantes do que o nome atribuído à fase.

O que é FEED em engenharia

FEED significa Front-End Engineering Design. A etapa transforma uma alternativa conceitualmente selecionada em uma solução tecnicamente caracterizada, com requisitos, critérios, documentos, estimativas e interfaces suficientemente desenvolvidos para orientar o avanço do empreendimento.

O FEED normalmente ocorre antes do Projeto Executivo de Engenharia e da implantação. Dependendo da metodologia adotada, pode integrar a fase final do Front-End Loading, ser denominado engenharia básica, detailed scope definition ou design development. Essas expressões podem se sobrepor, mas não são equivalentes em todos os setores.

Objetivos do FEED

Um FEED pode ter como objetivos:

  • consolidar a solução técnica selecionada;
  • confirmar requisitos, capacidades e critérios de desempenho;
  • desenvolver arquiteturas e dimensionamentos principais;
  • identificar interfaces entre disciplinas, sistemas e contratos;
  • aumentar a confiabilidade das estimativas de investimento e prazo;
  • tratar riscos técnicos, operacionais, regulatórios e de implantação;
  • definir pacotes de fornecimento e execução;
  • preparar documentação para RFP, licitação ou contratação EPC/EPCM;
  • estabelecer bases para a engenharia executiva;
  • fornecer evidências para um portão de decisão ou decisão final de investimento.

O FEED não é apenas um projeto preliminar

Um conjunto de plantas conceituais, isoladamente, não caracteriza um FEED completo. A etapa precisa integrar engenharia, custos, planejamento, riscos, requisitos, contratação e governança. A documentação deve demonstrar não apenas qual solução foi escolhida, mas também quais premissas sustentam essa escolha, quais interfaces precisam ser controladas e quais elementos ainda serão desenvolvidos.

O FEED também não elimina todas as incertezas. Seu papel é reduzi-las a um nível compatível com a decisão e com o modelo de contratação. Dados de fornecedores, licenças, investigações de campo ou detalhamentos podem permanecer pendentes, desde que estejam identificados, classificados e associados a responsáveis e planos de tratamento.

Maturidade é mais importante que quantidade de documentos

Um pacote pode conter dezenas de desenhos e continuar frágil quando requisitos estão indefinidos, dados de campo são insuficientes ou interfaces não possuem responsáveis. A qualidade deve ser avaliada pela maturidade das informações, pela coerência multidisciplinar e pela capacidade do pacote de sustentar a decisão prevista.

Onde o FEED se encaixa no ciclo do empreendimento

O FEED ocupa a transição entre a definição conceitual e a engenharia detalhada. Ele recebe como entrada uma necessidade estruturada, uma alternativa selecionada e premissas suficientemente consistentes para permitir o aprofundamento técnico.

Estudos anteriores e pré-FEED

Antes do FEED, o empreendimento pode passar por diagnóstico, site survey, due diligence, estudo de viabilidade, levantamento de requisitos, análise de alternativas e Projeto Conceitual. Quando os dados ainda não são suficientes, pode ser executado um pré-FEED para completar levantamentos, comparar configurações ou confirmar a alternativa escolhida.

O pré-FEED deve possuir objetivo e critério de saída claros. Ele não pode ser utilizado apenas para avançar um projeto cuja definição continua insuficiente.

Relação entre FEL e FEED

O Front-End Loading é um processo mais amplo de maturação e governança. Ele organiza a evolução desde a oportunidade inicial, passando pela viabilidade e pela seleção da alternativa, até a definição necessária para autorizar a implantação.

O FEED pode integrar a etapa mais avançada desse processo. Em algumas metodologias é associado ao FEL 3 ou à detailed scope definition; em outras aparece como fase autônoma após o conceito. O Construction Industry Institute posiciona o front-end planning entre viabilidade, conceito e definição detalhada do escopo, mas reconhece que a terminologia varia entre organizações.

Assim, não é correto afirmar que todo FEED é automaticamente FEL 3. A correspondência depende do sistema de gates, dos critérios de maturidade e dos entregáveis adotados pelo proprietário.

FEED, Projeto Conceitual, Projeto Básico e Projeto Executivo

EtapaPergunta principalResultado esperado
Estudo de viabilidadeO empreendimento deve avançar?Avaliação de alternativas, riscos, custos e viabilidade
Projeto ConceitualQual solução será adotada?Concepção, arquitetura, premissas e alternativa selecionada
FEEDA solução está suficientemente definida para aprovação e contratação?Bases de projeto, dimensionamentos, documentos, estimativas e estratégia de implantação
Projeto BásicoO objeto está caracterizado para orçamento e contratação?Escopo, critérios, quantitativos, especificações e orçamento compatíveis com a contratação
Projeto ExecutivoComo a solução será efetivamente executada?Detalhamento, compatibilização, montagem, instalação e documentação para execução

FEED e Projeto Básico de Engenharia podem apresentar grande sobreposição, especialmente quando ambos preparam a contratação da implantação. Entretanto, não devem ser tratados como sinônimos automáticos. O Projeto Básico possui significado próprio no contexto brasileiro; o FEED deriva de metodologias de desenvolvimento de empreendimentos e deve ser definido pelo nível de maturidade e pelos produtos contratuais.

O artigo sobre Projeto Básico x Projeto Executivo aprofunda a diferença entre caracterização do objeto e detalhamento para execução.

Defina a maturidade antes de avançar para contratação

A lista de entregáveis, os critérios de revisão e o gate de conclusão precisam estar vinculados à decisão que o FEED deverá suportar.

Conheça o serviço de FEL — Front-End Loading

Como um FEED é desenvolvido

O FEED é um processo multidisciplinar e iterativo. Decisões de uma disciplina afetam capacidade, implantação, custos, manutenção, segurança, cronograma e desempenho das demais. O trabalho não deve ser dividido em documentos independentes sem coordenação central.

Consolidação das bases de projeto

A primeira atividade é verificar se as entradas são suficientes e coerentes. Podem ser consolidados:

  • objetivos do negócio e requisitos do proprietário;
  • programa de necessidades, URS, OPR ou documento equivalente;
  • dados de levantamento, topografia, cadastro e instalações existentes;
  • estudos de demanda, capacidade e expansão;
  • requisitos operacionais, de manutenção e continuidade;
  • normas, licenças e condicionantes aplicáveis;
  • critérios de segurança, qualidade, disponibilidade e eficiência;
  • premissas de implantação, faseamento e transição;
  • limites de fornecimento e interfaces com terceiros.

Informações ausentes devem se transformar em ações de levantamento, estudos complementares, premissas controladas ou riscos formalizados. O FEED não deve avançar com lacunas críticas tratadas como se fossem dados confirmados.

Documentos como OPR, URS e Basis of Design ajudam a manter a relação entre necessidade, requisito e resposta técnica. O artigo sobre Basis of Design, OPR e URS apresenta essa cadeia de rastreabilidade em projetos de infraestrutura crítica.

Desenvolvimento e comparação técnica

Mesmo após a seleção conceitual, decisões de configuração podem precisar de validação. O desenvolvimento pode incluir cálculos, simulações, estudos de capacidade, análise de redundância, disponibilidade, confiabilidade, eficiência, construtibilidade, manutenção, segurança, integração e ciclo de vida.

As alternativas residuais precisam ser comparadas com critérios explícitos. A escolha não deve se limitar ao menor CAPEX. Operabilidade, OPEX, risco, prazo, disponibilidade de equipamentos, expansão, padronização, competências internas e impacto sobre sistemas existentes também podem alterar a decisão.

Coordenação multidisciplinar e interfaces

A coordenação verifica se premissas, documentos e limites de cada disciplina são compatíveis. Em infraestrutura crítica, energia, climatização, telecomunicações, automação, segurança, incêndio, arquitetura e operação precisam ser desenvolvidos como partes de um único sistema.

A gestão de interfaces deve identificar:

  • entradas e saídas entre disciplinas;
  • limites de fornecimento;
  • responsabilidades por dados, projetos e aprovações;
  • dependências entre pacotes;
  • requisitos de integração e interoperabilidade;
  • interferências físicas e operacionais;
  • pontos de teste e critérios de aceite;
  • interfaces com concessionárias, órgãos e ativos existentes.

Quando o empreendimento envolve múltiplos pacotes ou fornecedores, a Engenharia Consultiva para Empreendimentos pode integrar requisitos, disciplinas, decisões e critérios de avanço em uma mesma estrutura de governança.

Custos, prazo e estratégia de implantação

O desenvolvimento técnico alimenta estimativa de custos, cronograma e estratégia de contratação. Quantitativos, equipamentos principais, produtividade, logística, faseamento, janelas de intervenção, itens de longo prazo e restrições de campo devem ser refletidos nessas análises.

O cronograma de alto nível não deve mostrar apenas construção. Também precisa considerar engenharia complementar, aprovações, licenciamento, fabricação, diligenciamento, FAT, mobilização, implantação, comissionamento, treinamento e transição operacional. O serviço de Project Controls permite relacionar escopo, prazo, custos, riscos e mudanças durante essa evolução.

Revisão e portão de decisão

Ao final, o pacote deve ser submetido a revisão técnica, multidisciplinar e executiva. A decisão de avançar considera maturidade, riscos residuais, estimativas, estratégia de contratação e capacidade de execução. Pendências podem permanecer, mas precisam possuir responsável, prazo, impacto e tratamento definido.

O processo de stage-gate em projetos de engenharia ajuda a separar emissão de documentos de autorização efetiva para comprometer capital ou iniciar a execução.

Integre requisitos, disciplinas, custos e decisões

O FEED precisa ser coordenado como um pacote único de definição, com interfaces, responsabilidades, pendências e critérios de avanço rastreáveis.

Conheça a Engenharia Consultiva para Empreendimentos

Principais entregáveis de um FEED

Não existe uma lista única aplicável a todos os empreendimentos. Os entregáveis devem ser definidos conforme o ativo, a decisão pretendida e a contratação subsequente. Um pacote típico reúne os grupos a seguir.

Bases, requisitos e governança

  • Basis of Design ou critérios de projeto;
  • requisitos do proprietário e requisitos funcionais;
  • premissas, restrições e exclusões;
  • matriz de requisitos e rastreabilidade;
  • matriz de responsabilidades;
  • registro de decisões técnicas;
  • matriz de riscos e plano de respostas;
  • lista de interfaces e pontos de coordenação;
  • plano de desenvolvimento da engenharia restante.

Estudos e documentos de engenharia

  • relatórios de levantamento e caracterização do existente;
  • estudo da alternativa selecionada;
  • memoriais descritivos e memórias de cálculo principais;
  • diagramas de blocos, fluxogramas e arquiteturas de sistemas;
  • layouts gerais, plantas de implantação e arranjos preliminares;
  • diagramas unifilares, lógicos, funcionais ou de interligação;
  • dimensionamento de sistemas e equipamentos principais;
  • filosofia de operação, controle, redundância e manutenção;
  • listas preliminares de equipamentos, pontos e materiais;
  • requisitos de integração, automação e telecomunicações;
  • estudos de construtibilidade, faseamento e intervenções em ativos existentes.

Em indústrias de processo, o pacote pode incluir PFD, P&ID, balanços, datasheets e listas de linhas. Em Data Centers e infraestrutura tecnológica, pode incluir OPR, Basis of Design, arquiteturas de redundância, diagramas elétricos, layouts, rotas, matrizes de pontos, integrações e estratégia de comissionamento.

Documentação para contratação e suprimentos

  • estratégia de contratação e divisão em pacotes;
  • escopos técnicos e limites de fornecimento;
  • especificações de equipamentos, materiais e serviços;
  • requisições técnicas e datasheets;
  • RFI, RFP ou Termos de Referência;
  • critérios de qualificação e equalização técnica;
  • requisitos para fornecedores;
  • requisitos de inspeção, diligenciamento e FAT;
  • matriz de responsabilidades contratuais;
  • critérios de medição, testes, aceite e garantias de desempenho.

O Procurement Técnico utiliza essa base para qualificar fornecedores, equalizar propostas, revisar submittals e controlar aderência técnica.

Estimativas, planejamento e controles

  • quantitativos e equipamentos principais;
  • estimativa de CAPEX e, quando aplicável, OPEX;
  • base da estimativa, contingências e premissas;
  • cronograma mestre e marcos principais;
  • identificação de itens de longo prazo;
  • plano de implantação, faseamento e mobilização;
  • curva de desembolso ou fluxo de caixa preliminar;
  • análise de riscos de custo e prazo;
  • baseline técnica para a etapa seguinte.

Comissionamento e prontidão operacional

O FEED deve antecipar como o desempenho será demonstrado. Podem ser definidos:

  • filosofia e estratégia de comissionamento;
  • níveis e sequência de testes;
  • responsabilidades por pré-comissionamento e comissionamento;
  • requisitos de FAT, SAT e testes integrados;
  • critérios de desempenho e aceite;
  • requisitos de treinamento, manuais e sobressalentes;
  • documentação as-built e dossiê de entrega;
  • condições para transferência à operação.

Definir esses elementos apenas ao final da obra aumenta o risco de testes incompletos, responsabilidades indefinidas e aceite sem evidências suficientes.

Transforme o FEED em documentação contratável

Escopos, especificações, limites de fornecimento, critérios de equalização, testes e aceite devem formar uma base comparável para fornecedores e executores.

Veja como funciona o Procurement Técnico

Maturidade, estimativas e contratação

A qualidade do FEED deve ser avaliada pela maturidade e pela precisão das informações, não pelo volume de documentos. A decisão de contratação precisa considerar quais lacunas permanecem e como elas serão distribuídas entre proprietário, projetista, fornecedores e executor.

Avaliação da definição do escopo

Ferramentas como o Project Definition Rating Index — PDRI ajudam a avaliar a completude da definição antes do detalhamento e da construção. O objetivo não é obter apenas uma pontuação, mas identificar elementos frágeis, registrar ações de mitigação e verificar se a maturidade é compatível com o próximo gate.

O tipo de PDRI deve corresponder ao empreendimento. Instalações industriais, edificações e infraestruturas possuem elementos de definição distintos.

Classe da estimativa de custos

O FEED costuma permitir estimativas mais maduras do que aquelas elaboradas na viabilidade ou no conceito. Entretanto, a classe não deve ser atribuída somente porque o trabalho recebeu o nome de FEED.

A Recommended Practice 18R-97 da AACE International relaciona a classificação da estimativa à maturidade dos documentos de definição e à finalidade do orçamento. A aplicação exata depende do setor e da prática adotada; um FEED incompleto não produz automaticamente uma estimativa confiável.

A base da estimativa deve registrar quantitativos, preços, produtividade, data-base, câmbio, tributos, contingências, exclusões, riscos e faixa de precisão esperada. O artigo sobre gerenciamento de custos de projetos aprofunda a relação entre estimativa, orçamento, baseline e controle.

FEED como base para EPC e EPCM

Em uma contratação EPC, o contratado assume responsabilidades integradas de engenharia, suprimentos e construção dentro dos limites definidos. Quanto menos madura estiver a engenharia de referência, maior tende a ser a exposição a contingências de preço, exclusões, interpretações de escopo, mudanças e disputas.

O Departamento de Energia dos Estados Unidos informa, em suas perguntas frequentes sobre FEED, que o estudo pode demonstrar prontidão e fornecer entradas críticas para contratos EPC. Isso não transforma o FEED em requisito universal, mas ilustra sua função como base para avaliação técnica e contratual.

Antes de contratar EPC, o proprietário deve verificar se o pacote permite:

  • caracterizar objeto e limites de fornecimento;
  • quantificar os principais sistemas e capacidades;
  • estabelecer requisitos de desempenho;
  • identificar interfaces e condições existentes;
  • definir responsabilidades por licenças, dados e aprovações;
  • comparar propostas sobre uma base técnica comum;
  • estabelecer garantias, testes e critérios de aceite;
  • registrar os riscos mantidos pelo proprietário e os transferidos.

No EPCM, o proprietário mantém contratos diretos de fornecimento e execução, enquanto a empresa EPCM coordena engenharia, suprimentos e implantação. O FEED continua relevante para definir pacotes, interfaces, estimativas e estratégia de execução.

A Owner’s Engineering pode revisar o FEED, verificar aderência das propostas e controlar o desenvolvimento posterior da engenharia em nome do proprietário.

A engenharia de referência precisa continuar governada após a contratação

Revisões, submittals, mudanças, interfaces e critérios de aceite devem permanecer vinculados aos requisitos e às bases definidas no FEED.

Conheça o serviço de Owner’s Engineering

Projetos brownfield e modernizações

Em expansões e modernizações, a qualidade do levantamento é tão importante quanto a concepção da nova solução. Documentação desatualizada, instalações ocultas, restrições de acesso, janelas operacionais, interfaces com sistemas ativos e condições temporárias podem alterar significativamente custo e prazo.

O FEED brownfield deve dedicar atenção a cadastro, investigação de campo, estratégia de transição, contingência, sequenciamento, segurança operacional e critérios de recomissionamento.

Quando contratar FEED

O FEED é indicado quando o empreendimento já possui uma alternativa selecionada, mas ainda precisa de desenvolvimento técnico antes da aprovação final, da licitação, da contratação EPC/EPCM ou do início da engenharia executiva.

Situações típicas incluem:

  • implantação de novo ativo ou unidade;
  • expansão de capacidade;
  • modernização de infraestrutura em operação;
  • preparação de contratação EPC ou turnkey;
  • divisão do empreendimento em múltiplos pacotes;
  • necessidade de melhorar a precisão de custos e prazo;
  • consolidação de interfaces multidisciplinares;
  • preparação para financiamento ou decisão de investimento;
  • revisão independente de solução desenvolvida por terceiros;
  • empreendimento com riscos técnicos ou operacionais relevantes.

Como definir o escopo da contratação

O Termo de Referência do FEED deve estabelecer:

  • objetivo e decisão que o trabalho deverá suportar;
  • documentos e dados fornecidos pelo contratante;
  • atividades de campo e estudos complementares;
  • disciplinas e sistemas incluídos;
  • nível de desenvolvimento requerido;
  • lista de entregáveis e conteúdo mínimo;
  • critérios de revisão, aprovação e maturidade;
  • interfaces com terceiros e responsabilidades;
  • metodologia de custos, cronograma e riscos;
  • requisitos para contratação, comissionamento e aceite;
  • formato dos arquivos, revisões e acervo técnico;
  • exclusões e atividades destinadas à etapa executiva.

Erros que reduzem o valor do FEED

Os problemas mais frequentes são:

  • iniciar a etapa sem alternativa selecionada;
  • trabalhar com levantamentos insuficientes;
  • limitar o escopo a desenhos;
  • não coordenar disciplinas;
  • omitir interfaces contratuais;
  • utilizar quantitativos sem base rastreável;
  • definir custos sem registrar premissas;
  • postergar critérios de teste para depois da contratação;
  • exigir percentual genérico de avanço sem definir produtos e decisões;
  • encerrar o pacote sem registrar pendências e riscos residuais.

Critério de conclusão

Um FEED está concluído quando permite tomar a decisão prevista com riscos conhecidos e documentação compatível com a etapa seguinte. Isso pode significar autorizar investimento, emitir RFP, contratar EPCM, iniciar procurement de itens críticos ou avançar para Projeto Executivo.

A pergunta central não é “quantos desenhos foram emitidos?”, mas: o empreendimento está suficientemente definido para que custos, prazos, responsabilidades e desempenho possam ser assumidos de forma consciente e verificável?

Conclusão

O FEED conecta a alternativa selecionada à decisão de investimento e à contratação da implantação. Seu valor está em integrar requisitos, critérios de projeto, dimensionamentos, interfaces, custos, prazo, riscos, suprimentos, comissionamento e responsabilidades em uma base técnica coerente.

FEED não é sinônimo automático de FEL 3, Projeto Básico ou engenharia básica. A nomenclatura varia; a qualidade depende da maturidade efetiva das informações e da capacidade do pacote de suportar o próximo gate.

Quando bem definido, o FEED reduz ambiguidades, melhora a comparação de propostas, antecipa riscos de implantação e estabelece condições mais objetivas para desenvolver, executar, testar e aceitar o empreendimento. Quando tratado apenas como conjunto de desenhos, transfere incertezas para etapas em que mudanças são mais caras e disputas mais prováveis.

Estruture o FEED conforme a decisão e o modelo de contratação

A A3A Consulting desenvolve e revisa pacotes de engenharia, requisitos, estimativas, cronogramas, interfaces e documentação para contratação e implantação.

Converse com a equipe de Engenharia Consultiva

Referências técnicas

[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): maturação, viabilidade e definição de empreendimentos.

[6] A3A CONSULTING. Projeto Básico de Engenharia: escopo, critérios, dimensionamento e orçamento.

Perguntas frequentes
O que significa FEED em engenharia?

FEED significa Front-End Engineering Design. É a etapa que desenvolve e consolida a solução selecionada antes do detalhamento executivo e da implantação, produzindo bases de projeto, dimensionamentos, estimativas, riscos e requisitos para decisão e contratação.

FEED é a mesma coisa que Projeto Básico?

Não necessariamente. Os dois podem apresentar grande sobreposição quando preparam a contratação, mas pertencem a referenciais distintos. O Projeto Básico possui significado próprio no contexto brasileiro, enquanto o FEED é definido pelo processo de maturação e pelos entregáveis contratados.

FEED corresponde ao FEL 3?

Em muitas metodologias, o FEED integra a fase mais avançada do Front-End Loading e pode ser associado ao FEL 3. A equivalência, porém, não é universal e deve ser confirmada pelo sistema de fases, gates e critérios de maturidade adotado pelo proprietário.

Quais são os principais entregáveis de um FEED?

Podem incluir Basis of Design, requisitos, matrizes de riscos e interfaces, memoriais, cálculos, diagramas, layouts, especificações, listas de equipamentos, quantitativos, CAPEX, cronograma, estratégia de contratação e critérios de testes e aceite.

O FEED é necessário antes de contratar EPC?

Não existe regra única, mas um FEED maduro reduz incertezas e fornece referência para caracterizar escopo, responsabilidades, desempenho, interfaces e critérios de aceite. Contratar EPC com definição insuficiente aumenta contingências, exclusões, mudanças e disputas.

Quem deve participar do desenvolvimento do FEED?

A equipe depende do empreendimento, mas normalmente envolve engenharia multidisciplinar, operação, manutenção, segurança, meio ambiente, custos, planejamento, suprimentos, contratos e representantes do proprietário.

Materiais técnicos complementares

Planejamento e maturação

Desenvolvimento da engenharia

Contratação e implantação

Soluções da A3A Consulting