ndice

1 Conceitos de Gerenciamento de Projetos ......................................... 3

2 Iniciao do Projeto ........................................................................... 18

3 Planejamento do Projeto ................................................................... 23

4 Execuo, Monitoramento e Controle do Projeto .......................... 62

5 Encerramento do Projeto .................................................................. 71

2
 1 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. Consequncia 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 ideias em negcios.
3
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 atravs 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 ideia 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.
4
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 mais de 200.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.

PMBOK Guide1 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 de profissionais do mundo inteiro
que as encaminham a comits responsveis por consolid-las em um documento estruturado.

1
PMBOK marca registrada de Project Management Institute.
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,
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
procuram 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.
5
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.

1.1 O QUE UM PROJETO?

Segundo o Guia PMBOK, projeto 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.

2
PMP, PgMP, PMI-RMP, PMI-SP e CAPM so marcas registradas de Project Management Institute.
 PLANO

A B

Obj

t
D0 Janela de TEMPO DDeadline

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.

Escolhas de Projeto (TRADE-OFF)

P 6
H
Q
D
R
I
S
T
B J
E U
V
K

A X
Y
L
F W
C Z
M

A1

N B1

G C1

O D1

E1

Probabilstico (No Determinstico) Tem Risco (incerteza)

No senso comum, a palavra projeto carrega a ideia 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.
 Conduzido por pessoas
Significa que projetos so intensivos em relacionamentos interpessoais. Que 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 7
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.

Fonte: Guia PMBOK, 2008

 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
No processo de operao os recursos so renovados para mant-los em funcionamento
permanente. No projeto os recursos financeiros e humanos tm limites definidos pelo
tempo de sua durao.

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
8
maioria das vezes, no h tempo suficiente para reverter suas consequncias.

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.

Processo Histrico x Processo Estabilizado e Gerido Estatisticamente

A natureza nica dos projetos faz com que o processo de melhoria contnua s seja
possvel utilizando-se referncias histricas, enquanto que a operao consegue colher
amostras de desempenho com semelhanas suficientes para permitirem comparaes
estatsticas confiveis.

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
consequentemente 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).
1.2 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:

Identificao de necessidades
Estabelecimento de objetivos claros e alcanveis
Balanceamento de demandas concorrentes de
ESCOPO, TEMPO e CUSTOS (Tripla Restrio - Triple Constraint)

O bom termo destas trs difceis misses requer, antes de mais nada, a identificao do vetor
prioritrio do projeto, ou seja, descobrir dentre as intenes dos principais interessados no
projeto (cliente primrio e patrocinador, que sero melhor definidos posteriormente) qual o
fator crtico de sucesso do projeto.

O Guia PMBOK, ao relacionar que necessrio o balanceamento de demandas concorrentes,

quer dizer que escopo, tempo, custo competem entre si. 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. 9

Cada projeto tem uma relao de prioridades diferente destas variveis. Em um determinado
projeto o vetor prioritrio, ou fator crtico de sucesso, 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.

O mesmo tipo de projeto, a construo de uma casa, por exemplo, pode ter prioridades de
projeto, objetivo prioritrio, vetor prioritrio, foco de projeto, foco estratgico do projeto,
varivel de menor flexibilidade, alvo prioritrio diferente.

Primeira 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.

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 10
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.
Difcil e trabalhosa, a identificao do vetor prioritrio, entretanto, pode ser fundamental para o
sucesso do projeto. Tem relao direta com a eficcia do projeto. Um projeto conduzido sem
priorizar o fator crtico, pode ser executado com eficincia, mas corre srio risco de no ser
eficaz.

A premissa do gerenciamento estruturado de projetos pode ser apresentada como:

11
Quando um projeto tem sucesso?

Assim como difcil identificar o principal vetor de sucesso do projeto, tambm difcil
classificar um projeto como tendo sido um sucesso ou um fracasso.

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.

Por que projetos fracassam?

Comunicao mal conduzida

Conflitos mal resolvidos
Objetivos e Metas mal estabelecidos ou no so compreendidos pela equipe
Projeto baseado em informaes insuficientes ou inadequadas
No foi dedicado tempo suficiente para o planejamento
O produto do projeto no estava bem definido
Excesso de re-trabalho
12
As expectativas no estavam alinhadas com a realidade do projeto
No foram considerados eventos (riscos) que impactaram o projeto
As mudanas no foram controladas
No foram consideradas as questes polticas e culturais existentes

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 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 da comunidade de profissionais de
gerenciamento de projetos que advogam boas prticas preconizadas pelo PMI de que o
tempo dedicado ao planejamento seja inversamente proporcional ao acrscimo de tempo de
execuo por desperdcio ou re-trabalho.
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.
13
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

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 a 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 define cinco grupos de processos:

Iniciao
14
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.
Os grupos de processos no so fases do projeto. 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 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 de
fim de fase. 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 do Projeto, ou Plano de Gerenciamento do Projeto que ser a base de
referncia (baseline) para o processo de execuo das atividades do projeto. Porm, a relao
entre o ciclo de vida de cada projeto e os processos de gerenciamento aplicados a ele, varia de
acordo com as caractersticas especficas de cada projeto, ou tipo de projeto.
15
Nos projetos de construo civil, por exemplo, a diviso das fases e a intensidade dos processos
de gerenciamento tero uma relao diferente da estruturao dos projetos de
desenvolvimento de software. O ciclo de vida do projeto especfico de cada ramo de
atividade. Os processos de gerenciamento tm como finalidade gerenciar (planejando,
monitorando e controlando) como sero realizadas as atividades necessrias concretizao do
projeto.

Ciclo de Vida de projetos de Construo Civil e Processos de Gerenciamento do Projeto

Ciclo de Vida de projetos de Desenvolvimento de Software

A denominao de uma fase do ciclo de vida como projeto no significa, necessariamente,

que a atividade faa parte do grupo de processo do planejamento. No caso da construo civil,
por exemplo, a elaborao do projeto de arquitetura a execuo de uma atividade prevista no
plano. O plano de projeto, desenvolvido no processo de planejamento do projeto, deve prever
que sero executadas uma srie de atividades, entre elas, o projeto de arquitetura. Da mesma
forma, o projeto de arquitetura de um sistema uma atividade do processo de execuo do 16
projeto de desenvolvimento de software que foi definida como necessria, no plano do projeto,
elaborado no processo de planejamento do projeto.
 Grupos de Processos de Gerenciamento de Projetos
reas de
Monitoramento
Conhecimento Iniciao Planejamento Execuo Encerramento
e Controle
Integrao Desenvolver o Desenvolver o Plano Orientar e Monitorar e Encerrar o
Termo de Abertura de Gerenciamento do Gerenciar a Execuo Controlar o Projeto
do Projeto Projeto do Projeto Trabalho do Projeto
Desenvolver a Controle
Declarao Integrado de
Preliminar do Escopo Mudanas
Escopo Planejamento do Verificao do
Escopo Escopo
Definio do Escopo Controle do
Criar EAP Escopo
Tempo Definio das Controle do
Atividades Cronograma
Sequenciam/ das
Atividades
Estimativa de
Recursos
Estimativa de Durao
das Atividades
Desenvolvim/
Do Cronograma
Custos Estimativa de Custos Controle de
Oramentao Custos
Qualidade Planejamento da Realizar a Garantia Realizar o
Qualidade da Qualidade Controle da
Qualidade
Recursos Planejamento dos Contratar ou Gerenciar a
Humanos Recursos Humanos Mobilizar a Equipe do Equipe do Projeto
Projeto
Desenvolver a
Equipe do Projeto 17
Comunicaes Planejamento das Distribuio das Relatrio de
Comunicaes Informaes Desempenho
Gerenciar as
Partes Interessadas
Riscos Planejamento do Monitoramento e
Gerenciamento dos Controle dos Riscos
Riscos
Anlise Qualitativa
dos Riscos
Anlise Quantitativa
dos Riscos
Planejamento de
Resposta aos Riscos
Aquisies Planejar Compras e Solicitar respostas Administrao Encerramento
Aquisies de fornecedores dos Contratos do Contrato
Planejar Contrataes Selecionar
Fornecedores
 2 Iniciao do Projeto

Uma vez tomada a deciso de realizar o projeto, necessrio constitu-lo

formalmente. Segundo o Guia PMBOK, o grupo de processos de iniciao define e autoriza o
projeto ou uma fase projeto. O principal resultado do grupo de processos de iniciao o
Termo de Abertura do Projeto (Project charter).

O Termo de Abertura do Projeto tem como misso principal autorizar formalmente a realizao
do projeto. Ele 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.

Termo de Abertura do 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 18
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).

Itens componentes de um Termo de Abertura de 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.

