Resumo: projeto de sistema raramente morre por defeito do software. Morre por automatizar o caos: mapeamento às pressas feito por quem vende, cadastro sujo migrado “para arrumar depois”, virada big bang e time conhecendo a ferramenta só no dia da virada. A McKinsey aponta, na sua literatura de gestão de mudança, que cerca de 70% dos programas de mudança organizacional não atingem as metas. As causas são gente e processo, não tecnologia.
O padrão da falha
Quase sempre este roteiro, nessa ordem:
- O mapeamento costuma ficar com quem vende. E aí o levantamento tende a seguir o que o produto já faz bem, porque é o que ele conhece. O processo real, com suas exceções, acaba ficando de fora.
- O cadastro sujo migra junto. “Depois arrumamos” é a frase que enterra projeto: o sistema novo nasce alimentado pelo erro velho.
- Virada big bang. Tudo muda no mesmo dia, numa data mágica. Qualquer tropeço vira crise geral, e sempre há tropeço.
- O time conhece o sistema no dia da virada. Treinamento de véspera não é adoção. A operação volta para a planilha paralela em duas semanas.
- O contrato termina na entrega. O escopo era a licença e as horas, e fazer rodar na operação não estava no papel de ninguém. Não é abandono: é o escopo que acabou.
Repare: em nenhum passo o software foi o vilão. O projeto falhou antes de o sistema ligar. E não é defeito moral de ninguém; é o lugar de cada um na mesa.
Por que isso se repete tanto
Porque os incentivos apontam para isso. Quem vende sistema ganha na venda, não na sua operação rodando. Então mapear rápido, prometer prazo curto e empurrar a virada é racional para ele. Ninguém aqui é vilão. Cada um está jogando o papel que tem: quem vende, vende; quem implanta uma marca, defende a marca dele. O que falta é alguém do seu lado, técnico e sem marca para defender, segurando a ordem certa das coisas.
O que fazer diferente no próximo
Inverter a ordem: processo antes de sistema, piloto antes de escala. É o método que a Syphra aplica em todo projeto, Entender, Melhorar, Validar, Automatizar. O detalhe que mais muda o jogo: validar com o time em uma frente pequena antes de escalar. Adoção testada no piloto não vira surpresa na virada.
E se o projeto travado ainda está aí
Então a decisão é sobre o vazamento futuro, não sobre o que já foi gasto. E nem sempre a resposta é trocar de sistema: boa parte dos projetos travados sofre de processo e adoção, e o software instalado ainda serve. O caminho para fazer diferente dessa vez está em escolher e implantar sem se queimar. Para saber o que aproveitar e o que refazer no seu caso, comece pelo diagnóstico.