Apostila Compass - Fundamentos de Gerenciamento de Projetos

FUNDAMENTOS DE
GERENCIAMENTO DE PROJETOS
Sumrio
Conceitos de Gerenciamento
de Projetos......................................................................................................5
O QUE UM PROJETO?.............................................................................7
GERENCIAMENTO DE PROJETOS............................................................10
Processos
de
Iniciao........................................................................................................21
Processo
de
Planejamento................................................................................................28
Execuo,
Monitoramento
e Controle
do Projeto......................................................................................................83
RELATRIO DE STATUS DO PROJETO....................................................94
Projeto...........................................................................................................94
Data...............................................................................................................94
Nmero..........................................................................................................94
Principais Entregas realizadas...................................................................94
% completo do projeto REALIZADO...........................................................94
% completo do projeto PLANEJADO..........................................................94
Valor Planejado (PV)....................................................................................94
Custo Real (AC)............................................................................................94
Valor Agregado (EV)....................................................................................94
Oramento do Projeto (BAC)......................................................................94
Data de Trmino prevista............................................................................94
Copyright Compass International Knowledge Center
Indicadores ..................................................................................................94
Anterior.........................................................................................................94
Atual..............................................................................................................94
Sinalizador....................................................................................................94
Variao de Custo (CV)................................................................................94
Variao de Prazo (SV)................................................................................94
Performance de Custo (CPI)........................................................................94
Performance de Prazo (SPI) .......................................................................94
Estimativa de Custo no Trmino (EAC)c....................................................94
Estimativa de Prazo no Trmino (EAC)t.....................................................94
Aes Corretivas..........................................................................................94
FORMULRIO DE SOLICITAO DE MUDANA NO PROJETO.............98
Projeto...........................................................................................................98
Data da Solicitao......................................................................................98
Nmero..........................................................................................................98
Solicitante.....................................................................................................98
Descrio da Mudana................................................................................98
Justificava para a Mudana.........................................................................98
Impactos no projeto e medidas para mitigao dos impactos................98
1. Escopo......................................................................................................98
1.1. ...............................................................................................................98
2. Tempo........................................................................................................98
2.1. ...............................................................................................................98
3. Custo.........................................................................................................98
3.1. ...............................................................................................................98
4. Qualidade..................................................................................................98
4.1. ...............................................................................................................98
5. Riscos do projeto.....................................................................................98
5.1. ...............................................................................................................98
Aprovador.....................................................................................................98
Data da Aprovao.......................................................................................98
Encerramento
do
Projeto.........................................................................................................103
Conceitos de
Gerenciamento
de Projetos
Ser a atual preocupao das empresas com o tema gesto de
projetos um mero modismo? Alguns indicadores observados no contexto empresarial
atual nos levam a crer que no. Conseqncia de uma volatilidade cada vez mais
acentuada de mercados que aparecem e desaparecem da noite para o dia, a
instabilidade econmica, caracterstica no passado de perodos sazonais, hoje uma
realidade com a qual as organizaes precisam conviver. Este cenrio torna a
competio cada vez mais acirrada e agressiva e faz com que os riscos incorporados
aos negcios adquiram dimenses desproporcionais. Neste contexto, os recursos
consumidos pelas empresas para realizar suas estratgias tornam-se cada vez mais
importantes e precisam ser geridos com o mximo de eficincia.
Instrumento indispensvel para o crescimento e sobrevivncia no voltil mercado
atual, a capacidade de inovao outro importante fator crtico de sucesso. Inovar,
diferentemente de apenas inventar, pressupe um processo estruturado de estudos
tcnicos e financeiros at a transformao em aplicaes que traro resultados
efetivos para a organizao geradora da inovao. Isto , inovao no meio
empresarial transformao de idias em negcios.
O papel dos projetos neste contexto

Se analisarmos como as organizaes estruturam seus planos estratgicos, veremos
que as aes ou iniciativas estratgicas que realizam seus objetivos estratgicos de
crescimento so de fato materializadas atravs da execuo de projetos. O
lanamento de novos produtos, a expanso para uma nova rea de negcios,
mudanas estruturais, como o aumento de capacidade de produo ou da
produtividade de algum setor da organizao devem ser conduzidas por meio de
projetos.
Realizao de objetivos estratgicos atravs de projetos
Portanto, pode-se afirmar que o alcance dos objetivos estratgicos de uma

organizao ocorre na medida do sucesso de seus projetos estratgicos. Ou seja, a
eficcia de um planejamento estratgico organizacional est diretamente relacionada
eficcia de seus projetos estratgicos. Porm, os resultados dos projetos que so
realizados atualmente no so nada satisfatrios. Segundo pesquisa de 2004
publicada pelo Standish Group, instituto de pesquisas americano, apenas 34% dos
projetos realizados foram considerados concludos com sucesso.
Apesar de o conceito de sucesso em projetos no ser simples de ser definido, como
veremos posteriormente, fica evidente a necessidade de melhoria no desempenho
dos projetos conduzidos nas organizaes. Algumas perguntas que dificilmente
encontraro respostas do uma idia da dimenso de recursos envolvidos:

Quantos projetos terminam fora do prazo? Quanto custa o atraso?

Quantos projetos terminam acima do oramento? Quanto gasto a mais?
Quantos projetos terminam sem completar o escopo?
Que perdas so geradas pelo que deixa de ser realizado por projetos que no
completam seus escopos?
Qual o custo da no-conformidade?
Qual o custo do cliente insatisfeito? Da perda de um cliente?
Pode-se concluir, ento, que a preocupao com o gerenciamento de projetos de

forma metodolgica para a obteno de resultados estratgicos no um mero
modismo ou onda passageira, mas uma necessidade real.
Project Management Institute - PMI

A busca da melhoria no desempenho de projetos teve um marco importante no final
da dcada de 60. Neste ano foi criado o Project Management Institute. Instituio
no governamental sem fins lucrativos situada na Pensilvnia, Estados Unidos, e que
tem como misso fomentar a atividade de gerenciamento de projetos.
O PMI tem abrangncia internacional e est organizado em mais de 200 sucursais
chamadas de Chapters, distribudos em 125 pases. Atualmente existem cerca de
300.000 afiliados que tm acesso, atravs do site do PMI, a documentos, artigos e
informaes sobre gerenciamento de projetos. A filiao pode ser feita, mediante o
pagamento de uma taxa no site: www.pmi.org.
Guia PMBOK1 Project Management Body Of Knowledge

O PMI tem, tambm, a responsabilidade de publicar o Conjunto de Conhecimentos
em Gerenciamento de Projetos que est em sua quarta edio, lanada em 2008.
O Guia PMBOK, como conhecido, um guia de referncia bsica de contedo
para profissionais de gerenciamento de projetos e contribui para a divulgao de
uma terminologia e vocabulrio, comuns ao ambiente de projetos. construdo a
partir da contribuio de descries de BOAS PRTICAS resultantes de experincias
1
PMBOK marca registrada de Project Management Institute.
de profissionais do mundo inteiro que as encaminham a comits responsveis por

consolid-las em um documento estruturado.
O guia est organizado em 9 reas de conhecimento: gerenciamento do escopo,
gerenciamento do tempo, gerenciamento dos custos, gerenciamento da qualidade,
gerenciamento dos recursos humanos, gerenciamento das comunicaes,
gerenciamento dos riscos, gerenciamento das aquisies e gerenciamento da
integrao do projeto, que sero abordadas posteriormente e cujo domnio
considerado essencial para um bom gerenciamento de projetos.
Certificao PMP2 Project Management Professional

Outra atribuio do PMI certificar profissionais em gerenciamento de projetos. A
certificao PMP concedida aos aprovados em um teste de 200 questes de
mltipla escolha que procura avaliar o candidato nas reas de conhecimento do Guia
PMBOK e em situaes prticas do dia-a-dia do gerenciamento de projetos.
Para habilitar-se a fazer a prova necessrio comprovar 4.500 horas de experincia
prtica em projetos, para quem possui graduao superior, e 7.500 horas para
profissionais de nvel tcnico e pagar uma taxa de 525 dlares americanos para no
afiliados ao PMI, e 425 para afiliados.
Alm da certificao PMP o PMI tambm tem outras certificaes relacionadas ao
tema gerenciamento de projetos, a saber:
PgMP (Program Management Professional) demonstra conhecimento e

experincia na conduo de programas.
PMI-RMP (Risk Management Professional) demonstra conhecimento e

experincia em gerenciamento de riscos de projetos.
PMI-SP (Schedulling Professional) demonstra conhecimento e experincia

em gerenciamento de cronogramas de projetos.
CAPM (Certified Associate of Project Management) demonstra

conhecimento em gerenciamento de projetos. Para profissionais que ainda
no tm tempo de experincia suficiente para serem certificados como
PMP.
O QUE UM PROJETO?
O senso geral utiliza o termo projeto para referir-se a atividades da vida cotidiana
tais como: projeto de vida; uma inteno futura; desenhos, plantas, com
instrues para construo ou montagem de estruturas, enfim, aplicaes das mais
diversas e livres.
Para este estudo, vamos considerar o conceito de projeto, de forma tecnicamente
restrita, como: o todo de um esforo, ou empreendimento, temporrio para criar um
PMP, PgMP, PMI-RMP, PMI-SP e CAPM so marcas registradas de Project Management Institute.
produto, servio ou resultado exclusivo. Envolve todo o processo desde a

identificao da demanda at a entrega do produto, servio ou resultado final.
Conceituar projeto tecnicamente importante para que possamos reconhec-los no
contexto do dia-a-dia, distinguindo-os das rotinas operacionais e aplicarmos tcnicas
de gerenciamento especficas para obter melhores resultados.
O Guia PMBOK define projeto como um esforo temporrio para criar um produto,
servio ou resultado exclusivo.
Temporrio
Significa que, comparado com operaes de rotina, um projeto tem incio e
fim definidos antes do incio de sua execuo.
PLANO
Obj
t
D0
DDeadline
Janela de TEMPO
Produtos, Servios ou Resultados exclusivos

Mesmo que haja algumas semelhanas, os resultados dos projetos
apresentam diferenas. Prdios com o mesmo nmero de andares, mesmo
desenho de planta, executados pela mesma construtora, etc., tero
resultados nicos, uma vez que seus processos de construo sero
diferentes, suas orientaes em relao ao sol sero diferentes, suas
fundaes tero dimenses diferentes, pois estaro em posies de terreno
diferentes, etc.
H
D
I
R
S
A rvore de deciso, ao lado,

representa o processo de escolhas de
alternativas em um projeto.
A ponderao de prs e contras em
cada ponto de deciso um processo
de TRADE-OFF (conceito da economia
no qual nenhuma alternativa possui
apenas vantagens nem apenas
desvantagens)
T
J
E
K
V
X
A
L
F
C
Y
W
Z
A1
N
G
B1
C1
D1
E1
Probabilstico (No Determinstico) Tem Risco (incerteza)

No senso comum, a palavra projeto carrega a idia de plano para futuro,
previso. Possui sempre uma carga de incerteza de que acontecer o
esperado, ou planejado. Esta caracterstica torna o papel do gerenciamento

do projeto mais relevante, pois atua exatamente para reduzir a taxa de
desvio entre planejado e executado.

o fator crtico de sucesso de um projeto reside na capacidade de realizao
de atividades atravs das pessoas. Determinados tipos de operaes so
intensivos em mquinas ou equipamentos, mas em projetos os ativos
principais so, de fato, as pessoas que o realizam.
Elaborao Progressiva (em Etapas Fases)

As caractersticas anteriormente apresentadas conduzem a esta terceira
caracterstica de qualquer projeto: no se conhece cabalmente o que ser o
projeto assim que o mesmo se inicia. Com o passar do tempo, o
conhecimento que se tem dele aumenta. Para lidar com essa caracterstica,
que traz incerteza e indefinio para qualquer projeto, costuma-se utilizar o
recurso prtico de segment-lo em etapas ou fases para melhorar a
capacidade de gerenciamento e aumentar as chances de sucesso do projeto.
O princpio analtico de que partes menores so mais facilmente gerenciveis
vale muito em projetos. A diviso das fases que marcaro o processo do
projeto deve ser feita de acordo com a melhor convenincia do
gerenciamento e ir variar de acordo com a caracterstica especfica de cada
projeto.
Recursos limitados
Nas rotinas do dia-a-dia, os recursos so renovados para mant-los em
funcionamento permanente. Em um projeto os recursos financeiros e
humanos tm limites definidos pelo tempo de sua durao, pelo escopo e
pela qualidade do resultado esperado. O conceito de limitao pressupe
quantificao e diferente do conceito de escassez, pois recursos escassos

so insuficientes para alcanar os resultados planejados.
Precisa de Administrao Especfica

As tcnicas de gesto operacional no so suficientes para dar conta das
dificuldades prprias dos projetos. As caractersticas dos projetos tornam as
aes de planejamento, programao e controle mais crticas e complexas,
exigindo, portanto, tcnicas e ferramentas especficas.
Outra maneira de definir o conceito de projetos atravs da comparao com as

caractersticas das operaes rotineiras.
Projetos x Operaes
Decises Irreversveis x Decises Reversveis

Projetos, por sua natureza temporria, existem durante uma janela de tempo
limitada. Isso torna as decises tomadas no mbito do projeto muito mais
crticas, pois, na maioria das vezes, no h tempo suficiente para reverter
suas conseqncias.
Variveis Exgenas x Variveis Endgenas

Na operao os fatores que influenciam mais fortemente seu desempenho
so oriundos de dentro do ambiente operacional, e, portanto mais passveis
de controle. O projeto sofre influncia intensiva de fatores ou agentes
externos equipe do projeto.
Fluxo de Caixa Negativo x Fluxo de Caixa Positivo

A menos que um ambiente operacional esteja passando por uma crise
financeira, o montante das receitas geradas supera o de despesas no perodo
de tempo do ciclo de operao. Projetos so empreendimentos que geram
despesas que s podero ser cobertas quando seus produtos criados gerarem
os resultados esperados e conseqentemente as receitas. Mesmo que de
forma indireta, como no caso dos projetos de modificaes estruturais
desenvolvidos dentro das empresas. Por essa razo torna-se quase que na
totalidade dos casos obrigatria a reduo do perodo de existncia do
projeto (ciclo de vida).
GERENCIAMENTO DE PROJETOS
Segundo o Guia PMBOK, gerenciamento de projetos a aplicao de
conhecimentos, habilidades, ferramentas e tcnicas s atividades do projeto a fim de
atender aos seus requisitos.
O grande desafio comea em ser capaz de gerenciar e no apenas executar ou,
como comum ouvir-se, tocar o projeto. O gerenciamento, que queremos tratar
aqui, pressupe um processo estruturado e, preferencialmente, com a aplicao de
um mtodo, ou metodologia. O gerenciamento de projetos implica em levantar
necessidades, e identificar prioridades entre ESCOPO, TEMPO e CUSTO.
10
Priorizar escopo, tempo e custo significa que h uma dificuldade intrnseca de

projetos em atender plena e simultaneamente as trs dimenses principais de um
projeto, uma vez que projetos so carregados de incertezas geradoras de desvios.
Cada projeto tem uma relao de prioridades diferente destas variveis. Em um
determinado projeto o vetor prioritrio, ou FATOR CRTICO DE SUCESSO,
(tambm conhecido como DRIVER do projeto, ou seja, fator direcionador) ser o
custo, ou seja, todas as outras variveis devero ser subordinadas ao cumprimento
dos objetivos e metas de custo do projeto. Em outro, poder ser o tempo,
significando que as outras variveis sero dimensionadas para que o projeto cumpra
o prazo previsto.
Projetos de um mesmo tipo, a construo de uma casa, por exemplo, podem ter
prioridades diferentes. Vamos analisar trs casos como exemplo.
Primeiro caso: o cliente precisa se mudar at uma data especfica porque ter que
entregar o apartamento que ocupa no momento. A prioridade do projeto ser o
tempo. provvel que prximo da data marcada para a mudana do cliente, se o
projeto estiver atrasado, seja necessrio aumentar o custo para cumprir o prazo.
Talvez o escopo tenha que ser suprimido em alguns elementos que no sejam
essenciais mudana do cliente, pois o prazo o vetor menos flexvel.
Segundo caso: o cliente do projeto possui um montante determinado de recursos
financeiros e precisa construir uma casa que se encaixe neste valor. Como nesse
caso a prioridade o custo, provvel que o cronograma tenha que ser estendido
em funo do limite de oramento. Da mesma forma o escopo, se houver
necessidade, tenha que ser cortado, naquilo que no impea o funcionamento bsico
da residncia.
Terceiro caso: o cliente do projeto deseja uma casa com especificaes tais como:
nmero de quartos, banheiros, salas, salo de jogos, piscina com caractersticas
especficas, etc. Nesse caso, o cronograma, assim como o oramento, na dinmica
incerta do projeto, provavelmente, tenha que ser aumentado para cumprir os
requisitos de escopo.
Porm, estabelecer prioridades no significa descuido ou abandono das variveis que
no so a prioritria, pelo contrrio. O bom desempenho no conjunto das variveis
de restrio do projeto aumenta a probabilidade de sucesso no vetor prioritrio e
consequentemente do projeto.
A prioridade de objetivos, porm, no facilmente identificvel. O primeiro impulso
dos principais interessados desejar que todas as demandas, variveis, objetivos, ou
vetores, sejam atendidos igualmente. O que , quase sempre, invivel. Dada a
natureza da atividade projeto, extremamente voltil e carregada de incertezas.
O responsvel pelo projeto deve procurar identificar o vetor prioritrio lanando mo
de sequncias de perguntas nas quais sejam postas hipteses de situaes limites
entre pares de vetores para que possa, gradativamente, identificar as prioridades.
Por exemplo, se numa situao limite, para que o escopo seja completado for
necessria uma extenso do prazo, e isto for aceitvel, um indcio de que escopo
tem prioridade sobre prazo.
11
Os requisitos, portanto, no so simplesmente passados pelo demandante ao

gerente do projeto. necessria uma construo conjunta, na qual o gerente do
projeto far sugestes, alertar acerca de impossibilidades tcnicas, mostrar
conseqncias de opes escolhidas pelo demandante, etc. A descrio deste
modelo de relacionamento fica melhor representada pela expresso inglesa:
COMAKERSHIP (Processo de relacionamento de parceria para elaborao conjunta).
Deste relacionamento desdobra-se, tambm, a equao da qualidade do servio. Na
qual a qualidade percebida est diretamente relacionada qualidade esperada pelo
cliente e a qualidade daquilo que entregue, ou seja, ofertado. A qualidade
esperada reflete a expectativa do cliente que formada por diversos fatores
relacionados ao perfil racional e emocional do cliente.
Dependem do background cultural e educacional do cliente, das suas experincias

anteriores com projetos, e com projetos de mesma natureza, do ambiente sob o qual
ele est vivendo no momento do relacionamento com o projeto, enfim de uma srie
de fatores que compem um quadro de expectativa sob a qual o executor do
projeto, o gestor do projeto, no tem domnio. Tem, apenas, influncia desde o
momento em que comea o relacionamento pessoal para a conduo do projeto.
Esta equao confirma o carter subjetivo que permeia toda relao de consumo,
seja de um produto, seja de prestao de um servio, no caso, da realizao de um
projeto. No h como extrair totalmente este ingrediente subjetivo. Portanto, mesmo
que utilizemos mtodos para traduzir requerimentos e desejos e expectativas em
fatos e dados sempre haver uma parcela considervel de subjetividade.
A interdependncia entre as variveis significa que quando h a alterao
dimensional de uma delas implica na modificao de pelo menos mais uma delas. E,
uma vez definidas as dimenses adequadas de escopo, tempo e custo do projeto, a
qualidade do projeto ser a medida de cumprimento destas dimenses dentro dos
limites de tolerncia dos demandantes do projeto.
Quando um projeto tem sucesso?

A avaliao do sucesso de um projeto deve ser vista por duas perspectivas bem
distintas: do processo do projeto e do produto do projeto.
Perspectivas de sucesso de um projeto
Na perspectiva do processo de projeto so observados os aspectos de eficincia do

processo. Ou seja, se os requisitos de conformidade do processo do projeto foram
atendidos. Esta dimenso est ligada organizao executora do projeto. As perdas
de eventuais e desvios nos planos de projeto afetaro diretamente o desempenho
operacional da organizao executora.
J na perspectiva do produto do projeto so observados os aspectos da eficcia. Isto
, se o resultado do projeto foi entregue dentro dos requisitos de conformidade do
cliente. A avaliao feita pelo cliente do projeto na sua perspectiva.
Portanto, um projeto pode ser eficiente e no ser eficaz e vice-versa. Eficcia sem
eficincia, ou seja, sucesso apenas para o cliente e processo de projeto com nveis
de desvio elevados, estar gerando, em mdio ou longo prazo, desequilbrio de
consumo de recursos da organizao executora do projeto. Eficincia sem eficcia
resultar em insatisfao do cliente, porque o produto do projeto no atender seus
requisitos.
Projeto planejado e gerenciado x projeto tocado

Ao receber o encargo de realizar um empreendimento, o impulso natural de todos
ns, seres humanos, comear a executar as atividades que nos parecem
necessrias, imediatamente. Vencer este impulso e seguir um processo estruturado
ou metodolgico de concepo e elaborao de um plano para s ento execut-lo
requer um comportamento programado para tal.
A transformao de um mero tocador de projetos para um verdadeiro gerente de
projetos profissional tem como premissa bsica esse perfil de trabalho. Na execuo
13
sem planejamento a probabilidade de re-trabalho e desperdcio de recursos maior

