Capital Project Lifecycle: da oportunidade ao ativo operacional

O Capital Project Lifecycle organiza o investimento da necessidade inicial à operação, conectando decisão, engenharia, contratação, implantação, comissionamento, handover e realização de benefícios.

Confira!

Capital Project Lifecycle é o ciclo de vida de um projeto de capital desde a identificação de uma necessidade ou oportunidade até a entrada do ativo em operação, estabilização de desempenho e avaliação dos benefícios que justificaram o investimento. Diferentemente de uma leitura restrita ao cronograma de obra, o lifecycle acompanha a evolução da decisão de investimento: por que investir, em quê, com qual nível de definição, sob qual estratégia de entrega, com quais controles e em que momento o ativo pode ser considerado efetivamente operacional.

Em projetos de infraestrutura, indústria, energia, Data Centers, telecomunicações, segurança eletrônica, automação ou instalações críticas, esse ciclo normalmente atravessa fases de estratégia, Business Case, viabilidade, Project Framing, Front-End Planning, FEL, FEED, sanction/FID, engenharia, procurement, construção, completions, commissioning, Operational Readiness, handover, start-up, ramp-up e avaliação pós-projeto. A nomenclatura varia entre organizações e setores, mas a lógica permanece: cada fase deve produzir maturidade suficiente para sustentar o próximo compromisso de capital.

O lifecycle não deve ser interpretado como uma sequência rígida de documentos. Fases podem se sobrepor, contratos podem ser antecipados e diferentes pacotes podem avançar em velocidades distintas. Ainda assim, a governança precisa saber qual decisão está sendo tomada, quais evidências sustentam o avanço e quais riscos foram aceitos. Quando isso não ocorre, o cronograma passa a substituir a decisão: o projeto avança porque “chegou a hora”, mesmo que requisitos, interfaces, custos, riscos ou condições de operação ainda estejam imaturos.

A visão de lifecycle também evita que o projeto seja considerado concluído apenas porque a obra terminou. Um ativo só realiza valor quando está testado, documentado, transferido, operável e capaz de produzir o resultado previsto no Business Case. Portanto, o ciclo de vida de um Capital Project começa antes da engenharia detalhada e termina depois da conclusão física.

O lifecycle organiza decisões, não apenas fases

A forma mais útil de compreender o ciclo é associar cada etapa a uma pergunta de governança. O HUB de Capital Projects & Infrastructure organiza o domínio completo; este artigo aprofunda especificamente a progressão do investimento.

Etapa	Pergunta dominante
necessidade / oportunidade	existe um problema ou oportunidade material?
Project Framing	o problema está corretamente definido?
Business Case / viabilidade	vale a pena investir?
FEL / Project Definition	o empreendimento está suficientemente definido?
sanction / FID	podemos comprometer capital relevante?
delivery strategy	como o empreendimento será contratado e entregue?
engenharia / procurement	a solução está sendo desenvolvida e comprada conforme requisitos?
Construction Readiness	podemos mobilizar e construir?
Project Controls / Assurance	estamos preservando a baseline e a qualidade da decisão?
completions / commissioning	o sistema está completo, testável e funcional?
Operational Readiness / handover	a operação está pronta para receber e operar?
start-up / ramp-up	o ativo atingiu estabilidade e capacidade?
benefits realization / post-project evaluation	o investimento entregou o resultado que justificou o CAPEX?

Essa abordagem é consistente com a ideia de que um projeto precisa ser gerenciado no contexto do valor que pretende produzir. O PMBOK® Guide — Eighth Edition reforça a conexão entre resultados do projeto e objetivos organizacionais; a ISO 21502 estabelece orientação aplicável a diferentes modelos de ciclo de vida e abordagens de entrega.

O importante é evitar uma confusão recorrente: fase do projeto não é sinônimo de maturidade. Um projeto pode estar formalmente na etapa “execução” e continuar carregando decisões que deveriam ter sido resolvidas no front end. Da mesma forma, um pacote pode estar pronto para construção enquanto outro ainda depende de engenharia ou fornecedor.

