Você está na página 1de 164

1

Seja Bem Vindo!



Curso
Gesto de Projetos
Carga horria: 60hs







2

Dicas importantes

Nunca se esquea de que o objetivo central aprender o
contedo, e no apenas terminar o curso. Qualquer um termina, s
os determinados aprendem!

Leia cada trecho do contedo com ateno redobrada, no se
deixando dominar pela pressa.

Explore profundamente as ilustraes explicativas disponveis,
pois saiba que elas tm uma funo bem mais importante que
embelezar o texto, so fundamentais para exemplificar e melhorar
o entendimento sobre o contedo.

Saiba que quanto mais aprofundaste seus conhecimentos mais
se diferenciar dos demais alunos dos cursos.

Todos tm acesso aos mesmos cursos, mas o aproveitamento
que cada aluno faz do seu momento de aprendizagem diferencia os
alunos certificados dos alunos capacitados.

Busque complementar sua formao fora do ambiente virtual
onde faz o curso, buscando novas informaes e leituras extras,
e quando necessrio procurando executar atividades prticas que
no so possveis de serem feitas durante o curso.

Entenda que a aprendizagem no se faz apenas no momento
em que est realizando o curso, mas sim durante todo o dia-a-
dia. Ficar atento s coisas que esto sua volta permite encontrar
elementos para reforar aquilo que foi aprendido.

Critique o que est aprendendo, verificando sempre a aplicao
do contedo no dia-a-dia. O aprendizado s tem sentido
quando pode efetivamente ser colocado em prtica.




3

Contedo

Introduo
Evoluo do Gerenciamento de Projetos
O Trabalho nas Organizaes
Origem dos Projetos
Metodologia de Gerenciamento de Projetos
Conceituaes
Organizao do Gerenciamento de Projetos
Desenvolvimento de Projetos: Idealizao e Concepo
Desenvolvimento de Projetos: Planejamento
Cronograma de Execuo
Oramento de Custos
Plano da Qualidade
Plano de Comunicao
Plano de Suprimentos ou Plano de Aquisies
Execuo e Controle
Gerenciamento de Escopo
Gerenciamento de Riscos
Gerenciamento de Stakeholders
Administrando Conflitos em Projetos, via Gerenciamento de Stakeholders
Encerramento do Projeto
Bibliografia/Links Recomendados







4

Introduo

Legenda:
SF Sr. Fortunato
PMI Sr. Paulo Martins Incio
MC Maria Conselheira
DS Delma da Silva
PR Pedro Rocha
SB Sr. Been


No ambiente de trabalho, nossos colaboradores lem o convite:
Prezado Colaborador:
5

Com o objetivo de informar adequadamente
sobre a importncia das boas prticas em
gerenciamento de projetos e os benefcios de
sua utilizao, convidamos a participar do I
Encontro de Gerenciamento de Projetos, a
ser realizado hoje, conforme programao:
Programao
Apresentao do Presidente: Sr. Fortunato
Evoluo do Gerenciamento de Projetos: Sr.
Paulo Martins Incio
Local
Auditrio Trreo da empresa

MC: Que convite legal! Com este encontro, teremos a
oportunidade de conhecer prticas atuais de gesto. Iremos
melhorar o acompanhamento de nossos processos e projetos.
DS: Como que ? Preciso ver para acreditar.
PR: L vm eles de novo. Por que ser que toda vez que nos
acostumamos com nossas tarefas, a alta administrao resolve
trazer mais novidades? No estou gostando disso!
SR: Relaxa, Rocha, deve ser apenas mais uma reunio. Vamos
voltar e vai continuar tudo igual.
6


Auditrio da Empresa
SF: Bom dia a todos. Obrigado pela presena neste encontro
sobre Gerenciamento de Projetos. Hoje apresentaremos para
vocs modelo e ferramentas de gesto que esto em
conformidade com as melhores prticas adotadas pelo mercado.
O comprometimento da implantao deste modelo e destas
ferramentas que vai determinar o sucesso de nossa empresa
no futuro. Passo a palavra ao nosso consultor, Sr. Paulo Martins
Incio.
PMI: Bom dia a todos. Inicialmente gostaria de parabeniz-los
pela participao neste encontro e espero contribuir tanto para o
aperfeioamento de sua atividade diria, quanto para o seu
desenvolvimento pessoal.
7

Espero que este nosso encontro seja interativo e, para isso,
faam perguntas sempre que necessitarem de alguma
informao adicional ou tiverem dvidas.
Bem, no posso falar de gerenciamento de projeto sem falarmos
de modelo de gesto. Em poucas palavras, podemos dizer que
Modelo de Gesto composto por duas fases distintas, mas
interdependentes.
A primeira etapa consiste da elaborao da Formulao
Estratgica, em que definida a Identidade Organizacional
(Negcio, Misso, Viso, Vantagem Competitiva e Crenas e
Valores) e so feitas anlises dos ambientes externo e interno. A
partir desses insumos, so definidos os objetivos globais e as
diretrizes estratgicas que nortearo as aes da empresa.
Esta etapa conduz a empresa a organizar suas estratgias
globais e a desenvolver um senso explcito de direo
estratgica.
A segunda etapa consiste da implementao da estratgia
definida. Nessa etapa, essencial a adoo de um sistema de
gesto integrado, que rena as informaes necessrias ao
alcance dos resultados planejados.
A partir dessa prerrogativa, utilizamos o Balanced Scorecard
(BSC) como um instrumento gerencial que evidencia o
desempenho da empresa, permitindo correes de rumo em
tempo hbil.
O BSC um sistema de gesto, baseado em indicadores que
mensuram o desempenho, possibilitando empresa viso do
negcio atual e futura, de forma abrangente. Ele permite um
equilbrio entre objetivos de curto e longo prazo e entre medidas
financeiras e no financeiras, uma vez que mede o desempenho
sob quatro diferentes perspectivas: finanas, mercado e imagem,
processos e pessoas.
O BSC mostra as relaes de causa e efeito entre as Diretrizes,
pelos indicadores de desempenho, metas e Iniciativas
8

Estratgicas, que so Programas e Projetos definidos como
prioritrios para o alcance dos resultados pretendidos.
MC: Sr. PMI, podemos dizer, ento, que compete ao
Planejamento Estratgico e s lideranas das organizaes
identificar e selecionar as melhores aes estratgicas, e ao
Gerenciamento de Projetos ser o agente executor das
mudanas?
PMI: Exatamente. Voc j parou para pensar no nmero de
mudanas (culturais, tecnolgicas, polticas, econmicas, etc.)
que esto ocorrendo em sua volta neste exato momento? De
uma maneira geral, comum associarmos as mudanas
significativas ao resultado de projetos bem sucedidos. Como
conseqncia, gerenciar projetos de forma eficiente nessa era de
grandes mudanas um dos grandes desafios do executivo dos
tempos modernos.
AR (Em pensamento): Eu discordo dessa linha de
raciocnio. Por que comear a complicar o que j est sendo
trabalhado? Muito bem, vou continuar ouvindo para ver aonde
isto vai terminar.
DS: Sr. PMI por que trabalhar com gerenciamento de projetos?
O que ns e a empresa ganhamos com isso?
PMI: Boa pergunta!!!
O incio da implementao do processo de administrao
estratgica tem sido uma das principais preocupaes para as
empresas. Desta forma, a elaborao e acompanhamento de um
bom projeto permitem o cumprimento de objetivos estratgicos e
nos direcionam para o futuro.
O gerenciamento de projetos est no seu pico histrico,
principalmente por ter se tornado uma escolha estratgica pelas
empresas. As evidncias podem ser vistas nas grandes
corporaes do mundo, que lanam iniciativas e centros voltados
excelncia no gerenciamento de projetos, executando as
melhores prticas e visando criar um ambiente favorvel ao
sucesso de seus objetivos e disseminao do conhecimento
adquirido.
9

DS: Voc poderia nos explicar melhor por que gerenciar
projetos?
PMI: Claro! Por que gerenciar projetos?
Estudos realizados comprovam que empresas que investiram em
esforos nas fases de pr-desenvolvimento conseguiram no
mnimo duplicar as chances de sucesso no lanamento de seus
produtos.
Empresas que no faziam uso de tcnicas de gerenciamento de
projetos tinham em mdia 71% de atraso nos seus cronogramas
(e este no era o maior de seus problemas!).
Segundo Stalk e Houl, a dcada de 80 foi considerada a dcada
da qualidade, e a de 90 a dcada da responsividade (no sentido
da resposta rpida ao mercado e no atendimento aos clientes).
Para Gates, as empresas devem possuir um mecanismo de
resposta rpida s mudanas, semelhante capacidade do corpo
humano em reagir de maneira automtica aos estmulos do meio
exterior. Porm apenas responder de forma rpida a um estmulo
no atende mais a todas as necessidades dos mercados;
preciso ser proativo. Estamos na era da Proatividade, em que
levam vantagem aqueles que conseguem se antecipar s
mudanas.
Estamos num mercado muito competitivo, onde as necessidades
de atualizao tecnolgica so constantes. As margens de lucro
das empresas so cada vez menores e os padres mais
exigentes de qualidade. Enfim, ter um gerenciamento de projetos
passou a ser uma questo de sobrevivncia para as empresas.
SB (Em pensamento) J estou ficando cansado.
Ser que essa conversa ainda vai longe?

Evoluo do Gerenciamento de
Projetos
10


MC: Sr. PMI, poderia nos dar uma linha de tempo sobre a
utilizao do gerenciamento de projetos?
PMI: Vou contextualizar a evoluo do Gerenciamento de
Projetos.
Achamos que gerenciamento de projetos recente ou que est
na moda. Na verdade, a cincia do gerenciamento de projetos
surgiu no incio da dcada de 60, nas universidades americanas,
que constataram a precariedade como eram tocados os projetos.
Inicialmente os projetos eram planejados e acompanhados
atravs das tcnicas denominadas PERT e CPM, que significam
respectivamente Program Evaluation Evaluation and Review
Techinique e Critical Path Methodo. PERT/CPM utilizam o
conceito de Rede para planejar e visualizar a coordenao de
atividades. No foram adiante, pois eram planejamentos
11

enormes, de difcil operao, confeccionados por pessoas com
pouco conhecimento dos negcios das
empresas.
Tradicionalmente os projetos eram executados considerando
apenas prazo, custos e qualidade. A partir da dcada de 70, o
quesito escopo passou a ser essencial no processo.
Mas ainda assim aspectos como recursos humanos e clientes
no eram considerados.
A partir da dcada de 80, outros itens passaram a ser
considerados e avaliados e, dessa forma, para se ter sucesso ou
fracasso, passou-se a considerar tambm a Satisfao do
Cliente, Metas quantitativas (escopo, prazo, custo, qualidade,
indicadores, etc.) e Moral da equipe.

Em 1987, foi publicado o primeiro guia que se tornou referncia
em conhecimento para o gerenciamento de projetos.
Veja a seguir a ilustrao da evoluo do gerenciamento de
projetos:

MC: Sr. PMI, eu poderia dizer que inicialmente os projetos eram
gerenciados apenas nos quesitos Tempo, Prazo e Custos. Em
seguida, percebeu-se a importncia de acompanhar tambm o
que seria executado, ou seja, qual o escopo do projeto. E
finalmente, nos dias atuais, alm desses quesitos, temos que
12

gerenciar pessoas, compras e riscos, comunicar, entregar com
qualidade e principalmente ter todos eles integrados.
PMI: Isso mesmo.
SB: Ufa! muita coisa para um projeto s.
Risos
O Trabalho nas Organizaes
PR: Muito interessante. Mas como funciona o gerenciamento de
projetos nas organizaes? Todas trabalham por projeto ou
com projeto?
PMI: Vou explicar.
Na realidade, todas as empresas possuem projetos e processos.
Segundo Darci Prado, devemos considerar que, em todos os
tipos de empresa, temos sempre a ocorrncia de projetos e
operaes rotineiras e, dessa forma, precisamos avaliar a ligao
de um destes grupos (projetos ou processos) com os negcios da
empresa.
Processos e projetos tm caractersticas comuns:
executados por pessoas;
restringidos por recursos limitados;
planejados, executados e controlados.
O que diferencia o trabalho nas organizaes pode ser observado
a seguir:

13

DS: Posso dizer, ento, que a nossa rea de compras tm
processos e que a implantao de um software de compras um
projeto?
PMI: Exatamente. Na maioria das empresas, temos
processos/rotinas de compras, onde mtodos j foram definidos e
implantados. Essas reas atendem a vrios setores de forma
sempre contnua.
J a implantao de um software, independente de ser de
compras, algo novo, que deve ser tratado como um projeto.
Origem dos Projetos
DS: Mas qual a origem dos projetos?
PMI: Normalmente so elaborados partindo de um problema ou
oportunidade. Como dito anteriormente, so fatos e dados que
foram identificados e apontados no planejamento estratgico da
empresa.
Diversos tipos de projetos ocorrem dentro da organizao. Eles
so elaborados partindo de:

14

MC: Como podemos classificar os projetos?
PMI: As categorias mais conhecidas de projetos so:
Administrao;
Pesquisa e Desenvolvimento;
Design;
Construo;
Manuteno;
Informtica;
Desenvolvimento de Novos Produtos;
Eventos;
Instalao de Equipamentos;
Melhorias.

Metodologia de Gerenciamento de Projetos
SF: Gostaria de ressaltar a importncia de todas essas
informaes e questionamentos, pois elas embasam a
necessidade de utilizao de uma metodologia para o
gerenciamento de projetos.
PMI: Existem hoje vrias definies para metodologia de
gerenciamento de projetos, mas preciso ficar claro que a
metodologia adotada deve ser a que se adapte melhor a sua
empresa e aos projetos por ela gerenciados.
Uma metodologia de Gerenciamento de Projetos tem que:
ser uma coleo de mtodos, tcnicas e ferramentas para
desenvolvimento de programas e projetos;
ser o principal modelo: estabelecido no Guia PMBOK (Project
Management Body of Knowledge) pelo Project Management
Institute PMI;
estabelecer que um projeto deva ser administrado por Gerentes
de Projetos e sua equipe, que executaro processos de
gerenciamento de projetos;
estabelecer que os processos sero executados ao longo do
ciclo de vida;
estabelecer que os projetos possuam um ciclo de vida;
estabelecer que os projetos tm interfaces com as reas de
atuao gerencial da organizao;e
Estabelecer que projetos devem ser apoiados por um Escritrio
de Projetos.
SB: Agora no entendi nada. Sr. PMI, ser que poderia explicar
melhor as siglas e conceitos acima?
15

PMI: Perfeitamente. Iremos para um pequeno intervalo do caf e
retornaremos com a descrio geral de alguns itens importantes
para o gerenciamento de projetos.

CATEGORIAS DE PROJETOS

Diversos tipos de projetos ocorrem nas organizaes e, pelas
peculiaridades de seus processos de gerenciamento, so
naturalmente classificados em diversas categorias. As mais
conhecidas so listadas abaixo [4]:

ADMINISTRAO

Estes projetos esto acontecendo freqentemente na vida de
qualquer organizao. Alguns exemplos:
Campanha para reduo de custos;
Campanha de desburocratizao;
Reorganizao de um departamento;
Implementao de tcnicas de GQT (Gerncia pela Qualidade
Total).

PESQUISA E DESENVOLVIMENTO

Trata-se de projetos que objetivam, posteriormente, desenvolver
ou melhorar um produto, servio, processo ou mtodo. Para
alguns projetos dessa natureza, difcil saber, na fase de
planejamento, exatamente quando e como se chegar ao produto
final e, portanto, apresentam alto nvel de risco.
Alguns exemplos:
Pesquisa de um novo sabor para um alimento para gato;
Pesquisa de um motor de automvel mais econmico;
Pesquisa de uma variedade de soja mais resistente aos
trpicos;
Pesquisa de um medicamento para a cura da AIDS.

DESIGN

Nesta categoria, temos os projetos de arquitetura, engenharia,
vesturio, software, etc. Eles geralmente fazem parte de um
projeto maior que envolve uma construo, o desenvolvimento de
16

um novo produto ou de um software, etc. Portanto eles vo
somente at a gerao da documentao tcnica, da construo
de um prottipo, de uma fbrica-piloto, de um modelo em escala,
etc.
Geralmente so precedidos por um projeto do tipo pesquisa e
desenvolvimento. Posteriormente ao seu trmino, durante a
execuo definitiva, o projeto de design seguido por um projeto
de construo, montagem, programao, etc. Assim, as
finalidades de um projeto de Design so:
Especificaes detalhadas do produto.
Instrues sobre montagem e construo.
Testes em prottipos, fbrica-piloto, modelo em escala.
Alguns exemplos:
Estudo arquitetnico para uma residncia (no Brasil, comum
chamar o produto final desse estudo de Projeto Arquitetnico, o
que cria uma certa confuso);
Estudo hidrulico para um prdio;
Estudo eltrico para uma fbrica;
Montagem de uma fbrica-piloto de uma indstria qumica, para
testes.

CONSTRUO

Estes projetos geralmente se baseiam em um projeto de
engenharia (design) j realizado. A durao desses projetos varia
de meses a anos. So projetos em que possvel efetuar a
execuo de forma bem prxima ao planejado, diferentemente de
outros tipos de projetos. Nesses projetos, mais fcil obedecer
aos custos planejados do que aos prazos. Aspectos de
segurana so tambm de fundamental importncia devido s
severas leis governamentais. Alguns exemplos:
Construo de um prdio de moradia;
Construo de uma barragem hidroeltrica;
Construo de um aeroporto;
Construo de uma usina siderrgica;
Construo de uma ponte.

MANUTENO

Estes projetos consistem em desmontar e reconstruir uma
17

instalao ou produto. So projetos de curta durao, em que o
benefcio da reduo do tempo total em um dia pode,
eventualmente, ser medido em milhes. O aspecto-chave aqui
o seqenciamento das atividades e alocao de recursos no
exato momento de sua necessidade. Alguns exemplos:
Manuteno de um alto-forno de uma usina siderrgica;
Manuteno de uma torre de refinao de petrleo;
Reviso de aeronaves.

INFORMTICA

Trata-se de projetos relacionados com aplicaes para
computador e aqui se enquadram tanto os projetos de
desenvolvimento de uma nova aplicao como tambm a
aquisio, modificao e a instalao. Assim, alguns deles se
assemelham a projetos de construo (nos quais possvel
prever todas as etapas) e outros mais se assemelham a projetos
de pesquisa nos quais muito difcil prever antecipadamente
todas as caractersticas do produto final e, tambm, como se
chegar a ele.

DESENVOLVIMENTO DE NOVOS PRODUTOS

Estes projetos envolvem o desenvolvimento de um produto
totalmente novo ou modificaes em produtos j existentes.
Certamente uma categoria praticada em todas as empresas
nas quais, geralmente, o processo possui um alto nvel de
padronizao. Podem ser vistos de uma forma ampla,
abrangendo a pesquisa de mercado, o design e desenvolvimento
do produto e dos correspondentes processos de fabricao, a
construo da nova fbrica, a produo inicial e a campanha de
marketing.
Alguns exemplos:
Desenvolvimento e lanamento de uma nova verso do
software Windows;
Desenvolvimento e lanamento do automvel Fiat Plio;
Desenvolvimento e lanamento de uma nova linha de calados.

EVENTOS

Devido ampla aceitao da importncia da realizao de
18

eventos, essa categoria de projetos se profissionalizou muito e
existem inmeras empresas especializadas nela. Alguns
exemplos:
Feira de vesturios;
Conveno de vendas;
Show de rock;
Comcio poltico.

INSTALAO DE EQUIPAMENTOS

Um projeto de instalao de um equipamento pode envolver
inmeras aes. Por exemplo, a instalao de um grande
computador envolve:
Instalao de ar condicionado em um prdio, supermercado,
etc.;
Instalao de equipamentos de automao.

MELHORIAS

Os projetos de melhorias de indicadores de desempenho
constituem uma imensa gama de projetos que ocorrem em
qualquer tipo de empresa. De uma maneira ampla, eles esto
intimamente ligados s operaes rotineiras que ocorrem em
fbricas, escritrios, lojas, etc. Seu gerenciamento geralmente
no exige a aplicao de todo o ferramental de gerenciamento de
projetos, mas costuma exigir bons conhecimentos de tcnicas de
estatstica (six sigma black belt) para identificar claramente as
causas do problema e apontar solues. Geralmente as solues
apontadas exigem conhecimentos de tcnicas de Gerenciamento
pela Qualidade Total. Eventualmente, uma das solues
apontadas pode ser, por exemplo, a ampliao ou a construo
de um novo setor na fbrica e, nesse caso, tem-se um projeto
tradicional. Alguns exemplos de gerenciamento de melhorias:
Diminuio de gastos com transportes de uma empresa
transportadora;
Diminuio do gasto de energia eltrica de um alto-forno
siderrgico;
Diminuio do tempo de montagem de um produto de uma
fbrica;
Diminuio de re-trabalho em um setor de uma fbrica;
19

Diminuio de perdas de peas que se quebram em uma linha
de produo.

Conceituaes

Na rea de cofee break

MC: Quanta informao importante estamos recebendo, vocs
no acham?
DS: Concordo. No entanto, preciso de mais fatos e dados, para
efetivamente poder trabalhar com gerenciamento de projetos.
PR: No sei no. Acredito que tudo isso s vai burocratizar mais o
meu trabalho.
MC: Burocratizar no, Pedro Rocha. Temos de considerar que
novos processos de trabalho, no incio, so complicados, pois
so novidades. Mas depois facilitam nossas tarefas e
demonstram a eficincia e eficcia dos nossos resultados.
20

SB: A que mora o perigo!!!
Risos de todos
MC: Como disse o Sr. PMI, a metodologia de gerenciamento de
projetos traz um conjunto de mtodos, tcnicas e ferramentas
para nos auxiliar na execuo de programas e projetos.
SB: So muitas informaes para eu assimilar. No acredito que
isso vai dar certo.
MC: Temos que estar mais abertos s mudanas. Vejam s,
demos o primeiro passo ao elaborarmos nossa planejamento
estratgico.
PR: H, mas esse trabalho ficou s no papel.
DS: Voc est precisando de culos, Pedro. No reparou que, em
todos os andares da empresa, esto os quadros divulgando
nossa identidade organizacional?
PR: No que eu no reparei?
MC: E no s isso. Recebemos material por e-mail. Temos
insumos suficientes para trabalharmos nossos processos,
programas e projetos.
DS: Mas existem muitos conceitos que ainda no esto claros.
MC: Vamos voltar para o auditrio, acredito que neste segundo
tempo tudo ser esclarecido.
SB: L vamos ns de novo.

1 conceito PMI

SF: Sejam bem-vindos de volta ao nosso encontro. Espero que
tenham aproveitado esse intervalo para assimilar um pouco mais
as informaes j repassadas.
PMI: Para aprimorar nossos conhecimentos em gerenciamento de
projetos, vamos conceituar alguns termos importantes para vocs
no dia-a-dia.
Todo o nosso trabalho est conceituado conforme as melhores
prticas em gerenciamento de projetos definidas no PMBOK,
publicado pelo PMI.
PR: (Em pensamento) L vem ele de novo com essas siglas.
PMI: Mas o que PMI?
O PMI - Project Management Institute hoje a maior instituio
no mundo exclusivamente dedicada ao fomento da atividade de
Gerenciamento de Projetos. Criada em 1969 na Pensilvnia,
21

Estados Unidos, conta hoje com mais de 200.000 filiados
distribudos em cerca de 140 pases. O PMI compartilha seus
padres tcnicos e ticos com a comunidade internacional de
Gerenciamento de Projetos atravs de organizaes sem fins
lucrativos de mbito regional. So os Captulos locais do PMI.
Hoje so aproximadamente 300 captulos.
Com o passar do tempo, o PMI se tornou, e continua sendo, a
principal associao profissional em Gerenciamento de Projetos.
Os associados e interessados em Gerenciamento de Projetos
tm sua disposio uma extensa relao de produtos e servios
oferecidos pelo PMI. Esses produtos e servios esto
detalhados no site do PMI, que vocs podem acessar a
qualquer momento. O site www.pmi.org. Vou entregar a vocs
tambm um arquivo (LINK) com o detalhamento desses produtos
e servios.

2 conceito PMBOK

PMI: E PMBOK? O PMBOK Project Management Body of
Knowledge" (PMBOK Guide) um termo que abrange o
universo do conhecimento da profisso de Gerenciamento de
Projetos. Esse universo de conhecimento vem dos praticantes e
acadmicos que utilizam e desenvolvem tanto as prticas
amplamente testadas e aprovadas quanto aquelas modernas e
inovadoras, com aplicao mais restrita.
Um dos principais mecanismos utilizados para compartilhamentos
dos padres tcnicos e ticos a publicao, sempre atualizada
e revista, do PMBOK - Project Management Body of Knowlwdge,
um livro que rene o corpo de conhecimento em gerenciamento
de projetos.
O livro identifica e descreve o subconjunto do universo do
conhecimento de Gerenciamento de Projetos reconhecido como
boas prticas em muitos projetos na maior parte do tempo,
havendo consenso pelos praticantes sobre seus valores e
aplicabilidade. Entretanto, a aceitao geral no representa a
necessidade de aplicao uniforme em todos os projetos,
devendo ser definido o que apropriado para cada projeto /
indstria.
22

O PMBOK Guide tambm estabelece uma linguagem comum
para a profisso, servindo de referncia bsica para qualquer um
que se interesse pelo Gerenciamento de Projetos e, como tal,
no deve ser encarado como um documento que contemple a
totalidade do conhecimento de Gerenciamento de Projetos.
Periodicamente so realizadas revises, e novas verses so
desenvolvidas.

3 conceito Projetos
MC: O principal conceito de projetos vem do trabalho
desenvolvido pelo PMI?
PMI: Sim. Segundo PMI Projeto um esforo temporrio
empreendido para criar um produto, servio ou resultado
exclusivo.
Temporrio, pois cada projeto tem incio e fim definidos; e
Exclusivo, pois o produto ou servio gerado diferente, em algum
ponto, de qualquer produto ou servio existente.
23

DS: Mas quais so as principais caractersticas de um projeto?
PMI: Um projeto possui vrias caractersticas, dentre as quais eu
destaco:
ele sempre Multifuncional, pois requer recursos de vrias
reas, sejam recursos humanos, materiais ou financeiros;
envolve incertezas relativas a escopo, prazos e contedo de
forma geral, que, no incio, so grandes, mas diminuem com seu
andamento;
podem sofrer Alteraes de escopo, custo e prazo durante sua
realizao;
PR: Voc j classificou os projetos. Poderia me dar exemplos de
projetos?
PMI: claro! Exemplos de Projetos:
construo de uma usina siderrgica;
desenvolvimento de um software de computador;
construo de um prdio;
lanamento de um novo modelo de automvel;
implantao de um Sistema da Qualidade;
implantao de um sistema de medio de nvel do ao para
produo de lingotes.

4 conceito Gerenciamento de Projetos

