O que Gesto de Projetos ?

Porque a maioria dos projetos falha ou cancelada?

Que habilidades deve ter o candidato ideal a Gestor de Projetos?
Quais os documentos recomendados pelas boas prticas de Gesto de Projetos?
Afinal, o que preciso saber para acertar mais nos meus projetos?
Se voc veio at este site provvel que tenha uma ou algumas destas dvidas.
Aqui ns discutimos estes e outros assuntos para que voc tenha sucesso nos seus projetos e na sua carreira.
Nesta pequena entrevista, o editor do site fala sobre o comeo na carreira e algums dicas para
quem quer entrar na rea de projetos.
Se voc no conhece bem os termos usados na rea, d uma lida nos Conceitos Importantes.
Se voc quer saber o que preciso para ser um bom Gestor de Projetos d uma olhada no texto sobre as 6
habilidades.
Se procura dicas de como proceder para melhorar as chances de sucesso, leia este texto sobre os 7 passos.
Se quiser saber quais os documentos crticos para um projeto, veja os 8 documentos.
O conhecimento sobre Gesto de Projetos pode ser organizado em 9 reas de conhecimento.
Se quer dicas para se aprofundar, d uma olhada no texto para Saber mais.
Temos um Arquivo de material para download.
O contedo deste site gratuito e feito a partir das contribuies de usurios como voc que nos mandam
suas dvidas e comentrios pois a partir deles que elaboramos e melhoramos o nosso contedo.
-Conceitos Importantes
* Este texto pode ser livremente citado e distribudo desde que identificada a fonte/autoria.
Fernando C Barbi, PMP
fernando@gestaodeprojeto.info
Os primeiros conceitos que voc precisa conhecer so: Projeto, Risco, Escopo e Patrocinador.
Um Projeto um empreendimento que se caracteriza por ser evento temporrio e
ter um objetivo nico e bem definido. O projeto no se confunde com tarefas rotineiras
de operao normal da empresa.
Quando ocorre esta confuso, o projeto corre riscos desnecessrios.
Um risco todo evento que pode impactar o projeto, para o bem e para o mau.
Se o risco pode benfico ao projeto, chama-se oportunidade.
Normalmente associamos a palavra "risco" a conseqncias negativas,
por isso uma das nove reas de conhecimento recebe o nome de "Gesto de Riscos".
Um risco constante que sejam feitas alteraes no escopo do projeto.
O escopo (scope) tudo o que deve ser feito para se atingir o objetivo do projeto,
o que o projeto deve entregar.
Os entregveis (deliverables) so documentos, prottipos e todos os demais
intangveis (tais como treinamento e homologao) que o projeto deve entregar quando
for completado. Escopo no "tudo o que o cliente quer" poque muitas vezes ele no
sabe tudo o que deve ser feito!
O GP deve alinhar o escopo com o patrocinador do projeto.
O patrocinador (sponsor) quem apia o projeto dentro da organizao.
Pode ser um diretor que tambm autoriza os pagamentos, ou um gerente que
se reporta diretoria, o importante que ele ou ela apie o projeto tanto
em termos financeiros quanto com respaldo poltico, garantindo os recursos
(verba e tempo do pessoal) quando necessrio.
O patrocinador um interessado (stakeholder) do seu projeto, assim
como so os membros da equipe que o executa, os usurios que como clientes
demandam o produto que o projeto deve entregar. Os terceirizados que
participam do projeto ofertando servios para se fazer este produto tambm so
interessados. No caso de uma obra de engenharia civil que ter impacto na
vizinhana, como o caso de uma represa, os moradores do lugar afetado tambm

devem ser considerados como interessados e seus questionamentos devem ser