1. Necessidade, oportunidade e contexto do investimento

O lifecycle começa quando a organização identifica uma condição que pode justificar investimento: expansão de capacidade, obsolescência, risco, conformidade, redução de OPEX, continuidade operacional, eficiência energética, modernização, nova demanda, requisito de cliente ou estratégia corporativa.

Nesse momento ainda não existe obrigação de existir “um projeto”. Existe uma hipótese de investimento. A primeira responsabilidade é demonstrar que a necessidade é real e material.

Dados típicos incluem:

• demanda atual e prevista;
• indicadores de capacidade ou desempenho;
• falhas e indisponibilidades;
• condição de ativos;
• risco de continuidade;
• requisitos regulatórios;
• custos de operação e manutenção;
• impactos de não agir;
• oportunidades de crescimento ou eficiência.

Quando a condição existente é pouco conhecida, Due Diligence Técnica ou levantamentos de campo podem ser necessários antes mesmo de formular alternativas.

Essa fase deve evitar transformar uma necessidade em solução automática. “Trocar o equipamento”, “construir uma sala”, “aumentar a potência” ou “migrar de plataforma” são respostas possíveis, não necessariamente o problema.

2. Project Framing: definir o problema antes da solução

O Project Framing transforma uma necessidade ainda difusa em uma base de decisão. Ele define situação atual, estado futuro desejado, objetivos, critérios de sucesso, stakeholders, restrições, premissas, dependências e decisões que precisarão ser tomadas.

O principal risco que essa etapa combate é a solução prematura. Quando o projeto nasce como “comprar X”, “construir Y” ou “contratar Z”, toda análise posterior tende a justificar a escolha original.

O framing cria espaço para alternativas e permite separar:

• fatos de hipóteses;
• objetivos de entregáveis;
• restrições de preferências;
• critérios de sucesso de especificações;
• valor esperado de forma de implementação.

O resultado não precisa ser volumoso, mas deve ser rastreável o suficiente para alimentar Business Case e viabilidade.

3. Business Case e decisão de continuar estudando

O Business Case em Projetos de Engenharia organiza a justificativa do investimento. Ele conecta necessidade, alternativas, benefícios, custos, riscos, estratégia e capacidade de entrega.

Nesta fase, a precisão dos números deve ser compatível com a maturidade. O objetivo não é produzir uma falsa exatidão; é saber se existem razões suficientes para continuar investindo em definição.

Um Business Case robusto normalmente precisa demonstrar:

1. alinhamento estratégico;
2. necessidade ou oportunidade;
3. alternativas razoáveis, incluindo não fazer ou postergar quando aplicável;
4. benefícios e outcomes esperados;
5. custos e recursos em nível compatível com a fase;
6. riscos e incertezas relevantes;
7. prazo e dependências principais;
8. capacidade organizacional para desenvolver e entregar;
9. critérios para revisar a decisão à medida que a informação melhora.

O Business Case não deve ser tratado como documento congelado após a aprovação. Mudanças de escopo, custos, prazo ou benefícios podem alterar a justificativa original. A Gestão de CAPEX em Projetos de Engenharia precisa preservar essa relação durante o lifecycle.

4. Viabilidade e seleção de alternativas

Antes de desenvolver engenharia com profundidade, a organização precisa testar se as alternativas são exequíveis e comparáveis. O Estudo de Viabilidade em Engenharia avalia dimensões técnicas, econômicas, operacionais, regulatórias e de risco.

A alternativa “mais barata” não é necessariamente a melhor. Comparações podem incluir CAPEX, OPEX, prazo, disponibilidade, risco, flexibilidade, capacidade, manutenção, eficiência, impacto sobre operação e valor residual.

A análise pode combinar métodos financeiros e multicritério. O importante é que critérios e pesos sejam explicitados. Quando uma alternativa já está escolhida antes da análise, a viabilidade vira justificativa retrospectiva.

5. Front-End Planning, FEL e Project Definition

Depois que a oportunidade merece ser desenvolvida, entra a etapa de aumentar a definição. O FEL — Front-End Loading organiza essa maturação progressiva.

