Introduo

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 dentidade 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 niciativas Estratgicas, que so Programas e Projetos definidos como
prioritrios para o alcance dos resultados pretendidos.
MC: Sr. PM, 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.
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.
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.
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.
nicialmente 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
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:
Hoje o gerenciamento de projetos envolve: Tempo, Prazo, Custos, Escopo, RH e
Riscos, nformao (Comunicao e Qualidade). De maneira em que todos estejam
interligados.
O ra!al"o nas Organi#a$es
Como funciona o gerenciamento de projetos nas organizaes? Todas trabalham por
projeto ou com processo?
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:
%&: 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
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:
Uma demanda de mercado;
Uma necessidade de negcio;
Um pedido do cliente;
Um avano tecnolgico;
Uma exigncia legal;
Uma necessidade social;
Uma necessidade ambiental.
As categorias mais conhecidas de projetos so:
Administrao;
Pesquisa e Desenvolvimento;
Design;
Construo;
Manuteno;
nformtica;
Desenvolvimento de Novos Produtos;
Eventos;
nstalao de Equipamentos;
Melhorias.
Metodologia de Gerenciamento de Projetos
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.
'ma metodologia de Gerenciamento de Projetos tem (ue:
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 nstitute PM;
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;
Estabelecer que projetos devem ser apoiados por um Escritrio de Projetos.
&): Agora no entendi nada. Sr. PM, ser que poderia explicar melhor as siglas e
conceitos acima?
PMI: Perfeitamente. remos para um pequeno intervalo do caf e retornaremos com a
descrio geral de alguns itens importantes para o gerenciamento de projetos.

C*EGO+I*& %E P+O,EO&
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]:
*%MI-I&+*./O
Estes projetos esto acontecendo freqentemente na vida de qualquer organizao. Alguns
exemplos:
Campanha para reduo de custos;
Campanha de desburocratizao;
Reorganizao de um departamento;
mplementao de tcnicas de GQT (Gerncia pela Qualidade Total).
PE&0'I&* E %E&E-1O21IME-O
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 ADS.
%E&IG-
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 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.
nstrues 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.
CO-&+'./O
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.
M*-'E-./O
Estes projetos consistem em desmontar e reconstruir uma 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.
I-3O+M4IC*
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.
%E&E-1O21IME-O %E -O1O& P+O%'O&
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.
E1E-O&
Devido ampla aceitao da importncia da realizao de 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.
I-&*2*./O %E E0'IP*ME-O&
Um projeto de instalao de um equipamento pode envolver inmeras aes. Por exemplo, a
instalao de um grande computador envolve:
nstalao de ar condicionado em um prdio, supermercado, etc.;
nstalao de equipamentos de automao.
ME2HO+I*&
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;
Diminuio de perdas de peas que se quebram em uma linha de produo.
Conceitua$es
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.
SB: A que mora o perigo!!!
MC: Como disse o Sr. PM, 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 PM
SF: Sejam bem-vindos de volta ao nosso encontro. Espero que tenham aproveitado
esse intervalo para assimilar um pouco mais as informaes j repassadas.
PM: 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 PM.
PR: (Em pensamento) L vem ele de novo com essas siglas.
PM: Mas o que PM?
O PM - Project Management nstitute hoje a maior instituio no mundo
exclusivamente dedicada ao fomento da atividade de Gerenciamento de Projetos. Criada em
1969 na Pensilvnia, Estados Unidos, conta hoje com mais de 200.000 filiados distribudos em
cerca de 140 pases. O PM 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 PM. Hoje so aproximadamente 300 captulos.
Com o passar do tempo, o PM 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
PM. Esses produtos e servios esto detalhados no site do PM, que vocs podem acessar
a qualquer momento. O site www.pmi.org. Vou entregar a vocs tambm um arquivo (LNK)
com o detalhamento desses produtos e servios.
2 conceito PMBOK
PM: 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.
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 PM?
PM: Sim. Segundo PM 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.
DS: Mas quais so as principais caractersticas de um projeto?
PM: 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?
PM: 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
PM: Falei, na primeira parte do nosso encontro, sobre metodologia de gerenciamento
de projetos. Agora explico a vocs o que gerenciamento de projetos.
Segundo PM 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 diferentes preocupaes e
expectativas das diversas partes interessadas.
SB: Em resumo, para gerenciar projetos, temos que ser um super-heri.
MC: Mas gerenciamento de projetos s isso?
PM: 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.
PM: 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 infraestrutura e melhoria interna de processos. Programas
tambm envolvem sries repetitivas ou cclicas de aes.
Exemplos:
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?
PM: Exatamente. Em outras palavras, o sucesso do programa diretamente
proporcional ao sucesso dos projetos que o compem.
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?
PM: 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?
PM: 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?
PM: 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:
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.
7 conceito Convnios
PR: Trabalhamos hoje com um volume grande de convnios. Podemos considerar que
cada convnio um projeto?
PM: 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 organizaes particulares, para a realizao de objetivos
de interesse comum dos partcipes.
PM: 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?
PM: 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.
8 conceito Contratos
DS: Podemos dizer que convnio o mesmo que contrato?
PM: 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.
PM: sso 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 ncio estar disposio para quaisquer esclarecimentos que
vocs necessitem tendo em vista o bom desenvolvimento de suas tarefas. Desejo a vocs um
timo trabalho.
Organi#ao do Gerenciamento de Projetos
56 7 Ciclo de 1ida
MC: Vocs conseguem observar que tudo ao nosso redor lembra gerenciamento de
projetos?
MC: Observem duas rvores. Uma est seca e a outra est com todo vigor.
&): 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.
%&: Voc quer dizer que ela foi plantada, cresceu, deu frutos e agora est morrendo?
MC: sso mesmo!
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.
P+: 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.
%&: Se entendi bem, podemos dizer, ento, que todos os projetos possuem um ciclo de
vida, ou seja, nascimento, maturidade, velhice e morte.
86 7 Processos
MC: sso mesmo. Essas etapas so chamadas de processo no gerenciamento de
projetos.
&): 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.
P+: Ento me explique melhor sobre o que so processos em gerenciamento de
projetos.
MC: Voltando ao incio da nossa conversa, observe aquele ninho que est na rvore. O
que voc v?
P+: 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.
96 7 Processos de Gerenciamento de Projetos:
&): 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.
%&: 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.
P+: Mas para que ciclo de vida?
MC: Lembra-se do que o Sr. PM 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.
&): Est bom. E da?
%&: 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.
P+: Antes que d um n na minha cabea, posso traduzir isso da seguinte forma:
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.
&): Ento gerenciar projetos muito fcil!
%&: Fcil eu no diria. Exige conhecimento e dedicao.
&): J estou com muita fome. Podemos ir para o restaurante?
%&: Boa idia. Daqui a pouco no conseguimos nem lugar no restaurante para
almoar.
P+: Ento vamos todos no meu carro. Assim continuamos essa conversa. Este assunto
est comeando a me interessar.
;6 7 4reas de con"ecimento:
MC: Voltando a nosso assunto e falando em conhecimento, vocs se lembram do
nosso programa de qualidade?
P+: O que isso tem a ver com gerenciamento de projetos?
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)
%&: 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.
&): reas de conhecimento? O que isso?
MC: As reas de conhecimento so definidas pelo PM. Elas descrevem os
conhecimentos e prticas em termos de processos. Esses processos esto organizados em 9
(Nove) reas, que so:
1. Gerenciamento da ntegrao;
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).
P+: E como tudo isso est relacionado?
MC: Espere... Tenho um material na minha pasta que pode exemplificar o seu
questionamento.
P+OCE&&O&, 4+E*& %E CO-HECIME-O E O CIC2O %E 1I%*
&): 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.
%&: Voc leva tudo na brincadeira, mesmo quando o assunto srio.
Risos
P+: Chegamos. Vou estacionar enquanto vocs entram.
&): OK, Rocha. remos procurar uma boa mesa e aguardamos voc.

