Gerenciamento de mudanças em projetos de TI

Prévia do material em texto

Gerenciamento de mudanças em projetos 
de TI
APRESENTAÇÃO
O gerenciamento de mudanças é importante durante toda a execução do projeto, pois é possível 
identificar impactos técnicos no desenvolvimento do produto (aumento da complexidade) e até 
mesmo se é viável tecnicamente a alteração solicitada, como também alterações no prazo e 
custos, mediante a alteração de escopo do projeto. Sendo assim, é capaz de planejar respostas 
rápidas e eficientes para minimizar os possíveis impactos negativos do projeto. Além disso, 
como forma de antecipação e bom planejamento, os monitoramentos constantes devem ser 
feitos para detectar a necessidade de ações corretivas ou preventivas, da mesma forma que uma 
análise cuidadosa no processo de controle de mudanças se faz essencial para garantir que 
somente as mudanças aprovadas sejam implementadas. 
Nesta Unidade de Aprendizagem, você aprenderá os elementos relacionados ao gerenciamento 
de mudanças em projetos de TI. Ademais, verá a importância de se ter um gabarito do projeto 
(ou linha de base) para guiar os envolvidos em sua execução, a razão de se ter um controle 
integrado no tocante às mudanças em projetos e os possíveis impactos perante a mudança de 
escopo.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Definir linha de base de um projeto.•
Reconhecer a importância do controle integrado de mudanças em um projeto de TI.•
Identificar os envolvidos em um processo formal de mudanças no escopo do projeto.•
DESAFIO
As solicitações de mudança sempre demandam atenção por parte dos gerentes de projeto, pois, 
se elas não forem bem trabalhadas, os impactos decorrentes dessa falha no 
gerenciamento podem comprometer as entregas previstas pelo projeto. 
Considere o seguinte cenário: 
Durante uma reunião para acompanhamento do projeto do qual você é o gerente, o sr. Ricardo, 
gerente de RH, lhe entrega uma solicitação de alteração no escopo do projeto. Ele deseja incluir 
mais uma funcionalidade que não tinha sido prevista inicialmente no novo portal de RH, que 
está sendo desenvolvido. O sr. Ricardo acredita que essa funcionalidade vai trazer muitos 
benefícios ao produto depois de pronto. Assim, ele pede encarecidamente a você, gerente de 
projetos, que a mudança seja contemplada. 
A partir do cenário acima descrito, responda às seguintes perguntas: 
a) Você implementaria as mudanças tão logo recebesse o pedido de desenvolvimento da nova 
funcionalidade pelo sr. Ricardo, já que a funcionalidade vai trazer muitos benefícios ao produto 
desenvolvido para o RH? 
b) De que natureza é a solicitação de mudança feita pelo sr. Ricardo? 
c) Quais impactos podem ocorrer no projeto a partir da mudança?
INFOGRÁFICO
Uma vez que o projeto estiver em execução, podem surgir novas demandas das partes 
interessadas, como a implementação de novos atributos no produto ou no serviço que está sendo 
desenvolvido — por exemplo, um novo módulo no software em desenvolvimento. Mediante a 
solicitação, o que deve ser feito? Quais passos devem ser seguidos? Como garantir que 
os envolvidos sejam atualizados das mudanças? 
No Infográfico, veja um guia rápido de como agir nesse tipo de situação e de forma segura. 
CONTEÚDO DO LIVRO
O gerenciamento das mudanças em projetos de TI se mostra um conhecimento essencial a ser 
dominado pelo gerente de projetos. Dado o alto dinamismo do mercado, os requisitos 
mudam cada vez mais rapidamente, o que justifica, por exemplo, o crescimento das chamadas 
"metodologias ágeis" como uma alternativa viável de acomodação das mudanças exigidas. 
Algumas temáticas oriundas das Ciências Humanas e Sociais são de grande ajuda para o pleno 
entendimento da gestão da mudança em projetos. No entanto, o grande desafio da mudança 
reside no vetor humano, pois este, diferentemente de um sistema computadorizado, nem sempre 
é capaz de mudar seu mindset tão rapidamente para acomodar as mudanças revisadas e 
aprovadas em um projeto.
No capítulo Gerenciamento de mudanças em projetos de TI, da obra Gestão de projetos de 
TI, base teórica desta Unidade de Aprendizagem, entenda sobre ferramentas que podem ajudar 
os gerentes de projetos na implementação das mudanças propostas, como a linha de base (tão 
importante no contexto dos projetos) e um controle integrado.
Boa leitura.
GESTÃO DE 
PROJETOS DE TI
Allan de Souza Muniz
Gerenciamento de 
mudanças em projetos de TI
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Definir linha de base de um projeto.
 � Reconhecer a importância do controle integrado de mudanças em
um projeto de TI.
 � Identificar os envolvidos em um processo formal de mudanças no