gerando, em geral, a extenso do tempo e o estouro dos custos. A presuno de
profissionais de gerenciamento de projetos, que adotam boas prticas, de que o
tempo dedicado ao planejamento seja inversamente proporcional ao acrscimo de
tempo de execuo por excesso de retrabalho, ociosidade, etc.
Projeto planejado e gerenciado X Projeto tocado
O Gerente do Projeto
Em primeiro lugar, vale ressaltar que gerente do projeto, aqui, no o nome de um
ttulo formal de cargo administrativo. a designao do responsvel pelo
gerenciamento do projeto. Responsvel pelo seu sucesso ou fracasso, mesmo
quando lhe forem impostas condies absolutamente desfavorveis.
Hoje, h profissionais cujo cargo Gerente de Projetos. Significa que este
profissional tem como misso institucional gerenciar projetos. comum, porm, que
profissionais que ocupam os mais diversos cargos sejam designados, em
determinado momento de suas vidas profissionais, como responsveis por um
projeto. Neste momento o profissional passa a ser o gerente deste projeto.
So atribuies comuns ao gerente do projeto:

Entrega do produto do projeto

Formao e construo da equipe do projeto
Elaborao dos planos do projeto
Direo da execuo do projeto
Monitoramento e controle do projeto
Medio da performance do projeto
Relacionamento com os stakeholders do projeto
Determinao de aes corretivas e preventivas
Gerenciamento do escopo, tempo, custos, qualidade, recursos humanos,
riscos, comunicaes e aquisies do projeto
Promoo e manuteno da integrao e coeso dos componentes do projeto
14
O Gerente do Projeto deve ter autoridade suficiente para realizar suas atribuies.
Esta autoridade, no mbito do projeto, concedida pelo patrocinador do projeto.
Sem autoridade suficiente o Gerente do Projeto ter dificuldades em incorporar os
recursos necessrios ao cumprimento dos objetivos do projeto.
Perfil e competncias do Gerente do Projeto

Historicamente o Gerente do Projeto vem sendo escolhido para a funo de
gerenciar o projeto por suas competncias tecnolgicas da rea de conhecimento no
qual o projeto ser conduzido. Nos projetos de engenharia, o gerente do projeto
escolhido naturalmente por ser engenheiro, nos de tecnologia da informao, por
ser analista de sistemas, e assim por diante.
Pressionado pela exigncia por resultados, vem ocorrendo uma modificao nestes
requisitos. Pode-se considerar que at da metade dos anos 80, exigia-se do gerente
do projeto em torno de 20% de competncias comportamentais, ou gerenciais, e
80% de competncias tcnicas ou tecnolgicas especialistas. Hoje, a relao
considera apropriada para um melhor desempenho das funes de gerenciamento de
projetos gira em torno de 20% de competncias tcnicas e tecnolgicas e 80% de
competncias comportamentais.
Esse processo de mudana resulta, tambm, da constatao de que os fatores que
contribuem mais significativamente para os fracassos dos projetos so de ordem
gerencial e no tcnica.
Processos de Gerenciamento de Projetos

Como processo um conjunto de atividades inter-relacionadas capazes de gerar
resultados, o gerenciamento de projetos pode ser estruturado em processos
especficos. Na verdade, os efetivos ganhos de eficincia na realizao de projetos
ocorrem quando projetos so gerenciados seguindo processos.
O PMI, no Guia PMBOK, define cinco grupos de processos:

Iniciao
Planejamento
Execuo
Monitoramento e Controle
Encerramento
Cada grupo de processos contm um conjunto de processos capazes de gerar os

resultados esperados do projeto. O Guia PMBOK relaciona os processos utilizados
por profissionais e organizaes no mundo inteiro para gerenciar seus projetos. Estes
processos por terem demonstrado sua efetividade so considerados BOAS
PRTICAS. Cada organizao, porm, dever identificar dentre os processos, ou
boas prticas, disponveis, quais sero adequados aos seus projetos especificamente.
15
Grupos de Processos de Gerenciamento de Projetos - Fonte: Guia PMBOK, 2008
Os grupos de processos no so fases do projeto. Processos so genricos, ou

seja, aplicam-se a todo e qualquer projeto e repetem-se ao longo do ciclo de vida do
projeto. Por exemplo, o processo de iniciao ocorre quando o projeto autorizado e
quando cada fase do projeto tem sua autorizao de incio. O processo de
planejamento o pensar no que ser feito em cada fase. Seu principal objetivo
elaborar o plano de gerenciamento do projeto. Em cada fase do projeto, este plano
deve ser consultado e executado no processo de execuo. Os processos de
encerramento ocorrero toda vez que uma parte do projeto for concluda, ou seja,
realizada uma entrega. O processo de monitoramento e controle ocorre desde que as
primeiras aes do projeto so realizadas at o seu trmino. Os grupos de processos
de gerenciamento do projeto apresentam interaes entre si ao longo do ciclo de
vida do projeto.
Ciclo de Vida e Processos de Gerenciamento de Projetos

Esquematicamente, podemos identificar momentos do projeto nos quais os
processos ocorrem com mais intensidade, ou tm entregas marcantes. Por exemplo:
o processo de iniciao, quando ocorre no incio do projeto, gera o documento de
abertura do projeto (Project Charter, ou Termo de Abertura), o processo de
planejamento ocorre mais intensamente quando est se preparando o Plano de
gerenciamento do projeto, ou Plano de Gerenciamento do Projeto que ser a base
de referncia (baseline) para o processo de execuo das atividades do projeto.
O ciclo de vida de cada projeto identificado de acordo com suas fases especficas,
ou seja, um projeto de construo de uma casa ter fases prprias de projetos de
construo de casas, e seu ciclo de vida ser descrito tipicamente pelas fases:
fundaes, estrutura, alvenaria, instalaes, telhado, acabamento e limpeza. J um
projeto de desenvolvimento de um sistema de tecnologia da informao poder ter
seu ciclo de vida tpico como: levantamento de requisitos, anlise, programao,
instalao e homologao.
16
Os processos de gerenciamento tm como finalidade gerenciar (planejando,

monitorando e controlando) como sero realizadas as atividades necessrias
concretizao do produto do projeto. Em cada fase especfica do projeto, podero
ser rodados os processos de gerenciamento. Esta distino til para uma melhor
definio da natureza do trabalho que efetivamente estar sendo realizado a cada
momento, se de gerenciamento ou de elaborao do produto do projeto.
Desenvolvimento do Projeto
O modelo a seguir representa o desenvolvimento de um projeto desde a
identificao da necessidade de realizao do projeto, a partir de um problema ou do
aproveitamento de uma oportunidade.
As setas descrevem as interaes entre os processos e a lgica de elaborao
progressiva com o carregamento de dados e informaes nos componentes do plano
que ser executado, monitorado, controlado e encerrado.
17
18
19
reas de
Conhecimento
Integrao
Escopo
Tempo
Custos
Qualidade
Recursos
Humanos
Comunicaes
Riscos
Aquisies
Grupos de Processos de Gerenciamento de Projetos (Guia PMBOK, 2008)

Monitoramento
Iniciao
Planejamento
Execuo
Encerramento
e Controle
Desenvolver o Desenvolver o Orientar e
Monitorar e
Encerrar o
Termo de
Plano de
Gerenciar a
Controlar o
Projeto ou Fase
Abertura do
Gerenciamento
Execuo do
Trabalho do
Projeto
do Projeto
Projeto
Projeto
Controle
Integrado de
Mudanas
Coletar
Verificar o
Requisitos
Escopo
Definir o
Controlar o
Escopo
Escopo
Criar EAP
Controlar o
Definir as
Cronograma
Atividades
Seqenciar as
Atividades
Estimar os
Recursos
Estimar a
Durao das
Atividades
Desenvolver o
Cronograma
Estimar os
Controlar os
Custos
Custos
Definir o
Oramento
Realizar a
Planejar a
Realizar o
Qualidade
Garantia da
Controle da
Qualidade
Qualidade
Desenvolver o Mobilizar a
Plano de
Equipe do Projeto
Recursos
Desenvolver a
Humanos
Equipe do Projeto
Gerenciar a
Equipe do Projeto
Distribuir as
Identificar as
Planejar as
Reportar o
Partes
Comunicaes
Informaes
Desempenho
Interessadas
Gerenciar as
Expectativas das
Partes
Interessadas
Planejar o
Monitorar e
Gerenciamento
Controlar os
dos Riscos
Riscos
Identificar os
Riscos
Realizar a
Anlise
Qualitativa dos
Riscos
Realizar a
Anlise
Quantitativa dos
Riscos
Planejar
Respostas aos
Riscos
Planejar as
Conduzir as
Administrar as Encerrar as
Aquisies
Aquisies
Aquisies
Aquisies
20
Processos
de
Iniciao
Uma vez tomada a deciso de realizar o projeto, necessrio
constitu-lo formalmente. Segundo o Guia PMBOK, o grupo de processo iniciao
o processo que define e autoriza o projeto ou uma fase projeto. O grupo de processo
de iniciao do projeto composto por dois processos: desenvolver o termo de
abertura do projeto e identificar stakeholders.
DESENVOLVER O TERMO DE ABERTURA DO PROJETO

O Termo de Abertura do Projeto (project charter), tem como misso principal
autorizar formalmente a realizao do projeto. Define os principais elementos do
projeto suficientes para indicar os objetivos, o porqu da realizao do projeto
(justificativas), a contextualizao do projeto na organizao, enfim o que o
projeto.
Para cumprir sua misso essencial, um Termo de Abertura pode conter apenas
informaes essenciais, tais como um nome para o projeto e uma breve descrio.
Este seria um extremo de um Termo de Abertura de um projeto com o mnimo de
informaes disponveis no momento de sua constituio formal (autorizao por
quem de direito). No outro extremo poderamos ter um Termo de Abertura com o
mximo de informaes capazes de descrever elementos integrantes do projeto que
auxiliaro o entendimento do que representa o projeto. Um Termo de Abertura com
muitas informaes permitir que, durante seu processo de autorizao (aprovao)
este conjunto de informaes sejam validadas pelo patrocinador (sponsor - principal
signatrio da autorizao) e pelo cliente do projeto. Aquele que dar o aceite formal
no produto (resultado) do projeto.
Nome ou Ttulo do Projeto
Longe de ser uma mera formalidade, a denominao do projeto um elemento de
comunicao que pode cumprir um papel importante na divulgao do projeto para a
organizao executora e para stakeholders. Pode ser composto apenas com uma
forma resumida de descrever o resultado principal do projeto, como:
Desenvolvimento e Instalao de Sistema de Gesto Integrada ou utilizar um slogan
que sirva de instrumento de marketing para o projeto. Associados ao nome podem
ser desenvolvidos identidade visual, logomarcas e outros elementos de comunicao
para o projeto.
21
Cliente do Projeto
Indivduo que d o aceite formal no resultado (produto) do projeto. Pode no ser, e
em geral no , o usurio final do produto. Tambm no , necessariamente, quem
paga pelo projeto. O foco da identificao deste importante stakeholder o de
garantir que o projeto no fique impedido de ser encerrado por indefinio de quem
tenha autoridade e competncia formal para dar o de acordo formal na principal
entrega do projeto. A boa prtica recomenda que se busque identificar o indivduo
ao invs da designao de um setor, ou diretoria, ou at mesmo uma empresa, para
evitar que caso haja uma mudana na estrutura de pessoal, isso gere impasses na
entrega do produto do projeto e impea o encerramento formal do projeto.
Gerente do Projeto
O Termo de Abertura deve designar e atribuir autoridade formal ao responsvel pela
realizao do projeto. Na prtica, o prprio gerente do projeto, j indicado conduz o
desenvolvimento do documento a partir de informaes fornecidas pelos principais
stakeholders do projeto.
Patrocinador (Sponsor)
O termo patrocinador d a conotao de que este stakeholder seja apenas quem
prov recursos financeiros e libera recursos para o projeto, mas ele tem um papel
muito mais abrangente. D suporte e cobertura poltica ao projeto, tem o poder de
deciso quanto s prioridades do projeto e o principal agente autorizador de
mudanas no projeto. Pode exercer, ao mesmo tempo, o papel de cliente. Um
patrocinador forte (com poder na organizao) e atuante pode ser decisivo ao
sucesso do projeto.
Descrio do Projeto
Apresentao sumria do projeto. Deve ser sucinta para permitir uma viso geral do
que o projeto. Se forem necessrias mais informaes a recomendao que
sejam postas em anexos a fim de que no torne o documento extenso. De modo
geral, informaes em projetos devem ser postas de forma a serem entendidas o
mais rpido possvel.
Justificativa do Projeto (Problema/Oportunidade)
Um projeto consome recursos, a cada dia, mais escassos, portanto o porqu de sua
realizao deve ficar bem claro no documento que registra sua constituio. Um
projeto cuja justificativa forte tende a ter mais apoio da organizao executora e
consequentemente menos dificuldade em obter os recursos necessrios sua
execuo.
Se a organizao executora utiliza um processo de seleo e priorizao de projetos
para tomar a deciso de executar ou no projetos, a princpio, as razes que
justificam o empreendimento j devem ter sido apresentadas.
Mas a justificativa para a realizao do projeto vai alm da deciso de execut-lo.
Serve como fator de motivao para a equipe do projeto, como argumento em
22
negociaes com stakheolders e para o patrocinador defend-lo poltica e

financeiramente.
Uma boa justificativa para um projeto deve estar relacionada aos benefcios que ele
trar para a organizao que podem ser tangveis ou intangveis, em forma de
soluo de um problema ou do aproveitamento de uma oportunidade. Justificativas
baseadas na soluo de problemas tendem a ser mais facilmente aceitas do que
aquelas que propem o aproveitamento de oportunidades porque, em geral, o
problema j existe e j est causando efeitos reais, enquanto que a oportunidade,
por natureza, potencial, carrega mais risco.
Neste campo a recomendao, tambm de objetividade e sntese. Se forem
necessrios dados adicionais ou mais detalhados devem vir em anexos ao Termo de
Abertura.
Produto do Projeto
O resultado principal que ser gerado pelo projeto deve ficar bem claro a fim de
evitar expectativas alm da capacidade de realizao do projeto. O produto do
projeto a principal entrega produzida pelo projeto.
Pode ser um objeto, por exemplo, um projeto de construo de uma residncia. A
residncia pronta para morar seria o produto do projeto. Um servio, que seria
entregue por um projeto de consultoria. O produto gerado pelo projeto estaria
materializado no relatrio com as recomendaes da consultoria. O produto de um
projeto pode ser um estado modificado, que seria obtido pela execuo de um
projeto de modificao de um layout de um ambiente de trabalho. Deve ser
quantificvel.
O produto do projeto deve ser identificado e tangibilizado de tal forma que, ao final,
permita a verificao de que de fato foi entregue e a avaliao da adequao ao que
foi proposto em seu incio.
A indefinio do produto do projeto pode levar s partes interessadas no projeto
criarem expectativas diferentes em relao quilo que o projeto efetivamente estaria
configurado para entregar e causar conflitos, frustraes e prejuzos.
Objetivos e Metas do Projeto
O objetivo mais amplo do projeto, a inteno do projeto, seu requisito maior, suas
prioridades, devem ser expressas em objetivos quantificveis que permitam sua
verificao e avaliao do seu desempenho e seus resultados. Devem ser expressos
no tempo verbal infinitivo: realizar, entregar, desenvolver.
Se o objetivo de desempenho do projeto descreve o qu o projeto far, a meta
descreve o quanto. Ou seja, a meta a quantificao de um objetivo. A medida do
desempenho do projeto. Pode haver mais de uma meta para um mesmo objetivo,
mas no deve haver objetivo que no comporte a atribuio de pelo menos uma
meta.
Para o objetivo principal do projeto, relacionado principal entrega, recomendvel
que se estabeleam metas nas trs principais dimenses do projeto: escopo, tempo
23
e custo. A determinao de objetivos e metas pode seguir a hierarquia das fases e

entregas do projeto. No Termo de Abertura, porm, dado que o projeto est no
processo de iniciao, os objetivos tendem a ficar em mbito mais geral, sendo,
posteriormente, detalhados.
Metas devem refletir os compromissos assumidos pelo projeto, portanto, podem ser
referenciados a elementos ainda no definidos no momento da redao do Termo de
Abertura, mas que sero elaborados no planejamento do projeto. Por exemplo: meta
de no ultrapassar o oramento do projeto. Meta de no ultrapassar o cronograma
aprovado.
Metas relacionadas ao escopo podem vincular necessidades postas na Declarao do
Trabalho (Statement Of Work SOW - documento que formula as necessidades
postas ao projeto emitido pelos demandantes do projeto), que se tornaro
especificaes de escopo. Por exemplo, no projeto de uma escola: nmero de salas
de aula, nmero de laboratrios, etc.
As metas sero o referencial de comparao para a avaliao do projeto ao seu
trmino. Mediro, portanto, seu desempenho e seu sucesso.
Estimativa de Custos
A finalidade de elaborar uma estimativa de custos ainda no processo de iniciao
tentar dimensionar em ordem de grandeza os custos gerais do projeto. Pode ser uma
forma de confirmar uma faixa de valor que tenha sido enunciada em um estudo de
viabilidade financeira, quando da deciso de realizar ou no o projeto, ou de dar a
primeira idia do quanto o projeto poder custar. Neste caso, poder resultar na
deciso de no continuar com a realizao do projeto.
sempre importante lembrar que, seguindo um princpio geral da administrao,
quanto mais cedo, mais prximo da origem, tomar-se a deciso de interromper um
processo que no esteja conforme, mais econmica ser esta deciso para a
organizao.
A idia de validao da viabilidade um pressuposto que permeia todo o processo
de iniciao do projeto. Durante o processo de iniciao do projeto deve-se procurar
confirmar ou no a deciso de realizao do projeto.
Por conveno, que pode variar de acordo com cada organizao, a expectativa de
preciso desta estimativa de -50% a +100% do oramento final que ser apurado
no processo de planejamento do projeto.
A consulta a dados histricos de projetos anteriores semelhantes um recurso de
apoio no processo de estimativa de custos do projeto. Porm, se a base histrica no
possuir referncias semelhantes, pode-se solicitar apoio a um fornecedor que as
tenha ou que possa elaborar uma estimativa. Alm do apoio neste momento, este
fornecedor figurar como potencial executor de partes do projeto, no caso de
dificuldades da organizao executora. Funciona, portanto como mitigador de riscos.
24
Estimativa de Prazo
Infelizmente, a maioria dos projetos conduzidos hoje em dia, no so iniciados a
partir de um planejamento, mas de uma reao a uma necessidade, portanto os
prazos dos projeto so estabelecidos, e no estimados. O deadline, ou prazo de
trmino do projeto j faz parte da demanda. Dessa forma, pode ser classificado
como uma restrio imposta. Esta imposio influenciar o modelo de programao
do cronograma do projeto no processo de planejamento que ter que ser feito para
trs. Ou seja, a partir da data final estabelecida, programar as etapas do projeto.
No caso de no haver esta imposio, o prazo pode ser estimado considerando-se
referncias histricas de projetos semelhantes, como recomendado para custos.
Autorizao
Salvo regimentos organizacionais especficos, o principal stakeholder autorizador do
projeto o patrocinador (sponsor). No caso de outros membros da organizao
executora participarem da autorizao, suas assinaturas sero necessrias
aprovao do Termo de Abertura do Projeto.
O processo de aprovao do Termo de Abertura pode consumir um tempo
considervel em idas e vindas para anlises e avaliaes, porm importante
ressaltar que um projeto no deve ser autorizado com dvidas quanto s suas
finalidades.
Por outro lado, altamente recomendvel que no se comece a realizar, ou seja,
tomar decises ou consumir recursos por conta do projeto, sem que o processo de
autorizao formal esteja concludo.
STAKEHOLDERS (Partes Interessadas) DO PROJETO

Segundo o dicionrio Random House: detentores (holders) da aposta (stake). Partes
interessadas a traduo mais encontrada para essa palavra no contexto de
gerenciamento de projetos. Significa: todo indivduo, entidade, enfim qualquer
pessoa fsica ou jurdica que de alguma forma tenha relacionamento, seja atingida
ou impactada pelo projeto. Pode influenciar ou ser influenciada pelo projeto. No
decorrer do projeto ou mesmo aps seu encerramento.
A equipe de gerenciamento do projeto tem que identificar os stakeholders, partes
interessadas tanto internas quanto externas organizao executora de maneira a
determinar os requisitos e expectativas dessas partes. Uma vez identificadas, uma
anlise deve ser feita para se determinar estratgias de gerenciamento dessas partes
interessadas.
As etapas envolvidas em uma anlise de partes interessadas so:
Identificao de partes interessadas: desenvolver uma lista com

nomes dos interessados chaves do projeto, sua funo, rgo ou
empresa. Em alguns casos, podem ser identificados e listados grupos
de interessados que tenham um mesmo perfil ou participao no
projeto.
25
Classificao de partes interessadas: cada interessado da lista

identificado por um cdigo (por exemplo, por letras maisculas) e
feita uma avaliao em relao a seu poder de influenciar o projeto e
seu interesse. Alm disso, avalia-se se o interesse positivo ou
negativo.
Elaborao de estratgia: para cada interessado ou grupo de

interessados so desenvolvidas estratgias de relacionamento e
comunicao.
O grfico abaixo apresenta um exemplo de classificao de partes interessadas que

leva em conta o poder e o interesse de cada interessado ou grupo de interessados.
Anlise dos Stakeholders (Partes Interessadas do Projeto)
A informao resultante da anlise pode ser consolidada em um registro de partes

interessadas (quadro na prxima pgina). Esse registro primeiramente elaborado
no incio do projeto e deve ser mantido atualizado durante todo o ciclo de vida do
projeto.
Certas informaes relacionadas a uma ou mais das partes interessadas podem ser
muito sensveis para serem includas no registro de partes de interessadas que ser
tornado pblico como um documento do projeto. A equipe de gerenciamento de
projeto deve avaliar cada caso e decidir que nvel de detalhe ser includo no
registro e que informao merece divulgao restrita.
Em razo dos stakeholders influenciarem positiva ou negativamente o projeto e,
consequentemente, seus objetivos, eles so uma fonte primria de riscos ao projeto.
26
Figura 1 - Registro de Partes Interessadas
Registro dos Stakeholders (Partes Interessadas do Projeto)
Concluso do processo de iniciao do projeto