4+E*& %E CO-HECIME-O
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.
Gerenciamento do empo 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 0ualidade processos necessrios para que o projeto satisfaa
as necessidades para as quais foi criado. Consiste do planejamento, asseguramento e controle
da qualidade.
Gerenciamento de +ecursos 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 Comunica$es 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 +isco 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 *(uisi$es 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.
%esenvolvimento de Projetos: Ideali#ao e Concepo
56 < ermo de a!ertura
MC: Lembram-se da nossa conversa quando estvamos vindo para o restaurante?
DS: Sobre o ciclo de vida?
MC: sto 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. PM. 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 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.
86 < 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 empresas, as ideias 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.
%&: 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 restaurante vai fornecer. o que acontece com os nomes dos projetos. Eles identificam
o projeto.
P+: Muito fcil. E s isso. Colocamos o nome do projeto e est tudo entendido. At
parece.
%&: No seja to ctico, Rocha. Acredito que todos os processos venham para facilitar
nosso trabalho, desde que muito bem explicado.
MC: sso 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 coloca-la em prtica.
&): Para que mexer em time que est ganhando, Maria? Est to bem como est!
odos: Risos
%&: 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.
P+: Estava fcil demais para ser verdade. Eu no disse que isso tudo burocratiza
nosso trabalho?
%&: 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.

96 < Meta < o!jetivo, pra#o e valor
&): Acho que ns hoje s vamos almoar projeto. Vocs no querem mudar de assunto?
P+: Quero continuar esta conversa Been, pois temos que aproveitar o conhecimento
da Maria nesse papo descontrado.
%&: Muito bem, Rocha. Concordo com voc. melhor conversamos e tirarmos nossas
dvidas aqui, do que dentro da empresa.
&): 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 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.
P+: De prazo e custo eu entendo bem. Para estabelecermos prazo e quanto vai custar,
no podemos simplesmente colocar no papel, como um chute.
%& e MC: Claro que no!
P+: 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.
P+: Como que ?
MC: Desculpe, Rocha. Eu no falei direito. Dependendo do tipo do projeto, apenas um
oramento inicial suficiente.
%&: 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.
P+: Mas como so feitos esses agrupamentos?
MC: O Sr. PM nos apresentou uma lista com esses tipos de projetos, lembram:se?
&): 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:
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. nformar a natureza e extenso de quaisquer ameaas ao sucesso do
projeto e a extenso e conseqncias do risco.
&): E a, Rocha, voc bem que poderia nos dar uma aula de EVTE como a Maria.
P+: 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.
P+: 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.
&): 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.
%&: 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 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
P+: 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.
&): Nossa! Agora deu um n na minha cabea.
%&: 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;
- 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.
*)E2* 8: Classificao: 1alores = Grau de Comple>idade
%&: No podemos esquecer que essa classificao vai variar de empresa para
empresa.
MC: sso 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.
%&: 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.
&): 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.
P+: Maria, nesse caso o valor do projeto o custo do projeto.
MC: sso mesmo.
P+: Para calcular o valor do projeto, eu incluo os custos diretos e indiretos do projeto?
MC: nclui, 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.
&): Puxa, eu fiz uma pergunta to simples e vocs complicaram tudo. Algum pode
dizer, ento, como que se calcula o valor de um projeto?
%&: 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.
&): Voc me apertou sem me abraar. Clculo com o Rocha. E custo, para mim,
tudo igual. Eu gosto de escrever. Tudo muito tranqilo.
Risos
P+: 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.
&): Puxa, Rocha, voc j est at gostando de projetos!
P+: 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.
%&: sso 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.