escopo do projeto.
Introdução
Sabemos que nem sempre os projetos saem conforme o planejado. 
Por isso, neste capítulo você vai estudar as solicitações de mudança e o 
controle integrado de mudanças, que é o processo de revisar as solicita-
ções de mudanças, aprová-las e gerenciá-las, comunicando as decisões. 
Você verá que o controle integrado de mudanças permite que as 
mudanças registradas e documentadas dentro do projeto sejam enten-
didas de forma integral, nunca deixando de lado o risco geral do projeto. 
Mudanças precisam considerar, sempre, os objetivos e planos gerais 
do projeto, que deve possibilitar à organização atingir seus objetivos 
estratégicos. 
1 Linha de base de um projeto
A linha de base (tradução de baseline, no inglês) de um projeto serve para 
fornecer referências essenciais para o controle do trabalho (PROJECT MA-
NAGEMENT INSTITUTE, 2017). A linha de base é um recurso fundamental 
para o gerente de projetos no que tange a eventuais mudanças. Ela é um ponto 
de partida muito bem definido, uma referência formada pelos itens crono-
grama, orçamento e escopo do projeto, que funciona como uma fotografia, 
com dados de referência de um planejamento acordado que objetivam atender 
dois pontos importantes: 
1. Ao longo do projeto, permitir que a equipe se lembre de onde deveria 
estar a partir do plano original.
2. Ao fim do projeto, verificar o quão distante se chegou versus onde se 
desejava chegar.
No início da execução do projeto, uma linha do “realizado” será desenhada, 
capturando e organizando os dados do que realmente está acontecendo com 
o projeto. A partir da linha de base do projeto, será possível observar, por 
exemplo, se, ao fim do segundo mês, de acordo com a linha de base, o projeto 
está dentro do cronograma e dentro do custo planejado. Isso pode auxiliar a 
liderança organizacional a direcionar os esforços para ajustar o cronograma, 
bem como a definir ações para realinhar os custos excedidos com o original-
mente previsto. Para esses controles, o apoio ferramental, como o exemplo 
mostrado na Figura 1, é primordial e facilita o trabalho de acompanhamento 
do projeto.
Figura 1. Linha de base criada para um projeto com apoio ferramental.
Fonte: Khuong (2018, documento on-line).
Gerenciamento de mudanças em projetos de TI2
A linha de base serve para apoiar a liderança na identificação dos gaps 
entre o planejado e o realizado, assim como ajuda a mostrar o esforço de 
retornar à proposta original do planejamento. É comum que, com os projetos 
em execução, as mudanças aconteçam, e as linhas de base acabam não con-
siderando tais mudanças. Nesse caso, a saída é o replanejamento do projeto 
à luz das mudanças que foram aprovadas. A transformação, no entanto, não 
significa que a linha de base será descartada. Novamente, o apoio ferramental 
é essencial nesta parte, porque permite, de forma simples e rápida, verificar 
se o plano original está sendo seguindo ou não, facilitando o trabalho do 
gerente de projeto. 
Nem sempre as mudanças gerarão alterações nas linhas de base do projeto. Às vezes, 
as solicitações de mudanças são corretivas ou preventivas, reparos de defeitos ou 
alterações em documentos. O gerente de projetos toma as decisões sobre essas 
mudanças.As solicitações que tenham impacto sobre as linhas de base devem incluir 
informações sobre os custos das mudanças, as alterações em cronogramas e os riscos 
e são aprovadas pelo cliente ou patrocinador. Só as mudanças aprovadas devem ser 
incorporadas em uma linha de base revisada. 
Antes das mudanças serem aprovadas formalmente (para incorporação 
em uma nova linha de base), é importante que uma série de fatores sejam 
ponderados. Um deles é a prioridade, afinal de contas, como definir quais 
mudanças serão contempladas primeiro? Se não houver um critério de clas-
sificação, tudo será prioridade e, ao mesmo tempo, nada será prioridade, 
já que as mudanças estarão no mesmo nível de urgência na cabeça do solici-
tante. Uma importante contribuição nesse sentido é trazida por Vargas (2018) 
e pode ser seguida conforme a lista de prioridades a seguir.
 � Prioridade zero: demandam ação imediata por parte do gerente de 
projeto, que deve acionar o patrocinador urgentemente. Representam 
alto impacto no projeto e em outras áreas sobre as quais o gerente não 
tem autonomia.
3Gerenciamento de mudanças em projetos de TI
 � Prioridade um: demandam ação imediata do gerente de projeto, exi-
gindo o acionamento junto ao patrocinador, se necessário (em caso de 
autorizações financeiras fora da responsabilidade do gerente de projetos).
 � Prioridade dois: demandam um planejamento de ação pela equipe 
ou mesmo por terceiros que, em princípio, tenham disponibilidade. 
Sendo urgentes, estas mudanças agregam valor ao sucesso do projeto, 
mas não têm impacto significativo nos custos e nos prazos do projeto.
 � Prioridade três: não demandam ação imediata por não serem impac-
