Esta é a segunda newsletter de uma série de três, sobre os aspectos fundamentais para uma melhor previsibilidade de Capex em projetos de Capital e Infraestrutura. Caso você tenha perdido a primeira, vale a pena conferir aqui para não perder o fio da meada.
Hoje, vamos falar sobre a fase de FEL 2, ou de Definição do Escopo, e as falhas mais comuns que ocorrem nesta etapa em relação à estimativa de Capex.
FEL 2: O “Produto” – Falta de estudos que identifiquem corretamente o escopo
Com a viabilidade aprovada no FEL 1, o projeto entra no desenvolvimento técnico e a liderança migra da área de Negócios para a de Projetos/Engenharia. É iniciada a Engenharia Conceitual, que estudará alternativas para chegar no escopo mais adequado.
Ao final dessa fase, as informações técnicas são significativamente superiores às da etapa anterior – já temos um escopo traduzido em Engenharia (Conceitual). No entanto, muitas organizações ainda subvalorizam esse trabalho de transformação de um objetivo de negócio em escopo técnico, dando pouca importância para essa fase.
Os problemas mais frequentes nesta etapa são:
- Indefinições de Negócio: mudanças de premissas e direcionadores levam a uma solução conceitual diferente da referência do FEL 1. Quando isso ocorre, as estimativas deixam de ser comparáveis; o “aumento” pode ser, na verdade, uma troca de solução.
- Escopo incompleto (especialmente Outside Battery Limits ou OSBL): a atenção está no ‘coração’ do processo e nos grandes equipamentos, mas o agregado de infraestrutura do site, acessos, utilidades, áreas administrativas, remoções/interferências e apoios operacionais pode representar uma parcela relevante do Capex. Quando OSBL (Outside Battery Limits) entra tarde, o Capex ‘salta’.
- Falha no entendimento da Classe de Estimativa: aqui, lidamos com uma estimativa Classe 4 (segundo a AACE), ou seja, que pode variar de -30% a +50% do valor estimado (incluindo contingência). Mais uma vez, o ‘número’ resultante da estimativa não pode ser tratado como algo exato, e o Business Case precisa ser robusto o suficiente para absorver essas diferenças, porque elas irão ocorrer (em algum grau).
- Contingência subdimensionada: por pressão de viabilidade, a contingência tende a ser “discreta” e nem sempre coerente com o risco e a maturidade. O resultado é previsível: os ajustes de Capex são empurrados para fases posteriores (mas quem arrisca apresentar para os Executivos um valor mais realista?).
- Stakeholders e requisitos tardios: áreas não envolvidas trazem requisitos após a definição, e isso vira (a famosa e tão frequente) mudança de escopo. Uma governança fraca permite que preferências individuais prevaleçam sobre a função técnica. O correto é representar a função ou a área e não o “CPF”.
- Gate fraco no fim do FEL 2: sem critérios mínimos verificados (escopo formal, premissas consolidadas, interfaces tratadas), o projeto avança ‘parecendo definido’, mas carregando lacunas que se materializam no FEL 3.
O alvo móvel e a falha na formalização
A maior ameaça no FEL 2 não é a falta de detalhamento, mas a falha na amplitude do estudo e na formalização. Quantos de vocês possuem uma Declaração de Escopo completa e assinada ao final do conceitual? Sem isso, o baseline vira interpretação.
“É mais fácil definir o alvo depois de atirar a flecha, não é mesmo?” — Fred McCarthy
Os ritos formais são essenciais para prevenir mudanças tardias. Em uma época onde é mais “interessante” falar de IA do que fazer o trabalho árduo de documentação, negligenciamos os fundamentos de uma boa gestão de projetos.
A partir da aprovação no Gate 2, toda alteração de escopo deve passar por um rigoroso processo de avaliação, e a manutenção da solução definida deve ser a prioridade. Um dos fatores que mais incentiva as mudanças tardias é o costume (e falha na Governança) de deixar tudo para se resolver depois. É criada uma cultura de que “não adianta definir agora, porque depois vai mudar mesmo”.
Uma situação inusitada (e reveladora)
Certa vez, em reunião com uma equipe, questionei por que a Declaração de Escopo era prevista apenas no FEL 3. Me disseram que também não concordavam e me recomendaram agendar uma reunião com o Gerente de Engenharia.
Feito isso, pensei: “Com o apoio dele, vamos poder sugerir a mudança da Declaração de Escopo para o FEL 2, afinal, é a fase onde o escopo é definido, e esse é um dos principais documentos da etapa!”.
Começamos a reunião, comentei o objetivo (reavaliar a fase para a emissão da primeira Declaração de Escopo do Projeto – mas ainda não disse qual), e ele prontamente respondeu:
— “É isso! Eu sempre falei que a Declaração de Escopo deve ser emitida ao final da Engenharia Detalhada!”
Eu quase caí de costas. Era o oposto da boa prática e da minha sugestão. Argumentei que a declaração é um produto de FEL 2, ao que ele respondeu prontamente:
— “Eu não assino Declaração de Escopo no FEL 2. Depois vão me cobrar que eu entregue aquilo que foi assinado!”
Será que precisamos dizer que é para isso mesmo que serve a formalização das decisões e definições?
Com essa reflexão sobre o FEL 2, encerramos a segunda parte. Na próxima e última edição, falaremos sobre a etapa de Planejamento da Execução – FEL 3.
📌 Nos comentários, me diga: Qual foi o maior “custo oculto” que já apareceu no seu projeto devido à falta de estudos no FEL 2 (especialmente em OSBL, requisitos ou interfaces)?
Se quiser aprofundar com frameworks e exemplos práticos, continuo essa discussão também no Grupo VIP do WhatsApp. Para entrar, é só clicar aqui.
Ah, e se você quer entender melhor as boas práticas através de um estudo de caso com aplicação de FEL 1, 2 e 3 de um megaprojeto bastante emblemático, acesse agora o primeiro episódio do ChomaFlix: Eurotúnel. Será uma forma leve de absorver o que temos discutido por aqui!
Vamos juntos elevar a maturidade dos projetos.
Até a próxima News!