;6 < Escopo Preliminar
P+: Definidas as metas do projeto, j podemos planejar como vamos executar o projeto?
%&: 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.
&): 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.
&): Voc poderia apresentar um exemplo para mim?
MC: Claro. Vou apresentar um exemplo bem simples. Pegue o cardpio novamente.
&): Peguei. E da?
MC: Observe como ele est distribudo. Voc pode descrev-lo?
&): 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.
%&: Gostei dessa comparao. Nunca imaginaria fazer essa correlao.
P+: Se eu entendi bem, escopo tudo aquilo que precisamos fazer para que o projeto
acontea.
MC: sso 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.
%&: Maria, considerando nossa empresa, que presta servios para o governo e que
est sujeita a algumas regras do governo, como por exemplo, a Lei 8.666 e a nstruo
Normativa N: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.

?6 < Identificao de riscos
MC: Eu falei em riscos. Vocs sabem me dizer o que so riscos no projeto?
&): Acho que nosso maior risco aqui comermos muito e no darmos conta de voltar
para o trabalho.
O%O&: RSOS
&): 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.
&): 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 cedo identificarmos os riscos na concepo
de um projeto, mais fcil ser gerenci-los.
P+: 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 < &taAe"olders
%&: Nossa, a comida deste restaurante realmente muito boa. Seu amigo superou minhas
expectativas. D os parabns a ele por mim, Been.
P+: Acho que superou todos ns.
MC: Concordo com vocs. Ns, como stakeholders deste projeto, estamos muito
satisfeitos com o resultado alcanado.
%&: Stakeholders no so os patrocinadores do projeto?
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.
P+: Ento somos Stakeholders Clientes?
MC: E tambm usurios finais.
&): Quais so os principais stakeholders?
%&: 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: sso 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.
%&: Tambm acho. E vocs, rapazes, o que acham?
P+: Estou comeando a entender o assunto e acho que poderei contribuir neste
processo, mas ainda no sei se saberei utilizar este gerenciamento de projetos.
&): 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.
%esenvolvimento de Projetos: Planejamento
No Restaurante
&): Que comida boa! O tempero est muito suave.
%&: 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.
%&: Este planejamento pode ser comparado com o planejamento de um projeto?
P+: 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 do gerenciamento de projetos, temos algumas etapas e
procedimentos que so especficas.
P+: E quais seriam essas fases?
MC: Lembra-se da nossa conversa quando estvamos vindo para c?
P+: Sobre as fases do ciclo de vida?
%&: No s sobre o ciclo de vida, mas tambm dos processos que compem cada
fase.
MC: sso mesmo. Todo projeto tem um ciclo de vida com suas respectivas fases e
processos. Dessa forma temos o que chamamos Plano do Projeto.
P+: L vem voc novamente com mais informao.
%&: 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.
%&: 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.
%&: Podemos dizer que o plano define como o projeto elaborado, monitorado,
controlado e encerrado?
MC: Sim. Podemos.
P+: Maria, voc poderia nos explicar o que significa cada um deles?
MC: Posso tentar.
&): No seja modesta, Maria. Voc tem nos ajudado muito com seu conhecimento.
Estou comeando at a me interessar pelo assunto.
%&: Comeando Been!? Acredito que esse processo um caminho sem volta.
&): Caminho sem volta!? Que papo mais fnebre esse, Delma?
%&: 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.
&): Ah bom. Assim est melhor.
P+: 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?
O%O&: Boa idia.
MC: Been, qual o nome do dono deste restaurante?
&): 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.
&): Pelo jeito, o projeto do restaurante foi considerado vivel, caso contrrio no
estaramos aqui.
MC: sso mesmo.
P+: Prximo passo.