tantes ou urgentes, mas devem, a seu tempo, ser implementadas, porque 
influem no sucesso do projeto.
Uma vez determinado o nível de urgência das prioridades, quem irá ana-
lisar e aprovar as mudanças? Tanto o PMBOK (PROJECT MANAGEMENT 
INSTITUTE, 2017) quanto Vargas (2018) defendem a ideia da existência de 
um comitê de controle de mudanças do projeto, o qual deve ser o responsável 
por analisar as mudanças em requisitos do projeto. Em alguns casos, o gerente 
de projetos pode também, junto com o patrocinador, aprovar de forma interina 
uma mudança nos requisitos, sendo de responsabilidade do comitê de controle 
de mudanças a aprovação formal da mudança. 
2 Controle integrado de mudanças
O controle integrado de mudanças faz parte do grupo de processos de monito-
ramento e controle, responsável por acompanhar, estudar e promover ajustes 
no progresso e desempenho do projeto. Por monitoramento entendemos a 
coleta de dados de performance do projeto, produzindo medições sobre seu 
desempenho e realizando as comunicações pertinentes. Já por controle en-
tendemos o comparativo entre o desempenho real e o desempenho planejado, 
permitindo que análises de variações e tendências, avaliações de caminhos 
alternativos e recomendações de ações corretivas sejam realizadas sempre 
que necessário (PROJECT MANAGEMENT INSTITUTE, 2017). Visualize 
uma síntese do controle integrado de mudanças na Figura 2.
Gerenciamento de mudanças em projetos de TI4
Figura 2. Controle integrado de mudanças: diagrama do fluxo de dados.
Fonte: Project Management Institute (2017, p. 114).
Toda mudança ocorrida em um projeto deve ser registrada e controlada. 
A importância desse registro é inegável. Segundo o PMBOK (PROJECT 
MANAGEMENT INSTITUTE, 2017), cabe ao controle integrado de mudanças 
as seguintes responsabilidades:
 � revisão de todos os pedidos de mudança;
 � aprovação das mudanças;
 � gerenciamento das mudanças nas entregas, ativos de processos organi-
zacionais, plano de gerenciamento de projeto, documentos do projeto 
e ativos de processos organizacionais;
 � comunicação da decisão.
5Gerenciamento de mudanças em projetos de TI
A partir disso, é possível perceber a importância do controle integrado de 
mudanças, que é possibilitar que as mudanças registradas no projeto sejam 
consideradas em uma perspectiva integrada, trazendo também a ótica do 
risco geral do projeto. E por que a visão de riscos precisa ser resgatada neste 
ponto? É importante considerar que as mudanças podem trazem enormes 
riscos ao projeto, principalmente se elas desconsiderarem os planos gerais 
do projeto, ou seus objetivos. Sem um controle formal sobre essas questões, 
o escopo do projeto, seus custos, o escopo do produto e os prazos de entrega 
serão afetados negativamente. 
Alguns fatores podem contribuir para a realização do controle integrado 
de mudanças, como os fatores ambientais da organização, os fatores legais, 
as regulamentações locais ou do país, os padrões de governo ou do setor, 
a estrutura de governança organizacional, as restrições em questões de con-
tratação e processos de compras etc. Perceba que a mudança pode ser gerada 
internamente ou a partir de forças externas. 
No cenário interno, as mudanças podem gerar, por exemplo, inclusões 
de novas funcionalidades durante o desenvolvimento de um software ou a 
retirada de atributos em excesso na criação de um novo produto. Já no cenário 
externo, a pressão exercida por aprovações de leis, por exemplo, justifica a 
abertura de novos projetos nas organizações. Um importante marco no Brasil 
é a criação da Lei Geral de Proteção de Dados, Lei nº. 13.709, de 14 de agosto 
de 2018, que demandou de todas as organizações brasileiras a adaptação de 
seus processos internos (sob a forma de projetos) para o atendimento pleno 
às exigências legais (BRASIL, 2018).
Corroborando a visão do PMBOK (PROJECT MANAGEMENT INS-
TITUTE, 2017), Vargas (2018) e Nokes e Kelly (2012) defendem a ideia do 
controle integrado de mudanças como ferramenta essencial do monitoramento 
e controle de projetos. Larson e Gray (2016) também trouxeram contribui-
ções neste ponto, ao classificarem o controle integrado de mudanças entre as 
seguintes categorias: 
 � alterações no escopo, comumente sob a forma de solicitações de clientes 
para a inclusão de uma nova característica em um produto ou um novo 
design dele;
 � mudanças de melhoria, que são sugeridas por integrantes da equipe 
de projeto;
 � implementação de planos de contingência, especialmente quando 