PMI: Falei, na primeira parte do nosso encontro, sobre
metodologia de gerenciamento de projetos. Agora explico a vocs
o que gerenciamento de projetos.
Segundo PMI Gerenciamento de projetos a aplicao de
conhecimentos, habilidades, ferramentas e tcnicas s atividades
do projeto a fim de atender aos seus requisitos.
Todo projeto dever ter um responsvel a quem chamamos de
Gerente de Projeto. Este Gerente o responsvel pelo
gerenciamento do projeto.
Gerenciar um projeto inclui:
1. identificar necessidades, estabelecer objetivos claros e
alcanveis;
2. balancear as demandas conflitantes de qualidade, escopo,
tempo e custo;
3. adaptar as especificaes dos planos e da abordagem s
24

diferentes preocupaes e expectativas das diversas partes
interessadas.
SB: Em resumo, para gerenciar projetos, temos que ser um super
heri.
risos
MC: Mas gerenciamento de projetos s isso?
SB: S isso?!
PMI: Segundo descrio do PMBOK, o gerenciamento de projetos
existe em um contexto mais amplo que inclui o gerenciamento de
programas, o gerenciamento de portflios e o escritrio de
projetos. Normalmente, existe uma hierarquia de plano
estratgico, portflio, programa, projeto e subprojeto, na qual um
programa constitudo de diversos projetos associados contribuir
para o sucesso de um plano estratgico.

5 conceito Programas

PR: Tudo muito lindo, mas ainda no sei como isto vai facilitar o
meu trabalho. Vamos acabar misturando alhos com bugalhos.
PMI: Como acabei de dizer, o gerenciamento de projetos existe
em um contexto muito mais amplo. Dessa forma temos como
gerenciar projetos, atravs de programas.
Um Programa um grupo de projetos relacionados entre si,
administrados e coordenados de forma centralizada para se
obterem benefcios e controles no disponveis, se administrados
individualmente.
Programas possuem um Ciclo de Vida e projetos podem ser
acrescentados ao longo do ciclo conforme necessidade e
objetivos.
Programas podem incluir elementos de trabalho fora do mbito
do escopo de seus projetos. Os projetos de um programa podem
ser associados a linhas especficas de um negcio ou a tipos
gerais, como infra-estrutura e melhoria interna de processos.
Programas tambm envolvem sries repetitivas ou cclicas de
aes.
Exemplos:
25

O programa de um novo modelo de carro pode ser dividido em
projetos de desenho tcnico e atualizao de cada componente
principal (por exemplo, transmisso, motor, interior, exterior),
enquanto a fabricao acontece na linha de montagem;
Empresas realizam programas de construo anual, uma
operao regular e contnua que envolve muitos projetos.
O gerenciamento de programas compreende a administrao
coordenada e centralizada dos projetos que o compem, visando
a alcanar os objetivos estratgicos e os benefcios do programa.
A estrutura do programa precisa ser revisada e ajustada
periodicamente, em resposta ao desempenho interno e a fatores
externos governamentais, tecnolgicos, polticos e econmicos.
Pontos-chave a respeito de programas e projetos:
executar um programa como operar um negcio;
ambos tm os clientes e outros envolvidos com interesse no
resultado;
ambos tm uma misso contnua, um propsito e uma viso;
ambos tambm precisam de estratgias e planos com metas de
longo prazo e objetivos;
o programa composto por todos os projetos que, direta e
indiretamente, conduzem ao atendimento de sua meta;
em gerenciamento de programas, os elementos principais so
planejamento, oramento, estimativas de recursos, liderana e
coordenao;
o coordenador de programa deve produzir uma srie de planos
especficos e relacionados, que incluem planos estratgicos,
execuo, custos, pessoal, comunicao, negcio e tecnologia;
projetos bem definidos aumentam as chances de sucesso do
programa;
programas so dinmicos e requerem reviso peridica e
ajuste.

MC: Podemos afirmar que os Programas so completamente
dependentes dos seus projetos, subprojetos e processos, e o
sucesso do programa global diretamente proporcional ao
sucesso desses elementos?
PMI: Exatamente. Em outras palavras, o sucesso do programa
diretamente proporcional ao sucesso dos projetos que o
compem.
26


6 conceito Portflios

DS: Nem todos os conceitos esto muito claros para mim. Posso
dizer que gerenciamento de programas a mesma coisa que
gerenciamento de portflio?
PMI: No. Portflio mais amplo. Portflio o conjunto de
projetos e/ou programas de uma organizao, entidade ou
gerente. Os projetos e/ou programas que compem um portflio
no so necessariamente dependentes ou diretamente
relacionados.
PR: Agora bagunou minha cabea. Ento para que utilizamos
gerenciamento de programas, se podemos utilizar o
gerenciamento de portflios?
PMI: As empresas utilizam o gerenciamento de portflios quando
j possuem uma estrutura bem consolidada de gerenciamentos
de projetos.
Dessa forma, o gerenciamento de portflio passa a ser um
processo de deciso dinmico, atravs do qual uma lista de
projetos para novos produtos (e para Pesquisa &
Desenvolvimento) constantemente atualizada e revisada. Neste
processo, novos projetos so avaliados, selecionados e
priorizados; os existentes podem ser acelerados, eliminados ou
"despriorizados"; e recursos so alocados e realocados aos
projetos ativos.
Segundo Ricardo Vargas, Gerenciamento de Portflio significa
gerir o conjunto dos projetos e programas com um todo sistmico.
Mas no um todo indiferenciado. , sim, um sistema que
comporta diferentes graus de contribuio estratgica. Requer
agrupar e discriminar todas as iniciativas, permitindo:
a alocao diferenciada dos recursos,
a alocao adequada dos esforos para atingir os objetivos; e
a gesto tima dos investimentos.
DS: Mas que benefcios a empresa tem em utilizar o
Gerenciamento de Portflios?
PMI: O Gerenciamento de Portflios est diretamente vinculado s
estratgias da empresa. Se vocs lembrarem o que eu disse
anteriormente, as estratgias traduzem a direo da empresa
para o alcance dos objetivos. Dessa forma temos os seguintes
benefcios:
27

permite validar a estratgia corporativa;
permite o gerenciamento de recursos;
liga os resultados dos projetos com as estratgias
organizacionais;
mantm a visibilidade de todas as informaes vitais dos
projetos;
facilita o acesso e as comunicaes dentro da organizao; e
subsidia a tomada de decises.
SB: Tenho uma memria visual. Voc no teria por acaso uma
representao grfica de como todas as informaes esto
relacionadas?
PMI: Tenho sim. Veja a o prximo slide.

PMI: Agora ficou mais claro?
SB: Ficou sim. Obrigado.

7 conceito Convnios

PR: Trabalhamos hoje com um volume grande de convnios.
Podemos considerar que cada convnio um projeto?
PMI: Nem sempre um convnio igual a um projeto. Vocs sabem
a definio de convnio?
MC: Convnio um instrumento jurdico. So acordos firmados
por entidades pblicas de qualquer espcie, ou entre essas e
28

organizaes particulares, para a realizao de objetivos de
interesse comum dos partcipes.
PMI: Exatamente. Assim temos convnios que representam um
projeto ou convnios que representam um programa onde
podemos desenvolver vrios projetos.
PR: Podemos dizer que somos parceiros de entidades pblicas no
desenvolvimento de aes?
PMI: Sim, podemos. Essas parcerias so concretizadas por meio
de convnios que definem aes, em regime de cooperao, com
nfase nos aspectos relativos qualidade, produtividade,
inovao, capacitao, desenvolvimento de estudos, novos
produtos e processos produtivos.
Os convnios firmados entre as empresas e os seus parceiros
geram aes que resultam em projetos, os quais so
juridicamente contratualizados, especificando escopo, prazo e
custo.
29


8 conceito Contratos

DS: Podemos dizer que convnio o mesmo que contrato?
PMI: No. Contrato um acordo em que os participantes tm
interesses diversos e opostos, ou seja, quando se deseja, de um
lado, o objeto do acordo ou ajuste, e do outro, a contraprestao
correspondente, ou seja, o preo Contrato um instrumento
utilizado para firmar, perante terceiros, o compromisso de adquirir
ou oferecer servios, materiais e outras obrigaes
reciprocamente estabelecidas.
Os contratos podem variar em tamanho, contedo e propsito.
De forma geral, h diversos tipos de contratos, como de
prestao de servios e de representao, compra e venda de
bens e/ou produtos.
MC: Dessa forma podemos dizer que um convnio, alm de definir
um programa ou projeto, tambm composto de vrios contratos
para sua execuo.
30

PMI: Isso mesmo. Bem pessoal, termino aqui a minha
apresentao. Espero ter contribudo com informaes que lhes
permitam aprofundar seus conhecimentos em gerenciamento de
projetos.
SF: Gostaria de agradecer a todos pela participao neste
encontro. Tenho a certeza de que demos o primeiro passo para a
implantao de uma boa gesto de projetos na empresa. O Sr.
Paulo Martins Incio estar disposio para quaisquer
esclarecimentos que vocs necessitem tendo em vista o bom
desenvolvimento de suas tarefas. Desejo a vocs um timo
trabalho.

Organizao do Gerenciamento de Projetos

Na empresa:

SB: Vamos almoar?
31

DS: tima idia. Toda essa conversa me deixou com fome.
MC: Aonde vamos almoar?
SB: Tem um restaurante de um amigo meu, que foi inaugurado na
semana passada. Vamos conhec-lo?
PR: Espero que a comida seja boa!
Rsrs

1 Ciclo de Vida

MC: Vocs conseguem observar que tudo ao nosso redor lembra
gerenciamento de projetos?
PR: Voc j est delirando por causa da fome.
DS: Como assim Maria Conselheira?
MC: Observem aquelas duas rvores. Uma est seca e a outra
est com todo vigor.
SB: Mas o que isto tem a ver com gerenciamento de projetos?
MC: Tudo na vida tem um ciclo de vida. Aquela rvore seca, com
certeza, teve seu ciclo.
32

DS: Voc quer dizer que ela foi plantada, cresceu, deu frutos e
agora est morrendo?
MC: Isso mesmo!
PR: Fao minhas as palavras do Been. O que isso tem a ver com
gerenciamento de projetos?
MC: O conceito de ciclo de vida : Conjunto de atividades que
caracterizam a seqncia de desenvolvimento do projeto,
organizadas em fases e etapas. isso que a Delma descreveu.
A rvore passa por vrias fases e etapas, como um projeto.
PR: Voc quer dizer, ento, que o ciclo de vida de uma rvore
igual ao ciclo de vida de um projeto? Voc ficou maluca!
MC: rsrs. Eu no disse que so iguais, e sim que possuem as
mesmas caractersticas, ou seja, um ciclo de vida define o incio e
o fim de um projeto.
DS: Se entendi bem, podemos dizer, ento, que todos os projetos
possuem um ciclo de vida, ou seja, nascimento, maturidade,
velhice e morte.

2 Processos

MC: Isso mesmo. Essas etapas so chamadas de processo no
gerenciamento de projetos.
SB: Maria Conselheira, como voc sabe tudo isso?
MC: Tenho estudado sobre o tema gerenciamento de projetos e,
depois do encontro de hoje, muitas coisas ficaram mais claras
para mim.
PR: Ento me explique melhor sobre o que so processos em
gerenciamento de projetos.
33

MC: Voltando ao incio da nossa conversa, observe aquele ninho
que est na rvore. O que voc v?
PR: Um ninho cheio de passarinhos cantando. E da?
MC: Veja com outros olhos e lembre o que a Delma falou. Tudo
no passa de um ciclo. Os passarinhos nascem, aprendem a
voar, depois acasalam, tem seus filhotes e depois morrem.
As etapas esto ligadas umas nas outras. Os processos do
gerenciamento de projetos tambm. Podemos dizer que
processos so conjuntos de aes ou atividades
interrelacionadas, para criar um produto ou servio especfico.

3 Processos de Gerenciamento de Projetos.

SB: Mas espera a. Os processos de Gerenciamento de projetos
so nascimento, maturidade, velhice e morte!?
MC: No. Em gerenciamento de projetos, temos:
Nascimento = iniciao ou concepo
Adolescncia = planejamento
Maturidade = execuo
Velhice = Monitoramento e controle
Morte = encerramento.
DS: Se eu entendi bem, ento podemos dizer que o
gerenciamento de projetos uma atividade de integrao desses
processos, que devem ser executados simultaneamente, tantas
vezes quantas necessrias.
MC: Exatamente.
PR: Mas para que ciclo de vida?
MC: Lembra-se do que o Sr. PMI nos disse mais cedo? Ele disse
que toda organizao que trabalha com projetos possui uma
metodologia qual se adapta melhor e:
estabelece que os processos sejam executados ao longo do
ciclo de vida;
estabelece que os projetos possuam um ciclo de vida.
SB: Est bom. E da?
DS: Acho que consigo explicar. A formalizao dos processos ao
longo do ciclo de vida permite que a organizao administre seus
projetos considerando sempre as suas caractersticas internas.
PR: Antes que d um n na minha cabea, posso traduzir isso
da seguinte forma:
34

1. Ciclo de vida formado por processos;
2. Os processos so: processos de iniciao; processos de
planejamento; processos de execuo; processos de
monitoramento e controle; processos de encerramento; e que
3. O inter-relacionamento desses processos permite um bom
gerenciamento de projetos.
MC: Muito bom, Pedro. exatamente isso.
SB: Ento gerenciar projetos muito fcil!
DS: Fcil eu no diria. Exige conhecimento e dedicao.
SB: J estou com muita fome. Podemos ir para o restaurante?
DS: Boa idia. Daqui a pouco no conseguimos nem lugar no
restaurante para almoar.
PR: Ento vamos todos no meu carro. Assim continuamos essa
conversa. Este assunto est comeando a me interessar.

4 reas de conhecimento.

MC: Voltando a nosso assunto e falando em conhecimento, vocs
se lembram do nosso programa de qualidade?
PR: O que isso tem a ver com gerenciamento de projetos?
35

MC: Tudo!

MC: Na realidade, o relacionamento dos processos igual ao ciclo
do PDCA, ou seja, planejamos, desenvolvemos, checamos e
corrigimos as falhas. (Ver figura acima)
DS: Maria, se temos todos os processos, precisamos detalhar um
pouco mais para termos uma boa gesto dos projetos.
MC: Segundo o PMBOK, temos nove reas de conhecimento que
nos ajudam na gesto de projetos.
SB: reas de conhecimento? O que isso?
MC: As reas de conhecimento so definidas pelo PMI. Elas
descrevem os conhecimentos e prticas em termos de
processos. Esses processos esto organizados em 9 (Nove)
reas, que so:
1. Gerenciamento da Integrao;
2. Gerenciamento do Escopo;
3. Gerenciamento do Tempo;
4. Gerenciamento do Custo;
5. Gerenciamento da Qualidade;
6. Gerenciamento dos Recursos Humanos;
7. Gerenciamento das Comunicaes;
8. Gerenciamento do Risco;
9. Gerenciamento das Aquisies do Projeto (Suprimentos).
PR: E como tudo isso est relacionado?
MC: Espere... Tenho um material na minha pasta que pode
exemplificar o seu questionamento.

PROCESSOS, REAS DE CONHECIMENTO E O CICLO DE VIDA
36


SB: Delma...tenho que concordar com voc. Gerenciar projetos
exige muito conhecimento. Veja o quadro que a Maria nos
mostrou. At me deu mais fome. Esse quadro parece uma sopa
de letrinhas.
DS: Voc leva tudo na brincadeira, mesmo quando o assunto
srio.
Risos
PR: Chegamos. Vou estacionar enquanto vocs entram.
SB: OK, Rocha. Iremos procurar uma boa mesa e aguardamos
voc.


____________________________________________________
_______________________________________
REAS DE CONHECIMENTO

Gerenciamento de Integrao processos que garantem que os
diversos elementos do projeto esto apropriadamente
coordenados. Consiste do desenvolvimento do plano de projeto,
execuo do plano e controle de mudanas.
Gerenciamento de Escopo processos necessrios para garantir que
o projeto inclui todo o trabalho requerido, e somente o trabalho
requerido, para que seja completado com sucesso. Consiste da
iniciao do projeto, planejamento de escopo, definio de
escopo, verificao de escopo e controle de mudana do escopo.
37

Gerenciamento do Tempo processos que garantem que o projeto
seja concludo no tempo correto. Consiste de definio das
atividades, sequenciamento de atividades, estimativas de
durao de atividades, criao do cronograma e controle do
cronograma.
Gerenciamento de Custo processos necessrios para garantir que
o projeto seja completado dentro do oramento aprovado.
Consiste de planejamento de recursos, estimativa de custos,
definio de oramento e controle de custos.
Gerenciamento da Qualidade processos necessrios para que o
projeto satisfaa as necessidades para as quais foi criado.
Consiste do planejamento, asseguramento e controle da
qualidade.
Gerenciamento de Recursos Humanos processos para garantir o uso
mais eficiente das pessoas envolvidas no projeto. Consiste de
planejamento organizacional, bem como de formao e
desenvolvimento da equipe.
Gerenciamento de Comunicaes processos necessrios para que a
informao do projeto seja gerada, coletada, disseminada,
armazenada e/ou descartada da forma correta. Consiste de
planejamento da comunicao, distribuio da informao,
relatrios de desempenho e fechamento administrativo.
Gerenciamento de Risco processos que identificam, analisam e
respondem aos riscos do projeto. Consiste de identificao de
riscos, quantificao e qualificao de riscos e desenvolvimento e
controle da resposta aos riscos.
Gerenciamento de Aquisies processos necessrios para a
aquisio de bens e servios de terceiros. Consiste de
planejamento de aquisies, planejamento de solicitaes,
seleo dos fornecedores, administrao de contratos e
fechamento de contratos.

Desenvolvimento de Projetos: Idealizao e Concepo
38


No Restaurante

SB: Nossa, que lugar legal!
DS: Tambm concordo.
MC: Been, voc conhece o dono deste restaurante, no ?
SB: Sim, ele meu amigo. Por que a pergunta?
MC: Porque eu queria saber dos detalhes deste projeto.
PR: Que projeto?
MC: O deste restaurante, claro!!
SB: Agora tudo virou projeto?
MC: Been, voc acha que este restaurante foi montado sem um
bom projeto?
PR: Maria, voc poderia nos explicar melhor?
MC: claro. Vamos entrar, que durante o almoo eu explico.
39


1 - Termo de abertura

MC: Lembram:se da nossa conversa quando estvamos vindo
para o restaurante?
DS: Sobre o ciclo de vida?
MC: Isto mesmo!
SB: O que isso tem a ver com a montagem deste restaurante?
MC: Tudo. Desenvolver um projeto executar o ciclo de vida.
conceber, planejar, executar e acompanhar, encerrar.
DS: Maria, se eu estou entendendo bem, todo este trabalho
depende de uma metodologia, como disse o Sr. PMI. Precisamos
de mtodos, tcnicas, modelos e ferramentas para
desenvolvimento de projetos.
MC: Alguns documentos so essenciais para um projeto.
Segundo o Guia PMBOK, existem trs documentos principais e
cada um deles possui um objetivo especifico.
PR: Quais so eles, Maria?
MC: Termo de abertura, Declarao do escopo do projeto e Plano
de gerenciamento do projeto.
SB: Mas o que um termo de abertura? E mais, volto a
perguntar: o que isso tem a ver com a montagem deste
restaurante?
MC: Segundo o Guia PMBOK, Termo de Abertura o
documento que autoriza formalmente o projeto, concede ao
gerente de projetos indicado a autoridade para aplicar os
recursos disponveis e define a resposta para o problema do
cliente ou necessidade/oportunidade do mercado.
PR: Maria, voc no acha que toda essa coisa de
gerenciamento de projetos burocratiza muito o nosso trabalho?
MC: Claro que no, Rocha. Voltando ao termo de abertura.
Quando o dono deste restaurante resolveu abri:lo, ele criou um
termo de abertura, mesmo que no tenha utilizado esse nome.
Ao fazer o termo de abertura, com certeza foi feita uma anlise
40

crtica com vistas a identificar algumas caractersticas bsicas do
projeto, para verificar se ele estaria de acordo com os objetivos
de seu dono. O desenvolvimento do termo de abertura do projeto
trata da documentao das necessidades de negcios, da
justificativa do projeto, do entendimento atual das necessidades
do cliente e do novo produto, servio ou resultado que deve
satisfazer esses requisitos.
SB: Oh! Maria, voc falou e no disse nada. Continuo no
fazendo nenhuma ligao do gerenciamento de projetos com a
abertura de um restaurante.
MC: Risos.

2 - Identificao do Projeto
MC: Muito dos nossos sonhos ficam s na nossa cabea, outros
tornam:se grandes idias e transformam:se em projetos. Acho
que foi o que aconteceu com seu amigo, Been. No caso das
41

empresas, as idias surgem muitas das vezes da necessidade de
progresso ou de uma oportunidade de mercado.

MC: Voc parece que no entendeu. Vou melhorar minha
explicao. Ao comear a montagem deste restaurante, seu
amigo colocou suas idias num papel. A primeira coisa que ele
fez foi identificar sua idia, ou melhor, seu projeto.
DS: Maria, veja se eu entendi bem: quando uma organizao
inicia um projeto, ela utiliza um documento de abertura deste
projeto e nele identifica que tipo de projeto ele .
MC: No o tipo de projeto, mas sim o nome deste projeto. Por
exemplo: este restaurante. Quando o amigo do Been o
inaugurou, deu um nome para ele, identificando sua idia. Ento,
quando elaboramos um termo de abertura, primeiro colocamos o
nome do projeto, ou seja, Restaurante Bem Viver. Este nome
para mim j me remete ao estilo de alimentao que o
42

restaurante vai fornecer. o que acontece com os nomes dos
projetos. Eles identificam o projeto.
PR: Muito fcil. E s isso. Colocamos o nome do projeto e est
tudo entendido. At parece.
DS: No seja to ctico, Rocha. Acredito que todos os processos
venham para facilitar nosso trabalho, desde que muito bem
explicado.
MC: Isso mesmo, Delma. E, no caso do Gerenciamento de
Projetos, temos fatos e dados que comprovam isso. Alm do
mais, temos uma metodologia descrita e aprovada em nossa
empresa. Cabe a ns coloc:la em prtica.
SB: Para que mexer em time que est ganhando, Maria? Est to
bem como est!
Todos: Risos
DS: Been, voc muito tranqilo. Maria, mas identificar um
projeto s dar nome a ele e pronto?
MC: Alm do nome, identificamos quem ser o gerente desse
projeto, estabelecemos a justificativa para sua elaborao,
fazemos uma primeira anlise crtica de seus custos e benefcios,
alm de outros itens, de acordo com o Termo de Abertura que a
empresa estabeleceu em sua metodologia.
PR: Estava fcil demais para ser verdade. Eu no disse que isso
tudo burocratiza nosso trabalho?
DS: Pelo que eu estou percebendo, o termo de abertura pode ser
considerado um resumo do projeto.
MC: Um resumo detalhado. Veja o que mais devemos ter neste
termo de abertura.

3 - Meta - objetivo, prazo e valor

SB: Acho que ns hoje s vamos almoar projeto. Vocs no
querem mudar de assunto?
PR: Quero continuar esta conversa Been, pois temos que
aproveitar o conhecimento da Maria nesse papo descontrado.
DS: Muito bem, Rocha. Concordo com voc. melhor
conversamos e tirarmos nossas dvidas aqui, do que dentro da
empresa.
SB: J percebi, sou voto vencido. J que o que no tem remdio,
remediado est,, ento vamos continuar.
MC: Voc sempre brincando. Mas, como eu estava dizendo,
quando iniciamos um projeto, precisamos ter algumas
43

informaes que so muito importantes para o andamento do
mesmo. Um projeto para uma empresa deve ter uma justificativa,
ou seja, necessitamos identificar qual a oportunidade de mercado
precisamos alcanar ou qual fraqueza interna precisamos
minimizar. Dessa forma, assim que justificamos o porqu do
projeto, estabelecemos o seu objetivo, o prazo para sua
execuo e quanto ele vai custar.
PR: De prazo e custo eu entendo bem. Para estabelecermos
prazo e quanto vai custar, no podemos simplesmente colocar no
papel, como um chute.
DS e MC: Claro que no!
PR: Ento precisamos elaborar um estudo de viabilidade a fim de
definirmos prazo e custo para todos os projetos? Estou
comeando a gostar desse assunto.
MC: Depende do tamanho de projeto.
PR: Como que ?
MC: Desculpe, Rocha. Eu no falei direito. Dependendo do tipo do
projeto, apenas um oramento inicial suficiente.
DS: Explique melhor o que so tipos de projeto e sobre custos do
projeto.
MC: OK. Os projetos so muito diversificados, dessa forma existe
a necessidade de que sejam agregados em classes (tipos)
diferenciadas para serem tratados adequadamente, de acordo
com a necessidade de estratgia, gesto, suprimentos,
envolvimento de especialistas, etc.
PR: Mas como so feitos esses agrupamentos?
MC: O Sr. PMI nos apresentou uma lista com esses tipos de
projetos, lembram:se?
SB: Disso eu me lembro. Os projetos podem ser administrativos,
de Pesquisa, de Software, dentre outros.
MC: Muito bem, isto a. Dependendo do tipo de projeto, eles vo
apresentar diferentes necessidades. Os projetos apresentam
sempre um grau de incerteza, necessidade de tecnologia,
possuem prazo e tm um custo. Dessa forma um projeto
administrativo normalmente tem um grau de incerteza e custos
baixos, enquanto um projeto de construo tem grau de incerteza
baixa e custos altos. Vejam este quadro:
44


MC: Para propiciar a escolha do nvel de gerenciamento,
planejamento e controle, alm da documentao a ser utilizada,
classificamos os projetos atravs do mtodo valor versus
complexidade.Os projetos podem variar desde Tipo 1 a Tipo 4,
que significa projetos pequenos, mdios, grandes e muito
grandes. Essa variao depende da metodologia adotada por
cada empresa, alm do tipo de produto e servios prestados.
Dependendo da classificao do projeto, maior a necessidade do
detalhamento de custos. Um projeto administrativo tem a
necessidade de um oramento, enquanto um projeto de um novo
produto necessita de um Estudo de Viabilidade Tcnica e
Econmica, mais conhecido como EVTE. Um estudo de EVTE
aconselhar quanto a prazo, equipe, termos de referncia e
logstica. Informar a natureza e extenso de quaisquer ameaas
ao sucesso do projeto e a extenso e conseqncias do risco.
SB: E a, Rocha, voc bem que poderia nos dar uma aula de
EVTE como a Maria.
45

