Project Framing em Projetos de Capital: como definir o problema antes da solução

Project Framing estrutura o problema, o valor esperado, as restrições e as decisões de um projeto de capital antes que a organização se comprometa prematuramente com uma solução.

Confira!

Project Framing é o processo estruturado usado para definir corretamente qual problema, necessidade ou oportunidade justifica um projeto, quais resultados precisam ser alcançados e quais limites devem orientar a análise antes de transformar uma hipótese em solução de engenharia. Em projetos de capital, essa etapa existe para impedir um erro recorrente: começar pelo equipamento, tecnologia, obra ou fornecedor antes de existir consenso sobre o problema que o investimento precisa resolver.

O framing não é um anteprojeto, um FEED simplificado nem uma reunião de brainstorming. Ele organiza a decisão inicial. A equipe procura estabelecer a situação atual, o estado futuro desejado, os stakeholders relevantes, os objetivos de negócio, os critérios de sucesso, as restrições, as premissas críticas, as dependências e as decisões que ainda precisam ser tomadas. O resultado é uma referência comum para desenvolver alternativas, estruturar o Business Case e decidir se a oportunidade merece avançar para estudos mais profundos.

Em termos práticos, um bom Project Framing separa problema de solução. “Precisamos instalar uma nova subestação”, “precisamos trocar o VMS” ou “precisamos construir um novo Data Center” são formulações de solução. O problema pode ser insuficiência de capacidade, obsolescência, indisponibilidade, expansão de demanda, não conformidade, risco operacional, perda de produtividade ou incapacidade de atender um requisito futuro. Enquanto essa diferença não estiver clara, a organização corre o risco de otimizar uma solução que não resolve a necessidade real.

O framing também delimita a qualidade da decisão seguinte. Antes de autorizar estudos, reservar CAPEX ou envolver fornecedores, a governança precisa saber o que está sendo decidido, com base em quais evidências e quais incertezas permanecem abertas. Por isso, Project Framing funciona como uma etapa de redução de ambiguidade: ele não elimina riscos nem define todos os detalhes, mas cria uma base comum para que viabilidade, FEL, Project Definition e aprovação de investimento trabalhem sobre o mesmo problema.

Project Framing dentro do ciclo de um Capital Project

Um projeto de capital começa antes de existir projeto de engenharia. A origem pode ser uma necessidade operacional, uma expansão de capacidade, um requisito regulatório, uma oportunidade de redução de custo, uma mudança tecnológica, uma obrigação de continuidade, uma necessidade de resiliência ou uma estratégia corporativa. O primeiro desafio é transformar esse estímulo em uma definição suficientemente clara para orientar investigação e decisão.

Dentro do ciclo de Capital Projects & Infrastructure, o framing ocupa a transição entre a percepção de uma necessidade e a estruturação formal do investimento. Ele antecede o detalhamento da solução e conversa diretamente com o Business Case em Projetos de Engenharia, porque o Business Case precisa demonstrar por que determinada alternativa representa uma resposta adequada ao problema — e essa demonstração fica frágil quando o próprio problema foi mal definido.

Uma sequência lógica pode ser representada assim:

1. identificar a necessidade, oportunidade ou risco;
2. compreender a condição atual e o contexto;
3. formular o problema de maneira neutra em relação à solução;
4. definir objetivos, resultados esperados e critérios de sucesso;
5. registrar restrições, premissas, dependências e interfaces;
6. identificar stakeholders e autoridade decisória;
7. mapear decisões necessárias e informações faltantes;
8. abrir espaço para alternativas;
9. avançar para viabilidade, concepção e definição do empreendimento.

Essa sequência não significa que todo projeto exigirá um workshop formal chamado “Project Framing”. O princípio é mais importante que a nomenclatura: antes de comprometer recursos significativos, deve existir uma formulação rastreável do problema e uma compreensão comum do que seria uma solução bem-sucedida.

