5 erros que você não pode cometer no gerenciamento de mudanças

Gerenciar projetos não é fácil, mas gerenciar mudanças bate o recorde!! São projetos críticos em ambientes de produção e qualquer falha pode deixar a equipe parecida com a figura acima, belos “Trapalhões”.

Change (Gerenciamento de Mudança) refere-se ao ato de efetuar uma alteração em um ambiente em funcionamento / produção.

Estes ambientes geralmente não podem parar de funcionar, ou podem receber alterações somente em janelas de manutenção programadas  com antecedência. É requisito garantir que após a janela de mudança a operação continuará funcionando perfeitamente. Alguns exemplos de changes:

• Reforma de uma loja
• Troca da caldeira de uma metalúrgica
• Mudança de uma perfuratriz de poços petróleo
• Upgrade dos servidores do google
• Alteração de um site bancário

Já vi muitos GPs passando apertos durante changes, por falta de planejamento, experiência ou simplesmente por não identificar os stakeholders adequadamente. Coletei 5 erros que um GP NÃO PODE COMETER em changes:

1. Não definir a janela de manutenção

Toda manutenção em ambiente de produção deve ter uma janela com horário programado, autorizada pelos stakeholders e comunicada a todos os interessados. Ignorar essa regra é uma “trapalhada” máxima.

Caso: Certa vez o executivo chegou à sua sala apressado para imprimir um relatório, mas não conseguiu. Tentou mais uma vez, reiniciou o computador, nada feito. Ligou para o suporte, recebeu a visita de um técnico, mas nada resolvia a situação. Descobriu então que uma empresa parceira estava executando uma change na rede, que impactou sua impressora, mas ele não fora avisado…

O tempo de antecipação (para obter as autorizações) também deve ser pré-definido entre as empresas parceiras.  Ex: 24 horas para emergências, 48 horas para exceções e 72 horas para changes normais.

Deve-se ainda, definir nível de risco, possíveis impactos e levantar todas as equipes envolvidas, localidades, servidores, etc.

2. Não fazer um cronograma para a change

Não importa quantas vezes a equipe tenha feito changes similares, sempre faça um cronograma! Quando as coisas dão errado, a primeira pessoa a ser procurada será o GP.

É importante que você saiba responder TUDO sobre a change: o que, quem, onde, como, porque, se deu certo ou errado e o que está sendo feito para corrigir.

Para isso monte um cronograma incluindo: Id da atividade, descrição, pessoa responsável, previsão de inicio e fim, horas de inicio e fim realizadas e observação.

3. Ignorar o escopo negativo do projeto  / premissas

Como já disse, as changes não podem dar errado, pois não existe tempo para buscar recursos durante sua execução. Se você observar apenas o escopo positivo, poderá cair no erro de presumir inverdades.

_ Ah, mas eu planejei nas premissas do projeto.

_ Ok, muito bem. Mas isso resolve o problema?

O fato é que isso não garante absolutamente NADA, alguém tem que ser responsável (accountable) por resolver todas as pendências e certificar-se que  cliente e parceiros entenderam corretamente os escopos positivo e negativo.

A recomendação é: Revisar escopo e solução técnica junto com a equipe, transformar as premissas em dependências externas e monitorar periodicamente! (antes da change). Pode-se ainda usar uma tabela RACI.

4. Não ter caminhos alternativos, redundâncias e estratégia de retirada

Sim, você acertou! Estou falando de Gerenciamento de Riscos. Em changes, é preciso garantir que tudo esteja perfeitamente preparado e sincronizado para o dia da execução.

Mas as vezes gerenciamos projetos que não dominamos tecnicamente e com isso não conseguimos enxergar a ausência ou incompatibilidade de um material, falta de um acesso ou uma pessoa indisponível.

As recomendações são:

• Reunir a equipe e repasse a EAP e o cronograma, identificando os riscos envolvidos
• Observar sobretudo recursos humanos, materiais e financeiros
• Observar também disponibilidade e redundância de acessos
• De um modo geral, definir planos de mitigação onde for necessário
• Definir limites para a falha (Ex: 2 horas, 50 alarmes de erro etc)
• Definir estratégias de retirada (fallback)

Lembre-se, a Lei de Murphy está sempre presente nas horas mais difíceis.

5. Não comunicar adequadamente

Nunca presuma que as pessoas sabem o que está acontecendo! Sempre tem um desavisado em algum lugar e ele provavelmente vai ligar para o seu chefe reclamando de você.

A principal recomendação é criar um Plano de Comunicação definindo quem será informado, por que meio, com que periodicidade etc. Mas além listei algumas dicas:

• Estabeleça pontos de checagem (checkpoints) nos principais momentos do projeto, por exemplo, no inicio da execução da change e no final.
• Acompanhe o cronograma definido e comunique às partes interessadas. Alguns projetos exigem comunicação a cada passo, outros apenas no inicio e final, verifque qual é o caso.
• Se for um projeto com equipes geograficamente dispersas, deixe sempre uma bridge (um número de teleconferência) aberto e disponível para os técnicos usarem para comunicação durante a change, de preferência que você possa acessar de vez em quando.
• Ao final da change, faça uma reunião rápida com todos para confirmar a conclusão ou falha. Nesta reunião os técnicos e clientes podem conversar sobre o andamento e motivos de sucesso/fracasso.
• Se houver (estratégia de retirada), é uma boa prática fazer uma reunião restrospectiva para entender detalhadamente os motivos de falhae para preparar a próxima janela de manutenção.

Os trapalhões

Os trapalhões sempre se davam bem no final, especialmente o “Didi Mocó” que surgia com surpresas inusitadas. Mas na vida real não dá para contar sempre com a sorte e nem toda trapalhada é engraçada, é preciso planejamento e perspicácia.

Evitando esses erros clássicos, sua empresa, sua equipe e você evitarão ficar dando desculpas esfarrapadas por falta de planejamento. Acredite, é bem melhor que precisar contar piadas para contornar situações constrangedoras com clientes e parceiros. Better safe than sorry!

Eli Rodrigues

Posts relacionados:

• Desafios em projetos internacionais com equipes virtuais
• Um time de amadores