PR: Aula, eu no sei se sou capaz, mas se vocs quiserem se
aprofundar um pouco sobre esse assunto, tenho um material que
acredito ser de grande ajuda neste novo processo que estamos
trabalhando.
MC: Estou gostando de ver. Voc j est comeando a se
interessar pelo assunto.
PR: Maria, ainda tenho dvidas. Como definir o tipo de projeto?
MC: Boa pergunta. Como voc gosta muito de matemtica, a
definio do tipo de projeto ser uma mdia do grau de
complexidade dos fatores que interferem num projeto.
SB: Como ?!
MC: Calma. Existem fatores que interferem muito, outros pouco e
alguns mais ou menos. Damos peso a essas interferncias e
depois fazemos uma mdia dos valores.
DS: Maria, d-nos mais exemplos.
MC: Certo. Vamos l. Vou citar alguns exemplos de complexidade
que usamos atualmente em nossa empresa.
adequao do prazo de entrega: a presso sobre o tempo
um dos principais aspectos: quanto maior a presso, mais complexo
o projeto. Considerar, na avaliao, o dimensionamento da equipe;
influncias e fatores polticos: restries execuo de um
projeto;
know:how e conhecimento da tecnologia utilizada: quanto
maior a necessidade e diversidade de conhecimento e tecnologias
envolvidas, maior ser o grau de complexidade do projeto;
nmero de clientes envolvidos: quanto maior o nmero de
empresas envolvidas, maiores sero a complexidade e o desafio de
integrao entre as mesmas;
nmero de organizaes envolvidas: quanto maior o nmero
de organizaes envolvidas, maior ser a complexidade e o desafio
de integrao entre as mesmas;
nmero de pessoas da equipe envolvidas na execuo:
quanto maior a equipe executante, maior a complexidade do
projeto;
financiamento: os projetos podem ter financiamento interno,
com recursos prprios das entidades ou financiamento externo de
organizaes. Os projetos com financiamento externo tm
46

prioridade sobre os demais, refletindo:se em uma maior
complexidade;
Visibilidade: grau de visibilidade que esse projeto ter em
relao aos parceiros e clientes;
Aderncia aos objetivos estratgicos: a quais objetivos
estratgicos da instituio esse projeto visa atender;
nvel de interao: grau de interao de empresas associadas
e filiadas a sindicatos envolvidos na execuo do projeto. Quanto
menor a integrao entre as empresas, maior ser a complexidade
do projeto (esse nvel deve ser inferido pelo coordenador do projeto,
baseando:se em seu conhecimento do relacionamento entre as
empresas);
prazo: quanto maior o prazo de desenvolvimento dos projetos,
maior a complexidade dos mesmos. Cada empresa define esse
valor, desta forma temos o seguinte exemplo:
- Muito pequeno: Pouca Complexidade;
- Pequeno: Pouca Complexidade;
- Mdio: Mdia Complexidade
- Grande: Grande Complexidade;
- Muito grande: Grande complexidade
PR: E da, o que fazemos?
MC: Os projetos so classificados conforme seu grau de
complexidade, levando:se em considerao critrios
estabelecidos em uma metodologia. Cada critrio avaliado
como sendo pequena (P), mdia (M) ou alta (A) complexidade; e
recebe, em funo disso, uma pontuao. Com base no valor
mdio da pontuao atribuda aos critrios, define-se um grau de
complexidade A, B ou C para o projeto.
47


SB: Nossa! Agora deu um n na minha cabea.
DS: Se eu estou entendendo bem, esta matriz nos dar a
dimenso do projeto?
MC: Mais ou menos. Na realidade, a dimenso de um projeto ser
determinada confrontando:se, em uma matriz, o valor do
investimento necessrio com a sua complexidade.
Existem quatro dimenses possveis:

- PJ0: Muito pequeno;
- PJ1: Pequeno;
- PJ2: Mdio;
- PJ3: Grande;
- PJ4: Muito grande.
Alguns exemplos de valores e prazos para projetos:
Prazos:
- Muito pequeno: 0 a 2 meses;
- Pequeno: 3 a 4 meses;
48

- Mdio: 5 a 8 meses;
- Grande: 9 a 12 meses;
- Muito grande: acima de 12 meses.
Valores financeiros:
- Muito pequeno: R$ 1,00 a R$ 10.000,00;
- Pequeno: R$ 10.001,00 a R$ 50.000,00;
- Mdio: R$ 50.001,00 a R$ 250.000,00;
- Grande: R$ 250.001,00 a R$ 1.000.000,00;
- Muito grande: acima de R$ 1.000.000,00.

TABELA 2: Classificao: Valores X Grau de Complexidade

DS: No podemos esquecer que essa classificao vai variar de
empresa para empresa.
MC: Isso mesmo. Como eu estava explicando, as empresas que
possuem uma metodologia de gerenciamento de projetos
definem os valores de seus projetos de acordo com o tipo de
produto ou servio prestado.
DS: Objetivo, prazo e valor, posso traduzir esses conceitos como
META de um projeto?
MC: Exatamente. Num termo de abertura, esse item chamado
de Meta do projeto.
49

SB: Oh, Maria, os preos deste cardpio podem ser considerados
como sendo o valor do projeto?
MC: No. Custo aquilo que o dono do restaurante pagou pelos
ingredientes e pela mo-de-obra para confeco dos pratos. J o
preo o que eles nos cobra, ou seja, o custo de produo mais
uma margem de lucro.
PR: Maria, nesse caso o valor do projeto o custo do projeto.
MC: Isso mesmo.
PR: Para calcular o valor do projeto, eu incluo os custos diretos e
indiretos do projeto?
MC: Inclui, sim. Uns dos maiores estouros no oramento do
projeto justamente o esquecimento na hora de elaborar o
detalhamento dos valores e s incluir os custos diretos.
SB: Puxa, eu fiz uma pergunta to simples e vocs complicaram
tudo. Algum pode dizer, ento, como que se calcula o valor de
um projeto?
DS: Pelo que eu entendi o valor do projeto calculado pela soma
dos custos diretos e indiretos.
MC: Todo projeto tem um oramento inicial na sua fase de
concepo. Na fase de planejamento, existe o detalhamento dos
custos, o qual chamamos gerenciamento de custos.
SB: Voc me apertou sem me abraar. Clculo com o Rocha. E
custo, para mim, tudo igual. Eu gosto de escrever. Tudo muito
tranqilo.
Risos
PR: Acho que posso ajuda:lo, Been. Custos diretos so facilmente
identificados e quantificados a partir dos recursos necessrios
para a realizao das atividades. Eles so diretamente atribudos
ao processo e no necessitam de rateio. Por exemplo, no caso
desta refeio, as carnes, os legumes, o tempo da cozinheira so
custos diretos. Custos indiretos so despesas gerais e gastos
incorridos pela empresa em benefcio de mais de um processo.
Normalmente so custos relativos manuteno do negcio.
Aqui no restaurante, a mo-de-obra dos garons representa
custos indiretos.
SB: Puxa, Rocha, voc j est at gostando de projetos!
PR: Estou passando a acreditar que gerenciamento de projetos
no algo to complicado.
MC: E no . Como eu disse antes, temos que estudar, entender
do assunto, conhecer a metodologia adotada pela nossa empresa
e coloc:la em prtica. Os benefcios aparecem com o tempo.
50

DS: Isso verdade. Maria, o Rocha nos deu conceitos de custos
especficos. Eles so os mesmos para os projetos?
MC: So. Explicando com uma linguagem mais de projetos, os
custos diretos normalmente so horas de trabalho, custos de
viagens da equipe, custos dos materiais utilizados no projeto,
dentre outros e os custos indiretos so despesas administrativas
(salrios de tcnicos e administrativos; energia eltrica, telefone),
despesas com tributos e impostos, etc.

4 - Escopo Preliminar

PR: Definidas as metas do projeto, j podemos planejar como
vamos executar o projeto?
DS: Acho que no. Pelo pouco que entendo de gerenciamento de
projetos, o prximo passo definir o escopo do projeto. isso
mesmo, Maria?
MC: Definimos o escopo preliminar.
SB: O que escopo?
MC: Segundo o Guia PMBOK, escopo a soma dos produtos,
servios e resultados a serem fornecidos na forma de projeto.
Temos ainda o conceito de Escopo do Projeto, que o trabalho
a ser realizado para entregar um produto, servio ou resultado
com as caractersticas e funes especificadas. Em outras
palavras, escopo a descrio dos limites do projeto.
Caracteriza:se pela definio do trabalho que ser realizado,
definindo:se os produtos de cada etapa e as atividades
necessrias para sua execuo, e tambm o que no ser feito
dentro da abrangncia, eliminando qualquer expectativa dos
clientes e stakeholders no previstas.
SB: Voc poderia apresentar um exemplo para mim?
MC: Claro. Vou apresentar um exemplo bem simples. Pegue o
cardpio novamente.
51


SB: Peguei. E da?
MC: Observe como ele est distribudo. Voc pode descrev-lo?
SB: Entradas, Prato Principal e Sobremesas.
MC: Podemos descrever esses itens como sendo as metas do
projeto, ou seja, eles tm um objetivo (nesse caso atender
nossos desejos alimentares), tem um preo e um prazo para
ficarem prontos. Em contrapartida, para cada item deste
cardpio, existe uma lista de atividades que devem ser seguidas
para entrega, a qual podemos descrever como escopo.
DS: Gostei dessa comparao. Nunca imaginaria fazer essa
correlao.
PR: Se eu entendi bem, escopo tudo aquilo que precisamos
fazer para que o projeto acontea.
MC: Isso mesmo. Mas devemos lembrar que, na concepo de
um projeto, o escopo preliminar, pois, no detalhamento do
planejamento do projeto, podemos ampliar ou diminuir o escopo
inicialmente definido.
DS: Maria, considerando nossa empresa, que presta servios
para o governo e que est sujeita a algumas regras do governo,
52

como por exemplo, a Lei 8.666 e a Instruo Normativa IN:97,
que impacto isso tem no escopo de um projeto?
MC: No escopo, nada. Esse tipo de regra chamado de
restrio. Normalmente um evento ou limitao que impacta o
projeto e que deve ser contornado. Uma restrio pode causar
um risco no cronograma, mas a restrio em si no um risco.
As restries so fatores que limitam as opes da equipe de
gerenciamento de projetos e que as obrigam a trabalhar de
maneira criativa.
Exemplos de restries:
Um recurso pode no estar disponvel at 30 dias aps o incio
do projeto.
Tecnologia: usar apenas tecnologias em uso na empresa.
Recursos: no sero contratados terceiros.
Oramento: custo restrito.
Data: a inaugurao da obra est marcada.

53


5 - Identificao de riscos

MC: Eu falei em riscos. Vocs sabem me dizer o que so riscos
no projeto?
SB: Acho que nosso maior risco aqui comermos muito e no
darmos conta de voltar para o trabalho.
TODOS: RISOS
SB: Mas, agora sem brincar, para mim risco algo que pode
acontecer e que no temos controle sobre ele.
MC: Muito bom Been. Voc est quase certo. Risco em projetos
corresponde a um evento ou condio incerta que, se
efetivamente ocorrer, pode implicar efeito positivo ou negativo
nos resultados do projeto. Dependendo do risco, podemos
control-lo e at aproveit:lo a nosso favor.
SB: Aproveitar um risco a nosso favor!?
MC: Sim, riscos em projetos incluem tanto oportunidades quanto
obstculos para atingir os resultados de um projeto. Quanto mais
54

cedo identificarmos os riscos na concepo de um projeto, mais
fcil ser gerenci-los.
PR: Voc poderia falar mais sobre a natureza dos riscos?
MC: Rocha, os riscos podem ser de natureza interna e externa.
No caso de riscos externos, no temos controle e tampouco
conseguimos mudar. No caso de riscos internos, dependendo do
risco, podemos control-lo e at influenci-lo. Mas vamos
conversar sobre isso mais tarde. Estou ficando com fome. Vamos
comer um pouquinho?

6 - Stakeholders

DS: Nossa, a comida deste restaurante realmente muito boa.
Seu amigo superou minhas expectativas. D os parabns a ele
por mim, Been.
PR: Acho que superou todos ns.
MC: Concordo com vocs. Ns, como stakeholders deste projeto,
estamos muito satisfeitos com o resultado alcanado.
DS: Stakeholders no so os patrocinadores do projeto?
55

MC: Tambm. Stakeholders so pessoas, rgos, entidades ou
empresas interessadas nos resultados do projeto. Podem estar
diretamente envolvidos com o Projeto ou podem ter seus
interesses afetados positiva ou negativamente em decorrncia da
execuo ou concluso do Projeto. Os Stakeholders podem
influenciar o Projeto, bem como os seus resultados.
PR: Ento somos Stakeholders Clientes?
MC: E tambm usurios finais.
SB: Quais so os principais stakeholders?
DS: Muito bem, Been, voc j est comeando a se interessar
pelo assunto. Acho que essa resposta eu sei. Principais
Stakeholders so: Sponsor (que que paga pelo projeto), o
Gerente de Projeto, os clientes (indivduo ou organizao que
adquiriu os produtos gerados pelo projeto), a Organizao
executora (entidade responsvel pela execuo do projeto), a
equipe do projeto, os Fornecedores e os usurios finais que so
os indivduos ou organizao que faro uso dos produtos.
MC: Isso mesmo. Esta nossa conversa est sendo muita boa.
Acredito que assim a utilizao do Gerenciamento de Projetos
ser muito prazerosa e nos trar muitos resultados.
DS: Tambm acho. E vocs, rapazes, o que acham?
PR: Estou comeando a entender o assunto e acho que poderei
contribuir neste processo, mas ainda no sei se saberei utilizar
este gerenciamento de projetos.
SB: Sei no. Deixe:me conhecer um pouco mais para eu ver
como posso contribuir e saber como utilizar o gerenciamento de
projetos. Vamos continuar almoando.

Desenvolvimento de Projetos: Planejamento
56


No Restaurante

SB: Que comida boa! O tempero est muito suave.
DS: Concordo com voc. No deve ser fcil elaborar um cardpio
to variado e to saboroso.
MC: Seu amigo Been deve ter uma boa estrutura e bom
planejamento para que tudo d certo.
DS: Este planejamento pode ser comparado com o planejamento
de um projeto?
PR: Maria, voc poderia nos explicar melhor?
MC: claro. Vamos assentar, que durante o almoo eu explico.

Plano de gerenciamento de projetos

MC: Eu acredito que tudo que fazemos, seja no trabalho, seja na
nossa vida pessoal, depende de um bom planejamento. No caso
57

do gerenciamento de projetos, temos algumas etapas e
procedimentos que so especficas.
PR: E quais seriam essas fases?
MC: Lembra-se da nossa conversa quando estvamos vindo para
c?
PR: Sobre as fases do ciclo de vida?
DS: No s sobre o ciclo de vida, mas tambm dos processos que
compem cada fase.
MC: Isso mesmo. Todo projeto tem um ciclo de vida com suas
respectivas fases e processos. Dessa forma temos o que
chamamos Plano do Projeto.
PR: L vem voc novamente com mais informao.
DS: Calma, Rocha. Deixa a Maria explicar.
MC: Risos. Como estava dizendo, um dos maiores benefcios de
uma metodologia de gerenciamento de projetos ter definido o
conjunto de normas e mtodos, tcnicas, modelos e ferramentas
para desenvolvimento de projetos. Assim, o Plano do Projeto faz
parte desse conjunto.
DS: Mas como composto o Plano do Projeto?
MC: Ele um documento composto basicamente por vrios
planos auxiliares e especficos de reas de conhecimento, que
so:
- o Plano Organizacional;
- o Oramento de Custo;
- o Plano da Qualidade;
- o Plano de Comunicao;
- o Planejamento de Suprimentos;
- Plano de Resposta aos Riscos;
- e o Cronograma de Execuo.
O plano inclui as aes para definir, coordenar e integrar todos os
planos auxiliares de trabalho definidos para o projeto.
DS: Podemos dizer que o plano define como o projeto
elaborado, monitorado, controlado e encerrado?
MC: Sim. Podemos.
PR: Maria, voc poderia nos explicar o que significa cada um
deles?
MC: Posso tentar.
SB: No seja modesta, Maria. Voc tem nos ajudado muito com
seu conhecimento. Estou comeando at a me interessar pelo
assunto.
58

DS: Comeando Been!? Acredito que esse processo um
caminho sem volta.
SB: Caminho sem volta!? Que papo mais fnebre esse, Delma?
DS: Voc no leva jeito mesmo. S estou querendo dizer que
esse processo muito importante para ns e que, ao
trabalharmos com uma metodologia de Gerenciamento de
Projetos, no temos como voltar para os nossos controles
separados.
SB: Ah bom. Assim est melhor.
PR: Been, deixa a Maria explicar.
MC: Vou tentar explicar o plano de projeto deste restaurante,
alis, o que imagino que foi. O que vocs acham?
TODOS: Boa idia.
MC: Been, qual o nome do dono deste restaurante?
SB: Luiz Otvio.
MC: Muito bem, vamos l. Como eu disse no incio do nosso
almoo, o primeiro passo idealizar o projeto, estruturando as
idias e analisando sua viabilidade. O Luiz Otvio idealizou o
restaurante, montou o projeto analisando as oportunidades e
ameaas, bem como sua viabilidade.
SB: Pelo jeito, o projeto do restaurante foi considerado vivel,
caso contrrio no estaramos aqui.
MC: Isso mesmo.
PR: Prximo passo.

1 Plano Organizacional
MC: O prximo passo a Elaborao do Plano Organizacional.
DS: Com esse nome, mais parece um plano para montar uma
empresa!
MC: mais ou menos isto. Na realidade, o Plano Organizacional
define a estrutura de organizao, gesto e a equipe executora
do projeto. No caso da montagem do restaurante, o Luiz Otvio
teve que contar com uma equipe de engenheiro, arquiteto,
marceneiro, eletricista, mestre de obra, dentre outros.
DS: A julgar pelo ambiente, ele tambm contou com uma
decoradora no seu Plano Organizacional.
PR: s isso o Plano Organizacional? Voc relaciona as pessoas
das quais voc precisa para executar seu projeto?
MC: Quando iniciamos o projeto, j apresentamos, no nosso
Termo de Abertura, quais profissionais de que necessitamos; e,
quando elaboramos o Plano, j colocamos os nomes das
59

pessoas ou empresas que iro executar o projeto bem como a
relao de hierarquia entre elas.
DS: Mas s isso?
MC: No caso do restaurante sim, pois uma empresa nova.
Podemos dizer que o primeiro projeto dessa empresa.

1.1 Equipe de Projeto

SB: Mas, no caso da empresa, fazemos da mesma forma?
MC: No caso da nossa empresa, temos mais alguns detalhes.
SB: Fico s com o restaurante, falou!?
DS: No vou complicar. Segundo o Guia PMBOK, planejar
recursos humanos significa determinar funes,
responsabilidades e relaes hierrquicas do projeto, tanto em
relao s pessoas quanto aos grupos internos ou externos
organizao executora do projeto. Significa, ainda, incluir
informaes de como e quando os membros da equipe do projeto
sero contratados ou mobilizados, critrios para sua liberao do
projeto, identificao das necessidades de treinamento e
identificao das necessidades de mudana na Organizao
relativas implantao do projeto.
PR: No to simples assim. Voc pode explicar melhor?
MC: Vamos voltar metodologia. Tudo o que eu acabei de falar j
est definido na metodologia adotada pela empresa. E,
relembrando, todo projeto deve ser elaborado tendo como
objetivo a coerncia com os objetivos estratgicos da empresa.
DS: Maria, voltando apresentao do Sr. PMI, um projeto
quase sempre multifuncional. Isso significa que, ao elaborarmos
um Plano Organizacional, teremos pessoas de vrias reas e at
equipe externa, caso no tenhamos profissional dentro da
empresa?
60


1.2 Capacitao
MC: Isso mesmo, Delma. E, em alguns casos, para execuo do
projeto, profissionais da casa precisam de treinamentos mais
especficos para a execuo de algumas tarefas.
PR: Mas, se precisam de treinamento, no mais fcil contratar
um profissional que j sabe?
MC: Nem sempre. Pense no seu caso. Voc um expert na rea
financeira, mas tem pouco conhecimento no mercado de capitais.
melhor para a empresa trein-lo e ter o conhecimento na casa,
do que fazer uma contratao temporria.
PR: No pensei por esse lado.
MC: Assim, quando a empresa identifica as necessidades de
capacitao da equipe, ela elabora um plano de treinamento.
SB: E essa idia de mudana, o que significa isso?

61

1.3 Gesto da Mudana

MC: Muitos projetos impactam diretamente no processo de uma
empresa. Por exemplo, a implantao de um software de gesto,
tipo ERP.
SB: Muitas pessoas perdem o emprego.
DS: Claro que no.
PR: Maria, agora ficou mais clara sua explicao anterior.

PR: Quando implantamos o ERP na empresa, fui convidado a
participar da equipe de implantao por causa dos meus
conhecimentos em finanas, mesmo no trabalhando diretamente
no financeiro ou na contabilidade.
SB: Eu me lembro disso. O software de ERP foi um projeto?
MC: Foi. E um projeto muito bem planejado. Voc lembrou bem,
Rocha. A equipe montada para o projeto ERP tinha o
conhecimento de que a empresa precisava, mas no dominava o
software. Nesse caso, houve o treinamento especfico. Alm
disso, foi estruturado um plano de mudanas.
DS: Esse plano constava de toda a parte de informao sobre o
andamento do projeto e os impactos que ele tinha em cada rea.
Foram apresentados todos os benefcios e a readequao de
62

todo o quadro de pessoal. Foram observados os tempos de
transio e concluso de cada etapa, sem prejudicar o
andamento dos trabalhos e sem rdio peo entre os corredores.
PR: Este foi um projeto de sucesso. Olha que eu no considerava
que j tinha participado de um projeto e que fui til.
DS: Viu como as peas se encaixam quando temos os conceitos
certos?
MC: Isto mesmo. Se voc quiser aprofundar seus conhecimentos,
sugiro, ainda, a leitura do texto Gesto das Transies.
Vou desenhar para vocs um modelo de Plano Organizacional.

63

2 Planejamento de Escopo

SB: Muito bom. Fizemos o Plano Organizacional. Qual o prximo
passo?
MC: Detalhar o Escopo Preliminar, ou melhor dizendo, definir
como o trabalho precisa ser desenvolvido para garantir a entrega
de um determinado produto dentro de todas as suas
especificaes e funes.
SB: Mas j no fizemos isso antes?
MC: No processo de iniciao, apresentamos um escopo
preliminar. Esse escopo serve de base para futuras decises do
projeto, incluindo os critrios que avaliaro se o projeto, ou fase
dele, foi contemplado com sucesso.
DS: Podemos dizer, ento, que agora, com o planejamento do
escopo, determinaremos os limites do trabalho no projeto?
MC: Isto mesmo. A esses limites, chamamos de entrega. As
entregas so definidas no incio do projeto e aceitas/aprovadas
no final do projeto. Tornam-se marcos quando possuem uma
caracterstica de deciso importante.
PR: No entendi bem. Explique melhor.
MC: O objetivo fundamental deste planejamento deve ser o de
prover uma orientao consistente e realista a respeito do que
deve ser gerado pelo projeto e de como isso deve ser executado
e controlado. Segundo o Guia PMBOK os principais
componentes deste planejamento so:
1 Roteiro de preparao de uma declarao detalhada do escopo
de projeto, bem como o tratamento de suas mudanas;
2 Procedimentos para a construo da estrutura analtica de
projeto (EAP) com as respectivas regras para sua aprovao e
manuteno ao longo do empreendimento;
3 Regras sobre a aceitao formal dos entregveis, em um
formulrio-padro, por exemplo.

PR: O que estrutura analtica? Para que serve?
SB: Temos formulrio-padro?
MC: Calma. Vou responder uma questo de cada vez. Formulrio-
padro o que chamamos de termo de abertura. Ele consta da
nossa metodologia. Cada empresa adota um nome. Pode ser
Project Charter ou Anlise Crtica da Demanda. Lembram-se do
que eu disse sobre termo de abertura? (O desenvolvimento do
termo de abertura do projeto trata da documentao das
64

necessidades de negcios, da justificativa do projeto, do
entendimento atual das necessidades do cliente e do novo
produto, servio ou resultado que deve satisfazer esses requisitos
tratar como pensamento dos participantes). Ento, trata-se de
um documento essencial para o projeto e para o planejamento do
escopo, em particular nos estgios iniciais do empreendimento,
pois consolida informaes-chave para suporte deciso sob
nveis mais elevados de incerteza que caracterizam o incio dos
projetos.
DS: Como a Maria j disse, ele a formalizao do projeto.
MC: Isto mesmo. Continuando. Estrutura Analtica do Projeto
(EAP) a expresso em portugus para WBS (Work Breakdown
Structure). Segundo o Guia PMBOK, ela representa uma
decomposio hierrquica orientada entrega do trabalho a ser
executada pela equipe do projeto para atingir os objetivos do
projeto e criar as entregas necessrias.
SB: E da?
MC: EAP pode ser definido como:
um agrupamento de elementos do projeto, orientados a
produtos, que organiza e define o escopo total do trabalho;
1 uma representao grfica da hierarquia do projeto;
2 identificao de todo o trabalho a ser executado: trabalho que
no est no WBS no faz parte do Escopo do Projeto;
3 a base a partir da qual o projeto construdo;
4 reflexo das pessoas sobre todos os aspectos do projeto.
Alm disso, uma EAP construda pode ser reutilizada em outros
projetos.

DS: Isto muito bom. S no podemos esquecer que todos os
processos precisam ser documentados e registrados. S assim
poderemos aprender com os acertos e com os erros tambm.
PR: Quais os benefcios desta EAP?
MC: So vrios. Vou citar quais so:
1 Ajuda a prevenir que o trabalho se perca nos detalhes;
2 D equipe do projeto uma compreenso de como cada uma
das partes se encaixa no todo do projeto e o impacto do trabalho
de cada um no todo do projeto;
3 Facilita as comunicaes e cooperao entre os membros da
equipe e demais stakeholders;
65

4 Ajuda a prevenir mudanas;
5 Focaliza a experincia da equipe naquilo que precisa ser feito,
implicando um projeto de maior qualidade;
6 Promove uma base para dimensionamento da equipe,
oramento de custo e prazos;
7 Permite provar as necessidades de pessoal, custo e prazos;
8 Ajuda no comprometimento e desenvolvimento da equipe;
9 Ajuda a equipe focar seu pensamento no projeto;
10 Ajuda os membros da equipe perceber seus papis.

SB: Tudo isto!?
MC: E melhor, Been, ele visual. Parece um organograma.
SB: Agora voc falou minha lngua.
MC: Como parece com um organograma, a EAP possui nveis.
Assim temos:
1 Primeiro nvel: o projeto;
2 Segundo / terceiro nveis: estratgia de execuo;
3 ltimo nvel: tarefas do trabalho
Atividades para elaborao de produtos do projeto (entregas);
Possui um responsvel pela execuo;
Pode possuir limitaes de prazo e custo;
A partir do ltimo nvel so criadas as tarefas do cronograma.
Aps definida EAP, importante que todos os pacotes de
trabalho sejam estratificados em suas atividades, ou tarefas, que
podem ser chamados tambm de nvel de esforo.