Cliente do Projeto

Indivduo que d o aceite formal no resultado (produto) do projeto. Pode no ser 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 e
isso gere impasses na entrega do produto do projeto e isso 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
19
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 negociaes com
stakeholders 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.

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 as partes interessadas no projeto a criarem

expectativas diferentes em relao quilo que o projeto efetivamente se prope a entregar,
podendo causar conflitos, frustraes e prejuzos. 20
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 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 ideia 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.
21
A ideia 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.

Deve-se definir a expectativa de preciso desta estimativa de custos. Espera-se que a

preciso de uma estimativa seja maior medida que o planejamento do projeto evolui.

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.

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 regulamentos 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.

22
 3 Planejamento do Projeto

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
consequncias de uma execuo sem planejamento.

Por tempo de retrabalho entenda-se todo o tempo dedicado a refazer algo que foi feito
anteriormente em no conformidade com o especificado para o projeto. Sabemos que mesmo
com o planejamento existe retrabalho em projetos, dado que uma atividade probabilstica e 23
carregada de incerteza. O posicionamento a favor do planejamento vem da presuno de que o
retrabalho ser menor se houver planejamento.

Porm, as perguntas no so triviais porque 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,
depois de aceita a premissa da economia de recursos com o planejamento, 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. At este ponto, estaro
definidos: escopo, tempo e custo do projeto. Depois, viro as definies da qualidade, dos
recursos humanos, da comunicao, dos riscos e das aquisies necessrias ao projeto.

Apesar de seguir esta ordem de construo, o processo de planejamento iterativo, pois 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 do projeto.

O processo de planejamento, portanto, um processo iterativo de elaborao progressiva do

plano de gerenciamento do projeto.

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 a cada rea do gerenciamento do projeto.

Planos de Gerenciamento das reas de Conhecimento. O gerenciamento do projeto e a

24
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. Para tal faz-se necessrio definir:

Organograma e Matriz de Responsabilidades do Projeto

Representa a estrutura hierrquica no mbito do projeto. Incluir todo o pessoal da equipe de

trabalho do projeto, tanto das tarefas de gerenciamento quanto de execuo do projeto. Pode
ocorrer de inverter relaes hierrquicas da empresa, pois o foco da estrutura do projeto.

Digrama de recursos

Histograma que permite determinar o momento e a intensidade de alocao de recursos, tanto

de pessoas quanto de equipamentos.

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.

Sistema de Controle de Mudanas

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.

Linhas de Base (Baselines) de performance do projeto

O plano 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, 25
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.

PLANEJAMENTO DO ESCOPO

O processo de planejamento do escopo do projeto comea pela elaborao do plano de

gerenciamento do escopo do projeto no qual ser definida a estratgia de como ser tratado o
escopo do projeto. Determinar como ser o processo de definio, documentao e controle
de mudanas do escopo do projeto.

DEFINIO DO ESCOPO DO PROJETO

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 consequncias de cada escolha e identificar as 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. Todo o esforo dedicado a 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
Termo de Abertura do Projeto

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
26
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 ideias relacionadas ao objeto do projeto sem restries de pertinncia,
numa primeira rodada. Em seguida feita uma avaliao da pertinncia e selecionadas as
ideias 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 semelhanas 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 esquecer itens
importantes, como a ganhar tempo no processo. Por 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.
27
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.

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.

28

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).

A definio do escopo dessa forma permite que a demanda real do projeto, ou seja, a razo de
sua realizao, v sendo elaborada e formulada progressivamente.
Sada do processo de definio do escopo

Declarao de Escopo do Projeto

Este documento documenta o escopo do projeto e pode conter as seguintes definies:

Escopo do Produto

O escopo do produto 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.
Representa todas as aes necessrias para produzir a principal entrega do projeto, 29
para completar o escopo do produto.

Escopo do Produto e Escopo do Projeto

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. Desta maneira, itens desta
lista que devam ser entregues pelo projeto, mas que foram omitidos, no momento da
aprovao da Declarao Preliminar do Escopo tornam-se visveis para uma posterior
incluso como escopo.

Uma vez aprovada a Declarao Preliminar do Escopo o processo de iniciao do projeto

estar concludo. Significa que o projeto existe formalmente e sua finalidade em linhas
gerais est definida. Pode-se passar para o processo de planejamento.

Premissas 30
So fatos assumidos como verdadeiros pelas partes demandantes e os realizadores do
projeto. 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. Podem-se elencar
como premissas em um projeto de desenvolvimento de um sistema corporativo, por
exemplo, que ser dada autorizao de acesso a membros da equipe do projeto aos
sistemas da empresa.

Premissas so alvos primrios de riscos, porque, se alteradas, normalmente, geram

alteraes na estrutura do projeto e, consequentemente, 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
quaisquer obrigaes relacionadas ao objeto do projeto. O regimento interno de um
edifcio pode restringir o trabalho que gere rudo durante o perodo noturno.
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). 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).

31
 1
1 Nvel : Nome do Projeto
Nvel

1.
1. PROJETO
PROJETO

2.1
2.1 Fase
Fase 11 2.2
2.2 Fase
Fase 22 2.3
2.3 Fase
Fase 33

3.1
3.1 Entrega
Entrega 3.2
3.2 Entrega
Entrega 3.3
3.3 Entrega
Entrega 3.4
3.4 Entrega
Entrega 3.5
3.5 Entrega
Entrega 3.6
3.6 Entrega
Entrega

4.1
4.1 PT
PT 4.2
4.2 PT
PT 4.3
4.3 PT
PT 4.4
4.4 PT
PT 4.5
4.5 PT
PT 4.6
4.6 PT
PT 4.7
4.7 PT
PT 4.8
4.8 PT
PT 4.9
4.9 PT
PT 4.10
4.10 PT
PT 4.11
4.11 PT
PT 4.12
4.12 PT
PT

O segundo nvel da EAP geralmente representa o ciclo de vida do projeto, pois determina a
primeira partio do projeto, ou seja, suas macro-fases.

2
2 Nvel : Ciclo de Vida do Projeto
Nvel

1.
1. PROJETO
PROJETO

2.1
2.1 Fase
Fase 11 2.2
2.2 Fase
Fase 22 2.3
2.3 Fase
Fase 33

3.1
3.1 Entrega
Entrega 3.2
3.2 Entrega
Entrega 3.3
3.3 Entrega
Entrega 3.4
3.4 Entrega
Entrega 3.5
3.5 Entrega
Entrega 3.6
3.6 Entrega
Entrega

4.1
4.1 PT
PT 4.2
4.2 PT
PT 4.3
4.3 PT
PT 4.4
4.4 PT
PT 4.5
4.5 PT
PT 4.6
4.6 PT
PT 4.7
4.7 PT
PT 4.8
4.8 PT
PT 4.9
4.9 PT
PT 4.10
4.10 PT
PT 4.11
4.11 PT
PT 4.12
4.12 PT
PT

O projeto , ento, sucessivamente sendo quebrado (breakdown), em nveis de entregas cada 32

vez menores at o menor nvel desejado para detalhamento do escopo do projeto. Este nvel
denominado pacote de trabalho.

3
3 Nvel : Principais entregas do projeto
Nvel

1.
1. PROJETO
PROJETO

2.1
2.1 Fase
Fase 11 2.2
2.2 Fase
Fase 22 2.3
2.3 Fase
Fase 33

3.1
3.1 Entrega
Entrega 3.2
3.2 Entrega
Entrega 3.3
3.3 Entrega
Entrega 3.4
3.4 Entrega
Entrega 3.5
3.5 Entrega
Entrega 3.6
3.6 Entrega
Entrega

4.1
4.1 PT
PT 4.2
4.2 PT
PT 4.3
4.3 PT
PT 4.4
4.4 PT
PT 4.5
4.5 PT
PT 4.6
4.6 PT
PT 4.7
4.7 PT
PT 4.8
4.8 PT
PT 4.9
4.9 PT
PT 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 2.2
2.2 Fase
Fase 22 2.3
2.3 Fase
Fase 33

3.1
3.1 Entrega
Entrega 3.2
3.2 Entrega
Entrega 3.3
3.3 Entrega
Entrega 3.4
3.4 Entrega
Entrega 3.5
3.5 Entrega
Entrega 3.6
3.6 Entrega
Entrega

4.1
4.1 PT
PT 4.2
4.2 PT
PT 4.3
4.3 PT
PT 4.4
4.4 PT
PT 4.5
4.5 PT
PT 4.6
4.6 PT
PT 4.7
4.7 PT
PT 4.8
4.8 PT
PT 4.9
4.9 PT
PT 4.10
4.10 PT
PT 4.11
4.11 PT
PT 4.12
4.12 PT
PT