56 7 Plano Organi#acional
MC: O prximo passo a Elaborao do Plano Organizacional.
%&: 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.
%&: A julgar pelo ambiente, ele tambm contou com uma decoradora no seu Plano
Organizacional.
P+: 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
pessoas ou empresas que iro executar o projeto bem como a relao de hierarquia entre elas.
%&: Mas s isso?
MC: No caso do restaurante sim, pois uma empresa nova. Podemos dizer que o
primeiro projeto dessa empresa.
5:5 7 E(uipe de Projeto
&): Mas, no caso da empresa, fazemos da mesma forma?
MC: No caso da nossa empresa, temos mais alguns detalhes.
&): Fico s com o restaurante, falou!?
%&: 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.
P+: 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.
%&: Maria, voltando apresentao do Sr. PM, um projeto quase sempre
multifuncional. sso significa que, ao elaborarmos um Plano Organizacional, teremos pessoas
de vrias reas e at equipe externa, caso no tenhamos profissional dentro da empresa?
5:8 7 Capacitao
MC: sso mesmo, Delma. E, em alguns casos, para execuo do projeto, profissionais
da casa precisam de treinamentos mais especficos para a execuo de algumas tarefas.
P+: 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.
P+: No pensei por esse lado.
MC: Assim, quando a empresa identifica as necessidades de capacitao da equipe,
ela elabora um plano de treinamento.
&): E essa idia de mudana, o que significa isso?

5:9 7 Gesto da Mudana
MC: Muitos projetos impactam diretamente no processo de uma empresa. Por exemplo, a
implantao de um software de gesto, tipo ERP.
&): Muitas pessoas perdem o emprego.
%&: Claro que no.
P+: Maria, agora ficou mais clara sua explicao anterior.
P+: 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.
&): 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.
%&: 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 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.
P+: Este foi um projeto de sucesso. Olha que eu no considerava que j tinha
participado de um projeto e que fui til.
%&: Viu como as peas se encaixam quando temos os conceitos certos?
MC: sto 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.
86 7 Planejamento de Escopo
&): 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.
&): 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.
%&: Podemos dizer, ento, que agora, com o planejamento do escopo, determinaremos
os limites do trabalho no projeto?
MC: sto 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.
P+: 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:
5 Roteiro de preparao de uma declarao detalhada do escopo de projeto, bem
como o tratamento de suas mudanas;
8 Procedimentos para a construo da estrutura analtica de projeto (EAP) com as
respectivas regras para sua aprovao e manuteno ao longo do empreendimento;
9 Regras sobre a aceitao formal dos entregveis, em um formulrio-padro, por
exemplo.
P+: O que estrutura analtica? Para que serve?
&): 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 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.
%&: Como a Maria j disse, ele a formalizao do projeto.
MC: sto 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;
5 uma representao grfica da hierarquia do projeto;
8 identificao de todo o trabalho a ser executado: trabalho que no est no WBS no faz parte
do Escopo do Projeto;
9 a base a partir da qual o projeto construdo;
; reflexo das pessoas sobre todos os aspectos do projeto.
Alm disso, uma EAP construda pode ser reutilizada em outros projetos.
%&: sto 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.
P+: 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;
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.
&): Tudo isto!?
MC: E melhor, Been, ele visual. Parece um organograma.
&): 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.
MO%E2O %E 'M* E*P
Oramento de Custos
&): E agora, o que fazemos?
MC: O prximo passo saber quanto custa o nosso projeto.
P+: 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.
P+: 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.
%&: 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: sso mesmo.
&): J falei que nmeros no so a minha praia. Vocs podem me explicar em bom
portugus?
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.
nfraestrutura
Materiais de Consumo
Despesas de Viagens
Servios 3 Pessoa Jurdica
Comunicao e Marketing
Servios 3 Pessoa Fsica
Bolsistas e Estagirios
Despesas Financeiras
mpostos, Taxas e Contribuies
Despesas Operacionais
nvestimentos
&): 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:
Been, voc sabe quanto tempo durou a obra deste restaurante?
&): 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:
nvestimentos (bens durveis)
At o momento, o valor do oramento do Luiz Otvio :
SERVOS DE 3 - PJ = R$ 19.440,00
NVESTMENTOS = R$ 8.630,00
%&: Boa parte dos nossos projetos envolve viagens, dessa forma, ao elaborarmos o nosso
oramento, podemos considerar: passagens, hospedagem, alimentao e locomoo.
MC: sso mesmo.
P+: Deixe-me calcular no papel para ver se eu entendi.
Premissas:
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.
%&: 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.
%&: Mas, Maria, so muitas informaes. Confesso que j estou ficando preocupada se
daremos conta de elaborar tudo isto e tambm de acompanhar.
P+: 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.
P+: Est certa, Maria. S agora estou me dando conta disso. Na implantao do ERP foi
assim e agora, com o Gerenciamento de Projetos, tambm est sendo. Ainda bem que temos voc,
assim a transio fica mais fcil.
%&: Concordo com voc.
&): Quando ser que este novo processo vai me interessar?
MC: Acho que, a partir de agora, voc vai poder contribuir muito, Been.
Plano da 0ualidade
MC: No adianta estabelecermos metas se no acompanharmos. O prximo passo no
planejamento de um projeto o plano de qualidade.
&): 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.
&): O Plano de Qualidade trabalha, ento, com Gesto Vista, Grfico de Desempenho?
%&: Puxa, at que enfim alguma coisa lhe chamou a ateno!
&): Sou muito visual. Nmeros, nmeros e mais nmeros embaralham a minha vista. Gosto
de ver cores.
P+: 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.
&): 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.
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.
%&: 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.
&): 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: sto mesmo. Estou gostando de ver seu interesse.
P+ e %&: Ns tambm.

