top of page

Gestão de mudanças na prática, com ADKAR model

Atualizado: 6 de fev.

Realizar a gestão de mudanças e gerenciar projetos sempre foi desafiador, entregar um produto dentro da restrição tripla (escopo, tempo e custo) e com qualidade, pode parecer até impossível. Mas por que mesmo quando entregamos um projeto de tecnologia dentro do escopo, tempo e custo, e nos moldes que foi solicitado o cliente não utiliza?

Alguns diriam, ahh mas isso é inaceitável, tecnicamente o projeto esta totalmente disponível e o cliente não faz adoção.

Vamos pegar como exemplo um projeto de implantação de um ERP, grandes fases de planejamento, construção do blueprint com muitas discussões durante a revisão de processos, e nas implementações o fornecedor faz o trabalho bem feito, da maneira que o produto (ERP) foi desenhado, aconteceram as fases de treinamentos dos usuário finais, tecnicamente o projeto é um sucesso.

Foi dado o go live do ERP, a partir de uma determinada data os colaboradores deveriam passar a utilizar o produto que foi construído, mas parte do público que deveria utilizar não fez a adoção, outra parte fez a adoção parcial e um terço fez adoção total do ERP, neste caso podemos considerar que o projeto foi um sucesso?

Sabemos que o sucesso é relativo, mas neste caso o projeto não foi um sucesso, pois dentre os parâmetros de sucesso, um deles era a adoção do ERP por parte do cliente.

Mas, volto a perguntar, tecnicamente o produto estava pronto, por quê não deu certo? Vamos analisar o caso!



Figura 1 - Representação das duas perspectiva: lado humano e técnico do projeto


Podemos fazer uma réplica para este questionamento, fazendo duas perguntas:

  1. A gestão de mudanças deste projeto existiu e foi eficiente?

  2. Tecnicamente o produto estava pronto, mas e os indivíduos?

Seguindo algumas das principais abordagens para a gestão de mudanças, treinar os usuários não é o suficiente para implementar e sustentar a mudança. Para que a adoção aconteça as pessoas devem ter desenvolvido consciência dos "porquês" da mudança e o desejo de mudar, pois se não a mudança não acontecerá.


Quando falamos sobre projetos de tecnologia o fornecedor e o cliente podem não medirão esforços para fazer com que o produto seja desenvolvido da melhor maneira possível, mas temos que pensar que se as pessoas não entenderem os motivos da mudança e não tiverem seus desejos aumentados para fazer a mudança acontecer, produto nenhum terá validade.


E questionamentos destes tipos irão surgir:

  • “Mas por que vou deixar de utilizar a planilha para lançar os dados em outro lugar? No Excel consigo manusear e gerar os dados que preciso, gosto de trabalhar com flexibilidade.”

  • “Por que a mudança está acontecendo logo agora que estamos passando por uma fase difícil?”

  • “Ixi, aqui as pessoas têm muita resistência em mudar, as coisas sempre funcionaram do mesmo jeito, nem meu gerente acredita nesta mudança, sempre mais do mesmo.”


Agora te pergunto, adianta termos um produto que em teoria funcionará bem se as pessoas fazem questionamentos deste tipo? Este tipo de questão só me faz pensar em duas coisas, resistência e não adoção.

Se seguíssemos a técnica mais conhecida do mundo em gestão de mudanças, o ADKAR da Prosci, nos atentaríamos as 5 etapas da mudança:


Figura 2 - Representação do ADKAR model


Em algumas experiências que tive, posso dizer que em projetos de implantação de um ERP, os indivíduos focam em desenvolver o conhecimento no que irá mudar e a habilidade para fazer a mudança acontecer, como por exemplo, experiência e domínio no uso do ERP, e se esquecem de desenvolver a consciência do porque está mudando, o desejo de mudar e de traçar estratégias para reforçar a mudança para que não volte a fazer do modo antigo.


Arrisco em dizer que indivíduos preparados para a mudança por vezes vale mais que um produto tecnicamente pronto, pois indivíduos engajados dão um jeito para as coisas funcionarem, se esforçam para que a mudança tenha sucesso, "nem que aos trancos e barrancos", indivíduos que não estão engajados, darão um jeito para que mesmo um produto muito bem construído não seja implantado e para que a mudança não aconteça.


Você pode estar se perguntando, tudo isso é interessante, mas como que fazemos para desenvolver estes “estados da mudança” nos projetos que eu gerencio?


Algumas dicas que poderão te ajudar:

  • Envolvimento dos patrocinadores (sponsors) do projeto nas comunicações, o remetente que mais pode ajudar a aumentar a consciência do projeto é ele, em ações realizadas por e-mail, gravação de vídeos, e principalmente ações face a face nos cafés e workshops;


  • Desenvolvimento dos lideres para que atuem promovendo e patrocinando a mudança, mostrando para seus key users e colaboradores a importância da mudança, caso você identifique que o líder não está engajado na mudança, recorra ao sponsor primário, segundo as melhores práticas os líderes são os principais ativadores do desejo de mudar dos colaboradores;


  • Se necessário sacrifique um boicotador, dependendo da dimensão do projeto, o boicotador pode representar o fracasso do projeto, ainda mais se este indivíduo tiver bastante influência em algum processo crítico, se necessário articule para que o sacrifício aconteça e mostre para o restante da organização que a mudança irá acontecer;


  • Identifique os replicadores e os champions da mudança, aqueles que ajudarão a aumentar a consciência da organização sobre os porquês da mudança e a importância de mudar;


  • Comunique, comunique, comunique e comunique, deixe todos alinhados;


  • Promova cerimonias, rituais, ritos que garanta que periodicamente os envolvidos no projeto se encontrem para compartilhar as experiências e definições feitas no projeto, isso fará com que a comunicação se torne fluída.

Alguns projetos podem tecnicamente atender as necessidades de uma organização, mas caso os indivíduos não estejam prontos para mudar, isso pode ser considerado um motivo para o "não go live". Não perca mais tempo, reconhecimento e dinheiro, gerencie as mudanças.


Sobre o autor:

Fernando Veroneze é professor, escritor da editora gen Atlas e sócio diretor da SMR, especialista em gestão de projetos, processos e mudanças organizacionais, possui mais de 14 anos de experiência, incluindo projetos significativos em empresas como COPEL, Instituto Butantan, CNPEM, SESC, Marítima Seguros e etc. Autor do best-seller "Gestão de Projetos", também é um educador em instituições como FIA, Mackenzie e Politécnica da USP, com mestrado em Administração e extensão na Universidade da California - Berkeley. Sua missão é impulsionar transformações organizacionais e formar líderes empresariais para o futuro.


Quer saber mais? Assista ao vídeo:



Cabeçalho - site.png
bottom of page