acontecem eventos de risco, significando mudanças nos custos e nos 
cronogramas da linha de base.
Gerenciamento de mudanças em projetos de TI6
Portanto, considerando que as mudanças se evidenciarão de forma frequente 
no projeto, seu planejamento é essencial. Tal planejamento deve ocorrer no 
processo de comunicação, como parte do plano de comunicação do projeto, 
desde cedo, a partir das partes interessadas (LARSON; GRAY, 2016). Esses 
stakeholders devem determinar também o processo de tomada de decisão a ser 
utilizado para avaliar e aceitar as mudanças. Tal processo pode ser registrado 
em um documento visual como um fluxograma, o exemplificado na Figura 3.
Figura 3. Fluxograma para regis-
tro da solicitação de mudanças.
Fonte: Larson e Gray (2016, p.192).
7Gerenciamento de mudanças em projetos de TI
Naturalmente, o fluxo da Figura 3 pode ser modificado, dependendo de cada 
organização. Em projetos pequenos, o processo pode desencadear a aprovação 
de um grupo diminuto de partes interessadas, enquanto, em projetos maiores, 
outras ações podem ser combinadas. 
Em um projeto de desenvolvimento de software, se houver mudanças relacionadas 
a requisitos de desempenho, múltiplas aprovações ou consentimentos podem ser 
necessários, enquanto uma troca de fornecedor pode ser aprovada pelo gerente do 
projeto. 
Independentemente da natureza, do tamanho e da complexidade do pro-
jeto, o mais importante é que o processo para as mudanças seja definido 
antecipadamente e que as mudanças sejam tratadas de forma ágil e efetiva. 
Acima de tudo, é fundamental que elas sejam entendidas e respeitadas por 
todos os envolvidos. Um ponto essencial é que os clientes entendam que 
mudanças não podem simplesmente ser aprovadas para o atendimento de suas 
necessidades sem que a solicitação sejaanalisada previamente. Na cabeça do 
cliente, muitas vezes a inclusão de uma funcionalidade simples pode parecer 
de fácil implementação, mas, em um projeto de tecnologia da informação (TI), 
especialmente em desenvolvimento de software, pode representar um esforço 
enorme (em alguns casos, inviabilizando produtos que já foram entregues 
previamente em marcos anteriores do projeto).
Explore o caso “Chaos: projetos de software” no Capítulo 14, p. 456, do livro Geren-
ciamento de projetos: o processo gerencial, de Larson e Gray (2016), que faz parte das 
referências utilizadas neste capítulo. Os números mostrados pela pesquisa realizada 
pelo Standish Group para os projetos cancelados, bem como os projetos que custaram 
bem acima do orçado, são assustadores. 
Gerenciamento de mudanças em projetos de TI8
3 Envolvidos em um processo formal de 
mudanças no escopo do projeto
O PMBOK (PROJECT MANAGEMENT INSTITUTE, 2017) tem em sua 
visão geral do gerenciamento de escopo do projeto o controle do escopo. 
“Controle” aqui não significa que o escopo não possa ser mudado. Não há nada 
de errado com a mudança. O problema é como as solicitações de alteração de 
escopo são coordenadas, pois, dependendo de como elas são gerenciadas, os 
impactos podem ser negativos. Ainda de acordo com o PMBOK (PROJECT 
MANAGEMENT INSTITUTE, 2017), o grande benefício do processo é a 
manutenção da linha de base ao longo de todo o projeto. 
Uma questão central com relação à mudança reside no componente humano. 
No contexto de projetos, esse componente pode ser enxergado na figura dos 
stakeholders, as partes interessadas. Eles podem se envolver no processo 
formal de mudanças no papel de solicitantes ou aprovadores, ou serem apenas 
os comunicados de alguma mudança. Nesse jogo de interesses que envolvem o 
projeto, algumas solicitações de mudanças poderão ser enxergadas pelos seus 
autores como promissoras para os resultados do projeto, enquanto outras partes 
poderão enxergar as mesmas mudanças pelo lado negativo, desencadeando, 
em algumas circunstâncias, o comportamento de resistência. 
Muitas equipes temem as mudanças em projetos, seja porque é mais cômodo 
trabalhar em ambientes conhecidos, seja porque não sabem lidar com mudan-
ças de forma segura. Por isso fazer um bom plano de mudanças e preparar a 
equipe para novos cenários é fundamental, minimizando riscos ao projeto e 
aos negócios. Em projetos mais complexos, como trocas de sistemas de gestão 
empresarial (conhecidos pela sigla ERP, ou enterprise resources planning), 
a gestão de mudanças é utilizada com mais ênfase. Em projetos mais simples, 
a gestão de mudanças pode ser mais fácil de gerenciar, mas o cerne da questão 
não pode ser desprezado: as mudanças geram impactos, e esses impactos 
podem gerar muitos problemas no vetor pessoal. 
O que está no centro do problema da mudança, quando se considera o fator 
humano, é a resistência em mudar. Parece ser mais fácil administrar o que já 
está bem definido e previamente planejado do que ter de se adaptar ao longo 
do projeto para atender a uma demanda importante do mercado ou do próprio 
cliente, que detectou, por exemplo, que uma nova funcionalidade em seu 
produto poderá oferecer alguma vantagem competitiva frente à concorrência. 
9Gerenciamento de mudanças em projetos de TI
A ciência já estudou demasiadamente diversos fatores ligados à resistência 
às mudanças. Para gerar maiores possibilidades de sucesso no processo de 
mudanças, existem diversas ferramentas disponíveis. A seguir, três delas 
serão detalhadas.
Análise das partes interessadas
Uma parte envolvida no processo de mudança em um projeto são os stakehol-
ders, ou partes interessadas. Para aumentar as chances de o projeto dar certo, 
o gerente de projetos precisa usar a política a seu favor. O uso da política como 
ferramenta pode trazer benefícios importantes, como construir as expectativas 
do projeto junto aos stakeholders, aumentando as chances de eles apoiarem o 
projeto, assim como o ganho de recursos importantes como dinheiro, pessoas 
e prazos mais confortáveis. Um bom relacionamento nas fases iniciais entre 
as partes interessadas e o gerente de projetos ajuda-o a antecipar e prever 
reações dos stakeholders, possibilitando ações preventivas que ajudarão a 
ganhar o apoio das partes interessadas ao longo do ciclo de vida do projeto. 
De forma geral, uma boa análise das partes interessadas segue os seguintes 
passos:
1. Bom conhecimento das partes interessadas: conhecer antecipada-
mente os stakeholders do projeto será extremamente importante para o 
gerente de projetos. Saber o que cada um valoriza, suas personalidades, 
formações e padrões de decisão no tocante à gestão da organização 
são ações que ajudarão, e muito, no planejamento de projetos que pos-
sibilitarão a essas partes interessadas enxergar valor no trabalho que 
será desempenhado.
2. Exploração das habilidades de negociação: aproximar-se daque-
les que poderão apoiar não somente o projeto, mas as mudanças que 
acontecerão durante o seu ciclo de vida é uma estratégia que permite 
exercitar o poder da influência e da negociação, aumentando o número 
de aliados. Nem sempre será possível ter o apoio de todos e nem sempre 
os apoiadores terão o mesmo poder. Será importante entender, então, 
essa relação de poder, que pode ser a seguinte: 
 ■ Stakeholders com alto poder e muito interessados no projeto: 
