Você está na página 1de 4

Livraria Virtual PMI

2010 Cesar A. Portillo

Gerenciamento eficaz do escopo do projeto


Por Cesar A. Portillo, MSIT, PMP,ASQ-CMQ/OE,ASQ-SSG

Qualquer um que j tenha lido alguma literatura



Dr. Harold Kerzner (2006) define escopo
do projeto como O escopo a soma de todas as
entregas necessrias como parte do projeto. Isso
inclui todos os produtos, servios e resultados. " (p.
406).

sobre gerenciamento de projetos est certamente


familiarizado com a importncia de definir e
controlar o escopo do projeto apropriadamente. O
problema que o escopo pode ser mais difcil de
gerenciar do que voc imagina. Fontes de
Um Guia do Conhecimento em Gerenciamento de
dificuldade para
Projetos (Guia PMBOK)gerenciamento do
Quarta Edio, define o
escopo podem incluir
escopo do projeto como O
Mudanas no escopo do projeto trabalho que deve ser
um vendedor tentando
agradar um cliente ao
realizado para entregar um
podem impactar os custos e o
prometer mais
produto, servio ou
cronograma do projeto de maneira resultado com as
entregas; um gerente
snior que adiciona
diferente, dependendo de quando
caractersticas e funes
entregas ao projeto
especificadas. (p.429). Com
essas mudanas so implantadas
sem antes consultar a
essas duas definies
no ciclo de vida do projeto
equipe; um membro da
observamos que o escopo
equipe tcnica que
do projeto inclui todo o
decide adicionar algo ao
trabalho e entregas










escopo sem consultar a
necessrias para completar o
equipe; ou um cliente que percebe ou decide que o
projeto. No entanto, mudanas no escopo do
escopo precisa ser modificado.
projeto podem impactar de maneira diferente os
custos e o cronograma do projeto, dependendo de


Na vida real, mudanas no escopo so
quando essas mudanas so implantadas no ciclo
esperadas durante o ciclo de vida da maioria dos
de vida do projeto. Durante a iniciao do projeto,
projetos. Mudanas no escopo, implementadas
quando o escopo est sendo desenvolvido,
depois do inicio do projeto tero um maior
qualquer acrscimo no escopo do projeto ter um
impacto no custo e cronograma do projeto se
impacto menor no cronograma ou nos custos do
comparado mudanas implementadas durante a
projeto, uma vez que tanto o cronograma quanto a
fase de Iniciao ou de Planejamento;
a estimativa de custos no foram finalizados e
consequentemente, imprescindvel que o escopo
nenhum trabalho ter que ser descartado. Durante
do projeto seja bem definido antes do trabalho
a fase de planejamento, mudanas no escopo tero
comear. Caso a mudana no escopo seja
um impacto maior sobre o cronograma e o custo
necessria uma vez iniciado o trabalho, as partes
porque provavelmente vo exigir um planejamento
interessadas (principalmente o patrocinador, cliente
adicional. Esse planejamento adicional exigir
e equipe) precisam entender exatamente como o
pessoas, recursos e tempo extra para ajustar o
escopo adicional ir impactar nas datas das
plano. O planejamento adicional tambm pode
entregas do projeto, (cronograma) bem como os
incluir uma nova anlise do sistema de TI, mudana
recursos (custos).
nos desenhos de engenharia, requisies adicionais


O objetivo desse artigo ajudar o leitor a
de compras, s para citar alguns exemplos. Todas
definir melhor o escopo do projeto, apresentar
estas tarefas iro acrescentar custos ao projeto e
exemplos de algumas dificuldades no
geram atrasos no cronograma. Uma vez iniciado os
gerenciamento do escopo do projeto,as
trabalhos do projeto, e mais adiante no ciclo de
consequncias e recomendaes de como lidar
vida do projeto, mudanas de escopo iro
com essas dificuldades. Primeiramente, no entanto,
aumentar dramaticamente os custos e atrasar o
precisamos definir o escopo do projeto.
cronograma.



Outro impacto negativo devido a mudanas
no escopo do projeto o impacto sobre moral da
equipe. Na minha experincia, mudanas realizadas
tardiamente no ciclo de vida de um projeto podem
gerar sentimentos negativos dentro da equipe, o
que por sua vez pode ter um efeito negativo sobre
a dinmica da equipe, o trabalho em equipe, a
moral, e a organizao em geral. A seguir, so
listados alguns exemplos dessas situaes:


Alguns anos atras eu aceitei a posio, em
um recm-criado escritrio de projectos (PMO),
em um pequena empresa nacional de seguros. Nesta
posio, os meus deveres eram gerenciar programas
e projetos estratgicos, orientar os gerentes
juniores e ajudar a desenvolver os processos de
gerenciamento de projetos em toda a organizao.
Um dos maiores desafios da organizao era definir
e controlar o escopo, porque os funcionrios
acreditavam que o ciclo de vida de todos os
projetos incluam mudanas tardias no escopo,
nenhum projeto estava destinado a terminar no
tempo previsto e os custos no eram estimativas
precisas do trabalho necessrio para concluir o
projeto. Os funcionrios tambm acreditavam que o
trabalho do projeto era frustrante, e que todas as
tarefas do projeto deveriam ser feitas pelo menos
duas vezes. Quais foram as origens desses
problemas? As fontes de todas essas dificuldades,
por serem relacionadas ao escopo do projeto, eram
a m definio e controle.


Quando os projetos eram iniciados e
planejados nessa empresa, antes da criao do
PMO, somente alguns gerentes eram convidados
para as reunies de iniciao, planejamento ou
monitoramento e controle e, muitas vezes, esses
gerentes no eram se quer consultados. A excluso
de partes interessadas cruciais ao sucesso do
projeto, durante as reunies de iniciao,
planejamento, controle e monitoramento, resultou
na omisso de requisitos necessrios ao escopo. Por
exemplo, somente os gerentes foram convidados
para participar das reunies de planejamento
durante um projeto de TI para corrigir um
problema no sistema de faturamento no Estado do
Arizona; tambm foram deixadas de fora as pessoas
que processavam os formulrios de faturamento. A
falta de um programador ou especialista em
faturamento familiarizado com o sistema em
questo, resultou em um escopo de projeto sem a
incluso de todo trabalho necessrio para
completar o projeto. No final, o projeto foi iniciado
vrias vezes porm nunca foi concludo, pois teve
que ser replanejado e retrabalhado diversas vezes e
a gerncia decidiu paralisar o projeto uma vez que
os recursos eram necessrios em outro lugar.

Este projeto foi trabalhado por vrias vezes por


cerca de dois de anos, sem muito progresso. Aps
a implantao do PMO eu reiniciei esse projeto e
fiz com que todas as partes interessadas fossem
includas e/ou consultadas. Como resultado final, o
projeto foi entregue com xito pela equipe em
menos de dois meses. Esta no foi uma conquista
fcil, porque haviam muitos outros desafios dentro
da cultura organizacional, no entanto, a incluso de
todas as partes interessadas durante a iniciao,
planejamento, monitoramento e controle do
projeto permitiu equipe concluir o projeto
conforme o planejado.


Outro desafio nessa organizao foi
controlar o escopo aps a anlise do projeto e do
comeo do trabalho. Nessa empresa, os gerentes
viam os projetos como uma oportunidade de
concertar um problema sem incluir os custos dessa
correo em seus oramentos.


Por exemplo, um projeto de manuteno de
um sistema iniciado com a finalidade de atualizar o
sistema que gera a poltica de preo de automveis,
baseado no ano, marca e modelo (sistema de
classificao), em Nova York, acabou incluindo um
trabalho para corrigir os sistemas de classificao
em outros estados. Se o patrocinador do projeto,
ou outras partes interessadas, tivessem abordado
outros problemas relacionados com o sistema de
classificao, o trabalho necessrio para corrigir
esses problemas deveriam ter sido analisados no
incio do projeto e aprovados pelo patrocinador.
Sem essa aprovao, o trabalho do projeto para
esse projeto em particular, deveria incluir somente
o necessrio para corrigir o sistema de classificao
em Nova York. Porm, nessa organizao era
comum os gerentes requisitarem a equipe de TI que
trabalhassem em tarefas que resolveriam outros
problemas do sistema. Na perspectiva dos gerentes,
ter os funcionrios de TI trabalhando em outros
problemas conhecidos durante o projeto,
economizaria dinheiro (do seu prprio oramento)
uma vez que os tcnicos j estavam trabalhando no
sistema. Como no havia sido feita uma anlise para
avaliar o impacto do trabalho adicional, as mudanas
resultavam em outros problemas no sistema que
deveriam ser corrigidos. Alm de criar trabalho
extra e frustrao aos funcionrios, tambm
atrasava e aumentava os custos do projeto.
Novamente, com a implantao do PMO aplicando
polticas para limitar o trabalho do projeto ao
escopo do projeto, os projetos passaram a ser
entregues no prazo, os custos diminuram em cerca
de 60%, e os funcionrios se sentiram menos
frustrados.