endereados. Veja mais sobre Anlise de Stakeholders.
Para que o projeto acontea dentro de padres previsveis preciso que parta
de uma metodologia de trabalho. A metodologia o conjunto de processos,
documentos e regras para o desenvolvimento do trabalho. A empresa pode j dispor
de um conjunto de regras operacionais que o projeto pode usar para criar a sua
prpria metodologia. O importante que haja um conjunto formalizado de regras
de trabalho.
Tambm importante formalizar os objetivos, intermedirios e finais, do projeto.
So os marcos (milestones) do projeto: eventos de completamento de uma etapa.
Usa-se o conceito de marco para criar visibilidade dentro do processo. Atrasos na
entrega de um marco devem indicar problemas no projeto ou na sua conduo, j
que esta deveria ter incorporado os atrasos ao planejamento, possivelmente revendo
tambm cronograma e oramento.
Um cronograma (schedule) uma sequncia de datas de execuo das tarefas necessrias para
a realizao do escopo do projeto, listadas no WBS. O WBS (Work Breakdown Structure)
o detalhamento de todas as atividades do projeto. Normalmente se faz numa planilha e fica
a cargo do responsvel pela tarefa identificar todas as subtarefas que deve realizar para que
determinado objetivo seja atingido. O oramento (budget) a relao de custos associados s
tarefas especificadas no WBS.
Tanto o cronograma o quanto oramento devem ter um baseline de referncia.
O baseline um modelo, um guia do que foi planejado j com todas as alteraes
aprovadas. O benchmark um tipo de baseline aceito na indstria como um padro a
ser seguido. Para se chegar a um desempenho de benchmark, costuma-se seguir as melhores
prticas. As melhores prticas (best practices) um conjunto de procedimentos
entendidos como ideais para realizar uma determinada atividade.
Quando uma mudana solicitada, o GP deve verificar o impacto que ter sobre
o seu baseline. Se o impacto for significativo ele deve submeter o pedido de mudana
a um comit de controle. O comit de controle de mudana (change control board
ou CCB) o grupo autorizado a estudar e aprovar as solicitaes de mudana no projeto.
Este grupo pode ser composto apenas do patrocinador, se este tiver as condies para
assumir o nus da mudana.
Numa empresa com maior maturidade em Gesto de Projetos costuma-se encontrar um PMO.
O PMO (Project Management Office) um grupo que excerce desde funes de
treinamento e padronizao das metodologias at efetivamente gerenciar os projetos.
A existncia de um PMO indica um alto nvel de maturidade da empresa em gerenciamento de
projetos uma vez que ela busca, ao estabelecer um PMO, otimizao pelo compartilhamento
de recursos e aumento da qualidade da gerncia pela especializao de funes.
Normalmente, num PMO cada profissional cuida de um determinado aspecto de todos os projetos
da organizao, como finanas, planejamento, aquisio, pessoal, etc...
-Porque falham?
Porque falham os projetos?
* Este texto pode ser livremente citado e distribudo desde que identificada a fonte/autoria.
Fernando C Barbi, PMP
fernando@gestaodeprojeto.info
Quando um projeto encerrado prematuramente, cancelado ou termina sem que seus objetivos
tenham sido atingidos, considera-se que ele fracassou. O Gestor do Projeto (GP) tem que se prevenir,
o que no muito difcil j que as causas so quase sempre as mesmas, uma (ou vrias) destas:
Causa #1. Expectativas irrrealistas
Se verdade que o segredo da felicidade a administrao das expectativas, se voc
no administrar as suas (e as do patrocinador), voc pode acabar se decepcionando com
resultados que, sob uma outra tica, seriam considerados bons.
Seja por uma falha de compreenso do escopo ou por um cronograma muito apertado, os projetos
que no tm slidas bases realistas tendem a falhar mais do que os projetos que levam em conta a

cultura da empresa e as restries impostas naquele momento.

