Você está na página 1de 9

Os 7 Passos da Gesto de Projetos

Este texto pode ser livremente distribudo desde que citada a fonte/autoria.
Fernando C Barbi, PMP
fernando@gestaodeprojeto.info
O enxugamento dos quadros de pessoal e o aumento da necessidade de especializao tcnica tm
levado muitas empresas a recrutar no mercado profissionais por perodo determinado apenas para a
execuo de projetos especficos. Neste contexto, entender o processo de gerenciamento de projeto
tem se tornado vital para organizaes a medida em que mais e mais novos negcios vo se
revestindo da aura de projeto e passam a exigir um cabedal de tcnicas gerenciais que nem sempre
esto disponveis nas empresas.
Um projeto um empreendimento temporrio, com data de incio e fim, cujo objetivo criar ou
aperfeioar um produto ou servio. Gerenciar um projeto atuar de forma a atingir os objetivos
propostos dentro de parmetros de qualidade determinados, obedecendo a um planejamento prvio
de prazos (cronograma) e custos (oramento). Ou seja, dadas as metas e as restries de recursos
e tempo, cabe ao gerente de projetos garantir que ele atinja os objetivos propostos.
Muitas empresas esto adotando a estrutura de projetos no seu dia-a-dia. Desde a concepo de um
novo software at a implantao dos procedimentos de atendimento a clientes, desde a construo
de uma ponte at a reviso dos processos de venda com vistas a aumentar a taxa de fechamento de
negcios, muitos empreendimentos no seio das organizaes se enquadram na classe de projetos.
Nos mais diversos setores, a abordagem de gerenciamento de projetos est ganhando terreno por
permitir um melhor uso dos recursos para se atingir objetivos bem definidos pela organizao.
Sabendo da importncia de se gerenciar bem um projeto, vamos ver os passos que nos levam a
melhorar nossas habilidades de gerenciamento de projeto.
Tudo comea com a contratao de uma empresa para tocar o projeto ou a definio dos
colaboradores internos que integraro a equipe de projeto. Num dia determinado, inicia-se o projeto.
Este momento deve ser formalizado com um documento que se chama de termo de incio do
projeto. Em projetos maiores, deve ser um documento assinado pelos patrocinadores e pelo
gerente do projeto. Para projetos menores, pode ser um e-mail que o gerente envia aos
patrocinadores, copiando os demais envolvidos, para notificar que naquele momento se inicia o
projeto e todos esto envolvidos com a sua execuo.
1. Escolha e adote uma metodologia
Uma metodologia um processo a seguir que d maior controle sobre os recursos que sero
utilizados no projeto. Controlando melhor o processo a equipe ser mais eficiente pois entregar o
projeto com maior grau de acerto em termos de prazos e custos. O bom uso de uma metodologia
importante porque permite evitar prticas que levam ao insucesso e com isso reproduzir o sucesso.

www.gestaodeprojeto.info