Mas o que fazer quando as mudanas so
requisitadas pelo cliente ou pelo patrocinador? Na
minha experincia, isso pode acontecer por dois
motivos: (1) A equipe do projeto no se comunicou
efetivamente com o cliente tampouco coletou os
requisitos necessrios, e/ou (2) o ambiente de
negcios mudou portanto as mudanas de escopo
foram necessrias. Um outro exemplo: Eu trabalhei
em uma organizao que projeta e desenvolve data
centers. Alguns dos problemas dessa empresa eram
ocasionados porque os data centers eram
comercializados e vendidos por um vendedor e a
equipe do projeto tinha pouco ou nenhuma
participao na viabilizao do projeto e alm disso
a comunicao entre a equipe e o cliente era
ineficaz. O cenrio foi o seguinte: um data center foi
vendido ao cliente e tinha que ser entregue em um
perodo de 22 semanas. O vendedor prometeu
XYZ como entregas. O contrato foi assinado pelos
gerentes seniores, entretanto a equipe do projeto
no foi includa durante a fase de planejamento.
Neste caso, as questes referentes aos requisitos
do projeto no foram levantadas ou mesmo
pensadas antes que o contrato fosse assinado, o que
resultou em um escopo de trabalho incompleto.
Para corrigir essas deficincias de escopo, gerentes
seniores, muitas vezes concordavam em fazer
mudanas no escopo do projeto posterior anlise
e fase de planejamento e muitas vezes aps o
inicio do trabalho. Ns agora sabemos o que
acontece com os cronogramas e os custos dos
projetos por causa de mudanas no escopo aps o
inicio e o planejamento, por isso no vou repetir os
resultados aqui.

negativo nos projetos. Esse ambiente de projeto


disfuncional, como vimos no exemplo da companhia
de seguros, resultou em projetos atrasados com
oramento estourado e uma equipe infeliz. Ento, o
que podemos (gerentes de projeto e / ou
programa) fazer para ter certeza de que escopos
dos projetos sejam bem definidos de modo a
minimizar mudanas tardias durante o ciclo de vida
do projeto e para garantir que as partes
interessadas entendam os impactos das mudanas
no escopo?



Nessa mesma organizao, outra fonte de
mudanas tardias no escopo foram atribudas as
mudanas solicitadas pelo cliente; algumas delas
devido s lacunas criadas pela defasada definio do
escopo e planejamento (como mencionado
anteriormente) ou por mudanas no ambiente de
negcios do cliente. Como consequncia, o cliente
solicitava mudanas no escopo, a gesto autorizava
as mudanas sem consultar a equipe do projeto e
sem levar em considerao o efeito dessas no
cronograma e no custos do projeto. Porem, dentro
dessa organizao o o gerente snior e o cliente
no eram os nicos responsveis por mudanas
tardias no escopo do projeto. A equipe de
engenharia, por exemplo, frequentemente
implantava mudanas no escopo tardiamente no
ciclo de vida do projeto, a pedido do cliente ou por
causa de limitaes tecnolgicas. Estas mudanas
foram igualmente implementadas sem informar o
restante da equipe ou realizar anlises adequadas,
sendo que ambos resultariam em um impacto

3) Certifique-se que os requisitos do projeto sejam


compreendidos da melhor forma possvel. Os
requisitos do projeto sero mais claros durante
o planejamento do projeto, no entanto um
melhor entendimento durante a fase de iniciao
facilitar a definio de escopo durante a fase de
planejamento.

Recomendaes


O texto a seguir um resumo das atividades
que devem ser realizadas para garantir com que os
escopos dos projetos sejam bem definidos com o
intuito de eliminar ou reduzir drasticamente as
mudanas de escopo aps o planejamento do
projeto. Descrevo tambm, o que deve ser feito
para gerenciar efetivamente as mudanas de
escopo, caso estas sejam necessrias aps a
concluso do processo de planejamento do projeto.
Durante a Iniciao do Projeto
1) O projeto deve ser patrocinado por um gerente
snior, cuja funo remover obstculos que
poderiam ter impactos negativos sobre a equipe
do projeto e sobre as entregas (resultados).
2) Certifique-se que todas as partes interessadas
estejam includas no desenvolvimento do termo
de abertura do projeto (TAP) e no
desenvolvimento do escopo preliminar.