Plano de Comunicao
&): Comunicao em projetos?
MC: Gerenciamento das comunicaes. Nossa prxima etapa.
%&: H uma frase de David . 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 nformaes, os Relatrios de
Desempenho ou Performance e o Gerenciamento das Partes nteressadas.
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.
&): 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.
%&: 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.
P+: 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.
%&: 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;
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.
4.
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.
%&: 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.
%&: Maria, voc poderia desenhar para ns um modelo de Planejamento de Comunicao.
Fig1
MC: Primeiro devemos informar o nosso pblico-alvo, ou seja, qual stakeholder. Vocs se
lembram quais so?
&): 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: sto mesmo Been. Devemos planejar as informaes sobre o projeto para cada parte interessada. O prximo item definir qual
evento, conforme falei h pouco.
%&: 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.

Fig1.
Plano de &uprimentos ou Plano de *(uisi$es
&): Agora podemos comer nossa sobremesa?
MC: Podemos.
Risos
P+: Estou sentindo falta de mais uma etapa.
&): O que, Rocha?
P+: 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.
%&: 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.
&): Define o qu?
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.
%&: 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).
&): Puxa tudo isto?
MC: Tudo isto! remos conversar um pouco mais sobre Plano de Aquisies quando estiver
explicando sobre execuo e controle de projetos. Acredito que os exemplos ficaro mais claros.
&): Puxa, adorei adquirir esta sobremesa. Sem dvidas, ela est completando o meu
projeto alimentar de hoje.

Plano de +esposta aos +iscos
%&: Maria, acho que voc j falou de todos os Planos!
MC: Ainda no, falta falarmos sobre o Plano de Resposta aos Riscos.
P+: 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.
P+: OK.
E>ecuo e Controle
No Restaurante
%&: Maria, como eu acabei de dizer, elaboramos todos os planos. Agora, como executamos e
controlamos tudo o que planejamos?
P+: Boa pergunta! Tenho vrias dvidas de como colocamos em prtica tudo que
planejamos.
MC: Vamos com calma. Explicarei os processos de acompanhamento e controle.
&): 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.
P+: 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.
56: O (ue controlar e acompan"ar
&): 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.
P+: Maria, no entendi muito bem, voc poderia explicar melhor?
MC: Vocs se lembram da apresentao do Sr. PM?
&): Sobre a evoluo do Gerenciamento de Projetos?
MC: sso mesmo, Been.
&): Se eu me lembro bem, o Sr. PM 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.
MC: Puxa Been, voc explicou muito bem. Vejo que o assunto est lhe interessando!
%&: 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
- nformaes das aes
- Riscos
- Planos de Ao
Realizar:
- Comunicao
- Gesto de stakeholders.
- Documentao das aes
%&: 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.
P+: sto em se tratando de uma grande empresa. E aqui no restaurante?
MC: No s em grandes empresas. ndependente 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.
P+: 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.
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.
%&: Refao a minha pergunta. Como acontece o acompanhamento dos projetos?
MC: Depende da metodologia adotada!
&): 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:
5B < Etapa < *compan"amento 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.
8B Etapa < *compan"amento de desempen"o
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.
%&: Agora estou com dvidas. O que escritrio de projetos? No estou me lembrando de
termos falado sobre ele!
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.
&): Temos um escritrio de projetos na empresa?
MC: Est em fase de implantao juntamente com a metodologia. Voltando explicao
anterior, a terceira etapa :

9B Etapa < *compan"amento e>ecutivo
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.
86: 3erramentas
P+: 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.
%&: 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.
P+: 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, os Finocc!io r", #incoln de Sou$a Firmino da Silva"% &io
de aneiro% 'ditora FG, ())*+
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 CPMA (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 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.
P+: 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.
&): Quais as outras vantagens?
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.
P+: 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.
%&: 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: sso mesmo. Vou mostrar para vocs um exemplo de um projeto detalhado no MS
Project.
96: Gerenciamento
%&: 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:
5 < Gerenciamento de Pra#o:
Lembrando da obra do Restaurante Bem Viver, podemos simular o acompanhamento do prazo. Vejam o desenho que eu fiz.
8 < Gerenciamento de Custos:
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.
%&: 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.
P+: 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.
9 < Gerenciamento de 0ualidade:
&): E o gerenciamento da qualidade, como acontece?
MC: Esta a sua praia.
&): 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.
&): No meu vasto conhecimento em qualidade...
P+: Modesto.
RSOS
&): 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.
%&: E satisfao do cliente um grande passo para o sucesso dos projetos.
; < Gerenciamento de &taAe"olders
MC: A satisfao de clientes funo de uma adequada e detalhada anlise de necessidades.
P+: 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;
obteno de aceitao formal do Projeto pelos stakeholders quando do encerramento.

? < Gerenciamento de Escopo:
P+: 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.

;6: Controle de Mudanas
%&: 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 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.
?6: Comunicao
&): 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.
@6: 3al"as em Projetos
%&: Com todo esse planejamento e controle, por que existem tantas falhas em projetos?
&): 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;
%&: 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: 3atores CrCticos de &ucesso
%&: Ento, Maria, eu entendo que os fatores crticos para um resultado positivo na execuo dos
nossos projetos sejam:
meta claramente definida;
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
No Restaurante
%&: 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.
P+: Meninas, podemos pedir a conta?
MC e %&: Claro.
MC: Continuamos nossa conversa no carro.

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: sso 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.
E&COPO
-> 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.