O Project Set Up Toolkit do governo britânico trabalha lógica semelhante ao separar o porquê do projeto, o que deve ser entregue e o como será estruturada a capacidade de entrega. A utilidade dessa distinção em engenharia privada ou pública está em evitar que uma decisão de implementação seja tratada como se fosse a própria justificativa do investimento.

O erro mais comum: transformar a solução em problema

A forma como a oportunidade é escrita condiciona todo o raciocínio posterior. Se o enunciado inicial já contém a solução, as alternativas tendem a ser avaliadas apenas como variações da decisão previamente escolhida.

Considere três formulações:

Formulação inicial	Natureza	Efeito sobre a decisão
“Instalar um novo gerador de 500 kVA”	solução	restringe prematuramente capacidade, tecnologia e estratégia
“Eliminar quedas de energia na unidade”	problema amplo	abre o diagnóstico, mas ainda precisa de métricas e limites
“Garantir alimentação das cargas críticas por 4 horas, com disponibilidade mínima definida e sem ampliar a demanda contratada”	necessidade estruturada	cria critérios para comparar alternativas

No terceiro caso, a engenharia pode estudar gerador, UPS, armazenamento, redundância de alimentação, seletividade, redistribuição de cargas, geração local ou combinações entre soluções. A necessidade continua estável mesmo que a solução mude.

Essa disciplina é especialmente importante em brownfield. A organização costuma conhecer bem a dor operacional e, ao mesmo tempo, carregar interpretações históricas sobre a causa. Um problema de indisponibilidade pode ser atribuído a equipamento obsoleto quando a causa dominante está em proteção, manutenção, capacidade, configuração, infraestrutura de suporte ou processo operacional. Nesses casos, Due Diligence Técnica de Engenharia e levantamentos de campo ajudam a substituir opinião por evidência.

O framing deve conter linguagem suficientemente neutra para permitir investigação. Isso não significa ignorar hipóteses. Hipóteses são úteis, desde que sejam registradas como hipóteses e não convertidas silenciosamente em fatos.

Da condição atual ao estado futuro desejado

Um framing robusto precisa responder duas perguntas complementares: onde estamos? e o que precisa ser diferente?. A distância entre essas duas condições é a base para definir o problema.

A condição atual deve ser descrita com evidências proporcionais à decisão. Em alguns casos, dados operacionais, indicadores de disponibilidade, ocorrências e documentação existente são suficientes para iniciar o raciocínio. Em outros, especialmente quando o investimento depende de infraestrutura existente, pode ser necessário realizar inspeções, levantamentos, medições ou análises documentais antes de concluir o framing.

O estado futuro desejado, por sua vez, não deve ser descrito apenas como uma lista de entregáveis. “Ter uma nova sala elétrica” é entrega. “Suportar expansão de 30% de carga com seletividade, continuidade e margem de crescimento definida” descreve uma condição de desempenho. A segunda formulação oferece base muito melhor para requisitos e critérios de aceite.

Uma boa descrição do estado futuro normalmente considera:

• capacidade ou desempenho esperado;
• disponibilidade e confiabilidade;
• segurança e conformidade;
• restrições de operação e manutenção;
• horizonte de vida útil ou expansão;
• requisitos de continuidade;
• nível de serviço ou qualidade;
• impactos sobre custo operacional;
• critérios de sustentabilidade, quando aplicáveis;
• data ou janela em que o resultado precisa estar disponível.

Essa lógica ajuda a construir o “golden thread” do investimento: necessidade → objetivo → requisito → solução → teste → benefício. Quando esse encadeamento se perde, o projeto pode ser tecnicamente concluído e ainda assim não entregar o resultado que justificou o CAPEX.

Objetivos, outcomes e critérios de sucesso

Objetivos vagos produzem projetos vagos. Expressões como “modernizar”, “melhorar”, “otimizar” ou “aumentar a confiabilidade” precisam ser convertidas em critérios que possam orientar alternativas e, posteriormente, ser verificados.