Mas como saber se as minhas expectativas so realistas? Pense em discut-las com profissionais
mais experientes que conhecem os problemas que voc ter de resolver e que conhecem a organizao.
s vezes o procedimento mais simples fica travado pela burocracia e quem j passou por isso pode
ajud-lo contornar os obstculos.
Causa #2. Planejamento deficiente
Depois de estudar muita estatstica cheguei a uma concluso: planejamento muito mais arte do que cincia.
Voc pode aprender os mais sofisticados mtodos de previso, saber calcular o desvio-padro de uma estimativa
e usar as ferramentas mais sofisticadas e mesmo assim errar. Porqu? Em geral por que partiu de premissas
erradas. Voc espera que determinado fornecedor entregue uma tarefa com uma eficincia de 95% e
ele falha em 30% das vezes. Sua margem de manobra que era de 5% estourou e voc deve acomodar
os 25% (30%-5%) que aconteceram de forma imprevisvel.
Vivemos num mundo complexo em que os eventos podem ser influenciados por acontecimentos de uma
forma numa vez, mas por outra bem diferente na prxima ocorrncia. Quando aproximamos um processo
tendemos a buscar uma funo com forma linear, algo como y=Ax+B. Neste modelo, a varivel x que se
observa explica a varivel y segundo os parmetros A e B. Mas se houver outro fator, digamos z, que
afeta y e no colocamos na equao (porque quando medimos x e y, z era desprezvel), podemos incorrer
em grande erros nos casos em que esta varivel omitida, z, assuma valores significativos.
Nos processos de Gesto de Riscos, deve-se identificar os fatores relevantes (no nosso caso, x e z) e
procurar medir, ou estimar, qual o possvel impacto no resultado final (no nosso caso, y).
Causa #3. Falha no controle de desempenho
No h nenhuma desculpa aceitvel para se perder o controle sobre o desempenho da equipe de
projeto e de outros interessados que afetam diretamente os resultados. Alguns GPs preferem relatrios,
outros vo para o contato cara-a-cara. No importa como, mas vital que este processo de acompanhamento
seja permanente e regular. Se a tarefa parece cansativa, automatize-a mas faa.
As pessoas respondem de forma diferente quando so monitoradas, como nos ensina o "efeito Hawthorne".
Neste experimento, o mero fato de estarem sendo acompanhados por pesquisadores fazia com que os
trabalhadores de uma fbrica produzissem mais. Tentaram variar a luminosidade do ambiente de trabalho
e descobriu-se que com mais ou menos luz, as pessoas eram mais produtivas. Ficou ficou claro que no era
a luz que influa nos resultados, mas o ato de estar sendo monitorado que fazia o pessoal dar duro.
Desempenho pode ser algo complicado de medir. Num projeto de software, usa-se muito como mtrica
a quantidade de linhas de cdigo escritas. Mas um programador pode entregar mais cdigo e ao mesmo
tempo cometer mais erros do que os outros. Um bom indicador deve ser simples, mas no to simples
que esconda o que se deseja realmente medir, que a quantidade de cdigo de boa qualidade.
Lembre-se da velha frmula: "tudo o que se deseja obter deve ser medido".
Causa #4. Falta de liderana efetiva
Eu encontrei vrios GPs que vinham de organizaes matriciais fortes e acredito que foram muito
influenciados por elas. Parece que nestas organizaes, as pessoas demoram mais a responder
por receio de entrar numa rea alheia. No limite, a guerra entre os "feudos" impede que boas iniciativas
inter-departamentais decolem. As pessoas esto reprimidas e, se o GP "cria da casa", ele pode
apresentar hesitaes "inexplicveis".
Estas pessoas usualmente apostam que muitos rudos se dissipam "sozinhos", o que obviamente no
acontece. O rudo, ie. um pequeno problema dentro da equipe, pode ser mais do que isso. Pode ser
que no seja to pequeno mas que assim parea por uma falha de percepo do GP. Quanto maior o
projeto, maior a inrcia (leia-se, resistncia a mudanas) e maiores as chances de rudos.
Quanto mais rpido o problema for endereado pelo GP, melhor para todos.
Alm disso, a verdadeira liderana inspiradora e viral: um bom lder acaba criando um ambiente propcio
ao surgimento de novos lderes a sua volta. Uma dica: se voc topar com uma equipe cheia de pessoas
motivadas e que apresentam um claro interesse em liderar, voc tem uma boa pista de que o
GP um bom lder.
Causa #5. Falta de skills dos membros do time de projeto
Quando contratou um profissional, o GP pode ter sido enganado pensando que o candidato sabia fazer
uma coisa que na verdade no sabe, mas isso difcil de ocorrer se voc tomar as devidas precaues
como estabelecer uma descrio funcional ("job description") bem detalhada e que especifique uma srie
de habilidades que possam ser verificadas. Discutimos tcnicas para isso em outro artigo.
Mas mesmo que voc tenha feito tudo certo, comeou o projeto, definiu e plataforma de desenvolvimento
(digamos por exemplo, Windows), contratou experts e depois, por uma daquelas voltas da vida, descobre
que o produto deveria ser desenvolvido em outra plataforma (por exemplo, Unix) que sua equipe no
conhece. O que fazer? Trocar ou retreinar?
Depende dos recursos de tempo e verba disponveis mas via de regra prepare-se para mudar boa parte
da equipe, sem se deixar levar por sentimentos de amizade ou pena. Melhor seria especificar o pagamento
de um bnus de desligamento antes de contratar o profissional. Quanto antes ficam claras as regras do jogo,

