(Este conteúdo suplementar faz parte da metodologia TenStep Processo de
Gerenciamento de Projetos®)
Controlando
as pequenas Requisições de
Mudanças do Escopo
(5.2.P1)
Todo mundo pode reconhecer e
apreciar que o
processo de requisição de mudança do escopo deve ser invocado para
controlar as mudanças grandes do projeto. Mas, você poderá encontrar
resistência no gerenciamento formal para pequenas requisições de
mudanças do escopo. O cliente e os membros da equipe do projeto poderão
considerar que este é um encargo sem necessidade, mas mesmo assim as
mudanças deverão ser gerenciadas. Há três técnicas que podem ser
utilizadas para lhe auxiliar no gerenciamento das mudanças pequenas:
Obs. Nenhuma destas
opções indica que você não deve gerenciar e manter as mudanças do
escopo, estas técnicas adicionais são somente para lhe auxiliar. Se
nenhuma destas opções está sendo utilizada, o gerente do projeto deve
utilizar o processo normal de gerenciamento de mudanças do escopo para
todas as mudanças.
Não é simples ou prático fazer com que o Patrocinador aprove todas as
requisições de mudanças pequenas do escopo cada vez que uma for
solicitada. A equipe do projeto geralmente não tem acesso diário ao
Patrocinador, e é difícil chamar sua atenção para requisições pequenas.
A melhor maneira é agrupar as pequenas mudanças em um só pacote. Isto
significa que você documentará e manterá as pequenas mudanças do escopo,
o valor para o negócio e qual será o impacto no projeto. Então, quando
estas alcançarem um nível de limite acordado, deverá ser levada ao
patrocinador para aprovação. Se você não gerenciar as pequenas mudanças,
o escopo é susceptível para aumentar (Scope creep). Um benefício obtido
com a aprovação do patrocinador para todas as pequenas mudanças é que
ele também deverá aprovar os custos e as horas adicionais necessárias
para implementá-las.
Há uma segunda técnica para manejar as requisições de pequenas mudanças
do escopo. A
partir de um ponto de vista prático, normalmente
faz sentido para o Gerente do Projeto e
o Gerente do projeto do cliente ter a autorização para aprovar as
requisições de pequenas mudanças do escopo, dentro de um limite de horas
e custos de trabalho.
Esta autoridade de tomar decisões
não deve ser assumida. Esta autoridade deve ser delegada
explicitamente pelo patrocinador.
Contudo, isto supõe que o
projeto está dentro ou adiantado em relação ao cronograma, e que as
mudanças não farão com que o projeto exceda os custos, o esforço ou
a duração combinada. Por outro lado, se houver qualquer risco do
projeto não cumprir com os seus compromissos em termos de custos ou
duração, esta autorização não deverá ser utilizado - nem mesmo para
uma mudança de uma hora! Se o projeto estiver em risco, todas as
requisições de mudanças do escopo devem ser levadas ao Patrocinador
para serem aprovadas. Se o Patrocinador aprovar as mudanças, ele
também deverá aprovar os custos e as horas adicionais necessárias
para implementar as mesmas.
Em algumas organizações é comum alocar
uma reserva de contingência para manejar pequenas mudanças do escopo. Normalmente,
não é necessário ser justificada. A sua organização pode reconhecer que
algumas mudanças do escopo sempre são requisitadas e a organização
poderá alocar um percentual do orçamento do projeto para responder por
estas mudanças. Por exemplo, você poderá ter uma reserva para contingência de 5% do
valor total do orçamento, para realizar as pequenas mudanças. Se o
orçamento do seu projeto for de R$ 500.000,00, a sua reserva de contingência para
as mudanças do escopo deve ser de R$ 25.000,00. Mas, esta reserva de contingência é
o único valor alocado para as requisições de pequenas mudanças do
escopo. O cliente deve gerenciar a reserva de contingência para assegurar que todas
as pequenas mudanças poderão ser acomodadas. Se o cliente usar toda a
reserva de contingência cedo, ele não terá reserva de contingência suficiente para outras
requisições mais tarde. Isto coloca o cliente em uma posição de
racionamento para assegurar que somente as mudanças mais importantes
sejam aprovadas. Esta reserva de contingência é utilizada para as mudanças que
forem abaixo do limite acordado, em termos de custos ou horas. As
grandes requisições de mudanças do escopo devem ser feitas utilizando o
processo normal de gerenciamento de mudanças do escopo e ser avaliada e
aprovada pelo Patrocinador (Sponsor).
Não Utilize a Reserva de Contingência
Associada a Estimativa do Projeto para as Mudanças do Escopo
(5.2.P5)
Uma das etapas do
processo de estimação é adicionar
horas de contingência para refletir
o nível de incerteza associado com a
estimativa. Por exemplo, se as horas
de trabalho forem estimadas em 5.000
horas, você poderá adicionar 500
horas para a reserva de
contingência, o que reflete um fator
de confiança de 90%. Quando a
reserva de contingência for
aprovada, haverá uma pressão sobre o
Gerente do Projeto para que ele
utilize a reserva de contingência na
absorção das exigências adicionais.
O cliente poderá dizer, “Por
que devemos invocar o processo de
gerenciamento de mudanças do escopo
para esta mudança de 100 horas? Você
tem
em suas estimativas
500 horas de
reserva para
contingência!"
O gerente do projeto
deve resistir a tentação e a
pressão. A finalidade da reserva de
contingência é para refletir a
incerteza nas estimativas. Haverá
muitas oportunidades para utilizar a
reserva de contingência quando as
atividades requererem mais tempo do
que o esperado. Não utilize a
reserva de contingência para
realizar trabalho extra. Se as
estimativas do projeto forem
razoavelmente exatas, você deverá
enviar a reserva de contingência de
volta ao cliente no final do
projeto. (ou no caso de um cliente
externo, considerá-la como lucro)
Congelando as Requisições de Mudança do Escopo
(5.2.P6)
Você acha que enquanto está gerenciando a mudança do escopo de forma
eficiente, o cliente deve ficar livre para fazer as mudanças do começo
ao fim do projeto? É verdade que as mudanças rumo ao o final do projeto
tendem a requerer mais tempo e esforço para se acomodarem. Contudo, você
pode pensar que, enquanto o patrocinador está disposto a aprovar os
aumentos no orçamento e no tempo para realizar a mudança, o cliente deve
ser livre para fazê-la.
Isto é, de fato, normalmente verdadeiro, mas somente até um certo ponto.
Há um momento em um projeto onde simplesmente não vale a pena 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 valor alto para implementar, elas também representam uma
grande distração para a equipe do projeto.
Dependendo da natureza do projeto, este congelamento pode ser
implementado
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á focalizada na
implantação da solução. O gerente do projeto poderá micro gerenciar o
projeto para assegurar que todos os detalhes serão realizado 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 interrompitivos. A
equipe poderá perder o foco e ficar esvaziada mentalmente. Você poderá
descobrir que quando a equipe voltar novamente a fase de implantação,
eles poderão ser descuidados e cometer erros, devido que esta
seria a segunda vez que eles executariam as mesmas atividades.
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 implementada e estável.
(Isto se refere as requisições de mudanças e não se refere aos defeitos
- bugs. Os usuários poderão descobrir defeitos e erros durante os testes
que necessitarão ser reparados antes da implementação.)
Se você obtiver 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 implementada, 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.
Assegure-se que Somente o Patrocinador possa Aprovar Mudanças e Não os
Usuários e os Gerentes do Cliente
(5.2.P7)
Um problema típico em um projeto é que a equipe não compreende qual é o
papel (em relação ao Gerenciamento de Mudanças do escopo) do
patrocinador, do cliente e dos usuários finais. Em geral, o Patrocinador
do Projeto é a pessoa que está financiando o Projeto. Se for apenas um
cliente, ele deverá ser o Patrocinador do Projeto. Provavelmente eles
estão no topo da organização e não são fáceis de serem vistos de forma
cotidiana. Na maioria dos casos, o patrocinador designa outra pessoa de
sua organização para tomar a maioria das decisões no dia-a-dia.
As pessoas com quem a equipe do projeto
tende a trabalhar são freqüentemente usuários finais. Usuários finais
são as pessoas que utilizam as soluções que o projeto está construindo.
Os usuários finais são, normalmente, aqueles que fazem requisições de
mudanças do escopo do projeto. Não importa quão importante seja a
mudança para um usuário final - os usuários finais não podem tomar
decisões sobre mudanças do Escopo e não podem dar a aprovação a sua
equipe para fazer mudanças do mesmo.
No processo apropriado de gerenciamento
de mudanças do escopo, o patrocinador (ou designado) é quem deve dar a
aprovação. Os usuários finais podem solicitar mudanças do escopo do
projeto, mas não podem aprová-las. Os usuários finais não podem alocar
fundos adicionais para cobrir as mudanças e não sabem se o impacto no
projeto será aceitável. Se a mudança for importante o suficiente para o
Patrocinador, ele aprovará a mudança, juntamente com o seu orçamento e
prazo. Se a mudança não for suficientemente importante, a mesma não será
aprovada. Por tanto, será o Patrocinador quem tomará a decisão, e não o
Gerente de Projeto, os gerentes do cliente, os membros da equipe ou os
usuários finais.
Dizer 'Sim' as Requisições de Mudança do Escopo, Mostra um Bom Foco no
Cliente?
(5.2.P8)
O
Gerente do Projeto e a equipe às vezes pensam que estão focalizando o
cliente ao aceitar a mudança do Escopo e ao tentar entregar o projeto
dentro dos compromissos originais.
Contudo,
se o projeto for entregue atrasado ou
acima do orçamento, não é recomendável apontar todo o trabalho adicional
que foi incluído em relação “foco no cliente”. O Patrocinador do Projeto
e os Gerentes do patrocinador não querem ouvir sobre isto. Na maioria
dos casos, o projeto não será visto como bem sucedido, se ele não
cumprir com o prometido em relação ao orçamento e a data de entrega
original. O Patrocinador é o representante principal do cliente.
Permitir que o patrocinador tome todas as decisões sobre as mudanças do
escopo demonstra um bom foco no cliente. Se a equipe do projeto ou o
gerente do projeto aprovar as mudanças do escopo, eles não demonstram um
bom foco no cliente, especialmente se o projeto for entregue atrasado ou
acima do orçamento.
Incluir Benefícios
Diferidos
no Custo de Mudanças do Escopo
(5.2.P9)
O
patrocinador não pode tomar uma decisão informativa sobre uma requisição
de mudança do escopo sem ter o conhecimento dos benefícios da mudança
para empresa e o impacto no projeto. Tipicamente, o gerente do projeto
fornece informações sobre o impacto para o projeto, em termo de esforço,
custo e duração. Uma deficiência comum em determinar o impacto é que nas
estimativas não são incluídos os custos associados com os benefícios
diferidos do projeto. Em outras palavras, o projeto normalmente resulta
em um beneficio para a empresa. O beneficio normalmente começa
imediatamente após (ou um pouco antes) do tempo da solução ser
implementada. Se uma requisição de mudança do escopo resultar em atraso
do projeto, o custo da mudança do escopo deve incluir não somente o
custo da mudança atual, mas também o custo do atraso do benefício. Veja
o exemplo a seguir.
O
custo do seu projeto é de R$ 100.000,00. O beneficio do negocio é R$
5.000,00 por mês em
crescimento de
vendas (ou custos decrescentes). Durante o progresso do projeto, o
cliente fez uma requisição de mudança do escopo, que custará R$
5.000,00 e adicionou mais um mês no projeto. A mudança tem uma
recuperação de investimento de R$ 1.000,00 por mês.
Você poderá enviar a
requisição de mudança do escopo para o patrocinador com as referencias
de R$ 5.000,00 em custos e uma recuperação de investimento em cinco
meses de R$ 1.000,00 por mês. Mas, a parte que falta é o custo associado
com a implementação um mês atrasado. Neste caso, a implementação será
concluída um mês mais tarde e também o custo da empresa de R$ 5.000,00
em crescimento de vendas (ou
custos decrescentes), gerando um custo total da mudança de R$ 10.000,00.
O patrocinador poderá ou não aprovar a mudança. Mas, deverá ser feita
uma parte do relatório do impacto da mudança do escopo para o
patrocinador, incluindo o impacto do benefício desperdiçado associado
com o atraso no projeto para completar.
Deixe que o Patrocinador Tome as Decisões,
Normalmente Ele Não Tem Problema em Dizer Não
(5.2.P10)
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 ouvir 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. Mesmo que
seja difícil para o Gerente do
Projeto dizer “não”, o Patrocinador
do Projeto normalmente não tem
nenhum problema em dizer.
Fazer Com Que Todos Sejam Responsáveis pelo Processo de Gerenciamento
das Mudanças do Escopo
(5.2.P11)
Muitos processos de gerenciamento do
escopo funcionam bem ao nível do Gerente do Projeto, mas são
comprometidos pelos membros da equipe. Se o Gerente do Projeto reforçar
com diligência as regras de mudanças do escopo, o cliente poderá tentar
se dirigir diretamente aos membros da equipe para realizar as mudanças.
Por exemplo, quando um relatório (pré-definido e acordado pelo cliente)
é entregue para revisão, o cliente poderá pedir um segundo relatório
para fornecer mais claridade. O membro da equipe poderá concordar com
esse trabalho extra (que mostra o “foco no cliente”). O problema é que a
atividade é muito demorada, ou os recursos que poderiam ter sido
empregados em outro trabalho com alta prioridade, foram absorvidos em
atividades que estavam fora do escopo.
A questão é que todos necessitam ser
considerados responsáveis pelo processo de gerenciamento do escopo. Os
membros da equipe devem compreender o processo e porque o mesmo é
importante. A comunidade do cliente deve compreender o processo e a sua
importância. Não considere estes procedimentos como sendo de interesse
somente do Gerente do Projeto e do Patrocinador. Certifique-se de
comunicar os procedimentos a toda a equipe, incluindo o cliente.
Quando os clientes requisitarem mudanças
do escopo diretamente aos membros da equipe, o gerente do projeto deve
chamar a atenção do gerente do cliente ou do Patrocinador. Quando os
membros da equipe se comprometer com o trabalho que está fora do escopo,
lide com isso imediatamente. A primeira vez, isso poderá ser considerado
como uma questão de treinamento. Na próxima vez será um problema de
desempenho.
Para Projetos Grandes ou que
Envolvem Múltiplos Departamentos, Utilize um
Comitê de Controle de Mudanças
(5.2.P12)
Às vezes, em projetos muito grandes, o patrocinador do projeto não se
sente confortável para tomar decisões sozinho sobre as mudanças do
escopo. Esse poderá ser o caso, se o efeito da mudança impactar outras
organizações. Também, poderá ser o caso que múltiplas organizações
estejam envolvidas, ou contribuindo com fundos para o projeto e desejam
fazer algum comentário ao avaliar as requisições de mudanças do escopo.
Para estes casos, um grupo de pessoas poderá ser necessário para manejar
o processo de aprovação de mudanças do escopo.
Um nome comum dado a esse grupo é "Comitê de Controle de
Mudanças". Se existir um comitê, poderá ser mais difícil trabalhar.
Contudo,
o processo geral de gerenciamento da mudança do escopo não necessita
mudar dramaticamente.
Por exemplo, ainda há um documento que inicia a requisição de mudança do
escopo.
A equipe do projeto precisa determinar o impacto e o custo para o
projeto. O comitê
deve avaliar o impacto, o valor em termos de benefícios, o custo, o
sincronismo do projeto, etc. e então determinar se a requisição será
aceita ou não.
Os procedimentos de mudanças do escopo devem ser mais sofisticados para
o comitê. Por exemplo, você necessita esclarecer quem está no Comitê,
com que freqüências se encontrarão, como serão notificados em casos de
emergências, como tomarão as decisões (consenso, maioria, unanimidade,
etc.) e como o trabalho excedente será pago, etc.
Crie
uma
Lista de Pendências
de Requisições de Mudanças Que Não São Aprovadas
Durante o Projeto
(5.2.P13)
É 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 colocados 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.