MODELO DE UMA EAP

66

Cronograma de Execuo

MC: O nosso prximo passo estabelecer o cronograma de
execuo do projeto. J definimos o Plano Organizacional e a
seqncia das atividades; agora hora de juntar as partes e
elaborar o cronograma do projeto.
DS: Determinar a programao de um projeto no uma
atividade simples?
MC: Na verdade, no. Elaborar um cronograma requer uma
combinao de arte e cincia.
DS: Eu entendo que o principal objetivo desse cronograma
garantir que o projeto seja concludo dentro do prazo
determinado.
MC: o nosso desafio. Sabemos que o tempo no pra. O
cronograma do projeto sempre uma restrio, at mesmo
quando a data de trmino no crtica. Se um projeto atrasa, na
67

maioria das vezes ele ir consumir um capital que ele no tinha
previsto, comprometendo, tambm, o seu custo, podendo at
mesmo causar srias conseqncias mercadolgicas para o
produto, ou servio, do projeto.
SB: Lembro-me de o meu amigo Luiz Otvio dizer que ele
estabeleceu prazo para execuo da obra do restaurante de
acordo com o projeto arquitetnico, sem estabelecer nenhuma
folga. No entanto, ao iniciar as obras, ele viu que o prazo no era
suficiente e, para no comprometer todo o cronograma, acabou
contratando mais pessoas. Com isso gastou mais dinheiro.
PR: Este foi um bom exemplo. Maria, como estabelecer um
cronograma?
MC: Lembra-se de que eu acabei de falar da estratificao das
atividades?
PR: Lembro. Mas o que so atividades?
MC: Bem. Atividades so etapas necessrias para se contemplar
um projeto. So executadas em uma seqncia caracterizada
pela natureza do projeto. As atividades podem ocorrer
seqencialmente, ou simultaneamente.
PR: Est bem e da? Continuo sem entender!
MC: O projeto vai sendo decomposto at que todas as etapas e
entregas sejam atingidas. Os principais tipos de atividades so:
1 Atividades Executivas, que so aquelas relacionadas
diretamente com a ao dentro do projeto. Exemplo: embalar
computadores; limpar o terreno; digitar o relatrio de compras;
2 Marcos, que representam um evento, ou condio, que
determina a execuo de um grupo de atividades relacionadas
entre si, ou o trmino de uma fase de projeto.
Servem tambm para identificar as entregas dos pacotes de
trabalho e no possuem durao. So tambm chamados de
etapa. Como exemplo de marcos, temos: telhado pronto
(entrega); testes do produto realizados; recebimento da 3
parcela.
O terceiro e ltimo tipo so as Atividades-Resumo. So
atividades que englobam outras atividades, denominadas
68

subatividades. Elas representam um conjunto de atividades,
totalizando durao, datas e custos das atividades a elas
pertencentes.
PR: Mas como se desenvolve o cronograma?
MC: O desenvolvimento do cronograma deve ser feito
iterativamente, ou seja, ser elaborado de forma progressiva e
repetida at o momento em que seus resultados sejam confiveis
e possam atender aos objetivos do projeto.
Assim, neste desenvolvimento, estabelecemos as datas de incio
e trmino das atividades. Esse processo um dos mais
importantes de toda a fase de planejamento, uma vez que
consolida informaes de outras reas, tais como custo, recursos
humanos e escopo. O nivelamento de recursos uma das
ferramentas utilizadas.
DS: Mas como estimar a durao das atividades?
MC: Segundo o Guia PMBOK, estimar a durao das atividades
obter avaliaes quantitativas do nmero provvel de perodos
de trabalho necessrios para a concluso de uma atividade do
cronograma.
Para elaborao de um cronograma, necessrio o
desdobramento das atividades, como acabamos de falar na
explicao da EAP. Uma das questes mais ignoradas na
elaborao do cronograma relativa quelas datas que esto
amarradas a determinadas situaes. Por exemplo, para o Luiz
Otvio mobiliar o restaurante, ele precisou aguardar a concluso
da obra. Ele simplesmente no pode colocar os mveis sem que
antes tudo estivesse pronto.
Outras consideraes incluem saber quais os recursos sero
utilizados, sua disponibilidade (calendrios) e experincias
vivenciadas em outros projetos similares.
SB: Como estabelecemos a durao das atividades?
MC: Boa pergunta. A durao de uma atividade o tempo
necessrio para que a atividade possa ser realizada. Esse tempo
pode ser estipulado em semanas, dias, horas e minutos,
dependendo do tamanho de cada projeto.
69

Essa etapa tem por objetivo calcular ou determinar, corretamente,
a quantidade de tempo necessria para executar cada atividade
para que, ao ser integrante de um cronograma, possa determinar
a durao do projeto. Ela conduzida em paralelo alocao de
recursos nas atividades, uma vez que existe uma dependncia
intrnseca entre durao e quantidade de recursos.
DS: Por que as estimativas variam tanto?
MC: Porque desconhecemos quais fatores influenciaro a
durao. Ento no possvel saber exatamente quanto tempo
ser consumido.
Outro fato importante que muitas vezes, ao elaborarmos um
cronograma, no envolvemos quem ir executar a tarefa.
DS: Voc est dizendo que quem dever preparar as estimativas
so as pessoas que executam as atividades?
MC: Exatamente. Quem sabe o tempo quem faz.
PR: Realmente uma etapa bem difcil.
MC: Apesar de ser difcil, o envolvimento da equipe do projeto
desde a concepo fundamental para o sucesso.
PR: Voc falou que os prazos das atividades esto amarrados.
Explique um pouco melhor.
MC: Est certo. Acho que empolguei um pouco e acabei pulando
uma explicao fundamental nesta fase.
Quando disse que as atividades esto inter-relacionadas, estava
tentando explicar que temos de estabelecer precedentes para
que atividades interdependentes sejam identificadas e o
cronograma do projeto seja determinado.
DS: Maria, li alguma coisa sobre isso. Veja se entendi
corretamente: Uma atividade que comece ou finalize antes que
outra atividade possa comear chamada predecessora. Uma
atividade que dependa do incio ou do final de outra atividade
chamada de sucessora.
MC: Isto mesmo.
SB: E como definimos esta relao de amor dio?
70

DS: Amor e dio por sua conta.
RISOS
MC: necessrio estabelecermos alguns parmetros
importantes. So eles:
Data de incio do projeto: o primeiro dia da primeira
atividade a ser desenvolvida. Normalmente essa data definida
quando apresentamos a proposta do projeto, ou seja, juntamente
com o objetivo do projeto.
Data de trmino do Projeto o ltimo dia da ltima atividade
a ser desenvolvida. Normalmente calculada pelo detalhamento do
plano do projeto.
Incio da atividade a data e a hora em que a atividade se
inicia. Pode ser um dado fixo do projeto ou calculada em
conseqncia de suas atividades predecessoras.
Trmino da Atividade a data e a hora em que atividade
termina. Normalmente, calculada a partir da data de incio da
atividade e de sua durao.
Calendrios os calendrios so utilizados para determinar e
selecionar os dias de trabalho, ou folga, do projeto. Os calendrios
tambm devem ser utilizados para indicar horas especficas de
trabalho para um determinado recurso.
Feriados e Dias Especiais Devem ser sempre inseridos para
que no ocorram erros no gerenciamento das atividades. Por
exemplo, frias coletivas, feriados municipais, vspera de Natal e
Ano Novo, dentre outros.
DS: E frias dos participantes dos projetos?
MC: Boa lembrana. Um projeto pode ter datas especiais para
diferentes participantes do projeto, de acordo com cronograma de
frias de cada um.
SB: Existe alguma forma visual de montar um cronograma, ou
basta detalhar no papel?
MC: Voc pode apenas detalhar no papel, no entanto, temos hoje
o que chamamos de diagrama de Gantt.
SB: Muito prazer, Sr. Gantt, eu sou o Sr. Been.
71

MC: No brinque! Diagrama de Gantt, ou diagrama de barras,
hoje a forma mais utilizada para representao grfica de um
cronograma.
O diagrama utiliza barras horizontais, colocadas dentro de uma
escala de tempo. O comprimento relativo das barras determina a
durao da atividade. As linhas conectando as barras individuais
em um diagrama de Gantt refletem as relaes entre as
atividades.
DS: O Diagrama de Gantt j foi desenvolvido em software?
MC: Sim. O Diagrama de Gantt a visualizao-padro da
maioria dos softwares de gerenciamento de projetos.
PR: O software facilita a elaborao do cronograma!
MC: Facilita no, ajuda e muito. Mas temos de lembrar que temos
uma metodologia, e ela quem facilita o nosso trabalho. O
software apenas uma ferramenta que nos auxilia na construo
do cronograma.

Oramento de Custos
SB: E agora, o que fazemos?
MC: O prximo passo saber quanto custa o nosso projeto.
PR: Mas isto eu j sei. Fizemos o estudo de viabilidade ou
oramento inicial.
MC: Vamos voltar ao exemplo deste restaurante. O Luiz Otvio
elaborou o projeto e fez o estudo de viabilidade. Os valores
projetados foram transportados para o plano oramento do
projeto.
PR: O que fazemos agora ento detalhar os valores iniciais, de
acordo com as necessidades de gasto do projeto?
MC: Segundo Ricardo Vargas, a oramentao do projeto o
processo que envolve a alocao das estimativas de custos a
cada item de trabalho, de modo a estabelecer uma linha de base
de custos para medir a performance do projeto. Nesse processo,
o fluxo de caixa do projeto determinado.
DS: Trocando em midos, fizemos uma estimativa inicial de
quanto seria o nosso projeto. Agora iremos detalhar os valores
agregando-os por rubrica e o cronograma de desembolso?
MC: Isso mesmo.
SB: J falei que nmeros no so a minha praia. Vocs podem
me explicar em bom portugus?
72

MC: Desculpe, Been. Vou explicar melhor. Rubricas so contas,
ou grupo de contas.
Desta forma, ao elaborarmos o oramento do projeto, iremos
detalh-lo da seguinte forma:
Salrios, Adicionais e Encargos e Benefcios.
Infraestrutura
Materiais de Consumo
Despesas de Viagens
Servios 3 Pessoa Jurdica
Comunicao e Marketing
Servios 3 Pessoa Fsica
Bolsistas e Estagirios
Despesas Financeiras
Impostos, Taxas e Contribuies
Despesas Operacionais
Investimentos
SB: O que esto dentro destes grupos e como podemos calcular
esses valores?

MC: Been, vou lhe mostrar alguns exemplos. Vamos relembrar. J
elaboramos o plano organizacional, detalhamos o escopo e
elaboramos o cronograma de execuo. Cada etapa tem um
valor a ser gasto, desta forma temos:
1) Reforma do Espao
Execuo de projeto arquitetnico
Contratao de projetos complementares juntamente com a obra
Fiscalizao da Obra
Recebimento da Obra
2) Compra de equipamentos
No vou entrar no detalhe, pois no conheo o projeto, apenas
listei alguns itens que poderiam compor o escopo do projeto.
Portanto:
Para reforma do Espao, existe a necessidade de contratao do
arquiteto (lembramse, est no plano organizacional e faz parte da
equipe). Ele ir calcular o valor do projeto arquitetnico da
seguinte forma:
Contratao de servios de terceiros:
Obs.: ele pode pagar por hora trabalhada ou pelo valor do projeto
fechado. Neste caso, irei apresentar o clculo por hora:
73

Been, voc sabe quanto tempo durou a obra deste restaurante?
SB: Aproximadamente uns quatro meses, entre o incio das obras
e a inaugurao.
MC: OK. Ento, como exemplo:
Premissas da contratao:
Tempo: 3 meses, 4h/dia, 3 dias/semana
Valor da hora: R$ 120,00 (j includos os valores com encargos e
tributos, pois contratao de terceiros)
Total a ser pago:
R$ 120,00 x 4 x 3 x 4,5 x 3 = R$ 19.440,00
Para compra de equipamentos, temos:
Investimentos (bens durveis)

At o momento, o valor do oramento do Luiz Otvio :
SERVIOS DE 3 - PJ = R$ 19.440,00
INVESTIMENTOS = R$ 8.630,00
DS: Boa parte dos nossos projetos envolve viagens, dessa forma,
ao elaborarmos o nosso oramento, podemos considerar:
passagens, hospedagem, alimentao e locomoo.
MC: Isso mesmo.
PR: Deixe-me calcular no papel para ver se eu entendi.
Premissas:
74

Durao da viagem: 3 dias
Passagem: R$ 800,00 (ida e volta)
Locomoo: R$ 80,00/dia
Alimentao: R$ 80,00/dia
Hospedagem: R$ 150,00/diria
Total de despesas de viagem:
R$ 800,00 + (3 x 80) + (3 x 80) + (2 x 150) = R$ 1.580,00
MC: Muito bem. Temos de lembrar que os valores do oramento
devero ser coerentes com os objetivos do projeto. Lembrem-se
tambm dos custos indiretos, que muitas vezes so valores
econmicos, como, por exemplo, o custo de um telefonema, as
horas da equipe administrativa.
DS: Maria, voc j falou, mas no custa reforar. Muitos dos
estouros dos oramentos dos projetos esto associados ao
fracasso da estimativa dos custos indiretos e administrativos do
projeto.
MC: Segundo Ricardo Vargas, importante que se atente aos
seguintes fatores:
1 qualquer estimativa de custos deve vir acompanhada por sua
memria de clculo;
2 banco de dados comerciais sempre podem ser utilizados na
estimativa de recursos e custos, bem como os registros obtidos
em projetos anteriores;
3 muitas empresas patrocinam seus projetos, mesmo com os
custos no sendo recuperados, porque tm interesse em atingir
uma meta de longo prazo para a organizao; e
4 a forma de identificar o nvel de recursos necessrios, quando
eles estaro disponveis e quem so os seus responsveis, vital
para todo o processo de estimativas de custos e oramentao.

DS: Mas, Maria, so muitas informaes. Confesso que j estou
ficando preocupada se daremos conta de elaborar tudo isto e
tambm de acompanhar.
PR: Puxa, achei que o medo era s meu.
MC: A principio, tudo parece difcil. Eu acabei de comentar sobre a
gesto da mudana. E isto que estamos fazendo, uma
mudana no nosso processo. E a nossa empresa est
trabalhando a gesto da mudana.
PR: Est certa, Maria. S agora estou me dando conta disso. Na
implantao do ERP foi assim e agora, com o Gerenciamento de
75

Projetos, tambm est sendo. Ainda bem que temos voc, assim
a transio fica mais fcil.
DS: Concordo com voc.
SB: Quando ser que este novo processo vai me interessar?
MC: Acho que, a partir de agora, voc vai poder contribuir muito,
Been.

Plano da Qualidade
SB: Oba! O que vem agora?
MC: Qualidade do Projeto!
SB: Esse assunto me interessa.
MC: No adianta estabelecermos metas se no acompanharmos.
O prximo passo no planejamento de um projeto o plano de
qualidade.
SB: Significa que iremos trabalhar com indicadores?
MC: Exatamente. O Planejamento da Qualidade do projeto
caracteriza-se pela definio dos indicadores que devero ser
monitorados, a freqncia e a forma de medio.
SB: O Plano de Qualidade trabalha, ento, com Gesto Vista,
Grfico de Desempenho?
DS: Puxa, at que enfim alguma coisa lhe chamou a ateno!
SB: Sou muito visual. Nmeros, nmeros e mais nmeros
embaralham a minha vista. Gosto de ver cores.
PR: O conceito de qualidade total o mesmo para qualidade em
projetos?
MC: O objetivo o mesmo. O mais importante dessa rea
garantir que o projeto ser concludo dentro da qualidade
desejada, com a satisfao das necessidades de todos os
envolvidos.
SB: Acho que posso contribuir.
MC: Vamos l.
SB: A qualidade envolve inmeras dimenses. Mas acredito que
duas so fundamentais para o Gerenciamento de Projetos:
Fazer correto desde o incio. Neste caso o planejamento inicial e
fundamental. O gerenciamento da qualidade garante que cada
ao seja desenvolvida corretamente na primeira vez. O
processo de correo vrias vezes mais caro que o processo
de planejamento.
Satisfao do cliente. Aqui existe a necessidade de garantir que
o produto ou servio seja transferido para o cliente de maneira
correta.
76

MC: Obrigada pelas informaes. muito importante o
envolvimento de todos no processo de gerenciamento de
projetos. como venho dizendo o tempo todo: cada um tem uma
qualidade que pode contribuir para todo o processo.
DS: Existem indicadores fixos?
MC: Sim. Existem dois tipos de indicadores:
1 Bsicos: normalmente estabelecidos na Metodologia de
Gerenciamento de Projetos para custo, prazo, esforo.
2 Especficos: definidos pelo gerente/coordenador e dirigidos aos
produtos, considerando suas caractersticas tcnicas.

SB: Podemos dizer que o Plano de gerenciamento da qualidade
descreve como a equipe de gerenciamento de projetos
implementar a poltica de qualidade da organizao executora.
Desta forma, este plano faz parte de ou um plano auxiliar do
plano de gerenciamento do projeto. Pode ser formal ou informal,
bem detalhado ou genrico, dependendo dos requisitos do
projeto.

MC: Isto mesmo. Estou gostando de ver seu interesse.
PR e DS: Ns tambm.

Plano de Comunicao
SB: Algum quer sobremesa?
MC: Eu quero. Adoro doce.
DS: Saiu no jornal uma reportagem sobre as delcias das
sobremesas ligths elaboradas por este restaurante. Eu tambm
quero conhecer.
MC: J que estamos falando de reportagem, vamos falar um
pouco de comunicao?
SB: Comunicao em projetos?
MC: Gerenciamento das comunicaes. Nossa prxima etapa.
DS: H uma frase de David I. Cleland, que diz: A grande maioria
dos atritos, frustraes e ineficincias em nossas relaes com
as outras pessoas causada pela pobreza nas comunicaes
MC: Segundo o Guia PMBOK, o gerenciamento das
comunicaes subdivide em quatro processos: o Planejamento
das Comunicaes, a Distribuio de Informaes, os Relatrios
de Desempenho ou Performance e o Gerenciamento das Partes
Interessadas.
77

Ainda, segundo o Guia, o Planejamento da Comunicao o
processo onde ser determinada a necessidade de informaes
de cada parte interessada do projeto, bem como o modo como
essa informao ser levada ao mesmo e qual o seu nvel do
detalhe.
SB: Posso dizer, ento, que o Plano de Comunicao estabelece
os meios e instrumentos para a comunicao de dados e
informaes do projeto, de acordo com as necessidades dos
stakeholders.
DS: E quais seriam esses meios e instrumentos?
MC: Os meios podem ser mediante correspondncias (e-mails,
cartas, fax), mdia impressa (encartes, releases, notas e matrias
jornalsticas), mdia eletrnica (intranet, sistema de informao) e
os seguintes relatrios (Progresso, Desempenho, Executivo,
Divulgao e grficos de gesto a vista). E atravs de eventos.
Os eventos de comunicao so as reunies realizadas entre os
envolvidos, como por exemplo: Kick-off; Acompanhamento de
progresso; Reunio de encerramento.
PR: Quais os propsitos de um plano de comunicao?
MC: O desenvolvimento de um plano de comunicao eficaz deve
ter em mente atingir os seguintes propsitos:
1 Assegurar que as informaes importantes cheguem s partes
corretas nos prazos adequados;
2 Apontar e identificar problemas potenciais, por meio de reportes
de andamento programados e consistentes;
3 Gerar entusiasmo e empolgao com o projeto;
4 Facilitar a tomada de deciso e o controle de mudanas;
5 Oferecer um processo especfico para feedback e resoluo de
conflitos;
6 Melhorar e facilitar o trabalho em equipe, a cooperao e
colaborao.

DS: Maria, voc poderia explicar um pouco mais sobre os eventos
e tambm quais aspectos temos que observar ao elaborarmos
um plano de comunicao?
MC: Os Planos de Comunicao podem variar de acordo com a
complexidade, tamanho e durao do projeto, mas, de qualquer
forma, preciso observar os seguintes aspectos:
1 Propsito: os objetivos da comunicao do projeto, sendo esse
propsito formal ou informal;
78

2 Mtodos: os mecanismos e formatos da comunicao no
projeto;
3 Freqncia: o momento (data e evento) e a freqncia das
atividades formais de comunicao.
Sobre os eventos, posso dizer:
o Reunio de Partida (kick-off meeting): essa reunio formaliza
e d incio de fato ao projeto, justificando-se pelos seguintes
motivos: impe o planejamento no incio do ciclo de vida do projeto,
ajuda na formao de consenso, estimula engajamento e integrao
da equipe e, principalmente, ajuda a quebrar a inrcia que sempre
ocorre no comeo do projeto.
o Reunio de Acompanhamento: essa reunio usada para
acompanhar e verificar o andamento do mesmo, e ocorre
periodicamente com a freqncia combinada, acontecendo tambm
reunies de emergncia, sempre que um fato ou acontecimento
assim o justificar.
o Reunio de Encerramento ou de Entrega do Projeto: essa
reunio caracteriza e formaliza o fim do projeto bem como todo o
envolvimento do gerente e sua equipe com o mesmo; assim, ao seu
final, o projeto considerado entregue e funcionando a contento.
Esses eventos variam de empresa para empresa de acordo com
a metodologia utilizada.
DS: Ento existem outros eventos?
MC: Sim. Podemos ter reunies peridicas com os stakeholders,
Reunies de Avaliao de Desempenho e outros eventos que a
empresa julgar necessrios para execuo de seu projeto.
DS: Maria, voc poderia desenhar para ns um modelo de
Planejamento de Comunicao.
MC: Claro. Aqui est.

79

MC: Primeiro devemos informar o nosso pblico-alvo, ou seja,
qual stakeholder. Vocs se lembram quais so?
SB: Eu acho que lembro. Eles so:
- o Sponsor;
- o Gerente de Projeto;
- os clientes;
- a Organizao executora;
- a equipe do projeto;
- os Fornecedores;
- e os usurios finais.
MC: Isto mesmo Been. Devemos planejar as informaes sobre o
projeto para cada parte interessada. O prximo item definir qual
evento, conforme falei h pouco.
DS: Pelo que eu estou vendo, se possvel, devemos colocar o
nome dos participantes.
MC: Exatamente. E por fim colocar de quanto em quanto tempo
ir ocorrer ou quando ir ocorrer. um modelo simples, no
entanto, muito importante. E mais uma coisa, para cada
metodologia adotada, este modelo muda, dependendo, inclusive,
do tamanho do projeto.

Plano de Suprimentos ou Plano de Aquisies
SB: Agora podemos comer nossa sobremesa?
MC: Podemos.
Risos
PR: Estou sentindo falta de mais uma etapa.
SB: O que, Rocha?
PR: Eu no sei se entendi direito ou se realmente est faltando.
Ao elaborarmos o cronograma de execuo, tambm devemos
elaborar o plano de compras?
MC: No cronograma de execuo, ns inserimos o que e quando
precisamos de um determinado recurso, mas existe tambm a
necessidade de um Plano de Suprimentos.
DS: O que seria esse Plano?
MC: Este plano contempla a aquisio de equipamentos, materiais
e servios; considera o estoque, as necessidades do projeto,
fornecedores bem como qualidade de produto. E, principalmente,
define os lead time para aquisio dos servios e
equipamentos.
SB: Define o qu?
80

MC: Ao p da letra levar tempo, ou seja, o tempo necessrio
para aquisio de produtos e servios. Dessa forma, no
corremos o risco de precisar de algo que no foi comprado ou
contratado.
DS: Significa que um plano de aquisies mal elaborado pode
atrasar o nosso cronograma?
MC: Sem dvidas. Eu disse mais cedo que temos convnios com
o Governo e, por isso, estamos sujeitos Lei de Licitaes 8.666.
O Plano de Suprimentos tem que considerar esse aspecto.
Segundo o Guia PMBOK, o gerenciamento das aquisies em
um projeto implica a necessidade de conduo de processos de
planejamento (planejar compras e aquisies, bem como planejar
contrataes), processos de execuo (solicitar respostas de
fornecedores e selecionar fornecedores), processo de
monitoramento e controle (administrao de contrato) e processo
de concluso (encerramento de contrato).
SB: Puxa tudo isto?
MC: Tudo isto! Iremos conversar um pouco mais sobre Plano de
Aquisies quando estiver explicando sobre execuo e controle
de projetos. Acredito que os exemplos ficaro mais claros.
SB: Puxa, adorei adquirir esta sobremesa. Sem dvidas, ela
est completando o meu projeto alimentar de hoje.

Plano de Resposta aos Riscos

DS: Maria, acho que voc j falou de todos os Planos!
MC: Ainda no, falta falarmos sobre o Plano de Resposta aos
Riscos.
PR: Voc j falou alguma coisa sobre riscos, que eles podem ser
internos ou externos, mas no me lembro de termos relacionado
nenhum.
MC: Na verdade no relacionei. Ainda no encontrei bons
exemplos para que eu possa relacionar. Vamos continuar
conversando. No momento certo, eu voltarei com este assunto.
PR: OK.

Execuo e Controle
81


No Restaurante

DS: Maria, como eu acabei de dizer, elaboramos todos os planos.
Agora, como executamos e controlamos tudo o que planejamos?
PR: Boa pergunta! Tenho vrias dvidas de como colocamos em
prtica tudo que planejamos.
MC: Vamos com calma. Explicarei os processos de
acompanhamento e controle.
SB: Estou comeando a gostar deste assunto.
MC: Apenas como introduo da nossa conversa, gostaria de
ressaltar que o planejamento bem como a execuo e controle
so processos interdependentes e essenciais para o sucesso do
projeto.
PR: Voc quer dizer que, com a elaborao dos planos, temos o
norte a seguir; e que a execuo e controle nos indicam se
estamos trabalhando ou no corretamente?
MC: Alm de nos indicar se estamos no caminho certo, essas
estratgias nos permitem detectar os desvios e propor a
implantao de medidas corretivas.
82



1: O que controlar e acompanhar

SB: J entendi que esta fase muito importante para o sucesso
do projeto, mas como esto relacionados?
MC: Been, segundo o Guia PMBOK, o monitoramento contnuo
permite que a equipe de gerenciamento de projetos tenha uma
viso clara da sade do projeto e identifica as reas que exigem
ateno especial. Ainda segundo o Guia, o processo Monitorar e
controlar o trabalho do projeto est relacionado:
comparao do desempenho real do projeto com o plano de
gerenciamento do projeto;
avaliao do desempenho para determinar se so indicadas
aes preventivas ou corretivas e recomendar essas aes
conforme necessrio;
anlise, acompanhamento e monitoramento de riscos do
projeto para garantir que os riscos sejam identificados, que o
andamento seja relatado e que planos de respostas a riscos
adequados estejam sendo executados;
manuteno de uma base de informaes precisas e corretas
relativas ao produto do projeto e a sua documentao associada
at o trmino do projeto;
ao fornecimento de informaes para dar suporte a relatrios de
andamento, medies de progresso e previses;
ao fornecimento de previses para atualizar o custo atual e as
informaes sobre o cronograma atual;
ao monitoramento da implementao de mudanas aprovadas
quando e conforme ocorrem.
PR: Maria, no entendi muito bem, voc poderia explicar melhor?
MC: Vocs se lembram da apresentao do Sr. PMI?
SB: Sobre a evoluo do Gerenciamento de Projetos?
MC: Isso mesmo, Been.
SB: Se eu me lembro bem, o Sr. PMI disse que inicialmente os
projetos eram gerenciados apenas nos quesitos Tempo, Prazo e
Custos. Em seguida, percebeu-se a importncia de acompanhar
tambm o que seria executado, ou seja, qual o escopo do projeto.
E atualmente temos que gerenciar pessoas, compras, riscos,
comunicar, entregar com qualidade e, principalmente, precisamos
ter tudo isso integrado.
83