ltimo N
ltimo vel : Pacotes de Trabalho
Nvel
(menor entrega do projeto)
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.
33
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 (subprojeto) e no haver necessidade de
detalhar o como da entrega terceirizada.

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 Entrega
Entrega B
B Resp.Ent
Resp.Ent.A
.A
Resp.Ent.A Resp.Ent
Resp.Ent.B
.B
Resp.Ent.B

PT
PT 11 PT
PT 22 PT
PT 33 PT
PT 44 R.PT
R.PT 11 R.
R. PT
PT 22 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.

Tratamento de
Riscos Associados
por entregas PROJETO
PROJETO

Identificao de Riscos
Associados por entregas
Fase
Fase 22

Entrega
Entrega Entrega
Entrega

PT
PT 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 50
50

34
25
25 25
25 25
25 25
25

O cronograma do projeto, tambm, ser elaborado com mais preciso e rapidez se tiver a EAP
como guia.

O ltimo nvel da EAP, os pacotes de trabalho, uma vez decompostos, identificaro as

atividades do projeto que so, sob o ponto de vista do processo de decomposio, a menor
clula do projeto. Com as atividades identificadas ser possvel construir o diagrama de rede
com suas relaes de dependncias com o mximo de riqueza possvel.

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.

Portanto, a perguntas muitas vezes formuladas: vale a pena fazer EAP mesmo para projetos
simples? Uma lista de atividades com indentaes indicando as atividades sumarizadoras no
suficiente? As respostas passam pela considerao de trs fatores: benefcios, esforo e
prejuzos ou danos ao projeto. Em relao aos benefcios, de forma geral, a EAP permite melhor
definio do escopo e maior controle do projeto. Quanto ao esforo, sendo o projeto simples, a
EAP, tambm ser simples, portanto gerar menos esforo. O fator: potenciais prejuzos ou
danos causados ao projeto, talvez, seja decisivo para recomendar a elaborao da EAP tanto
para projetos complexos quanto para projetos simples, pois formula a seguinte questo: o
projeto poder ser gerenciado da melhor maneira possvel sem a EAP? O fato de o projeto ser
simples, justifica no gerenci-lo da melhor forma possvel?

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.
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

35

Modelo de Dicionrio da EAP. 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 seqncia do processo de
planejamento

PLANEJAMENTO DO TEMPO

A definio do escopo permite realizar o planejamento de como ser tratado o tempo no

projeto para que as entregas parciais e a total sejam feitas dentro do prazo. Como em todo o
processo de planejamento, comear pela elaborao de um plano que determinar a melhor
estratgia a ser utilizada para a construo do cronograma do projeto com todos os seus
componentes.

A construo do cronograma do projeto requer a definio das atividades e seu

seqenciamento, a determinao da durao e o posicionamento em um calendrio real em
que sejam consideradas as limitaes de perodos de trabalho.

O Plano determinar, portanto, os critrios que orientaro a conduo de cada um destes

processos.

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 consequentemente permite demonstrar as mais
detalhadas relaes de dependncia necessrias elaborao do diagrama de rede do projeto.

Decomposio dos pacotes de trabalho em atividades que formaro o diagrama de rede do projeto

Diagrama de Rede

Todo projeto, por definio tem incio e fim definidos previamente, ou seja, um ponto de
36
partida e outro de chagada, portanto possvel representar graficamente as atividades do
projeto em seqncias determinadas pelas relaes de dependncia entre elas em forma de
uma rede.

No diagrama de rede so determinadas 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. Portanto, todo digrama de rede representando um projeto fechado.

Caminhos do projeto
Atividade A Atividade B
1 INCIO-A-B-D-FIM
2 INCIO-A-B-E-FIM
3 INCIO-A-C-E-FIM
Ativ. B Ativ. D

Incio Ativ. A FIM

Ativ. C Ativ. E
Tipos de dependncias

Dependncias Obrigatrias Seguem uma lgica rgida (hard logic), significa que s podem
ser executadas em uma determinada seqncia. Por exemplo: uma parede s poder ser
pintada se antes tiver sido emboada. Ou seja, mesmo que se deseje impossvel inverter esta
seqncia.

Dependncias Facultativas H conjuntos de atividades, porm, cuja relao no rgida,

isto , podem ser realizadas tanto em srie (seqncia direta) quanto em paralelo
(simultaneamente), nestes casos fica a cargo do gestor do projeto decidir pela melhor
composio de acordo com as melhores prticas do ramo de atividade relacionada ao projeto,
ou de experincias em projetos anteriores.

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 subsequentes que dependam dela.

Recursos necessrios execuo das atividades

A fim de poder calcular as duraes das atividades, antes necessrio determinar que recursos
humanos, materiais e de equipamentos sero utilizados, ou seja, os recursos executores das
atividades.

Alm da determinao dos tipos de recursos e suas quantidades, necessrio identificar as

37
disponibilidade de cada um desses recursos, a fim de que no haja super-alocaes, se o
recurso prprio da organizao ou ser contratado de terceiros, assim como suas capacidades
de desempenho.

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 super-estimao de
desempenho pode gerar falsas expectativas que no momento da execuo sero frustradas.

Uma ferramenta que pode ser utilizada a Estrutura Analtica de Recursos (EAR) ou Resource
Breakdown Structure (RBS). Essa estrutura usada para decompor o projeto por tipo de
recursos. Por exemplo, uma EAR pode representar, agrupados por categoria, todos os
soldadores e equipamentos de solda que esto sendo usados em diferentes reas de uma
plataforma, embora os mesmos estejam distribudos entre diferentes ramos da EAP. A EAR
til no acompanhamento de custos do projeto e pode ser associada ao sistema de contabilidade
da organizao.

Estimativas 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.

Antes de 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. preciso identificar o ponto timo para cada projeto.

Estimativa nica considerado um nico valor que obtido do prprio recurso escalado
para executar a atividade, de um especialista na matria, 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.

Nas estimativas fornecidas pelo executor da atividade h invariavelmente a incluso de uma

margem de segurana para o cumprimento do compromisso. Nenhum executor 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. A boa prtica do gerenciamento
de projetos pressupe cumprimento de estimativas. Executado correspondente ao planejado.

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.

Caminho Crtico 38
O mtodo do caminho crtico foi mais uma das contribuies para o gerenciamento de projetos
desenvolvida na dcada de 50 simultaneamente pelo pessoal da companhia americana Duppont
e a inglesa Remington. Gerando inclusive, questionamento quanto a plgio.

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.

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.

Ativ. B Ativ. D

Incio Ativ. A FIM

CAMINHOS
Ativ. C Ativ. E
Incio-A-B-D-Fim

Incio-A-B-E-Fim

Incio-A-C-E-Fim Ativ. B Ativ. D

Incio Ativ. A FIM

Ativ. C Ativ. E

Representao grfica do caminho crtico

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
39
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.
Caminho Crtico

6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Folga
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Incio mais CEDO Trmino mais CEDO

Incio mais TARDE Trmino mais TARDE
O grfico de rede tem como misso demonstrar as relaes de dependncias entre as
atividades formando uma seqncia lgica formando os caminhos do projeto.

Representao grfica da rede com a Atividade no N (Activiti-on-node AON)

Para o clculo do caminho crtico necessrio analisar as atividades 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
ATIV. Ant. Durao
Atividade B pode comear aps a atividade A ser
completada e tem uma estimativa de durao de 3 A - 3
semanas
B A 3
Atividade C pode comear aps a atividade A ser
completada e tem uma estimativa de durao de seis
C A 6
semanas
Atividade D pode comear aps a atividade B ser D B 8
completada e tem uma estimativa de durao de oito 40
semanas E C, D 4

Atividade E pode comear aps a atividade C e D serem

completadas e tem uma estimativa de durao de
quatro semanas
B 3 D 8

A 3 E 4
INCIO FIM

C 6

Em seguida, calculam-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

B 3 D 8

3 6

A 3 E 4
INCIO FIM
0 3
0

C 6
 Incio Mais Cedo de E (Convergncia)
= Trmino Mais Cedo da Atividade de
Maior Trmino Mais cedo das
convergentes
14 > 9
B 3 D 8

3 6 6 14

A 3 E 4
INCIO FIM
0 3 14 18
0 18 18

C 6

3 9 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.

B 3 D 8

3 6 6 14

3 6 6 14

A 3 E 4
INCIO FIM
0 3 14 18
0 0 18 18
0 3 14 18

C 6
41
3 9
Se houvesse folga total 3 menor que 8 8 14
para o Projeto FOLGA em C
Apareceria aqui 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 Dur

Incio-A-B-D-E-Fim 18