O framing não precisa transformar todos os objetivos em especificações detalhadas, mas deve distinguir três níveis:

Nível	Pergunta	Exemplo
objetivo estratégico	por que investir?	suportar expansão operacional sem aumentar exposição a indisponibilidade
outcome esperado	o que precisa mudar no negócio/operação?	aumentar capacidade disponível e reduzir interrupções não programadas
critério de sucesso	como reconhecer que funcionou?	margem de capacidade, disponibilidade e tempo de recuperação dentro dos valores aprovados

Essa estrutura se conecta diretamente à Gestão de Benefícios em Projetos e Programas. Um benefício precisa de owner, métrica, horizonte e relação causal com as entregas. Se o framing não consegue explicar qual outcome o projeto deve habilitar, a justificativa tende a depender apenas de uma lista de ativos a serem adquiridos.

A definição de sucesso também reduz conflitos entre stakeholders. A operação pode priorizar disponibilidade; finanças, limite de CAPEX; manutenção, padronização e acesso; segurança, mitigação de riscos; TI, interoperabilidade; engenharia, desempenho e vida útil. O framing torna explícitas essas prioridades para que conflitos apareçam antes de serem incorporados ao projeto.

Stakeholders: quem define valor, quem entrega e quem recebe o ativo

Project Framing não pode ser conduzido apenas pela área que identificou a necessidade. Projetos de capital criam impactos transversais e, por isso, precisam reunir perspectivas que normalmente aparecem em momentos diferentes do ciclo.

Os stakeholders relevantes podem incluir patrocinador, operação, manutenção, engenharia, facilities, TI, segurança, HSE, suprimentos, finanças, jurídico, usuários, gestão de ativos, fiscalização, reguladores e, em determinados casos, parceiros externos. A composição depende do tipo de empreendimento.

O objetivo não é ampliar indefinidamente o fórum. É garantir que as funções capazes de alterar requisitos, impor restrições ou receber o ativo sejam consideradas cedo o suficiente.

Uma matriz simples pode distinguir:

• decision owner: quem possui autoridade para aprovar o avanço;
• benefit owner: quem responde pela realização do resultado esperado;
• requirement owner: quem define ou valida determinado requisito;
• asset/operations owner: quem receberá o ativo em operação;
• technical authority: quem protege critérios técnicos e padrões;
• delivery owner: quem conduzirá o desenvolvimento e a implantação.

A clareza desses papéis reduz um problema frequente: o projeto ser desenvolvido pela engenharia, aprovado por finanças e recebido por operação sem que nenhuma das partes tenha tido responsabilidade explícita pela continuidade entre necessidade, requisitos e benefício.

Restrições, “givens” e premissas: não são a mesma coisa

Uma das contribuições mais práticas do framing é organizar o que é realmente fixo e o que apenas parece fixo.

Restrições são condições que limitam as alternativas: área física, janela de parada, legislação, capacidade de alimentação, data regulatória, orçamento máximo, interfaces existentes ou impossibilidade de interromper determinada operação.

Givens são decisões ou condições consideradas estabelecidas pela governança naquele momento. Devem ser testadas, porque muitas vezes representam decisões históricas que perderam validade.

Premissas são condições assumidas como verdadeiras para permitir análise, embora ainda dependam de confirmação. Precisam de owner, evidência esperada e data para validação.

Elemento	Tratamento no framing	Risco se confundido
restrição	registrar origem e impacto	excluir alternativas viáveis ou ignorar limites reais
given	confirmar autoridade e validade	perpetuar decisão antiga sem fundamento atual
premissa	indicar incerteza e plano de validação	construir estimativas e projetos sobre informação não comprovada

Essa distinção prepara o terreno para um futuro Assumptions Register e para a gestão de restrições. Também melhora a qualidade de estimativas e cronogramas, porque permite separar informação conhecida de hipótese.

Dependências e interfaces que precisam aparecer cedo