melhor para todos. No final, a opo simples: agir quando ainda h tempo ou ver o barco afundar.
Causa #6. Falta de motivao do time e dos interessados
O moral da equipe sofre muito quando a gesto fraca. Imagine se o Joo, que um gerente jnior
importante para o projeto acabou de casar e est sendo pressionado pela esposa a procurar outro emprego
que pague mais. O GP, temendo perd-lo, lhe promete um bnus mas no pede autorizao da direo
nem com do pessoal de RH. Ele pensa que no necessrio j que o projeto tem oramento para isso.
Joo d duro, se esfora e o projeto um sucesso. Na hora H, o bnus no vem como prometido e Joo
recebe um tapinha nas costas. As explicaes so as mais diversas: no temos oramento para isso,
poltica de empresa no fazer estas coisas, voc no seguiu os procedimentos da empresa, etc...
Isso pouco importa para quem no recebeu a devida recompensa.
O que acontecer com o desempenho de Joo depois disso? Isso para no mencionar a perda de credibilidade.
Tenho uma regra: quando um bom profissional est entregando abaixo do seu potencial o GP tem "culpa no
cartrio": ele deveria ter se informado sobre o que est acontecendo. No caso do Joo, ele agora est
saindo mais cedo para ir a entrevistas de emprego em outras empresas. O GP deveria ter tomado as devidas
medidas corretivas, como se informar sobre a possibilidade de bonificar o pessoal.
Moral de histria: se voc no puder oferecer um bnus, no o faa. Se fizer, tem de cumprir.
Causa #7. Falta de apoio dentro da organizao
Apoio aqui a fora poltica que um diretor, scio ou presidente pode dar ao projeto. A figura mais importante
para o projeto a do patrocinador que deve comunicar aos demais membros da organizao a importncia da
iniciativa para a empresa, cobrando deles a ateno necessria para que as tarefas sejam concludas.
Por exemplo, imagine instalar um sistema financeiro numa empresa pequena com um grande nmero de pedidos
processados manualmente todos os dias. Haver uma sobrecarga do pessoal do departamento pelo tempo
necessrio ao teste e implantao do projeto.
Esse tempo extra pode exigir a contratao de pessoal temporrio para fazer as tarefas do dia-a-dia
enquanto o pessoal da casa usa a nova ferramenta. Sem apoio de algum com poder de deciso
pode ser difcil contratar esta equipe para ajudar na transio ou para fazer o pessoal do departamento
financeiro separar duas horas do seu dia para testar e aprender a usar a nova ferramenta.
Causa #8. Falta de recursos
Apesar de algumas pessoas no tomarem o cancelamento de um projeto por falta de fundos como um
fracasso, entendo que de alguma forma o GP poderia ter se antecipado ao problema. Qualquer companhia
pode enfrentar momentos difceis, que exijam a reduo rpida de custos. No entanto, isso dificilmente
acontece do nada (como, por exemplo, na mini-crise de 11 de setembro de 2001).
Em geral os sinais esto por toda parte e cabe ao GP estar ligado neles. Por exemplo, se parte dos recursos
para um projeto ainda devem ser captados no mercado e os juros (leia-se, a taxa Selic) sobem, provvel
que surjam dificuldades para realizar esta captao.
E como tratar o problema com a equipe? melhor abordar o tema claramente numa reunio do que deixar
os rumores de demisses tomarem conta das mentes de pessoas que deveriam estar concentradas em
obter resultados.
Se haver um corte de oramento, o GP deve se antecipar e planejar como se poderia reduzir custos e seguir
com o projeto. No limte, ele deveria pensar em encerrar o projeto deixando resultados palpveis, mesmo
que no os originalmente esperados. A partir de algo concreto mais provvel que se possa retomar
o projeto quando o ambiente econmico melhorar.
Mas se os recursos faltarem porque a empresa est vendo outros projetos como prioritrios, o GP deve
lutar por seu projeto e mostrar o que j se ganhou com ele e quanto ainda deve ganhar se complet-lo.
Se o patrocinador receber um plano para seguir com o projeto com custos reduzidos, isso pode evitar a
suspenso/cancelamento do projeto.
Concluso
Sejam quais forem as causas do cancelamento do projeto, recomendo que sempre se faa uma reunio
de encerramento para se discutir o que se pode aprender com essa experincia. Quando h confiana
e respeito mtuo a equipe enfrenta as consequncias do fracasso de forma unida. Cabe ao GP informar
aos demais os propsitos da reunio, seno corre-se o risco dos mais exaltados buscarem culpados,
o que cria um clima desagradvel que impede o dilogo.
Sugiro que cada um faa o seu mea culpa, levantando apenas os pontos em que deveria ter agido de outra
forma, sem tentar explicar seus atos em resposta a erros dos outros. Assumindo que o grupo fez tudo o que
podia ser feito para evitar o fracasso, o GP deve tirar as lies devidas e resumi-las para todos. Assim
aumenta-se as chances de sucesso no prximo projeto.
De toda forma, planejamento e comunicao so as duas atribuies crticas que o GP no deve delegar.
-As 6 Habilidades...