A opo pela metodologia deve ser tomada a partir de alguns fatores: as exigncias de cada
mercado em que a empresa atua, a disponibilidade de mo-de-obra e a cultura organizacional
necessria para adot-la. Para exportar software, muitas empresas nacionais tm se alinhado com o
padro CMM para dar credibilidade a sua iniciativa em mercados dominados por indianos e chineses,
que j possuem capacitao neste padro. Em ltima instncia, uma metodologia um conjunto de
regras de como conduzir um projeto com sucesso. Pode at no ter siglas bonitas, mas importante
que j tenha se mostrado eficiente dentro da sua empresa, de preferncia em situao similar que
voc est vivendo no seu projeto atual. Para quem gosta de siglas, h uma que est bem na moda:
a UML (Unified Modeling Language) que, como j diz o nome, no uma metodologia mas uma
linguagem, uma forma de se documentar um projeto. Uma linguagem de modelagem uma
notao, em geral feita com smbolos grficos, que se usa para traduzir processos abstratos. A
empresa que criou a UML desenvolveu uma metodologia conhecida como RUP, Rational Unified
Process.
2. Comunique-se: no s o peixe que morre pela boca!
Quando falta comunicao, os boatos e outras formas de rudos tomam seu lugar. Na falta de verso
oficial, ficam circulando informaes que podem minar a moral da equipe e levantar suspeitas sem
fundamento. O gerente de projeto deve evitar esse tipo de prtica, conhecida por "rdio-peo",
dando informaes claras e confiveis sobre o status do projeto. Certamente esta uma rea em
que a diplomacia essencial. Se h um problema, o gerente de projetos pode e deve no s falar
sobre ele, mas tambm informar que est trabalhando na soluo, e no apenas comunicar que o
problema existe. Problemas sem uma perspectiva de soluo so angustiantes e causam um
desconforto na equipe que muitas vezes desnecessrio.
A criao de relatrios de progresso do projeto ajuda no processo de comunicao, sobretudo por
que torna o processo impessoal e mais objetivo. Imagine o efeito de um email onde se critica um
membro da equipe pelo atraso do projeto. Imagine a mesma informao vinda de um relatrio em
que a data de trmino real de uma tarefa est em branco: objetivamente a situao a mesma, o
indivduo no fez a sua parte, mas no caso do email a pessoa envolvida pode se melindrar. No
relatrio, temos um dado objetivo, que salta aos olhos, mas que no gera ressentimentos.
3. Defina o escopo do projeto e detalhe as atividades
O escopo do projeto o trabalho que deve ser realizado para se obter um produto ou servio com
determinadas caractersticas e recursos. Comece por definir o que deve ser feito e o que no deve.
Esse processo nos permite entender os contornos do projeto e traar uma linha divisria entre o que
deve ser feito e o que no deve ser, pelo menos neste momento. Muitos novatos se perdem em
discusses interminveis sobre recursos do produto final que o tornariam perfeito. Sempre me
lembro de um amigo muito experiente que, ante a minha nsia em acertar todos os detalhes logo de
cara, me dizia que o timo inimigo do bom, ou seja: enquanto perseguimos o timo nos
distanciamos de algo que est bem mais prximo, o bom, que temos mais chance de conseguir
atingir. Com o tempo achei uma forma elegante de contornar as exigncias de projeto sem

www.gestaodeprojeto.info

decepcionar os clientes: no que no faremos o que est sendo pedido, mas devemos ver que este
recurso cabe na verso 2, 3, etc... mas no cabe na verso 1, que o que estamos tentando
desenvolver neste momento ! Afaste o fantasma da perfeio.
Para voc no se perder numa lista interminvel de caractersticas da verso 1, uma boa idia
pedir ao cliente que liste s que o que absolutamente essencial. Claro que se voc der a ele 30
minutos para responder, tudo ser absolutamente essencial. No adianta, temos de ser realistas, o
tempo curto temos de escolher s o que realmente importante. Se escrever cortar como
dizem os grandes escritores, a arte de se definir o escopo do projeto passa por saber o que
abandonar e o que reter do universo de necessidades do cliente.
Bom, definido o escopo do projeto, podemos passar para a fase de detalhamento das tarefas. O
objetivo chegar ao WBS (Work Breakdown Structure), onde temos as unidades de trabalho com
tempo medido em dias ou horas de trabalho. Como regra, uma atividade deve ocupar entre 4 e 80
horas, nem mais, nem menos. Em paralelo, deve ser elaborado um oramento levando em conta
quantas horas de cada profissional sero necessrias. Veja um modelo simples:

Para montar este modelo, voc precisa saber o custo-hora de cada profissional e estimar o tempo
que cada um gastar no projeto. Os profissionais podem estar envolvidos em outros projetos e
quando o programador est cuidando de uma fase do projeto A, o gerente de projeto j pode estar
planejando o projeto B, s voltando ao projeto A quando for para entregar ao cliente e obter a sua
aprovao, sobre o que falaremos mais adiante.
Estas estimativas so mais precisas medida em que se avana no detalhamento do projeto. Para
estimativas iniciais, admite-se uma variao de -25% a +75%. Na fase de planejamento, o
oramento deve ter uma variao de -10% a +25%. Lembre-se que nesta fase, o gerente de projeto
j envolveu quem realizar a tarefa. Na estimativa final, a margem de erro menor: de -5% a
+10%. Aqui, o conhecimento do gerente de projeto de situaes anteriores far diferena. Eu, por
exemplo, sei que quando lido com determinados clientes, haver tanto overhead administrativo,
como dezenas de reports para cima e para baixo antes que cada passo importante seja dado, que eu
j estimo 50% a mais do tempo nas tarefas em que o cliente est diretamente envolvido. Vai da
experincia do gerente, mas nessa hora, se a empresa tm um histrico de projetos semelhantes,