Um projeto pode parecer simples quando analisado isoladamente e se tornar complexo por causa das interfaces. O framing deve identificar dependências que podem controlar a viabilidade ou o prazo mesmo antes de existir projeto detalhado.

Exemplos incluem:

• disponibilidade de energia, água, telecomunicações ou utilidades;
• obras civis associadas;
• licenças e aprovações;
• janelas de desligamento;
• integração com sistemas existentes;
• capacidade da equipe de operação;
• dependência de fornecedor específico;
• importação e long lead items;
• obras de terceiros;
• migração de dados ou sistemas;
• condicionantes de segurança e acesso;
• mudanças organizacionais necessárias para usar o ativo.

A Gestão de Interfaces passa a ser crítica à medida que a solução amadurece, mas o framing já deve identificar as interfaces capazes de alterar alternativas, prazo ou custo.

Framing e alternativas: abrir o espaço de decisão antes de fechar a solução

A finalidade do framing não é selecionar a alternativa vencedora. É criar as condições para que a comparação seja racional.

Uma alternativa pode variar por tecnologia, arquitetura, localização, capacidade, faseamento, modelo de implantação, prazo, nível de redundância, utilização de ativos existentes ou combinação entre intervenção física e mudança operacional.

O framing deve evitar dois extremos. No primeiro, a equipe parte diretamente para uma solução favorita. No segundo, abre um universo tão amplo de possibilidades que a análise perde foco. A função dos objetivos e restrições é criar um “solution space” controlado.

Depois do framing, técnicas como Análise Multicritério (MCDA), matriz de decisão, custo-benefício e estudos de viabilidade podem comparar alternativas com critérios explícitos. Isso é muito diferente de pedir três propostas a fornecedores e tratar as propostas recebidas como se fossem as únicas alternativas do problema.

Riscos no framing: identificar exposição antes de estimar precisão

O registro de riscos não deve começar apenas quando existe cronograma executivo. Riscos de definição aparecem muito antes e podem controlar a qualidade da decisão de investimento.

No framing, a análise é predominantemente exploratória. A equipe procura identificar incertezas capazes de alterar o problema, invalidar uma alternativa ou exigir investigação adicional. Os riscos podem envolver demanda futura, condição existente, tecnologia, licenciamento, capacidade de integração, disponibilidade de área, interfaces, prazo, custo, operação, recursos internos e dependências externas.

O artigo de Análise de Riscos em Projetos de Engenharia aprofunda métodos qualitativos e quantitativos. No framing, a pergunta central é anterior: quais incertezas são suficientemente relevantes para mudar a forma como a oportunidade deve ser estudada?

Uma boa prática é classificar cada incerteza em uma das seguintes ações:

1. aceitar provisoriamente como premissa;
2. investigar antes de selecionar alternativa;
3. investigar antes do Business Case;
4. transferir para etapa posterior com plano explícito;
5. tratar como restrição;
6. escalar para decisão da governança.

O evidence pack mínimo de um Project Framing

O framing precisa produzir evidência suficiente para que outra pessoa consiga compreender o raciocínio sem depender da memória do workshop. O pacote não precisa ser volumoso, mas deve ser rastreável.

Um evidence pack pode incluir:

Documento / registro	Função
problem statement	registrar o problema de forma neutra em relação à solução
opportunity statement	explicar a oportunidade e seu valor potencial
current state	consolidar fatos e baseline conhecidos
target state / success statement	definir a condição futura desejada
objectives and success criteria	traduzir valor em critérios de decisão
stakeholder map	identificar funções que influenciam, decidem ou recebem o ativo
constraints and assumptions	separar limites reais de hipóteses
dependencies and interfaces	revelar fatores externos que controlam a decisão
initial risk register	registrar incertezas capazes de alterar o caminho
decision roadmap	mostrar quais decisões ainda precisam ser tomadas e em que sequência
information gaps	transformar desconhecidos relevantes em ações de investigação