MC: Puxa Been, voc explicou muito bem. Vejo que o assunto
est lhe interessando!
DS: Acredito que quanto mais integrado ns estivermos, mais fcil
ser a implantao da metodologia de Gerenciamento de
Projetos na nossa rea.

MC: Concordo com voc. Apenas complementando o que o Been
falou:
Controlar:
- escopo;
- prazo;
- custo;
- qualidade;
Acompanhar:
- Financeiro
- Informaes das aes
- Riscos
- Planos de Ao
Realizar:
- Comunicao
- Gesto de stakeholders.
- Documentao das aes

DS: Maria, eu entendo que todo esse acompanhamento deve ser
aprovado e/ou autorizado. Mas como isso ocorre?
MC: Voc fez uma pergunta referente a um assunto que at agora
eu no tinha comentado. muito importante que, para cada fase,
tenha um marco; e que, para cada marco, seja determinada a
aprovao de uma instncia superior.
PR: Isto em se tratando de uma grande empresa. E aqui no
restaurante?
MC: No s em grandes empresas. Independente do tamanho da
empresa, todo projeto dever ser aprovado e autorizado. No caso
do restaurante, pense no Luiz Otvio como o presidente da
empresa, desta forma em algumas aes ele aprova e em outras
ele autoriza.
PR: No entendi. Como ele aprova em alguns casos e, em outros,
autoriza?
MC: Vou tentar dar um exemplo prtico. Todo projeto tem fase de
iniciao, fase de planejamento, fase de execuo e controle e
fase de encerramento.
84

No caso do restaurante, o Luiz Otvio, como nico dono, aprovou
todo o projeto e o marco de cada fase. Por se tratar de uma
pequena empresa, ele tambm foi o gerente do projeto e, neste
caso, autorizou as aes de cada fase.
DS: Refao a minha pergunta. Como acontece o
acompanhamento dos projetos?
MC: Depende da metodologia adotada!
SB: L vem voc de novo com metodologia.
MC: Been, a metodologia nos ajuda muito. Assim, apenas como
exemplo, podemos dizer que o acompanhamento de um projeto
pode ocorrer em trs etapas:

1 - Etapa - Acompanhamento de progresso
Nesta etapa, realizado o acompanhamento operacional, para
identificar o andamento da execuo das atividades, a
atualizao dos dados de prazo, custo e escopo, a atualizao
dos indicadores, acompanhamento dos planos de ao e de
respostas aos riscos.
Esse acompanhamento normalmente ocorre em reunio
semanal, realizada entre o gerente do projeto e a equipe
executora.
Os indicadores acompanhados so os de custo, prazo, esforo e
especficos, criados no plano de qualidade para cada projeto.

2 Etapa - Acompanhamento de desempenho
Nesta etapa, realizado o acompanhamento ttico para verificar
se a execuo est de acordo com o planejado, analisando-se os
indicadores e se os desvios identificados esto sendo tratados
com planos adequados. Realiza-se, tambm, anlise crtica da
utilizao da metodologia.
Esse acompanhamento normalmente ocorre em reunio mensal,
realizada entre o gerente do projeto e a equipe do escritrio de
projetos. Nessa reunio, so analisados os dados de execuo,
das informaes colhidas nas reunies de acompanhamento de
progresso e da documentao do projeto.
DS: Agora estou com dvidas. O que escritrio de projetos? No
estou me lembrando de termos falado sobre ele!
85

MC: Tambm no estou me lembrando. Em todo caso, vou
conceituar. Segundo Ricardo Vargas, Escritrio de Projetos, ou
PMO (Project Management Office) um local central para
conduzir, planejar, organizar, controlar e finalizar as atividades do
projeto. Suas principais funes so:
orientar e apoiar a organizao no desenvolvimento de seus
projetos
desenvolver e manter atualizada uma metodologia de
gerenciamento de projetos
integrar e coordenar a gesto de projetos
fornecer informaes estratgicas Alta Administrao,
Stakeholders, Gerentes de Projetos e organizao.
SB: Temos um escritrio de projetos na empresa?
MC: Est em fase de implantao juntamente com a metodologia.
Voltando explicao anterior, a terceira etapa :

3 Etapa - Acompanhamento executivo
Nesta etapa, realizado o acompanhamento estratgico para
apresentar os resultados dos projetos.
Esse acompanhamento normalmente ocorre em reunio mensal,
realizada entre o escritrio de projetos (PMO) e a Alta
Administrao.


2: Ferramentas

PR: Maria, da mesma forma que temos modelos de formulrios
para o planejamento, temos tambm para o acompanhamento e
execuo do projeto?
MC: Temos sim, Pedro. De acordo com a metodologia adotada,
teremos ferramentas especficas. Segundo o Guia PMBOK,
ferramenta pode ser entendida como Alguma coisa tangvel,
como um modelo ou um programa de software, usada na
realizao de uma atividade para produzir um produto ou
resultado.
DS: Quais so as ferramentas mais utilizadas?
MC: Hoje temos a tcnica do valor agregado, o diagrama de causa
e efeito, diagrama de pareto, a matriz de responsabilidades, alm
das nossas velhas conhecidas planilhas de custos, planilhas de
acompanhamento fsico e financeiro.
86

PR: Maria, fale um pouco de cada uma, por favor.
MC: Claro.
(Conceito extrado do livro Fundamentos do Gerenciamento de Projetos / Andr
Birrencourt do Valle, Carlos Alberto Pereira Soares, Jos Finocchio Jr., Lincoln de Souza
Firmino da Silva.: Rio de Janeiro: Editora FG, 2007)
A Tcnica do Valor Agregado (TVA), tambm conhecida como
anlise do valor agregado, uma ferramenta de gerenciamento
da integrao, do tempo e do custo de projetos que, segundo
Ricardo Vargas, tem como foco a relao entre os custos reais
consumidos e o produto fsico obtido no projeto por meio de uma
quantidade especfica de trabalho, ou seja: o que foi obtido pelo
projeto em relao quantidade de capital consumido para atingir
esse resultado.
A TVA possibilita uma anlise integrada do escopo, prazos e
custos do projeto, permitindo verificar atrasos ou adiantamentos
do cronograma, identificar extrapolaes do oramento, medir a
eficincia do uso do tempo e dos recursos, alm de possibilitar
inferncias sobre estimativas de concluso e custo do projeto.
Segundo pesquisa efetuada pelo ICPMA (2002), a TVA apresenta
os seguintes benefcios:
proporciona uma clara percepo do status real do projeto;
beneficia o controle;
possibilita a estimativa de previses;
facilita o processo de tomada de decises
gerenciais/capacidade de gerenciar projetos;
fornece uma fonte independente de informao/mtodo;
melhora a eficincia do projeto;
melhora o ambiente;
proporciona um aviso prvio em relao aos problemas;
possui uma clara aplicabilidade/alinhamento com a companhia;
possibilita a otimizao do trabalho (por exemplo, horas
reduzidas, conflitos, etc)
possui alta capacidade de receber informaes.

Outra ferramenta o nosso velho conhecido Diagrama de Causa
e Efeito, tambm conhecido como diagrama de espinha de peixe.
uma representao grfica utilizada para identificar os fatores
que contribuem para um resultado ou as causas de um
determinado problema. As relaes de causa e efeito so
87

descritas por meio de um diagrama parecido com uma espinha
de peixe, sendo utilizado para analisar as causas que produzem
efeitos tanto benficos quanto malficos.
O Diagrama de Pareto a representao grfica utilizada para
evidenciar os fatores que contribuem para ressaltar a importncia
relativa entre vrios problemas ou de determinadas situaes.
Baseia-se no princpio de Pareto, onde 20% dos fatores
respondem por 80% dos resultados.
Apresenta as seguintes contribuies:
o diagrama sugere ateno a elementos crticos do processo.
Passa, assim, a noo de prioridade a determinados aspectos. O
diagrama ajuda a identificlos;
o diagrama permite classificar (em ordem decrescente) os
elementos do processo segundo a importncia da contribuio de
cada um para o processo inteiro. Permite, tambm, organizar
esses elementos em categorias, classes ou grupos;
o diagrama investe na visualizao global do processo,
passando a idia de que essa viso abrangente fundamental
para decises nesse nvel, sempre de porte amplo;
a ferramenta mostrar onde se devem priorizar as aes de
melhorias. O diagrama causa e efeito usar como base de ao
esses dados.
Contudo deve-se dar especial ateno ao fato de que nem
sempre os problemas mais freqentes so os que apresentam
maiores custos.
E h a Matriz de Responsabilidades, que uma estrutura que
relaciona o organograma do projeto com a estrutura analtica do
projeto para ajudar a garantir que cada componente do escopo
de trabalho do projeto seja atribudo a uma pessoa responsvel.
uma ferramenta gerencial que auxilia o processo de
determinao e visualizao das responsabilidades de cada
membro da equipe do projeto.
PR: Eu entendo que, no caso dessa matriz, fica clara a
responsabilidade de cada membro na execuo das aes.
MC: Esta uma das vantagens da matriz.
SB: Quais as outras vantagens?
88

MC: Como disse o Pedro, a matriz possibilita que sejam
evidenciados de forma clara e concisa a responsabilidade, a
autoridade e os canais de comunicao. Alm disso:
ressalta indivduos e/ou organizaes sobrecarregados;
aponta deficincias de falta de pessoal habilitado ou disponvel;
facilita o julgamento sobre a necessidade de remanejamento do
pessoal;
facilita a visualizao do relacionamento de cada atividade ou
fase do projeto com as equipes ou rgos responsveis por
algum tipo de ao no projeto;
auxilia na negociao com outras organizaes.

PR: Maria, todas essas ferramentas esto informatizadas e em um
nico sistema?

MC: No necessariamente. Entre as ferramentas informatizadas
mais simples, temos planilhas eletrnicas e gerenciadores de
banco dados.
As planilhas eletrnicas, muitas vezes, so criadas em softwares
como MS Excel, Word e so utilizadas para o planejamento e
controle de recursos, para elaborao de oramentos, para o
gerenciamento da apropriao de dados, a elaborao de
grficos de controle, etc.
Os gerenciadores de banco de dados podem ser utilizados para
gerenciar os diferentes tipos de insumos utilizados no projeto, a
produtividade do pessoal alocado, os agendamentos. Hoje, os
mais utilizados so os softwares MS Project e o Primavera.
DS: Esses programas so normalmente interativos e possibilitam
que as informaes sejam associadas e transferidas de um para
outro, automatizando parte do processo de gerenciamento.
MC: Isso mesmo. Vou mostrar para vocs um exemplo de um
projeto detalhado no MS Project.
89



3: Gerenciamento
DS: Maria, falamos das ferramentas de execuo e controle, mas
agora relacione-as com os planos elaborados.
MC: OK, vou tentar. Vamos voltar nossa conversa de quando
estvamos vindo para o restaurante. A fase de execuo e
controle um ciclo PDCA. Assim temos:

1 - Gerenciamento de Prazo:
Lembrando da obra do Restaurante Bem Viver, podemos simular
o acompanhamento do prazo. Vejam o desenho que eu fiz.
90


2 - Gerenciamento de Custos:

91

O progresso do projeto deve freqentemente ser comparado com
a sua linha de base.
Os desvios mais significativos devem ser comunicados de acordo
com seu impacto at o nvel hierrquico adequado do projeto e,
em caso de desvios significativos, aes corretivas devem ser
identificadas e implementadas.
DS: O que linha de base?
MC: Linha de base o conjunto de informaes iniciais
aprovadas para o trabalho do projeto, em relao s quais
comparada a execuo do projeto e so medidos os desvios para
o controle do gerenciamento. A linha de base da medio de
desempenho normalmente integra parmetros de escopo,
cronograma, trabalho e custo, mas tambm pode incluir
parmetros tcnicos e de qualidade.
PR: Juntamente com gerenciamento de custos, acompanhamos
tambm o planejamento das aquisies?
MC: Sim, Rocha. Os contratos com os fornecedores tm que ser
administrados, de forma que o progresso do escopo contratado
seja verificado e conciliado com pagamentos e disposies do
contrato.

3 - Gerenciamento de Qualidade:
SB: E o gerenciamento da qualidade, como acontece?
MC: Esta a sua praia.
SB: Dessa parte eu realmente gosto.
MC: O gerenciamento da qualidade est em todo o processo.
Mas, na prtica, a qualidade implementada atravs de
atividades ou caractersticas tpicas de melhoria contnua, como,
por exemplo:
atividades de garantia da qualidade;
parmetros quantificveis para definir como o sucesso ser
medido;
realizao de comits de projeto, com informaes sobre o
andamento do projeto, assegurando a realizao de revises (ou
controles) para manter o projeto alinhado com suas metas;
aceitao, por parte da alta administrao, da necessidade de
realizar ajustes, com base na experincia e recomendaes dos
gerentes de projeto.
SB: No meu vasto conhecimento em qualidade...
92

PR: Modesto.
RISOS
SB: Continuando meu raciocnio... apesar de o suporte da alta
administrao ser necessrio para uma implantao bem
sucedida de processos de gesto da qualidade, toda empresa
precisa de diretrizes e processos para transformar polticas de
qualidade em satisfao do cliente.
DS: E satisfao do cliente um grande passo para o sucesso
dos projetos.

4 - Gerenciamento de Stakeholders

MC: A satisfao de clientes funo de uma adequada e
detalhada anlise de necessidades.
PR: Posso considerar que um dos nossos principais clientes so
os stakeholders clientes?
MC: Sim. Relembrando o conceito, Stakeholders so pessoas,
rgos, entidades ou empresas interessadas nos resultados do
projeto.
Assim, stakeholder management, ou gerenciamento de
stakeholder uma atividade eminentemente pr-ativa, ou seja,
temos que nos antecipar em atender os desejos dos nossos
stakeholders.
Gerentes de Projetos devem procurar incorporar as necessidades
dos stakeholders como parte integrante do escopo do Projeto e
os requisitos dos mesmos como base para a gesto da
qualidade.
Envolve os seguintes aspectos:
identificao dos stakeholders;
entendimento do conhecimento e habilidades dos stakeholders;
anlise do Projeto de forma a assegurar que as necessidades
dos stakeholders sero atendidas.
mobilizao e envolvimento dos stakeholders no Projeto atravs
de:
alocao de trabalho para os stakeholders;
utilizao dos mesmos como especialistas;
informaes sobre o Projeto;
envolvimento dos stakeholders em mudanas no Projeto;
criao de lies aprendidas atravs dos mesmos;
93

obteno de aceitao formal do Projeto pelos stakeholders
quando do encerramento.

5 - Gerenciamento de Escopo.

PR: O bom gerenciamento dos stakeholders garante o bom
gerenciamento do escopo?
MC: O Gerenciamento de Stakeholders apenas uma parte.
O Gerenciamento de Escopo de Projetos envolve os processos
necessrios para assegurar que o projeto inclua todo o trabalho
requerido e apenas o trabalho requerido, de modo a se concluir o
projeto com sucesso, ou seja, temos de assegurar que o escopo
inicial do projeto inclua todas as aes e trabalhos necessrios e
que na execuo somente o que foi proposto seja executado.
Assim, o foco principal consiste em definir e controlar o que est
e o que no est includo no projeto.
Em ltima anlise, Gesto de Escopo significa:
1. fazer uma constante verificao no sentido de assegurar que
todo o trabalho est sendo executado;
2. dizer no a trabalhos adicionais, no includos no projeto ou
no constantes do termo de abertura do projeto;
3. prevenir trabalho adicional.
O Gerenciamento do Escopo controla os deliverables (produtos
dos itens da WBS): quantidade e conformidade em relao s
especificaes, e as mudanas fora do acordado na definio do
projeto.

4: Controle de Mudanas

DS: E como gerenciamos a mudana no escopo?
MC: O gerenciamento das mudanas protege a viabilidade do
projeto e os requerimentos de negcio aprovados. Esse processo
fornece as informaes apropriadas ao sponsor para decidir se
as modificaes devem ser aprovadas com base no impacto do
projeto em termos de custo e cronograma.
razovel esperar que mudanas ocorram em vrios momentos
do projeto, sendo conveniente estar preparado para isso e definir
94

um processo para gerenci-las. A questo da comunicao ser
um dos pontos bsicos no tratamento do assunto.
Existem vrios tipos de mudana (escopo, qualidade, prazo,
custos, etc) que levam em conta dois aspectos fundamentais:
Mudanas necessrias (requeridas): normalmente surgem de
problemas de processos, atrasos de cronograma, questes
tcnicas ou falta de recursos para o projeto (humanos ou
financeiros). Essas questes necessitam de uma forte ateno
dos gerentes do projeto e eles precisam reagir a elas com
modificaes no plano do projeto, no oramento, no cronograma,
nas entregas ou em algum outro aspecto dos processos do
projeto;
Mudanas solicitadas: bastante comum que os requisitos
tcnicos ou de negcios se alterem durante a vida de um projeto,
demandando certa flexibilidade dos responsveis pelo projeto e
pelas partes interessadas. Ainda que nem toda solicitao de
mudana seja (ou deva ser) aceita e implementada, precisa haver
um processo onde possa ser tratada.

5: Comunicao

SB: Da mesma forma que o gerenciamento de qualidade, o
gerenciamento de comunicao est presente em todo o
processo de elaborao e execuo do projeto.
MC: Segundo o Guia PMBOK, medida que ocorre a fase de
execuo do projeto, estar sendo realizada a implementao do
gerenciamento de comunicaes, por meio das aes previstas
no plano de comunicao. A distribuio da informao envolve
colocar as informaes disposio das partes interessadas no
projeto no momento oportuno, alm de responder s solicitaes
de informaes no previstas.
So encaminhados e-mails, cartas, fax e, dependendo do projeto,
ocorre tambm a publicao no jornal. Para o pblico interno,
geralmente a divulgao feita na intranet.
De acordo com a programao das reunies, elaboramos os
relatrios de Progresso, Desempenho, Executivo, Divulgao e
grficos de gesto vista.
95


6: Falhas em Projetos

DS: Com todo esse planejamento e controle, por que existem
tantas falhas em projetos?
SB: Gostei da pergunta. Deve ser porque as empresas querem
tudo para ontem e esquecem que muitas atividades s podem
ocorrer amanh.
Risos.
MC: Na realidade existem vrios fatores:

falha no planejamento e na antecipao de riscos e incertezas;
comunicao com a equipe deficiente;
falta de liderana;
suporte inconsistente (alocao de pessoas, conflitos, sistemas e
procedimentos para suporte ao planejamento e ao controle);
falta de comprometimento dos times com o sucesso dos
Projetos;
nvel do desafio;
Stakeholders no envolvidos nos momentos certos
objetivos no claros;
definio de papis e responsabilidades vagas ou inexistentes;
necessidades de recursos incompletas ou imprecisas;
compromissos-chave do Projeto no identificados ou no
institucionalizados;
falta de um processo formal de comunicao;
monitoramento do progresso do Projeto imprecisa ou tardia;
falta de sistematizao da gesto da performance, do
reconhecimento e da recompensa das pessoas;
DS: Mas tudo isso pode ser evitado ou minimizado com uma
metodologia.
MC: S a metodologia no basta. A metodologia tem que ser
conhecida e aplicada por todos os envolvidos em gerenciamento
de projetos.

6: Fatores Crticos de Sucesso

DS: Ento, Maria, eu entendo que os fatores crticos para um
resultado positivo na execuo dos nossos projetos sejam:
meta claramente definida;
96

gerente e Equipe do projeto experiente;
comprometimento das partes envolvidas;
eficiente sistema de comunicaes;
planejamento e controle adequados;
inexistncia de item de alto risco;
estrutura organizacional adequada;
acordo entre a equipe do projeto, o cliente e a gerncia em
relao aos objetivos do projeto;
plano com caminho, responsabilidades claras, estruturado para
se fazer medies;
comunicao constante;
controle eficiente e adequado de escopo, prazo e custos.
MC: Em outras palavras, eu diria: a gesto eficiente de Escopo,
Prazo, Custos, Qualidade e Stakeholders aliada boa
Comunicao, Gesto de Riscos e Controle de Mudanas que
definem o sucesso dos nossos projetos.


Gerenciamento de Escopo
97


No Restaurante

DS: Maria, estou um pouco confusa. Ns conversamos sobre
Termo de Abertura apresentando um Escopo Preliminar. Depois
elaboramos um Planejamento do Escopo com o detalhamento
das atividades. Eu entendo que esta uma etapa muito
importante, mas que no est muito clara. Ser que podemos
conversar um pouco mais sobre ela?
MC: Claro que sim, Delma. Todas as dvidas devem ser
compartilhadas. Precisamos sempre conversar e trocar
experincias para que tenhamos um bom gerenciamento dos
nossos projetos.
PR: Meninas, podemos pedir a conta?
MC e DS: Claro.
MC: Continuamos nossa conversa no carro.

98

Conceitos

DS: Ento, Maria, reforando o conceito de escopo, posso dizer
que escopo a maneira como ns descrevemos os limites do
projeto. Caracteriza-se pela definio do trabalho que ser
realizado, estabelecendo os produtos de cada etapa e as
atividades necessrias para sua execuo, e tambm o que no
ser feito dentro da abrangncia, eliminando qualquer
expectativa no prevista dos clientes e dos stakeholders.
MC: Isso mesmo. Um escopo bem elaborado reduz
consideravelmente o nvel de incerteza quanto aos resultados de
um projeto no seu incio.
PR: O que vocs disseram refora a necessidade de termos tudo
bem documentado entre as partes a respeito dos objetivos,
restries, premissas e interfaces.
SB: Maria, o detalhamento do escopo est relacionado com o
tamanho do projeto?
MC: Boa lembrana, Been. Lembram-se do incio das nossas
conversas, quando falei da complexidade dos projetos? Ento, o
nvel de detalhamento do escopo deve corresponder s
demandas do porte do projeto (valor x complexidade).
DS: Fico muito preocupada com essa definio de escopo, pois
entendo que muitas vezes no existe consenso no entendimento
sobre o produto final do projeto.
MC: Voc est certa, Delma. Por isso todas as etapas so
importantes. Veja este desenho, que retrata, de forma engraada,
como importante o detalhamento do escopo.

RISOS

ESCOPO
99


-> Da esquerda para direita: Como o cliente explicou sua necessidade; Como o
gerente de projeto entendeu; Como a equipe projetou; O que foi executado; A
expectativa dos stakeholders; Como o projeto foi documentado; Como o cliente foi
cobrado; Do que o cliente realmente precisava; Como o projeto foi suportado;
Quais os recursos que foram alocados.

RISOS
100


Consideraes

PR: Reforando as informaes: o processo de gerenciamento do
escopo realizado para controlar os deliverables, (entregas)
quantidade e conformidade em relao s especificaes e s
mudanas fora do acordado na definio do projeto.
SB: Pera. Entendi quase tudo, mas refora um pouco essa tal
de mudana.
MC: Essa tal de mudana o gerenciamento das mudanas. Ele
protege a viabilidade do projeto e os requerimentos de negcio
aprovados. Quando o projeto definido, determinadas premissas
so feitas a respeito daquilo que ser produzido.
Estas so identificadas e aprovadas no Termo de Abertura. Se os
deliverables (entregas) mudam durante o projeto, geralmente isso
significa que o cliente deseja itens adicionais ou a alterao de
um item acordado. Ento as estimativas para o custo, o esforo e
a durao sero alterados.
101

Se o sponsor concordar em incluir o trabalho adicional, o
coordenador ter o direito de alterar custo, horas de trabalho e a
durao, para refletir esse trabalho. Essa nova estimativa de
custo, o esforo e a durao agora se transformam na nova meta
aprovada.
O coordenador e a equipe de projeto devem reconhecer quando
essas mudanas so solicitadas. Ento elas devem seguir um
processo predefinido de mudana do escopo.
Esse processo fornece as informaes apropriadas ao sponsor
para decidir se as modificaes devem ser aprovadas com base
no impacto no projeto em termos de custo e cronograma.

Mudana de Escopo

SB: Maria, apresente um exemplo prtico do que voc acabou de
falar. Acho que fica mais claro.
MC: Deixe-me pensar.
PR: Puxa, pessoal, tem uma obra na avenida principal. Vou
precisar mudar o caminho e talvez atrasaremos para chegar
empresa.
MC: Olha a nosso exemplo!
102


SB: Que exemplo?
MC: Acompanhem meu raciocnio. Quando samos para o almoo,
tnhamos um roteiro pr-definido.
DS: Voc quer dizer que o nosso almoo um projeto?
MC: Sim. um evento com incio e fim definido (horrio do
almoo), alm de um resultado exclusivo (almoo dos colegas do
setor). Tambm pode sofrer alteraes (como acabou de
acontecer).
SB: Continuo no entendendo.
MC: Nosso almoo tinha as seguintes atividades:
- sair da empresa s 12 horas;
- pegar o carro;
- seguir pelas avenidas principais at o restaurante Bem Viver;
- chegar ao restaurante;
- pedir o almoo;
- pedir a sobremesa;
- pagar pela refeio;
- voltar ao Carro;
103

- retornar empresa pelas avenidas principais;
- chegar empresa s 14 horas.

PR: Vamos seguir esse raciocnio. Nosso projeto teve durao de
2 horas, ao custo total de R$ 100,00 (R$ 25,00 p/ pessoa). Isso
com a nossa total satisfao, uma vez que o restaurante atendeu
as nossas expectativas.
MC: Sim. No entanto nem todas as atividades definidas sero
cumpridas.
PR: Como no sero?
MC: Voc acabou de nos dizer que existem obras na avenida
principal. Assim teremos que pegar um caminho alternativo para
chegar empresa.
DS: Isso significa que alteramos o escopo do projeto?
MC: Exatamente. Do escopo proposto, alteraremos as duas
ltimas atividades. Assim teremos:
- retornar empresa pelas vias secundrias;
- chegar empresa s 14h30min.
DS: Eu entendo que essas alteraes devam ser acordadas por
todas as partes interessadas.
MC: No meu exemplo, as partes interessadas somos ns
mesmos. E essas alteraes no prejudicaram nosso projeto.
Ocorrer apenas o atraso na entrega.
PR: Este foi um exemplo muito simples.
MC: Foi, Rocha. O que eu quero reforar que mudanas sempre
podem ocorrer e que temos de estar prontos para os impactos
que elas iro trazer para nossos projetos.
DS: Ento, trabalhar com controle do escopo quase sempre
lidar com o controle das mudanas de escopo.
SB: S por curiosidade, temos de documentar tudo isso tambm?
MC: Claro. Toda a solicitao de mudana deve ser registrada.
importante que os registros contenham:
- data;
- local, atividade ou fase do projeto de ocorrncia da mudana;
- estado de origem, antes da mudana, e estado de destino,
depois da mudana implementada;
- grau de importncia da mudana;
- solicitante.
SB: Maria, desenhe um modelo para mim.
MC: No carro difcil. Acho que tenho um modelo aqui na minha
pasta. Aqui est.
104