O Construction Industry Institute associa Front End Planning à definição do escopo antes de detailed design e construction. O PDRI — Project Definition Rating Index oferece um método para avaliar lacunas de definição antes que elas sejam transferidas para etapas mais caras.

No front end, a organização procura consolidar progressivamente:

• requisitos de negócio e técnicos;
• alternativas e solução selecionada;
• Basis of Design;
• levantamentos e dados do site;
• interfaces;
• riscos;
• estratégia de execução;
• estimativas de custo;
• cronograma;
• procurement;
• requisitos operacionais;
• critérios de aceite.

A principal mudança de lógica é sair de “temos uma ideia promissora” para “temos um empreendimento suficientemente definido para assumir compromissos maiores”.

6. FEED: transformar a alternativa selecionada em base técnica de contratação

O FEED em Engenharia consolida a solução selecionada em nível capaz de sustentar estimativa, decisão, procurement e desenvolvimento posterior da engenharia.

Dependendo do setor, FEED pode se aproximar de engenharia básica, design development ou detailed scope definition. A nomenclatura é menos importante que a maturidade exigida.

Um pacote FEED precisa demonstrar coerência entre requisitos, critérios de projeto, arquitetura, dimensionamentos principais, interfaces, riscos, cronograma, estimativas e estratégia de contratação. Quantidade de desenhos não é substituto para definição.

O FEED também deve preparar a transição para procurement. Equipamentos críticos, vendor data, long lead items e pacotes de contratação precisam estar suficientemente compreendidos para evitar que compras antecipadas criem dependências técnicas irreversíveis.

7. Stage-Gates e Project Readiness

O Stage-Gate em projetos de engenharia transforma a evolução do lifecycle em decisões formais. Cada gate verifica se evidências, maturidade, riscos e recursos são compatíveis com o próximo compromisso.

O Project Readiness aprofunda a pergunta “pronto para quê?”. Um projeto pode estar pronto para avançar FEED e não estar pronto para licitar; pronto para contratar determinado pacote e não para mobilizar construção; mecanicamente concluído e ainda não pronto para operação.

Resultados de gate podem incluir:

• go;
• go condicionado;
• hold;
• rework;
• cancelamento ou reorientação.

A decisão deve registrar condicionantes, responsáveis e prazo. “Aprovado com ressalvas” sem owner e sem controle apenas transfere risco.

8. Project Sanction / Final Investment Decision

Sanction ou Final Investment Decision é o ponto em que a organização autoriza um compromisso relevante de capital com base em uma configuração suficientemente madura do empreendimento.

O gate de sanction precisa responder mais que “o VPL é positivo?”. Deve verificar se Business Case, engenharia, estimativas, cronograma, riscos, delivery strategy, organização, procurement e readiness formam um conjunto coerente.

A maturidade exigida varia por projeto e modelo contratual. Um EPC turnkey exige base de contratação diferente de uma estratégia EPCM com múltiplos pacotes. Porém, em qualquer modelo, a governança precisa compreender a incerteza residual e quem a está assumindo.

Uma decisão de sanction tecnicamente robusta deveria deixar claro:

• baseline aprovada;
• escopo e requisitos;
• alternativa selecionada;
• classe e base das estimativas;
• cronograma e caminho crítico em nível compatível;
• principais riscos e contingências;
• estratégia de contratação;
• pacotes e interfaces;
• organização do owner;
• readiness para procurement e fases seguintes;
• critérios de mudança e reaprovação.

9. Project Execution Plan e Delivery Strategy

Depois do sanction, o empreendimento precisa transformar a decisão aprovada em uma arquitetura executável. O Project Execution Plan descreve como o trabalho será organizado, integrado, controlado e governado.

A Delivery Strategy define como engenharia, procurement e construção serão distribuídos entre owner, EPC, EPCM, gerenciadora, projetistas, fornecedores e contratados. Essa escolha determina onde residem interfaces e riscos.