As 6 habilidades do Gerente de Projeto*

* Este texto pode ser livremente citado e distribudo desde que identificada a fonte/autoria.
Fernando C Barbi, PMP
fernando@gestaodeprojeto.info
preciso ser sincero, honesto, transparente.
O lder tem de dar ao grupo o que ele precisa, no o que ele quer.
Tem de satisfazer s necessidades, e no os desejos.
fundamental consquistar a confiana da equipe e conhecer seus limites.
No interferir no poder do outro, deix-lo trabalhar.
As pessoas precisam ser encorajadas.
Carlos Alberto Parreira
Depois destas palavras sobre liderana, veremos que um bom Gestor de Projetos (GP) deve ser BLONDE:
1. Bom comunicador.
Tanto oralmente quanto por escrito, o bom GP deve ter grande habilidade para se comunicar,
transmitir e receber mensagens dos demais membros da equipe e dos interessados.
Comunicar um processo bi-direcional: no basta enviar a mensagem, crtico que ela seja recebida com preciso.
2. Lder, nada a ver com chefe, liderar motivar, mostrar como se fez pelo exemplo.
Por lder entende-se algum que:
(1) tem um senso claro de misso a cumprir, com foco e comprometimento,
(2) serve de modelo ao personificar os valores que defende,
(3) seja capaz de ter empatia, saber se colocar no lugar do outro e
(4) seja orientado a resultados, de forma a ser admirado (e no temido) pelos liderados.
3. Organizado, sabe onde est cada informao quando precisa dela.
A organizao permite identificar rapidamente onde esto os dados necessrios para a tomada de deciso.
Os mecanismos de busca textual tornam certos procedimento catalogrficos menos importantes do que j foram.
Uma dica usar os servios de hospedagem de documentos online (como o Google Docs) para ter acesso aos
dados necessrios relevantes a qualquer hora e de qualquer lugar.
4. Negociador, no ser um tirano ou um fraco.
Mas o que negociar? O que voc pensa quando est negociando?
Negociar trocar algo de valor para mim por algo de valor para voc.
Numa negociao, a percepo de valor fundamental: o que escasso para mim pode no ser para voc.
Tambm importante que o lder tenha como meta sempre o ganha-ganha, em que os dois lados ganham.
Na prxima negociao, ao invs de pechinchar tente extrair mais do outro lado pelo mesmo valor, para ele
o servio adicional que ele lhe prestar pode custar menos do que o valor que voc iria pedir de abatimento e
ambos saem satisfeitos. A alternativa "eu ganhar em cima de voc", que traz ressentimentos e
baixa produtividade.
5. Desembaraado. O bom GP pr-ativo e toma iniciativas por conta prpria.
Pessoas tmidas podem ter dificuldade em abordar uma pessoa que esteja com desempenho fraco
para cobrar resultados. O GP no pode ter este tipo de auto-bloqueio, mas tambm no precisa ser
o cara mais popular, como o "rei da festa". Ele precisa ter iniciativa para agir a partir dos dados de
desempenho coletados e sem o receio de ser mal recebido pelos demais interessados do projeto.
6. tico. Respeitando as regras de conduta da profisso e as normas do grupo, o GP respeitado por sua equipe.
Apesar de no termos tido bons modelos em nossos lderes polticos recentemente, a tica importante.
ela que nos protege da cobia alheia desenfreada e d chances a todos de competir. Sem tica, o grande
quebraria o pequeno, o forte subjugaria o fraco e o mundo seria um lugar pior para todos, mesmo
para os fortes e poderosos. Um bom princpio tico nos foi legado pelo filsofo alemo Emanuel Kant:
"Haja como se suas aes fossem se tornar normas de conduta para todos". Um sbio colega me deu a sua verso:
"Haja de forma a poder explicar para a seus filhos o que voc faz, sem passar vergonha".
Concluso

