Resposta direta: a decisão mais difícil que tomei como gestora de projetos não foi técnica — foi dizer não a um prazo que a diretoria já tinha comunicado, porque o risco real do projeto não estava onde todo mundo estava olhando.
O projeto era um programa de integração de marca depois de uma aquisição, dentro de uma operadora de telecom brasileira. Na superfície, parecia simples: trocar o logotipo em milhões de faturas e materiais de atendimento. Na prática, virou um programa inteiro de requisitos, com cinco frentes de canal de cliente rodando em paralelo — relacionamento, rede de revendas, atendimento, televendas e um programa de fidelidade. E o prazo que a liderança já tinha anunciado publicamente não sobrevivia ao primeiro mapeamento sério de dependências.
Principais aprendizados
- O risco real de um projeto raramente está onde a liderança está olhando primeiro.
- “Simples” é a palavra de quem ainda não mapeou as áreas impactadas.
- Dizer não a um prazo com dado na mão é uma decisão de gestão, não um atraso.
- A disciplina que salvou aquele programa de rebranding é a mesma que falta em muitos projetos de IA hoje.
- Mapear a cadeia de dependências antes de prometer uma data evita o pior tipo de atraso: o anunciado com confiança e revertido depois.
Qual foi a decisão mais difícil que tomei como gestora de projetos?
Foi recusar o prazo que a própria diretoria já tinha comunicado como certo, semanas depois de uma aquisição de alto perfil, quando a pressão por uma vitória rápida e visível era máxima. Cada frente do programa seguia um template simples no papel: requisito, áreas impactadas, sistemas envolvidos, critérios de aceite, pontos de atenção, riscos. Foi esse template — não a intuição — que revelou o problema.
Trocar a marca numa fatura de telecom regulada não é um trabalho de design. Arrasta obrigações perante a agência reguladora do setor (memorial descritivo formal, comunicação oficial em jornais, ajuste por região de concessão), obrigações fiscais (nota fiscal, livros contábeis) e uma cadeia inteira de sistemas de CRM que precisavam ser ajustados em sequência, não em paralelo. O risco não estava no design da nova marca. Estava na cadeia regulatória e fiscal que ninguém tinha desenhado ainda quando o prazo foi anunciado.
A decisão difícil não foi identificar isso — o mapeamento fez esse trabalho. Foi levar a notícia para cima, logo depois de uma aquisição em que todo mundo queria mostrar velocidade, e dizer que o prazo público estava errado. Não porque o time era lento. Porque a cadeia de aprovação regulatória tinha uma velocidade própria, que nenhuma reunião de status muda.
O prazo revisado foi aceito — não de imediato, mas depois de a diretoria conferir, requisito por requisito, que a lista de dependências era real e não uma desculpa de time atrasado. O programa entregou dentro do novo prazo, sem nenhum problema regulatório ou fiscal decorrente da troca de marca. O ganho não apareceu como manchete de resultado rápido; apareceu como ausência de incidente, que é o tipo de resultado mais difícil de reivindicar depois e mais fácil de esquecer quando as coisas dão certo.
Por que dizer não com dado na mão é mais difícil do que dizer sim
Dizer sim a um prazo apertado custa pouco no momento — o custo aparece depois, quando o projeto atrasa de qualquer forma, só que sem aviso e sem explicação estruturada. Dizer não custa imediatamente: expõe quem decide a ser visto como obstáculo, numa hora em que a organização inteira quer ouvir “sim, dá tempo”.
O que tornou essa decisão sustentável não foi coragem — foi o mapeamento completo, área por área, sistema por sistema, feito antes de qualquer reunião difícil. Um “não” apoiado em intuição perde a primeira discussão. Um “não” apoiado numa lista verificável de dependências muda a natureza da conversa: deixa de ser uma negociação de prazo e vira uma checagem de fatos que qualquer pessoa pode conferir.
Essa é a parte que mais se repete em mais de 30 anos de carreira em tecnologia, muito antes de qualquer projeto de inteligência artificial existir: o gestor que só aparece com boas notícias perde credibilidade mais rápido do que o gestor que aparece com más notícias bem documentadas.
O que isso ensina sobre priorizar projetos de IA na sua empresa
A maioria dos projetos de IA que viram problema começa exatamente do mesmo jeito: parecendo simples. Um assistente de atendimento, um copiloto interno, um agente que lê contrato — tudo isso soa como troca de logotipo. E, como a troca de logotipo, costuma arrastar uma cadeia que ninguém mapeou antes de prometer a data: adequação à LGPD, revisão de segurança da informação, contrato de fornecedor de modelo, integração com sistema legado que não foi feito para conversar com uma API de IA.
A lição prática não é “desconfie de prazo simples” — é ter, antes de qualquer data ser comunicada para cima, o mesmo tipo de mapeamento que aquele programa de rebranding tinha: requisito, área impactada, sistema, critério de aceite, risco. Isso é o que separa uma empresa que consegue aprovar orçamento de IA com critério de uma que descobre o risco regulatório ou de dados no meio da implementação, quando já é caro recuar.
E é também por isso que o papel de quem decide em projetos de IA não pode se limitar a aprovar ferramenta — precisa incluir a disposição de dizer não a um prazo que a própria liderança já anunciou, quando o mapeamento mostra que ele não é real. Isso vale tanto para uma operadora de telecom regulada em 2015 quanto para uma empresa de médio porte automatizando um processo com IA em 2026.
Na prática, isso significa tratar o cronograma de IA como uma consequência do mapeamento, não como um compromisso assumido antes dele. Antes de qualquer data ser prometida a um conselho ou a um cliente interno, vale a mesma pergunta que aquele template de rebranding fazia área por área: quem mais depende disso, o que precisa mudar em sistema legado, que aprovação externa esse projeto arrasta e quem assume o risco se o prazo otimista não se confirmar. Empresas que pulam essa etapa não eliminam o risco — apenas adiam a hora de descobri-lo, geralmente na pior hora possível, com o projeto já em produção.
Perguntas frequentes
Qual foi a decisão mais difícil que já tomei como gestora de projetos?
Foi recusar um prazo de integração de marca que a diretoria já tinha anunciado publicamente, logo após uma aquisição, porque o mapeamento de dependências mostrou que o risco real estava numa cadeia regulatória e fiscal que ninguém tinha considerado ao definir a data.
Por que um projeto “simples” pode esconder o maior risco de um programa?
Porque a palavra “simples” costuma vir de quem avaliou só a parte visível do trabalho — o design, a interface, a peça de comunicação — sem mapear as áreas, sistemas e obrigações regulatórias ou fiscais que esse projeto arrasta por trás.
Como aplicar essa lição em projetos de IA hoje?
Antes de comunicar qualquer prazo para cima, mapeie requisito por requisito: qual área é impactada, qual sistema participa, qual critério define “pronto” e qual risco de dado, segurança ou contrato existe. Isso transforma uma eventual recusa de prazo em fato verificável, não em opinião.
O que fazer quando a liderança já anunciou um prazo que não é viável?
Leve o mapeamento completo antes da conversa, não a intuição. Um prazo revisado apoiado em dependências reais e verificáveis muda a natureza da discussão — deixa de ser uma negociação de confiança e vira uma checagem de fatos.
Gillian Pellegrino é fundadora da HAIA e consultora executiva de IA aplicada, com mais de 30 anos de carreira em tecnologia — de programas de integração pós-aquisição em telecom a governança de IA para empresas de médio porte. Escrevo também, em primeira pessoa, sobre outra decisão de carreira que virou lição de governança de IA no meu blog pessoal. Se sua empresa está prometendo prazos de IA sem ter mapeado as dependências reais, o Diagnóstico Gratuito de Maturidade de IA da HAIA é o ponto de partida.
