Você acha que enquanto está gerenciando a mudança do escopo de forma eficiente, o cliente deve ficar livre para fazer mudanças do início ao final do projeto? É verdade que as mudanças rumo ao final do projeto tendem a requerer mais tempo e esforço para se estabelecerem. Contudo, você pode pensar que, enquanto o patrocinador estiver disposto a aprovar o orçamento adicional e prorrogar o tempo do projeto para a realização de mudanças, o cliente deve ficar livre para executá-las.

Isto é, normalmente genuíno, mas somente até um certo ponto. Há um momento em um projeto aonde simplesmente não é mais viável fazer mudanças, ou realizar exigências adicionais. Este é o momento de comprometer-se com o congelamento das mudanças. As novas mudanças não têm somente um custo alto para implantar, elas também representam uma grande distração para a equipe do projeto.

Dependendo da natureza do projeto, este congelamento pode ser implantado depois que os testes de aceitação dos usuários forem aprovados e a equipe do projeto estiver se preparando para a fase de implantação. Neste período, a equipe estará focada na implantação da solução. O gerente do projeto poderá micro gerenciar o projeto para assegurar que todos os detalhes serão realizados nas datas programadas. Neste momento no projeto, os requisitos para fazer mudanças no escopo não são somente caros, mas também muito interruptivos. A equipe poderá perder o foco e ficar esvaziada mentalmente. Você poderá descobrir que quando a equipe voltar novamente a fase de implantação, ela poderá ser descuidada e cometer erros, devido ao cansaço e a frustração de ter que executar as mesmas atividades pela segunda vez.

A melhor abordagem é manter estas mudanças (modificações) em uma lista de pendências (Backlog)  e gerenciá-las como se fossem requisições de aperfeiçoamentos depois que a solução estiver implantada e estável. (Isto se refere as requisições de mudanças e não aos defeitos - bugs. Os usuários poderão descobrir defeitos e erros durante os testes que terão que ser reparados antes da implantação.)

Se você obter um consenso sobre a data de congelamento das mudanças, a sua equipe poderá focalizar na entrega da solução atual. Naturalmente, como todos os processos, se houver uma requisição de mudança que deve ser implantada, você ainda poderá deixar que o patrocinador tome a decisão. Entretanto, obter o consenso sobre uma data de congelamento, eliminará a necessidade de mudanças adicionais na maioria dos projetos.

Deixe que o patrocinador tome as decisões, normalmente ele não tem problema em dizer NÃO

Uma das coisas fundamentais em reforçar a disciplina de ter o Patrocinador aprovando as mudanças do escopo, é que, a não ser que a mudança seja muito importante, mas, normalmente o patrocinador dirá “não”. Mais uma vez, o patrocinador geralmente é alguém em posição elevada na organização e não quer saber sobre requisições de mudanças pequenas do escopo. Eles querem o projeto original cumprido de acordo com os compromissos originais relativos ao custo, esforço e duração. Às vezes é difícil para o Gerente do Projeto dizer “não”, mas o Patrocinador do Projeto normalmente não tem nenhum problema em dizer.

Crie uma lista de pendências de requisições de mudanças que não são aprovadas durante o projeto

É possível que o patrocinador não aprove requisições de mudanças do escopo durante o projeto, mas poderá existir requisições válidas que poderão ser executadas mais tarde. Este tipo de requisições de mudanças deve ser colocado numa lista de pendências. Depois que o projeto for completado e a solução for transferida para o departamento de suporte, poderá haver uma oportunidade para fazer aperfeiçoamentos, ou estabelecer um projeto como fase II. Novamente, estas mudanças serão implementadas somente se forem aprovadas pelo patrocinador e disponibilizado a verba.

Para maiores detalhes sobre as mudanças de escopo de um projeto, veja >> Gerenciando as mudanças