Considera$es
P+: 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.
&): 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.
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
&): Maria, apresente um exemplo prtico do que voc acabou de falar. Acho que fica mais claro.
MC: Deixe-me pensar.
P+: Puxa, pessoal, tem uma obra na avenida principal. Vou precisar mudar o caminho e
talvez atrasaremos para chegar empresa.
MC: Olha a nosso exemplo!
&): Que exemplo?
MC: Acompanhem meu raciocnio. Quando samos para o almoo, tnhamos um roteiro pr-
definido.
%&: 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).
&): 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;
- retornar empresa pelas avenidas principais;
- chegar empresa s 14 horas.
P+: Vamos seguir esse raciocnio. Nosso projeto teve durao de 2 horas, ao custo total de R$
100,00 (R$ 25,00 p/ pessoa). sso 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.
P+: 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.
%&: sso 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.
%&: 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.
P+: 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.
%&: Ento, trabalhar com controle do escopo quase sempre lidar com o controle das
mudanas de escopo.
&): 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.
&): Maria, desenhe um modelo para mim.
MC: No carro difcil. Acho que tenho um modelo aqui na minha pasta. Aqui est.
Modelo de E*P
%&: 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.
%&: Essa decomposio hierrquica subdivide o escopo do projeto e as entregas do projeto
em componentes menores?
MC: Sim. Segundo o glossrio do PM, 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.
&): Existe algum passo-a-passo para decomposio de uma EAP?
%&: 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:
&): Voc poderia detalhar cada um desses passos?
MC: Vejamos:
1) Escrever o nome do projeto no primeiro nvel (nvel 0) da EAP:
2) niciar 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:
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.
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.
%&: O que dicionrio da EAP.
MC: um documento complementar EAP. Apresenta uma breve especificao do pacote
de trabalho e seu critrio de aceitao.
%&: 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.
&): 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.
P+ Estamos chegando empresa. Podemos continuar a conversa depois?
MC: Claro, Rocha.

Gerenciamento de +iscos
P+: Puxa, como o tempo est mudando. Parece que vai cair uma chuva daquelas.
&): Vai mesmo. Tomara que voc consiga estacionar o carro no estacionamento coberto.
P+: 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!
P+: Como que !?
MC: Continuamos nossa conversa no carro.

56 < Conceitos
MC: Voc se lembra do conceito de riscos em projetos?
P+: 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: sso mesmo. At agora no havia falado muito de riscos, mas voc me deu um exemplo
que podemos explorar para falar um pouco de riscos.
%&: 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.
%&: 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.
P+: 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.
%&: OK. Voc vai explicar um pouco mais sobre todas as etapas do gerenciamento de
riscos.
MC: Vou.

86: Etapas do Gerenciamento de +iscos
&): Viver um risco.
%&: Viver assumir risco.
P+: 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.
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:
5: Planejar a gerncia de risco: determinar qual a abordagem e planejar as atividades de gerncia de
risco que sero executadas para o projeto.
8: dentificar riscos: determinar quais riscos podem afetar o projeto e documentar as suas
caractersticas.
9: Analisar riscos qualitativamente: avaliar, determinar e compor os fatores de impacto e
probabilidade, bem como priorizar seus efeitos nos objetivos do projeto.
;: 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.
?: Planejar as respostas aos riscos: desenvolver procedimentos e tcnicas para avaliar
oportunidades e reduzir as ameaas aos objetivos do projeto.
@: Controlar e monitorar riscos: executar planos de respostas e identificar novos, monitorar riscos
residuais e avaliar efeitos no ciclo de vida do projeto.
&): Est bem. Mas como identifico riscos, analiso, controlo, etc.? sso no fcil.
MC: No disse que era. No entanto, como j conversamos anteriormente, existem formas de
identificar riscos.
%&: Ento identificar riscos determinar o evento, a causa e o efeito.
MC: sso 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.
P+: 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.
&): Existe alguma tcnica para identificar riscos, ou trabalhamos no achmetro?
MC: Been, em projetos no achamos nada.
%&: tudo preto no branco.
96: 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.
P+: 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:
&): 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.
%&: 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.
%&: Significa que, para utilizarmos essa tcnica, os projetos anteriores tm que estar bem
documentados?
MC: sso 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.
%&: 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.
P+: E da? dentificamos os riscos. O que fazemos agora?

;6: *nDlise dos +iscos
MC: No processo de anlise de risco, fazemos anlise qualitativa e anlise quantitativa.
&): 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.
P+: Trabalhamos, ento, com probabilidades?
MC: Probabilidade x mpacto. 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).
%&: 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
P+: 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
P+: 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 mpacto.
%&: 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.
P+: 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.