Como foi visto, no processo de iniciao so coletadas informaes preliminares e
levantadas questes gerais relacionadas capacidade de realizao do projeto.
Considera-se que na iniciao faz-se um planejamento de alto nvel, um
planejamento macro, que define as linhas gerais do projeto capazes de fornecer o
mximo de subsdios para o patrocinador (sponsor) do projeto tomar a deciso de
autorizar a continuidade do trabalho em um planejamento em baixo nvel que
produzir um plano de gerenciamento do projeto detalhado. Dessa forma, elementos
chave, tais como premissas e restries, devero ser revisados, refinados,
detalhados e registrados na declarao do escopo do projeto.
27
Processo
de
Planejamento
A concluso do processo de iniciao indica que o projeto pode
seguir em frente e pode-se, ento, investir tempo e recursos na elaborao do Plano
de Gerenciamento do Projeto que a principal misso e resultado do processo de
planejamento do projeto.
Antes de tratarmos do trabalho que compe o processo de planejamento,
importante refletirmos sobre algumas questes de ordem prtica que esto longe de
serem triviais: por que planejar? Por que dedicar esforo e tempo planejando se j
poderamos ir direto execuo do projeto? Qual o benefcio de planejar se as coisas
no saem exatamente como planejado? Por que elaborar um plano se a
probabilidade de haver mudanas muito alta? Isto no perda de tempo?
No h uma resposta nica, mas um posicionamento. preciso considerar que o
trabalho, esforo ou recursos, inclusive de tempo, sero menores do que os gastos
com as conseqncias de uma execuo sem planejamento.
O posicionamento a favor do planejamento vem da presuno de que o retrabalho
ser menor se houver planejamento. Por re-trabalho entenda-se todo o trabalho que
no poder ser aproveitado para o resultado do projeto. Sabemos que mesmo com o
planejamento existe re-trabalho em projetos, dado que uma atividade
probabilstica e carregada de incerteza.
Porm, a dose de planejamento no pode ser prescrita de forma genrica, mas de
acordo com cada caso especfico. Excesso de tempo e esforo dedicados ao
planejamento pode representar mais perdas do que ganhos. O desafio, portanto,
encontrar o ponto de equilbrio.
O processo de planejamento do projeto segue uma sequncia lgica necessria
elaborao do plano de gerenciamento do projeto.
Em primeiro lugar, define-se o escopo, que representa aquilo que ser feito pelo
projeto, para em seguida dimensionar-se o tempo necessrio para esta realizao,
que por sua vez, permitir a quantificao dos custos. Depois, viro as definies da
qualidade, dos recursos humanos, da comunicao, dos riscos, enfim, dos demais
parmetros do projeto.
Apesar de seguir uma lgica de elaborao progressiva, o processo de planejamento
interativo, pois seus parmetros so correlacionados, e ao mesmo tempo,
iterativo, isto , a definio de um elemento pode implicar na necessidade de ajuste
em outro anteriormente definido. Por exemplo: durante a definio dos parmetros
da qualidade do projeto pode-se verificar que um item de escopo precisa ser
modificado, gerando, assim a necessidade de redefinio do tempo e dos custos.
Assim sendo, uma vez identificada a inteno de realizar o projeto, necessrio
constitu-lo formalmente e definir seus principais parmetros para uma tomada de
deciso quanto sua execuo. Estes parmetros devem ser documentados de tal
forma que permitam uma avaliao quanto capacidade do projeto em alcanar
seus objetivos e gerar os benefcios para a organizao executora.
Uma boa documentao de um projeto fator decisivo para seu bom gerenciamento
e para ganhos de produtividade em projetos futuros desenvolvidos pela organizao.
muito comum a documentao de projetos ser vista como burocracia no sentido
pejorativo do termo, porm, se lembrarmos que projetos so empreendimentos que
geram produtos nicos, possvel perceber a utilidade de se ter referncias que
diminuam o grau de ineditismo.
Metodologia de Gerenciamento de Projetos
A sistematizao da documentao de projetos geralmente est associada ao que se
denomina metodologia de gerenciamento de projetos. Que nada mais do que a
determinao de processos estruturados e conjunto de documentos recomendados
para o gerenciamento de projetos com a finalidade de diminuir o grau de improviso
das aes de projeto e permitir o alcance de melhores resultados custa de menos
esforo.
Evidentemente durante o processo de incorporao da tcnica h um esforo que
pode, a princpio, ser considerado desproporcional, ou seja, estaria exigindo mais
esforo para documentar do que para fazer. Isto de fato um risco que deve ser
considerado, pois os limites do que pode ser instrumento gerencial e burocracia
excessiva tnue. H um princpio da administrao, enunciado por Henry Fayol
(1910), preconizando que: o controle no deve exceder o objeto controlado, isto ,
no devemos gastar mais energia para gerenciar do que para fazer.
Para entendermos a aplicao prtica de uma metodologia de gerenciamento de
projetos e a documentao associada, podemos fazer uma analogia com a natao.
Um indivduo que incorporou uma tcnica de nado, depois de orientado por um
treinador, passa a despender menos esforo e a obter melhores resultados em
relao a quem nada por instinto, sem tcnica especfica. No caso da natao, quem
domina a tcnica chega mais rpido outra margem com menos esforo.
29
A idia de que o mtodo de trabalho em projetos, metodologia de gerenciamento

de projetos, permita o alcance de resultados efetivos com menos esforo.
Pode parecer que nos primeiros projetos documentados e gerenciados segundo uma
metodologia adotada, o esforo seja desproporcional, mas a tendncia de que os
projetos subsequentes exijam menos esforo e gerem melhores resultados,
representando o efetivo ganho de produtividade.
Plano de Gerenciamento do Projeto

O plano que ser a base de referncia para a execuo do projeto dever conter
todas as orientaes necessrias para completar a entregas do projeto. composto
de um conjunto de documentos dedicados ao gerenciamento do projeto.
ESCOPO
Declarao do ESCOPO
WBS EAP Estrutura Analtica do Projeto
TEMPO (Cronograma)
Grfico de Gantt
Diagrama de REDE
CUSTO
Oramento do projeto
Sistema da Qualidade (Parmetros e Procedimentos)
Organograma do Projeto e Matriz de Responsabilidades
Matriz de Comunicaes
Registro de Riscos (Resposta aos Riscos)
Sistema de Gerenciamento de Configuraes
Controle Integrado de Mudanas
Sistema de Documentao
Sistema de Gerenciamento de Configuraes
necessrio definir como ser realizada a identificao e documentao das
caractersticas funcionais e fsicas do produto e subprodutos do projeto, controle das
mudanas feitas nessas caractersticas, registro e relato de cada mudana e o
andamento da sua implantao, suporte auditoria dos produtos para verificar
conformidade com os requisitos. Pode definir, tambm, como ser feita o controle de
verses dos documentos do projeto.
Define os procedimentos para efetuar mudanas nas baselines do projeto ou no
escopo do produto do projeto. Determina a documentao necessria, os sistemas
de acompanhamento e os nveis de aprovao necessrios para autorizar mudanas.
30
Planos Subsidirios
O gerenciamento do projeto e a manuteno dos elementos do projeto coesos entre
si compem a rea de conhecimento integrao. A boa prtica recomenda que seja
elaborado um plano determinando a melhor estratgia a ser adotada para gerenciar
cada uma das demais reas de conhecimento necessrias ao gerenciamento do
projeto.
Plano de Gerenciamento do Escopo
Plano de Gerenciamento do Tempo
Plano de Gerenciamento dos Custos
Plano de Gerenciamento da Qualidade
Plano de Gerenciamento dos Recursos Humanos
Plano de Gerenciamento das Comunicaes
Plano de Gerenciamento dos Riscos
Plano de Gerenciamento das Aquisies
Alm dos planos de gerenciamento das reas de conhecimento o plano do