www.gestaodeprojeto.info

vale a pena se basear neste background, mesmo que tenha sido com outras equipes e outros
gerentes de projeto.
Um dos grandes segredos do gerenciamento de projetos proteger o seu escopo. Projetos que ficam
mudando o escopo durante sua execuo tm srias dificuldades em cumprir o cronograma e
estouram o oramento. O risco mais comum o que se chama de scope creep, quando o escopo
vai crescendo a medida que o cliente vai entendendo suas necessidades e reformulando seus
objetivos. H quem chame este problema de Jacques. Seria uma homenagem a um francs
ilustre ? No, trata-se apenas da forma como o cliente costuma abordar o assunto: j que o
sistema faz isso, ele pode ento fazer aquilo. Agora eu quero aquilo tambm incorporado ao
projeto. O gerente do projeto deve ter calma e analisar com cuidado cada demanda: ao rejeitar um
pedido, ele pode se indispor com o cliente, mas se aceitar ele pode estar dando um tiro no prprio
p, j que o prazo e oramento no sero to elsticos quanto as exigncias. Devemos sempre
contar com uma certa margem de manobra, mas nos tempos atuais, em que eficincia a palavra
que est na ordem do dia, no h muita gordura para queimar e os compromissos assumidos pelo
gerente podem se transformar num sacrifcio, muitas vezes desnecessrio, para toda a equipe.
Em projetos de software, o scope creep uma situao to comum que no d para come-los
sem tomar algumas precaues. O primeiro cuidado negociar a forma de remunerao: fixa ou
varivel. Se for fixa, o risco das mudanas est toda com o gerente do projeto, se for varivel, o
cliente assume os custos extras. Mesmo neste caso, o gerente do projeto deve cuidar para que o
cliente seja informado a priori dos novos custos. Por precauo, eu sempre redijo um adendo ao
escopo colocando o que ser feito, em quanto tempo e a que custo. Colho a assinatura do cliente e
s depois autorizo a execuo da tarefa. Gerentes financeiros no participam destas reunies e
podem alegar que no h previso de recursos para os extras, ento mantenha-os informados das
novas condies para evitar dissabores na hora do recebimento.
O segundo cuidado documentar meticulosamente o escopo do projeto. Este documento resume o
que ser feito, com que caractersticas e com que recursos. Ele um quase-contrato mas no traz
as clusulas de resciso e as penalidades. Neste momento, tudo est bem e todos concordam. S
que, na cabea de cada um, h uma imagem diferente do que ser o produto final. medida que
este produto vai tomando forma e sendo entregue, o cliente vai vendo que o que ele imaginou no
bem aquilo e podem comear as decepes.
A satisfao do cliente depende em muito do que ser dito e prometido no que se chama de prvenda. neste momento que o gerente de projetos deve entrar em cena para meticulosa,
cuidadosa e disciplinadamente escrever tudo o que o sistema deve ter e fazer. Este processo o
planejamento de escopo e num software dele abrange das telas at os relatrios. Esta tarefa pode
ser delegada para um analista, mas a responsabilidade no sai nunca das mos do gerente. Eu
costumo especificar toda a interface dos usurios com o sistema: telas e relatrios. Depois de
colocar tudo no papel, o gerente deve obter do cliente um de acordo, de preferncia assinado no
final do documento em que todas as pginas sero rubricadas com um visto para que ele tome
cincia do que ser feito. No h palavras para expressar a importncia deste planejamento em que

www.gestaodeprojeto.info