O valor desses registros está na consistência entre eles. Um target state que exige disponibilidade elevada deve aparecer depois em requisitos, arquitetura, estimativa, testes e operação. Um risco crítico identificado no framing não pode desaparecer apenas porque o projeto entrou em FEED.

Decision roadmap: o framing precisa produzir decisões, não apenas informação

Um dos melhores resultados de um framing é um mapa de decisões. Projetos complexos raramente precisam de uma única aprovação; precisam de uma sequência de decisões em que cada uma depende de informações e maturidade diferentes.

O decision roadmap pode indicar, por exemplo:

• confirmar a necessidade;
• validar dados da condição existente;
• aprovar critérios de alternativas;
• selecionar alternativa preferencial;
• aprovar Business Case preliminar;
• autorizar FEL/FEED;
• definir estratégia de contratação;
• concluir Project Readiness;
• realizar sanction/FID.

Isso evita que a organização tente resolver tudo em uma única reunião de aprovação. Também se conecta ao Stage-Gate em projetos de engenharia, no qual cada gate precisa de critérios, evidências, autoridade e resultados possíveis.

Project Framing x Opportunity Framing x Business Case x FEL

Os termos se sobrepõem em algumas metodologias, mas possuem responsabilidades semânticas diferentes. O melhor critério é observar a decisão que cada atividade precisa suportar.

Elemento	Pergunta central	Resultado esperado
Project/Opportunity Framing	qual problema ou oportunidade merece ser desenvolvido?	problema, sucesso, restrições, stakeholders, decisões e gaps
Business Case	vale a pena investir e por quê?	justificativa estratégica, econômica, financeira e de entrega
Viabilidade	quais alternativas são exequíveis e qual apresenta melhor relação entre benefícios, custos e riscos?	recomendação fundamentada e condicionantes
FEL / Front-End Planning	o empreendimento está suficientemente definido para avançar?	maturidade progressiva de escopo, engenharia, custos, riscos e execução
FEED	a solução selecionada está tecnicamente definida para estimar, contratar e preparar implantação?	pacote de engenharia e definição técnica

Essa fronteira evita dois problemas. O primeiro é exigir que o framing tenha o nível de detalhe de um FEED. O segundo é pular o framing e tentar usar o FEED para descobrir qual problema deveria ter sido resolvido.

O FEL — Front-End Loading possui função complementar: depois que a oportunidade está corretamente enquadrada, o FEL estrutura a maturação progressiva da solução, viabilidade, engenharia e critérios para os gates seguintes.

Como saber se o framing está suficientemente maduro

Maturidade não significa ausência de incerteza. Significa que a incerteza remanescente é conhecida, classificada e compatível com a decisão seguinte.

Um framing está suficientemente maduro quando a governança consegue responder de forma consistente:

• qual necessidade ou oportunidade está sendo tratada;
• quais evidências demonstram que ela existe;
• o que caracteriza sucesso;
• quais outcomes e benefícios são esperados;
• quais restrições limitam as alternativas;
• quais premissas ainda precisam ser validadas;
• quais stakeholders possuem autoridade ou requisitos críticos;
• quais dependências podem controlar prazo ou viabilidade;
• quais riscos podem invalidar a oportunidade;
• quais informações faltam;
• quais decisões serão tomadas em seguida;
• qual etapa de engenharia ou análise precisa ser autorizada.

Se a equipe só consegue responder “qual solução queremos comprar?”, o framing ainda não cumpriu sua função.

A lógica é compatível com Project Readiness em Engenharia: estar pronto não significa estar completo, mas possuir evidências e condições adequadas ao próximo compromisso.

Como conduzir um workshop de Project Framing

Workshops são úteis porque tornam divergências visíveis. Porém, o valor não está na dinâmica em si, mas na qualidade das entradas, da facilitação e das decisões produzidas.

Uma estrutura prática pode ser conduzida em sete blocos:

1. Contexto e evidências: apresentar fatos, dados, decisões anteriores e condição atual.
2. Problem statement: formular o problema sem incorporar solução.
3. Success statement: descrever o estado futuro e critérios de sucesso.
4. Stakeholders e interfaces: identificar quem define, decide, entrega e recebe.
5. Constraints, givens e assumptions: separar limites, decisões estabelecidas e hipóteses.
6. Riscos e information gaps: registrar desconhecidos que mudam a decisão.
7. Decision roadmap: definir decisões, owners, evidências necessárias e próximos passos.

Em projetos críticos, a facilitação independente pode ser útil quando existem soluções favoritas, conflitos entre áreas ou forte pressão por aprovação. A independência não substitui a autoridade do sponsor; ajuda a reduzir viés de confirmação e a documentar dissensos antes que virem mudanças caras.

Framing em projetos brownfield

Projetos brownfield exigem cuidado adicional porque a baseline física pode ser menos confiável que a percepção dos stakeholders. As-Built desatualizado, instalações modificadas ao longo dos anos, capacidade residual desconhecida e dependências operacionais informais podem alterar completamente a viabilidade de uma alternativa.

Nesses casos, o framing deve distinguir explicitamente o que sabemos, o que acreditamos saber e o que precisa ser levantado. Pode ser prematuro discutir solução antes de executar site survey, levantamento cadastral ou due diligence.

Essa abordagem reduz o risco de produzir um projeto tecnicamente correto para uma condição que não existe mais.

Framing em projetos públicos

No setor público, o framing possui forte relação com definição da necessidade, planejamento, ETP, seleção de alternativas, value for money e qualidade do problema público que a contratação pretende resolver. A engenharia consultiva não substitui as competências legais da Administração, mas pode melhorar a base técnica sobre a qual decisões são instruídas.

Um enunciado excessivamente orientado à solução pode restringir alternativas antes da análise de viabilidade. Por outro lado, uma necessidade genérica demais pode produzir ETP e Projeto Básico sem critérios suficientes para delimitar objeto, desempenho, prazo e riscos.

A disciplina de framing ajuda a construir continuidade entre necessidade, levantamento, alternativas, engenharia, orçamento, contratação, fiscalização e recebimento.

Como contratar apoio para Project Framing

Quando o framing depende apenas de reuniões internas informais, existe risco de registrar percepções sem investigar dados, conflitos e restrições. A contratação de apoio especializado faz sentido quando a decisão possui impacto material, existem múltiplas disciplinas ou stakeholders, a condição existente é incerta, há alternativas tecnológicas relevantes ou o investimento precisa passar por gates formais.

O escopo contratado deve deixar claro que a finalidade não é simplesmente “realizar workshop”. O objeto precisa estar orientado a produzir uma base de decisão. Entre os entregáveis possíveis estão problem statement, target state, mapa de stakeholders, registro de premissas e restrições, critérios de sucesso, matriz inicial de riscos, information gaps, alternativas a investigar e decision roadmap.

É recomendável especificar:

• documentos de entrada e baseline disponível;
• stakeholders obrigatórios;
• atividades de preparação e análise prévia;
• necessidade de levantamento ou visitas;
• método de facilitação;
• forma de registro de divergências;
• critérios para considerar o framing concluído;
• responsabilidades por validar premissas;
• interface com Business Case, viabilidade e FEL;
• formato de aprovação do pacote final.

Como a A3A Engenharia aborda a definição inicial do empreendimento

A atuação da A3A deve partir do problema real e do nível de evidência necessário para a decisão. Dependendo do contexto, o framing pode exigir apenas facilitação e análise documental ou pode precisar ser precedido por levantamento, site survey e due diligence.

A lógica de trabalho é progressiva:

Assessment — compreender condição, documentos, riscos, premissas e lacunas; Advisory — estruturar objetivos, alternativas, critérios, interfaces e decisões; Assurance — verificar se a evidência disponível é suficiente para avançar ao próximo compromisso.

O serviço não deve antecipar conclusões que pertencem a etapas posteriores. O papel da engenharia consultiva é transformar uma necessidade ainda difusa em uma questão tecnicamente investigável, com decisões e responsabilidades claras.