gerenciamento do projeto deve conter alguns documentos como: contrato (quando
for o caso; a definio dos objetivos e metas (se houver mudana em relao ao
Termo de Abertura).
necessrio, tambm, tratar de aspectos da organizao e da forma como ser
conduzido o trabalho do gerenciamento do projeto. Quais processos sero utilizados
no gerenciamento. Que artefatos (documentos, grficos, tabelas, etc.) sero
elaborados e como ser o processo de elaborao. Como sero realizados os
processos de monitoramento e controle do projeto.
Outra definio importante quanto ao processo de planejamento, diz respeito s
ferramentas e tcnicas que sero utilizadas nos processos. Por exemplo, determinar
que o processo de definio do escopo do projeto utilizar reunies de brainstorming
e entrevistas com os principais stakeholders do projeto.
Linhas de Base (Baselines) de performance do projeto
O plano de gerenciamento do projeto definido e aprovado ser a Linha de Base de
referncia (baseline) a partir da qual o progresso do projeto ser avaliado. Sendo
assim, as variveis definidas de escopo, tempo, custo, qualidade, recursos humanos
(equipe do projeto), comunicaes, riscos e aquisies sero as bases de referncia
do projeto como um todo. Significa que quaisquer mudanas nestas referncias
devero ser tratadas como mudanas, pois geraro impactos no projeto.
31
COLETA DE REQUISITOS
O sucesso do projeto diretamente influenciado pela ateno na captura e
gerenciamento dos requisitos do projeto e do produto. Estes requisitos precisam ser
obtidos, analisados e registrados com detalhe suficientes para sem medidos uma vez
que a execuo do projeto se inicie. Coletar requisitos envolve definir e gerenciar as
expectativas do cliente. Os requisitos sero o fundamento para o planejamento do
escopo do projeto.
Os requisitos podem ser categorizados em requisitos do projeto e requisitos do
produto.
Os requisitos do projeto podem, por sua vez, se encontrar dentro de uma das
seguintes subcategorias:
Requisitos relacionados com as necessidades de negcio identificadas no

Termo de Abertura do Projeto (requisitos de negcio).
Requisitos relacionados ao gerenciamento do projeto (requisitos de prazo, de

custo e requisitos gerais de gerenciamento de projeto).
Requisitos relacionados com a forma pela qual o projeto deve ser realizado,
isto , relacionados ao processo do projeto.
Os requisitos do produto so aqueles que o produto do projeto precisa atender

desde sua entrega ao cliente, ao final do projeto, at o fim do ciclo de vida do
produto.
Os requisitos coletados so ento documentados em um Documento de Requisitos, e
usados como referncia para o planejamento e a execuo do projeto.
DEFINIO DO ESCOPO DO PROJETO

Apesar de haver uma pretenso j posta pelos demandantes do projeto, a forma do
resultado final, assim como os passos intermedirios e o seu processo de elaborao,
podem diferir, substancialmente.
Como vimos, projetos no so atividades determinsticas, ou seja, no tm seu
resultado garantido, pois so atividades que sempre carregaro uma parcela de
risco, ou incerteza, so, portanto, atividades probabilsticas.
Assim sendo, as escolhas possveis acerca do projeto precisam ser feitas. Este
processo faz parte da definio do escopo, tanto de produto quanto de projeto. O
desafio conseguir antever as conseqncias de cada escolha e identificar os
melhores relaes de custo e benefcio.
O escopo do projeto o ponto de partida de todas as outras variveis do projeto. O
tempo, os custos, a qualidade, os recursos humanos necessrios, etc., s podero
ser dimensionados se o escopo estiver definido. Ou seja, aquilo que para ser feito.
32
Todo o esforo dedicado uma boa definio de escopo ser bem empregado, pois
os demais parmetros do projeto dependem diretamente deste.
Elementos necessrios para definio do escopo (input)
Para melhor realizar o processo de definio do escopo recomendvel que se utilize
as informaes que estiverem disponveis at o momento:

Histrico de projetos anteriores

Declarao do trabalho
Project Charter
Declarao Preliminar do Escopo
Ferramentas e Tcnicas utilizadas no processo de definio do escopo

A natureza do produto do projeto ir determinar o conjunto de ferramentas e
tcnicas mais adequado para realizar a definio do escopo.
Brainstorming
Se o projeto indito e requer uma contribuio criativa o brainstorming ser uma
tcnica recomendada, pois consiste numa seo conduzida por um coordenador que
estimula os participantes a terem idias relacionadas ao objeto do projeto sem
restries de pertinncia, numa primeira rodada. Ou seja sem censura que reprima a
criatividade. Em seguida feita uma avaliao da pertinncia e selecionadas as
idias mais teis ao projeto.
Opinio de especialistas (presencial ou com a Tcnica Delphi)
importante, sempre que possvel, ouvir a opinio de especialistas sobre o tema do
projeto. O mtodo Delphi uma tcnica com algumas semelhaas ao brainstorming,
porm com algumas diferenas.
Ambas devem ser conduzidas por um coordenador, ou facilitador, porm no Delphi
os participantes permanecem annimos, portanto no devem estar no mesmo
ambiente fsico. O coordenador do processo coloca a questo a ser opinada, recolhe
as contribuies de cada participante, consolida, repassa os pontos de convergncia
sucessivamente at o grupo chegar ao consenso.
Esta tcnica tornou-se especialmente til com a facilidade da comunicao pela
internet. Hoje, podemos colher a opinio de um especialista que esteja do outro lado
do mundo.
Modelos (templates), formulrios, normas, checklists
Como apoio ao processo de definio do escopo conveniente lanar mo de
quaisquer modelos, formulrios ou listas de verificao que possam ajudar a lembrar
de elementos a serem includas no escopo.
Listas de verificao (Checklists) que contenham informaes tpicas relacionadas ao
tipo do projeto funcionam como uma espcie de roteiro e ajudam, no s a no
deixar de esquecer de itens importantes, como a ganhar tempo no processo. Por
33
exemplo, em um projeto de construo de uma residncia os itens: estilo

arquitetnico, nmero de quartos, existncia de piscina, etc., so tpicos.
Anlise dos Stakeholders
No apenas os interessados principais no projeto como o cliente e o patrocinador
(sponsor) tm requerimentos que devem ser considerados na composio do escopo
do projeto, os demais stakeholders, tambm, podem sofrer impactos, possuem
necessidades e expectativas que devem ser consideradas e atendidas, na medida em
que no comprometam o cumprimento dos objetivos do projeto. Em um projeto de
modificao de layout, um determinado setor da empresa pode ter como
requerimento que o trabalho seja interrompido o menor perodo de tempo possvel.
Se este requerimento puder ser atendido sem prejudicar a relao de tempo e custo
do projeto recomendvel que seja atendido, pois, a princpio, trar economia para
a organizao.
Metodologia de Desenvolvimento de Produtos
Todo projeto ao seu trmino entrega um produto, portanto, as diversas tcnicas
sistematizadas para o desenvolvimento de produtos so, na realidade, tcnicas de
definio de escopo. Engenharia Robusta, Engenharia Simultnea, Prototipagem,
QFD Quality Funtion Deployment, etc.
As principais destas tcnicas foram desenvolvidas nos anos 80 e, hoje, j esto
maduras em razo da aplicao intensiva com resultados expressivos em diversas
reas da economia, com literatura disponvel para estudos mais aprofundados.
Escopo do Produto e Escopo do Projeto

A boa prtica recomenda que para uma melhor organizao do trabalho se dividam
as informaes de escopo em escopo do produto e escopo do projeto.
Escopo do Produto
Este primeiro escopo trata das especificaes do resultado que ser gerado pelo
projeto na sua concluso. Descreve como ser a principal entrega do projeto.
Relaciona caractersticas, funes e atributos. Deve traduzir os requerimentos postos
ao projeto em especificaes para o resultado.
Especificar o produto do projeto significa diferenci-lo dos demais do mesmo gnero,
torn-lo, especial em suas particularidades, especfico. Em um projeto de uma
residncia, por exemplo, residncia genrica. A especificao ir definir quantos
quartos a residncia ter, quantos banheiros, se ter sala de jantar separada da sala
de estar, qual sero as cores, etc. Todos os requisitos que tornam a residncia que
ser construda nica.
Escopo do Projeto
Todo o trabalho necessrio para gerar o produto do projeto com todas as suas
caractersticas especificadas no escopo do produto compem o escopo do projeto.
34
Representa todas as entregas intermedirias necessrias para produzir a principal

entrega do projeto, para completar o escopo do produto. Para cada especificao de
escopo do produto haver pelo menos uma entrega de escopo de projeto associada.
Entregas (Deliverables) e Marcos (Milestones)

Alm do produto final ou resultado principal do projeto, ao longo do seu ciclo de
vida, sero gerados subprodutos ou resultados parciais. Resultados so gerados por
processos que seguem o modelo: entrada (input), processo (process) e sada
(output), porm no mbito de projetos necessrio fazer-se uma distino entre as
sadas (outputs) dos processos que no sero avaliadas e validadas por um terceiro
daquelas que sero avaliadas pelo prprio executor. As primeiras, ou seja, aquelas
que sero avaliadas e validadas por outro que no o prprio executor, so
consideradas entregas (deliverables). Os demais resultados sero apenas sadas
(outputs).
Portanto, pode-se considerar que as entregas sero objeto de um controle externo
ao executor. So passveis de verificao. O prprio termo remete ao movimento de
transmisso do executor para o avaliador.
Assim sendo, os momentos em que ocorrem entregas do projeto servem como
pontos de referncia para a avaliao do progresso do prprio projeto. Estes pontos
de verificao so denominados de marcos ou milestones.
A expresso milestone, literalmente pedra da milha, vem da engenharia romana que
usava uma pedra para marcar o percurso da estrada a cada de mil ps de um
soldado romano.
O conceito de marcar a distncia da origem como referncia fundamental para a
medio do trabalho realizado no projeto. Se a entrega prevista para ser realizada
naquele momento (ponto no tempo marco milestone) tiver sido efetivada, o
projeto estar dentro do cronograma. Se no, estar atrasado.
Dessa forma, o escopo (o trabalho) do projeto deve ser definido pelas entregas que
sero necessrias para que o projeto atenda aos seus requisitos.
35
Critrios de aceitao do produto

necessrio que as regras do jogo estejam bem claras desde o incio do projeto.
Estes critrios sero a referncia que os demandantes do projeto utilizaro para
avaliar se o projeto efetivamente cumpriu aquilo a que se props quanto aos seus
objetivos e metas.
So os limites de tolerncia para a aceitao formal das entregas do projeto. Sero
utilizados no processo de inspeo realizado pelo cliente, denominado no Guia
PMBOK de verificao do escopo do projeto. Compara aquilo que foi estabelecido
nos requerimentos com o que de fato entregue.
As metas do projeto so as referncias para o estabelecimento dos critrios de
aceitao. Uma meta de um projeto de desenvolvimento de um software pode
prever que 1.000 usurios faam acesso simultneo sem perda de performance, e
estabelecer como critrio de aceitao, que se at 900 o projeto ser aceito.
Excluses Especficas - Itens NO includos no escopo
Procura definir itens que no sero entregues pelo projeto. Este conjunto de
informaes faz-se necessrio porque, por melhor que seja a especificao do
escopo do projeto, sempre haver possibilidade de dvida quanto a configurao
tanto do produto do projeto quanto ao trabalho para realiz-lo.
Serve, tambm, para identificar expectativas dos demandantes quanto a entregas,
funcionalidades, atributos ou caractersticas que no foram explicitadas na
Declarao do Trabalho (Statement of Work).
H projetos que, por sua natureza, podem gerar elementos de especificao
considerados bvios pelo demandante e por isso no so lanados na Declarao do
Trabalho. Neste caso esta relao de itens funciona como uma lista de verificao
(checklist) daquilo que efetivamente esperado do projeto.
Premissas
So fatos assumidos como verdadeiros pelas partes demandantes e os realizadores
do projeto. So as regras do jogo. Condies sob as quais o projeto ser conduzido
e que, se modificadas, influenciam a capacidade do projeto de alcanar seus
resultados. Implicam, portanto, na necessidade de reviso dos parmetros
estabelecidos para o projeto. Pode-se elencar como premissas em um projeto de
desenvolvimento de um sistema corporativo, por exemplo, que ser necessria a
autorizao de acesso a membros da equipe do projeto aos sistemas da empresa.
Premissas so alvos primrios de riscos, porque, se atingidas, normalmente, geram
alteraes na estrutura do projeto e, conseqentemente, na capacidade de atingir
seus objetivos.
Restries
So fatores, previamente estabelecidos, que limitam as opes do projeto. Podem
ser normas organizacionais que precisam ser seguidas, regimentos, legislaes, ou
36
quaisquer obrigaes relacionadas ao objeto do projeto. O regimento interno de um

edifcio pode restringir o trabalho que gere rudo durante o perodo noturno.
Definio progressiva do escopo
H projetos cuja dificuldade de definio de escopo muito grande. Isto ocorre em
funo do ineditismo do produto do projeto, do ambiente tecnolgico ser muito
voltil, que o caso dos projetos de tecnologia da informao, ou mesmo pelas
necessidades serem muito difusas em funo de interesses diversos.
Este grau de incerteza pode ser traduzido em funo da distncia entre o ponto de
partida e o alvo (escopo) a ser atingido.
Geometricamente percebe-se que quanto maior for esta distncia maior ser a
possibilidade de desvio do alvo. Ou seja, uma pequena variao no incio pode, dada
a distncia ao alvo, tornar-se grande.
Portanto, a recomendao de que se procure identificar, sempre que possvel,

pontos de partio do escopo total que possam ser realizados parcialmente. Ou seja,
verificar se possvel dividir o projeto em partes e fechar o acordo de definio do
escopo da ou das partes que possibilitem a definio de escopo com razovel grau
de previsibilidade.
O alvo do projeto passa a ser ento B1 e no o todo Bt (total). O compromisso do

projeto entregar B1. Reduzindo o potencial de desvio.
A entrega B1 ser, posteriormente elemento de entrada (input) para o projeto de

entrega de B2 e assim sucessivamente at completar a entrega total pretendida (Bt).
37
A natureza integrativa do planejamento exige que reas como escopo, tempo e custo
sejam coordenadas cuidadosamente em um processo iterativo. medida que mais
informaes ou caractersticas do projeto so reunidas e compreendidas,
planejamento adicional pode ser necessrio. O detalhamento progressivo do plano
de gerenciamento do projeto geralmente chamado de planejamento em ondas
sucessivas, indicando que o planejamento e a elaborao da documentao
associada so processos contnuos e repetitivos.
A definio do escopo, dessa forma, permite que a demanda real do projeto, ou seja,
a razo de sua realizao, seja elaborada e formulada progressivamente.
O processo de Verificao do Escopo

Uma vez definido o escopo necessrio determinar como o cliente avaliar a sua
efetiva realizao. Que procedimentos sero usados para o cliente verificar, constatar
se aquilo que foi proposto na declarao do escopo corresponde ao que de fato
estar sendo entregue. Ser a aplicao de critrios de aceitao de entregas
parciais, ou intermedirias, e do produto final, definidos na declarao do escopo.
ESTRUTURA ANALTICA DO PROJETO (EAP)

(Work Breakdown Structure WBS)
Os americanos costumam referir-se EAP (WBS) como the big picture of the
project, no sentido de que uma imagem que permite a viso do todo, do conjunto
completo. Possibilita uma viso holstica do projeto. Que ao olhar a EAP (WBS)
consegue-se enxergar tudo aquilo que o projeto ir realizar.
Analisar (Estrutura Analtica) significa decompor em partes menores para melhor
compreender o todo e as partes que o compem. exatamente essa a misso da
EAP que a principal ferramenta para o gerenciamento do escopo do projeto.
A decomposio d-se de cima para baixo, da o termo em ingls: breakdown, a
partir do projeto, que ser o primeiro nvel, ou nvel zero, como preferem alguns
autores. Por ser uma ferramenta de escopo, na EAP no aparecem atividades (aes
ou tarefas), so representadas apenas entregas geradas pelo projeto (deliverables).
38
Portanto, nela no so representadas relaes de dependncia temporal de

execuo. A hierarquia da EAP diz respeito a um todo (no nvel acima) que
composto de partes (no nvel abaixo).
1
vel : Nome do Projeto
1 N
Nvel
1.
1. PROJETO
PROJETO
2.1
2.1 Fase
Fase 11
3.1
3.1 Entrega
Entrega
4.1
4.1 PT
PT
4.2
4.2 PT
PT
2.2
2.2 Fase
Fase 22
3.2
3.2 Entrega
Entrega
4.3
4.3 PT
PT
4.4
4.4 PT
PT
3.3
3.3 Entrega
Entrega
4.5
4.5 PT
PT
4.6
4.6 PT
PT
2.3
2.3 Fase
Fase 33
3.4
3.4 Entrega
Entrega
4.7
4.7 PT
PT
4.8
4.8 PT
PT
3.5
3.5 Entrega
Entrega
4.9
4.9 PT
PT
3.6
3.6 Entrega
Entrega
4.10
4.10 PT
PT
4.11
4.11 PT
PT
4.12
4.12 PT
PT
O segundo nvel da EAP representa o ciclo de vida do projeto, pois determina a

primeira partio do projeto, ou seja, suas macro-fases.
2
vel : Ciclo de Vida do Projeto
2 N
Nvel
1.
1. PROJETO
PROJETO
2.1
2.1 Fase
Fase 11
3.1
3.1 Entrega
Entrega
4.1
4.1 PT
PT
4.2
4.2 PT
PT
2.2
2.2 Fase
Fase 22
3.2
3.2 Entrega
Entrega
4.3
4.3 PT
PT
4.4
4.4 PT
PT
3.3
3.3 Entrega
Entrega
4.5
4.5 PT
PT
4.6
4.6 PT
PT
2.3
2.3 Fase
Fase 33
3.4
3.4 Entrega
Entrega
4.7
4.7 PT
PT
39
4.8
4.8 PT
PT
3.5
3.5 Entrega
Entrega
4.9
4.9 PT
PT
4.10
4.10 PT
PT
3.6
3.6 Entrega
Entrega
4.11
4.11 PT
PT
4.12
4.12 PT
PT
3
vel : Principais entregas do projeto
3 N
Nvel
1.
1. PROJETO
PROJETO
2.1
2.1 Fase
Fase 11
3.1
3.1 Entrega
Entrega
4.1
4.1 PT
PT
2.2
2.2 Fase
Fase 22
3.2
3.2 Entrega
Entrega
4.2
4.2 PT
PT
4.3
4.3 PT
PT
3.3
3.3 Entrega
Entrega
4.4
4.4 PT
PT
4.5
4.5 PT
PT
2.3
2.3 Fase
Fase 33
3.4
3.4 Entrega
Entrega
4.6
4.6 PT
PT
4.7
4.7 PT
PT
3.5
3.5 Entrega
Entrega
4.8
4.8 PT
PT
4.9
4.9 PT
PT
3.6
3.6 Entrega
Entrega
4.10
4.10 PT
PT
4.11
4.11 PT
PT
4.12
4.12 PT
PT
1.
1. PROJETO
PROJETO
2.1
2.1 Fase
Fase 11
3.1
3.1 Entrega
Entrega
4.1
4.1 PT
PT
4.2
4.2 PT
PT
2.2
2.2 Fase
Fase 22
3.2
3.2 Entrega
Entrega
4.3
4.3 PT
PT
4.4
4.4 PT
PT
3.3
3.3 Entrega
Entrega
4.5
4.5 PT
PT
4.6
4.6 PT
PT
2.3
2.3 Fase
Fase 33
3.4
3.4 Entrega
Entrega
4.7
4.7 PT
PT
4.8
4.8 PT
PT
3.5
3.5 Entrega
Entrega
4.9
4.9 PT
PT
4.10
4.10 PT
PT
3.6
3.6 Entrega
Entrega
4.11
4.11 PT
PT
4.12
4.12 PT
PT
ltimo N
vel : Pacotes de Trabalho
ltimo
Nvel
(menor entrega do projeto)
O projeto , ento, sucessivamente sendo quebrado (break), em nveis de entregas

cada vez menores at o menor nvel desejado para detalhamento do escopo do
projeto. Este nvel denominado no Guia PMBOK de pacote de trabalho.
A deciso de at onde decompor determinada por alguns fatores relacionados
forma pela qual o projeto ser gerenciado.
Novamente se apresenta uma situao de trade-off, ou seja, faz-se necessria uma
avaliao de custo/benefcio entre detalhar (decompor) ou no decompor.
A favor da maior decomposio pesa o fato de permitir uma melhor identificao
(visualizao) das menores partes e com isso aumentar a previsibilidade de projeto.
Porm este maior detalhamento implica em maior esforo de planejamento e
posterior controle.
O ltimo nvel de decomposio da EAP, ou detalhamento do projeto est
relacionado ao nvel de domnio e controle que se deseja exercer sobre os elementos
de escopo do projeto, isto , se for necessrio que um elemento de escopo seja
realizado exatamente de determinada forma, ento ser necessrio o detalhamento.
Por exemplo, em um projeto de um evento, onde a EAP for decomposta at o nvel
de aquisio das passagens areas dos participantes e no for relevante ou
determinante que a entrega seja decomposta em: prospeco, seleo e
contratao, isto se os detalhes de como a entrega ser realizada no forem
importantes e no requererem um controle de execuo das partes, no h
necessidade de decompor esta entrega. Neste caso a superviso e o controle ir at
o nvel de entrega das passagens areas.
40
O projeto , ento,
sucessivamente quebrado
(break), em subprodutos
cada vez menores at o
menor nvel desejado para
detalhamento do escopo do
projeto.
Possveis EAP (Estrutura Analtica

do Projeto WBS Work
Breakdown Structure) para um
mesmo projeto.
41
Ainda relacionado ao controle est o princpio 8/80 que recomenda que um pacote
de trabalho no tenha menos do que 8 e no mais do que 80 horas de durao. O
que equivale recomendar que o menor ciclo de controle do projeto no seja menor
do que um dia (8 horas) e no maior do que duas semanas (2 semanas de trabalho
de 40 horas)
Outro fator determinante para a parada da decomposio se a entrega ser
realizada por um terceiro. Mesmo que seja da prpria organizao executora, no
caso de um setor de Marketing que ir preparar um plano de marketing para o
projeto, nestes casos, o gestor do projeto figurar como um demandante de um
projeto (sub-projeto) e no haver necessidade de detalhar o como da entrega
terceirizada.
Decomposio dos pacotes de trabalho em atividades que formaro o diagrama de rede do projeto
Formas de EAP
A estruturao do projeto pode d-se da maneira mais conveniente para os
executores do projeto. Pode ser em formato de uma lista indentada ou em
distribuio radial, conforme exemplos abaixo.
42
Funes da EAP
Alm da misso de identificar a plenitude do trabalho do projeto, seguindo o
princpio dos 100%, que determinam que 100% do trabalho do projeto deve estar
representado na EAP, esta permite ou facilita a elaborao de uma srie de
elementos do projeto.
Por sua estrutura refletir a hierarquia de construo do projeto a EAP permite, com
pequenos ajustes, a elaborao do organograma do projeto.
Permite a atribuio especfica
de responsabilidades por
entregas
PROJETO
PROJETO
Gerente
Gerente do
do Projeto
Projeto
Fase
Fase 22
Resp.
Resp. Fase
Fase 22
Entrega
Entrega A
A
PT
PT 11
PT
PT 22
Entrega
Entrega B
B
PT
PT 33
Resp.Ent
Ent.A
.A
Resp.
Resp.Ent.A
PT
PT 44
R.PT
R.PT 11
R.
R. PT
PT 22
Resp.Ent
Ent.B
.B
Resp.
Resp.Ent.B
R.PT
R.PT 33
R.PT
R.PT 44
A EAP pode servir como referncia para uma identificao e tratamento de riscos a
partir de cada entrega.
43
Tratamento de
Riscos Associados
por entregas
PROJETO
PROJETO
Identificao de Riscos
Associados por entregas
Fase
Fase 22
Entrega
Entrega
PT
PT
Entrega
Entrega
PT
PT
PT
PT
PT
PT
Estimativas de custo tornam-se mais simples se seguirem a seqncia inversa da

EAP, ou seja de baixo para cima (Bottom Up).
100
100
50
50
25
25
50
50
25
25
25
25
25
25
O ltimo nvel da EAP, os pacotes de trabalho, uma vez decompostos, identificaro

as atividades do projeto que , sob o ponto de vista do processo de decomposio, a
menor clula do projeto. Com as atividades identificadas ser possvel construir o
cronograma do projeto.
A EAP est diretamente relacionada natureza do produto do projeto. Significa que
projetos de mesma natureza, como por exemplo, projetos de desenvolvimento de
software que utilizem a mesma metodologia, tero EAP muito parecidas, podendo,
inclusive, ser aproveitadas como modelo.
Dicionrio da EAP (WBS)

As entregas indicadas na EAP devem ser descritas de forma sucinta, portanto h a
necessidade de descrev-las de forma mais detalhada. Para isso, a boa prtica
recomenda que seja elaborado um dicionrio, uma espcie de glossrio da EAP
(WBS), no qual sero detalhados os significados e os elementos mais importantes
das entregas do projeto.
44
DICIONRIO DA WBS
Cdigo #
Responsvel
Data ltima atualizao
Verso #
Descrio da Entrega
Produto (Deliverable)
Critrios de Aceitao
Recursos
Durao
Custo
Milestones (Marcos)
Predecessor
Sucessor
Restries
Aprovador da Execuo
Data da Aprovao
Aprovador da Entrega
Data da Aprovao
Modelo de Dicionrio da EAP (WBS). As informaes essenciais so o cdigo e a descrio da entrega as

demais, inclusive de outras reas de conhecimento, tais como durao, custo etc., sero documentadas
na sequncia do processo de planejamento
CRONOGRAMA DO PROJETO
O desenvolvimento do cronograma do projeto envolve a definio das atividades e
seu sequenciamento, a determinao dos recursos humanos e materiais necessrios
realizao das atividades, a estimativa da durao das atividades e o
posicionamento em um calendrio real em que sejam consideradas as limitaes de
perodos de trabalho.
1- DEFINIO DE ATIVIDADES
A decomposio das entregas do ltimo nvel da EAP (pacotes de trabalho)
identificar as atividades necessrias para a realizao das entregas previstas pelo
projeto. Estas sero as menores unidades de execuo do projeto. As atividades
permitiro demonstrar as mais detalhadas relaes de dependncia necessrias
elaborao do diagrama de rede do projeto.
45
2- SEQUENCIAMENTO DAS ATIVIDADES

Sequenciar as atividades do projeto significa determinar as relaes de dependncia
lgica entre as atividades. A dependncia lgica uma relao de causa e efeito
entre atividades na qual: a atividade PREDECESSORA a causadora da SUCESSORA.
Ou seja, a atividade SUCESSORA determinada, influenciada, pela atividade
PREDECESSORA. A dependncia lgica no uma dependncia cronolgica, isto a
atividade SUCESSORA pode ser realizada antes no tempo da atividade
PREDECESSORA.
As atividades preparao para a prova e a marcao da data da prova podem ilustrar

essa diferena, pois dependendo das condies podem assumir o papel tanto de
PREDECESSORA como de SUCESSORA.
46
Tipos de dependncias
Dependncias Obrigatrias Seguem uma lgica rgida (hard logic). Dada a
natureza das atividades, a atividade sucessora depende necessariamente da
predecessora. fisicamente impossvel ser invertida. Por exemplo: a pintura de uma
parede depende do emboo.
Dependncias Facultativas H atividades, porm que no apresentam
dependncia lgica entre si, mas por convenincia, ou preferncia, o gestor do
projeto estabelece uma relao de dependncia. Tambm denominada de
dependncia arbitrada ou discricionria (soft logic), passa a existir por deciso do
gestor do projeto em funo de ser uma melhor composio de acordo com as
melhores prticas do ramo de atividade relacionada ao projeto, ou de experincias
em projetos anteriores. Por deciso gerencial, podem ser desfeitas ou invertidas.
Dependncias Externas Fatores externos ao projeto podem ter relacionamentos
que gerem restries forma pela qual as atividades podem ser conduzidas. Uma
aprovao governamental, por exemplo, ir limitar as atividades que dependam dela.
Relaes de Dependncia entre atividades
47
Todo projeto, por definio, tem incio e fim definidos previamente, ou seja, um
ponto de partida e outro de chegada, portanto possvel representar graficamente
as atividades do projeto em sequncias determinadas pelas relaes de dependncia
entre elas em forma de uma rede.
No diagrama de rede, ou diagrama de precedncia (PDM Precedence Diagramming

Method), so identificadas quais atividades sero executadas em srie e quais sero
desenvolvidas simultaneamente, ou em paralelo.
Os conjuntos de atividades dependentes entre si so denominados de caminhos. Um

projeto pode ter muitos caminhos, mas todos eles partiro do ponto de incio e
terminaro no ponto de fim do projeto. A rede acima apresenta os seguintes
caminhos: Incio-A-B-D-Fim; Incio-A-B-E-Fim e Incio-A-C-E-Fim.
48
Exemplo da determinao das dependncias entre as atividades e o consequente diagrama de rede
3- ESTIMATIVA DE RECURSOS
A fim de poder calcular as duraes das atividades necessrio determinar que
recursos humanos, materiais e de equipamentos sero utilizados, ou seja, os
recursos executores das atividades.
preciso identificar as disponibilidades de cada um dos recursos, a fim de que no
haja superalocaes, se o recurso prprio da organizao ou ser contratado de
terceiros, assim como suas capacidades de desempenho.
Havendo a possibilidade do recurso a ser utilizado na realizao da atividade
necessrio que cada recurso seja associado, atribudo, a cada atividade, conforme
figura a seguir.
49
No caso de recursos humanos importante identificar suas produtividades que

dependem de suas competncias especficas relacionadas natureza da atividade,
de suas experincias anteriores, nas suas formaes e perfis profissionais.
Quanto aos equipamentos importante, na medida do possvel, diferenciar a
capacidade nominal, a prevista no manual, da capacidade real, ou efetiva, pois uma
superestimao de desempenho pode gerar falsas expectativas que no momento da
execuo sero frustradas.
4- ESTIMATIVA DE DURAO DAS ATIVIDADES
Uma vez que os recursos executores com suas respectivas capacidades de
desempenho foram determinados, possvel estimar o tempo de durao das
atividades.
A durao da atividade como funo da relao entre o trabalho e os recursos

determinados para execut-lo faz com que o aumento do nmero de recursos para
uma mesma quantidade de trabalho, ou esforo, gere uma reduo na durao,
conforme grfico a seguir:
Entretanto, esta relao matemtica, na prtica no se confirma, pois segue o

princpio de economia dos lucros cessantes ou retornos decrescentes (Law of
Diminushing Returns), que considera que o ganho de produtividade com a adio de
recursos no linear, isto , na realidade os recursos tm competncias ou
capacidades diferentes, portanto gerando desempenhos diferentes.
50
Sendo assim, estas perdas devem ser compensadas quando forem feitas as
estimativas de durao das atividades.
Ao realizar o processo de estimar durao das atividades necessrio determinar o
grau de preciso requerido. Uma estimativa com maior preciso, se por um lado gera
maior confiabilidade, por outro requer mais esforo, utilizao e manipulao de mais
dados e informaes, portanto tem maior custo.
Em casos onde no possvel obter informaes mais precisas, pode-se estimar a
durao por analogia, isto , comparando com experincias anteriores. Vale
ressaltar, que se deve ter o cuidado em comparar grandezas de mesma ordem e
caractersticas.
A melhor condio de confiabilidade para a estimativa que seja obtida do prprio
recurso escalado para executar a atividade e que sua produtividade real seja
conhecida do gestor do projeto.
Na impossibilidade de definio do executor o gestor do projeto ter que realizar a
estimativa a partir da opinio de um especialista na matria, de tempos padro em
funo do tipo da atividade, ou de clculos paramtricos, ou seja, a multiplicao de
quantidades por produtividades. Modelos matemticos que estabelecem correlaes
entre variveis: metros por hora, montagens por dia, etc.
O processo de elaborao da estimativa, entretanto, determinante na qualidade
dos esforos e tempos estimados. Uma simples solicitao de prazo pelo gestor do
projeto ao executor pode esconder distores significativas. Vale a pena analisar
algumas situaes tpicas e seus efeitos nos parmetros do projeto.
Estimativa do Executor
Neste caso, o gestor do projeto solicita ao executor que estime a durao de uma
atividade. De modo geral, o executor faz uma anlise superficial, pois, infelizmente,
no prtica comum ter-se controles de time sheet ou apontamento de horas
correlacionando perodo de trabalho e tarefa ou atividade de projeto. Assim, a partir
51
apenas de uma idia do volume de trabalho j comprometido, o executor fornece

uma estimativa maior do que real para se defender de cobranas acerca do no
cumprimento do compromisso. O esquema abaixo procura ilustrar esta relao.
Nas estimativas fornecidas pelo executor, em geral, h a incluso de uma margem
de segurana para o cumprimento do compromisso. O executor no gosta de ter
sua estimativa no confirmada, portanto natural que queira se proteger colocando
colches (padding). Cabe ao gestor do projeto tentar identificar os excessos e
negociar, com base em histricos anteriores ou outras fontes uma maior adequao.
Estimativa do Gestor do Projeto
Aqui o gestor do projeto estima por sua conta a durao da atividade considerando
que o executor a realizar no perodo estabelecido e dedicar seu tempo
integralmente a execuo da atividade.
Estimativa Conjunta Gestor do Projeto e Executor

Neste caso, o gestor do projeto e o executor da atividade analisam os perodos
efetivamente disponveis e que realisticamente sero dedicados ao trabalho na
atividade e negociam uma distribuio da carga de trabalho e chegam durao da
atividade.
52
Estimativas Probabilsticas - Estimativa a partir de clculos estatsticos que

considera trs valores de estimativa (Three points Estimate): a estimativa mais
otimista, a mais pessimista, a mais provvel.
F
Esta modelagem foi elaborada para aplicao em projetos no final da dcada de 50

durante o desenvolvimento da srie de submarinos Polaris para a Marinha Americana
e foi denominada de PERT (Program Evaluation and Review Technique).
Este mtodo de estimar perfeitamente coerente com a natureza da atividade
projeto que essencialmente probabilstica. Apresenta as estimativas como faixas de
valores possveis e no como um palpite certeiro que dificilmente seria cumprido.
No primeiro passo, a formulao estatstica soma os tempos otimistas e pessimistas
ao mais provvel multiplicado por 4.
E=
O + 4M + P
6
Esta mdia considera a proporo probabilstica de ocorrncia da mais provvel e

gera um efeito de compensao dos extremos estimados. Ou seja, uma estimativa
que tenderia a ser muito otimista, ao aplicar a frmula compensada em direo a
valores pessimistas, e vice e versa.
E>M
E=M
E<M
M E
E M
Aps esta mediao necessrio estabelecer a faixa de expectativa de preciso, ou

seja, o intervalo a partir do qual ser estabelecido o compromisso do projeto. No
exemplo a seguir, estimativas calculadas com base na frmula probabilstica.
53
ATIVIDADE
Otimista
(O)
Mdia
(M)
Pessimista
(P)
Estimativa
(E)
Determinao da data da conferncia
Determinao do tema e do programa
Escolha do local
Obter palestrantes
Desenvolver material de divulgao
10
11
Obter mailling
4,5
Enviar divulgao
Imprimir material para participantes
3,5
Receber inscries
Preparar KITs
O intervalo de preciso determinado pelos desvios padres considerados. Para um

desvio padro a expectativa de cumprimento da estimativa de 68,26%, se forem
considerados dois desvios padro, sobe para 95,46% e se forem trs, para 99,73%.
99,73 %
95,46 %
68,26 %
1s
1s
2s
2s
3s
3s
A natureza da atividade, sua complexidade, seu ineditismo, etc., ser determinante

para a aplicao de uma faixa maior ou menor de estimativa.
Para o clculo do desvio padro pode ser utilizada a frmula emprica onde:
Desvio
Padro
s
P-O
6
54
ATIVIDADE
Desenvolver material de
divulgao
Otimista
(O)
3,00
Mdia
(M)
10,00
Pessimista
(P)
Estimativa
(E)
11,00
9,00
Desvio
Padro
1,33
Varincia
1,77
Range de
Estimativa
Range de
Estimativa
1s
1s
7.67
a
10.33
9,00
+ ou 1,33
2s
2s
6,34
a
11,66
9,00
+ ou 2,66
3s
3s
5,01
a
12,99
9,00
+ ou 3,99
Dessa forma a estimativa de durao da atividade E estaria entre 7,67 e 10,33 dias
com a preciso de 1 desvio padro, estaria entre 6,34 e 11,66 dias com a preciso
de 2 desvios padro e entre 5,01 e 12,99 dias com a preciso de 3 desvios padro
de tolerncia.
Caminho Crtico
O mtodo do caminho crtico (CPM - Critical Path Method) foi uma importante
contribuio para o gerenciamento de projetos, desenvolvida, no final da dcada de
50, pelo pessoal da companhia americana Duppont e a inglesa Remington.
O conceito baseia-se no modelo de rede que identifica caminhos, que so
conjuntos de atividades dependentes entre si. Dos caminhos do projeto um ou mais
deles ter ou tero maior durao. Este ou estes caminhos, determinam a durao
total do projeto. Este ou estes caminhos, sero considerados crticos porque
qualquer atraso nele ou neles resultar em atraso do projeto.
Os demais caminhos tero, portanto, menor durao. Esta diferena de durao ser
tratada como folga. Sendo assim o caminho crtico ser aquele ou aqueles com a
menor folga ou com folga igual a zero, no caso do tempo permitido ou demandado
ao projeto ser igual ao tempo calculado ou estimado. Por exemplo, se o produto de
um projeto precisa ser entregue no dia 30 e a estimativa calculada prev que o
projeto poder ser entregue no dia 25. Neste caso h uma folga de projeto que ser
tambm do caminho crtico. Portanto, o caminho crtico, nesse caso ser o de menor
folga.
55
importante ressaltar que as folgas dos demais caminhos, no-crticos so recursos

valiosos a serem utilizados pelo gestor do projeto e no tempo disponvel para ser
desperdiado. Uma manipulao adequada das folgas de caminhos no-crticos pode
gerar economias de tempo e custo significativas ao projeto, como veremos nos
mtodos de compresso ou reduo de cronograma.
Para calcular o Caminho Crtico necessrio seguir uma rotina que ser descrita
passo-a-passo a seguir.
Antes de mais nada, necessrio definir o que so incios mais cedo e mais tarde e
trminos mais cedo e mais tarde. Considerando-se o conceito de folga, onde haver
a possibilidade de executar as atividades de caminhos que no so crticos, que
portanto, tm folgas, dentro de um intervalo de tempo igual a folga sem
comprometer o projeto, ou seja, sem ultrapassar a durao do caminho crtico.
Sendo assim estas atividades podero comear a ser executadas em um momento
mais cedo ou em um momento mais tarde no cronograma sem atrasar o projeto.
Conseqentemente, somando-se a durao estimada para a atividade teremos seus
trminos mais cedo e mais tarde.
6
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Incio mais CEDO
Trmino mais CEDO
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Incio mais TARDE
Representao grfica da rede com a Atividade no N (Activiti-on-node AON)
56
Trmino mais TARDE
Para o clculo do caminho crtico necessrio analisar as atividades do projeto a fim

de estabelecer as relaes de dependncia a fim de encontrar os caminhos da rede
do projeto.
Atividade A pode comear imediatamente e tem uma

estimativa de durao de 3 semanas
Atividade B pode comear aps a atividade A ser

completada e tem uma estimativa de durao de 3
semanas
ATIV.
Ant.
Durao
Atividade C pode comear aps a atividade A ser

completada e tem uma estimativa de durao de seis
semanas
Atividade D pode comear aps a atividade B ser

completada e tem uma estimativa de durao de oito
semanas
C, D
Atividade E pode comear aps a atividade C e D serem

completadas e tem uma estimativa de durao de
quatro semanas
INCIO
FIM
Em seguida, calcula-se os tempos de incio e trmino mais cedo de cada atividade.
Trmino Mais Cedo de B = Trmino Mais Cedo de A + Durao de B
INCIO
4
FIM
57
Incio Mais Cedo de E (Convergncia)

= Trmino Mais Cedo da Atividade de
Maior Trmino Mais cedo das
convergentes
14 > 9
INCIO
14
14
18
FIM
18
18
Tempo Total do Projeto

Estimado
Se houvesse mais tempo permitido
Este valor seria diferente
Por Exemplo: 20.
O Projeto teria uma folga de 2 semanas
Depois o clculo dos tempos mais tarde.
INCIO
0
14
14
14
18
14
3 menor que 8
Se houvesse folga total

para o Projeto
Apareceria aqui
FIM
18
18
18
14
FOLGA em C
14 9 = 5
83=5
Com isso possvel identificar o caminho crtico do projeto, que, neste caso, tem
folga igual a zero. O outro caminho possui folga de 5 semanas.
CAMINHOS
INCIO
0
14
14
Dur
Incio-A-B-D-E-Fim
18
Incio-A-C-E-Fim
13
14
18
14
18
FIM
18
18
14
O diagrama de rede, portanto, permite identificar as relaes de dependncia entre

as atividades e o caminho crtico do projeto.
58
Grfico de Gantt
Cada ferramenta utilizada para o gerenciamento do projeto tem uma finalidade
especfica e apresenta um conjunto diferente de informaes. O grfico de barras
desenvolvido pelo Engenheiro Gantt no final da dcada de 20 mostra a proporo de
durao das atividades em uma escala de tempo. Mostra, tambm, os
posicionamentos dos perodos de durao das atividades. Permite visualizar mais
facilmente quanto de interseo h entre os momentos de realizao das atividades.
Atividades
10 11 12 13 14 15 16 17 18 19
Atividade A
Atividade B
Atividade C
Atividade D
Atividade E
Grfico de Gantt (ou Barras)
Algumas regras precisam ser respeitadas quando do desenho de um grfico de

Gantt. A escala de tempo no deve ser modificada em um mesmo desenho, pois isso
geraria perda da visualizao da proporo das duraes. A recomendao de que
se faa grficos diferentes para cada escala de visualizao. No caso de um projeto
de durao de 5 anos, poderia ser feito um grfico em anos, outro em semestres,
outro em trimestres, meses e at semanas. Da mesma forma, no se deve fazer
cortes no meio do grfico para encurt-lo.
Grfico de Gantt (ou Barras) e Diagrama de Rede, compondo o Cronograma do Projeto
59
Reduo do Cronograma (Schedule Compression)

Aps a elaborao do cronograma pode-se constatar que os prazos calculados no
atendem aos requisitos do projeto. Neste caso, deve-se procurar alternativas de
reduo do cronograma que mantenham a melhor relao de custo benefcio.
Fast Tracking (Paralelismo) A tcnica consiste na anlise de atividades do
CAMINHO CRTICO, que foram programadas para serem executadas em seqncia
linear a fim de verificar a possibilidade de passarem a ser executadas em paralelo,
simultaneamente.
B
I
Fim
E
G
Fim
A
C
H
As atividades do Caminho Crtico cujas relaes de dependncia so arbitradas e

foram planejadas em seqncia linear por convenincia de projeto, sero os alvos
primrios da anlise de Fast Tracking, porm as atividades com dependncias
obrigatrias tambm podem permitir um Fast Traking parcial. Ou seja uma parte da
atividades poder ser executada em paralelo ou simultaneamente.
T - FT
FT
Ganho de tempo com o Fast

Traking
O Fast Tracking tanto total quanto parcial aumenta o risco de atraso do projeto, pois
aumenta a necessidade de gerenciamento. Atividades ocorrendo em paralelo,
simultaneamente, exigem maior superviso. Os pontos de autorizao do incio da
sucessora so, em geral, difusos, isto , so obtidos por clculos paramtricos. Por
exemplo: aps 1 metro de cola aplicada ser possvel comear a colao do papel de
parede.
Pode exigir tambm, conforme a natureza das atividades a adio de mais recursos
para executar ambas as atividades.
No possvel afirmar genericamente que isto, necessariamente, levaria a um
aumento de custo, pois os ganhos com o tempo de execuo podem compensar e
60
at mesmo ultrapassarem o valor dos recursos adicionais. Por isso, tanto neste
mtodo como no seguinte, necessria uma anlise de trade-off, isto avaliar qual
opo trar mais vantagens para o projeto.
Crashing (Compresso) Mais uma vez o Caminho Crtico ser o alvo de uma
anlise que verificar se a adio, troca ou realocao de recursos poder gerar
ganhos de tempo no cronograma. Tambm, neste mtodo as trade-off so
necessrias.
Na adio de recursos necessrio considerar a influncia nos resultados de alguns
fatores.
1- Se a atividade sensvel durao, ou seja, se a adio de recurso de fato
diminuir sua durao. Por exemplo, em um projeto de uma casa, a atividade
de concretagem da laje requer um nmero necessrio e suficiente de
recursos humanos e de equipamentos para a realizao do trabalho de
lanamento e assentamento do concreto que determinam sua durao. No
haver reduo de durao se houver um acrscimo de recursos nesta
atividade.
2- A lei dos retornos decrescentes (Law of Dimininushing Returns), citada
anteriormente, deve-se considerar fatores tais como: a maior necessidade de
superviso, perdas por processos de setup redundantes, etc.
3- necessrio avaliar (trade-off), se o custo do recurso adicional ir ultrapassar
os ganhos de desempenho. Se isto acontecer, e o fator crtico de sucesso do
projeto for custo, a adio no ser uma alternativa vivel.
CUSTOS DO PROJETO
Uma vez definidos o escopo, o que fazer, e o tempo necessrio para fazer o que
precisa ser feito no projeto, pode-se estimar o quanto ir custar o projeto. Como em
todo o processo de planejamento a modo como o custo ser tratado no projeto
precisa ser planejado. Ser necessrio elaborar o plano de gerenciamento de custos
do projeto que indicar a estrutura de custos do projeto determinando a classificao
dos centros de custos, critrios de rateios, reservas previstas, etc., ou seja, definir a
estratgia a ser adotada na oramentao do projeto.
Classificao dos Custos
A forma geral, contbil, de classificar custos leva em considerao o ponto de vista
da empresa, isto , o referencial a empresa. Para uma classificao que sirva ao
gerenciamento do projeto, deve-se classificar custos sob a perspectiva do projeto, ou
seja, tendo como referencial o projeto e no a empresa.
Custos Fixos e Variveis Custos que no variam com o tempo, nem com a
intensidade de utilizao, nem com o volume de servios gerados pelo projeto, so
classificados como fixos. So custos que, independentemente da durao, ou de
quaisquer variveis do projeto, tero o mesmo valor. Se, ao contrrio da situao
anterior, os custos variarem de valor conforme o uso eles sero classificados como
custos variveis.
61
O custo do transporte de um equipamento, que ser usado no projeto, um

exemplo de custo fixo. J o custo de mo-de-obra para a execuo de uma atividade
do projeto um exemplo de custo varivel, pois seu valor depender da durao da
atividade.
Custos Indiretos e Diretos Um custo ser indireto se no conseguirmos atribulo direta e especificamente a uma nica atividade do projeto. Isto , se deste custo
beneficiarem-se mais de uma atividade do projeto. Neste caso haver a necessidade
de um rateio entre as atividades beneficiadas para que elas absorvam a proporo
devida a cada uma do custo. Se, ao contrrio, conseguirmos atribuir diretamente a
uma nica atividade um custo este ser classificado como um custo direto.
O salrio do coordenador de uma rea do projeto, por exemplo, cujo trabalho ser
dedicado a todas as atividades da reas coordenada, um custo indireto que dever
ser rateado entre todas as atividades da rea segundo critrios que sejam capazes
de representar a verdadeira proporo de dedicao do coordenador. J o custo de
um equipamento que ser utilizado exclusivamente para a execuo de uma nica
atividade dever ser classificado como um custo direto.
Uma classificao de custos realizada de forma indevida pode levar a distores que
mascarem a real distribuio dos custos no projeto, podendo gerar decises
desfavorveis aos objetivos do projeto.
Alocao dos custos no projeto
A fim de representar o real impacto dos custos nas partes especficas do projeto
necessrio que seja feita a apropriao de custos. A cada atividade do projeto dever
ser apropriado os valores correspondente aos seus custos diretos e carga dos
custos indiretos que lhes so devidas seguindo critrios de rateio.
Atribuio (vinculao) dos custos a cada atividade do projeto
62
A correta alocao dos custos do projeto gerar uma curva de custos incorporados
que ser o balizador de monitoramento e controle dos custos do projeto. Esta curva
em razo da natureza geral de projetos, que possuem um comportamento tpico de
menor intensidade de consumo de recursos no seu incio, maior consumo nas fases
intermedirias e declnio de consumo ao seu final, assume o formato de S, sendo,
portanto denominada de curva S do projeto.
Curva S do Projeto Curva de distribuio dos custos acumulados do projeto
Custo
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 36
1
Custo
40
100
70
10
30
70
30
60
40
60
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 36
550
500
450
400
350
300
250
200
150
100
50
0
PROJETO 1
Atividade 1
Atividade 2
Atividade 3
Atividade 4
Atividade 5
Atividade 6
Atividade 7
Atividade 8
Atividade 9
Atividade 10
280
280
8- Oramento total do Projeto

7- Reserva de Gerenciamento (Trat. Desconhecidos)
60
60
6- Base de Referncia de Custos (Cost Baseline)
220
220
5- Reservas de Contingncia (Trat. conhecidos)
20
20
Curva S do Projeto Representa a correlao direta entre as atividades e os custos do projeto
Estrutura hierrquica dos custos do projeto

200
200
4- Projeto
Aps a correta alocao ser obtido o montante geral oramentrio para o projeto ao
100
100
100
qual3- devero
ser somados os valores 100
relativos s reservas de contingncia
do
Contas de Controle
50
50
Copyright
Compass
International Knowledge
Center
2- Pacotes
de Trabalho
1- Atividades
25
25
25
25
63 5050
25
25
50
50
25
25
25
25
50
50
25
25
25
25
25
25
projeto, ou seja, os valores dos oramentos das aes de respostas aos riscos
identificados e classificados como merecedores, dada sua importncia para os
objetivos do projeto, de uma resposta ativa. Este somatrio representar a base de
referncia de custos do projeto. Significa dizer que se o valor reservado ao plano de
contingncia for gasto nas aes do plano no haver estouro de oramento, ou seja
este valor faz parte do plano de gerenciamento do projeto. Vide modelo abaixo:
280
280
8- Oramento total do Projeto

7- Reserva de Gerenciamento (Trat. Desconhecidos)
60
60
6- Base de Referncia de Custos (Cost Baseline)
220
220
5- Reservas de Contingncia (Trat. conhecidos)
20
20
4- Projeto
200
200
100
100
3- Contas de Controle
50
50
2- Pacotes de Trabalho
1- Atividades
100
100
25
25
50
50
25
25
25
25
50
50
25
25
25
25
50
50
25
25
25
25
25
25
O item 3 diz respeito a Contas de Controle que devem corresponder s macro

entregas do ciclo de vida do projeto e sero as correspondncias que o plano de
contas da contabilidade da organizao e o projeto podero fazer sua conciliao.
PLANEJAMENTO DA QUALIDADE DO PROJETO

A elaborao do Plano de Gerenciamento do Projeto prossegue e, neste ponto do
processo, j devem ter sido definidos o escopo, o tempo e o custo do projeto. Ou
seja, as trs principais variveis determinantes do projeto. Outros elementos do
plano, porm, ainda no tero sido tratados o que significa que as definies
anteriores podero e devero ser reformuladas, uma vez que o processo de
elaborao do plano de fato interativo. A seqncia segue uma ordem lgica, mas
que deve comportar idas e vindas.
Antes de tudo, importante lembrar que qualidade s pode ser entendida se

referenciada a um padro. Isto , no existe qualidade absoluta, mas sim qualidade
requerida por algum (sujeito) que espera atendimento dos seus requisitos dentro
de certas margens de tolerncia. Estas margens de tolerncia so os limites,
fronteiras do padro da qualidade requerida.
Plano de Gerenciamento da Qualidade
Assim sendo, o plano de gerenciamento da qualidade do projeto deve levar em
considerao este cenrio. A fim de encontrar a melhor estratgia para atender s
expectativas do cliente deve empreender todos os esforos possveis para descobrir
quais so estas expectativas, explicit-las, para, em seguida, encontrar os meios de
64
atend-las. O gerenciamento da qualidade do projeto, segundo o Guia PMBOK,

definido como sendo: os processos que cuidam das atividades da organizao
executora que determinam as responsabilidades, os objetivos e as polticas de

qualidade para que o projeto satisfaa as necessidades para as quais foi criado.
O plano de gerenciamento da qualidade definir padres e processos que garantam
a qualidade do projeto. Determinar como sero tratados a garantia dos processos e
o controle da qualidade do produto do projeto.
Deve definir, tambm, as responsabilidades especficas dos membros da equipe para
conduzir as aes do gerenciamento da qualidade. Quem liderar cada processo,
quem far inspees, quem aprovar, autorizar etc.
Anlise de Custo x Benefcio
O conceito de qualidade enunciado pela ISO 9000:2000 de que qualidade : o
grau no qual um conjunto de caractersticas inerentes satisfaz aos requisitos.

Portanto, no h qualidade absoluta ou total. Em meados dos anos 80, o termo
Qualidade Total foi interpretado equivocadamente como sendo qualidade absoluta,
quando deveria significar que a totalidade da organizao deve buscar a qualidade
como objetivo e no apenas aqueles que tinham como funo zelar pela qualidade.
Assim sendo, necessrio, para o planejamento da qualidade do projeto, identificar
qual a melhor relao entre as necessidades do cliente e os custos envolvidos para
atender a estas necessidades. Haver um ponto de equilbrio indicando que a partir
de um determinado ponto, no haver valor percebido pelo cliente.
Nvel de
Atendimento aos
requerimentos
Gold P lating
No Requsitado
No Esperado
No Contratado
Requisitos do P rojeto
(CLIENTE)
Valor Esperado
(contratado)
Custo
da Qualidade
Oramento do P rojeto
As entregas que excederem ao limite do contratado sero consideradas

formalmente, alm do requisitado, do esperado pelo cliente. No foi pedido pelo
cliente. O jargo da comunidade de gerenciamento de projetos denomina esta
prtica de gold plating. Em uma traduo livre, seria a gria: dourar a plula.
65
Significa que no faz parte do escopo muito menos dos requisitos acordados
formalmente. No uma boa prtica de gerenciamento de projetos entregar alm do
requisitado, pois a premissa de que seja elaborado um plano que atenda aos
requisitos e que este plano seja executado. Qualquer diferena a mais ou a menos
que no seja fruto da incerteza inerente a qualquer projeto, ou seja, movimentos
intencionais de modificaes do plano ser uma quebra do acordo feito com o
cliente.
Determinao dos Padres da Qualidade do Projeto
A qualidade precisa de uma referncia de avaliao. Esta referncia o padro da
qualidade que deve ser estabelecido pelo cliente do projeto. funo do gestor do
projeto identificar este padro e persegui-lo. Cada padro, porm, possui uma
probabilidade de ser atingido que depender das caractersticas de processamento e
gerao do produto. Esta probabilidade, ou possibilidade, de cumprimento do padro
que deve ser reconhecida e aceita pelo cliente ser tratada como TOLERNCIA.
Portanto, necessrio para estabelecer os acordos relacionados qualidade que
sejam determinantes do padro, ou seja a tolerncia do cliente variabilidade dos
resultados das entregas. Na figura abaixo temos a descrio de um padro, ou
tolerncia, para a fabricao de uma pea mecnica. Esta , certamente, uma
situao de grau de facilidade alto para a determinao destas variveis, pois quanto
mais abstrato for o objeto da entrega mais difcil a determinao dos padres e
tolerncias envolvidos. o caso por exemplo de projetos que geram solues para
um problema, ou melhorias. O que no exime o gestor do projeto de faz-lo.
Tolerncia = PADRO DA QUALIDADE
DD
D+
D
Procedimentos, mtricas e indicadores da qualidade

Uma vez que tenham definidos os padres de referncia do projeto ser preciso
determinar os procedimentos necessrios para que eles sejam atingidos, assim como
66
as unidades de medida, mtricas, para cada parmetro da qualidade e os indicadores

que permitiro monitorar o quanto eles estaro sendo cumpridos e tomar as medidas
preventivas e corretivas necessrias.
A medida da qualidade do projeto ser a medida do cumprimento dos parmetros
estabelecidos nas variveis de escopo, tempo de custo do projeto. Cada
especificao do projeto passa a ser uma referncia a ser seguida e medida da
qualidade do projeto. A determinao de que uma parede em um projeto de
construo de uma casa ser pintada com uma tinta especfica e com uma
determinada densidade so itens de escopo, mas a medida do cumprimento destas
especificaes, isto , a garantia de que a tinta e a densidade especificadas sejam
cumpridas assunto do gerenciamento da qualidade.
PAPIS E RESPONSABILIDADES DAS PESSOAS NO PROJETO

Atividades e ramos da economia, conforme sua natureza, so intensivos em capital,
caso das instituies financeiras, intensivos em tecnologia, caso das empresas de
telecomunicaes, intensivas em equipamentos caso de empresas que dependam
fortemente de mquinas, etc. Projetos so intensivos em pessoas. Significa que o
sucesso de um projeto depende diretamente do desempenho das pessoas que o
realizam.
O planejamento dos recursos humanos do projeto tem como objetivo criar o Plano
de Gerenciamento de Pessoal que estabelece a forma como as pessoas do projeto
sero incorporadas, organizadas, distribudas pelas partes do projeto, como sero
capacitadas e coordenadas para alcanarem os objetivos do projeto.
Contratao ou Mobilizao da Equipe do Projeto
De acordo com os requisitos de desempenho do projeto o plano indicar critrios e
processos necessrios para a busca e a escolha dos profissionais que integraro a
equipe do projeto.
O tipo de vnculo que o profissional ter com o projeto, ser determinado pela sua
origem. Se for pessoal da prpria organizao ser uma mobilizao, mas se for
externo organizao executora do projeto ser uma contratao.
Para tal necessrio que o gestor do projeto identifique as competncias que a
equipe deve ter a fim de realizar as atividades do projeto necessrias ao seu
sucesso.
A primeira dificuldade na identificao de competncias reside no fato de que
competncia diferente de qualificao, isto , competncia segundo Felipe
Perrenoud (1999), Capacidade de agir eficazmente em um determinado tipo de
situao, apoiando-se em conhecimentos, mas sem limitar-se a eles. O currculo do
profissional apresenta conhecimentos adquiridos em formao acadmica e
experincias anteriores, mas no consegue garantir que ele seja competente para a
atividade requerida.
67
O conhecimento um dos componentes da competncia, assim como as habilidades

que so desenvolvidas na prtica de atividades que requeiram a aplicao de
tcnicas conhecidas.
De forma simplificada competncias podem ser definidas como o conjunto de
conhecimentos, habilidades e atitudes de um profissional. Esquematicamente podese dizer que conhecimentos so o saber, as habilidades o saber fazer, e as
atitudes o querer fazer. Este ltimo elemento refere-se ao posicionamento que o
profissional frente aos desafios das atividades. Nele esto contidos o
comprometimento, o envolvimento e a motivao para agir no momento adequado
mobilizando conhecimentos e habilidades.
A identificao de competncias necessrias execuo do projeto assim como dos
potenciais membros da equipe de um projeto no da tarefa trivial. Exige, portanto,
que o gestor do projeto invista esforo considervel j que uma equipe competente
fator crtico de sucesso para o projeto.
As competncias necessrias ao projeto precisam ser traduzidas de forma mais
explicita e prtica possvel atravs da anlise da natureza de cada tarefa. Por
exemplo, ser necessrio elaborar um cronograma composto de: um grfico de
Gantt e de um Diagrama de Rede inseridos em um calendrio, utilizando o software
X. O profissional candidato posio precisa ser capaz de executar esta atividade
utilizando a referida ferramenta.
Aps a identificao das competncias exigidas para execuo de cada tarefa o
gestor deve especificar o conjunto de competncias que sero necessrias para cada
profissional do projeto, determinando, assim um perfil desejado.
Este perfil profissional desejado ser o instrumento que servir de guia para a busca
na prpria organizao, para uma mobilizao, ou no mercado, para uma
contratao.
Uma vez recrutados os candidatos, ser necessria a seleo. Para esta etapa,
Seguindo uma orientao focada em competncias, o gestor do projeto pode solicitar
que o candidato se submeta a um teste ou que obtenha informaes de fontes
abalizadas que atestem seu desempenho em tarefas equivalentes s que sero
necessrias, ou seja, que obtenha uma comprovao das competncias e no haja
apenas uma demonstrao de currculos.
Organograma e Matriz de Responsabilidades do Projeto
Como resultado estruturado do processo de especificao das pessoas em suas
respectivas posies, atribuies e relaes hierrquicas um organograma e uma
matriz de atividades por pessoas alocadas no projeto, conhecida como Matriz de
Responsabilidades.
68
Sponsor
Sponsor
Sponsor do
do Projeto
Projeto
Gerente
Gerente do
do Projeto
Projeto
Resp.
Resp.
Resp.Fase
FaseA
A
Membro
Membro 11
Membro
Membro 22
Resp.
Resp. Fase
FaseB
B
Membro
Membro 33
Apoio
Apoio
Apoio Adm
Adm
Resp.
Resp.Contratos
Contratos
Consultor
Consultor
Resp
Resp.
Ent.
Resp.. Ent
Ent.. nn
- Resp. Atividade A
- Resp. Atividade B
- Resp. Atividade n
Organograma do Projeto
No organograma devem estar demonstradas as relaes de subordinao funcional

no projeto. Devem estabelecer o papel de todas as pessoas que participaro
ativamente no projeto, inclusive pessoas externas organizao executora. Para
deixar claro que este organograma do projeto e no reflete necessariamente a
hierarquia da empresa, costuma-se denomin-lo de organograma virtual do projeto.
A matriz de responsabilidades tem uma abordagem mais operacional, pois as
referncias so as atividades do projeto e o papel que cada membro da equipe do
projeto desempenho em relao a elas.
Alguns princpios devem nortear a elaborao da matriz, entre eles o da unicidade de
comando. Isto , cada atividade deve ter apenas um responsvel. Mesmo que haja
dois membros da equipe que dividam a responsabilidade pela execuo da
atividade, recomendvel que o gerente do projeto nomeie um deles como o
responsvel.
Matriz de Responsabilidades do Projeto
69
PLANEJAMENTO DAS COMUNICAES DO PROJETO

O recente estudo de benchmarking realizado pelo PMI aponta a comunicao um
problema importante em projetos. Um dos principais fatores de fracassos em
projetos. Tratar as comunicaes de forma planejada, portanto, um caminho para
diminuir a probabilidade de dificuldades no gerenciamento do projeto.
Projeto algo que precisa ser criado para resolver um problema ou aproveitar uma
oportunidade. Estas necessidades ou requisitos precisam ser transmitidos,
comunicados, a quem ser encarregado de realiz-lo. Sendo assim, a comunicao
elemento chave neste relacionamento que dever identificar os objetivos e definir o
escopo do projeto. Portanto, se analisadas em mais profundidade as causas de
objetivos, escopo e outras varveis de projeto mal definidos, pode-se chegar com
freqncia ao componente comunicao como fator preponderante.
Muitos dos problemas ligados comunicao so identificados pela compreenso dos
elementos presentes no processo, conforme demonstra a figura a seguir.
Modelo Bsico de Comunicao (fonte: Guia PMBOK, 2008)
A partir deste modelo fundamental deixar claro que a responsabilidade pela

qualidade, eficcia, da comunicao do emissor. Ou seja, de quem transmite a
mensagem. Sendo assim, ele deve cuidar para que eventuais desvios, diferenas,
rudos, barreiras ou lacunas na comunicao no ocorram. E se ocorrerem dar o
melhor tratamento. Jogar a responsabilidade pela no compreenso da mensagem
para o receptor, no prtica recomendvel.
Ponto sensvel em ambientes de projeto, a escolha do cdigo utilizado pelo emissor
para encapsular a mensagem fator decisivo na eficcia da comunicao. O cdigo
escolhido pelo emissor deve ser de domnio do receptor. Como guardio da eficcia
da comunicao, o emissor, antes de mais nada, deve certificar-se de que o receptor
domina o cdigo que ser usado na transmisso da mensagem.
Jarges tcnicos de domnio de ambientes tecnolgicos restritos, com siglas e
abreviaturas especficas, muito comuns em projetos de reas intensivas em
tecnologia, so pontos de ateno para cdigos desconhecidos pelo receptor. A
presuno de que o jargo deve ser dominado, por quem do meio, perigosa.
Projetos so atividades de relacionamentos internos e externos organizao
executora. Hoje, dado o grau de especializao tecnolgico e a velocidade das
70
mudanas, profissionais de uma mesma rea podem ter srias dificuldades de

compreender os termos usados na comunicao de um projeto.
O problema se agrava se levarmos em considerao a interao que os executores
de projetos precisam ter com membros da alta direo empresarial. Um diretor
recm contratado pela organizao pode se sentir constrangido em demonstrar
desconhecimento de um jargo e por isso no externar que no compreendeu
adequadamente uma informao valiosa para sua tomada de deciso. O mesmo
pode ocorrer com um fornecedor ou outro stakeholder do projeto.
Assumindo o papel de responsvel pela eficcia da comunicao no projeto o
emissor deve, inclusive procurar garantir que o retorno (feedback) dado pelo
receptor seja ativo. Feedback ativo, no o mesmo que o receptor responder
entendi, porque pode ter sido entendido algo diferente do contedo que o
emissor desejava comunicar. Feedback ativo, portanto, requer a confirmao do
significado da mensagem nas palavras do receptor, afim de que seja possvel ao
emissor verificar se houve divergncia entre o que foi entendido e o que precisava
ser comunicado.
A ttulo de exemplo de uma estratgia para provocar feedback ativo de stakeholders
importantes tais como o cliente ou o sponsor, o gestor do projeto, durante uma
entrevista de levantamento de requisitos ou de definio de escopo, pode testar o
entendimento, induzir ao feedback ativo, lendo em voz alta o que foi acertado e
anotado e solicitando ao interlocutor que identifique alguma divergncia.
Portanto, o planejamento das comunicaes do projeto dever determinar:
O que deve ser comunicado.
Que documentos e informaes do projeto devem ser transmitidas. O Termo de
Abertura, a declarao do escopo, o plano de gerenciamento do projeto, variaes
de prazo, de custo, novos riscos identificados, mudanas, etc.
Quem deve enviar e receber a comunicao.
Os stakeholders (partes interessadas) do projeto devem ser o alvo de um plano de
comunicao de um projeto. A boa tcnica da comunicao recomenda, para maior
eficcia, a seletividade. Isto , a comunicao deve ser direcionada ao receptor
especfico. Se a comunicao no for seletiva pode causar o efeito que os e-mails
spam (comunicao em massa). A distribuio indiscriminada, no seletiva,
desvaloriza tanto a mensagem quanto o emissor. Outras mensagens do emissor no
seletivo tendem a ser desconsideradas. Este processo, portanto, depende de um
bom mapeamento, identificao precisa das necessidades e interesses, de cada
stakeholder do projeto.
Quando deve ser feita a comunicao.
A periodicidade ou momentos especficos do projeto que deve ser realizada. Uma vez
que o princpio do planejamento prevalea e o plano de gerenciamento do projeto
determine um ciclo de controle, o calendrio de reunies de progresso programadas
j deve ser divulgado a quem delas ir participar.
71
Como ser feita a comunicao.

Que meios ou canais sero utilizados a fim de que haja maior eficcia. Aqui tambm,
o princpio da seletividade se faz necessrio. Cada informao a ser comunicada a
um stakeholder especfico deve ser entregue pelos meios, canais, ou veculos
especficos. Determinada informao para alguns stakeholders pode ser suficiente a
publicao em um jornal de grande circulao ou em um dirio oficial regional. Para
outro stakeholder pode ser mais indicado uma apresentao presencial em sua
prpria sala. Cabe ao gestor do projeto, apoiado pelo sponsor, identificar estas
especificidades que so fatores crticos de sucesso para a comunicao do projeto.
Documento
Stakeholder
Quando?
Como?
Termo de Abertura
Sponsor, Cliente,
Equipe, Gerentes
Funcionais,...
Na abertura do projeto
Cpia em papel entregue

em mos
Plano do Projeto
Sponsor e Equipe
Na conluso do
planejamento

em mos
Contrato
Sponsor e Cliente
Na assinatura do contrato

em mos
WBS
Sponsor, Cliente,
Equipe
Na gerao do
documento

em mos
Cronograma de
Utilizao de recursos
Gerentes Funcionais
No trmino do
planejamento
Memorando interno
Riscos Identificados
Sponsor, cliente e
equipe
Na abertura do projeto e
na concluso do plano

em mos
Equipe
Na identificao de novos
riscos
E-mail
Problemas
identificados
Equipe
Na identificao de
problemas
E-mail
(...)
(...)
(...)
Matriz de Comunicaes
GERENCIAMENTO DOS RISCOS DO PROJETO

Risco de projeto, segundo o Guia PMBOK, um evento ou condio incerta que, se
ocorrer, ter um efeito positivo ou negativo sobre pelo menos um objetivo do
projeto, como tempo, custo, escopo ou qualidade.
Projetos so atividades probabilsticas e no determinsticas, isto , seus resultados
possuem considervel grau de incerteza. Projetos so realizados para a criao de
algo que no existe ou para a aplicao de uma soluo a um problema presente.
Em ambos os casos no possvel garantir com absoluta certeza que acontecero.
So eventos futuros sobre os quais possvel, no mximo, fazer estimativas e
previses com taxas de probabilidades associadas.
Neste cenrio o gerenciamento dos riscos constitui-se no conjunto de processos que
aumentem a possibilidade de sucesso do projeto, aumentando a probabilidade e o
impacto dos riscos positivos, e diminuir a probabilidade e o impacto dos riscos
negativos do projeto. Aumentar a dimenso das oportunidades, ou fatores favorveis
72
ao projeto alcanar seus objetivos e diminuir as ameaas, ou fatores desfavorveis

ao alcance dos objetivos do projeto.
Um risco origina-se de uma fonte, o evento materializa-se por uma causa que gera
conseqncias, impactos nos objetivos do projeto.
Configurao do Risco em projetos
O evento ser potencial, portanto, risco, se possuir uma probabilidade de ocorrncia.

Se a probabilidade for nula no ser considerado como hiptese, ou se for de 100%
ser um fato que pode configurar-se como uma certeza, restrio ou irrelevante para
o projeto. Havendo probabilidade de ocorrncia e a presuno de que o evento
venha a causar impactos, efeitos nos objetivos do projeto, ser considerado risco.
Portanto, um risco deve ser avaliado sempre considerando-se as duas variveis: a
probabilidade e o impacto.
Plano de Gerenciamento dos Riscos
O planejamento do gerenciamento dos riscos produzir um plano que determinar
como sero realizados os demais processos do gerenciamento dos riscos, que so:

Identificar os riscos
Realizar a anlise qualitativa de riscos
Realizar a anlise quantitativa de riscos
Planejar respostas aos riscos
Monitorar e controlar os riscos
Determinar, tambm, a abordagem, estratgia, que ser dada aos riscos de acordo
com suas caractersticas: se pr-ativa, agindo antecipadamente, ou reativa, agindo
se e quando, o evento incerto ocorrer.
Imediatamente aps a elaborao do plano de gerenciamento dos riscos, ainda no
processo de planejamento, ser necessrio realizar os processos do gerenciamento
dos riscos, exceto o de monitoramento e controle dos riscos que ser realizado ao
longo do processo de execuo do plano de gerenciamento do projeto.
Identificar os riscos
Determinao, atravs de uma abordagem organizada, dos riscos positivos e
negativos que podem afetar os objetivos do projeto. Este processo envolve, tambm,
o levantamento e documentao de informaes que caracterizem os eventos ao
ponto de permitir aes especficas sobre eles.
73
Para um melhor resultado neste processo, visto que envolve a identificao de

hipteses de eventos potenciais, recomendvel utilizar mtodos de trabalho em
grupo que estimulem a criatividade, tais como brainstorming, delphi, modelagens
mentais e de associao de idias, diagramas de causa e efeito (Ishikawa), anlise
de Foras, Oportunidades, Fraquezas e Ameaas (SWOT Strengths, Weaknesses,
Opportunities, and Threats) etc.
Modelos de categorizao elaborados no planejamento dos riscos, tais como
estruturas hierrquicas em forma de organogramas, neste caso, denominadas de
estrutura analtica de riscos (EAR), podem ajudar na induo de identificao de
riscos.
O principal resultado do processo de identificao de riscos um documento
denominado Registro de Riscos (Risk Register) que contm a lista de riscos, com
suas respectivas causas, efeitos e potenciais respostas.
Dicas para documentar bem os riscos do projeto:
1. Descrever o risco de maneira estruturada, utilizando uma descrio em 3
partes:
Devido a <uma ou mais causas>, <risco> poder ocorrer, o que levaria a <um ou
mais efeitos>.
2. Quanto mais especfica for a descrio do evento de risco, mais facilmente
conseguiremos planejar uma resposta e monitor-lo posteriormente.
Descrio genrica de um risco:
Devido situao atual do cliente, podero ocorrer mudanas de escopo, o que
levaria a um atraso do projeto.
Descrio especfica de um risco:
Devido quantidade de dvidas do cliente em relao s possibilidades de utilizao
do ambiente a ser construdo, poder ocorrer um aumento na rea de construo
prevista originalmente para o auditrio, o que levaria a um atraso na fase de
desenho do projeto.
3. Quando possvel, identifique alertas (triggers) que indiquem que o risco est
prestes a ocorrer. Eles o ajudaro futuramente no monitoramento e controle
daquele risco.
Descrio do Risco:
Devido falta de experincia do pessoal com o equipamento XYZ, um desempenho
ruim na execuo dos testes deste equipamento poder ocorrer, o que levaria a um
aumento da durao prevista dos testes, que de 20 dias.
Alerta:
Progresso dos testes inferior a 20% aps 4 dias de teste.
74
Exemplo de EAR (Estrutura Analtica de Riscos)
Realizar a anlise qualitativa de riscos

Priorizao dos riscos identificados para anlise ou ao adicional subseqente
atravs de avaliao e combinao de sua probabilidade de ocorrncia e impacto.
Classificao para priorizao dos riscos em funo da probabilidade e do impacto
75
Para o processo de anlise qualitativa de riscos podem ser utilizadas escalas

relacionadas s duas principais variveis do risco: a probabilidade de ocorrncia e o
impacto sobre os objetivos. A ferramenta denominada Matriz de Probabilidade x
Impacto permite uma melhor visualizao da classificao dos riscos do projeto.
Os graus ou as faixas das escalas de probabilidade e de impacto devem ser
determinados de acordo com o perfil de tolerncia ou averso a riscos da
organizao executora do projeto.
Exemplo de Escala de PROBABILIDADES
Exemplo de Escala de IMPACTOS
76
Exemplo de MATRIZ DE PROBABILIDADE X IMPACTOS (P x I)
Na matriz os eventos so posicionados de acordo com as estimativas de

probabilidade e impacto a fim de que sejam classificados segundo o produto das
duas variveis. Esta classificao servir de orientao estratgia de resposta que
ser elaborada no processo de Planejamento de Resposta aos Riscos. Os riscos com
classificao ALTA, por exemplo, alta probabilidade e alto impacto podem ser
considerados de prioridade mxima e exijam tratamento agressivo. J para os de
classificao BAIXA, a estratgia pode ser passiva, ou seja, apenas monitor-los a
partir de uma lista de observao (Watchlist).
Realizar a anlise quantitativa de riscos
Anlise numrica do efeito dos riscos identificados nos objetivos gerais do projeto.
Tem por objetivo analisar numericamente os riscos mais significantes estabelecidos
durante a anlise qualitativa, e a interao entre eles, para estimar a faixa de
possveis resultados para o projeto como um todo.
Este processo utiliza tcnicas como a simulao de Monte Carlo e a anlise da rvore
de Deciso para:
Quantificar os possveis resultados do projeto e suas probabilidades
Avaliar a probabilidade de atingir objetivos especficos do projeto
Identificar os riscos que exigem mais ateno quantificando sua contribuio

relativa para o risco total do projeto.
Identificar metas realistas e alcanveis de custo, cronograma ou escopo,

quando fornecidos os riscos do projeto
Determinar a melhor deciso de gerenciamento de projetos
Planejar respostas aos riscos

Desenvolvimento de opes e aes para aumentar as oportunidades e reduzir as
ameaas aos objetivos do projeto.
Formas de responder a riscos NEGATIVOS de um projeto:
Eliminar o risco, planejando uma forma de exclu-lo completamente.
77
Mitigar o risco, buscando uma forma de reduzir a probabilidade de sua

ocorrncia ou do seu impacto, caso o mesmo venha a ocorrer.
Transferir o risco, normalmente repassando-o para um terceiro.
Formas de responder a riscos POSITIVOS de um projeto:

Explorar o risco, eliminando a incerteza associada a um risco positivo

fazendo com que a oportunidade efetivamente acontea.
Melhorar o risco, modificando o tamanho da oportunidade

aumentando a probabilidade e/ou impacto (valor esperado) do risco
positivo.
Compartilhar o risco, atribuindo a sua propriedade a terceiros que

possam capturar melhor a oportunidade do risco acontecer em benefcio
do projeto.
Formas de responder a riscos POSITIVOS e NEGATIVOS de um projeto:

Aceitar Ativamente, buscando se preparar com reservas de tempo ou

de dinheiro caso o risco venha a ocorrer.
Aceitar Passivamente, simplesmente no fazendo nada e torcendo

para que o risco no venha a ocorrer.
Respostas de Contingncia, elaborando planos de contingncia que s

sero executados se algum alerta, sintoma ou trigger (gatilho) ocorrer, ou
se o prprio risco ocorrer.
Estratgias de Resposta aos Riscos
78
Dicas para documentar bem um plano de respostas a riscos:

1. Planos de resposta a riscos devem ser mais do que simples desejos de que
as coisas dem certo.
Plano de ao ou apenas um desejo?:
-
Garantir que o equipamento seja entregue no prazo.
Plano de ao objetivo:
-
Negociar com o fornecedor visitas quinzenais fbrica para

verificao do progresso da fabricao do equipamento.
Disponibilizar linha de comunicao direta (hot-line) com a fbrica

para agilizar comunicao de eventuais problemas durante a
fabricao.
2. Evite que os planos de resposta descrevam apenas o que j parte das

atividades cotidianas do trabalho.
Descrio do Risco:
-
Quebra da alavanca cdigo BHYZPT durante instalao do quadro

eltrico n 21A.
Plano de ao ou trabalho do dia-a-dia?:
Seguir as especificaes de instalao do quadro eltrico.
O que poderia ser feito de diferente, em relao ao que j costume, para

mitigar ou prevenir a ocorrncia do risco?
3. Cuidado com aes de resposta que exijam acompanhamento durante toda a
extenso do projeto:
Em lugar de:
-
Acompanhar as atividades do fornecedor atravs de gesto

integrada.
Prefira:
-
Elaborar procedimento para acompanhamento das atividades do

fornecedor atravs de gesto integrada.
Monitorar e controlar os riscos

Acompanhamento dos riscos identificados, monitoramento dos riscos residuais,
identificao dos novos riscos, execuo de planos de respostas a riscos e avaliao
da sua eficcia durante todo o ciclo de vida do projeto.
79
80
PROCESSOS DE AQUISIES
O projeto precisa de recursos para conseguir realizar seus objetivos. Dessa forma, os
processos de aquisio determinaro como ser a aquisio de bens e servios de
fora da organizao executora do projeto.

Planejar Aquisies
Realizar Aquisies
Administrar Aquisies
Encerrar Aquisies
Deciso de Comprar ou Fazer (Make or Buy)

Como parte do processo de planejamento das aquisies, necessrio analisar as
alternativas para cada recurso necessrio ao projeto entre adquirir de fora da
organizao ou produzir internamente. Considerar prs e contras, preferencialmente
utilizando mtodos de tomada de deciso.
Indicaes de FAZER

Facilidade de integrao com operaes de rotina

Utilizao de capacidade ociosa
Falta de fornecedores confiveis
Necessidade de controle direto
Indicaes de COMPRAR

Fornecimento especializado
Pequenos volumes
Capacidade limitada
Ampliar leque de fornecedores
Transferncia de risco ao fornecedor
Seleo do Tipo de Contrato

1- Contratos com Preo Fixo e com Pagamento Integral
2- Contratos com Reembolso de Despesas
3- Contratos de Mo-de-Obra e Material
Especificao do Servio (SOW Statement of Work)
A fim de que as necessidades especficas do projeto sejam atendidas importante
identificar todas as caractersticas de cada item a ser adquirido. Neste momento do
projeto o gestor do projeto estar atuando como um cliente. Quanto mais
especificaes forem passadas aos fornecedores maiores sero as chances de que as
aquisies sejam adequadas.
O nvel de definio do escopo de cada parte do projeto determinar a possibilidade
de especificao da aquisio e conseqentemente do modelo de contrato que
poder ser firmado. Se o escopo no estiver bem definido o contrato dificilmente
poder ser por preo fixo, o que acarreta mais risco para o comprador, neste caso o
gestor do projeto.
81
Critrios e Mtodos de Avaliao de Fornecedores

A melhor prtica de aquisies recomenda que se utilizem mtodos de tomada de
deciso que diminuam a subjetividade da escolha de fornecedores. Esta prtica pode
diminuir, tambm, a influncia do fator preo sobre a escolha do fornecedor, o que
em muitos casos no sinnimo de qualidade nem de melhor soluo tcnica.
APROVAO DO PLANO DE GERENCIAMENTO DO PROJETO

Todo este trabalho que at agora analisamos de desenvolvimento do plano de
gerenciamento do projeto precisou ser AUTORIZADO. Autorizao esta necessria
para que o gestor do projeto e, dependendo da situao, uma equipe de
gerenciamento do projeto, pudessem trabalhar na configurao do plano de
gerenciamento do projeto.
O trabalho de desenvolvimento foi AUTORIZADO, entretanto o plano desenvolvido
precisa ser APROVADO.
A instncia aprovadora do plano de gerenciamento do projeto depender de cada
projeto. Tipicamente, o Patrocinador (Sponsor) do projeto teria esta prerrogativa,
mas pode ser aprovado por uma diretoria ou constitudo um comit especialmente
para esse fim.
Cabe lembrar que a aprovao do plano pressupe a concordncia com todos os
parmetros do projeto incluindo, prazo e oramento.
Conceitualmente, a partir de sua aprovao, o plano de gerenciamento do projeto
passa a representar a referncia para a execuo do projeto, a linha de base do
projeto (Project baseline).
A integridade desta referncia, linha de base, passa a ser responsabilidade do gestor
do projeto, isto , uma vez aprovado o plano, criada a linha de base, toda mudana
em qualquer dos parmetros do projeto deve ser tratada como modificao do
plano. Significa que dever ser conduzido um processo de aprovao das mudanas
pelas instncias autorizadas para tal.
REUNIO DE PARTIDA DA EXECUO DO PROJETO KICKOFF MEETING
A boa prtica recomenda que o incio da execuo do plano de gerenciamento do
projeto seja marcado, isto , COMUNICADO aos principais stakeholders do projeto e
organizao executora como um todo.
Este pontap inicial tem a finalidade de esclarecer dvidas relacionadas ao plano
de gerenciamento do projeto, a estratgias utilizadas, sistemas de controle adotados,
pontos crticos, objetivos especficos, metas, enfim, o momento e a oportunidade
de confirmar a participao e o comprometimento dos principais envolvidos com os
objetivos do projeto e angariar apoio de reas fornecedoras de recursos.
82
Execuo,
Monitoramento
e Controle
do Projeto
Uma vez elaborado o plano de gerenciamento do projeto,
necessrio realiz-lo, cumpri-lo. Esta afirmativa est longe de ser uma obviedade,
porque comum que no calor dos acontecimentos o plano seja esquecido e o
processo de execuo passe a ser uma sucesso de improvisos.
O processo de execuo consiste na integrao das pessoas e recursos materiais
para realizar o plano de gerenciamento do projeto. A concentrao dos esforos
necessrios para atingir os objetivos estabelecidos para o projeto.
Os processos de monitoramento e controle ocorrem desde o primeiro momento do
projeto, porm, quando o plano estiver sendo executado, as exigncias de
monitorar, isto , verificar como est sendo executado o plano, e quando necessrio,
tomar medidas corretivas, ou seja, controlar, tornam-se mais prementes.
A execuo do projeto envolve essencialmente:
Executar, seguir o PLANO DE GERENCIAMENTO DO PROJETO
Realizar o ESCOPO do projeto
Entregar os PRODUTOS INTERMEDIRIOS
Gerenciar os RECURSOS
Gerenciar MUDANAS
Corrigir DESVIOS
Atualizar o PLANO DE GERENCIAMENTO DO PROJETO
Equipe de execuo do projeto

o momento de incorporar os membros da equipe que o plano de gerenciamento de
pessoal determinou como necessria realizao do projeto. Mobilizar, se for
pessoal interno organizao ou contratar, se forem externos.
Em ambos os casos o gestor dever apia reas de suporte no recrutamento,
conduzir entrevistas e avaliar as competncias dos candidatos.
83
Faz parte das atribuies do gestor neste momento do projeto, o desenvolvimento

de competncias que ainda no estejam plenamente incorporadas pelos membros da
equipe, seguindo estratgias e mtodos de desenvolvimento profissional.
Ciclo de Controle do Projeto
A freqncia com que o projeto ser, de forma programada, monitorado e
controlado pode ser decisivo para o sucesso do projeto, pois determinar o nvel de
esforo empreendido nestes processos.
Ciclo muito frequente
Mais uma vez coloca-se uma situao em que faz-se necessrio encontrar o ponto de
equilbrio, pois uma frequncia muito alta ir requerer um esforo que talvez
inviabilize o trabalho de monitoramento e controle. Pode inviabilizar, por exemplo, a
atualizao dos documentos do projeto. Levando situao na qual o controle
excede o objeto controlado, princpio de Henry Fayol, que em outras palavras,
significa consumir mais esforo para monitorar e controlar do que para fazer.
Ciclo pouco frequente

Por outro lado, demorar para monitorar o projeto pode levar a desvios de tal ordem
que no possam mais ser corrigidos, isto , no seja mais possvel s aes
corretivas fazerem o projeto voltar sua linha de base. Desvios impossveis de
serem corrigidos levam necessidade de mudana para que o projeto continue com
uma linha de base factvel. Uma linha de base que sirva, efetivamente de referncia
para a execuo do projeto.
84
O monitoramento e controle do projeto

A cada ponto do ciclo de controle de acordo com o previsto no plano de
gerenciamento do projeto devem ser realizadas medies para a coleta de dados
para a determinao do status do projeto. A data em que as medies so realizadas
denominada DATA DATE (Data dos Dados). A sequncia de grficos, a seguir,
As atividades em vermelho pertencem ao caminho crtico. No primeiro ponto do Ciclo

de Controle (C1), na DATA DATE, os dados de execuo do projeto devero ser
85
Dados coletados: Atividade A concluda e sem variao de custo
Os dados indicam, portanto que no primeiro Ciclo (C1) o projeto est de acordo com
o planejado. Cronograma e Oramentos cumpridos. No segundo ponto do Ciclo (C2)
Impactos no PRAZO
1- Atraso na Atividade B (Caminho Crtico) gera atraso no projeto
2- Atraso na Atividade C no gera atraso por ter FOLGA de 5 dias
CRONOGRAMA ATRASADO
Impactos no CUSTO
1- Atividade B gastou mais 20% do orado para fazer apenas 80% de 100% planejados
2- Atividade C gastou mais 30% do orado para fazer apenas 30% de 50% planejados
ORAMENTO ESTOURADO
Se nenhuma ao corretiva for tomada o projeto sofrer os impactos totais

identificados, mas papel do gerente do projeto identificar aes que neutralizem ou
86
minimizem os impactos dos desvios e tragam o projeto as previses de prazo e custo

originais, ou seja, voltar linha de base.
87
GERENCIAMENTO DO VALOR AGREGADO EARNED VALUE MANAGEMENT

O ponto de partida para medidas de gesto efetivas uma correta avaliao do
desempenho do projeto. Uma forma estruturada de avaliar o desempenho de
projetos a tcnica do Gerenciamento do Valor Agregado, que oferece uma ampla
viso dos desvios existentes, tanto de custo como de prazo, utilizando como base
informaes de custo do AVANO FSICO ou ESCOPO REALIZADO.
O Valor agregado tem foco na relao entre CUSTOS reais incorridos e o trabalho
realizado no projeto (ESCOPO) dentro de um determinado perodo de TEMPO. O
foco est em comparar o quanto foi efetivamente gasto com o quanto foi
efetivamente produzido (agregado Avano Fsico ESCOPO realizado) e no o
quanto foi gasto com o quanto se esperava gastar.
Valor agregado pode ser definido como a avaliao entre o que foi obtido em relao
ao que foi realmente gasto e ao que se planejava gastar, onde se prope que o valor
a ser agregado inicialmente para uma atividade o valor orado para ela. Na medida
em que cada atividade realizada, aquele valor inicialmente orado para a atividade
passa, agora, a constituir o Valor Agregado do Projeto.
O EVM como conhecido o mtodo do Gerenciamento do Valor Agregado, portanto,
disponibiliza um sistema de controle gerencial unificado confivel, propicia a
integrao do trabalho, prazos e custos utilizando a EAP do projeto (WBS) e
permite anlises comparativas com projetos j concludos.
O EVM permite ao gerente do projeto responder a perguntas como:
O cronograma est adiantado ou atrasado?
O oramento est acima ou abaixo?
A ttulo de exemplo, consideremos um projeto com durao de 7 meses e que

possua trs fases. Cada uma com seu oramento especfico, e os valores, em Reais,
acumulados ao fim de cada fase e do projeto. Poderamos representar estes valores
no grfico da Curva S do projeto.
88
Ao final do segundo ms, no primeiro ciclo de controle (C1), efetuada a verificao

e constata-se que o que estava previsto foi efetivamente realizado. Sendo assim, o
avano fsico foi de 100%. Podemos considerar, portanto, que o valor agregado ao
Quanto ao avano fsico o projeto est em dia, isto , o cronograma est sendo
cumprido. Entretanto, ao verificarem-se os gastos reais, constatou-se que foram de
R$ 1.200. Ou seja, R$ 200. acima do oramento de R$ 1.000. para a fase.
89
Entretanto, ao final do quinto ms, no segundo ciclo de controle (C2), as medies

indicam que apenas metade do que estava planejado foi efetivamente realizado.
Significa que o avano fsico foi de 50%, equivalendo a um valor agregado de
Neste ciclo, porm, os gastos reais, o custo real apurado, foi equivalente ao valor
agregado, ou seja, os gastos forma proporcionais ao que foi efetivamente realizado.
Sendo, ento, de R$ 1.500.
90
Neste ponto, o projeto est atrasado, pois agregou apenas R$ 2.500. quando deveria
ter agregado R$ 4.000. e est, tambm, com o oramento estourado, pois gastou R$
2.700. para agregar apenas R$ 2.500. comum gestores de projetos que no
utilizam o EVM interpretarem, erradamente, o gasto real de R$ 2.700. como bom
desempenho ao compararem com os R$ 4.000. previstos. Porm a comparao deve
ser do gasto real com o valor agregado, ou seja, com o que foi efetivamente
realizado.
O mtodo do Valor Agregado permite, portanto, uma avaliao da sade do projeto
de maneira analtica considerando as principais variveis do projeto: ESCOPO,
TEMPO e CUSTO comparadas duas a duas, sempre tendo como ponto de partida o
ESCOPO completado, ou avano fsico, ou VALOR AGREGADO.
A partir da medio fsica do quanto foi efetivamente realizado em termos de
ESCOPO (Avano Fsico), esta grandeza comparada no ponto do tempo (milestone)
para avaliar o desempenho de TEMPO e comparada com os gastos reais, CUSTO
real, naquele ponto, para avaliar o desempenho de CUSTO do projeto.
Indicadores do EVM
PV Valor Planejado (Planned Value)
(COTA Custo Orado do Trabalho Agendado)
Nomenclatura Antiga: BCWS Budget Cost of Work Scheduled
O que planejamos executar at esta data? No exemplo: Em C1= 1.000. C2= 4.000.
EV Valor Agregado (Earned Value)
(COTR Custo Orado do Trabalho Realizado)
Nomenclatura Antiga: BCWP Budget Cost of Work Performed
Quanto efetivamente executamos do que planejamos? Em C1= 1.000. C2= 2.500.
AC Custo Real (Actual Cost)
(CRTR Custo Real do Trabalho Realizado)
Nomenclatura Antiga: ACWP Actual Cost of Work Performed
Quanto efetivamente gastamos naquilo que executamos? Em C1= 1.200. C2= 2.700.
BAC Orado na Concluso (Budget at Completion)
Qual o valor total orado para o projeto? No exemplo = 5.000.
CV Variao de Custo (Cost Variance) CV=EV AC
Em C1 = 1.000 1.200 = (- 200). C2 = 2.500 2.700 = (-200)
SV Variao de Prazo (Schedule Variance) SV=EV - PV
Em C1 = 1.000 1.000 = 0 (sem variao). C2 = 2.500 4.000 = (- 1.500)
Variaes Negativas so sinal de ALERTA !!!
CPI Indicador de Desempenho de Custo CPI=EV/AC
(Cost Performance Index)
Em C1 = 1.000 / 1.200 = 0,83. C2 = 2.500 / 2.700 = 0,93 (estourado)
91
SPI Indicador de Desempenho de Prazo SPI=EV/PV

(Schedule Performance Index)
Em C1 = 1.000 / 1000 = 1 (OK). C2 = 2.500 / 4.000 = 0,63 (atrasado)
ndices menores que 1 so sinal de ALERTA !!!
ETC Estimado para Completar (Estimated to Completion) ETC = BAC EV
Valor total estimado que falta para completar o projeto
Quanto falta para completar.
Em C1= 5.000 1.000 = 4.000. C2= 5.000 2.500 = 2.500
EAC Estimativa na Concluso (Estimate at Completion) EAC = AC + ETC
Valor total estimado para o projeto
O quanto gastaremos no total NOVO ORAMENTO
O quanto gastaremos no total (EAC)
ser sempre igual a o quanto j gastamos (AC) + o quanto gastaremos (ETC).
Em C1 = 1.200 + 4.000 = 5.200. C2 = 2.700 + 2.500 = 5.200 (estouro de 200)
Parmetros do EVM na Curva S do projeto
92
MTODOS DE MEDIO DO TRABALHO (VALOR AGREGADO)

A base de todo o mtodo do Gerenciamento do Valor Agregado (EVM) reside na
medio do avano fsico, do escopo completado, trabalho efetivamente realizado.
Todos os indicadores partem do valor agregado (EV) para os clculos, portanto a
maneira como ser medido o valor agregado precisa seguir mtodos que
estabeleam padres confiveis.
12345-
Percentual (%) completo

Marcos Ponderados
Frmula Fixa
Esforo Associado
Nvel de Esforo
Cada mtodo dever ser utilizado de acordo com a natureza da atividade.

1- Percentual (%) completo
Pode ser aplicado quando a atividade permite a medio precisa do avano fsico.
Caso de atividades cujo trabalho tangvel e de dimenses fsicas expressas em
unidades paramtricas. Por exemplo: rea, comprimento, altura, volume, etc. Aps a
medio fsica, uma regra de trs permite encontrar o percentual completado do
todo. Por exemplo: foram completados 3 metros da pintura de uma parede de 10
metros, portanto, o avano fsico foi de 30%. Em seguida, necessrio calcular o
Valor Agregado, que ser o Valor dos 30% completos da pintura da parede.
2- Marcos Ponderados
Este mtodo aplicado quando no possvel ter parmetros de dimenses precisas
que permitam medir o percentual completo. Consiste em determinar a proporo das
partes do todo (100%) que possam ser identificados, marcados, por entregas do
projeto. A ponderao, atribuio de pesos que segmentem o todo de forma
proporcional, carrega certa dose de subjetividade, pois dependo do julgamento em
funo de um parmetro indireto. No caso da construo de uma residncia, o
parmetro tempo pode servir de base para a ponderao e determinar a seguinte
distribuio por fases: fundaes (10%), estrutura (30%) alvenaria (20%),
instalaes (10%) e acabamento (30%).
3- Frmula Fixa
Em casos de dificuldade de medio precisa ou de atividades de curta durao, cuja
diferena entre medidas no gere conseqncias significativas para a avaliao do
desempenho do projeto, pode-se utilizar valores padronizados para estabelecer os
percentuais de avano fsico tais como: 20/80 25/75 - 50/50 0/100. O primeiro
nmero do padro atribudo quando a atividade comea a ser executada, portanto,
no caso do 50/50, quando houvesse a informao de que a atividade foi iniciada
seria considerada como estando 50% completa. Ao seu trmino ela receberia os
50% restantes.
4- Esforo Associado
Empregado quando uma atividade tem relao direta ou com carter de suporte em
relao a outra que denominada base de medida. Caso de atividades de garantia
da qualidade, de inspeo ou fiscalizao. Neste caso o valor agregado da atividade
associada ser igual ao da atividade base.
93
5- Nvel de Esforo
Utilizado para medir o avano de trabalhos indiretos realizados no projeto,
tipicamente o trabalho de gerenciamento do projeto ou de suporte ao projeto que
no pode ser isolado como contribuinte de uma parte especfica da gerao do
produto do projeto. Por conveno adota-se que o Valor Agregado (EV) destas
atividades ser sempre igual ao Valor Planejado (PV) para elas.
Relatrio de Status
Os principais parmetros do desempenho do projeto devem ser periodicamente
informados aos principais stakeholders do projeto. A boa prtica recomenda que
relatrios de status sejam sintticos e objetivos.
RELATRIO DE STATUS DO PROJETO
Projeto
Data
Nmero
Principais Entregas realizadas
Indicadores
Variao de Custo (CV)
Variao de Prazo (SV)
Performance de Custo (CPI)
Performance de Prazo (SPI)
Estimativa de Custo no Trmino (EAC)c
Estimativa de Prazo no Trmino (EAC)t
% completo do projeto REALIZADO

% completo do projeto PLANEJADO
Valor Planejado (PV)
Custo Real (AC)
Valor Agregado (EV)
Oramento do Projeto (BAC)
Data de Trmino prevista
Anterior
Atual
Sinalizador
Aes Corretivas
O relatrio de status deve ser tratado sob duas perspectivas: a situao atual do
projeto (status), e as recomendaes de providncias a serem tomadas para que o
projeto volte possibilidade de cumprir seus objetivos de escopo, prazo, custo,
qualidade, etc.
A situao atual uma constatao do desempenho do projeto at o ponto do ciclo
de controle, ou data, em que foram realizadas as medies de avano fsico e do
custo real do projeto.
Dessa forma, a equipe do projeto pode traduzir o status utilizando os indicadores de
desempenho do EVM (Gerenciamento do Valor Agregado).
Um recurso prtico para relatrios de status utilizar sinalizadores coloridos do tipo
painel de controle que seguem a conveno de: vermelho, amarelo e verde de
acordo com a condio do indicador.
94
Para os indicadores cujo sinalizador esteja em amarelo ou vermelho medidas de

gerenciamento, ou MEDIDAS CORRETIVAS devem propostas e submetidas a
aprovao.
MEDIDAS CORRETIVAS
O mtodo do Valor Agregado permitir uma avaliao da sade do projeto com certo
grau de preciso, porm, uma vez que foram identificados desvios no plano de
gerenciamento do projeto ser necessrio tomar medidas corretivas que faam o
projeto voltar condio de alcanar seus objetivos.
As perguntas que surgem quando so constatados os desvios so:
Gastar mais para melhorar prazo?
Gastar menos para melhorar custo?
Cortar escopo?
Propor mudanas?
A resposta s poder ser dada pelo FATOR CRTICO DE SUCESSO DO PROJETO.

O DRIVER do projeto que estabelece as prioridades para o projeto dentre suas
variveis.
Qual a prioridade, basicamente, entre ESCOPO, TEMPO e CUSTO? Esta prioridade,
como vimos deve ser identificada no incio do projeto, pois ela determinar,
direcionar, todas as aes do projeto.
Entretanto, se ela ainda no estiver clara ser explicitada neste momento, pois os
demandantes do projeto (patrocinador sponsor e cliente) rejeitaro quaisquer
solues para os desvios do projeto que contrariem a prioridade real do projeto.
No caso de um projeto cujo fator crtico de sucesso seja custo, e o projeto estiver
com desvios de prazo de custo, por exemplo, uma proposta do gerente do projeto
para reduo do atraso que implique em aumento de custos ser, certamente,
rejeitada pela alta direo do projeto.
Portanto, o gerenciamento do projeto, considerando todo o processo desde sua
iniciao, planejamento, execuo, monitoramento e controle at o encerramento,
deve ser direcionado pelos reais interesses do projeto, por suas reais prioridades,
que permitam o melhor aproveitamento dos recursos limitados com os quais seu
condutor (gerente do projeto) poder contar para produzir a entrega final dentro dos
parmetros esperados por seus demandantes.
95
Processo de Ao Corretiva
A BOA PRTICA recomenda que ao corretiva, ao contrrio da prtica geral, seja,
submetida aprovao da autoridade responsvel. Seja o sponsor do projeto, uma
diretoria, ou um comit constitudo especialmente. importante lembrar que os
critrios, limites e aladas j devem ter sido estabelecidos no plano de
gerenciamento do escopo e impedem que as decises do projeto fiquem
engessadas.

A natureza de elaborao progressiva e de uma projeo a um ponto futuro do
projeto faz com que esteja sujeito a mudanas.
Mudanas em projetos podem originar-se por muitas razes: podem ser fruto de
uma maior compreenso do produto a ser entregue em razo do avano de partes
do projeto que permitiram uma nova viso; por uma mudana no ambiente no qual
o projeto est inserido que fez com que a estratgia que deu origem ao projeto
tenha mudado; por riscos que materializaram-se e tornaram o plano de
gerenciamento do projeto invivel, enfim, antes de impedir mudanas, o gestor do
projeto deve gerenci-las, ou seja, tomar as providncias necessrias para que elas
sejam incorporadas devidamente ao projeto.
Assim sendo, necessrio seguir procedimentos rigorosos de formalizao das
solicitaes, de avaliao dos impactos que a mudana gerar nos outros
componentes do projeto e em seu sucesso, informar os stakeholders, e atualizar
toda a documentao do projeto atingida.
96
Processo de Mudana
O processo de mudana inicia-se na solicitao da mudana, portanto altamente

recomendvel que as solicitaes sejam formais, isto , feitas atravs de documentos
reconhecidos pela organizao executora. Idealmente deve-se utilizar formulrios
padronizados.
97
FORMULRIO DE SOLICITAO DE MUDANA NO PROJETO

Projeto
Data da Solicitao
Nmero
Solicitante
Descrio da Mudana
Justificava para a Mudana
Impactos no projeto e medidas para mitigao dos impactos

1. Escopo
1.1.
2. Tempo
2.1.
3. Custo
3.1.
4. Qualidade
4.1.
5. Riscos do projeto
5.1.
Aprovador
Data da Aprovao
Um risco associado a mudanas em projetos o tratamento inadequado, em geral,

gerado pela confuso entre mudana e correo de desvio, medida corretiva, que
leva a distores do plano de gerenciamento do projeto.
A medida de gesto, ao corretiva ou correo de desvio tem origem diferente da
mudana. Vem de uma constatao feita a partir do monitoramento do projeto,
enquanto que a mudana uma nova demanda posta ao projeto, novo input.
Solicitao - Definio do procedimento formal para a solicitao de

mudanas no escopo
Avaliao - Definio do processo para avaliao dos impactos causados

pelas mudanas solicitadas, a fim de propiciar a informao necessria para a
tomada de deciso quanto a autorizao da mudana
Autorizao - Definio do processo e dos envolvidos na autorizao das

mudanas solicitadas (Comit de Controle de Mudanas)
Documentao - Definio do processo de atualizao da documentao do

projeto, em decorrncia da mudana solicitada
Comunicao - Comunicao aos envolvidos ou impactados pela mudana
Distribuio das Informaes do projeto

O plano de comunicaes estabeleceu o que deve ser comunicado, pra quais
stakeholders, em que momentos, e os meios que devem ser utilizados, portanto, o
gestor do projeto, utilizar como guia a matriz de comunicaes.
98
As reunies, um dos meios de comunicao essenciais para um projeto, que so, na

verdade instrumentos poderosos de gesto, devem ser conduzidas pelo gestor do
projeto com muito rigor seguindo tcnicas de coordenao de reunies que
garantam que o tempo e recursos envolvidos sejam aproveitados da melhor forma
possvel, isto , tenham eficcia.
Considerando-se que o tempo em projetos recurso , por definio, limitado e de
influncia direta nas outras variveis do projeto, obrigao primria do gestor do
projeto, administr-lo com o mximo de cuidado. recomendvel para a estabilidade
na funo que o gestor do projeto seja, e transmita aparncia de ser, organizado.
Uma reunio que consuma mais tempo que o necessrio e que no cumpra seus
objetivos, passa mensagens que atingem a reputao de profissional capaz de
elaborar planos e realizar estes planos, que expectativa bsica de competncia de
um gestor de projetos.
Assim sendo, essencial que sejam tomadas providncias que garantam a eficincia
e eficcia das reunies de projeto.
Coordenao de Reunies
Objetivo da Reunio. Em um projeto h diversos tipos de reunies necessrias ao
seu gerenciamento: reunio de Kickoff (partida da execuo), de avaliao de
membros da equipe, de solues tcnicas, de lies aprendidas, de identificao de
riscos, de brainstorming para definio do escopo, de progresso, para citar as
principais. Portanto, fundamental para a eficcia e especificao dos principais
elementos da reunio, tais como, a pauta e convocados, que seja bem definido o
objetivo da reunio.
Coordenador da Reunio. Elemento essencial para a eficcia da reunio deve ter
conscincia de que o responsvel pelo sucesso ou fracasso da reunio. No caso do
projeto, na maior parte das reunies esta coordenao ser exercida pelo gestor do
projeto que ter, neste papel, as seguintes atribuies:

Preparar pauta e distribuir previamente aos participantes

Convocar participantes (necessrios e suficientes)
Abrir a reunio (ltima reunio - fazer apresentaes)
Conduzir a pauta (prioridade de assuntos)
Promover processos de tomada de decises (votao)
Administrar conflitos e disputas de poder
Fechar a reunio (fazer resumo dos assuntos abordados)
Durao. Este talvez seja o fator mais crtico para o sucesso de uma reunio. Na
verdade o fato dela, a durao, no ser definida com clareza e, principalmente,
cumprida. A indefinio dos horrios de incio trmino e o no cumprimento destes
limites, faz com que os participantes cheguem atrasados, consome mais tempo do
99
que o necessrio e joga o instrumento gerencial reunio no descrdito. Em analogia

ao projeto como um todo, a durao est para a reunio, assim como o prazo limite
est para o projeto.
Pauta. A pauta de uma reunio o contedo, ou conjunto de assuntos que sero
tratados na reunio. Se mantivermos a analogia com o projeto, a pauta equivaleria
ao escopo do projeto. Neste caso, se o cumprimento da durao for considerado
fator crtico de sucesso, a pauta dever subordinar-se durao. Isto , a pauta
dever ter o tamanho que caiba na durao estabelecida para a reunio. Os
estudiosos do assunto afirmam que reunies tendem a ter pautas extensas na
medida em que os problemas ou questes a serem tratadas se acumulam. Sendo
assim, um projeto que estabelea e siga um ciclo de controle adequado tender a ter
menos necessidade de pauta por reunio. Outra prtica que conduz a reunies mais
rpidas a adoo de um roteiro de pauta padronizado em formato de lista de
verificao (checklist).
Agenda. Ainda na analogia, deve-se distribuir o tempo disponvel determinando
perodos de tempo proporcionais e especficos a cada assunto da pauta. Isto
determinar milestones, ou marcos nos quais o coordenador da reunio dever
promover processos de tomada de deciso, por votao, se for o caso, e passar ao
assunto seguinte. Ou seja, se a pauta o escopo, a agenda passa a ser o
cronograma da reunio. Que, tambm, deve ser cumprido. A dificuldade de
estabelecer limites de tempo por assunto a mesma que se tem em dimensionar
duraes para realizaes do escopo. Analogamente, deve-se aprender (lies
aprendidas), melhorar esta distribuio de proporo com o planejamento e a prtica
avaliada e estudada.
Periodicidade. muito provvel que haja necessidade de uma reunio
extraordinria, ou emergencial para solucionar problemas, riscos que se
materializam, em um projeto, mas por princpio, as reunies de um projeto devem
ser planejadas. Isto , ao trmino da elaborao do plano de gerenciamento do
projeto, o gestor do projeto j deve ter o calendrio das reunies programadas.
Sendo assim, este calendrio deve ser divulgado com antecedncia a fim de que os
participantes convocados possam programar-se registrando em suas agendas. Se
esta boa prtica for adotada conveniente que haja uma previso de comunicao
com antecedncia de adiamentos e cancelamentos. No esqueamos que a
reputao de planejador competente do gestor do projeto est em jogo.
Local. Informado e preparado previamente, o local da reunio, evita atrasos dos
participantes e at mesmo do incio possvel da reunio. Deve, tambm, ser
adequado em termos de espao e conforto, mas deve ser respeitado o princpio da
economicidade. Isto , locais desproporcionalmente grandes para o nmero de
pessoas e cujas instalaes consumas muita energia, so contra-indicados.
Responsvel pela Ata. Esta providncia permitir que os participantes que tenham
contribuies ativas na reunio possam concentra-se nos assuntos e no se distraiam
tendo que registrar o que tratado na reunio. Em seguida, recomendvel que a
assistente administrativa (contra-indicado que seja um tcnico de valor-hora, em
geral maior) responsvel pela redao da ata, envie aos stakeholders determinados
na matriz de comunicaes para receb-la.
100
Reunies de Progresso
O monitoramento do projeto prov informaes acerca do desempenho do projeto e
seus desvios em relao ao plano. As providncias de controle podem ser tomadas
isoladamente, mas avaliaes do progresso, isto , o quanto foi realizado do que foi
planejado, como esto sendo aplicados os recursos do projeto, qual a magnitude dos
desvios, que previses podem ser feitas para o restante do projeto, enfim, o
gerenciamento do projeto em equipe deve ser realizado nas reunies de andamento
do projeto, segundo o Guia PMBOK, ou de progresso.
Devem ser realizadas de acordo com o CICLO DE CONTROLE do projeto. O foco
deve ser avaliar o executado comparando com o planejado. O status ou situao, ou
posio do projeto deve ser insumo para a reunio de progresso, isto , deve ser
levado pelos participantes em forma de relatrios para anlise. No boa prtica
utilizar a reunio de progresso para levantar o status do projeto. A reunio de
progresso uma reunio para anlise de dados, e tomada de decises.
Devem ser analisados os pontos de ateno, riscos identificados e riscos que
perderam a potencialidade, e elaborar previses de desempenho e de status futuros,
preferencialmente utilizando a tcnica do valor agregado que foi vista.
O processo de Verificao do Escopo e Aceitao Formal

A cada etapa concluda, antes de realizar a entrega, a equipe do projeto deve
realizar uma inspeo, isto , uma comparao entre o que est prestes a ser
entregue ao cliente e os requisitos definidos da qualidade.
Se resultado estiver dentro dos limites de tolerncia estabelecidos, ento a entrega
poder ser efetivada. Se o trabalho no estiver conforme, correes devem ser
realizadas at que os requisitos sejam atendidos, para s ento, ser entregue ao
cliente.
A prtica de inspecionar o trabalho antes de entregar ao cliente segue o princpio de
administrao geral que prega a economicidade de processo, ou seja, quanto mais
distante identificada uma no-conformidade mais custo ela gera.
Dessa forma, se a no-conformidade for identificada ainda no mbito do projeto, sua
correo gerar menos custo do que se for identificada nas mos do cliente.
O cliente, por sua vez, ao receber o trabalho (a entrega), deve verificar a
conformidade com os parmetros da qualidade acordados. Estes parmetros serviro
de Critrios de Aceitao da entrega para o cliente.
Este processo de gerenciamento do projeto, realizado pelo cliente, denominado de
Verificao do Escopo, pois basicamente verifica se o escopo est completo e se foi
realizado dentro dos critrios de aceitao.
Se o trabalho estiver dentro dos critrios de aceitao, isto , conforme, o cliente
deve, ento dar o ACEITE FORMAL no trabalho.
101
Podem ser utilizados outros termos para designar a verificao do escopo: reviso de
produto, auditoria, homologao, etc.
102
Encerramento
do
Projeto
O processo de encerramento de projetos, por diversas razes, no
conduzido com o devido cuidado que sua importncia requer. Alguns membros da
equipe j esto dividindo seu tempo com outro projeto, conflitos podem ter ocorrido
e gerado desgaste emocional, cansao fsico, os gerentes funcionais que cederam
seus subordinados pressionam para os terem de volta, enfim, muitos fatores
conspiram para que o projeto seja abandonado e no encerrado formalmente.
Um processo de encerramento mal realizado, porm, causa danos no s ao projeto
em si, mas organizao executora que perde a oportunidade valiosa de gerar
dados, informaes e conhecimentos para aplicao nos projetos subsequentes,
alm de ficar sujeita a aes judiciais movidas pelo cliente por descumprimento do
contrato, gerando prejuzos financeiros.
O encerramento do projeto consiste basicamente do encerramento administrativo e
do encerramento dos contratos.
Se a administrao dos contratos tiver sido realizada, ao longo do projeto, com a
prtica de acompanhamento atravs de uma planilha com as informaes do
contrato, e as obrigaes tiverem sido cumpridas, os procedimentos de
encerramento dos contratos sero bastante facilitados. Deixar qualquer contrato do
projeto em aberto, gera um risco grave organizao executora do projeto.
O encerramento administrativo confirmar que o trabalho foi realizado de acordo
com os requerimentos e obter a aceitao formal do cliente. A partir da entrega do
produto final do projeto e da verificao do escopo, realizada pelo cliente. Se no
houver correes de no-conformidades, poder ser formalizada a aceitao do
resultado do projeto, permitindo, ento que sejam tomadas as demais providncias
administrativas tais como:

Preparar o relatrio de performance final do projeto

Indexar e arquivar documentos
Realizar a reunio de balano final de Lies Aprendidas (Lessons Learned)
Desmobilizar os recursos do projeto
Lies Aprendidas
Os estudiosos afirmam que o desenvolvimento de competncias organizacionais no
gerenciamento de projetos ocorre por processo histrico. Significa que a organizao
deve aprender com os projetos que realiza.
Este aprendizado transformado em conhecimento em gerenciamento de projetos
considerado pelo Guia PMBOK como sendo ativos organizacionais. Bens de valor.
Recursos que podem gerar riqueza e, conseqentemente crescimento para a
organizao.
103
Dois elementos so fundamentais para que este processo de aprendizado acontea:

Registro
Anlise
O registro a documentao da histria do projeto. A descrio com o maior nvel

de detalhes das ocorrncias do projeto. Como problemas e dificuldades foram
superados, como desvios foram corrigidos, como solues tcnicas foram
encontradas, enfim,
Visto que um processo de aprendizado coletivo, sees de lies aprendidas so
mais produtivas se o foco no aspecto positivo, isto , foco nas solues e no nos
erros. O Dr. Joseph Juran j recomendava que problemas possuem causas e no
culpados. Esta uma boa postura a ser assumida pelo gestor do projeto se o
objetivo for criar um clima favorvel ao aprendizado. A busca por culpados pode
transformar o processo de lies aprendidas em uma troca de acusaes e defesas
que no traro benefcio.
recomendvel que sejam conduzidos processos, ou sees de lies aprendidas ao
longo de todo o processo do projeto, porque alguns membros da equipe deixaro o
projeto quando forem concludas suas atividades, porque quanto mais prximo do
fato gerador, mais preciso o relato das ocorrncias, e, por fim, o processo sendo
realizado desde o comeo do projeto permite que os ganhos do aprendizado sejam
aproveitados para o prprio projeto.
104
BIBLIOGRAFIA
AMBRIZ, Rodolfo. Dynamic Scheduling with Microsoft Office Project 2007. Florida, J.
Ross Publishing, 2007.
CHAPMAN, Chris. Project Risk Management. New York, John Wiley, 1997.
DINSMORE, Paul C at al. The AMA Handbook of Project Management. New York,
Amacom, 2009.
DINSMORE, Paul C at al. Projetos Brasileiros Casos Reais de Gerenciamento. Rio de
Janeiro, Brasport, 2007.
GOLDRATT, Eliyahu M.. Corrente Crtica. So Paulo, Nobel, 1998.
HAMILTON, Albert. Management by Projects - Achieving Success in a Changing
World. London, Thomas Telford, 2003.
HELDMAN, Kim. Gerncia de Projetos Fundamentos. Rio de Janeiro, Campus, 2005.
KERZNER, Harold. Gesto de Projetos As Melhores Prticas. So Paulo, Bookman,
2005.
KERZNER, Harold. Project Management - A Systems Approach to Planning,
Scheduling and Controlling. New York, John Wiley & Sons, 2008.
MEREDITH, Jack R.. Project Management: A Managerial Approach. New York, John
Wiley, 2002.
PROJECT MANAGEMENT INSTITUTE - PMI. Um Guia do Conjunto de Conhecimentos
em Gerenciamento de Projetos (Guia PMBOK), 4 Edio. Pennsylvania, PMI, 2008.
PROJECT MANAGEMENT INSTITUTE PMI. Practice Standard for Project Risk
Management. Pennsylvania, PMI, 2009.
PROJECT MANAGEMENT INSTITUTE - PMI. The Standard for Program Management.
Pennsylvania, PMI, 2008.
PROJECT MANAGEMENT INSTITUTE - PMI. The Standard for Portfolio Management.
Pennsylvania, PMI, 2008.
PINTO, Amrico. Benchmarking em Gerenciamento de Projetos Brasil: Relatrio
2004. Rio de Janeiro, Editora SENAI, 2005.
SHTUB, Avraham. Project Management - Engineering,
Implementation. New Jersey, Prentice-Hall, 1994.
Technology,
Links:
Softwares sobre gerenciamento de projetos:
http://en.wikipedia.org/wiki/List_of_project_management_software
105
and

Apostila Compass - Fundamentos de Gerenciamento de Projetos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Compass - Fundamentos de Gerenciamento de Projetos

Enviado por

Direitos autorais:

Formatos disponíveis

FUNDAMENTOS DE

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

O papel dos projetos neste contexto

Copyright Compass International Knowledge Center

Realizao de objetivos estratgicos atravs de projetos

Portanto, pode-se afirmar que o alcance dos objetivos estratgicos de uma

Quantos projetos terminam fora do prazo? Quanto custa o atraso?

Pode-se concluir, ento, que a preocupao com o gerenciamento de projetos de

Project Management Institute - PMI

Guia PMBOK1 Project Management Body Of Knowledge

PMBOK marca registrada de Project Management Institute.

Copyright Compass International Knowledge Center

de profissionais do mundo inteiro que as encaminham a comits responsveis por

Certificao PMP2 Project Management Professional

PgMP (Program Management Professional) demonstra conhecimento e

PMI-RMP (Risk Management Professional) demonstra conhecimento e

PMI-SP (Schedulling Professional) demonstra conhecimento e experincia

CAPM (Certified Associate of Project Management) demonstra

Copyright Compass International Knowledge Center

produto, servio ou resultado exclusivo. Envolve todo o processo desde a

Produtos, Servios ou Resultados exclusivos

A rvore de deciso, ao lado,

Probabilstico (No Determinstico) Tem Risco (incerteza)

Copyright Compass International Knowledge Center

esperado, ou planejado. Esta caracterstica torna o papel do gerenciamento

Elaborao Progressiva (em Etapas Fases)

Copyright Compass International Knowledge Center

quantificao e diferente do conceito de escassez, pois recursos escassos

Precisa de Administrao Especfica

Outra maneira de definir o conceito de projetos atravs da comparao com as

Decises Irreversveis x Decises Reversveis

Variveis Exgenas x Variveis Endgenas

Fluxo de Caixa Negativo x Fluxo de Caixa Positivo

Priorizar escopo, tempo e custo significa que h uma dificuldade intrnseca de

Copyright Compass International Knowledge Center

Os requisitos, portanto, no so simplesmente passados pelo demandante ao

Dependem do background cultural e educacional do cliente, das suas experincias

Quando um projeto tem sucesso?

Perspectivas de sucesso de um projeto

Na perspectiva do processo de projeto so observados os aspectos de eficincia do

Projeto planejado e gerenciado x projeto tocado

sem planejamento a probabilidade de re-trabalho e desperdcio de recursos maior

Projeto planejado e gerenciado X Projeto tocado

Entrega do produto do projeto

Copyright Compass International Knowledge Center

Perfil e competncias do Gerente do Projeto

Processos de Gerenciamento de Projetos

Cada grupo de processos contm um conjunto de processos capazes de gerar os

Copyright Compass International Knowledge Center

Grupos de Processos de Gerenciamento de Projetos - Fonte: Guia PMBOK, 2008

Os grupos de processos no so fases do projeto. Processos so genricos, ou

Ciclo de Vida e Processos de Gerenciamento de Projetos

Os processos de gerenciamento tm como finalidade gerenciar (planejando,

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

Grupos de Processos de Gerenciamento de Projetos (Guia PMBOK, 2008)

Copyright Compass International Knowledge Center

DESENVOLVER O TERMO DE ABERTURA DO PROJETO

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

negociaes com stakheolders e para o patrocinador defend-lo poltica e