as expectativas sero levantadas e moldadas, de forma que, diante do produto final, o cliente no
possa se dizer decepcionado.
O terceiro cuidado definir prioridades. O gerente deve ter a sensibilidade para identificar quais so
os requisitos obrigatrios e quais os desejveis, marcando cada um segundo com a sua prioridade.
Isso evita que algum arbitre o que importante no lugar do cliente. H gerentes de projeto que
vo mais longe e pedem ao cliente para definir o que ele considera sucesso do projeto. Por
exemplo, num sistema em que havia desperdcio de 30% da matria-prima, foi considerado sucesso
reduzir esta taxa para 15%. Mas este nmero ainda alto, diria voc. Sim, mas o cliente
considerou que uma reduo de 50% dos desperdcios j representaria benefcios suficientes que
compensariam os investimentos no projeto. Alm do mais, lembre-se de que: o timo inimigo do
bom. Em suma: definir o escopo, no fundo, saber o que deve ser feito para atender a necessidade
do cliente.
4. Conhea os envolvidos e monte seu time
Todos os envolvidos no projeto so os "stakeholders". Nesse grupo esto no apenas os membros
da equipe, mas tambm os clientes e fornecedores envolvidos. Dentro da empresa do cliente, h
uma pessoa que se destaca por ser a patrocinadora ("sponsor") do projeto. Ela que cria as
condies para a contratao do projeto, mesmo que no seja ela que v usar o produto final.
importante que o gerente do projeto conhea os interesses de todos os envolvidos. Imagine como
arriscado contar com um membro da equipe que no est disposto a colaborar. Ele pode ser um
problema mais do que uma soluo dentro do grupo: sabendo disso, melhor pensar em chamar
outra pessoa. Eu passei por uma situao destas quando fui destacado para gerenciar um projeto
onde havia um colaborador mais antigo e que entendia que ele quem deveria estar gerenciando.
Eu no percebi seu ressentimento a princpio e medida que o projeto avanava esta pessoa se
tornava um problema cada vez maior, na medida em que, no s ele no fazia a sua parte, como
minava os demais membros da equipe contra minhas decises. Um dia, eu o chamei e abri o jogo.
Ele ento me explicou o que estava sentindo e fizemos um acordo: ele se enquadraria para
completar o projeto, que graas a ele j estava atrasado, e eu o apoiaria junto direo para que
recebesse seu prprio projeto para gerenciar. claro que manter um profissional com este tipo de
atitude no bom negcio para a empresa no longo prazo, porque cedo ou tarde ele vai acabar
atirando contra a prpria equipe novamente, s para mostrar que as coisas tm de ser feitas do
jeito dele.
No processo de definio do escopo, as habilidades necessrias vo ficando mais claras. Nesse
momento, importante formar uma equipe com competncia diversificada e com experincia nas
reas de atuao do projeto. Em projetos em que h muito conhecimento tcnico envolvido, surge a
figura do "lder de projeto", um profissional com grande conhecimento tcnico e com capacidade de
liderana entre os tcnicos. Em geral um profissional snior, com credibilidade junto aos demais
tcnicos e com muita bagagem. A experincia desse especialista pode economizar muito tempo e
dinheiro no projeto. D-lhe voz ativa, cobre dele insights que voc no tem e respeite a sua opinio.

www.gestaodeprojeto.info

S assim ele estar sempre do seu lado, mesmo quando voc errar.
5. Desenvolva o cronograma junto com quem pe a mo na massa
Uma vez que temos as tarefas definidas a partir do escopo, temos de estimar a durao de cada
uma. Procure fazer esta estimativa de tempo de execuo com a ajuda de quem est escalado para
executar o trabalho. Ao mesmo tempo em que essa pessoa quem melhor sabe quanto tempo
precisar, ela estar se comprometendo com um prazo para a sua execuo. Por outro lado, quando
se trabalha com consultores externos, o custo ser funo direta do tempo estimado para a
execuo do projeto. Ao fixar o cronograma, o profissional est dando por tabela um oramento da
sua parte.
Veja estas atividades que representam as linhas gerais de um projeto de sistema:

Note que alm de saber o que deve ser feito, as tarefas tm trs propriedades importantes:
durao, inter-dependncia e responsvel. A durao importante mas se as tarefas podem ser
realizadas em paralelo, como ilustrado neste caso onde h duas figuras: o analista e o
programador, a durao total do projeto encurta. Dessa possibilidade de trade-off entre tempo e
recursos alocados, alguns gerentes acreditam que se o projeto est atrasado, ento basta colocar
mais gente que o problema se resolve. Isso raramente ajuda uma vez que com mais gente, os
problemas de comunicao aumentam e o projeto que j est atrasado atrasa mais ainda. Trazer
mais gente pode ser til quando se precisa de especialistas em temas que os membros no
dominem. A rigor, se o planejamento foi bem-feito, j se sabe que esta mo-de-obra ser recrutada
em algum momento do projeto. A atitude de simplesmente aumentar a equipe para acelerar a
produo que est errada e deve ser combatida. S que alguns gerentes de projeto medem seu
poder pelo tamanho da equipe que gerenciam. Voc pode imaginar como isso acaba: contratamos
mais pessoas, eu fico mais poderoso e temos todas as explicaes para os atrasos, afinal o projeto
era mesmo muito grande.
O gerente de projetos deve trazer sua experincia para corrigir as expectativas muito otimistas de

www.gestaodeprojeto.info

algum colaborador mais afoito. Sim, h quem estime 50 horas e depois, com a maior tranqilidade,
cobre pelas 120 horas que foram necessrias para realizar a tarefa. Ele s errou em 140% ! Se o
preo fechado, o risco fica todo com o consultor, mas a sua boa-vontade e a qualidade do produto
final podem sofrer em decorrncia da pressa. Se a remunerao ficar vinculada ao tempo de
prestao de servio, o contratante precisa de um mecanismo de controle minimamente confivel.
Eu no uso uma frmula geral, prefiro trabalhar segundo as caractersticas do profissional mas de
todos exijo um relatrio de horas que contm o dia, data de hora e incio, tempo de trabalho e a(s)
tarefa(s) realizadas no dia.
Se no planejamento da semana h tarefas que no foram realizadas, na reunio de avaliao, eu
pergunto porque a coisa no seguiu o ritmo programado e quanto isso impacta na data final de
entrega. Procure estabelecer pontos de controle, "checkpoints", que so datas onde se medir o
andamento do projeto em face do cronograma que havia sido programado. Nestas datas, pode-se
estar apenas executando-se uma verificao do progresso das atividades ("milestones") ou pode
haver entrega de produtos ou sub-produtos (deliverables) tais como desenhos, especificaes,
prottipos, modelos, etc...
Quem j reformou ou construiu uma casa sabe que esta to trivial experincia de gerenciamento de
projeto pode acabar mal. Quantas histrias existem de gente que foi pagando o pedreiro sem atrelar
os pagamentos a entregas de tarefas determinadas. Nestas histrias tristes, o dinheiro acaba antes
da obra, e o pedreiro some, deixando o cliente sem dinheiro e sem a sua casa. Tudo porque ele no
cuidou de atrelar entregas de tarefas a pagamentos, no criou pontos de controle que lhe dariam
visibilidade do atraso. Sabendo antes que a vaca est indo para o brejo o cliente pode optar por
apertar o pedreiro ou suspender os trabalhos enquanto ainda tem dinheiro, que poder ser usado
para pagar uma equipe mais eficiente. verdade que em projetos de TI nem sempre d para trocar
o pedreiro porque h muito conhecimento e estudo envolvidos. Mas por isso mesmo, temos de ser
muito mais cuidadosos na monitorao para saber em que momento o projeto comea a atrasar e
como fazer para recuperar o ritmo no futuro prximo.
6. Monitore os riscos e seja pr-ativo
Agora que todos sabem o que devem fazer, importante mitigar os riscos que podem impedir o bom
desenvolvimento do projeto. Desenvolva uma lista de fatores de risco e um plano para lidar com
eles. Mas lembre-se de que so duas coisas
A monitorao dos riscos envolve acompanhar o status de cada risco e as opes de aes definidas
para enfrent-los, caso eles venham a se tornar problemas reais. A monitorao tambm se
preocupa em avaliar a probabilidade de ocorrncia de um risco, qual o seu impacto no andamento do
projeto e como contorn-lo. Por exemplo, numa determinada tarefa crtica a contratao de dois
profissionais pode parecer um exagero mas o gerente do projeto sabe que se algo acontecer nesta
rea do projeto o impacto ser grande no restante. Os profissionais passam a ser um backup do
outro dentro da linha de que quem tem um, no tem nenhum.