105

Modelo de EAP

DS: Maria, voc falou mais cedo sobre a decomposio do
escopo numa estrutura analtica, mais conhecida por EAP.
Explique um pouco mais, por favor.
MC: Legal. Acho que vale a pena retornarmos a esse assunto.
EAP representa uma decomposio hierrquica orientada
entrega do trabalho a ser executada pela equipe do projeto para
atingir os objetivos e criar as entregas necessrias.
A organizao das entregas por meio de uma EAP vem sendo
fortemente utilizada nos projetos de sucesso em todo o mundo, j
que permite o esclarecimento equipe do projeto, fornecedores,
clientes, patrocinadores e demais interessados sobre o que se
espera em termos de resultados do projeto e, conseqentemente,
do que ser monitorado e controlado.
DS: Essa decomposio hierrquica subdivide o escopo do
projeto e as entregas do projeto em componentes menores?
MC: Sim. Segundo o glossrio do PMI, a decomposio uma
tcnica que subdivide o escopo do projeto e as entregas do
projeto em componentes menores e mais facilmente gerenciveis
at que o trabalho do projeto associado realizao do escopo
do projeto e ao fornecimento das entregas seja definido em
detalhes suficientes para dar suporte execuo, ao
monitoramento e ao controle do trabalho.
SB: Existe algum passo-a-passo para decomposio de uma
EAP?
DS: Voc explicou o que era EAP e nos mostrou um exemplo.
Existe uma EAP padro que podemos utilizar?
MC: Como eu havia dito anteriormente, a EAP possui trs nveis:
Primeiro nvel: representa o tema do projeto;
Segundo nvel: representa o tema delimitado, a estratgia de
execuo;
Terceiro nvel: normalmente, representa o trabalho a ser
realizado:
define os produtos do projeto (deliverables);
possui um responsvel pela execuo; e
pode possuir limitaes de prazo e custo.

Assim, adotamos a seguinte EAP para elaborao do escopo do
projeto:
106


SB: Voc poderia detalhar cada um desses passos?
MC: Vejamos:
1) Escrever o nome do projeto no primeiro nvel (nvel 0) da EAP:

2) Iniciar o segundo nvel com uma entrega denominada
gerenciamento do projeto:

3) Acrescentar as fases do ciclo de vida (entrega completa da
fase) ou maiores entregas provenientes da decomposio inicial
do escopo do projeto no segundo nvel:

4) Acrescentar no segundo nvel, ao final, uma entrega
denominada fechamento:
107


5) Acrescentar as entregas (produtos) e subprodutos (entregas
parciais) que as compem:

6) Decompor as entregas parciais at um nvel de detalhe que
viabilize o planejamento e controle em termos de tempo, custo,
qualidade, risco, atribuio de responsabilidade e contratao, se
for o caso.
108


Os componentes que no esto dentro de uma caixa esto
expressos no nvel mais baixo de cada ramo da EAP. Esses
componentes so denominados pacotes de trabalho e devem ser
detalhados no dicionrio da EAP.
DS: O que dicionrio da EAP.
MC: um documento complementar EAP. Apresenta uma breve
especificao do pacote de trabalho e seu critrio de aceitao.
DS: Esse dicionrio obrigatrio?
MC: O guia PMBOK sugere que todos os pacotes de trabalho
estejam detalhados no dicionrio EAP. No meu entendimento,
projetos pequenos no precisam dessa obrigao, desde que o
enquadramento do projeto na metodologia de gerenciamento do
projeto da empresa indique esse documento como opcional.
SB: Maria, quando elaboramos um escopo, fazemos tambm sua
representao atravs da EAP. Voc nos mostrou um exemplo
disso. Quando fazemos mudana, nossa EAP tambm muda?
MC: Claro. Dever ser elaborada uma nova EAP com as
alteraes.
PR Estamos chegando empresa. Podemos continuar a
conversa depois?
MC: Claro, Rocha.

Gerenciamento de Riscos
109


No Carro

PR: Puxa, como o tempo est mudando. Parece que vai cair uma
chuva daquelas.
SB: Vai mesmo. Tomara que voc consiga estacionar o carro no
estacionamento coberto.
PR: Tambm espero. Faz tanto tempo que no chove, que, pelo
jeito, vai ser chuva de granizo. Vai ser um risco deixar o carro do
lado de fora.
MC: Rocha, que exemplo legal voc acabou de dar sobre risco!
PR: Como que !?
MC: Continuamos nossa conversa no carro.

1 - Conceitos

MC: Voc se lembra do conceito de riscos em projetos?
110

PR: Sim. Risco em projetos corresponde a um evento ou condio
incerta que, se efetivamente ocorrer, pode implicar efeito positivo
ou negativo nos resultados do projeto.
MC: Isso mesmo. At agora no havia falado muito de riscos, mas
voc me deu um exemplo que podemos explorar para falar um
pouco de riscos.
DS: Outro conceito de risco a probabilidade de um evento
ocorrer associado ao impacto (conseqncia da ocorrncia).
MC: Devemos lembrar que o risco pode ser de natureza interna ou
externa. A chuva representa um risco de natureza externa e no
temos controle sobre ele. No entanto o local aonde iremos
estacionar o carro pode ser considerado um risco. Como um
risco de natureza interna, temos controle sobre ele.
DS: De acordo com as nossas conversas, podemos dizer que o
risco composto pelo evento, sua causa e o efeito da ocorrncia.
MC: Apenas complementando a sua informao, temos:
Evento: acontecimento, eventualidade.
Causa: aquilo ou aquele que ocasiona um acontecimento ou faz
com que algo exista; princpio; origem; motivo, razo, pretexto;
partido.
Efeito: conseqncia; produto de uma causa, fim, destino,
aplicao.
PR: Se entendi bem, se eu estacionar o carro no estacionamento
descoberto, corro o risco de ter o meu carro amassado, caso a
chuva seja de granizo.
MC: Exatamente. Na medida em que eu explicar um pouco mais
sobre riscos, irei fazendo as comparaes. Acredito que assim
ficar mais claro.
DS: OK. Voc vai explicar um pouco mais sobre todas as etapas
do gerenciamento de riscos.
MC: Vou.

2: Etapas do Gerenciamento de Riscos

SB: Viver um risco.
DS: Viver assumir risco.
PR: Nossa! Vocs dois esto viajando. Vamos deixar a Maria
explicar.
MC: Hoje em dia, uma das reas de conhecimento do
gerenciamento de projetos que est sendo mais estudada a do
Gerenciamento de riscos.
111

O gerenciamento de riscos tem como objetivo maximizar os
resultados de ocorrncias positivas e minimizar as conseqncias
de ocorrncias negativas. O gerenciamento de riscos composto
por seis etapas. So elas:
1. Planejar a gerncia de risco: determinar qual a abordagem e
planejar as atividades de gerncia de risco que sero executadas
para o projeto.
2. Identificar riscos: determinar quais riscos podem afetar o
projeto e documentar as suas caractersticas.
3. Analisar riscos qualitativamente: avaliar, determinar e compor
os fatores de impacto e probabilidade, bem como priorizar seus
efeitos nos objetivos do projeto.
4. Analisar riscos quantitativamente: analisar os riscos
priorizados, associando a eles um nmero que permitir avaliar,
sobretudo financeiramente, as implicaes caso esses riscos
venham a ocorrer.
5. Planejar as respostas aos riscos: desenvolver procedimentos e
tcnicas para avaliar oportunidades e reduzir as ameaas aos
objetivos do projeto.
6. Controlar e monitorar riscos: executar planos de respostas e
identificar novos, monitorar riscos residuais e avaliar efeitos no
ciclo de vida do projeto.

SB: Est bem. Mas como identifico riscos, analiso, controlo, etc.?
Isso no fcil.
MC: No disse que era. No entanto, como j conversamos
anteriormente, existem formas de identificar riscos.
DS: Ento identificar riscos determinar o evento, a causa e o
efeito.
MC: Isso mesmo. Assim, h uma causa para cada risco e um
efeito se o risco ocorrer. A causa uma situao que existe e que
estabelece um risco potencial. Em geral, a causa um fato ou
uma certeza para o projeto. Por outro lado, o efeito o resultado
provvel da ocorrncia do risco.
PR: Posso dizer, ento, que a causa, neste caso, o
estacionamento lotado. O resultado disso que meu carro pode
ou no ficar exposto ao tempo.
MC: Grosso modo, pode sim.
SB: Existe alguma tcnica para identificar riscos, ou trabalhamos
no achmetro?
MC: Been, em projetos no achamos nada.
112

DS: tudo preto no branco.

3: Identificao dos riscos

MC: Existe uma grande variedade de tcnicas para identificar
riscos. Dentre elas, temos: check-list, comparao anloga,
anlise de premissas, decomposio, entrevista com
especialistas, tcnicas de diagramao e Delphi. Algumas das
tcnicas so focadas em uma sada especfica, por exemplo: se a
incerteza estiver relacionada aos custos, a tcnica pode ser a de
anlise da EAP.
PR: Maria, explique um pouco mais essas tcnicas.
MC: Vou explicar as tcnicas que podem ser aplicadas a todas as
sadas do projeto: custo, trabalho, prazo e qualidade.
A primeira tcnica o check-list. Nesta tcnica, utilizam-se listas
prontas para identificar os riscos. O check-list pode ser
desenvolvido com base nas informaes histricas, no
conhecimento acumulado dos projetos e na experincia de
especialistas. Veja esta folha com um exemplo de check-list:
113


114


115


SB: Puxa, que lista comprida. Temos que usar essa lista sempre?
MC: No, Been. Como eu disse, ela um check list e nos auxilia
na identificao dos riscos de um projeto.
Continuando. Outra tcnica a Comparao Anloga. Essa
tcnica identifica riscos com base na idia de que nenhum projeto
representa um sistema totalmente novo, independente do quo
complexo ele seja. Para tanto, a tcnica prev a identificao de
projetos similares, cujos dados possam ser utilizados para a
reviso ou para a elaborao dos novos projetos.
A identificao de projetos similares envolve a determinao de
caractersticas comuns, por exemplo, tecnologia, funcionalidade,
estratgia de contrato e processo de desenvolvimento.
DS: Mas qual a vantagem dessa tcnica?
MC: Na realidade, existem vantagens e desvantagens. Uma
vantagem da comparao anloga que ela fcil de ser
utilizada. Como desvantagem, tem-se que sua preciso depende
dos dados histricos, da interpretao desses dados e do nvel
de detalhe em que esto descritos.
DS: Significa que, para utilizarmos essa tcnica, os projetos
anteriores tm que estar bem documentados?
MC: Isso mesmo. Outra tcnica a anlise de premissas. Na
anlise de premissas, cada projeto concebido e desenvolvido
com base em um conjunto de premissas.
Esta uma tcnica que explora as incertezas do projeto pela
existncia de premissas que foram assumidas, e que podem no
ser verdadeiras. As premissas imprecisas, inconsistentes ou
incompletas devero ser identificadas.
116

DS: Relembrando. Premissas so fatores que, para os propsitos
do planejamento, consideram-se como verdadeiros, como reais
ou como mais provveis, como o exemplo que voc deu para o
projeto do restaurante.

MC: A outra tcnica muito utilizada a anlise causal.
A anlise causal mostra a relao entre um efeito e sua possvel
causa, para que seja verificada a origem do risco.
Da mesma forma que utilizada para o acompanhamento do
projeto, aqui tambm o conhecido diagrama de causa e efeito
ou espinha de peixe ser til para identificar as causas dos
riscos. A filosofia da anlise causal sustenta que, se um erro
ocorrer, ele ir acontecer novamente, a menos que se faa
alguma coisa para evit-lo.
PR: E da? Identificamos os riscos. O que fazemos agora?

4: Anlise dos Riscos

MC: No processo de anlise de risco, fazemos anlise qualitativa
e anlise quantitativa.
SB: Como que ?
MC: Analisar qualitativamente um risco qualific-lo quanto sua
pontuao: a probabilidade multiplicada pelo impacto. Em
projetos, para um evento ser considerado um risco, deve-se ter
uma perda ou ganho associado e alguma chance ou escolha. Ou
seja, o risco pode ser modificado por uma ao.
PR: Trabalhamos, ento, com probabilidades?
MC: Probabilidade x Impacto. Fazemos a anlise da seguinte
forma:
Primeiro, temos o referencial de probabilidade de ocorrncia.
Riscos tm probabilidade de 1% a 99% de ocorrer. Se um evento
tiver uma probabilidade de zero por cento de ocorrer, dever ser
ignorado, e, se tiver uma probabilidade de 100% de ocorrer,
ento um fato (e talvez uma restrio).
117

DS: Temos referncias estabelecidas?
MC: Temos as referncias mais utilizadas, que so:
Alta chance de ocorrer 0.75
Mdia chance de ocorrer 0.50
Baixa chance de ocorrer 0.25
Muito baixa chance de ocorrer 0.10

PR: Ento agora temos o referencial de impacto?
MC: Exato. As referncias mais utilizadas so:
Muito alto 5.0
Alto 4.0
Mdio 3.0
Baixo 2.0
Muito baixo 1.0

PR: Pelo meu conhecimento em probabilidade, considero que,
para um bom entendimento, devemos colocar essas informaes
em uma matriz e classific-las.
MC: Sim. Fazemos uma pontuao para cada risco especfico,
baseada em uma matriz Probabilidade x Impacto.
DS: Dessa forma os riscos sero classificados de acordo com
grau de importncia?
MC: Classificaremos os riscos em baixo, mdio e alto e, assim,
podemos traar o planejamento de respostas aos riscos.
PR: Voc acabou de falar sobre a classificao dos riscos. Mas
como eu os classifico em baixo, mdio ou alto?
MC: Desculpe-me. Esqueci de dizer. Os riscos do projeto podem
ser classificados em:
Baixo risco 0,10 a 0,75
Mdio risco 0,95 a 1,90
Alto risco 2,00 a 3,75
Vejam esta figura. Ela a representao de uma matriz de
probabilidade x impacto.
118



5: Fontes de risco

SB: Est tudo muito bem explicado. Mas como identifico um risco?
Existe alguma fonte especfica?
MC: Existem fontes de riscos, que um grupo de caractersticas
semelhantes que originam os riscos. Por exemplo, pessoas,
tecnologia, escopo e mercado.
SB: Voc poderia explicar um pouco melhor sobre essas fontes
de riscos?
MC: Claro. Hoje as fontes mais comuns so:
Aquisies: riscos relacionados ao tempo para aquisio de
compras de bens e servios;
Cliente: riscos relacionados ao envolvimento do cliente e s
relaes entre os clientes;
Comunicao: riscos de no comunicar bem o andamento do
projeto;
Complexidade do projeto (Escopo): riscos relacionados ao grau
de dificuldade para o desenvolvimento do projeto;
Composio da equipe (pessoas): riscos relativos aos aspectos
de montagem da equipe. importante verificar se equipes
mistas, equipes formadas por pessoas que possuem regime de
trabalho diferenciado (funcionrios, subcontratados, estagirios),
podem influenciar o andamento do projeto, pois a diversidade
pode trazer para a equipe de desenvolvimento problemas como
comparaes salariais e diferentes nveis de comprometimento
entre os seus membros;
Equipe do Projeto: riscos relacionados habilidade dos
tcnicos, ao relacionamento da equipe e motivao para o
trabalho;
119

Gerncia de projetos: riscos relacionados habilidade do
coordenador e s atividades prprias de gerncia de projetos;
Poltica organizacional: riscos relativos aos aspectos culturais e
polticos da organizao;
Prazo (Tamanho e durao do projeto): riscos relativos ao
tamanho e durao (prazo) do projeto. Trata-se de aspectos
significativos para o aumento da complexidade, que requerem
uma anlise da influncia desses
fatores no risco de prazo do projeto;
Processo (Qualidade): riscos relacionados ao processo, ou seja,
todos os processos necessrios para a produo dos produtos do
projeto com qualidade. Portanto a categoria, ao invs de ser
nomeada Processo de Desenvolvimento, foi generalizada
simplesmente para Processo, a fim de ser mais abrangente;
Tamanho da equipe: riscos relativos aos aspectos de tamanho
da equipe. diretamente proporcional necessidade de
entrosamento da equipe e ao esforo para manuteno da
comunicao entre os seus membros, exigindo maior
coordenao do gerente de projeto, o que torna seu trabalho
mais complexo;
Tempo de dedicao do coordenador ao projeto: riscos relativos
aos aspectos de performance do projeto. Pode ser afetada pelo
nmero de projetos pelos quais o coordenador de projeto
responsvel ou o seu tempo de dedicao ao projeto.

PR: Maria, voc poderia listar alguns riscos potenciais?
MC: Conheo alguns. Posso destacar:
Relativos ao Cliente
Ausncia da participao do cliente
Cliente resistente a mudanas
Conflitos entre clientes
Clientes com atitudes negativas em relao ao projeto
Clientes no comprometidos com o projeto
Relativos Equipe de Desenvolvimento
Ausncia de cooperao entre os membros da equipe
Conflitos entre cliente e equipe de desenvolvimento
Membros da equipe de desenvolvimento treinados
inadequadamente
Ausncia de comprometimento dos membros da equipe de
desenvolvimento em relao ao projeto
Membros da equipe inexperientes
120

Falta de boas prticas da equipe tcnica
Conflitos entre os membros da equipe de desenvolvimento
Freqente rotao de pessoal na equipe de projeto
Equipe de desenvolvimento no familiarizada com as
ferramentas
Membros da equipe de desenvolvimento no familiarizados com
o negcio do cliente
Atitudes negativas da equipe de desenvolvimento
Ausncia de perfil especializado na equipe de projeto para
atender aos requisitos do projeto
Relativos a Polticas Organizacionais
Recursos retirados do projeto por causa de mudanas nas
prioridades organizacionais
Mudanas na gerncia da organizao durante o projeto
Polticas corporativas com efeito negativo no projeto
Influncia poltica no projeto (externa)
Ambiente organizacional instvel
Reestruturao organizacional durante o projeto
Ausncia de suporte gerencial de alto nvel para o projeto
Ausncia ou perda do comprometimento organizacional com o
projeto
Relativos Complexidade do Projeto
Dependncia de fornecedores externos
Muitos fornecedores externos envolvidos com o projeto de
desenvolvimento
Alto nvel de complexidade tcnica
Tarefas altamente complexas a serem automatizadas
Projeto afetando um grande nmero de departamentos ou
unidades do cliente
Grande quantidade de interao com outros sistemas
Projeto envolvendo o uso de novas tecnologias
Inadequada transferncia de tecnologia para o projeto
Condies de trabalho inadequadas
Relativos a Processo:
Padres, polticas e metodologias de engenharia de software
inadequados
Mtodos e ferramentas de engenharia de software inadequados
Burocracia excessiva
Falta de suporte para a resoluo de problemas tcnicos
Falta de infra-estrutura para reuso
Falta de prtica de reuso
121

Repositrios de projeto e controle de configurao inadequados
Ausncia de uma metodologia efetiva de gerncia de projetos
Relativos Gerncia de Projetos:
Planejamento inadequado do prazo
Planejamento inadequado dos recursos necessrios
Planejamento inadequado do oramento
Presso excessiva de prazo
Baixa produtividade
Baixa qualidade dos produtos intermedirios e finais
Ausncia de pessoas com perfil para liderar o projeto
Acompanhamento do progresso do projeto insuficiente
Fraco planejamento de projeto
Falta de definio dos marcos do projeto
Ineficincia do gerente do projeto
Inexperincia do gerente de projeto
Comunicao ineficiente
Relativos a Requisitos:
Mudanas contnuas dos objetivos e escopo do projeto
Requisitos conflitantes
Mudanas contnuas dos requisitos
Requisitos no definidos de forma adequada
Falta de clareza dos requisitos
Requisitos incorretos
Deficincia no entendimento dos usurios quanto s limitaes
ou capacidades do sistema
SB: Puxa. Ser que iremos conseguir tratar esse assunto?
PR: Por que no?
SB: So muitas informaes e no me sinto seguro em determinar
quais riscos so mais ou menos impactantes.
DS: Estamos iniciando o processo de gerenciamento de projetos.
Acredito que tudo uma questo de prtica.
MC: Concordo com a Delma. Apenas com o tempo, teremos
conhecimento e maturidade para realizarmos uma gesto de
projetos eficiente e eficaz.
122



6: Planejamento das respostas

DS: Entendo que, depois de identificarmos os riscos, como voc
acabou de dizer, teremos que planejar como administrar os
riscos, caso eles ocorram.
PR: Como fazemos esse planejamento?
MC: simples. O planejamento das respostas consiste da
determinao da estratgia de como gerenciar o risco e elaborar
um plano de ao para trat-lo. Esse processo aplicado
obrigatoriamente nos projetos de dimenso PJ4, PJ3, PJ2 e
opcional nos projetos PJ1.
SB: Por que opcional nos projetos PJ1?

MC: Porque so projetos de curta durao e de valores
financeiros muito pequenos. Os riscos, nesse caso, quase so
imperceptveis ou no existem.
123

PR: Existem estratgias especficas para tratar os riscos?
MC: Existem alguns tipos de estratgia que podem ser adotadas
como resposta a riscos. So elas:
Evitar o risco: essa estratgia deve ser considerada para risco
de alta probabilidade e com severas conseqncias;
Transferir o risco: implica repassar para um terceiro a
responsabilidade por sua gesto. No implica sua eliminao. O
plano de resposta, quando elaborado, consiste da identificao e
contratao de terceiro, que assumir as responsabilidades do
risco;
Mitigar o risco: visa reduo da probabilidade e do impacto do
risco;
Aceitar o risco: implica aceitar as conseqncias do evento de
risco. O plano de resposta, quando elaborado, inclui a
contingncia;
Alavancar o risco: implica maximizar as chances dos riscos
positivos para o sucesso do projeto.

SB: O que incluir a contingncia?
PR: Se entendo bem, contingncia deve ser uma reserva
financeira.
MC: Exato. Contingncia, nesse caso, a reserva monetria para
o projeto, na eventualidade de um risco acontecer. calculada
para riscos altos em projetos do tipo PJ2, PJ3 e PJ4. Para riscos
identificados, aplica-se a probabilidade de ocorrncia sobre o
valor monetrio relativo s atividades impactadas pelo risco.
Quando no identificamos os riscos, geralmente devemos
contingenciar 5% do oramento total do projeto.

7: Controle

SB: Legal. Gostei deste assunto.
PR: At que enfim.
RISOS
DS: Todos estes processos so muito importantes.
MC: So realmente importantes. E, para finalizarmos este
assunto, temos o controle da gesto de riscos.
SB: Pelo que conversamos, o controle de riscos tem que ser
acompanhado o tempo todo.
MC: Isto mesmo, Been. O controle de respostas a riscos um
processo contnuo ao longo do ciclo de vida, uma vez que o
124

gerenciamento de riscos um processo dinmico. realizado por
meio do acompanhamento dos planos de respostas, do
monitoramento dos riscos residuais e da identificao de novos
riscos.
SB: Estaremos num ciclo PDCA.
MC: Exatamente.
PR: Pessoal, chegamos. Ser que vou conseguir estacionar?

DS: Vamos l. A probabilidade grande de conseguir.
SB: Olha l, Rocha, uma vaguinha no estacionamento coberto
esperando por voc.
PR: Legal. Assim, nem o carro nem ns corremos o risco de nos
molhar.

Gerenciamento de Stakeholders
125


No Estacionamento da Empresa

DS: Nossa, que chuva. Ainda bem que j chegamos.
PR: . E estamos protegidos.
SB: Maria, aproveitando que j chegamos e estamos protegidos,
gostaria que voc falasse um pouco mais sobre os stakeholders.
Considero que sua gesto seja tambm muito importante.
MC: E muito importante. Voc se lembra do conceito de
stakeholders?
SB: Stakeholders so pessoas, rgos, entidades ou empresas
interessadas nos resultados do projeto.
MC: Isto mesmo. Mas executar um projeto com sucesso requer
um alto grau de integrao com os stakeholders.
Stakeholder qualquer um dos atores que esteja interessado em
seu projeto ou que possa impactar no andamento ou vir a ser
afetado por seus produtos. importante entender os valores e os
126

assuntos relacionados aos stakeholders, para foc-los e mant-
los integrados ao projeto.

1 - Principais Stakeholders e suas Funes

DS: Mas cada stakeholder possui valores e desejos diferentes?
MC: Sim. Lembra-se do que eu disse na hora do almoo? Temos
que nos antecipar em atender os desejos de nossos
stakeholders.
PR: Ento, para cada stakeholder, teremos desejos diferentes.
MC: Alm disso, cada stakeholder envolvido ter uma funo
definida, assim, as expectativas tambm sero diferentes.
SB: Maria, d exemplos.
MC: OK. Lembra-se quando conversamos sobre os principais
stakeholders e eu citei alguns?
SB: Sim, voc citou: sponsor, gerente de projeto, clientes,
organizao executora, equipe de projeto, fornecedores e
usurios finais.
127

MC: Muito bem Been, e como acabamos de comentar, cada um
tem sua caracterstica e sua funo especfica.
SB: E quais so?
MC: Vou explicar.

1.1- Sponsor

MC - Temos, em primeiro lugar, o Sponsor. Ele o indivduo ou
entidade que disponibiliza os recursos financeiros (patrocinador)
para a execuo do projeto.
Usualmente, essa funo desempenhada por um agente
financeiro.
As principais funes do sponsor so:
caracterizar a demanda e os produtos esperados com o projeto;
apresentar a caracterizao do projeto para todos os
participantes do programa;
participar com a equipe do projeto na definio do escopo do
128

projeto;
aprovar o escopo definido para o projeto;
garantir foco e direcionamento do projeto;
analisar e aprovar as propostas do grupo.

DS: Posso dizer que o Senhor Fortunato, presidente da nossa
empresa, um sponsor?
MC: Pode sim, Delma. Hoje, parte dos nossos projetos de
melhoria interna, e quem disponibiliza recursos o Sr. Fortunato.
PR: Sem dvida, os dirigentes so partes interessadas.
DS: Mas, sem sombra de dvidas, uma das partes interessadas
mais importante o prprio gerente do projeto.
MC: Isso verdade.

1.2 - Gerente de Projeto

