Resistência à mudança no projeto: o que está por trás e como conduzir

O sistema entrou no ar há três semanas. Os indicadores de acesso mostram que as pessoas fazem login. Mas a coordenadora de compras ainda manda, toda manhã, a mesma planilha de antes por e-mail, e a equipe dela registra os pedidos nos dois lugares. Quando você pergunta, ouve: "É só por segurança, até o sistema estabilizar".

Ninguém se recusou abertamente. Ninguém fez uma reclamação formal. E, mesmo assim, o projeto não está entregando o que prometeu, porque a mudança não aconteceu de fato.

Esse é o formato mais comum de resistência: não é um "não", é um "sim, mas depois". E por ser silenciosa, ela costuma ser percebida tarde.

Uma entrega que ninguém usa não é uma entrega

Projetos existem para gerar uma mudança: um processo mais rápido, uma decisão mais bem informada, um custo menor. Se as pessoas continuam trabalhando como antes, o projeto entregou um produto, mas não entregou o benefício. Para o sponsor, a diferença é enorme.

O custo de deixar a resistência correr solta aparece em camadas. Primeiro, retrabalho, com dados registrados em dois lugares. Depois, inconsistência, quando as duas fontes começam a divergir. Por último, descrédito: a área passa a dizer que o sistema "não funciona", e a narrativa contamina outras áreas antes mesmo de elas começarem a usar.

O que as pessoas protegem quando resistem

Resistência à mudança em projetos raramente é contra a mudança em si. É a favor de alguma coisa que a pessoa tem medo de perder.

Pode ser competência. A coordenadora de compras domina a planilha antiga há anos e resolve qualquer exceção em minutos. No sistema novo, ela volta a ser iniciante, e isso é desconfortável para quem é referência na área. A planilha paralela preserva a sensação de controle.

Pode ser autonomia. Processos novos costumam trazer regras mais rígidas, aprovações a mais, menos espaço para o jeitinho que resolvia casos urgentes. Quem perde flexibilidade sente que perdeu poder.

Pode ser carga. Durante a transição, a área faz o trabalho de sempre e ainda aprende o sistema novo. Se ninguém reduziu a demanda nesse período, a resistência é, em parte, sobrevivência.

Pode ser desconfiança acumulada. Se a empresa já lançou outras iniciativas que foram abandonadas, as pessoas aprendem a esperar para ver. Investir esforço em algo que pode ser descontinuado parece desperdício.

E pode ser um problema real. Às vezes o sistema não trata uma exceção importante, ou deixou um processo mais lento. A pessoa que resiste está, na prática, avisando que algo foi mal desenhado.

A parte do projeto nisso também conta. Se as áreas afetadas não participaram do desenho, receberam treinamento genérico na última semana e souberam do go-live por e-mail, a resistência é uma reação previsível a uma mudança feita sobre elas, e não com elas.

Forçar ou ceder: os dois caminhos que dão errado

O primeiro reflexo é impor. Desligar a planilha antiga, mandar comunicado da diretoria, cobrar uso em reunião. Às vezes isso é necessário, mas feito como primeira ação, empurra a resistência para o subterrâneo. As pessoas usam o sistema do jeito mínimo, registram dados incompletos e esperam o momento de provar que não funcionava.

O segundo reflexo é ceder. Aceitar que a área use o sistema "do jeito dela", manter o processo paralelo indefinidamente, adiar o desligamento do legado. O projeto fecha formalmente, mas o benefício nunca chega.

Há um terceiro erro, mais sutil: tratar toda objeção como resistência. Quando o GP rotula qualquer crítica como "falta de vontade de mudar", deixa de ouvir os problemas legítimos e confirma para a área que ninguém está prestando atenção.

Como conduzir a adoção, passo a passo

Comece separando as pessoas. Resistência não é um bloco único. Um mapa de stakeholders com as áreas afetadas, o que cada uma ganha e perde e quanta influência tem sobre as outras mostra onde concentrar energia.

Depois, converse com quem resiste antes de tentar convencer. A pergunta útil não é "por que você não está usando?", mas "o que ficou mais difícil para você com o sistema novo?". Ela legitima a experiência da pessoa e traz informação concreta.

Com as respostas, as ramificações ficam claras. Se a objeção é um problema real do sistema, registre, priorize a correção e devolva o andamento para a área; poucas coisas reduzem tanto a resistência quanto ver uma reclamação resolvida. Se o motivo é insegurança com a ferramenta, ofereça apoio próximo, não treinamento genérico: alguém da própria área que já domine o sistema, disponível nas primeiras semanas. Se o motivo é carga, negocie com o gerente funcional uma redução temporária de demanda durante a transição.

