Gestão da Mudança

Num projeto, a mudança não é a exceção: é o que se espera. Os requisitos evoluem, o contexto muda e as pessoas descobrem o que realmente precisam à medida que veem resultados. O risco não está em haver mudanças, mas em elas acontecerem sem serem avaliadas, decididas e registadas.

A mudança é normal

• É habitual haver uma mudança de 1% a 2% dos requisitos por mês. O valor varia com o ramo de atividade e com o dinamismo do mercado.
• Num projeto que dure um ano, é fácil ter cerca de 25% dos requisitos iniciais alterados.

Estes números são ordens de grandeza, não metas: servem para mostrar que um projeto sem processo de alterações acaba por executar um projeto diferente do que foi aprovado, sem que ninguém o tenha decidido.

Dois tipos de mudança

Alterações ao projeto

Pedidos que mudam o âmbito, o prazo, o custo ou a qualidade acordados. São geridos pelo controlo de alterações.

Mudança nas pessoas e na organização

O que o projeto entrega obriga as pessoas a trabalhar de outra forma. São geridas pela gestão da adoção: sem ela, o entregável existe mas não é usado.

Processo de controlo de alterações

O processo responde às seis perguntas que todo o projeto deve ter respondidas antes de a primeira alteração chegar:

1. O que é controlado? Definir quais as mudanças que passam pelo processo (por exemplo, qualquer alteração a âmbito, prazo, orçamento ou critérios de aceitação).
2. Como se pede? Pedido por escrito, num formulário ou registo único, com justificação.
3. Qual o impacto? Avaliar o efeito em âmbito, prazo, custo, qualidade e risco, antes de decidir.
4. Quem decide? Atribuir autoridade clara para aprovar ou rejeitar, individual ou num comité de controlo de alterações, com limites por valor ou impacto.
5. Como se comunica? Documentar a decisão e distribuí-la a quem é afetado.
6. Como se implementa? Executar a alteração, registar quando foi feita e atualizar a baseline, o cronograma e os requisitos.

O escalamento de situações relacionadas com mudanças também deve estar pensado: o que fazer quando o pedido excede a autoridade do gestor ou quando o patrocinador e o cliente discordam.

Registo de alterações

Campo	Para que serve
Identificador e data	Rastrear cada pedido
Quem pede e porquê	Perceber a origem e a necessidade real
Descrição da alteração	Evitar ambiguidade
Impacto em âmbito, prazo, custo, risco	Decidir com informação
Decisão, aprovador e data	Responsabilidade e histórico
Data de implementação e baseline atualizada	Fechar o ciclo

Deriva de âmbito (scope creep)

A deriva de âmbito é a acumulação de pequenas alterações aceites sem processo. Cada uma parece inofensiva; juntas desfazem o plano.

• Sinais: «só mais uma coisa pequena», tarefas novas sem orçamento associado, entregas a mudar sem aprovação, equipa em horas extra sem razão aparente.
• Resposta: não dizer logo não; dizer «vamos avaliar o impacto» e mostrar o custo em prazo e dinheiro. A decisão passa a ser do patrocinador, com informação.

O efeito financeiro vê-se em orçamento vs realizado e no forecast; o efeito nos requisitos, em Requisitos.

Mudança nas pessoas: adoção

Entregar não é o mesmo que ser usado. Dois modelos usados com frequência ajudam a planear esta vertente.

Os oito passos de Kotter

1. Criar sentido de urgência.
2. Formar uma coligação orientadora.
3. Definir uma visão e uma estratégia.
4. Comunicar a visão.
5. Remover obstáculos e dar poder para agir.
6. Criar vitórias de curto prazo.
7. Consolidar ganhos e continuar a mudar.
8. Ancorar a mudança na cultura.

ADKAR

Modelo centrado no indivíduo. Cada pessoa precisa de passar por cinco etapas, e basta falhar uma para a mudança não acontecer:

• Awareness (consciência): perceber porque é preciso mudar.
• Desire (desejo): querer participar na mudança.
• Knowledge (conhecimento): saber como mudar.
• Ability (capacidade): conseguir pôr em prática.
• Reinforcement (reforço): manter a mudança ao longo do tempo.

Na prática: identificar os stakeholders afetados, perceber o que perdem e o que ganham, comunicar cedo, formar antes da entrada em produção e medir a utilização depois. A resistência raramente é teimosia; é geralmente falta de informação, de confiança ou de tempo. Ver também Gestão das Pessoas e Psychological Safety.

Checklist de Gestão da Mudança

• O processo de alterações está definido e aprovado antes de a execução começar
• Existe um registo único de alterações, com decisão e responsável
• Cada pedido tem avaliação de impacto em âmbito, prazo, custo e risco
• A autoridade para aprovar está clara, com limites e escalamento
• A baseline é atualizada sempre que uma alteração é aprovada
• Os stakeholders afetados são identificados e envolvidos antes da entrega
• A adoção é medida depois da entrega, não apenas o entregável

Erros Frequentes

• Aceitar pedidos verbais ou por corredor, sem registo.
• Avaliar o impacto só no prazo e esquecer o custo e o risco.
• Aprovar alterações sem atualizar a baseline, o que torna impossível medir desvios.
• Tratar a adoção como um assunto de comunicação no fim, em vez de planeamento desde o início.
• Culpar a «resistência à mudança» sem perceber de que informação ou apoio as pessoas precisam.

Como Aplicar em 30 Dias

1. Semana 1: definir quais as mudanças controladas, o formulário de pedido e quem decide.
2. Semana 2: criar o registo de alterações e incluí-lo na rotina de controlo semanal.
3. Semana 3: mapear os stakeholders afetados e o que cada grupo precisa de saber e de fazer.
4. Semana 4: rever as alterações do mês, o seu impacto acumulado no orçamento e no prazo, e o plano de adoção.

Referências

• Kotter, J. P., Leading Change (Harvard Business Review Press, 1996).
• Hiatt, J., ADKAR: A Model for Change in Business, Government and our Community (Prosci).
• PMI, PMBOK Guide: controlo integrado de alterações.

Atualizado em: 03/10/2026