SB: Quais so suas principais funes?
MC: Suas funes so:
129

definir o escopo do projeto;
identificar e selecionar os recursos (equipe e recursos
materiais);
liderar a equipe nas fases do projeto;
estimar e criar o oramento;
identificar e gerenciar todas as questes e riscos do projeto;
criar e manter o plano do projeto;
gerenciar todas as mudanas no projeto;
gerenciar a documentao do projeto;
realizar a prestao de contas mensal e final do projeto;
comunicar e manter os relatrios de progresso nas reunies de
acompanhamento;
produzir o produto / servio de acordo com as especificaes
tcnicas, no prazo e custos orados e com os recursos
disponveis na organizao;
recomendar o trmino do projeto ou soluo alternativa caso os
objetivos no possam ser atingidos e as obrigaes contratuais
permitam;
tomar ou forar as decises requeridas para assegurar que os
objetivos do projeto sejam atingidos;
ser o ponto focal de contato do projeto com o cliente e gerentes
funcionais;
negociar com outras reas de forma a conseguir recursos para
o projeto, sempre que necessrio;
promover as articulaes com os stakeholders internos.

SB: Ele um super heri e o escritrio de projetos a liga da
justia.
Risos
MC: Voc no perde a oportunidade de brincar. Na realidade, o
gerente de projetos deve possuir um conjunto bsico de
conhecimentos para que ele possa desempenhar suas funes.
PR: E quais seriam esses conhecimentos?
MC: Como eu disse, um conjunto de conhecimentos. Eu
destacaria os seguintes:
1. o conjunto de conhecimento em tcnicas de gerenciamento de
projetos;
2. conhecimento bsico da rea onde estar gerenciando o
projeto. Por exemplo, normas e regulamentos das reas de
aplicao, ou seja, reas como petrleo e gs, setor automotivo,
biotecnologia, servios, dentre outros;
130

3. conhecimento e habilidades de gerenciamento geral; e
4. habilidades interpessoais.
DS: O que seriam habilidades interpessoais?
MC: As habilidades interpessoais incluem:
liderana;
comunicao eficaz;
influncia sobre a organizao;
motivao;
negociao e gerenciamento de conflitos;
resoluo de problemas.
SB: Eu no disse? Um super heri!
RISOS
MC: Veja este desenho. Se a empresa no souber identificar as
habilidades e competncias dos seus funcionrios, corre o risco
de perder excelentes profissionais.

1.3 - Equipe do Projeto

PR: Mas esse super-heri no trabalha sozinho. Ele conta com
uma legio de colaboradores para ajud-lo.
131

MC: Isso mesmo. O gerente de projeto no trabalha sozinho, e a
montagem de sua equipe fundamental para o sucesso dos
projetos.
PR: Quais os benefcios na montagem de uma equipe?
MC: Eu no diria benefcios e, sim, vantagens. Quando montamos
uma equipe, temos:
1. criatividade na soluo de problemas, por meio do enfoque
multidisciplinar;
2. especializao e diviso do trabalho, promovendo economias
de escala e aprendizagem bem como minimizando os custos do
projeto;
3. comprometimento da equipe com o sucesso do projeto, j que
este implica o sucesso pessoal de cada um deles.
DS: Mas montar uma equipe no deve ser uma tarefa fcil.
MC: Realmente no fcil, pois o gerente precisa administrar uma
equipe heterognea e multidisciplinar. Alguns autores identificam
cinco fases para a composio de uma equipe de projetos.
1 fase: formao: nessa fase, os membros da equipe podem no
ter papis claros e provavelmente no se conhecem ou se
conhecem apenas de cumprimentar. Nessa fase, existe um nvel
de desconfiana. importante que o gerente exera sua
autoridade formal para orientar a equipe;
2 fase: conflito: nessa fase, os membros da equipe podem
desafiar a autoridade do lder, j que a existncia do grupo tende
a limitar a sua expresso individual. So comuns nessa fase as
lutas de poder, determinando as relaes e hierarquia final do
grupo;
3 fase: normas: nessa fase, as regras de conduta ou normas
determinam papis e responsabilidades, criando um sentimento
de trabalho de grupo e coeso;
4 fase: desempenho: o grupo se transforma em equipe, onde cada
um dos membros se dedica a uma tarefa especfica, buscando
alcanar os objetivos do projeto; e
5 fase: encerramento: essa fase alcanada quando o projeto
encerrado, causando a dissoluo do grupo. O lder deve fazer
um balano da experincia, debater lies aprendidas, aprender
com os erros e se preparar para o prximo projeto.

PR: Realmente no uma tarefa fcil.
DS: Gerenciar pessoas muito difcil.
132

SB: Beleza. Montamos a equipe, desmontamos a equipe, mas
quais so suas funes?
MC: As funes da equipe do projeto so:
executar as atividades do cronograma fsico;
subsidiar o gerente com informaes do projeto;
dar suporte ao cliente;
na figura do relator, gerar e manter a documentao durante o
ciclo de vida do projeto, como e-mails e atas de reunies;
executar as decises requeridas para assegurar que os
objetivos do projeto sejam atingidos.

1.4 - Cliente

SB: Todos os stakeholders tm funes definidas?
MC: No necessariamente. Temos algumas funes esperadas ou
desejadas.
No caso dos clientes, temos as seguintes funes:
caracterizar a demanda e os produtos esperados com o projeto;
aprovar o escopo definido para o projeto;
aprovar as mudanas no projeto;
dar feedback sobre o desenvolvimento do projeto.
Para os fornecedores, esperamos as seguintes funes:
fornecer o produto segundo as especificaes contratuais;
informar sobre o andamento do projeto.

PR: Maria, um projeto pode ter stakeholders que sejam
especficos para sua realidade, e que no se apliquem a outros
projetos?
MC: Sim, Rocha. Como disse anteriormente, muito importante
identificarmos os stakeholders de cada projeto. S assim
poderemos nos antecipar as expectativas deles.
DS: Para mim, a importncia de identificar os stakeholders que,
alm de serem afetados pelo projeto, eles podem ter uma
influncia direta ou indireta no seu resultado. Uma falha nesta
identificao significar que o gerente de projeto no estar
pensando nas necessidades de todos os envolvidos, e isto um
fator de risco para o projeto.
MC: Voc est certssima, Delma. Posso dar dois exemplos
simples desta situao:
133

Um projeto que envolve uma obra em via pblica deve
considerar as necessidades da comunidade que ser afetada
pelo barulho e pelos transtornos (mesmo que a obra seja em
benefcio da comunidade), ou ser alvo de reclamaes que
podero levar a atrasos no cronograma.
Dentro de uma organizao, um projeto pode gerar um
resultado que fortalece algumas reas em detrimento de outras.
Mesmo que essas reas no participem do projeto, importante
entender as relaes de poder envolvidas, j que os que sero
afetados negativamente podero tentar boicotar o projeto.
Ao mesmo tempo, o gerente de projeto deve ter cuidado em no
procurar stakeholders por todos os lados, ou ficar com um
cenrio difcil de gerenciar. necessrio um limite lgico para a
identificao de quem afeta ou afetado pelo projeto.


134

2 - O Gerenciamento

SF: Boa tarde!
Todos: Boa tarde.
SF: Gostaram da apresentao do Sr. PMI?
MC: Sim, foi tima. Mostrou a todos a importncia da utilizao do
gerenciamento de projetos.
PR: Continuamos a conversar durante o almoo, e a Maria
reforou a apresentao do Sr. PMI, com vrias informaes que
nos sero teis no nosso dia-a-dia.
SB: Agora mesmo, estvamos conversando sobre os
stakeholders dos nossos projetos.
SF: Temos projetos de vrias dimenses e isso implica
stakeholders diversos. A satisfao dos envolvidos no projeto
funo de uma adequada e detalhada anlise de necessidades.
Assim, o gerenciamento de stakeholders uma atividade
eminentemente pr-ativa.
DS: Sem sombra de dvidas.
SF: Fiquem vontade. Um bom trabalho para vocs.
Todos: Obrigado (a)
MC: Devemos procurar incorporar as necessidades dos
stakeholders como parte integrante do escopo do projeto e os
requisitos dos mesmos como base para o gerenciamento da
qualidade e da comunicao.
DS: Eu entendo que, sem uma definio e entendimento comuns
entre os stakeholders, no h garantia de obteno de resultados
esperados porque os critrios para o sucesso no foram
compartilhados.
SB: Ento devemos elaborar tambm um planejamento para
gerenciar os stakeholders?
MC: No necessariamente. importante que o gerente de
projetos desenvolva um plano de como o projeto pretende
atender s expectativas do patrocinador e dos demais
stakeholders. Desta forma, ele conseguir coletar, entender e
gerenciar as expectativas de todos os stakeholders.
PR: Quais os passos o gerente de projetos dever seguir?
MC: No existe um roteiro pr-definido, mas os gerentes de
projetos, do meu ponto de vista, devem procurar:
1. identificar os stakeholders;
2. entender o conhecimento e habilidades dos stakeholders;
3. analisar o projeto, de forma a assegurar que as necessidades
135

dos stakeholders sejam atendidas;
4. mobilizar e envolver os stakeholders no projeto, por meio de:
alocao de trabalho para os stakeholders;
utilizao dos mesmos como especialistas;
informaes sobre o projeto;
envolvimento dos stakeholders em mudanas no projeto;
criao de lies aprendidas atravs dos mesmos;
5. obter a aceitao formal do projeto pelos stakeholders quando
do encerramento do mesmo;
6. diferenciar necessidades e desejos;
7. fixar metas e objetivos juntamente com os stakeholders. Deve-
se envolver os stakeholders criando um conjunto de metas e
objetivos realistas. Os stakeholders se envolvero mais com
metas e objetivos bem definidos desde o incio e ajudaro a
garantir o sucesso, principalmente se as metas e objetivos
apontarem para melhorar o desempenho empresarial;
8. negociar os deliverables (entregas): todos os projetos precisam
de um conjunto claro de deliverables dirigidos para alcanar as
metas e os objetivos do projeto. Estes devem ser comunicados
claramente aos stakeholders, e esforos devem ser feitos para
assegurar que haja uma compreenso clara relativa qualidade
e composio de cada deliverable.
9. garantir que o gerenciamento da comunicao seja claro com
os stakeholders. Uma vez que o projeto esteja em execuo, h
dois grupos das pessoas que precisam ser mantidos informados
sobre o progresso: o time de projeto e os stakeholders. O modo
mais efetivo de comunicar o progresso por meio de relatrios
de progresso regulares, os quais formam um registro til do
projeto e podem ser enviados por e-mail a todos os envolvidos ou
colocados em um repositrio central disponvel a todos.
PR: Maria, explique um pouco o que seria necessidades x
desejos.
MC: OK. Nos casos em que existam divergncias entre as
necessidades dos diferentes stakeholders, estas devem ser
solucionadas em favor do cliente do projeto.
Expectativas de stakeholders so mais ambguas do que
requisitos e podem estar implcitas de forma intencional ou no
intencional. As expectativas dos stakeholders devem ser
identificadas, documentadas e gerenciadas ao longo do ciclo de
vida do projeto, da mesma forma que os requisitos.
136

DS: Puxa, apesar do gerenciamento de stakeholders no ser uma
das nove reas de conhecimento, ela exige do gerente de
projetos o mesmo esforo e dedicao!
MC: Isso verdade. Mas, mesmo assim, como eu acabei de dizer,
o gerenciamento de stakeholders encontra-se presente em todas
as fases, ou seja, no incio do projeto, no seu planejamento, na
execuo e no encerramento.
SB: Gostei muito desta nossa conversa. Maria, voc no teria
nenhum livro ou texto que pudssemos ler para ajudar a
complementar esse assunto?
MC: Na realidade, saiu recentemente um artigo sobre
gerenciamento de stakeholders. Tenho uma cpia aqui no meu
computador. Vou encaminh-la para vocs, pois julgo importante
essa leitura.
Este artigo contempla o que acabamos de conversar. Tenho
certeza de que vocs iro gostar muito. (LEITURA
OBRIGATRIA: TEXTO Administrando Conflitos em Projetos, via
Gerenciamento de Stakeholders: prxima lio)
PR: Vamos colocar a mo na massa. Temos muito trabalho pela
frente.
SB: Maria, quando iremos conversar sobre a fase de
encerramento do projeto?
MC: Primeiro leiam o texto que indiquei e amanh retornaremos
com esse assunto.
SB: OK. Vamos ao trabalho.

Administrando Conflitos em Projetos, via Gerenciamento
de Stakeholders
Artigo publicado na Revista Mundo PM: nmero 16: Ago/Set 2007

Flvia Dias Moreira: Administradora: ESHO: Grupo Amil
Cristiane Jourdan: Mdica especializada em Endocrinologia e
bacharel em Direito: Amil Assistncia Mdica Internacional
Eduardo Andrade: Administrador Andrade: Seaworld
Mariela Baraibar: Bacharel em Comunicao Social: Universidad
DeLa Republica Del Urugay
Arthur Macedo: Engenheiro Civil: Amil Assistncia Mdica
Internacional

Abstract
137


Este artigo apresenta o importante papel do gerenciamento dos
stakeholders e seus interesses para o sucesso do projeto. Trata
as diversas habilidades do gerente de projetos no relacionamento
com os stakeholders, como: identificao e conhecimento dos
interesses dos stakeholders; estratgia de comunicao junto aos
envolvidos; desenvolvimento, motivao e apoio ao principal
stakeholder: a equipe; administrao dos conflitos de interesse; e
a importncia da inteligncia emocional associada s habilidades
tcnicas do gerente.
Os projetos surgem para atender s necessidades do mercado,
legislao, viso da empresa e so demandados essencialmente
pelo cliente/patrocinador. Este quando fica satisfeito significa uma
combinao vitoriosa, indicando que o produto/servio foi
entregue no valor e tempo certos e de acordo com as
expectativas. Porm, o cliente um dos stakeholders dentro dos
vrios envolvidos no projeto e, como os demais, requer
relacionamento especfico de acordo com seus interesses,
influncia e expectativas.
Os stakeholders so os envolvidos que influenciam o projeto (ou
so influenciados por ele) positiva e/ou negativamente de acordo
com seus interesses.
De acordo com dados do Benchmarking em Gerenciamento de
Projetos: RJ, COMPASS (2006), 33% dos erros e problemas em
projetos acontecem por falha de suporte e gerenciamento de
stakeholders. Pode-se atribuir diversas causas a essa falha, so
elas:
Pouca ateno dedicada ao melhor entendimento dos
envolvidos sobre o projeto durante a anlise de viabilidade e
planejamento.
Desconhecimento dos envolvidos e de seus interesses por parte
do gerente de projeto.
Por vezes, os gerentes de projetos no possuem habilidades
em comunicao, motivao, negociao, administrao de
conflitos e de liderana.
O gerenciamento de stakeholders abrange a identificao,
anlise, desenvolvimento de aes, comunicaes e interfaces
com cada um dos envolvidos no projeto.

138

O sucesso do projeto depende da participao de suas partes
interessadas e, por isso, necessrio assegurar que suas
expectativas e necessidades sejam conhecidas e consideradas
pelo gerente de projeto.

Os interesses e os objetivos

Podemos considerar como um dos fatores determinantes para o
sucesso ou fracasso de um projeto, o relacionamento que o
Gerente do Projeto tem com seus stakeholders, procurando
sempre atender a todos sem perder de vista o objetivo final do
projeto.
Segundo HELDMAN (2006), stakeholders so aqueles que tm
algo a ganhar ou a perder com a implementao do projeto e,
como tal, tm diferentes interesses, necessidades e objetivos.
Portanto, alm de cuidar para que tudo saia conforme o
combinado, atendendo s expectativas do cliente, o Gerente de
Projeto tem como uma de suas principais misses equilibrar os
diversos interesses dos stakeholders.
No relacionamento com os stakeholders, o gerente de projeto
deve traar um plano baseado nas seguintes tarefas:
Identificar quem so as partes interessadas no projeto.
Na fase de estudo de viabilidade e planejamento do projeto,
buscar sempre que os stakeholders tenham um bom
entendimento sobre o projeto.
Criar um mapa de avaliao, ou SAM: Stakeholders
Assessment Map, de ELLIOT (2001), para conhecer melhor os
interesses, objetivos, grau de influncia e responsabilidade de
cada envolvido.
Certificar-se da documentao e da comunicao do projeto,
identificando a melhor forma de atuar e trocar informaes de
acordo com as necessidades de cada envolvido.
Certificar-se de manter a informao organizada e filtrada.
fundamental ter cuidado com o excesso de informao. Ningum
gosta de ter de ler um relatrio inteiro para verificar um nico item
de seu interesse.
O mapa de avaliao de stakeholders deve conter as seguintes
informaes, conforme tabela 1:
139

Quem so os stakeholders-chave?
Quais so seus objetivos, metas, motivaes e interesses?
Qual o poder de influncia de cada um na organizao?
Qual a importncia e o impacto de cada um no projeto?
Quais os papis e responsabilidades de cada um no projeto?
Como trabalhar com cada um buscando o sucesso do projeto
(sintonia fina)?
Quais sero as estratgias adotadas na relao de cada
stakeholders-chave?

Tabela I: Mapa de avaliao dos stakeholders.
Fonte: Use these two forms to analyse your stakeholders, de
Elliot (2001).

Essas informaes podem ser verificadas junto equipe do
projeto, ao sponsor, documentao histrica, relatrios, atas,
apresentaes, observaes, network, entre outros, e exige
fundamentalmente habilidade emocional na busca pela melhor
forma de se relacionar e administrar os envolvidos no projeto.

A importncia da comunicao no relacionamento com os stakeholders

Alm de identificar e conhecer os interesses, objetivos e
motivaes de seus stakeholders, o gerente de projetos precisa
administrar as comunicaes para satisfazer s necessidades
das partes interessadas no projeto e resolver problemas com
elas.
Criar uma matriz de relatrios com critrios de distribuio de
informaes, ou SRM: Stakeholders Relationship Management de
ELLIOT (2001), fundamental para no se transmitir informaes
nem a mais nem a menos.
140

A matriz de relatrios deve conter as seguintes informaes,
conforme tabela 2:
Relatrios a receber (rea de interesse);
Volume/nvel de detalhe;
Melhor formato;
Freqncia;
Mecanismo de entrega.

Existem outras ferramentas tradicionais e vastamente conhecidas
que podem ajudar a traar planos de comunicao, como, por
exemplo, a anlise SWOT: Strenghts, Weaknesses,
Opportunities, Threats: dos envolvidos, que ajuda a identificar os
pontos fortes, fracos, as ameaas e oportunidades daquele
stakeholders perante o projeto.
Associado s habilidades tcnicas e ao conhecimento dos
envolvidos no projeto, o gerente de projeto precisa ter a
capacidade de se comunicar com eles e forma diferenciada,
considerando suas especificidades, objetivos e necessidades. A
comunicao uma das partes mais importantes em todo projeto
e o gerente de projeto o responsvel por fazer o projeto
acontecer, mantendo a comunicao transparente, precisa e
fluida.
Fluidez nesse caso significa troca de informaes e garantia de
que os stakeholders no tero dificuldade de entendimento das
mensagens recebidas e enviadas (feedbacks). O uso de uma
terminologia comum fundamental para o gerenciamento das
comunicaes em um projeto.
Segundo COUTO (2002), toda comunicao possui cinco
elementos bsicos: So eles:
Emissor: quem emite uma informao, o responsvel para
que as informaes cheguem ao receptor de uma forma
adequada, para este entend-las corretamente.
141

Receptor: a pessoa a qual a mensagem enviada. As
informaes so filtradas pelos receptores, por meio do
conhecimento que tm do assunto, influncias culturais, idioma
emoes, gestos, etc.
Mensagem: a informao enviada e recebida. Ela tem diferentes
tipos: oral, escrita e corporal, longa ou simples, etc.
Canal: o meio que ser utilizado para transmitir a mensagem.
Feedback: o retorno do receptor.
Devido s diversas formas de interpretao das mensagens
enviadas e recebidas, a comunicao bem conduzida base de
um projeto bem sucedido. A tarefa do gerente de projetos, nesse
contexto, identificar a forma que os stakeholders codificam e
decodificam as mensagens, para facilitar sue trabalho junto s
diversas formas de apresentao e transmisso a adotar.
A habilidade de comunicar no est s em saber transmitir e
codificar a mensagem corretamente, mas tambm em saber
ouvir.
A comunicao pode ser formal ou informal, oral ou escrita, ou
at corporal (a comunicao no-verbal compe mais da metade
da comunicao humana), mas apesar da comunicao oral ser
mais fcil que a escrita, esta mais adequada para transmitir
mensagens complexas, minuciosas e a muitas pessoas,
permitindo-se rev-las, ficam inesquecveis.

Administrando os conflitos

O conflito uma divergncia, formada por idias, objetivos e
relacionamento e personalidades diferentes, que cria uma
situao de oposio. Seja como colaborador, supervisor ou
subordinado, o ambiente de trabalho e as diferentes
metodologias e formas de produo de bens e servios, bem
como interesses pessoais, incrementam a possibilidade de atritos
de diversas naturezas.
Os conflitos esto diretamente relacionados a pessoas e crescem
de acordo com expectativas e objetivos particulares, sendo
agravados caso no estejam em sintonia com os objetivos do
grupo e do projeto. Tambm influem diferentes tipos de
personalidade, formao tcnica e culturas organizacionais.
Entretanto, os conflitos no so unicamente prejudicais. Certas
142

situaes podem inclusive, estimular a busca de solues
criativas para muitos problemas, proporcionando ganhos tanto
para o projeto quanto para os indivduos pessoalmente, seja na
forma de crescimento profissional seja na melhoria nos
relacionamentos.
Os conflitos so benficos quando estabelecem um desafio para
a busca de solues, motivam grupos a resolver problemas em
conjunto, aumentam o conhecimento aps a experincia,
melhoram a iniciativa dos integrantes do grupo e facilitam o
alcance do objetivo comum. Ao contrrio, quando uma situao
cria um ambiente de tenso e presso excessiva, tornando o
trabalho improdutivo, distorce o comportamento dos indivduos
gerando sensao de perda de confiana e permite
demonstraes de poder desnecessrias, o conflito prejudicial.
Um dos grandes desafios do gerente do projeto saber identificar
a existncia de conflitos e implementar as tcnicas adequadas a
cada caso para resolv-los da forma mais produtiva para a
equipe e, principalmente, em linha com os objetivos do projeto.
Segundo FERNANDES (2004), os conflitos possuem vrias
origens e classificamos nos seguintes tipos:

De ordem pessoal.
De relacionamento com outros indivduos.
De ordem organizacional.
Qualquer pessoa possui condies internas que, em dado
momento, influenciam seu desempenho e suas reaes, e podem
faz-las entrar em choque com seus pares.
Questes de ordem pessoal, psicolgicas, de difcil identificao,
so problemas complexos de resolver. Alm de prejudicar os
relacionamentos, influenciam tambm na vida diria da pessoa,
interferindo na capacidade de concentrao, no raciocnio, na
motivao e, principalmente, no equilbrio emocional.
Os conflitos de relacionamento com outros indivduos ocorrem
por opinies antagnicas, falhas na comunicao, problemas de
personalidade ou objetivos conflitantes. Todos tm necessidades
diferentes, entretanto, o reconhecimento do trabalho, a
valorizao como indivduo, a auto-estima, o respeito e a
143

segurana so caractersticas desejadas por todos e muito
necessrias para a manuteno do equilbrio.
Preservar valores e evoluir, profissional e pessoalmente,
determinante para o ser humano. Entretanto, os valores
constitudos atravs do desenvolvimento pessoal, no adiantam
se, em conjunto a eles, o indivduo no possuir a capacidade de
aceitar diferenas e encontrar caminhos satisfatrios de
convivncia com os outros.
Em complemento ao estado pessoal interno e as caractersticas
individuais, muitas vezes a razo dos conflitos est relacionada a
fatores ambientais. Novas diretrizes e polticas organizacionais,
reestruturaes, escassez de recursos, choques culturais,
influncias polticas, entre outros, so motivos muito encontrados.
Objetivos conflitantes entre grupos, departamentos e pessoas,
sejam de liderana ou no, criam e aumentam situaes de
tenso que exigem a adoo de tcnicas especficas de
administrao de conflitos.
A administrao de conflitos permite que uma soluo seja
encontrada e implementada, tanto para um simples problema ou
para causas complexas.
De forma geral, o enfoque deve ser sempre o da soluo. Atuar
de forma positiva, buscando o equilbrio no resultado entre as
partes fundamental para a conservao do estado de confiana
da equipe e manuteno dos objetivos do projeto.
O gerente de projetos , alm de um coordenador, um
negociador que deve ter grande capacidade de comunicao,
uma vez que, boa parte do seu tempo ser empregado nessa
tarefa.
Saber identificar caractersticas pessoais, comportamentos
situacionais e situaes de risco, ajudar a evitar conflitos
iminentes e extinguir os j existentes.
O conhecimento para identificar os tipos de comportamento de
cada um, seja Passivo, Agressivo ou Assertivo, associados aos
tipos de poder, como Coercivo, Recompensador, de Conexo,
Legtimo, de Informao, de Referncia ou Especializao e,
dessa forma, encontrar a soluo adequada, parte fundamental
das habilidades do gerente de projetos. Ele dever julgar qual a
144

melhor alternativa considerando os tipos de comportamento e
poder variados.
Alm da capacidade acima descrita, dificilmente um gerente de
projetos poder desempenhar bem suas funes se no possuir
a capacidade de ser um bom negociador.
Um bom negociador deve conhecer muito bem a realidade de
cada um dos envolvidos, conhecer com profundidade o problema
e estar preparado para enfrentar os desafios para identificar
solues. Na mesma linha, ter a competncia para identificar
solues.
Na mesma linha, ter a competncia para identificar cenrios,
possuir conhecimento do assunto e saber se relacionar, so
habilidades que permitiro ao gerente a correta insero no
contexto do problema. Para identificar os cenrios, necessrio
ter a capacidade de interpretar questes de ordem pessoal,
psicolgicas, familiares, culturais e econmicas. Conhecer o que
est sendo negociado facilitar a distino entre o que bom e o
que no como alternativa. Em complemento, e como fator
crtico para o xito na negociao, est o relacionamento
interpessoal.
A fuso entre a habilitao tcnica, as competncias de
comunicao, negociao e as tcnicas de administrao de
conflitos, ir proporcionar a identificao das melhores
alternativas e a concluso das negociaes atravs da adoo da
melhor soluo, de forma convincente e satisfatria, apoiada em
argumentos legtimos e coerentes.

A equipe: o principal stakeholder

O principal stakeholder em todos os projetos a equipe envolvida
na execuo do projeto. Todo projeto deve se iniciar pela perfeita
compreenso do seu escopo, ter uma boa idia do mercado onde
se insere e conhecer em detalhes o papel, as caractersticas e as
responsabilidades da equipe envolvida.
Equipe um conjunto de pessoas diferentes, com personalidades
diversas, motivadas a uma misso e objetivos comuns por um
lder. Cabe ao gerente de projeto assumir este papel de liderana
junto equipe.
145

