Evitando projetos elefante em dados

Por que projetos de dados crescem e matam transformação

A jornada típica de um projeto elefante: começa com escopo simples ("vamos fazer BI para vendas em 6 meses"). Três meses depois, alguém diz "enquanto estamos nisso, operações quer análise de custos, e finance quer previsão de fluxo de caixa, e RH quer painel de pessoas". Escopo dobra. Cronograma não muda — promessas ficam iguais. Seis meses depois, primeira entrega ainda não está pronta, todos desapontados.

Culpados não são pessoas — são processos fracos. Sem mecanismo de dizer "não" a requisitos novos, toda necessidade legítima entra na cesta. Sem priorização clara, tudo vira "crítico". Sem faseamento, projeto fica "90% pronto" por anos^[2].

Impacto: equipe fica frustrada (prometem entregar, não conseguem). Liderança desiste ("BI não funciona aqui"). Investimento virou sunk cost. O que deveria dar retorno de R$ 500k virou despesa de R$ 2M sem resultado. E a culpa não é de tecnologia — é de escopo e gestão.

Sinais de alerta que seu projeto está virando elefante

Cinco sinais que aparecem semanas ou meses antes de projeto ficar completamente fora de controle. Quanto antes os identifica, mais fácil é corrigir.

1. Escopo crescente: Projeto começou com 3 áreas, agora tem 7. Documento de requisitos que era 10 páginas agora tem 50. Requisitos novos aparecem toda semana. Causa: sem mecanismo de dizer não, toda necessidade entra.
2. Datas movendo: Promessa inicial era dezembro. Depois virou março. Agora é agosto. Ninguém mais acredita em cronograma. Causa: cada atraso não reduz escopo (deveria reduzir) — só move data.
3. Stakeholders insatisfeitos: Comitê de liderança reclama de "falta de progresso". Usuários finais nunca veem nada pronto. Time de dados está desmotivado. Causa: expectativa vs. realidade ficou muito distante.
4. Atraso de dependências técnicas: Projeto espera decisão sobre arquitetura de 6 meses. Integração com sistema X fica presa em negociação. Dados que prometi ter não estão prontos. Causas: dependências não foram mapeadas no início.
5. Falta de entrega intermediária: Projeto levantou requisitos, desenhou solução, começou build. Mas nada saiu do forno ainda. Tudo é "ainda está sendo feito". Causa: não há checkpoints onde algo viável é liberado para usuários.

Matriz de risco: quando projeto é arriscado demais

Use esta matriz para avaliar se seu projeto tem risco aceitável. Projetos que combinam dimensões altas são perigosos.

Scoring: 3+ "Baixo risco" = projeto viável. 2-3 "Risco moderado" = manageable com governo forte. 3+ "Alto risco" = risco inaceitável — replanejar ou reduzir escopo.

Estratégia 1: Escopo fixo e comunicado desde o início

Defesa mais poderosa contra elefante é escopo cristalino: o que entra, o que não entra, por quê. Documento de escopo deve ter 1-2 páginas no máximo (se tem 50 páginas, é muito complexo).

Conteúdo de documento de escopo: (1) Problema a resolver (em 1 parágrafo). (2) Solução (em 1 parágrafo). (3) O que entra: áreas, dados, funcionalidades (em lista). (4) O que não entra: requisitos explicitamente descartados (em lista). (5) Por quê: justificativa de limites (em 2-3 linhas). (6) Cronograma (duração realista). (7) Aprovação: assinada por sponsor, dono, stakeholder principal.

Defesa contra scope creep: "Ótima ideia — manda para backlog de fase 2". Toda ideia nova (mesmo legítima) vai para backlog separado, não para o projeto atual. Revisão de backlog acontece em gate de conclusão: o que foi priorizado para próxima onda?

Estratégia 2: Entregas incrementais e marcos visíveis

Projeto que dura 12 meses sem nada pronto é elefante. Projeto que dura 12 meses mas entrega resultado novo a cada 2-3 semanas não é (mesmo que seja longo).

Estrutura de entregas: em vez de "projeto de BI em 12 meses", quebrar em 4-6 fases de 2-3 meses cada. Cada fase entrega algo viável aos usuários (painel, relatório, integração). Cada fase tem gate: "Este resultado justifica continuar investindo?"

Benefício psicológico é grande: usuários veem progresso mensalmente, não anualmente. Stakeholders veem resultado concreto, não promessas. Equipe tem ciclos curtos de sucesso, não anos de "ainda estamos construindo".

