Se você chegou até aqui, provavelmente já viveu a experiência de explicar para o board por que um projeto de BI ou engenharia de dados não entregou o que prometia. Talvez o projeto tenha sido cancelado no meio. Talvez tenha sido entregue, mas nunca usado. Ou tenha consumido orçamento e tempo sem transformar nada na operação.
Seja qual for o formato, a sensação é parecida: uma mistura de frustração, constrangimento e uma pergunta que não sai da cabeça. Onde foi que errou?
A primeira coisa que precisa ser dita é que esse não é um problema seu. Estudos do setor apontam que mais de 60% dos projetos de dados falham na primeira tentativa. Não por incompetência de quem conduziu. Mas porque projetos de dados têm características que tornam a execução genuinamente difícil: dependência de dados que nem sempre estão onde deveriam estar, escopo que evolui ao longo da descoberta, e uma cadeia de dependências entre times que costuma ser subestimada no planejamento.
As 5 causas mais comuns de falha em projetos de dados
Antes de retomar qualquer coisa, é preciso entender o que aconteceu. Não para distribuir culpa, mas para não repetir o mesmo padrão. Aqui estão as cinco causas que aparecem com mais frequência:
Escopo mal definido desde o início
É a causa mais comum e a mais difícil de perceber enquanto acontece. O projeto começa com um objetivo genérico como “ter mais visibilidade sobre os dados da operação” ou “construir um data warehouse”. Parece suficiente. Mas quando chega o momento de entregar, ninguém consegue dizer com clareza se o que foi feito corresponde ao que era esperado, porque nunca houve critério de aceite definido.
Sem um entregável concreto e verificável, qualquer coisa pode ser entregue. E qualquer coisa pode ser contestada. O resultado é um projeto que encerra no papel mas não gera adoção real.
Time errado para o projeto
Não basta contratar uma boa consultoria. É preciso contratar a consultoria certa para o seu contexto. Uma empresa com histórico forte em varejo pode não ter o domínio necessário para projetos no setor financeiro. Uma consultoria experiente com empresas grandes pode ter dificuldades com a velocidade e as restrições de uma empresa em crescimento.
Dependência de dados que a empresa não conseguiu fornecer
Projetos de dados dependem de dados. Parece óbvio, mas a maioria das empresas subestima o trabalho necessário para tornar esses dados acessíveis. Sistemas legados com estruturas não documentadas, integrações que nunca foram feitas, times de TI com capacidade insuficiente para suportar a demanda no prazo.
Falta de patrocínio executivo real
Existe uma diferença entre aprovar um projeto e patrocinar um projeto. Aprovar é assinar a ordem de compra. Patrocinar é participar ativamente, remover bloqueios quando eles aparecem, e garantir que outros times priorizem as demandas que o projeto precisa.
Muitos projetos de dados morrem não porque a tecnologia falhou, mas porque o diretor que aprovou o budget nunca mais apareceu. Quando a consultoria precisava de acesso a um sistema, a solicitação ficava parada. Quando precisava de tempo do time de negócio para validar uma lógica, ninguém estava disponível.
Mudança de prioridade sem replanejamento
O negócio muda. Isso é inevitável e, na maioria das vezes, saudável. O problema acontece quando a prioridade do projeto muda mas ninguém para para replanejar o escopo, o cronograma e os recursos. O projeto continua sendo executado segundo o plano original, mas o contexto que justificava aquele plano já não existe mais.
Como conduzir um post-mortem honesto
Antes de apresentar qualquer plano de retomada ao board, você precisa ter clareza sobre o que aconteceu. E isso requer um post-mortem honesto, não defensivo.
O objetivo do post-mortem não é encontrar um culpado. É documentar, com objetividade, quais fatores contribuíram para o resultado. Isso inclui fatores internos que estavam sob seu controle, e fatores externos que não estavam.
Comece respondendo a quatro perguntas:
O que foi definido como sucesso no início do projeto? Se não havia definição clara, isso já é um achado importante. Significa que o projeto começou sem critério de avaliação.
Quais foram os principais pontos de atrito durante a execução? Atrasos na entrega de dados, conflitos de escopo, mudança de time, falta de alinhamento com stakeholders. Liste tudo sem filtro.
Em que momento o projeto começou a perder tração? Geralmente existe um evento ou uma semana específica em que as coisas começaram a desandar. Identificar esse ponto ajuda a entender qual causa foi predominante.
O que foi entregue e por que não foi adotado? Se o projeto chegou ao fim mas não foi usado, o problema provavelmente está na fase de descoberta, não na fase de execução.
Com essas respostas em mãos, você consegue ter uma conversa muito mais produtiva com o board. Não uma conversa de defesa, mas de diagnóstico.
O que fazer diferente na retomada
Retomar um projeto de dados não é recomeçar do zero. É reconstruir com mais rigor, aproveitando o aprendizado da tentativa anterior. Aqui está o que precisa ser diferente:
Comece pelo critério de aceite, não pelo escopo. Antes de definir o que vai ser construído, defina como você vai saber se o projeto foi bem-sucedido. Qual métrica vai se mover? Em quanto tempo? Quem vai validar? Isso parece simples, mas muda completamente a dinâmica do projeto.
Escolha o fornecedor pela execução, não pela apresentação. Na nova rodada de propostas, peça para conhecer o time que vai trabalhar no projeto antes de assinar. Peça referências verificáveis de clientes em contexto parecido com o seu. Avalie a metodologia semana a semana, não só o que será entregue ao final. Você pode usar um framework de avaliação objetivo para comparar fornecedores com mais rigor, como o que detalhamos neste guia de critérios para escolher uma consultoria de dados.
- Mapeie a disponibilidade dos dados antes de assinar o contrato.
- Defina quem vai patrocinar o projeto e o que isso significa na prática.
- Construa um mecanismo de gestão de mudança desde o início.
Como apresentar a retomada ao board
Essa é a parte que mais intimida. Você já pediu orçamento uma vez, o projeto não entregou, e agora precisa pedir de novo. É natural sentir que a credibilidade está em jogo.
A boa notícia é que boards experientes entendem que projetos complexos falham. O que eles não toleram é a falta de aprendizado. Se você chegar com diagnóstico claro, plano estruturado e mecanismos de controle que não existiam antes, você está demonstrando exatamente o que um board quer ver: maturidade para transformar fracasso em aprendizado.
Estruture sua apresentação em quatro blocos:
- O que aconteceu e por quê.
- O que mudou.
- O que será entregue e como saberemos.
- O custo e o retorno esperado. Seja conservador nas projeções. Um board que já viu um projeto falhar vai desconfiar de promessas otimistas. Apresente o retorno esperado com base em benchmarks do setor ou em hipóteses verificáveis, não em extrapolações. Se precisar de referências externas para embasar os números, o MIT Sloan Management Review publica regularmente pesquisas sobre ROI em projetos de dados que podem ser úteis nessa argumentação.
A segunda tentativa começa antes da aprovação
Uma das armadilhas mais comuns na retomada de projetos de dados é esperar a aprovação do board para começar a trabalhar. O período entre a decisão de retomar e a aprovação formal é um tempo valioso que pode ser usado para preparar o terreno.
Faça o inventário de dados internamente. Mapeie os stakeholders que vão precisar se envolver. Faça conversas exploratórias com dois ou três fornecedores para entender o que é viável dentro do orçamento que você vai propor. Documente o aprendizado da primeira tentativa de forma estruturada.
Quando a aprovação vier, o projeto não vai começar do zero. Vai começar com meses de trabalho preparatório já feitos.
Se quiser entender como estruturamos esse processo de diagnóstico e retomada com clientes que já passaram por experiências parecidas, você pode conhecer como a beAnalytic conduz projetos de dados do diagnóstico à entrega.
Gabriela Melo é estrategista de conteúdo na beAnalytic, especializada em SEO e GEO. Com foco na criação de conteúdos otimizados para posicionar temas de Business Intelligence e Engenharia de Dados.
- Gabriela Melo
- Gabriela Melo
- Gabriela Melo
- Gabriela Melo