Isso também significa saber parar. Se o framing revelar que a oportunidade não possui aderência estratégica, que os benefícios não justificam o esforço ou que existe uma alternativa operacional de menor custo, a recomendação técnica pode ser não avançar para um projeto de capital naquele momento.

Conclusão técnica

Project Framing é uma disciplina de decisão, não de desenho. Seu valor está em organizar a oportunidade antes que o investimento seja condicionado por uma solução escolhida cedo demais. Quando problema, objetivos, restrições, stakeholders, riscos e decisões são explicitados, a engenharia consegue comparar alternativas com maior qualidade e o Business Case passa a responder a uma necessidade real, não a justificar retrospectivamente uma preferência.

Em Capital Projects, essa etapa reduz o risco de carregar ambiguidade para FEL, FEED, procurement e execução. O custo de descobrir tarde que o problema estava mal formulado é muito superior ao custo de investir cedo em definição. Por isso, o framing deve produzir uma base rastreável: o que sabemos, o que assumimos, o que precisamos descobrir, quem decide e qual evidência é necessária para avançar.

A pergunta de fechamento não é “qual solução vamos executar?”. É: o problema está definido de maneira suficientemente clara para que alternativas de engenharia possam ser avaliadas sem viés e para que a próxima decisão de investimento seja tomada sobre evidências?

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] INFRASTRUCTURE AND PROJECTS AUTHORITY. Overview of the Project Set Up Toolkit. Londres: UK Government, 2022. Disponível em: https://www.gov.uk/government/publications/project-set-up-toolkit/overview-of-the-project-set-up-toolkit

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

Perguntas frequentes

O que é Project Framing?

Project Framing é o processo de estruturar o problema, a oportunidade, os objetivos, as restrições, os stakeholders, as premissas, os riscos e as decisões de um projeto antes de selecionar e detalhar a solução de engenharia.

Project Framing é igual a FEL?

Não. O framing enquadra o problema e estabelece a base de decisão. O FEL desenvolve progressivamente alternativas, viabilidade, definição técnica, estimativas, riscos e maturidade do empreendimento antes de compromissos maiores de capital.

Qual a diferença entre Project Framing e Business Case?

O framing define o problema e o que caracteriza sucesso. O Business Case utiliza essa base para justificar se o investimento deve ser realizado, comparando alternativas, benefícios, custos, riscos e capacidade de entrega.

Project Framing precisa de workshop?

Não obrigatoriamente. O workshop é uma forma eficiente de alinhar stakeholders e tornar divergências visíveis, mas o processo pode combinar análise documental, entrevistas, levantamentos e sessões estruturadas conforme a complexidade do empreendimento.

Quais documentos devem sair do framing?

Tipicamente: problem statement, current state, target state, critérios de sucesso, stakeholders, restrições, premissas, dependências, riscos iniciais, information gaps e decision roadmap.

Quando contratar apoio especializado?

Quando a decisão possui CAPEX relevante, múltiplas disciplinas, condição existente incerta, conflitos entre stakeholders, alternativas tecnológicas relevantes ou necessidade de evidência formal para gates e aprovação de investimento.

Materiais técnicos complementares

Serviços relacionados

• Estudo de Viabilidade Técnica e Econômica
• Due Diligence Técnica de Engenharia
• FEL — Front-End Loading
• Gerenciamento de Riscos de Engenharia

Conteúdos principais sobre o tema

• Capital Projects & Infrastructure — HUB
• Capital Project Lifecycle: da oportunidade ao ativo operacional
• 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

• Estudo de Viabilidade em Engenharia
• Análise Multicritério em Projetos de Engenharia
• Análise de Riscos em Projetos de Engenharia
• Gestão de Benefícios em Projetos e Programas
• PDRI — Project Definition Rating Index
• FEED em Engenharia
• Guia Completo sobre Engenharia Consultiva
• Guia de Gerenciamento de Projetos