o gerente de projetos deve envolver essas pessoas totalmente, bus-
cando empreender os maiores esforços para satisfazê-las.
Gerenciamento de mudanças em projetos de TI10
 ■ Stakeholders com alto poder e pouco interesse no projeto: o gerente 
de projetos deve manter essas pessoas satisfeitas com o trabalho, mas 
não o suficiente para entediá-las com a quantidade de interações.
 ■ Stakeholders com baixo poder e muito interessados no projeto: 
para este grupo, o gerente de projetos deve buscar a atualização de 
tudo o que está acontecendo, para evitar que mudanças indesejadas 
ou problemas surjam ao longo do caminho. Apesar do baixo poder, 
elas se mostram interessadas, o que pode ser usado a favor do gerente 
e da equipe de projetos.
 ■ Stakeholders com baixo poder e pouco interesse no projeto: para 
este grupo, basta a manutenção da comunicação, mantendo as pessoas 
informadas, mas tendo o bom senso de não aborrecê-las, já que elas 
não têm muito interesse no que está acontecendo.
3. Entendimento dos stakeholders: após ter entendido os pontos 1 e 2, 
é importante separar entre apoiadores, neutros e opositores. Espe-
cialmente com relação aos dois últimos grupos, quem na organização 
poderia ser apoiador dos trabalhos do projeto se eles se posicionarem 
de forma neutra ou contrária? O que os motiva a assumir tais posições, 
de forma a não apoiar o projeto ao longo de todo o seu ciclo de vida? 
Essas são perguntas que podem ajudar a minimizar as forças contrárias, 
ou, dito de outra forma, a transformar os sinais negativos em positivos, 
trazendo cada vez mais aliados. 
Modelo de Lewin
O modelo de mudança de Kurt Lewin, apesar de antigo, ainda serve de base 
para a gestão e comunicação de mudanças. Criado em 1940, ele se baseia no 
fato de que o imobilismo é fatal. O modelo de Lewin é simples e baseia-se 
em três processos: descongelar, mudar, congelar. 
Uma situação do dia a dia pode ajudar a exemplificar o modelo de Lewin. Um cubo 
de gelo dentro de um daqueles compartimentos que ficam dentro do congelador 
normalmente tem a forma de um cubo, quadrada. Se você quiser transformar o cubo 
de gelo em um formato redondo, a pedra deverá ser descongelada e, somente no 
estado líquido, ser acomodada na forma redonda, para então congelar novamente. 
11Gerenciamento de mudanças em projetos de TI
Vejamos em mais detalhes os três passos do modelo, aplicados para um 
cenário de projetos: 
 � Descongelar: cada vez mais o cenário de projetos está se dinamizando. 
Não é à toa que as metodologias ágeis de desenvolvimento vêm ganhando 
mais espaço, pois elas se mostramcapazes de responder às mudanças 
constantes. Portanto, uma competência essencial para os gerentes e 
times de projeto é a habilidade de respostas rápidas e adaptações a novos 
cenários e novas necessidades de negócio para entregas de produtos 
mais aderentes às exigências do mercado. Gerentes e times de projeto 
avessos às mudanças terão cada vez menos espaço no ambiente de 
projetos. Descongelamentos cada vez mais frequentes acontecerão em 
todas as organizações. 
 � Mudar: complementando o primeiro passo do modelo de Lewin, geren-
tes e integrantes de equipes de projeto deverão ser capazes de ter foco 
em ambientes voláteis, sempre considerando que o planejado de hoje 
pode ser o obsoleto de amanhã (literalmente). Nesse sentido, novamente 
as metodologias ágeis mostram-se capazes de atender a esta demanda, 
porque planejam as ações em um projeto de forma iterativa e incremen-
tal. Mudar um sistema de TI é fácil. Um é trocado pelo outro, simples 
assim (desde que o ambiente seja adequado para o novo sistema). Fazer 
o vetor humano aderir ao novo já não é tão simples. Pessoas não mudam 
rapidamente. Elas guardam memória de sistemas antigos, “manias”, 
esquemas que não são esquecidos facilmente, enfim, seus mindsets não 
podem ser formatados como um disco rígido de computador. 
 � Congelar: o objetivo desta última etapa é garantir que, uma vez dentro 