A formao da equipe de projeto deve considerar as
competncias individuais necessrias para o desenvolvimento
das atividades e alcance das metas. Os indivduos da equipe
devem ser escolhidos com base em sua capacidade reconhecida
de exercer a funo necessria, e talvez, e ainda mais
importante, sua capacidade de atuar em conjunto de forma a
potencializar a capacidade individual dos integrantes da equipe.
Com uma equipe entrosada e atuando em sinergia, haver a
multiplicao das capacidades individuais e a garantia de um
projeto bem-sucedido.
O gerente de projeto exerce um papel fundamental de liderana.
Segundo COUTO (2002), ele responsvel pelos aspectos da
administrao das personalidades e dos egos envolvidos e, por
isso, deve atentar para os diversos aspectos fundamentais ao
sucesso do projeto:
Motivao. Um dos pontos cruciais do papel de liderana a
motivao do time. Somente com uma equipe motivada que se
completa um objetivo. Pessoas motivadas executam trabalhos de
qualidade e mantm um compromisso com o resultado. O
gerente de projetos deve possuir a capacidade de percepo
para medir o grau de envolvimento dos integrantes, assim como o
resultado dos seus trabalhos.
O acompanhamento e avaliao da consecuo das aes do
projeto de acordo com as responsabilidades especficas de cada
integrante passam necessariamente pela sensibilidade do
gerente em perceber, assimilar e reconhecer o grau de motivao
e de resultados gerados pela equipe.
Comunicao. Cabe ao lder da equipe estabelecer e gerenciar a
comunicao, de forma clara e transparente. As informaes
devem fluir livremente na equipe, que deve se sentir informada e
com um bom canal de comunicao. Manter um bom canal de
comunicao com informaes de tudo que acontece e das
modificaes porventura realizadas um feedback esperado no
trabalho de equipe. Cabe no item comunicao, a gesto do
conhecimento do projeto para a formao de quadros
capacitados, incrementando os ativos intangveis da organizao
e facilitando a execuo do projeto.
Ambiente. O ambiente de trabalho tambm considerado um
fator decisivo para o sucesso de um projeto. Deve ser percebido
146

pela equipe um ambiente flexvel, agradvel, criativo e
incentivador das realizaes pessoais. A questo do clima
organizacional e conseqentemente do ambiente de projetos e
fundamental para o aumento da melhoria da qualidade do
trabalho e eficincia das aes-chave do projeto. Quando um
indivduo se sente mais confortvel num ambiente de trabalho,
gasta menos energia na sua defesa e a desvia para o
desempenho de suas atividades tornando-se satisfeito com seu
trabalho e membro ativo de uma equipe.
Criar mecanismos de motivao e desenvolvimento da equipe,
manter um canal de comunicao em ambas as direes, cuidar
do ambiente de trabalho so atitudes que contribuem para a
manuteno de uma equipe engajada no sucesso da empreitada.

A inteligncia emocional no relacionamento com os stakeholders

Cada vez mais, no somente no campo profissional, mas tambm
no pessoal, a inteligncia est associada ao controle das
emoes. A capacitao tcnica no mais suficiente para que
algum desempenhe suas funes plenamente.
O melhor desempenho das habilitaes tcnica, humana e
conceitual est condicionado tambm capacidade de controle
das emoes. A competncia emocional deve ser desenvolvida e
aplicada no ambiente pessoal e profissional. Trabalhar, e viver, ,
acima de tudo, ter a capacidade de se relacionar de forma
positiva e satisfatria com outras pessoas e com o ambiente.
Controlando melhor os impulsos emocionais, ser possvel ser
melhor sucedido profissionalmente e como indivduo, contribuindo
para o desenvolvimento do grupo e do projeto.
De acordo com GOLEMAN (2001), a empatia alimentada pelo
auto-conhecimento; quanto mais consciente estivermos acerca
de nossas prprias emoes e do controle delas, mais facilmente
poderemos entender o sentimento alheio. Portanto, desenvolver
empatia com os stakeholders ajuda a entender como eles
enxergam a cena, como enxergar um mesmo fato sob diversos
pontos de vista.
Por diversas vezes, o apego a pequenos detalhes afastam o foco
da questo principal e da sua correspondente soluo. A busca
por resultados finais favorveis atravs do entendimento do
147

contexto e como cada deciso afetar as partes, proporcionar o
entendimento real da questo e a identificao da melhor
proposta.
Alm disso, empresas com maior grau de maturidade tcnica em
gesto de projetos esto se voltando gesto comportamental
em vez da gesto tcnica, em que a liderana situacional, de
HERSEY e BLANCHARD (1986), est em voga. Segundo
HELDAMN (2006), a caracterstica fundamental para o sucesso
na gesto de projetos a tolerncia em relao a eventos
externos e tolerncia em relao personalidade das pessoas.
Na liderana situacional, a empatia motor das relaes com
os stakeholders, pois nela o gerente de projeto lida com situaes
diferentes das lideranas funcionais.
Seguem alguns exemplos de situaes:
Relacionamentos de mltipla subordinao.
Escassez de autoridade real.
No participao na avaliao de desempenho dos funcionrios.
Posio temporria devido a natureza do projeto.
Posio hierrquica inferior a do liderado no projeto.

Consideraes finais

Atualmente, as empresas bem-sucedidas consideram que o
fracasso de um projeto se deve na maior parte das vezes as
questes comportamentais, sendo elas; desmotivao dos
membros da equipe; relacionamentos interpessoais negativos,
baixa produtividade, comunicaes truncadas e ausncia de
comprometimento com os objetivos do projeto.
O gerenciamento pr-ativo dos stakeholders aumenta a
probabilidade do projeto no desviar de seu curso por causa de
problemas no resolvidos dos mesmos, alm disso, aumenta a
capacidade das pessoas operarem em sinergia e limita
interrupes durante o projeto.
Ter a capacidade de minimizar conflitos e encontrar alternativas
positivas e viveis para todos o desafio constante. Dessa
forma, habilidades como comunicao, inteligncia emocional,
administrao de conflitos, negociao, motivao e
148

desenvolvimento da equipe so requisitos bsicos exigidos ao
bom gerente de projetos.
Encerramento do Projeto

No dia seguinte

MC: Bom dia a todos! E a, gostaram dos textos que eu passei
para vocs?
DS: Como disse o Pedro e pelas nossas conversas, temos muito
trabalho pela frente. Os textos ajudaram muito a clarear algumas
dvidas.
PR: Para mim, que estava bem receoso, achei a leitura muito
produtiva.
SB: OK. Tenho que admitir. Todo este assunto muito
interessante. Muita coisa para fazer, mas sem dvidas ir
contribuir muito para o nosso dia-a-dia. Vamos ao trabalho.
DS: At que enfim, Been. Voc agora percebeu a importncia
deste processo.
PR: Antes tarde do que nunca.
149

DS: Elaboramos, planejamos, executamos e avaliamos projetos.
E agora? O que falta conhecermos sobre gerenciamento de
projetos?
MC: Lembra-se do ciclo de vida?
DS: Sim. Concepo, Planejamento, Execuo e Controle, bem
como Encerramento.
MC: Ento agora encerraremos o projeto. Dessa forma,
abordamos todos os processos do ciclo de vida de um projeto.
PR: O que fazemos primeiro?
MC: Esta ltima fase, ou ltimo processo, consiste da
formalizao do aceite do projeto e so encerrados os contratos
gerados durante sua execuo. Outro ponto importante consiste
da medio e anlise dos resultados aps seu encerramento.
SB: Acabou o projeto. timo. Toda a documentao gerada,
todos os problemas solucionados, o que fazemos com essas
informaes?
MC: Registramos e documentamos como Lies Aprendidas.
PR: Mas como fazemos tudo isso?
MC: Vamos com calma. Uma coisa de cada vez.

1 Encerramento de contratos (encerramento administrativo)

SB: Como dizem os mineiros vamos comer o boi aos bifes.
PR: Been, no hora de brincadeiras.
MC: No esquenta, Rocha. Como eu estava dizendo, esta a
ltima etapa do gerenciamento de projetos. uma etapa muito
simples, no entanto uma etapa muitas vezes esquecida ou
negligenciada.
PR: Como assim esquecida?!
MC: A etapa final da conduo de um projeto geralmente
negligenciada pela maioria das empresas. Ao aproximar-se o
trmino dos trabalhos, os membros da equipe vo sendo
desligados e alocados em outras atividades; alm disso, existe a
tendncia natural de relaxamento com a falta de exigncias de
prazos que a etapa de execuo vinha demandando.
150

Muitos gerentes de projetos entendem que, aps a entrega do
projeto, este j est encerrado, e que mais nada precisa ser feito.
No existe uma cobrana formal para o encerramento do projeto.
PR: O que o encerramento administrativo?
MC: O encerramento administrativo consiste em documentar os
resultados do projeto para formalizar a aceitao do produto do
projeto pelos patrocinadores ou clientes. Isso inclui:
a coleta dos registros do projeto, garantindo que eles reflitam as
especificaes finais;
anlise do sucesso, efetividade do projeto;
lies aprendidas e o arquivamento dessas informaes para
uso futuro.
As atividades do encerramento administrativo no devem ser
retardadas at a concluso do projeto. Cada fase do projeto deve
ser apropriadamente encerrada para assegurar que as
informaes teis e importantes no sejam perdidas.
DS: Voc poderia explicar melhor?
MC: Claro. Vou tratar este assunto apresentando os
procedimentos desta fase. Acredito que assim o entendimento
seja melhor.
Em primeiro lugar, temos o Procedimento de encerramento
administrativo. Esse procedimento consiste das atividades para
encerrar o projeto internamente na organizao.
PR: Quais so essas atividades?
MC: Trata-se da Documentao da medio do desempenho,
Documentao do Produto e outros registros inerentes ao projeto.
DS: D alguns exemplos.
MC: Temos ento:
1. Documentao da medio do desempenho: toda a documentao
produzida para registro e anlise do desempenho do projeto,
incluindo os documentos de planejamento que estabeleceram a
estrutura da medio do desempenho, deve estar disponvel para
revises durante o encerramento administrativo.
2. Documentao do produto: os documentos produzidos para
descrever o produto do projeto (planos, especificaes,
documentao tcnica, plantas, arquivos eletrnicos, etc.) devem,
tambm, estar disponveis para revises durante o encerramento
administrativo.
3. Outros registros do projeto: os registros devem incluir
151

correspondncias, memorandos, relatrios e outros documentos
que descrevem o projeto. Essas informaes devem, na medida
do possvel, ser mantidas de modo organizado. Relatrios
formais do status do projeto e/ou pendncias. E tambm
Apresentaes do Projeto, onde a equipe do projeto fornece
informaes formalmente e informalmente, para alguns ou todas
as partes envolvidas no projeto. A informao relevante para as
necessidades de audincia e o mtodo de apresentao
apropriado.
DS: Esta documentao reunida compe o encerramento
administrativo.
MC: Exatamente. Mas temos tambm o Procedimento de
encerramento de contratos, que aborda os termos e condies
para finalizar os contratos de fornecimento realizados durante o
projeto.
Para os projetos nos quais se faz necessria a aquisio de bens
e servios e, portanto, o gerenciamento de contratos entre cliente
e fornecedor, tambm de suma importncia o adequado
encerramento do contrato.
PR: O encerramento de contratos em gerenciamento de projetos
diferente do encerramento no caso de aquisies nos nossos
processos internos?
MC: Na verdade, basicamente a mesma coisa. Mas alguns
aspectos devem ser levados em conta.
PR: Quais aspectos?
MC: So basicamente os seguintes:
a documentao para encerramento do contrato;
Nota de Resciso (quando for o caso),
verificao de conformidade com procedimentos;
auditoria de aquisies;
aceitao e pagamento final; e
arquivo do contrato.
DS: Voc poderia explicar um pouco mais?
MC: Vamos l.
(O texto a seguir foi extrado do seguinte livro: XAVIER, Carlos Magno da Silva et.
al. Gerenciamento de Aquisies
em Projetos. Rio de Janeiro: Editora FG, 2007)


A documentao para encerramento do contrato
152

So documentos necessrios para o encerramento do contrato,
sob as perspectivas tanto do contratante quanto do contratado.
So exemplos de documentos usados no encerramento de
contratos:
emitidos pelo contratante relatrio de encerramento do
contrato e termo de aceite;
emitidos pelo contratado atestado de inexistncia de
reivindicaes e relatrio de encerramento do contrato.

Nota de resciso

A nota de resciso um instrumento emitido unilateralmente pela
parte contratante que se sentiu prejudicada, independente de
notificao judicial ou extrajudicial. Ela , portanto, uma
notificao para cancelar o contrato, decorrente da quebra do
mesmo.

Verificao de conformidade com procedimentos

necessrio verificar se os procedimentos estabelecidos para
encerramento do contrato sob o prisma administrativo foram
observados. Por exemplo, no caso do cliente, no se deve
proceder ao pagamento final do fornecedor se este no houver
concludo todos os procedimentos administrativos estabelecidos
no contrato, tais como: devoluo de ativos de propriedade do
contratante, encerramento e ajustes com subcontratados e
adequada disponibilizao de aspectos considerados propriedade
intelectual.

Auditoria de aquisies

Auditorias de aquisies so uma anlise estruturada de todos os
processos de aquisies desde a deciso de contratar ou no at
o encerramento de contratos, visando identificao de lies
aprendidas e correo de procedimentos. So identificados os
pontos positivos e os negativos (lies aprendidas), que podero
ser aplicados na aquisio de outros itens do projeto em questo
ou at em um novo projeto.

Aceitao e pagamento final
153


O cliente procede aceitao formal dos produtos ou servios
objeto do fornecimento e efetiva o pagamento final ao fornecedor.
verificado se todos os produtos e servios constantes do
escopo do contrato foram entregues.
O fornecedor, aps o recebimento da ltima fatura, deve fazer a
liberao de seguros-garantia ou carta de crdito.

Arquivo do contrato

A equipe do projeto deve manter uma srie de pastas, ou um
arquivo, como referncia do contrato, com finalidade de facilitar
auditorias ou revises. A pasta e o ndice representam a atividade
de um contrato com um fornecedor. O ndice mnimo para uma
pasta do contrato :
RFP (Request for proposal) documento de solicitao de
cotao;
Contrato;
Cronogramas;
Alteraes solicitadas e aprovadas;
Documentaes tcnicas;
Aditivos ao contrato;
Ordens de trabalho;
Aprovao dos deliverables;
Correspondncias do contrato;
Avaliaes do contratado;
Relatrios de desempenho;
Cpias das faturas e pagamentos;
Resultados de fiscalizaes.

A destruio dos arquivos relacionados com o fornecimento de
produtos e servios s dever ser efetivada pelas empresas
contratantes depois de ultrapassado o perodo de garantia
contratual ou legal. Uma vez reivindicada a responsabilidade de
qualquer das partes neste particular, elas podero se defender
utilizando todos os elementos e documentos gerados no mbito
da referida contratao.
SB: Nossa, isto que explicao, o resto bobagem.
MC: Encerramento administrativo, Encerramento de Contratos...
Estou sentido falta do Encerramento junto ao nosso cliente. Estou
certa? Falta essa etapa?
154

MC: a minha prxima explicao.

2 - Formalizao do encerramento

SB: Voc parece que l nossos pensamentos, Maria.
MC: No isso. Apenas as explicaes seguem uma linha de
raciocnio, em que as etapas so complementares.
PR: Been, deixa a Maria continuar as explicaes.
SB: Est bem. Eu deixo.
MC: Todo projeto tem um cliente, que a pessoa ou entidade que
demandou o projeto. Dessa forma, para esse cliente, a fase de
concluso uma das mais importantes, uma vez que nela que
se dar a entrega final dos produtos e servios gerados.
A fase de encerramento do projeto conduzida de forma que os
produtos e servios constantes do escopo delineado sejam
disponibilizados para o cliente, sendo que esse momento
acompanhado da caracterizao e oficializao da concluso e
aceitao do projeto.
DS: A formalizao do encerramento acontece somente por
ocasio do trmino do projeto?
MC: No.
SB: Como no?!
MC: Um contrato pode ser encerrado, no s quando termina a
execuo, mas das seguintes formas:
em primeiro lugar, pelo trmino das atividades estabelecidas
contratualmente (terminao);
pelo acordo mtuo entre as partes; ou
pela no-observncia das obrigaes contratualmente
estabelecidas.

DS: Maria, eu entendo que o encerramento do contrato acontea
pelo trmino das atividades contratadas, mas os demais
encerramentos, como se caracterizam?
MC: Vou explicar como se d todos os encerramentos.
(O texto a seguir foi extrado do seguinte livro: XAVIER, Carlos Magno da Silva et.
al. Gerenciamento de Aquisies
em Projetos. Rio de Janeiro: Editora FG, 2007)
155


O trmino das atividades estabelecidas no contrato, tambm chamado
de terminao, se caracteriza pelo encerramento natural do
contrato, em decorrncia do trmino de todas as obrigaes ali
estabelecidas. As partes satisfeitas acertam as pendncias finais
e do-se quitaes mtuas para nada mais reclamarem uma da
outra, seja a que ttulo for, por si, seus herdeiros e sucessores.
Nessa oportunidade, o cliente emite a aceitao definitiva do
fornecimento e paga a integralidade do preo. Assim, se o
fornecedor tiver apresentado qualquer tipo de garantia (por
exemplo, uma cauo bancria), esta retorna para o seu
patrimnio, ou parte dela liberada, ficando apenas um
percentual para dar cobertura garantia que ultrapassa o prazo
do contrato e se estende at o trmino do perodo e vigncia ali
estabelecido. A situao se caracteriza pelo desempenho
satisfatrio das partes, que se configura pelo fiel cumprimento de
todas as condies contidas no escopo do trabalho.
O acordo mtuo entre as partes, tambm chamado de resilio,
a condio que envolve a vontade de ambas as partes na
extino do contrato e que abrange no s a terminao, mas a
156

resoluo. So situaes em que as partes podem concordar em
encerrar o contrato, mesmo que os objetivos iniciais no tenham
sido atingidos. Nessa hiptese, as partes contratantes acertam a
forma de concluso dos trabalhos pendentes, o recebimento de
parcelas devidas e o perodo predeterminado, quando elas se
obrigam a dar total quitao para as pendncias cumpridas.
Neste caso, o cliente poder contratar a finalizao dos servios
junto a terceiros, no podendo o ex-fornecedor exigir qualquer
indenizao, seja a que ttulo for.
A no-observncia das condies no contrato, ou Resoluo e
Resciso, efetivam-se de forma unilateral e independente de
notificao judicial ou extra-judicial, gerando, como
conseqncia, o direito da parte prejudicada de exigir da outra o
pagamento de indenizao por danos morais e/ou materiais.
Resoluo o evento que resolve o contrato em decorrncia do
descumprimento de suas clusulas e condies, porm
estabelece um prazo de aviso prvio para que as atividades em
andamento sejam concludas. Resciso a ruptura do ajuste por
interesse de uma das partes, por descumprimento das
obrigaes pela outra.

PR: Maria, existe algum modelo ou formulrio padro para
utilizao na formalizao do encerramento do contrato?
MC: Eu expliquei, de forma genrica, a formalizao do
encerramento de todos os contratos. Cada empresa estabelece,
de acordo com a metodologia estabelecida, como ocorrer a fase
de encerramento dos projetos.
Existem alguns modelos. Tenho aqui um modelo de Termo de
Encerramento de Projetos para vocs verem.
157


158

3 - Documentao das lies aprendidas

SB: Ento, pela lgica, temos agora que documentar tudo o que
ocorreu com o nosso projeto?
MC: Isto mesmo, Been. Agora hora de registrarmos toda a
aprendizagem obtida no processo de realizao do projeto. Esse
documento tambm chamado de registro das lies aprendidas.
PR: Como fazemos isso?
MC: simples. Como disse agora mesmo, muito importante que
Cada fase do projeto deve ser apropriadamente encerrada para
assegurar que as informaes teis e importantes no sejam
perdidas. Dessa forma j estamos armazenado as informaes
para o relato final.
A teoria diz que documentar lies aprendidas uma atividade
importantssima durante qualquer projeto. Qualquer gerente de
projeto concordar com isso, mas nem sempre esta atividade
realmente executada com a seriedade necessria.
DS: Sendo um aspecto to positivo, por que isso acontece?
MC: fcil entender porque as lies aprendidas so muitas
vezes deixadas de lado:
Presses para cumprir prazos: leva o gerente a se preocupar
mais com as atividades diretamente relacionadas ao produto do
projeto. Lembrem-se, eu falei que a fase de execuo e controle
mais cobrada, mas, depois de o produto ser entregue, existe
um relaxamento natural.
Mudana de foco ao terminar um projeto: as pessoas e
organizaes acabam mais concentradas no prximo projeto do
que no fechamento correto do projeto anterior.
Falta de interesse da alta gesto neste tipo de documentos.
Problemas culturais na empresa: levam o gerente a acreditar
que documentar lies aprendidas uma perda de tempo, j que
no ter verdadeira influncia sobre os prximos projetos da
organizao.

SB: Ns sabemos que isso no verdade. Pelos princpios da
qualidade, toda documentao importante para rastreamentos e
confiabilidade das informaes. o que chamamos de fatos e
dados. Dessa forma aprendemos com os nossos erros.
MC: Muito bom, Been. Mas, como acabei de dizer, um problema
de cultura. Cabe a ns, da equipe de projeto, no deixar que isso
159

ocorra e efetivamente trabalhar para uma boa documentao das
nossas atividades.
PR: Para mim, eu entendo que independente de todos esses
fatores, o gerente de projeto deve entender que as lies
aprendidas so uma ferramenta essencial para seu crescimento
profissional e para a melhoria contnua da organizao.
SB: Falou o filsofo Rocha. Muito bom.
DS: Been, no comea.
MC: Vejo que vocs esto bem afinados com o nosso propsito.
Resumindo o que acabamos de falar, o registro das lies
aprendidas muito mais do que um documento para cumprir a
formalidade do projeto. So as informaes que permitiro que os
erros passados no se repitam e os acertos possam ser feitos
novamente.
DS: Por isso importante registrar tanto as boas quanto as ms
experincias do projeto. Esses registros ajudaro a moldar as
atividades e controles dos projetos futuros.
MC: Isso mesmo.
PR: Qual a melhor forma de fazermos isso?
MC: Segundo Luiz de Paiva, Consultor em Gerenciamento de
Projetos, a forma de fazer a documentao de lies aprendidas
varia muito de uma empresa para outra (ou de um projeto para
outro). A maioria das empresas, mesmo as que adotaram o
gerenciamento de projetos de uma forma ou outra, no possuem
uma forma nica de criar esses registros. Cabe ao gerente de
projeto tomar a iniciativa para criar algo que seja:
til: se a informao no ajudar a empresa, equipe e gerente
nos prximos projetos, provavelmente no vale a pena registr-la.
prtico: a forma de registro deve ser simples, ou a burocracia
tornar difcil o acompanhamento das lies aprendidas.
compreensvel: importante que o gerente lembre que as
informaes so para todos e que no deve cometer o erro de
documentar as informaes de tal forma que somente ele
compreender.
DS: Na nossa metodologia, temos algum modelo que devamos
seguir?
MC: Temos, sim. Nesse modelo, avaliamos as reas de
conhecimento em relao ao projeto executado.
DS: Como seria esse modelo?
MC: Aqui est. Nele descrevemos os aspectos positivos e
negativos em relao a cada item analisado.
160


161


PR: Esse modelo vai nos ajudar muito.
DS: Com certeza.

4 - Anlise de indicadores de desempenho

SB: Maria, terminamos ou j falamos de todas as etapas?
MC: Falamos de tudo. Voc est sentindo falta de mais alguma
coisa?
SB: Estou, sim. Da anlise dos nossos indicadores de
desempenho.
MC: Been, muito bem lembrado. Eles tambm compem a lista do
encerramento dos projetos.
DS: Mas os indicadores no esto contidos no plano de qualidade
e so avaliados constantemente para realizarmos o ciclo PDCA?
MC: Isto mesmo, Delma. No entanto, ao encerramos o projeto,
necessrio apresentar os resultados obtidos atravs da anlise
desses indicadores.
PR: Mas existem indicadores especficos para essa anlise final?
MC: No. Depende de cada empresa. Para o nosso trabalho de
gerenciamento de projetos, utilizaremos os indicadores de custo,
prazo e receitas. Assim temos:
162


PR: Esses so os indicadores mais avaliados hoje.
SB: Sem sombra de dvidas.
MC: isso a, pessoal. Hora de colocar a mo na massa.
DS: J temos alguma demanda especfica?
MC: Temos sim, Delma.
DS: O que ?
MC: O Sr. Fortunato quer que elaboremos um Curso sobre
Gerenciamento de Projetos para divulgao na empresa. E a,
vocs aceitam o desafio?
Todos: Claro que sim.
MC: Ento mos--obra. Primeiro passo?
SB: Elaborao do projeto para aprovao do Sr. Fortunato.
MC: Depois?
DS: Projeto aprovado, hora de planejarmos.
PR: Vamos agora executar.
MC: Isso a. Vamos depois registrar o nosso trabalho. Parabns.
Vejo que entramos em sintonia.
PR: Parabns a voc, que tanto contribuiu para que
aprendssemos a importncia deste trabalho.
DS: Concordo com o Pedro.
SB: Eu tambm.
MC: Obrigada. Ento vamos deixar de conversa e comear a
escrever o nosso primeiro projeto na metodologia da nossa
empresa.

Bibliografia/Links Recomendados

VERZUH, Eric. MBA Compacto: Gesto de Projetos. 5 ed.
Rio de Janeiro: Campus, 2000. 398 p.
DINSMORE, Paul C. Gerncia de Programas e Projetos. So
Paulo: Pini, 1992. 176 p.
CLELAND, D. I.; IRELAND, L. R. Gerncia de Projetos. Rio
de Janeiro: Reichmann & Affonso, 2002.
163

HARRIS, Simon. Powerful Magic with Gantt-Charts,
Microsoft Project and Excel. Project Manager Today, [s.l.], [s.n.], p.
27-29, may 2010. [Apresenta vrias dicas no uso das ferramentas
de gerenciamento de projetos da Microsoft.]
JOHNSON, Ben; GARAGNA, Luciano. Frequently Forgotten
Work Packages. Project Manager Today, [s.l.], [s.n.], p. 24-25,
jan.-feb. 2010. [Lista atividades comuns em muitos projetos mas
que no costumam ser explicitadas nos cronogramas e EAPs.]
VARGAS, Ricardo V. Gerenciamento de Projetos:
Estabelecendo Diferenciais Competitivos. 6 ed. Rio de Janeiro:
Brasport, 2005.
Vargas, Ricardo. Plano de Projeto 3.ed. Rio de Janeiro:
Brasport, 2007.


















164