EPC, EPCM e múltiplos contratos não são apenas formas comerciais. Eles alteram responsabilidades de design, procurement, coordenação, integração e controle. A escolha deve considerar maturidade do escopo, mercado, capacidade do owner, tolerância a risco, necessidade de flexibilidade e complexidade das interfaces.

Nesse ponto, Owner’s Engineering pode representar tecnicamente o proprietário, enquanto Project Controls transforma prazo, custo e progresso em informação de governança.

10. Engenharia, Procurement e gestão de interfaces

Durante delivery, a engenharia executiva desenvolve o detalhamento necessário à execução, mas continua subordinada aos requisitos, Basis of Design e decisões do front end. Mudanças precisam ser controladas para evitar erosão silenciosa do Business Case.

Procurement não é uma função isolada de compras. Equipamentos e sistemas influenciam desenho, interfaces, layout, potência, civil, automação, documentação, testes, manutenção e cronograma.

Vendor Data precisa alimentar a engenharia no momento adequado. Long lead items precisam ser identificados cedo. Technical Bid Evaluation precisa verificar aderência a requisitos, exceções, documentação e impactos de integração.

A Gestão de Interfaces ganha importância crescente quando o empreendimento possui múltiplos pacotes, disciplinas ou fornecedores.

11. Project Controls durante a implantação

O lifecycle precisa de baseline e forecast. A Gestão de Projetos — Project Controls integra cronograma, custo, progresso, tendências e mudanças para responder onde o projeto está e para onde está indo.

Controls não é apenas relatório histórico. Seu valor está em antecipar tendência antes que o desvio se torne irreversível.

Uma estrutura adequada normalmente inclui:

• WBS/EAP e estruturas de custo;
• baseline de escopo, prazo e custo;
• critérios de medição física;
• atualização de progresso;
• análise de caminho crítico;
• forecast;
• tendências;
• change control;
• integração com riscos;
• relatórios executivos.

12. Project Assurance: confiança antes dos compromissos críticos

O Project Assurance em Engenharia não deve ser confundido com gerenciamento diário. Sua função é revisar, com independência suficiente, se a governança possui evidências para confiar em uma decisão.

Assurance pode ser aplicado antes de sanction, procurement, mobilização, energização, commissioning, handover ou outros marcos materialmente relevantes.

Ao longo do lifecycle, assurance ajuda a evitar que a mesma equipe responsável por produzir o plano seja a única fonte de confiança sobre a qualidade desse plano.

13. Construction Readiness

Construction Readiness responde se o empreendimento está realmente pronto para campo. Emitir desenho IFC é apenas uma parte.

A prontidão pode exigir:

• áreas liberadas;
• projetos suficientemente desenvolvidos;
• materiais e equipamentos disponíveis;
• acessos e logística;
• licenças;
• métodos executivos;
• ITPs e hold points;
• segurança;
• equipes;
• interfaces resolvidas;
• cronograma coerente;
• restrições removidas.

Mobilizar antes de resolver essas condições costuma converter incerteza de engenharia em improdutividade, RFIs, retrabalho, espera e mudanças de campo.

14. Execução, qualidade e gestão de mudanças

Durante a construção, a governança precisa preservar configuração e evidência. Field Engineering, RFIs, Site Instructions, NCRs, submittals e mudanças formam parte do sistema de controle técnico.

A execução física não pode se distanciar silenciosamente da documentação aprovada. Mudanças precisam ter causa, análise de impacto, autoridade, atualização de documentos e efeito sobre baseline.

A qualidade deve ser verificável por ITPs, inspeções, testes, certificados, registros e critérios de aceite, não apenas por percepção de boa execução.

15. Completions e Systemization

À medida que a obra avança, o empreendimento precisa deixar de ser controlado apenas por disciplinas e áreas e passar a ser organizado por sistemas capazes de serem concluídos, testados e transferidos.

Systemization divide o ativo em sistemas e subsistemas coerentes com a sequência de completions e commissioning. Isso permite definir fronteiras, turn-over packages, punch lists e readiness por sistema.

