Obra parada, aditivo e apontamento do TCU raramente são azar de execução — são falha de front-end. Quem sofre na obra herdou uma definição ruim que passou pelo portão. O FEL explica por que decidir cedo é barato e poderoso, e mudar tarde é caro e traumático.
Quando a obra pública trava, o reflexo é olhar para a execução: choveu demais, a empreiteira patinou, o fornecedor atrasou, a desapropriação emperrou. São causas reais — mas quase sempre são o sintoma, não a doença. O padrão que se repete em relatório de auditoria e em acórdão do TCU é outro, e é mais desconfortável: projeto básico deficiente aprovado no portão. Quantitativos furados, solução técnica indefinida, interferências não mapeadas, licença ambiental pendente. Tudo isso vira, meses depois, aditivo, retrabalho e paralisação.
A frase que resume o problema é dura: quem sofre na execução herdou uma definição ruim. A equipe de campo não criou o buraco — ela caiu num buraco cavado lá atrás, quando a decisão de investir foi tomada em cima de um projeto que ainda não estava pronto para sustentá-la. O Front-End Loading é a disciplina de carregar esforço na definição, antes de comprometer o dinheiro, exatamente para não pagar essa conta na frente.
FEL — Front-End Loading — é o modelo de stage-gate que a indústria de capital (óleo & gás, mineração, energia) usa para maturar um empreendimento em fases, cada uma fechada por um portão de decisão. Não é um cronograma; é uma sequência de go / no-go / hold antes do compromisso irreversível.
A tese do IPA (Independent Project Analysis, de Edward Merrow) nasce de milhares de projetos comparados e é quase uma lei física de gestão: quanto melhor a definição no front-end, mais previsível o custo e o prazo. Projetos que chegam ao portão de sanção com o front-end maduro erram menos a estimativa e paralisam menos. Os que forçam a passagem com definição frouxa pagam em desvio, aditivo e atraso — de forma tão sistemática que dá para medir e prever.
O instrumento clássico para pontuar essa maturidade é o PDRI (Project Definition Rating Index, do CII): um placar de definição que o portão consulta para responder uma pergunta binária — este projeto está definido o bastante para eu comprometer o dinheiro? O portão não é carimbo. É um freio: se a nota não fecha, o projeto volta para a fase anterior. É essa a diferença entre ter fases e ter disciplina de fase.
A boa notícia: a obra pública brasileira já tem o análogo do FEL. Estudos de viabilidade, anteprojeto, projeto básico e projeto executivo — a Lei 14.133/2021 (como a 8.666 antes dela) nomeia e sequencia essas etapas. O mapeamento é quase um a um:
| Fase FEL | Análogo na obra pública BR | O portão decide |
|---|---|---|
| FEL 1 | Estudos de viabilidade (EVTEA) | Vale a pena investir? |
| FEL 2 | Anteprojeto · seleção de alternativa | Qual solução seguir? |
| FEL 3 | Projeto básico (base da licitação) | Está definido para comprometer? |
| Execução | Projeto executivo + obra | Detalhar e construir o definido |
A má notícia: temos as fases no papel, mas raramente a disciplina do portão. O projeto básico é aprovado incompleto — porque o cronograma pressiona, porque o recurso orçamentário tem janela, porque "detalha-se depois no executivo". A licitação avança sobre uma definição imatura, e o vão entre o que foi definido e o que a obra exige aparece, inevitável, como aditivo. No FEL, o portão segura a passagem. Na prática brasileira, ele costuma apenas registrar a passagem. É a mesma escada — sem os corrimões.
Por que o portão importa tanto? Por causa de duas forças que caminham em sentidos opostos ao longo do projeto. No começo, sua capacidade de influenciar o resultado é quase total e o custo de uma mudança é quase zero: mexer numa linha de anteprojeto é apagar e redesenhar. No fim, é o inverso: a influência já se gastou e cada alteração é cara — porque exige refazer, remobilizar, renegociar e, muitas vezes, parar.
A engenharia de custos formaliza isso como escalada do custo de correção — a lógica 1 · 10 · 100: um erro corrigido cedo custa uma unidade; o mesmo erro corrigido tarde custa ordens de grandeza a mais. Traduzido para as fases da obra pública:
O aditivo não é um evento externo que "acontece" com a obra. Na maioria das vezes é uma decisão adiada — algo que caberia barato no front-end e foi empurrado para a frente, onde só existe a versão cara. Antecipar a decisão é o produto que o portão vende.
Aqui você move o cursor para onde o projeto está e lê as duas forças ao mesmo tempo: quanta influência ainda resta sobre o resultado e quanto custa, agora, uma mudança. Repare no ponto em que as curvas se cruzam — é a vizinhança do portão de sanção (fim do projeto básico). Antes dele, a governança é barata e poderosa. Depois, você está apenas administrando as consequências.
Um portão sério não pergunta "o projeto está pronto?" no geral — ele tem um checklist objetivo de aceitação, e só libera a passagem se cada item fecha. Numa obra de infraestrutura, os itens de front-end se dividem entre a engenharia (quantitativos, soluções, estimativa) e a dimensão de prazo e risco (o cronograma que sustenta a decisão). Esta é a face que o Getsimplan endereça — e o portão precisa das duas.
| O portão checa | Pergunta de aceitação | Getsimplan apoia |
|---|---|---|
| Baseline crível | A curva S prevista vem de uma linha de base real, reconferida? | Sim · prazo |
| Lógica de rede | A rede tem amarração lógica, sem restrições rígidas escondendo atraso? (DCMA 14) | Sim · prazo |
| Marcos contratuais | Os marcos do edital estão no cronograma e são atingíveis? | Sim · prazo |
| Riscos de prazo | Os riscos que ameaçam a data estão mapeados e refletidos na rede? | Parcial · risco |
| Contingência | Há folga dimensionada, coerente com a incerteza declarada? | Parcial · risco |
| Classe de estimativa | A estimativa de custo tem a classe (AACE) coerente com a decisão? | Não · custo/engenharia |
| Projeto básico completo | Quantitativos e soluções técnicas fechados, interferências mapeadas? | Não · custo/engenharia |
O portão de prazo tem um artefato central: o cronograma-baseline. No Getsimplan, a Curva S prevista é a própria baseline — e o app mede se ela é confiável antes de você comprometer a decisão em cima dela. Suba o arquivo e o painel responde à pergunta do portão na dimensão de tempo: o cronograma que sustenta esta decisão está maduro?
| O portão pergunta | Onde o app mostra | Manda você fazer |
|---|---|---|
| Baseline é crível? | Curva S · valores reconferidos | corrigir nós fora do oficial antes de aprovar |
| A rede tem lógica? | DCMA · 14 pontos | tratar links faltantes, restrições rígidas, folga |
| Os marcos fecham? | Prazo · tendência | reprogramar antes de assumir a data |
O Getsimplan mede a maturidade do cronograma que sustenta a decisão — não substitui o FEL nem a estimativa de custo. É a metade de prazo/risco do portão, feita com rigor.
Suba seu .mpp, .xer ou .xml e leia, na Curva S e no DCMA, se a baseline aguenta a decisão que você está prestes a tomar — antes de o portão virar aditivo.
Edward Merrow (IPA — Independent Project Analysis) — Industrial Megaprojects: definição de front-end ↔ previsibilidade de custo e prazo.
CII — Construction Industry Institute — PDRI (Project Definition Rating Index): o placar de definição consultado no portão.
AACE International — Recommended Practices: classes de estimativa (17R-97) e escalada do custo de correção (regra 1·10·100).
Capital Projects Podcast — André Choma (aprofundamento honesto sobre FEL e maturidade de projeto na realidade brasileira).
Brasil — Lei nº 14.133/2021 (anteprojeto, projeto básico e projeto executivo); acórdãos do TCU sobre projeto básico deficiente e aditivos contratuais.