4) Desenvolver um TAP.
Durante o Planejamento do Projeto
1) Certifique-se de que todas as questes tcnicas,
de entregas e do cronograma que a equipe,do
projeto possui sejam respondidas.

2) Certifique-se de que todas as entregas sejam


acordadas pela equipe do projeto, patrocinador
do projeto e pelo cliente.
3) O TAP deve incluir uma lista completa de tarefas
e entregas que esto fora do escopo do projeto.
4) Certifique-se de toda esta informao esteja
atualizada no TAP.
5) Certifique-se que o TAP seja assinado pela
equipe do projeto, pelo patrocinador e pelo
cliente.
6) Certifique-se de que seja desenvolvido um plano
do projeto realista.
Durante a Execuo do Projeto
1) Certifique-se de que nenhum trabalho fora do
escopo do projeto seja feito.
2) Certifique-se de que todas as solicitaes de
mudana no escopo do projeto sejam
efetivamente comunicadas e compreendidas pelo
cliente.
3) Se um membro da equipe, gerente snior, ou o
cliente solicitar alteraes, certifique-se que
essas mudanas solicitadas sejam totalmente
analisadas e todos os impactos para o projeto
sejam totalmente explicados e aprovados pelo
patrocinador do projeto e / ou cliente.
4) Certifique-se que o TAP e o plano reflitam as
mudanas do escopo previamente aprovadas ou
seja, muito provavelmente ambos devero incluir
as mudanas no cronograma, recursos e custos.
5) Se um gerente snior reivindicar mudanas no
escopo previamente rejeitadas, discuta a questo
com o patrocinador do projeto e solicite sua
ajuda. Resolva o problema da melhor maneira
possvel e certifique-se que todas as partes
interessadas entendam os efeitos que as
mudanas exigidas causaro no projeto.
6) No mundo real, h momentos em que gerentes
seniores exigem a implementao de mudanas
de escopo independentemente do impacto no
projeto; em tais casos, voc tem duas opes: (1)
pedir para ser realocado para outro projeto ou
removido do projeto. Dada a situao economica
atual a ultima escolha pode ser difcil.; ou2)
implementar as mudanas, porm exigir com que
essas sejam aprovadas por escrito, juntamente
com os respectivos impactos no projeto, pelo
gerente que fez a requisio.
4

Concluso


Mudanas no escopo do projeto tero um
impacto sobre o cronograma do projeto e / ou
recursos. Os efeitos das mudanas de escopo
podem aumentar dramaticamente quanto mais
tardiamente forem implementadas no ciclo de vida
do projeto. Como gerentes de projetos ,
fundamental minimizar as mudanas de escopo,
principalmente aps o inicio do trabalho. Para isso,
devemos fazer o nosso melhor para desenvolver
escopos de projetos precisos, que podem ser
viabilizados com o envolvimento de todas as partes
interessadas nessa tarefa; todas as perguntas so
respondidas, e acordadas pelo patrocinador e / ou
cliente; todo trabalho fora do escopo e as entregas
so documentados; e, certificando-se que nenhum
trabalho fora do escopo deve ser feito como parte
do projeto. Se um gerente snior exigir mudanas
de escopo, certifique-se de analisar todos os efeitos
que essas mudanas tero no projeto, e garanta que
o gerente requerente assine e se responsabilize por
escrito por essas mudanas.
Referncias


Kerzner, H. (2006). Project management: A
systems approach to planning, scheduling, and
controlling. Hoboken, NJ: John Wiley & Sons, Inc.


Project Management Institute. (2008). A guide
to the project management body of knowledge (PMBOK
Guide) Fourth Edition. Newtown Square, PA:
Author.
Sobre o autor


Cesar A. Portelo possui mais de 13 anos de
experincia em gesto de programas/projetos nas
indstrias de tecnologia da informao, fabricao,
transporte e seguros. Possui tambm, vasta
experincia em treinamento e formao de
equipes, comportamento organizacional, mudana
organizacional, qualidade e Lean Six Sigma. O Sr.
Portillo bacharel em negcios e sistemas de
informao e mestre em TI. Tambm possui
certificao PMP, ASQ-CMQ/OE (Certified
Manager of Quality/Organizational Excellence) e
ASQ-SSGB (Certified
Six Sigma Green Belt). O Sr. Portillo candidato ao
doutorado de administrao de empresas, com foco
em mudana e desempenho organizacional, na
Baker College Center para Graduate Studies, Flint,
Michigan, USA. Contato atravs do e-mail:
cesarportillo@sbsglobal.net.