Mechanical Completion significa que determinado sistema atingiu uma condição física definida para avançar. Não equivale automaticamente a operação.

Essa etapa reduz o risco de descobrir no final que milhares de atividades “quase concluídas” não formam um sistema testável.

16. Pre-Commissioning e Commissioning

O Guia de Comissionamento trata em profundidade planejamento, verificação, FAT, SAT, testes funcionais, integração, documentação e aceite.

No lifecycle, commissioning é a ponte entre construção e demonstração de desempenho. Seu objetivo não é apenas energizar ou ligar equipamentos, mas produzir evidências de que sistemas funcionam segundo requisitos e critérios previamente estabelecidos.

Pré-comissionamento normalmente prepara equipamentos e sistemas para testes funcionais. Commissioning verifica funcionamento, integração, sequência, desempenho e readiness.

A qualidade do commissioning depende de decisões tomadas muito antes: testabilidade, pontos de medição, acessos, critérios de aceite e responsabilidades deveriam estar incorporados ainda em projeto e contratação.

17. Operational Readiness

Um sistema pode estar tecnicamente comissionado e a operação ainda não estar pronta. Operational Readiness amplia o olhar para pessoas, processos, documentação, manutenção, spare parts, sistemas corporativos, treinamento, procedimentos, asset register e governança operacional.

A pergunta muda de “o equipamento funciona?” para “a organização consegue operar, manter e responder ao ativo de forma segura e sustentável?”.

A readiness operacional precisa evoluir paralelamente ao projeto. Deixar treinamento, procedimentos e cadastro de ativos para o final cria transferência incompleta e prolonga a instabilidade pós-handover.

18. Handover e transferência de responsabilidade

O Handover Técnico em Engenharia é a transferência estruturada do ativo para quem irá operar e manter.

Handover não é envio de pasta final. Ele combina:

• condição técnica aceita;
• As-Built;
• Data Book e test records;
• manuais;
• punch list controlada;
• treinamento;
• asset information;
• spare parts;
• garantias;
• responsabilidades;
• aceites e custódia.

Sem essa estrutura, a operação recebe fisicamente um ativo sem receber a informação e o conhecimento necessários para sustentá-lo.

19. Start-Up e Ramp-Up

Start-Up é a entrada inicial do ativo em condição operacional. Ramp-Up é o período de crescimento progressivo até capacidade, estabilidade, produtividade ou desempenho nominal.

Projetos falham ao assumir que capacidade nominal aparece imediatamente após commissioning. Operadores ainda estão ganhando experiência, parâmetros precisam ser ajustados, interfaces são estabilizadas e defeitos iniciais podem aparecer.

A curva de ramp-up deve ser considerada no Business Case e no planejamento de benefícios. Se a receita ou economia assume desempenho nominal no primeiro dia, o modelo econômico pode estar superestimando a velocidade de realização de valor.

20. Benefits Realization

O lifecycle só faz sentido se fechar o ciclo do investimento. Gestão de Benefícios verifica se outputs geraram outcomes e se esses outcomes produziram benefícios.

Alguns benefícios só aparecem meses depois da operação. A responsabilidade precisa continuar após o encerramento contratual do projeto.

Indicadores podem incluir:

• capacidade;
• disponibilidade;
• produtividade;
• redução de falhas;
• redução de OPEX;
• eficiência energética;
• qualidade;
• segurança;
• tempo de atendimento;
• receitas;
• satisfação de usuários;
• redução de risco.

Sem métricas e owners, o benefício tende a desaparecer do radar quando a equipe do projeto é desmobilizada.

21. Post-Project Evaluation e Lessons Learned

A etapa pós-projeto compara premissas, resultados e desempenho real. Ela não é uma cerimônia de encerramento. É um mecanismo de governança de portfólio.

A ISO 21513:2026 cria uma referência específica para post-project e post-programme evaluation, reforçando a importância de avaliar resultados após a entrega.

Uma avaliação pós-projeto pode perguntar:

• o investimento entregou os benefícios esperados?
• o CAPEX final é coerente com a decisão original?
• o ramp-up ocorreu como previsto?
• quais riscos se materializaram?
• quais premissas estavam erradas?
• quais decisões tiveram maior impacto?
• o modelo de contratação funcionou?
• que aprendizados precisam entrar em padrões futuros?

Lessons Learned só geram valor quando alteram processos, critérios, templates, estimativas, contratos ou práticas de novos projetos.

Gates do lifecycle: o avanço deve ser proporcional à evidência

Uma organização pode criar diferentes gates, mas a lógica precisa permanecer consistente. Cada gate deve responder:

1. qual decisão está sendo tomada;
2. qual compromisso de capital ou risco será assumido;
3. quais evidências são obrigatórias;
4. qual incerteza residual é aceitável;
5. quem possui autoridade;
6. quais condicionantes podem permanecer;
7. quando a decisão precisa ser revista.

O erro é transformar gate em reunião de status. Um gate só possui valor quando pode impedir, condicionar ou redirecionar o avanço.

Como a maturidade muda ao longo do ciclo

Maturidade não cresce apenas porque o tempo passou. Ela aumenta quando decisões são tomadas e evidências são produzidas.

Dimensão	Early stage	Antes de sanction	Antes de construção	Antes de operação
problema	definido	validado	estável	rastreado aos requisitos
solução	alternativas	solução selecionada e definida	detalhe executável	configuração testada
custo	ordem de grandeza	estimativa compatível com decisão	baseline controlada	custo final e forecast residual
prazo	marcos	cronograma integrado	sequência executiva	start-up/ramp-up
riscos	exposições principais	análise e contingência	riscos de execução	riscos operacionais residuais
informação	gaps conhecidos	pacote de definição	IFC/vendor data	As-Built/Data Book
operação	requisitos	envolvimento crescente	preparação	readiness comprovada

Essa leitura ajuda a combater precisão aparente. Um número detalhado não é necessariamente confiável quando o escopo que o sustenta ainda é imaturo.

Quem governa o lifecycle

O lifecycle atravessa diferentes funções. Sponsor, investment committee, project manager, Owner’s Engineer, Project Controls, Technical Authority, procurement, operação e assurance possuem papéis distintos.

A governança deve deixar claro:

• quem aprova capital;
• quem é owner dos benefícios;
• quem conduz o projeto;
• quem controla baseline;
• quem protege requisitos técnicos;
• quem revisa independentemente a readiness;
• quem aceita riscos residuais;
• quem recebe o ativo.

A Governança decisória com alçadas, comitês e stage-gates aprofunda direitos de decisão e tolerâncias.

Como contratar apoio especializado ao longo do lifecycle

Um contrato genérico de “consultoria” pode misturar funções. O escopo precisa distinguir diagnóstico, viabilidade, definição, projeto, controls, Owner’s Engineering, assurance, fiscalização e commissioning.

A contratação deve especificar:

• fase do lifecycle;
• problema e decisão a suportar;
• entregáveis;
• responsabilidades;
• autoridade e limites;
• interfaces com equipe interna e contratados;
• evidências requeridas;
• critérios de medição;
• critérios de aceite;
• marcos de revisão;
• tratamento de mudanças;
• forma de encerramento e transferência.

Isso evita contratar uma função esperando resultado de outra. Project Controls não substitui Owner’s Engineering; assurance não conduz o projeto; fiscalização não substitui commissioning; FEED não substitui framing.

Como a A3A Engenharia estrutura a jornada de Capital Projects

A A3A pode atuar em diferentes pontos do lifecycle sem pressupor que todo cliente precise contratar todas as etapas. A combinação depende da maturidade e do risco do empreendimento.

A lógica institucional pode ser resumida em três movimentos:

Assessment — entender condição, problema, maturidade, riscos e evidências; Advisory — estruturar alternativas, requisitos, projetos, contratação e decisões; Assurance — verificar readiness, conformidade, desempenho e aceite antes de compromissos críticos.