do novo cenário, todos sejam capazes de assimilar as novas regras do 
jogo. Neste processo, será essencial lidar ainda com opositores dentro 
do jogo de interesses no ambiente de projetos. Alguns tentarão trazer a 
água para o antigo formato, mas neste momento, a habilidade política 
do gerente de projeto junto aos patrocinadores e a alta administração 
serão fundamentais para fixar os passos no novo ambiente. 
Gerenciamento de mudanças em projetos de TI12
Kurt Lewin era um psicólogo social alemão que, em virtude de sua origem judia, 
precisou sair da Alemanha durante a II Guerra Mundial, refugiando-se nos Estados 
Unidos, em 1933. Para Lewin, o comportamento humano é resultado de um campo 
formado pelo indivíduo e seu entorno, que não podem ser vistos como dois ambientes 
distintos. Com o intuito de entender o comportamento humano, as variáveis em volta 
dele devem ser consideradas. No contexto organizacional e também de projetos, a 
teoria das três etapas (descongelamento, mudança, congelamento) é utilizada por ter 
revolucionado a ideia das mudanças organizacionais.
Curva da mudança
Esta é, certamente, uma das ferramentas mais interessantes para entendermos 
o componente emocional de mudanças em uma organização. Ela pode ser 
facilmente aplicada ao mundo dos projetos, pois pode auxiliar (e muito) na 
diminuição do fator resistência das pessoas nos processos de mudança. Adi-
cionalmente, ela traz respostas à dificuldade do estágio “mudar” no modelo 
de Lewin. 
A curva da mudança foi estudada em 1969 por Elisabeth Kübler-Ross, 
psiquiatra suíça que estudou cerca de 200 pessoas em estágios terminais de 
câncer e percebeu um padrão de comportamento em suas vidas desde a hora 
do descobrimento da doença até o dia da morte. Os estágios são negação, raiva, 
barganha, depressão e aceitação. O modelo de Kübler-Ross não necessariamente 
determina que esses cinco estágios acontecerão em sequência, nem mesmo 
que esses estágios se revelarão em todos os pacientes. 
Este modelo foi depois estudado em outras áreas da ciência, sendo uma delas 
a da aprendizagem. E qual a relação do luto com a aprendizagem, especialmente 
no que toca aos projetos? O processo de aprendizagem gera uma espécie de 
luto, porque o cérebro entende que a mudança envolve o reaprendizado de algo, 
de um novo começo, e todo esse processo engloba sentimentos que embasam 
muitas emoções, que se afloram em meio às mudanças nos projetos. 
O primeiro estágio, segundo Kübler-Ross (2008), é a negação do diagnós-
tico da doença. Nesta fase, o paciente não acredita que sua vida agora está se 
findando e ele nega a realidade. Dito de forma mais pedestre, “a ficha ainda 
não caiu”. No contexto do projeto, se determinada célula na organização será 
desmanchada porque todo o trabalho ali será automatizado com um novo 
sistema de TI, por exemplo, é natural que a primeira reação seja a da negação 
13Gerenciamento de mudanças em projetos de TI
naquele ambiente. Frases como “Já tentaram isso antes aqui e não deu certo”, 
ou “Sempre foi feito assim, por que mudar agora?” são clássicas neste momento, 
porque a mudança proposta pode ser tão radical que os afetados por ela não se 
permitirão acreditar que tudo aquilo está acontecendo. Percepções como perda 
de emprego e de status e afastamento dos colegas de trabalho potencializam 
o comportamento de negação nesta fase. 
O estágio seguinte é o estágio da culpa e da raiva. Para Kübler-Ross 
(2008), muitas pessoas acreditam que estão sendo punidas por Deus ou 
outro ser sobrenatural em quem acreditam, por más atitudes do passado. 
No cenário corporativo, o afetado pela mudança começa a culpar a organiza-
ção. Nesta etapa, são comuns indagações como “Estou sendo afetado porque 
a organização está se vingando de mim por ter sempre sido franco”, ou “Por 
que fazer isso agora?”. Também é comum nesta fase as pessoas reclamarem 
até de coisas que não são o foco da mudança, evidenciando raivas até então 
não perceptíveis. Nas organizações é muito comum que os gerentes de projeto 
se tornem as pessoas mais odiadas da empresa, porque eles personificam a 
perda de emprego, de status, de poder, entre outras perdas percebidas e, por 
seguirem o caminho delineado no projeto, parece pouco se importarem com 
a vida e a até então “estabilidade” dos colaboradores que serão prejudicados. 
No estágio seguinte é comum o processo de barganha. No modelo de 
Kübler-Ross (2008), a pessoa que recebe o diagnóstico de uma doença incurável 
acredita que se implorar a alguma entidade em quem ela acredita, ela ficará 
curada. No cenário corporativo, é comum nesta fase as pessoas que serão 
afetadas pela mudança tentarem negociações com outras pessoas dentro da 
empresa com poder de decisão, ou mesmo, por meio das exceções, tentarem 
travar o processo da mudança. Exemplos clássicos da barganha são novas 
políticas internas que determinam o uso de novos sistemas, em que as pessoas 
fazem perguntas do tipo “Eu tenho mesmo de usar este ERP ou posso continuar 
usando as minhas planilhas que sempre funcionaram?”, ou “Por que tenho 
de preencher este documento eletronicamente? O papel era mais seguro!”.
O quarto estágio no modelo de Kübler-Ross (2008), o da depressão, pode ser 
causado pela situação que a própria doença impõe ao paciente (desconfortos, 
dores, efeitos colaterais de medicações, rotinas constantes de entrada e saída 
em hospitais etc.). No contexto empresarial, este momento caracteriza-se 
quando os afetados pela mudança, depois de terem tentado barganhar, aceitam a 
mudança mentalmente e param de expressar suas opiniões, tornam-se passivas 
e deixam de falar aquilo que pensam. Elas internalizam a mudança e entendem 
que, emocionalmente, não vale mais a pena lutar por aquilo, alimentando, 
internamente, sentimentos negativos e pesados contra a organização.
Gerenciamento de mudanças em projetos de TI14
O quinto e último estágio do modelo de Kübler-Ross (2008) é o da aceitação, 
a compreensão da finitude da matéria. No contexto organizacional, muito 
embora algumas pessoas afetadas pela mudança dentro da organização acabem 
se conformando, em muitos casos elas não se dão conta de que as mudanças 
podem ser positivas, como promoções, alterações nas rotinas de trabalho 
para melhor (em alguns casos, retirada de atividades meramente mecânicas 
e inclusão de atividades mais intelectuais, valorizando o conhecimento do 
colaborador). Neste momento, o papel do gestor é fundamental para abrir os 
olhos do colaborador para os pontos positivos da mudança. 
As mudanças em projetos, como visto neste capítulo, mostram que diversos 
temas orbitam a disciplina de gerenciamentode projetos. Por essa razão, as 
ciências da psicologia, da psiquiatria, dos recursos humanos, da administração 
e outras matérias correlatas serão, cada vez mais, importantes recursos, que 
entrarão na bagagem dos estudiosos de projetos e que, aplicados em momento 
oportuno, poderão contribuir significativamente para o sucesso das entregas 
de um projeto. 
BRASIL. Lei nº. 13.709, de 14 de agosto de 2018. Lei Geral de Proteção de Dados. Brasília, 
DF: Presidência da República, 2018. Disponível em: http://www.planalto.gov.br/cci-
vil_03/_ato2015-2018/2018/lei/l13709.htm. Acesso em: 25 set. 2020.
KHUONG, D. How to update the Baseline Schedule in Primavera P6? Project Control 
Academy. 7 jan. 2018. Disponível em: https://www.projectcontrolacademy.com/update-
-baseline-schedule-primavera-p6/. Acesso em: 25 set. 2020. 
KÜBLER-ROSS, E. Sobre a morte e o morrer. 9. ed. São Paulo: Martins Fontes, 2008.
LARSON, E. W.; GRAY, C. F. Gerenciamento de projetos: o processo gerencial. 6. ed. Porto 
Alegre: AMGH, 2016.
NOKES, S.; KELLY, S. O guia definitivo do gerenciamento de projetos: como alcançar resul-
tados dentro do prazo e do orçamento. 2. ed. Porto Alegre: Bookman, 2012.
PROJECT MANAGEMENT INSTITUTE (PMI). Guia PMBoK®: um guia do conjunto de co-
nhecimentos do gerenciamento de projetos. 6. ed. Newton Square, PA: PMI, 2017.
VARGAS, R. V. Gerenciamento de Projetos: estabelecendo diferenciais competitivos. 
9. ed. Rio de Janeiro: Brasport, 2018.
15Gerenciamento de mudanças em projetos de TI
Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a 
rede é extremamente dinâmica; suas páginas estão constantemente mudando de 
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade 
sobre qualidade, precisão ou integralidade das informações referidas em tais links.
Leitura recomendada
VARGAS, R. V. Manual Prático do Plano do Projeto: utilizando o PMBOK Guide. 6. ed. Rio 
de Janeiro: Brasport, 2018.
Gerenciamento de mudanças em projetos de TI16
DICA DO PROFESSOR
É muito comum que os clientes e até pessoas da equipe, depois de o projeto estar em 
andamento, peçam mais coisas ou tentem reduzir o escopo ou o tempo, em função de ajustes nos 
custos ou mesmo ocorrências vindas dos cenários interno e externo que impactem o projeto.
Para balizar as ações do gerente de projetos e de toda a equipe, o PMBOK estabelece processos 
para o controle integrado de mudanças. Dessa forma, é possível organizar o fluxo de 
solicitações, análises e tomadas de decisão em torno das mudanças propostas.
Nesta Dica do Professor, entenda o fluxo completo das solicitações de mudança.
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
1) Um importante componente do projeto é a chamada "linha de base". Ela é revisada 
ao longo do ciclo de vida de um projeto e possui outras atribuições e 
características. Julgue as afirmativas a seguir sobre essas atribuições e 
características: 
I- A linha de base do escopo fornece a definição do projeto e do produto.
II- A linha de base do escopo serve para avaliar o impacto das mudanças no 
cronograma do projeto.
III- O plano de gerenciamento de projeto, que funciona como entrada para o controle 
integrado de mudanças, possui, entre outros componentes, as linhas de base do 
escopo, cronograma e custos. 
A alternativa correta é:
A) I.
B) II e III.
C) I e III.
D) III.
E) II.
2) A revisão das solicitações de mudança em um projeto é parte integrante do processo 
de solicitação de mudança. E esse processo faz parte do controle integrado de 
mudanças. Nesse sentido, julgue as afirmativas a seguir: 
I- As mudanças precisam ser controladas ao longo de todo o ciclo de vida do projeto, 
sendo responsabilidade de todo o time de projeto.
II- As mudanças, mesmo antes de estabelecidas nas linhas de base, precisam ser 
controladas de modo formal pelo processo "Realizar o controle integrado de 
mudanças". 
III- O gerente de projetos é o responsável pelo processo "Realizar o controle 
integrado de mudanças", sendo conduzido do início ao término do projeto.
A alternativa correta é: 
A) III.
B) II.
C) I.
D) I e II.
E) II e III.
3) No processo de solicitação de mudança em um ambiente de gerenciamento de 
projetos, estão previstas algumas formas de registro dessas solicitações, assim como 
alguns personagens diretamente envolvidos na mudança. Com base nessa descrição, 
julgue as afirmativas abaixo:
I- As mudanças em um projeto devem ser sempre registradas por escrito, não 
havendo, portanto, nenhum espaço para que as mudanças sejam postas de forma 
verbalizada. 
II- O processo "Realizar o controle integrado de mudanças" sempre vai ter um 
Comitê de Controle de Mudanças (CCM).
III- Nos casos em que a aprovação de uma mudança tenha sido deferida pelo CCM, 
pode ainda haver a necessidade de aprovação do cliente ou do patrocinador.
A alternativa correta é:
A) I e II.
B) II e III.
C) III.
D) II.
E) I e III.
Linhas de base são como fotografias dentro dos projetos. Estas "fotografias" são de 
grande ajuda em todo o ciclo de vida de um projeto, principalmente quanto ao report 
do andamento dos trabalhos. A partir dessa afirmação, julgue as afirmações a 
seguir: 
4) 
I- Mudanças podem ser feitas nas linhas de base de custos dentro do processo de 
controlar custos do projeto.
II- O processo de controle de custos oferece o benefício de manter a linha de base de 
custos atualizada.
III- As previsões de custos são usadas como entradas do processo de controle de 
custos.
A alternativa correta é:
A) I.
B) II.
C) III.
D) I e III.
E) I e II.
5) O escopo em um projeto é a soma total de todos os produtos do projeto e seus 
requisitos. Seu monitoramento é fundamental e tem como ponto essencial o controle 
formal e aprovado de mudanças. Julgue as afirmativas a seguir:
I- Embora o controle do escopo seja necessário para garantir as entregas previstas, 
não existe linha de base do escopo. As linhas de base conhecidas em um projeto são 
somente as de custo e as de cronograma. 
II- Ao controlar o escopo do projeto, monitora-se tão somente o status do projeto.
III- A manutenção da linha de base do escopo atualizada é um benefício do processo 
de controlar o escopo do projeto. 
A alternativa correta é:
A) I.
B) II.
C) III.
D) I e II.
E) II e III.
NA PRÁTICA
A forma como se gerencia a mudança em um projeto pode ser determinante para o seu sucesso 
ou fracasso. Se não forem bem gerenciadas, as mudanças podem causar sérios 
estragos. Imagine, por exemplo, ter de refazer partes do escopo, porque uma parte interessada 
não foi envolvida no planejamento do projeto. O efeito cascata pode impactar, além do próprio 
escopo, o custo e o cronograma do projeto, aumentando os riscos de efeitos negativos. 
Na Prática, veja o caso do projeto de automação de bagagens no Aeroporto Internacional de 
Denver, nos EUA. 
SAIBA +
Para ampliar o seu conhecimento a respeito desse assunto, veja a seguir as sugestões do 
professor:
A relação entre as práticas de gestão de mudança e o sucesso de projetos organizacionais
Confira um estudo aprofundado sobre a relação entre as práticas de mudanças organizacionais e 
suas evidências sobre o sucesso dos projetos.
Conteúdo interativo disponível na plataforma de ensino!
O papel dos stakeholders no contexto do gerenciamento de projetos
Confira neste artigo como a influência das partes interessadas (stakeholders) pode afetar 
diretamente o projeto, causando mudanças que podem desde cooperar para seu sucesso até 
ameaçar as entregas previstas por meio de alterações indesejadas, gerando imprevistos 
desagradáveis que afetam a execução do projeto.
Conteúdo interativo disponível na plataforma de ensino!
A importância das mudanças
Confira no podcast a seguir como gerentes de projetos podem abordar os diferentes impactos da 
mudança em seus projetos.
Conteúdointerativo disponível na plataforma de ensino!