Como este tema funciona na sua empresa
Risco de elefante é menor (não tem escala para isso). Desafio é tentar fazer tudo com poucos recursos, deixando iniciativa sem momentum. Recomendação: máximo 1-2 projetos paralelo, escopo bem controlado, timeline máximo 12 meses.
Risco de elefante é alto. Tem escala para grande projeto (30-50 pessoas), não tem agilidade de grande corporação. Desafio é que "quebrar em pequenos" parece ineficiente. Recomendação: máximo 12 meses e 30 pessoas por projeto.
Experiência com grandes projetos, mas ainda há risco. Estrutura de PMO ajuda, mas não é garantia. Desafio é política organizacional (quando projeto fica grande, mais stakeholders, mais conflito). Recomendação: gates periódicos (trimestral), mudanças de scope requerem aprovação formal.
Projeto elefante é projeto de transformação digital tão grande, tão complexo, tão longo que enfrenta múltiplos riscos: scope creep (escopo fica cada vez maior), perda de foco (prioridades mudam), fadiga (equipe cansa), perda de patrocínio (executivo saiu), mudanças tecnológicas (ficou obsoleto). A estratégia é evitar desde o início, ou quebrar grandes projetos em sequências de projetos menores[1].
Por que grandes projetos de transformação digital falham
A pergunta crítica não é "por que meu projeto ficou grande" mas "por que grandes projetos frequentemente falham"?
Scope creep: Projeto começa com escopo X. Conforme vai andando, aparecem necessidades novas. "Enquanto estamos transformando vendas, vamos transformar operações também". Escopo fica 2x maior do que foi planejado. Timeline e orçamento não acompanham.
Prioridades mudam: Coisa que era crítica quando projeto foi aprovado (12 meses atrás) já não é. Mercado mudou, estratégia mudou, executivo que iniciou projeto saiu. Novo executivo quer redireção. Projeto já investiu, agora é sunk cost fallacy ("já gastamos, vamos terminar"), mesmo que direção tenha mudado.
Mudanças tecnológicas: Arquitetura foi decidida há 18 meses. Agora, 6 meses depois, tecnologia nova aparece que é melhor. Mas projeto já está comprometido com arquitetura antiga. Ao final do dia, sistema é "yesterday's best practice".
Fadiga de equipe: Projeto grande demanda. Pessoas trabalham em intensidade alta por meses. Passado 1-2 anos, fadiga acumula. Qualidade de trabalho cai. Atrasos aumentam. As melhores pessoas saem (porque conseguem emprego em lugar menos caótico).
Perda de momentum: Projeto começa energético ("vamos transformar a empresa!"). Passa 12 meses, ainda não viu resultado visível. Momentum cai. Pessoas questionam se está dando certo. Patrocínio enfraquece. Novo executivo quer outras prioridades.
Complexidade organizacional: Projeto grande envolve muita gente. Muita gente = muitos stakeholders = muitos interesses. Alguém sempre está insatisfeito. Decisões viram politicamente carregadas. Velocidade de decisão cai[2].
Risco de projeto elefante é menor pelo orçamento limitado, mas existe quando empresa tenta copiar transformação de grande empresa. Manter escopo proporcional ao tamanho — entregas em semanas, não meses.
Risco alto: orçamento suficiente para começar grande, mas insuficiente para sustentar. Dividir em fases de 8-12 semanas com entrega tangível em cada uma. Cancelar fase é menos doloroso que cancelar projeto inteiro.
Risco máximo: projetos de milhões que levam anos e entregam pouco. Governança com gates de decisão, métricas de progresso reais (não apenas marcos administrativos), e coragem para pivotar ou cancelar.
Sinais de alerta: seu projeto está virando elefante?
Não é sempre óbvio quando projeto está ficando elefante. Alguns sinais:
Timeline expandindo: Projeto foi planejado para 18 meses, agora está em 24. Não foi porque você foi rápido e adicionou scope—foi porque tudo ficou mais lento do que esperado. Fila de decisões. Espera por terceiros. Problemas técnicos que tomam mais tempo que previsto.
Equipe crescendo: Começou com 10 pessoas. Agora tem 25. Não foi porque descobriu nova oportunidade importante—foi porque cada problema adicionava mais pessoa. Alguém para integração, alguém para dados, alguém para compliance, etc.
Escopo mudando frequentemente: Cada reunião de steering committee tem "também vamos fazer X". Escopo não reduz, só aumenta. Ninguém diz "vamos descontinuar Y para caber Z".
Atrasos acumulados: Primeira fase atrasou 2 semanas. Segunda atrasou 3. Terceira atrasou 4. Velocidade não está melhorando. Síndrome: projeto está "90% pronto" há 3 meses.
Conflitos entre stakeholders: Grupo A quer uma coisa, grupo B quer outra. Conflito intrínseco, não é que alguém está errado. Exemplo: grupo de vendas quer implementação rápida (aceita que funcione bem depois), operações quer fazer certo primeiro (nem que demore).
Perda de patrocínio visível: CEO que iniciou projeto já não aparece em reuniões. Novo sponsor está menos envolvido. Orçamento que era "aberto" agora tem limite. Sinais de que entusiasmo diminuiu.
Saída de talentos chave: Pessoas melhores do projeto saem. Não porque foram desligadas, mas porque "procuraram emprego em lugar menos caótico". Red flag—se melhores pessoas estão saindo, cultura do projeto é ruim.
Estratégia: quebrar grande projeto em pequenos incrementos
A solução para projeto que está virando (ou já é) elefante é quebrar em pedaços menores.
Ao invés de "implementar ERP completo em 18 meses": Fazer "implementar módulo de vendas em 6 meses, depois operações em 6 meses, depois contabilidade em 6 meses". Cada incremento é um projeto completo em si mesmo (não deixa coisas "em aberto"). Cada entrega valor (módulo de vendas já funciona sozinho, mesmo que contabilidade ainda não esteja em produção).
Ao invés de "transformar customer experience em 2 anos": Fazer "implementar chat em 4 meses, depois analytics em 6 meses, depois mobile app em 6 meses". Cada incremento melhora experiência de cliente de forma incremental. Não precisa esperar 2 anos para ter valor.
Vantagens da abordagem incremental: Aprende rápido (finalizou módulo 1, sabe mais que antes, aplica aprendizado no módulo 2). Risco menor (se módulo 1 falha, investimento foi pequeno). Momentum (cada incremento é celebração). Capacidade de pivotar (se estratégia muda, pode descontinuar próximo incremento).
Como definir incrementos: Cada incremento tem objetivo de negócio claro (não é "fazer coisas de TI"). Cada incremento é completo em si mesmo (não deixa dependências não resolvidas). Sequência é pensada (qual ordem faz sentido de aprendizado e valor?). Timeline de cada incremento é 4-8 meses (não 12+).
Governança para evitar crescimento sem controle
Para que projeto não acumule scope indefinidamente, governance é essencial.
Gate reviews periódicos: A cada trimestre, projeto tem gate review. Pergunta: estamos no trilho (tempo, orçamento, escopo)? Se sim, continua. Se desviou, por que? Se não há explicação boa, redefinir projeto ou parar. Não é "vamos rever em 12 meses quando terminar".
Change control disciplinado: Qualquer mudança de escopo passa por processo formal (não é "ah, vamos adicionar isso rapidinho"). Mudança é avaliada: que impacto tem em timeline? Em orçamento? Em risco? Se impacto é alto, tem que haver aprovação formal, e possivelmente que se retire outra coisa para compensar.
Monitoramento de timeline: Atrasos de mais de 2 semanas disparam revisão. Não é "vamos ignorar e compensar depois". Atraso pequeno tratado rápido fica pequeno. Atraso ignorado vira grande.
Monitoramento de equipe: Rotatividade alta é sinal de problema. Se 20%+ da equipe sai em 3 meses, algo está errado (pressão alta, falta de clareza, gestão ruim). Endereçar antes de deteriorar mais.
Comunicação de progresso: Não espera steering committee mensal para comunicar atraso. Comunicação é contínua, transparente. Stakeholders sabem estado real, não surpresa no final.
Quando redefinir um projeto em andamento
Às vezes projeto já está grande demais. Como saber se está na hora de parar e redefinir?
Timeline deslocou 3+ meses: Reúna steering committee. Analisa: vai deslocar mais? Por que não conseguiu estimar certo na primeira vez? O que precisa mudar para conseguir terminar em timing razoável? Talvez redefinir em incrementos menores ajude.
Escopo mudou significativamente: Projeto original era X, agora é 1.5X. Reúna stakeholders. Pergunta: qual dessas coisas novas são absolutamente críticas? Qual pode ser fase 2? Talvez escopo do projeto 1 fica 0.9X (menos que original) e você cria projeto 2 para resto.
Patrocínio enfraqueceu: Sponsor original saiu ou mudou prioridade. Novo sponsor (se existe) está menos envolvido. Reúna novo sponsor. Pergunta: continua prioridade? Se sim, recomita (tempo, recursos). Se não tão prioritário quanto era, redimensiona projeto.
Equipe está desmotivada: Pesquisa de clima mostra que pessoal do projeto está insatisfeito. Pergunta: por que? Se resposta é "projeto é interminável", talvez redefinir em pedaços menores com datas de termino claras ajuda.
Tecnologia foi superada: Arquitetura que era best practice quando foi decidida agora ficou dated. Continuar com ela é perpetuar obsolescência. Talvez para projeto 1 e reavaliar abordagem. Ou já começa fase 2 com tecnologia nova.
Checklist: seu projeto está virando elefante?
Responda honestamente. 3+ "sim" significa projeto precisa ser redefinido.
- Timeline já deslocou 3+ meses desde aprovação.
- Escopo mudou significativamente desde que foi aprovado.
- Equipe cresceu em 50%+ desde início.
- Há conflitos organizacionais que atrasam decisões.
- Sponsor original já não está envolvido ou mudou prioridade.
- Pessoal do projeto está pedindo para sair ou reclamando constantemente.
- Não há visibilidade clara de quando projeto vai terminar.
- Tecnologia que foi escolhida já está em questão.
- Há múltiplas versões de "qual é o plano" entre stakeholders.
- Mudança de escopo é frequente e normalizada (todo mês tem coisa nova).
Caminhos para quebrar ou redefinir projeto grande
Redefinição pode ser feita internamente ou com ajuda externa.
Viável quando empresa tem PM expertise e capacidade de tomar decisão difícil.
- Processo: PMO reanalisa projeto, propõe redefinição, steering committee vota
- Tempo: 2-4 semanas para definir incrementos e plano de escala
- Desafio: Difícil politicamente (admitir que projeto está errado)
- Resultado: Série de projetos menores com timeline clara
Indicado para olho externo imparcial e expertise em desmembramento de projetos.
- Tipo: Consultoria de PMO, Consultoria de transformação
- Serviço: Assessment do projeto, proposta de redefinição, plano de transição
- Vantagem: Imparcialidade (não está envolvida politicamente)
- Resultado: Plano executivo de redefinição que steering committee pode apresentar
Seu projeto está começando a parecer um elefante?
Se você está em transformação digital e percebe que projeto está ficando maior/mais longo/mais complexo que esperado, o oHub conecta você a consultores de PMO especializados em redefinição de grandes projetos. Em menos de 3 minutos, descreva seu projeto e receba propostas de especialistas que sabem como quebrar projeto grande em incrementos bem-sucedidos.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe análise de sua situação.
Perguntas frequentes
A que ponto um projeto é "grande demais"?
Recomendação: se timeline é 18+ meses, equipe é 30+ pessoas, ou escopo é 3+ sistemas/processos principais, começou a ser risco. Médias empresas: máximo 12 meses e 20-30 pessoas. Grandes: máximo 18 meses e 50+ pessoas com estrutura PMO forte.
Quebrar projeto em pequenos não é mais lento?
Não. Ao contrário. Projeto grande tem ineficiências (wait times, complexidade política, mudanças de prioridade). Projetos menores são mais rápidos por unidade de trabalho. Sequência de 3 projetos de 6 meses termina mais rápido e com menos risco que 1 projeto de 18 meses.
Como convencer stakeholders que pequeno é melhor que grande?
Argumento principal é risco. "Projeto grande de 18 meses tem risco alto—tecnologia muda, prioridade muda, equipe sai. Sequência de 3 projetos de 6 meses tem risco menor—se primeiro falha, aprendeu antes de apostar tudo." Mostrar histórico de grandes projetos que falharam ajuda.
E se stakeholders insistem em "fazer tudo de uma vez"?
Pergunta: qual é a pressa? Se há razão de negócio (mercado vai embora, competidor vai chegar), talvez realmente precisa acelerar. Mas se é só inércia ("sempre planejamos assim"), pode negociar. Alternativa: primeiro incremento de 6 meses, então avalia se continua grande ou quebra mais.
Qual é o tamanho ideal de um projeto de transformação?
Recomendação: máximo 12 meses de duração, máximo 20-30 pessoas dedicadas. Se precisa de mais, quebra em 2-3 projetos. Se menos, às vezes é quick win, não projeto de transformação.
Como defino os incrementos de um projeto grande?
Cada incremento tem objetivo de negócio claro (não é "fazer trabalho de TI"). Sequência é pensada (qual ordem faz sentido?). Cada incremento é completo em si mesmo (não deixa dependências). Entre incrementos há janela pequena (1-2 semanas) para aprender e ajustar. Exemplo: ERP = módulo vendas (6m) + módulo operações (6m) + módulo contabilidade (6m).