Uma pessoa que tenha todas estas habilidades costuma ser um bom GP.
Mas se isso no for possvel e voc tiver de escolher, provavelmente o mais importante aspecto seja o da liderana.
--

Os 7 Passos...
Os 7 Passos da Gesto de Projetos*
* A verso original deste texto foi publicada no site da Microsoft como
"Os 7 Passos do Gerenciamento de Projetos". Esta verso mais atual.
Este texto pode ser livremente citado e distribudo desde que identificada 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.
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 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, 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 pr-venda. 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 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. 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 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.
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 pr-ativa.

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.
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-a-dia 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, clientes 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".
-Os 8 Documentos...
{ Estamos preparando esta pgina. }
Os 8 Documentos mais importantes e que devem existir em todo projeo so:
1.Termo de Abertura ("Project Charter")
2.Detalhamento das Atividades (WBS)
3.Cronograma
4.Oramento

5.Plano de Resposta aos Riscos

6.Matriz de Responsabilidades
7.Termo de Aceite
8.Termo de Encerramento (TE)
Alm desses documentos, o projeto deve ter ainda registros de eventos, tais como: atas de reunies, timesheets
(relatrio de trabalho detalhando data, incio, fim, tarefa executada, cdigo do projeto) e fichas de controle, como
auditorias de qualidade, relatrios de desempenho, etc...
Todos os documentos juntos compem o Plano de Projeto.
-As 9 reas...
{ Estamos preparando esta pgina. }
As 9 reas de conhecimento da Gesto de Projetos
Segundo o PMBOK (PM Book Of Knowledge) do PMI, Instituto de Gesto de Projeto,
as nove reas de conhecimento relevantes para a Gesto de Projeto so:
1.Gesto de Escopo
Conjunto de atividades para identificar e controlar o escopo do projeto e suas mudanas.
2.Gesto de Tempo
3.Gesto de Custo
4.Gesto de Qualidade
5.Gesto de RH
6.Gesto de Comunicao
7.Gesto de Riscos
Conjunto de aes para identificar, medir e tratar os riscos de forma a minimizar os impactos no sucesso do projeto.
Para saber mais como reduzir os riscos do seu projeto, leia sobre como reduzir riscos.
8.Gesto de Aquisio
9.Gesto de Integrao
Processos que integram todas as reas acima.
-Caindo na Real
Uma empresa com muita experincia em aplicativos para a web, a 37 Signals, colocou
num livro (Getting Real ou Caindo na Real) os princpios de trabalho que usa para desenvolver
seus projetos e recrutar talentos. A leitura rpida e o texto flui bem. As idias deles so simples,
quase senso comum mas que frequentemente esquecemos quando estamos no meio da
empolgao/agitao do projeto.
Eles vo na linha do "simplifique ao mximo a sua vida": mantenha seu escopo bem delimitado,
sua equipe pequena, etc.... uma forma de produzir com muita eficincia e agilidade mas se
aplica a situaes especficas, projetos de menor envergadura. Se os conselhos nem sempre
podem ser seguidos risca, os princpios de simplicidade e foco num objetivo bem definido
devem estar em todos os projetos.
Vale uma leitura cuidadosa do texto mesmo que seu negcio no seja desenvolver software para web,