?6: 3ontes de risco
&): 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.
&): 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;
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.
P+: Maria, voc poderia listar alguns riscos potenciais?
MC: Conheo alguns. Posso destacar:
+elativos 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
+elativos E E(uipe de %esenvolvimento
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
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
+elativos a PolCticas Organi#acionais
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
nfluncia 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
+elativos E Comple>idade 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
nadequada transferncia de tecnologia para o projeto
Condies de trabalho inadequadas
+elativos 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
Repositrios de projeto e controle de configurao inadequados
Ausncia de uma metodologia efetiva de gerncia de projetos
+elativos E GerFncia 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
neficincia do gerente do projeto
nexperincia do gerente de projeto
Comunicao ineficiente
+elativos a +e(uisitos:
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
&): Puxa. Ser que iremos conseguir tratar esse assunto?
P+: Por que no?
&): So muitas informaes e no me sinto seguro em determinar quais riscos so mais ou
menos impactantes.
%&: 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.
@6: Planejamento das respostas
%&: Entendo que, depois de identificarmos os riscos, como voc acabou de dizer, teremos que
planejar como administrar os riscos, caso eles ocorram.
P+: 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.
&): 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.
P+: 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.
&): O que incluir a contingncia?
P+: 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.
G6: Controle
&): Legal. Gostei deste assunto.
P+: At que enfim.
RSOS
%&: Todos estes processos so muito importantes.
MC: So realmente importantes. E, para finalizarmos este assunto, temos o controle da
gesto de riscos.
&): Pelo que conversamos, o controle de riscos tem que ser acompanhado o tempo todo.
MC: sto mesmo, Been. O controle de respostas a riscos um processo contnuo ao longo
do ciclo de vida, uma vez que o 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.
&): Estaremos num ciclo PDCA.
MC: Exatamente.
P+: Pessoal, chegamos. Ser que vou conseguir estacionar?
%&: Vamos l. A probabilidade grande de conseguir.
&): Olha l, Rocha, uma vaguinha no estacionamento coberto esperando por voc.
P+: Legal. Assim, nem o carro nem ns corremos o risco de nos molhar.

Gerenciamento de &taAe"olders
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: sto 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 assuntos relacionados aos stakeholders, para foc-los e mant-los integrados ao projeto.
56 < Principais &taAe"olders e suas 3un$es
%&: 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.
P+: Ento, para cada stakeholder, teremos desejos diferentes.
MC: Alm disso, cada stakeholder envolvido ter uma funo definida, assim, as
expectativas tambm sero diferentes.
&): Maria, d exemplos.
MC: OK. Lembra-se quando conversamos sobre os principais stakeholders e eu citei
alguns?
&): Sim, voc citou: sponsor, gerente de projeto, clientes, organizao executora, equipe de
projeto, fornecedores e usurios finais.
MC: Muito bem Been, e como acabamos de comentar, cada um tem sua caracterstica e sua
funo especfica.
&): E quais so?
MC: Vou explicar.
5:5< &ponsor
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 projeto;
aprovar o escopo definido para o projeto;
garantir foco e direcionamento do projeto;
analisar e aprovar as propostas do grupo.
%&: 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.
P+: Sem dvida, os dirigentes so partes interessadas.
%&: Mas, sem sombra de dvidas, uma das partes interessadas mais importante o prprio
gerente do projeto.
MC: sso verdade.
5:8 < Gerente de Projeto
&): Quais so suas principais funes?
MC: Suas funes so:
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.
&): 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.
P+: 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;
3. conhecimento e habilidades de gerenciamento geral; e
4. habilidades interpessoais.
%&: 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.
&): Eu no disse? Um super heri!
RSOS
MC: Veja este desenho. Se a empresa no souber identificar as habilidades e competncias
dos seus funcionrios, corre o risco de perder excelentes profissionais.
5:9 < E(uipe do Projeto
P+: Mas esse super-heri no trabalha sozinho. Ele conta com uma legio de colaboradores para
ajud-lo.
MC: sso mesmo. O gerente de projeto no trabalha sozinho, e a montagem de sua equipe
fundamental para o sucesso dos projetos.
P+: 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.
%&: 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.
P+: Realmente no uma tarefa fcil.
%&: Gerenciar pessoas muito difcil.
&): 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.

5:; < Cliente
&): 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.
P+: 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.
%&: 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:
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.