Essa estrutura permite adaptar a intervenção: Due Diligence em uma aquisição, Viabilidade em uma expansão, FEL em um novo empreendimento, Project Controls durante implantação, Owner’s Engineering para representar o proprietário ou commissioning e recebimento na transição.

Conclusão técnica

Capital Project Lifecycle é a estrutura que conecta estratégia, engenharia, capital e operação. Seu valor não está em desenhar uma linha do tempo bonita, mas em impedir que compromissos cresçam mais rápido que a maturidade do projeto.

Um lifecycle robusto preserva o encadeamento entre necessidade, decisão, requisitos, solução, CAPEX, contratos, execução, testes e benefícios. Cada avanço precisa ser sustentado por evidências compatíveis com o risco da decisão. Cada transição precisa deixar claro o que está aprovado, o que permanece condicionado e quem aceita a incerteza residual.

A conclusão física é apenas um marco. O ciclo se fecha quando o ativo está operacional, a informação foi transferida, o ramp-up estabilizou e a organização consegue comparar o resultado real com o Business Case que autorizou o investimento.

A pergunta que governa todo o lifecycle é simples: o projeto possui maturidade suficiente para assumir o próximo compromisso de capital sem transferir incerteza indevida para a fase seguinte?

Referências técnicas

[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Genebra: ISO, 2020. Disponível em: https://www.iso.org/standard/74947.html

[2] PROJECT MANAGEMENT INSTITUTE. PMBOK® Guide — Eighth Edition. Newtown Square: PMI, 2025. Disponível em: https://www.pmi.org/standards/pmbok

[3] CONSTRUCTION INDUSTRY INSTITUTE. Project Definition Rating Index (PDRI) Overview. Austin: CII. Disponível em: https://www.construction-institute.org/pdri-overview

Perguntas frequentes

O que é Capital Project Lifecycle?

É o ciclo de vida de um investimento de capital desde a identificação da necessidade até a entrada em operação, estabilização e avaliação dos benefícios do ativo.

O lifecycle é igual ao cronograma do projeto?

Não. O cronograma organiza atividades e datas. O lifecycle organiza fases de decisão, maturidade, evidências e compromissos de capital.

Onde entram FEL e FEED?

FEL integra o Front-End Planning e amadurece o empreendimento antes de compromissos relevantes. FEED consolida a solução selecionada em nível técnico capaz de sustentar estimativa, contratação e desenvolvimento posterior.

O que é sanction ou FID?

É a decisão de autorizar um compromisso relevante de capital após verificar Business Case, definição técnica, estimativas, riscos, estratégia de entrega, organização e readiness.

Quando um projeto de capital termina?

A conclusão física não é suficiente. O ciclo se encerra de forma mais completa quando o ativo foi testado, transferido, entrou em operação e existe avaliação dos resultados e benefícios esperados.

Project Controls e Owner’s Engineering são a mesma coisa?

Não. Project Controls mede e prevê prazo, custo e progresso. Owner’s Engineering representa tecnicamente o proprietário, protegendo requisitos, interfaces, execução, testes e aceite.

Materiais técnicos complementares

Serviços relacionados

• Due Diligence Técnica de Engenharia
• Estudo de Viabilidade Técnica e Econômica
• FEL — Front-End Loading
• Gestão de Projetos — Project Controls
• Engenharia do Proprietário — Owner’s Engineering
• Gerenciamento de Riscos de Engenharia

Conteúdos principais sobre o tema

• Capital Projects & Infrastructure — HUB
• Project Framing em Projetos de Capital
• Business Case em Projetos de Engenharia
• Gestão de CAPEX em Projetos de Engenharia
• Stage-Gate em Projetos de Engenharia
• Project Readiness em Engenharia

Conteúdos técnicos correlatos

• PDRI — Project Definition Rating Index
• FEED em Engenharia
• Project Assurance em Engenharia
• Análise de Riscos em Projetos de Engenharia
• Gestão de Benefícios em Projetos e Programas
• Handover Técnico em Engenharia
• Guia Completo sobre Engenharia Consultiva
• Guia de Gerenciamento de Projetos
• Guia Completo de Comissionamento