nesse caso atenha-se aos princpios.

-Saber mais...
A carreira em Gestor de Projetos vale a pena j que, alm dos desafios profissionais,
serve de vitrine para posies executivas, o que bom para sua carreira, mas pode ser
mau se voc no estiver preparado...
Para saber mais, voc pode desde comprar um bom livro, fazer um curso livre ou at
mesmo pensar numa ps-graduao (MBA) em Gesto de Projetos. A deciso depende
dos seus objetivos, da sua pacincia e do seu bolso.
As recomendaes de livros variam de acordo com seu conhecimento atual e seus interesses.
Aqui vo algumas dicas para os trs grupos: iniciantes, profissionais com experincia e
profissionais que buscam a certificao PMP:
Livros que recomendo para comear a estudar Gesto de Projetos:
Caindo na Real
Verso on-line em portugus de acesso gratuito em http://gettingreal.37signals.com/GR_por.php
Arte do Gerenciamento de Projetos
Scott Berkun. Editora Artmed. ISBN: 9788577801701. (Submarino)
MBA Compacto: Gesto de Projetos
Eric Verzuh. Editora Campus. ISBN: 853520637X. (Submarino)
Livros para quem quer se aprofundar em Gesto de Projetos:
Gesto De Projetos - As Melhores Prticas
Harold Kezner. Editora Bookman. ISBN: 8536306181
Projetos de Investimento na Empresa
Juan Carlos Lapponi. Editora Campus. ISBN: 9788535224344. (Submarino)
Indicadores de Gerenciamento de Projetos
Armando Terribili Filho. Editora M.Books. ISBN: 978857680087-3.
Livros que recomendo para certificao PMP:
PMBOK, 4 edio (PMI Marketplace)(Amazon)
PMI. ISBN: 9781933890517.
PMP Exam Prep Rita's Course In A Book For Passing the PMP Exam (Amazon)
Rita Mulcahy. RMC Publisihing. ISBN: 1932735003.
Cursos preparatrios para certificao PMP
As sees do PMI de cada estado do Brasil ministram cursos preparatrios.
Para ver os caprtulos do PMI pelo Brasil, consulte o site http://www.pmi.org.br/.
Em So Paulo, veja o site em www.pmisp.org.br.
MBA Executivo Internacional em Gerenciamento de Projeto na FGV SP
MBA Executivo em Gerenciamento de Projetos (Maring, PR)
MBA - Gesto de Projetos - Instituto Mau de Tecnologia em SP
Ferramentas para GP
http://basecamphq.com/
Basecamp um sistema de gesto de projeto que deve ser usado por todos da
equipe de projeto para facilitar os apontamento das tarefas e o acompanhamento
das atividades.