Se for perda de autonomia ou de status, procure dar à pessoa um papel na mudança. A coordenadora que domina as exceções pode ser quem ajuda a configurar as regras do sistema novo. Ela deixa de ser a guardiã do processo antigo e passa a ser a referência do novo.

Se nada disso funcionar e a resistência estiver ameaçando o resultado, o tema sobe. Leve ao sponsor o impacto concreto e a proposta, como uma data para desligar o processo paralelo, combinada com o líder da área. Antes, avise o líder de que vai fazer isso. Construir esse apoio com antecedência é parte do trabalho descrito em como construir aliados no projeto.

O que dizer para quem está resistindo

"Não quero te convencer de nada agora. Quero entender o que ficou mais difícil para você com o sistema novo."

"Você conhece as exceções desse processo melhor do que qualquer um. Me ajuda a fazer o sistema tratar essas exceções direito?"

"Sei que você está fazendo o trabalho em dobro. Vamos combinar uma data para desligar a planilha e, até lá, o que eu posso tirar da sua frente?"

"Se tiver alguma coisa que o sistema faz pior do que antes, eu preciso saber. Não é crítica, é informação que eu não tenho."

Indícios de que a adoção está avançando

A natureza das reclamações muda. No começo, são genéricas ("o sistema é ruim", "é muito lento"). Quando a adoção avança, ficam específicas ("o filtro por fornecedor não traz os inativos"). Reclamação específica é sinal de uso real.

Pessoas da área começam a ajudar umas às outras sem chamar o projeto. O processo paralelo é usado com menos frequência, e alguém pergunta quando ele vai ser desligado. Os líderes de área passam a falar do sistema como "nosso", e não como "do projeto".

Sinais de alerta: aumento de registros incompletos, pedidos de exceção mais frequentes a cada semana, ou uma área que para de reclamar de repente. Silêncio total depois de muitas críticas pode significar que as pessoas desistiram de ser ouvidas. Se a resistência vem de um especialista que domina a operação e trata o projeto como interferência, o cenário tem nuances próprias, tratadas em quando o especialista técnico ignora o gerente de projetos.

A planilha da coordenadora

Exemplo ilustrativo (situação fictícia): Marcos era GP da implantação de um sistema de compras em uma rede de varejo. Três semanas depois do go-live, a coordenadora Sandra e sua equipe ainda mantinham a planilha antiga em paralelo. O diretor queria desligar a planilha por decreto.

Marcos pediu uma semana antes disso. Sentou com Sandra e perguntou o que tinha ficado mais difícil. Ela listou quatro situações em que o sistema travava: compras emergenciais, fornecedores com cadastro pendente, pedidos parcelados e devoluções. Em três delas, Sandra tinha razão.

Marcos levou as três correções para a equipe técnica e convidou Sandra para validar as regras antes de irem para produção. Disse a ela: "Você vai ser a pessoa que diz se ficou bom. Se não ficar, não sobe". A quarta situação, devoluções, era uma questão de treinamento, e Sandra mesma passou a explicar para a equipe.

Algumas semanas depois, foi a própria Sandra quem propôs a data para desligar a planilha. O diretor teve o que queria, e a área sentiu que a decisão era dela.

Mudança é trabalho de liderança, não de comunicação

Muitos projetos tratam gestão da mudança como um pacote de e-mails, cartazes e treinamentos na véspera do go-live. Isso ajuda, mas não muda comportamento. O que muda comportamento é as pessoas sentirem que foram ouvidas, que o problema delas foi levado a sério e que ganharam algo com a mudança.

O GP que olha um nível acima entende que o projeto não termina na entrega, termina na adoção. E que medir sucesso só pelo go-live é aceitar o risco de entregar algo sem valor percebido. Para entender o quadro mais amplo das forças que movem as pessoas, vale ler o artigo pilar sobre comportamento humano em projetos.

Checklist para conduzir a adoção

• Mapeei as áreas afetadas, o que cada uma ganha e perde e sua influência.
• Conversei individualmente com quem mais resiste antes de tentar convencer.
• Separei objeções legítimas de insegurança, carga ou perda de autonomia.
• Problemas reais do sistema estão registrados e com retorno para a área.
• Existe apoio próximo nas primeiras semanas, de preferência da própria área.
• Combinei com o gestor da área alguma redução de carga durante a transição.
• Há uma data acordada para desligar o processo paralelo.
• O sponsor sabe dos riscos de adoção antes que virem crise.

Esta semana, uma conversa

Escolha a pessoa ou área que mais resiste à entrega do seu projeto e marque uma conversa curta, sem pauta de convencimento. Leve só uma pergunta: o que ficou mais difícil para você? Anote tudo e devolva, em até uma semana, o que será feito com cada ponto.

Para organizar quem está a favor, quem resiste e por quê, use o modelo de matriz de stakeholders. Ele ajuda a enxergar onde a adoção vai travar antes que trave.