Incio-A-C-E-Fim 13

B 3 D 8

3 6 6 14

3 6 6 14

A 3 E 4
INCIO FIM
0 3 14 18
0 0 18 18
0 3 14 18

C 6

3 9

8 14

O diagrama de rede, portanto, permite identificar as relaes de dependncia entre as

atividades e o caminho crtico do projeto.
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 1 2 3 4 5 6 7 8 9 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 42
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 Marcos (Milestones)

A visualizao das entregas, concluses do projeto, marcos crticos ou milestones, pode ser
muito til para o controle do projeto e para a interlocuo com stakeholders.

Grfico de Marcos (ou Milestones)

Assim como o grfico de Gantt, ele construdo em uma escala de tempo e os cuidados quanto
perda de proporo tambm valem.
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, devem-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 D E F G

I
Fim

A C H

B D E

I G
Fim

A C

As atividades do Caminho Crtico cujas relaes de dependncia so arbitradas e foram

43
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 Tracking parcial. Ou seja uma parte da atividades poder ser executada em paralelo ou
simultaneamente.

T T - FT FT

Ganho de tempo com o

Fast Tracking

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 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 Diminishing Returns) que demonstra que a
adio de recursos no gera o ganho de desempenho na mesma proporo e que, a
partir de um certo ponto torna-se improdutiva. Associado ao conceito geral desta lei,
que tem suas razes na economia, esto fatores tais como: a diferena de competncia
e experincia entre os executores, 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
44
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 o 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

Custos Fixos e Variveis Como o nome j indica, um custo fixo aquele que no varia com
a quantidade de itens produzidos, estando presente independentemente do volume da
produo. O custo varivel, por sua vez, e tambm como indicado pelo nome, varia
proporcionalmente ao volume produzido.

Cabe ressaltar que, no ambiente de projetos, a produo representada pelo escopo do

projeto. Custos que no variam proporcionalmente com o aumento ou diminuio do escopo
so, portanto, custos fixos do projeto (por exemplo, o custo do aluguel de uma sala onde
trabalhar a equipe do projeto). Custos que variam proporcionalmente com o aumento ou
diminuio do escopo do projeto so custos variveis do projeto (por exemplo, o custo do
material utilizado na produo das entregas do projeto ou o custo da mo de obra direta para a
produo dessas entregas).

Custos Diretos e Indiretos Os custos diretos so aqueles relacionados diretamente ao

produto final, isto , so custos obtidos pela soma do custo dos insumos bsicos que ficam
diretamente agregados ao produto final do projeto.

Por outro lado, toda organizao tem uma categoria de despesas que consiste de custos
indiretos, tambm chamados de overhead. Esses custos no so atribudos diretamente a
entregas especficas do projeto. So custos incorridos para manter a organizao de maneira
geral, tais como custos com a alta gerncia, com unidades organizacionais que suportam toda a
organizao (contabilidade, tecnologia da informao, recursos humanos), com infra-estrutura e
manuteno de reas fsicas (energia, gua, segurana). Custos indiretos geralmente so
alocados aos projetos atravs de um mtodo arbitrrio. O processo de alocao precisa ser
arbitrrio porque os custos so indiretos; por sua natureza, no h meio direto de atribuir tais
custos aos projetos.

Agregao 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 45
devidas seguindo critrios de rateio.

Custo 1 2 3 4 5 6 7 8 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 Custo 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 36
Atividade 1 40
Atividade 2 100
Atividade 3 70
Atividade 4 10
Atividade 5 30
Atividade 6 70
Atividade 7 30
Atividade 8 60
Atividade 9 40
Atividade 10 60
A correta agregao 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.

A Estrutura hierrquica dos custos do projeto

Aps a correta alocao ser obtido o montante geral oramentrio para o projeto ao qual
devero ser somados os valores relativos s reservas de contingncia do 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 do projeto. Vide modelo abaixo:

8- Oramento total do Projeto 280

280

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

46
4- Projeto 200
200

3- Contas de Controle 100

100 100
100

50 50 50 50
2- Pacotes de Trabalho 50 50 50 50

25 25 25 25 25 25 25 25
1- Atividades 25 25 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 atend-las.

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 47
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.

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. 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.
 Nvel de
Atendimento aos
requerimentos

Gold Plating
No Requsitado
No Esperado
No Contratado

Requisitos do Projeto
(CLIENTE)
Valor Esperado
(contratado)

Custo
Oramento do Projeto da Qualidade

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 48
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

D- D+
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 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. 49
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.

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 pode-se 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 tem 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 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 explcita 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.
50
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, tm-se um organograma e uma matriz de
atividades por pessoas alocadas no projeto, conhecida como Matriz de Responsabilidades.
 Sponsor
Sponsor do
do Projeto
Projeto

Gerente
Gerente do
do Projeto
Projeto Apoio
Apoio Adm
Adm

Resp.
Resp. Fase
Fase A
A Resp.
Resp. Fase
Fase B
B Resp.
Resp. Contratos
Contratos Consultor
Consultor

Membro
Membro 11 Membro
Membro 22 Membro
Membro 33 Resp.
Resp.. Ent.
Resp Ent.. nn
Ent

- 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 51
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
gestor do projeto nomeie um deles como o responsvel.

Matriz de Responsabilidades do Projeto

PLANEJAMENTO DAS COMUNICAES DO PROJETO

O recente estudo de benchmarking realizado pelo PMI aponta que 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.

52

Modelo Bsico de Comunicao (fonte: Guia PMBOK)

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 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.
53
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 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 do
projeto determine um ciclo de controle, o calendrio de reunies de progresso programadas j
deve ser divulgado a quem delas ir participar.

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. Para enviar 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, Na abertura do projeto Cpia em papel entregue

Equipe, Gerentes em mos
Funcionais,...
Plano do Projeto Sponsor e Equipe Na conluso do Cpia em papel entregue
planejamento em mos
Contrato Sponsor e Cliente Na assinatura do contrato Cpia em papel entregue
em mos
WBS Sponsor, Cliente, Na gerao do Cpia em papel entregue
Equipe documento em mos
Cronograma de Gerentes Funcionais No trmino do Memorando interno
Utilizao de recursos planejamento
Riscos Identificados Sponsor, cliente e Na abertura do projeto e Cpia em papel entregue
equipe na concluso do plano em mos
Equipe Na identificao de novos E-mail
riscos
Problemas Equipe Na identificao de E-mail
identificados problemas
(...) (...) (...)

Matriz de Comunicaes

54
GERENCIAMENTO DOS RISCOS DO PROJETO

Risco de um 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 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.
 FONTE

RISCO
RISCO
CAUSA CONSEQUNCIAS
(EVENTO)
(EVENTO)

IMPACTOS
PROBABILIDADE

? OBJETIVOS

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.
55
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, segundo o Guia PMBOK,
so:

Identificao de riscos
Anlise qualitativa de riscos
Anlise quantitativa de riscos
Planejamento de respostas a riscos
Monitoramento e Controle de 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 do projeto.

Identificao de 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.

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.

56

Exemplo de EAR (Estrutura Analtica 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.

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

Para este processo 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.

57

Exemplo de Escala de PROBABILIDADES

Exemplo de Escala de IMPACTOS

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).

Anlise quantitativa de riscos. Anlise numrica do efeito dos riscos identificados nos 58
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

Planejamento de respostas a 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:

Evitar o risco, planejando uma forma de elimin-lo completamente.

 Transferir o risco, normalmente repassando-o para um terceiro.
Mitigar o risco, buscando uma forma de reduzir a probabilidade de sua ocorrncia
ou do seu impacto, caso o mesmo venha a ocorrer.

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.
Compartilhar o risco, atribuindo a sua propriedade a terceiros que possam
capturar melhor a oportunidade do risco acontecer em benefcio do projeto.
Melhorar o risco, modificando o tamanho da oportunidade aumentando a
probabilidade e/ou impacto (valor esperado) do risco positivo.
Formas de responder a riscos POSITIVOS e NEGATIVOS de um projeto:

Aceitar Ativamente, buscando desenvolver planos alternativos (Contingncia)

caso o mesmo venha a ocorrer
Aceitar Passivamente, simplesmente no fazendo nada e torcendo para que o
risco no venha a ocorrer

59

Estratgias de Resposta aos Riscos

Monitoramento e controle de 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.
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 fora da organizao
executora do projeto.

Planejamento das Aquisies

Planejamento de Contrataes (Contratos)
Solicitao de Respostas a Fornecedores
Seleo de Fornecedores
Administrao de Contratos
Encerramento de Contratos

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 60

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 consequentemente 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.

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.

61
 4 Execuo, Monitoramento e
Controle do Projeto