www.gestaodeprojeto.info

Voltando ao nosso projeto de exemplo, chamo a ateno para um recurso que o MS Project tem e
que deve ser usado para se identificar riscos. Veja a tela do diagrama de Gantt que obtivemos a
partir da lista de tarefas que elaboramos acima:

Note que h uma seqncia de tarefas que quando alinhadas compem o prazo de durao do
projeto todo. Destaquei o incio e o final s para que voc perceba que se trata de uma srie de
processos que devem ser gerenciados mais de perto uma vez que o atraso em algum deles
acarretar o atraso do projeto todo. Por isso que se chama este de caminho crtico. Os riscos que
esto embutidos nestas tarefas so os que se deve gerenciar mais de perto, de forma mais prativa.
O controle dos riscos o processo de executar o plano de aes e divulgar seus relatrios de status.
Inclui tambm possveis mudanas no plano de riscos, e eventualmente at nos planos do projeto.
Essas mudanas so referentes a recursos, funcionalidades ou cronograma.
7. Formalize o incio e o encerramento do projeto
O incio do projeto um momento solene. O patrocinador deve formalizar a todos os envolvidos que
o projeto est iniciado e o cronmetro est correndo. Muita gente no gosta de se preocupar com
isso, mas imagine que haja resistncia de setores da empresa que se opem ao projeto. Sem um
documento que atesta que o projeto comeou, o gerente pode no conseguir apoio algum. Alm
disso, este documento funciona como um cumpra-se de uma autoridade da empresa: no cabe
discutir a ordem, o projeto comeou e todos os arrolados devem participar.

www.gestaodeprojeto.info

Outro momento importante o do encerramento do projeto. preciso formalizar o final para que
fique claro para todos os envolvidos, especialmente para o cliente, que o projeto est concludo e
que novas necessidades sero atendidas em um novo projeto. Qualquer extenso ou alterao
dever ser orada e todo o ciclo se inicia novamente. Com relao manuteno do sistema
entregue, no se pode considerlo um projeto na medida em que, a princpio, trata-se de um
processo contnuo. O que pode ocorrer definir-se projetos ao longo da vida til do sistema com o
objetivo de melhor-lo. Por exemplo, a atualizao dos equipamentos eletrnicos (avinicos) de
um avio para auxlio ao vo um projeto que se distingue da sua manuteno rotineira.
Ao final faz-se tambm uma reunio de avaliao dos erros e acertos da equipe.
Chamadas de reunies "post-mortem", elas servem para se gerar uma lista de "melhores prticas"
contribuindo para a formao de uma base de conhecimento que poder ser muito til em projetos
futuros. Da minha experincia pessoal, posso dizer que tirei grandes lies quanto s "piores
prticas", atitudes e decises que se mostraram ruins e que devem ser evitadas em projetos futuros.
Concluso
Acima de tudo, gerenciar projetos planejar e acompanhar a execuo com "um olho no peixe e
outro gato". O gerente do projeto deve se manter alerta e flexvel com os acontecimentos do dia-adia mas deve estar sempre se reportando ao plano inicial para no perder o controle. A principal
qualidade do gerente de projeto saber se comunicar bem com todos. Ele o ponto focal das
informaes, nele convergem as informaes que ele depois dever processar e divulgar para todo o
restante da equipe.
O segredo envolver a equipe, cliente e fornecedores de tal forma que todos se sintam diretamente
responsveis pelo sucesso do projeto. Como diz aquele velho ditado caipira, "quando todos
empurram na mesma direo, n h carroa que no saia do atoleiro".

Visite: www.gestaodeprojeto.info

www.gestaodeprojeto.info

Você também pode gostar