Estrutura de fases: Fase 1 (semanas 1-8): Setup e primeiro caso de uso (painel de vendas). Fase 2 (semanas 9-16): Segundo caso de uso (análise de custos). Fase 3 (semanas 17-24): Terceiro caso de uso + arquitetura. Resultado: 3 entregas viáveis, não 1 entrega depois de 24 semanas.

Estratégia 3: Limite de tamanho (máximo 12 meses, máximo 3 áreas, máximo 5 fontes)

Heurística prática para avaliar se projeto é "seguro" demais grande:

• Duração: Se projeto vai levar mais de 12 meses, quebrar em dois projetos menores. Maioria dos projetos de BI que excedem 12 meses fracassa — momentum cai, requisitos mudam, tecnologia muda.
• Número de áreas: Se projeto envolve mais de 3 áreas, chance de desalinhamento sobe exponencialmente. Sales, Finance, Operações é o máximo recomendado. Além disso, quebrar em projetos paralelos por área.
• Número de fontes de dados: Se projeto precisa integrar mais de 5 sistemas, complexidade técnica explode. Comece com 2-3, expanda depois. Cada fonte adicional é exponencialmente mais difícil.

Regra prática: se projeto tem 12+ meses E 4+ áreas E 6+ fontes, risco é muito alto. Replanejar. Se tem 2 dessas características, cuidado. Se tem só 1 ou nenhuma, é viável.

Estratégia 4: Governance leve e decisões rápidas

Projeto que leva 3 meses para tomar decisão é elefante. Projeto que tem processo de decisão rápido não é (mesmo que seja longo).

Estrutura de decisão: comitê pequeno (sponsor + 2-3 stakeholders), reunião semanal curta (30 min), agenda pré-definida, decisões documentadas, ações atribuídas. Isso é ágil o suficiente para mover rápido, formal o suficiente para liderança estar tranquila.

Defesa contra inércia: "Isso precisa de aprovação de X". Resposta: "Quem é X? Quando conseguimos conversa?" Nunca deixa decisão presa em limbo por semanas. Se vai demorar, agenda reunião, coloca no calendário, fecha em minutos.

Armadilha: comitê muito grande (10+ pessoas). Resultado: ninguém consegue falar, decisão leva 3 meses. Defesa: comitê max 5 pessoas (sponsor + 3-4 stakeholders principais). Outros consultam, não decidem.

O que fazer se projeto já está grande

Se você identificou que seu projeto virou (ou está virando) elefante, três opções viáveis:

1. Parar e replanejar (recomendado se < 50% feito): Pause projeto por 2-4 semanas. Revise escopo: o que é realmente crítico? Reduzir a 50% do original. Quebrar em duas ondas. Relançar com escopo menor e prazo mais curto. Sunk cost fallacy: o que foi gasto não volta — foco no futuro.
2. Pivotar para faseamento (recomendado se 50-75% feito): Projeto continua, mas de forma diferente. MVP sai em X semanas com escopo reduzido. Resto vira backlog de futuras fases. Muda narrativa: "Estou entregando algo real agora, não uma promessa".
3. Rescatar com novo liderança e estrutura (recomendado se > 75% feito ou projeto é crítico): Chamar gestor de projetos externo experiente em resgate. Fazer audit rápido (1-2 semanas). Implementar governance forte. Redefinir escopo. Colocar deadline firme. Comitê executivo de override das prioridades antigas.

Princípios universais: quando tudo é prioridade, nada é

Projeto elefante é sintoma de ausência de priorização. Quando liderança diz "tudo é importante", resultado é paralisia.

Princípio 1: "Começar pequeno, crescer metodicamente." Não existe "projeto perfeito e completo" no primeiro ano. Existe "primeira onda bem-sucedida" e "segunda onda" e "terceira onda". Cada onda leva aprendizado para a próxima.

Princípio 2: "Ambição é inimigo da entrega." Empresa que promete BI para toda organização em um projeto falha. Empresa que promete BI para sales, depois finance, depois operações, depois RH — escala bem.

Princípio 3: "MVP antes de produto." Não construa sistema perfeito. Construa sistema mínimo que resolve o problema. Usuários veem benefício em 8 semanas, não em 12 meses. Depois refina baseado em feedback real.

Princípio 4: "Decisão é melhor que perfeição." Quando em dúvida entre continuar refinando e lançar com 80% de perfeição, lance. Aprendizado real vem de usuários usando, não de comitê debatendo.