Uma vez elaborado o plano 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 est sendo executado, as exigncias de monitorar, isto , verificar como
est sendo executado o plano tornam-se mais intensas para, quando necessrio, tomar
medidas corretivas, ou seja controlar.

Equipe de execuo do projeto

Adquirir os membros da equipe que o plano de gerenciamento de pessoal determinou como 62

necessria realizao do projeto.

Mobilizar, se for pessoal interno organizao e contratar, se forem externos. Em ambos os

casos o gestor dever apoiar reas de suporte no recrutamento, conduzir entrevistas e avaliar
as competncias dos candidatos.

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.

Distribuio das Informaes

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.

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.

Tcnicas de 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 63

Convocar participantes (necessrios e suficientes)
Abrir a reunio (revisar 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 fazem com que os
participantes cheguem atrasados, consome mais tempo do 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 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 64
desproporcionalmente grandes para o nmero de pessoas e cujas instalaes consuma muita
energia, so contra-indicados.

Responsvel pela Ata. Esta providncia permitir que os participantes que tenham
contribuies ativas na reunio possam concentrar-se nos assuntos e no se distraiam tendo
que registrar o que tratado na reunio. Em seguida, recomendvel que um assistente
administrativo (contra-indicado que seja um tcnico de valor-hora, em geral maior) responsvel
pela redao da ata, envie a mesma aos stakeholders determinados na matriz de comunicaes
para receb-la.

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 ou, segundo o Guia PMBOK, 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 ser vista adiante.

Controle Integrado de Mudanas

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 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.
65
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.
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
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 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

Processo de Ao Corretiva
Avaliar outras
alternativas

Submeter ao
No 66
Controle
Integrado
Avalia Alternativas de Mudanas Sim Implementa
Variao e recomenda a para Aprovao Aprovada?
Correo
AO CORRETIVA Comit de Controle
de Mudanas
CCB
(Change Controle Board)

Atualiza
Planos

Informa
Stakeholders

A BOA PRTICA recomenda que ao corretiva, ao contrrio da prtica geral, seja, tambm
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.
VERIFICAO DO ESCOPO

Obteno da ACEITAO FORMAL, pelas partes interessadas, do escopo do projeto

terminado e das entregas associadas. Inclui a inspeo, feita pelo cliente, das entregas para
garantir que cada uma delas foi terminada de forma satisfatria.
Verificao do escopo difere do Controle de qualidade
Verificao do escopo = aceitao das entregas
Controle de qualidade = atendimento aos requisitos de qualidade especificados
para as entregas
O Controle de qualidade realizado antes da Verificao do escopo. Podem ser utilizados outros
termos para designar a verificao do escopo: reviso de produto, auditoria, homologao, etc.

CONFLITOS EM PROJETOS

Durante a execuo do projeto conflitos costumam surgir entre as partes envolvidas. Aqueles
que participam de projetos precisam estar preparados para lidar com situaes de conflito,
encarando as mesmas como um processo normal, inerente ao projeto.

Ao procurarmos a definio de Conflito em um bom dicionrio, encontraremos: 67

1. Embate dos que lutam. 2. Discusso acompanhada de injrias e ameaas; desavena. 3.

Guerra. 4. Luta, combate. 5. Coliso. (Aurlio)

A partir desta definio genrica, entende-se porque tradicionalmente a viso que se tinha
sobre conflito era a seguinte:

- Conflito atrapalha a Organizao e causado por diferenas de personalidade ou por falha de

liderana.

- Conflito para ser evitado.

- Conflito resolvido separando fisicamente as pessoas ou pela interveno da gerncia

superior.

Em projetos, felizmente, devemos utilizar uma definio especfica:

Conflito em Projetos: Processo que se inicia quando uma parte percebe que a outra est
frustrada ou est para se frustrar a seu respeito. (Thamhain e Wilemon, 1975)

O objetivo do gerenciamento de projetos em relao ao conflito resolv-lo. Assim, quando

todas as partes envolvidas no conflito esto satisfeitas diz-se que o conflito est resolvido.
(Meredith e Mantel, 1995).

Diante desta postura, a viso contempornea a respeito de conflitos pode ser resumida da
seguinte forma:

- Conflito inevitvel e conseqncia das interaes na Organizao.

- Conflito pode ser benfico.

- Conflito resolvido atravs da identificao de suas causas e pela ao das pessoas

envolvidas e suas gerncias imediatas.

Conflitos em projetos podem ter vrias fontes. Uma pesquisa do Standish Group, realizada no
ano de 2004 aponta as seguintes principais fontes de conflito em projetos, em ordem de
freqncia:

1 Cronogramas

2 Prioridades do Projeto

3 Recursos

4 Opinies Tcnicas

5 Procedimentos Administrativos
68
6 Custos

7 - Personalidades

Para buscar a resoluo de conflitos, cinco tcnicas podem ser apresentadas:

Retirada Estratgica (Withdrawing) Evitar ou adiar uma deciso sobre o problema.

Frases tpicas de quem est adotando esta estratgia:

Vamos lidar com esta questo na prxima semana.

J que no podemos decidir sobre a compra dos novos computadores, teremos que esperar
at nossa prxima reunio no ms que vem.

Panos Quentes (Smoothing) Enfatizar o acordo em lugar das diferenas de opinies.

Frases tpicas de quem est adotando esta estratgia:

Vamos nos acalmar e terminar o trabalho.

Marluce e Antnio, vocs dois desejam que este projeto cause o mnimo possvel de problemas
para seus departamentos, certo? Com isto em mente, tenho certeza de que podemos chegar a
um acordo a respeito da compra dos computadores e do que seja melhor para o projeto.

Fora (Forcing) Impor um ponto de vista em detrimento dos demais.

Frases tpicas de quem est adotando esta estratgia:

Faam do meu jeito!

J falamos demais sobre novos computadores. Eu no quero comprar os computadores e

ponto final!

Barganha ou Comprometimento (Compromising) Encontrando solues que tragam

algum grau de satisfao para as partes envolvidas.

Frases tpicas de quem est adotando esta estratgia:

Vamos fazer um pouco do que vocs dois sugeriram.

Marluce, e se ns adquirssemos novos computadores para as tarefas de design e usssemos

os computadores existentes para as funes de monitoramento?

Confronto ou Resoluo de Problema (Confronting ou Problem Solving) Resolvendo

o verdadeiro problema.

Frases tpicas de quem est adotando esta estratgia:

69
Parece que o verdadeiro problema aqui no uma falta de comunicao, mas uma falta de
conhecimento de o que precisa ser feito e quando. Aqui est uma cpia do cronograma do
projeto, de forma que vocs entendam o que precisa ser feito!

Marluce, voc diz que o projeto deve incluir a compra de novos computadores e Antnio, voc
diz que o projeto pode usar o equipamento existente. Eu sugiro que executemos os seguintes
testes no equipamento existente para determinar se o mesmo precisa ser substitudo.

Na Matriz de Resoluo de Conflitos, a seguir, as tcnicas de resoluo de conflitos so

comparadas quanto ao estilo de soluo, ao resultado que trazem, e importncia que as
mesmas do para as metas do projeto e para o relacionamento entre as partes.
As tcnicas tambm podem ser comparadas em relao firmeza que aplicam resoluo do
conflito e ao grau de cooperao que exigem das partes envolvidas. O quadro abaixo ilustra
esta comparao.

70
 5 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 e cansao fsico, os gerentes funcionais que cederam seus subordinados pressionam
para terem-nos 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. 71

O encerramento administrativo confirmar que o trabalho foi realizado de acordo com os

requerimentos e que se obteve 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 que
sejam tomadas as demais providncias administrativas, tais como:
Preparar o relatrio de desempenho final do projeto
Indexar e arquivar documentos
Realizar a reunio de balano final de Lies Aprendidas
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 um ativo organizacional, um bem de valor, um recurso que pode gerar
riqueza e, consequentemente, crescimento para a organizao.
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.
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 se considerasse 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 o processo de lies aprendidas seja conduzido ao longo de todo o
projeto, porque alguns membros da equipe deixaro o projeto quando forem concludas suas
atividades e quanto mais prximo do fato gerador, mais preciso o relato das ocorrncias.
Outro motivo que, ao realizar o processo de lies aprendidas desde o comeo do projeto,
permite-se que os ganhos do aprendizado sejam aproveitados para o prprio projeto.

72
BIBLIOGRAFIA
CHAPMAN, Chris. Project Risk Management. New York, John Wiley, 1997.
DINSMORE, Paul C at al. The AMA Handbook of Project Management. New York, Amacom,
2005.
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, 2005.
MULCAHY, Rita. PMP Exam Prep. RMC Publishing, 2005.
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 (PMBOK Guide), 4 Edio. Pennsylvania, PMI, 2008.
PROJECT MANAGEMENT INSTITUTE - PMI. The Standard for Program Management.
Pennsylvania, PMI, 2006.
PROJECT MANAGEMENT INSTITUTE - PMI. The Standard for Portfolio Management. 73
Pennsylvania, PMI, 2006.
PINTO, Amrico. Benchmarking em Gerenciamento de Projetos Brasil: Relatrio 2004. Rio de
Janeiro, Editora SENAI, 2005.
SHTUB, Avraham. Project Management - Engineering, Technology, and Implementation. New
Jersey, Prentice-Hall, 1994.
VARGAS, Ricardo. Gerenciamento de Projetos. Rio de Janeiro, Brasport, 2005.
VARGAS, Manual Prtico do Plano de Projeto. Rio de Janeiro, Brasport, 2005.
 ESTUDO DE CASO

EXPANSO DAS INSTALAES DA QUALITY

PROJECT
74
Apresentao da empresa e do projeto

Atuando no mercado desde os anos 80, a Quality Project conseguiu se posicionar como uma
empresa gerenciadora de projetos. Seus clientes estratgicos so grandes empresas que
contratam a Quality Project para materializar seus objetivos estratgicos que envolvem a
implementao de grandes empreendimentos, a estruturao de novas unidades de negcios,
a incorporao de aquisies, reestruturaes organizacionais, melhoria de processos, o
desenvolvimento de produtos para a indstria, at mesmo a realizao de grandes eventos.
Os scios fundadores: Sr. Aristteles e Sr. Arquimedes fazem parte, hoje, do conselho de
administrao que apoia o atual presidente, Sr Immanuel Kant nas decises estratgicas.
Localizada na Cidade do Rio de Janeiro, com quase mil colaboradores diretos e mais um
grande contingente de prestadores de servio a Quality vem crescendo a taxas expressivas a
cada ano em funo da qualidade de seus servios que tem como diferencial a excelncia no
gerenciamento dos projetos.
Foi identificada a necessidade de expanso das instalaes da rea de trabalho dos
projetistas. Voc, como gerente de projetos da Quality Project, foi indicado pelo Diretor de
Projetos, Sr. Niels Pascal, como gerente desse projeto.
Estudos preliminares determinaram como melhor opo a construo de um novo prdio para
onde sero transferidas a rea de projetos da Quality Project. Contudo, o Diretor Financeiro da
Quality Project, Blaise Bohr, discorda da abordagem, considerando um esforo grande demais
para o momento. Ele preferia aguardar mais dois anos antes de disparar a iniciativa, mas foi 75
voto vencido na ltima reunio do Comit Diretivo da Quality Project.
Informaes sobre o Projeto

1. Data de autorizao do projeto (assinatura do Termo de Abertura do Projeto):

10 de janeiro de 2012.
2. O projeto prioritrio para a empresa, pois estima-se que podero ocorrer perdas de
produtividade em funo da dificuldade de espao fsico.
3. O perodo de maior atividade comea em setembro e vai at o final de dezembro. Os
meses de janeiro e fevereiro so os de menor intensidade. Portanto, o custo de
oportunidade estimado do dia til de operao parada nos meses de maior pique de R$
1.000,00 por projetista. Nos meses de janeiro e fevereiro o custo dirio de parada por
projetista de R$ 300,00 e nos demais meses de R$ 600,00.
4. A empresa que elaborar o design j est contratada. Ser necessrio fornecer a essa
empresa um documento com os requisitos detalhados de ocupao do novo escritrio
antes que o trabalho no design inicie. Esses requisitos precisam ser coletados,
consolidados e posteriormente validados junto aos gerentes de cada clula de projetistas e
junto ao gerente administrativo.
5. O processo de contratao da empreiteira far parte do projeto.
6. O terreno j foi adquirido e est preparado para a construo.
7. O turno de trabalho padro da empreiteira de 8 h/dia.
8. O Presidente mundial do maior cliente da Quality Project vir ao Brasil em junho de 2012
especialmente para visitar a empresa. parte obrigatria do evento uma visita ao local de
trabalho dos projetistas. 76
9. Alm da necessidade de aquisio de equipamentos e mveis novos, cerca de 20
projetistas atualmente esto trabalhando com equipamentos obsoletos e mveis
inadequados que precisam ser trocados.
10. Ser necessrio realizar o processo de contratao dos equipamentos e mveis.
11. Os trabalhos da empresa sero totalmente interrompidos no primeiro dia de mudana e s
retornaro uma semana aps a concluso da mudana.
12. O oramento do projeto precisar ser aprovado pela diretoria da Quality Project.
13. A Quality Project possui uma poltica de recursos humanos que probe que seus
funcionrios realizem horas extras.
14. A Quality Project anualmente lana uma linha de produtos cujo projeto dura 2 meses
consecutivos, envolve 4 clulas de produo e iniciado em setembro de cada ano. O
lanamento desta linha de produtos no pode ser impactado pela execuo do projeto.
15. O atual imvel ocupado pelos projetistas da Quality Project alugado e dever ser
devolvido at o final de maro de 2013.
16. O sucesso do projeto ser medido pelo atendimento s restries de prazo e pelo menor
custo total final (custo do projeto + custo de oportunidade).
Requisitos do Projeto

1. O prdio dever ser projetado, preferencialmente em um nico andar trreo, a fim de evitar
o uso de elevadores.
2. O projeto de arquitetura (design) dever prever:
2.1. Estacionamento para pelo menos 30 automveis.
2.2. Refeitrio
2.3. Miniauditrio
3. Contingente a ser alocado (as metragens de ocupao j consideram as reas comuns e
de circulao):
3.1. Administrativos 30 profissionais ocupam 2m2 cada, organizados em 3 clulas com
10 profissionais cada. Cada clula possibilita a operao de 4 clulas de projetistas.
3.2. Projetistas 100 profissionais ocupam 4m2 cada, organizados em 10 clulas de
produo com 10 projetistas cada, que atuam de forma independente.
4. Cada clula de projetistas tem um Projetista Gerente e um nico Gerente Administrativo
coordena o trabalho de todas as clulas administrativas. Ambos j esto includos no
contingente total.
5. Sero contratados mais 30 projetistas e 10 administrativos.
6. Projeto (design) completo do novo escritrio (arquitetura e instalaes):
6.1. Escritrio tipo 1 R$ 25.000,00 prazo de entrega: 15 dias teis
6.2. Escritrio tipo 2 R$ 20.000,00 prazo de entrega: 20 dias teis 77

6.3. Escritrio tipo 3 R$ 18.000,00 prazo de entrega: 25 dias teis

7. Opes de sistemas construtivos para a construo do escritrio:
7.1. 1 Sistema construtivo A Custo: R$ 1.000,00/m2 Prazo: 1,5h/m2
7.2. 2 Sistema construtivo B Custo: R$ 800,00/m2 Prazo: 2h/m2
7.3. 3 Sistema construtivo C Custo: R$ 600,00/m2 Prazo: 3h/m2
8. A licena da obra leva no mnimo 30 dias teis para ser liberada. A solicitao da licena
dever ser encaminhada ao rgo aprovador em formulrio prprio e requer que o design
do escritrio esteja pronto. O custo da licena de R$ 10.000,00.
9. Equipamento e mveis
9.1. Conjunto de Equipamento e Mvel por Projetista: R$ 5.000,00
prazo de entrega: 20 dias teis a cada lote de 20 conjuntos.
9.2. Conjunto de Equipamento e Mvel por Administrativo: R$ 3.000,00
prazo de entrega: 40 dias teis a cada lote de 20 conjuntos.
10. Opes de servios de mudanas:
10.1. X - R$ 3.000,00 por dia Produtividade: 5 postos de trabalho por dia
10.2. Y - R$ 1.500,00 por dia Produtividade: 3 postos de trabalho por dia
10.3. Z - R$ 700,00 por dia Produtividade: 2 postos de trabalho por dia
11. Quadro de recursos internos da Quality Project disponveis para trabalho no projeto:

Recurso Quantidade Custo

Gerente de Projeto 1 R$ 70,00/h
Analista de Planejamento e Controle 1 R$ 40,00/h
Arquiteto 1 R$ 50,00/h
Engenheiro 1 R$ 50,00/h
Tcnico de Edificaes 2 R$ 35,00/h
Auxiliar Administrativo 2 R$ 20,00/h

12. Quadro de dias no trabalhados da Quality

Evento 2012 2013

Confraternizao Universal 01/01
Carnaval 21/02 12/02
Paixo de Cristo 06/04 29/03
Tiradentes 21/04
Dia do Trabalho 01/05
Corpus Christi 07/06 30/05
Independncia 07/09
N. S. Aparecida 12/10
Finados 02/11 78
Repblica 15/11
Natal 25/12

13. Organograma da Quality

GERENCIAMENTO DE PROJETOS
APLICADO

CADERNO DE EXERCCIOS 79
PASSO 1
Escolher Lder da Equipe
Analisar informaes do CASE
Desenvolver o Termo de Abertura

Cliente do Projeto
Patrocinador do Projeto (Sponsor)
Descrio do Projeto
Justificativa para realizao do projeto (problema/oportunidade)
RESULTADO principal do projeto (PRODUTO DO PROJETO)
Estimativas de PRAZO e CUSTO

80
PASSO 2
Definir Escopo do Produto
Criar a Estrutura Analtica do Projeto (EAP)
Relacionar Premissas e Restries
Relacionar Excluses Especficas

Criar a Estrutura Analtica do Projeto (EAP)

Para a criao da EAP ser utilizado um software especfico para este fim que possui a
vantagem de ser integrado ao MS-Project. Esta integrao elimina a necessidade de digitao
e garante a integridade de dados.

81
PASSO 3
Desenvolver o Cronograma do Projeto
Definir Atividades
Sequenciar Atividades
Estimar Recursos das Atividades (com custos)
Estimar Duraes das Atividades
Analisar o Cronograma

Neste ponto ser necessrio utilizar um software especfico para elaborao de cronogramas de
projetos, o Microsoft Project.
Como a EAP foi criada em um software integrado ao MS-Project, como por exemplo, o WBS
Chart Pro, possvel transferir diretamente a EAP.

Boto: Go To Project

82
Uma vez que as entregas do projeto tenham sido transferidas para o MS-Project, antes de
comear a elaborar o cronograma, necessrio definir alguns parmetros do projeto e do
sistema.

Configurar o tipo de atividade.

Os atributos de durao, trabalho e recursos de cada atividade so calculados pelo MS-Project
utilizando a equao:

O MS-Project permite a configurao do tipo da atividade entre (Durao, Recursos que o

MS-Project denomina de Unidades e Trabalho) e a escolha do parmetro que ser
determinado (fixo) e os que sero calculados. Isto , se o tipo da atividade for configurado 83
como Durao Fixa, significa que o usurio determinar a Durao da Atividade e o MS-Project
calcular o nmero de Recursos (Unidades) e a carga do Trabalho necessrios.

A fim de refletir a prtica, facilitar o processo de desenvolvimento do cronograma e evitar

retrabalhos recomendvel que o tipo da atividade seja definido como: Durao Fixa.
Dessa forma, uma vez que a Durao da Atividade seja definida, o sistema manter o tempo de
durao mesmo que o nmero de Recursos (Unidades) e a carga de trabalho sejam
modificados.

No menu Arquivo/Opes (File/Options). Selecione a aba: Calendrio (Schedule) e

configure: Durao Fixa (Fixed Duration).
 84

Configurar parmetros de clculos.

No mesmo quadro de dilogo Arquivo/Opes (File/Options), a fim de que o MS-Projeto
calcule os valores agregados at a data date (data de status para o sistema), necessrio
configurar as opes das abas conforme abaixo:

- Schedule:
- Advanced:

Definir o perodo til de trabalho para o projeto.

O calendrio de projeto define, para um determinado projeto, quais datas sero consideradas
como dias no trabalhados. O acesso ao calendrio de projeto feito pelo menu
Projeto/Alterar o Tempo do Trabalho (Project/Change Working Time). Em seguida, a
janela abaixo apresentada:

85

Para criar um CALENDRIO especfico para o projeto

1. No quadro Alterar o Tempo do Trabalho (Change Working Time);
2. Pressione o boto Criar Novo Calendrio (Create New Calendar);
 3. Escolha Criar uma cpia do calendrio Padro;
4. Digite o nome do calendrio;

Em seguida podem ser definidos os dias no trabalhados no calendrio criado.

86

Especifique cada dia no-trabalhado com suas respectivas datas.

Definir parmetros gerais para o projeto.

Em Projeto/Informaes sobre o Projeto (Project/Project Information) definir:
1. Data de Incio (do Projeto)
2. Data atual (definio no case)
3. Calendrio: criado (este ser o calendrio de referncia para todo o projeto).
Desenvolvimento do Cronograma do Projeto

Definir Atividades
Defina as atividades necessrias para realizar as entregas do ltimo nvel da EAP.

87
 Sequenciar Atividades
Elabore o diagrama de rede de atividades do projeto, informando as atividades predecessoras
e/ou sucessoras de cada atividade. As seguintes regras devem ser seguidas:
O sequenciamento deve ser feito no nvel das atividades e no em nveis
superiores.
Na linha 2, logo aps o nome do Projeto, crie uma atividade com durao 0
(zero) chamada Incio do Projeto.
Na ltima linha do projeto, crie uma atividade com durao 0 (zero) chamada
Fim do Projeto.
Cada atividade deve possuir pelo menos uma atividade predecessora e uma
atividade sucessora. Atividades que, considerando a lgica da rede, no
possurem predecessoras, devem utilizar a atividade Incio do Projeto como
predecessora. Atividades que, considerando a lgica da rede, no possurem
sucessoras, devem utilizar a atividade Fim do Projeto como sucessora.
No devem ser utilizadas restries de datas de incio ou de trmino para as
atividades do cronograma.

88

Uma vez sequenciadas as atividades, deve-se estimar os recursos que iro realiz-las. Antes de
estimar as duraes, pois os recursos humanos executores das atividades devero participar do
processo de estimativa.
 Estimar Recursos das Atividades
O cadastro dos recursos deve ser realizado na planilha de recursos do MS-Project, menu
Exibir/Planilha de recursos (View/Resource Sheet).
Para os recursos materiais da prpria organizao, tais como equipamentos ou insumos, ou que
se refiram a fornecedores externos, isto , que no sero debitados por hora no projeto, altere
o tipo de recurso (Type) de trabalho para Material.

Informe a Taxa padro (custo) de cada recurso, utilizando como referncia a tabela de recursos
e custos fornecida, e os custos estimados de cada material ou servio que ser contratado pelo
projeto.

89

Uma vez cadastrados os recursos, necessrio atribu-los s respectivas atividades. A

atribuio de recursos a atividades pode ser feita tanto na tabela de entrada do Gantt quanto
em Tarefa/Informao/Recursos (Task/Information/Resources).

Quando uma atividade utilizar o mesmo recurso j informado anteriormente em outra atividade,
em lugar de digitar novamente o nome do recurso, selecione o recurso da lista que aparecer
no campo Nome do recurso. Isso evitar que o software crie por engano (por exemplo, em
caso de digitao errada) um recurso diferente, quando o que se deseja utilizar o mesmo
recurso em vrias atividades.
 Estimar Durao das Atividades
Estime a durao, em dias teis, necessria para realizao de cada atividade do projeto que
ser executada por recursos internos da empresa.
As duraes de atividades que sero contratadas de fornecedores externos devero respeitar as
duraes previstas no contrato em questo.

90
 Analisar o Cronograma do Projeto
Ajuste do esforo dos recursos
V ao menu Exibir/Uso da tarefa (View/Task Usage) e estime o esforo (trabalho) que ser
empreendido por cada recurso interno da empresa. O MS-Project ter calculado um valor de
trabalho para cada recurso baseado na durao de cada atividade, mas necessrio rever esse
valor e, se necessrio, ajust-lo.

Restries de datas
Analise o cronograma atual do projeto em relao s restries de datas estabelecidas na
Declarao de Escopo do Projeto. Caso alguma restrio de data no esteja sendo respeitada,
verifique as alternativas de compresso (crashing) ou paralelismo (fast tracking) e faa uma
reviso no cronograma.
91
No menu Exibir/Grfico de Gantt/Gantt de controle (View/Gantt Chart/Trancking Gantt) o MS-
Project fornecer a viso de um grfico de barras onde o caminho crtico do projeto estar
sinalizado.
Utilizao de recursos
Verifique a alocao de recursos acessando o menu Exibir/Outro/Grfico de recursos
(View/Other Views/Resource Graph). Situaes de superalocao de recurso devero ser
resolvidas atravs de alocao de recursos adicionais (se disponveis) ou nivelamento de
recursos (caso no haja disponibilidade de mais recursos).
Outra maneira de verificar a superalocao de recursos, ou ajustar a carga de trabalho, no
modo de visualizao: uso do recurso (View/Resource Usage), utilizando a barra de
ferramentas gerenciamento de recursos.

92
PASSO 4
Aprovar Plano do Projeto
Definir Linha de Base

Oramentao do Projeto
Os custos do projeto podem ser especificados no momento em que os recursos so
cadastrados. Se este procedimento for adotado, restar, apenas ser feita uma verificao de
alguma omisso.
Para tal, no menu Exibir/Planilha de recursos (View/Resource Sheet) atribua valores de custos
a todos os recursos utilizados no projeto, inclusive os servios de terceiros e materiais.

Uma vez atribudos todos os custos a todos os recursos do projeto, o sistema realiza os clculos
de acordo com a durao da atividade e o tipo de recurso.
93
Para os recursos, cuja unidade de atribuio o trabalho, sero multiplicados os valores
unitrios (custo/hora) pela quantidade de trabalho necessria para a realizao de cada
atividade. Normalmente o trabalho varia em funo da durao, sendo assim, se a durao da
atividade aumentar, aumentar o trabalho e, consequentemente, o custo total da atividade.
No menu Exibir/Planilha de recursos (View/Resource Sheet) selecione o mtodo de
acumulao de custos que ser utilizado em cada recurso.

No caso dos recursos materiais ou servios de terceiros, o valor montante pode resultar da
durao da atividade qual ele esteja associado e, neste caso, aumentar com o aumento da
durao. Mas o valor montante pode ser independente da durao (ferramentas, por exemplo),
neste caso o valor montante ser constante.
Tendo atribudo valores a todos os recursos empregados no projeto, o software ter calculado o
custo de cada atividade e totalizado o custo total do projeto.
Um elemento importante para a configurao de um projeto o grfico que representa a curva
de custos acumulados. Tambm conhecida como Curva S do Projeto.

Aprovar o Plano do Projeto

94
necessrio que o plano seja submetido aprovao do patrocinador (sponsor) do projeto ou
pela diretoria da empresa.

Definir a Linha de Base do Projeto

Todos os parmetros definidos e aprovados como
o plano de gerenciamento do projeto serviro
como base de referncia, ou linha de base. O MS-
Project permite registrar a linha de base do
cronograma e dos custos associados.
Projeto/Definir Linha de Base (Project/Set
Baseline)
PASSO 5
Registrar o Progresso do Projeto
Preparar Relatrio de Status do Projeto
Aprovar Medidas de Controle

Neste passo vamos simular a execuo do projeto utilizando informaes tpicas do status do
projeto para avaliar o desempenho do projeto.

Preparao do MS-Project para o Monitoramento e Controle

Para o monitoramento e controle do projeto acesse o menu Exibir/Gantt de Controle
(View/Gantt Chart/Trancking Gantt). Insira as colunas: Durao, Incio e Trmino. Configurando
da seguinte forma:

Registrar o Progresso do Projeto 95

Aps receber as informaes sobre o andamento do projeto, siga os passos seguintes para
atualizar as informaes sobre o projeto:

1- Informe ao software, na janela Projeto/Informao do projeto (Project/Project

Information), a data de status para efeito de monitoramento do projeto.
Para configurar uma melhor visualizao da Data de Status (Status Date):
Em qualquer ponto em branco do grfico de Gantt do MS-Project clique com o boto
direito do mouse e selecione a opo Linhas de grade (Gridlines)

Em seguida localize no quadro Data de Status (Status Date), configure Tipo ou Type
como linha cheia e escolha uma cor para linha.

96

Data de
Status
2- Colete o Percentual completo PLANEJADO do projeto at a Data de Status
A fim de prevenir perda dos dados salvar o arquivo do MS-Project como nova
verso;
No menu Projeto/Atualizar Projeto (Project/Update Project);

Colete o percentual completo (planejado) na coluna % completo;

97

Este procedimento permite identificar o quanto teria sido realizado se todas as atividades
tivessem sido executadas conforme o planejado. Sem desvio algum.

3- Registre o percentual completo do projeto (% Realizado)

Utilizando a funcionalidade desfazer (undo) voltar at o ponto antes da atualizao
automtica realizada no passo anterior. Se o arquivo foi salvo como nova verso,
tambm possvel voltar ao arquivo original, ou seja sem atualizao alguma do
projeto;
Para a atualizao manual e especfica de cada atividade, no MS-Project, atualize a
coluna % concluda com as informaes recebidas sobre o andamento do projeto,
com ateno para os seguintes procedimentos:
Ao atualizar o progresso fsico das atividades procure seguir a sequncia de
realizao das mesmas.
Caso uma atividade tenha sido 100% concluda com variao de prazo, atualize
 primeiro a durao real da atividade e posteriormente informe o percentual de
concluso.
Caso uma atividade esteja parcialmente concluda e com previso de variao de
durao, atualize primeiro a nova durao prevista para a atividade e posteriormente
informe o percentual de concluso.
Aps estes procedimentos a coluna de % completo representar o valor efetivo
realizado at a Data Date (Data de Status), conforme figura abaixo:

98

4- Colete os valores de linha de base de oramento e cronograma

No menu Projeto/Informao do projeto (Project/Project Information), clique no
boto Estatsticas (Statistics);

Neste quadro possvel coletar os dados para preparar o relatrio de status.

 Preparar Relatrio com Informaes de Desempenho do Projeto
Prepare um relatrio de desempenho do projeto apresentando as seguintes informaes:
Percentual planejado de concluso;
Percentual completo;
Principais entregas completadas;
Principais entregas em andamento;
Linha de Base do Oramento do Projeto;
Linha de Base do Prazo do Projeto;
Variao de Custo (Real Linha de Base);
Variao de Prazo (Real Linha de Base);
Estimativa de custo no trmino;
Estimativa de data no trmino;
Proposta de aes corretivas, caso sejam necessrias.

99

Aprovar medidas de controle

As medidas de controle propostas no relatrio devem ser aprovadas pelo sponsor
(patrocinador) do projeto ou pela diretoria da empresa para, s ento, serem incorporadas ao
projeto.
PASSO 6
Registrar Mudanas Solicitadas
Analisar impactos no Projeto
Aprovar Mudanas

Aps receber a informao de Solicitao de Mudana em Projeto, que deve ser feita por meio
de documentao (como o formulrio abaixo), necessrio analisar os potenciais impactos no
projeto gerados pela mudana para s ento, submet-la aprovao.

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 100

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

A avaliao dos impactos das mudanas solicitadas deve ser tratada em dois movimentos:
1- Quantificar os impactos em cada uma das variveis do projeto, conforme disposto no
exemplo de formulrio acima;
2- Identificar aes de mitigao dos impactos da mudana que sejam capazes de manter o
projeto dentro dos seus parmetros de base.
Para atualizar as linhas de base de tempo e custo do projeto, mantendo as linhas de base
originais como registro histrico no MS-Project, acesse o menu Projeto/Definir Linha de Base
(Project/Set Baseline) e proceda da seguinte maneira:
Copie a Linha de base atual em Linha de base 1.
Salve a nova Linha de base para as atividades que foram atualizadas em funo da
solicitao de mudana em questo.

Se, no futuro do projeto, houver necessidade de salvar uma nova Linha de base, copie a Linha
de base atual em Linha de base 2 e assim por diante, para preservar o registro histrico das
vrias linhas de base que o projeto j teve.

101

Outra providncia que permitir voltar ao projeto com a linha de base original salvar o
arquivo com uma nova verso arquivo_V2, por exemplo.
PASSO 7
Avaliar Lies Aprendidas

A melhor prtica recomenda que se faa sees de lies aprendidas ao longo de todo o
processo do projeto a fim de que possa aproveitar as lies para o prprio projeto, que conte
com a contribuio de membros da equipe que participaro apenas em algumas fases do
projeto e que melhore a qualidade da memria das informaes em funo de uma menor
distncia dos fatos.
Para a prtica das sees de lies aprendidas recomendvel estabelecer um roteiro que guie
as discusses do grupo com questes semelhantes s seguintes:

1. O escopo do projeto foi claramente definido? O que poderia ter sido melhor definido?
2. Toda a equipe estava ciente dos objetivos do projeto e de como o sucesso seria
medido? O que pode ser feito para manter o foco nos objetivos de um projeto durante a
execuo do mesmo?
3. A equipe conseguiu propor aes corretivas para as variaes observadas entre a
execuo e o plano? Quais as dificuldades encontradas para propor aes corretivas?
4. Como a equipe se comportou diante das mudanas no projeto? Liste aspectos positivos
e aspectos a melhorar em relao ao comportamento diante de mudanas. 102
5. Houve conflitos durante as reunies da equipe? O que pode ser feito em outros projetos
para ajudar na resoluo de conflitos na equipe?
6. As reunies da equipe foram bem gerenciadas? Que recomendaes podem ser feitas
para reunies em projetos futuros?

* * *