86 < O Gerenciamento
&3: Boa tarde!
odos: Boa tarde.
&3: Gostaram da apresentao do Sr. PM?
MC: Sim, foi tima. Mostrou a todos a importncia da utilizao do gerenciamento de projetos.
P+: Continuamos a conversar durante o almoo, e a Maria reforou a apresentao do Sr. PM, com
vrias informaes que nos sero teis no nosso dia-a-dia.
&): Agora mesmo, estvamos conversando sobre os stakeholders dos nossos projetos.
&3: 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.
%&: Sem sombra de dvidas.
&3: Fiquem vontade. Um bom trabalho para vocs.
odos: 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.
%&: 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.
&): 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.
P+: 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 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.
P+: 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.
%&: 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: sso 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.
&): 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.
(LETURA OBRGATRA: TEXTO Administrando Conflitos em Projetos, via Gerenciamento de
Stakeholders: prxima lio)
P+: Vamos colocar a mo na massa. Temos muito trabalho pela frente.
&): Maria, quando iremos conversar sobre a fase de encerramento do projeto?
MC: Primeiro leiam o texto que indiquei e amanh retornaremos com esse assunto.
&): OK. Vamos ao trabalho.
*dministrando Conflitos em Projetos, via Gerenciamento de &taAe"olders
*rtigo pu!licado na +evista Mundo PM: nHmero 5@: *goI&et 8JJG
3lDvia %ias Moreira: Administradora: ESHO: Grupo Amil
Cristiane ,ourdan: Mdica especializada em Endocrinologia e bacharel em Direito: Amil
Assistncia Mdica nternacional
Eduardo *ndrade: Administrador Andrade: Seaworld
Mariela )arai!ar: Bacharel em Comunicao Social: Universidad DeLa Republica Del
Urugay
*rt"ur Macedo: Engenheiro Civil: Amil Assistncia Mdica nternacional
Abstract
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.
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 o!jetivos
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:
dentificar 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 ELLOT (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:
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?
,abela -% .a/a de avalia01o dos sta2e!olders.
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.

* importKncia da comunicao no relacionamento com os staAe"olders
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 ELLOT (2001), fundamental para no se
transmitir informaes nem a mais nem a menos.
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.
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.
*dministrando 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 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 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 nformao, de Referncia ou Especializao e,
dessa forma, encontrar a soluo adequada, parte fundamental das habilidades do gerente
de projetos. Ele dever julgar qual a 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.
* e(uipe: o principal staAe"older
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.
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 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.

* inteligFncia emocional no relacionamento com os staAe"olders
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 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.
Considera$es 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 desenvolvimento da equipe
so requisitos bsicos exigidos ao bom gerente de projetos.
Encerramento do Projeto
MC: Bom dia a todos! E a, gostaram dos textos que eu passei para vocs?
%&: Como disse o Pedro e pelas nossas conversas, temos muito trabalho pela frente. Os
textos ajudaram muito a clarear algumas dvidas.
P+: Para mim, que estava bem receoso, achei a leitura muito produtiva.
&): 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.
%&: At que enfim, Been. Voc agora percebeu a importncia deste processo.
P+: Antes tarde do que nunca.
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.
56 7 Encerramento de contratos Lencerramento administrativoM
&): Como dizem os mineiros vamos comer o boi aos bifes.
P+: 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.
P+: 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.
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.
P+: 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. sso 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.
%&: 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.
P+: Quais so essas atividades?
MC: Trata-se da Documentao da medio do desempenho, Documentao do Produto e
outros registros inerentes ao projeto.
%&: 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 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.
%&: 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.
P+: 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.
P+: 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.
%&: Voc poderia explicar um pouco mais?
MC: Vamos l.
(O texto a seguir foi extrado do seguinte livro: XAVER, Carlos Magno da Silva et. al.
Gerenciamento de Aquisies em Projetos. Rio de Janeiro: Editora FG, 2007)
* documentao para encerramento do contrato
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.
-ota 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.
1erificao 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.
*uditoria de a(uisi$es
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.
*ceitao e pagamento final
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.
*r(uivo 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.
&): 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?
MC: a minha prxima explicao.

86 < 3ormali#ao do encerramento
&): Voc parece que l nossos pensamentos, Maria.
MC: No isso. Apenas as explicaes seguem uma linha de raciocnio, em que as etapas
so complementares.
P+: Been, deixa a Maria continuar as explicaes.
&): 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.
%&: A formalizao do encerramento acontece somente por ocasio do trmino do projeto?
MC: No.
&): 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.
%&: 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: XAVER, Carlos Magno da Silva et. al. Gerenciamento de
Aquisies em Projetos. Rio de Janeiro: Editora FG, 2007)
O tNrmino das atividades esta!elecidas 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
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.
P+: 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.
96 < %ocumentao das li$es aprendidas
&): Ento, pela lgica, temos agora que documentar tudo o que ocorreu com o nosso projeto?
MC: sto 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.
P+: 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.
%&: 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.
&): 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 ocorra e efetivamente trabalhar para uma boa
documentao das nossas atividades.
P+: 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.
&): Falou o filsofo Rocha. Muito bom.
%&: 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.
%&: 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: sso mesmo.
P+: 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.
%&: Na nossa metodologia, temos algum modelo que devamos seguir?
MC: Temos, sim. Nesse modelo, avaliamos as reas de conhecimento em relao ao projeto
executado.
%&: Como seria esse modelo?
MC: Aqui est. Nele descrevemos os aspectos positivos e negativos em relao a cada item
analisado.
P+: Esse modelo vai nos ajudar muito.
%&: Com certeza.
;6 < *nDlise de indicadores de desempen"o
Da anlise dos nossos indicadores de desempenho.
Eles tambm compem a lista do encerramento dos projetos.
%&: Mas os indicadores no esto contidos no plano de qualidade e so avaliados
constantemente para realizarmos o ciclo PDCA?
No entanto, ao encerramos o projeto, necessrio apresentar os resultados obtidos atravs
da anlise desses indicadores.
P+: 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:
)i!liografiaI2inAs +ecomendados
http://www.gestaodeprojeto.info/
http://www.gerenciamentodeprojeto.com/
VERZUH, Eric. MBA Compacto: Gesto de Projetos. 5 ed. Rio de Janeiro: Campus,
2000. 398 p.
DNSMORE, Paul C. Gerncia de Programas e Projetos. So Paulo: Pini, 1992. 176 p.
CLELAND, D. .; RELAND, L. R. Gerncia de Projetos. Rio de Janeiro: Reichmann &
Affonso, 2002.
HARRS, 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.