Curso Gestao de Projetos educa

Prévia do material em texto

1 
 
Seja Bem Vindo! 
 
Curso 
Gestão de Projetos 
Carga horária: 60hs 
 
 
 
 
 
 
 
2 
 
Dicas importantes 
 
• Nunca se esqueça de que o objetivo central é aprender o 
conteúdo, e não apenas terminar o curso. Qualquer um termina, só 
os determinados aprendem! 
 
• Leia cada trecho do conteúdo com atenção redobrada, não se 
deixando dominar pela pressa. 
 
• Explore profundamente as ilustrações explicativas disponíveis, 
pois saiba que elas têm uma função bem mais importante que 
embelezar o texto, são fundamentais para exemplificar e melhorar 
o entendimento sobre o conteúdo. 
 
• Saiba que quanto mais aprofundaste seus conhecimentos mais 
se diferenciará dos demais alunos dos cursos. 
 
 Todos têm acesso aos mesmos cursos, mas o aproveitamento 
que cada aluno faz do seu momento de aprendizagem diferencia os 
“alunos certificados” dos “alunos capacitados”. 
 
• Busque complementar sua formação fora do ambiente virtual 
onde faz o curso, buscando novas informações e leituras extras, 
e quando necessário procurando executar atividades práticas que 
não são possíveis de serem feitas durante o curso. 
 
• Entenda que a aprendizagem não se faz apenas no momento 
em que está realizando o curso, mas sim durante todo o dia-a-
dia. Ficar atento às coisas que estão à sua volta permite encontrar 
elementos para reforçar aquilo que foi aprendido. 
 
• Critique o que está aprendendo, verificando sempre a aplicação 
do conteúdo no dia-a-dia. O aprendizado só tem sentido 
quando pode efetivamente ser colocado em prática. 
 
 
 
 
3 
 
Conteúdo 
 
Introdução 
Evolução do Gerenciamento de Projetos 
O Trabalho nas Organizações 
Origem dos Projetos 
Metodologia de Gerenciamento de Projetos 
Conceituações 
Organização do Gerenciamento de Projetos 
Desenvolvimento de Projetos: Idealização e Concepção 
Desenvolvimento de Projetos: Planejamento 
Cronograma de Execução 
Orçamento de Custos 
Plano da Qualidade 
Plano de Comunicação 
Plano de Suprimentos ou Plano de Aquisições 
Execução e Controle 
Gerenciamento de Escopo 
Gerenciamento de Riscos 
Gerenciamento de Stakeholders 
Administrando Conflitos em Projetos, via Gerenciamento de Stakeholders 
Encerramento do Projeto 
Bibliografia/Links Recomendados 
 
 
 
 
 
 
 
4 
 
Introdução 
 
Legenda: 
SF – Sr. Fortunato 
PMI – Sr. Paulo Martins Inácio 
MC – Maria Conselheira 
DS – Delma da Silva 
PR – Pedro Rocha 
SB – Sr. Been 
 
 
No ambiente de trabalho, nossos colaboradores lêem o convite: 
Prezado Colaborador: 
5 
 
Com o objetivo de informar adequadamente 
sobre a importância das boas práticas em 
gerenciamento de projetos e os benefícios de 
sua utilização, convidamos a participar do “I 
Encontro de Gerenciamento de Projetos”, a 
ser realizado hoje, conforme programação: 
Programação 
Apresentação do Presidente: Sr. Fortunato 
Evolução do Gerenciamento de Projetos: Sr. 
Paulo Martins Inácio 
Local 
Auditório Térreo da empresa 
 
MC: Que convite legal! Com este encontro, teremos a 
oportunidade de conhecer práticas atuais de gestão. Iremos 
melhorar o acompanhamento de nossos processos e projetos. 
DS: Como é que é? Preciso ver para acreditar. 
PR: Lá vêm eles de novo. Por que será que toda vez que nos 
acostumamos com nossas tarefas, a alta administração resolve 
trazer mais novidades? Não estou gostando disso! 
SR: Relaxa, Rocha, deve ser apenas mais uma reunião. Vamos 
voltar e vai continuar tudo igual. 
6 
 
 
Auditório da Empresa 
SF: Bom dia a todos. Obrigado pela presença neste encontro 
sobre Gerenciamento de Projetos. Hoje apresentaremos para 
vocês modelo e ferramentas de gestão que estão em 
conformidade com as melhores práticas adotadas pelo mercado. 
O comprometimento da implantação deste modelo e destas 
ferramentas é que vai determinar o sucesso de nossa empresa 
no futuro. Passo a palavra ao nosso consultor, Sr. Paulo Martins 
Inácio. 
PMI: Bom dia a todos. Inicialmente gostaria de parabenizá-los 
pela participação neste encontro e espero contribuir tanto para o 
aperfeiçoamento de sua atividade diária, quanto para o seu 
desenvolvimento pessoal. 
7 
 
Espero que este nosso encontro seja interativo e, para isso, 
façam perguntas sempre que necessitarem de alguma 
informação adicional ou tiverem dúvidas. 
Bem, não posso falar de gerenciamento de projeto sem falarmos 
de modelo de gestão. Em poucas palavras, podemos dizer que 
“Modelo de Gestão é composto por duas fases distintas, mas 
interdependentes”. 
A primeira etapa consiste da elaboração da Formulação 
Estratégica, em que é definida a Identidade Organizacional 
(Negócio, Missão, Visão, Vantagem Competitiva e Crenças e 
Valores) e são feitas análises dos ambientes externo e interno. A 
partir desses insumos, são definidos os objetivos globais e as 
diretrizes estratégicas que nortearão as ações da empresa. 
Esta etapa conduz a empresa a organizar suas estratégias 
globais e a desenvolver um senso explícito de direção 
estratégica. 
A segunda etapa consiste da implementação da estratégia 
definida. Nessa etapa, é essencial a adoção de um sistema de 
gestão integrado, que reúna as informações necessárias 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 correções de rumo em 
tempo hábil. 
O BSC é um sistema de gestão, baseado em indicadores que 
mensuram o desempenho, possibilitando à empresa visão do 
negócio atual e futura, de forma abrangente. Ele permite um 
equilíbrio entre objetivos de curto e longo prazo e entre medidas 
financeiras e não financeiras, uma vez que mede o desempenho 
sob quatro diferentes perspectivas: finanças, mercado e imagem, 
processos e pessoas. 
O BSC mostra as relações de causa e efeito entre as Diretrizes, 
pelos indicadores de desempenho, metas e Iniciativas 
8 
 
Estratégicas, que são Programas e Projetos definidos como 
prioritários para o alcance dos resultados pretendidos. 
MC: Sr. PMI, podemos dizer, então, que compete ao 
Planejamento Estratégico e às lideranças das organizações 
identificar e selecionar as melhores ações estratégicas, e ao 
Gerenciamento de Projetos ser o agente executor das 
mudanças? 
PMI: Exatamente. Você já parou para pensar no número de 
mudanças (culturais, tecnológicas, políticas, econômicas, etc.) 
que estão ocorrendo em sua volta neste exato momento? De 
uma maneira geral, é comum associarmos as mudanças 
significativas ao resultado de projetos bem sucedidos. Como 
conseqüência, gerenciar projetos de forma eficiente nessa era de 
grandes mudanças é um dos grandes desafios do executivo dos 
tempos modernos. 
AR (Em pensamento): Eu discordo dessa linha de 
raciocínio. Por que começar a complicar o que já está sendo 
trabalhado? Muito bem, vou continuar ouvindo para ver aonde 
isto vai terminar. 
DS: Sr. PMI por que trabalhar com gerenciamento de projetos? 
O que nós e a empresa ganhamos com isso? 
PMI: Boa pergunta!!! 
O início da implementação do processo de administração 
estratégica tem sido uma das principais preocupações para as 
empresas. Desta forma, a elaboração e acompanhamento de um 
bom projeto permitem o cumprimento de objetivos estratégicos e 
nos direcionam para o futuro. 
O gerenciamento de projetos está no seu pico histórico, 
principalmente por ter se tornado uma escolha estratégica pelas 
empresas. As evidências podem ser vistas nas grandes 
corporações do mundo, que lançam iniciativas e centros voltados 
à excelência no gerenciamento de projetos, executando as 
melhores práticas e visando criar um ambiente favorável ao 
sucesso de seus objetivos e à disseminação do conhecimento 
adquirido. 
9 
 
DS: Você poderia nos explicar melhor por que gerenciar 
projetos? 
PMI: Claro! Por que gerenciar projetos? 
Estudos realizados comprovam que empresas que investiram em 
esforços nas fases de pré-desenvolvimento conseguiram no 
mínimo duplicar as chancesde sucesso no lançamento de seus 
produtos. 
Empresas que não faziam uso de técnicas de gerenciamento de 
projetos tinham em média 71% de atraso nos seus cronogramas 
(e este não era o maior de seus problemas!). 
Segundo Stalk e Houl, a década de 80 foi considerada a década 
da qualidade, e a de 90 a década da responsividade (no sentido 
da resposta rápida ao mercado e no atendimento aos clientes). 
Para Gates, as empresas devem possuir um mecanismo de 
resposta rápida às mudanças, semelhante à capacidade do corpo 
humano em reagir de maneira automática aos estímulos do meio 
exterior. Porém apenas responder de forma rápida a um estímulo 
não 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 
mudanças. 
Estamos num mercado muito competitivo, onde as necessidades 
de atualização tecnológica são constantes. As margens de lucro 
das empresas são cada vez menores e os padrões mais 
exigentes de qualidade. Enfim, ter um gerenciamento de projetos 
passou a ser uma questão de sobrevivência para as empresas. 
SB (Em pensamento) – Já estou ficando cansado. 
Será que essa conversa ainda vai longe? 
 
Evolução do Gerenciamento de 
Projetos 
10 
 
 
MC: Sr. PMI, poderia nos dar uma linha de tempo sobre a 
utilização do gerenciamento de projetos? 
PMI: Vou contextualizar a evolução do Gerenciamento de 
Projetos. 
Achamos que gerenciamento de projetos é recente ou que está 
na moda. Na verdade, a ciência do gerenciamento de projetos 
surgiu no início da década de 60, nas universidades americanas, 
que constataram a precariedade como eram tocados os projetos. 
Inicialmente os projetos eram planejados e acompanhados 
através das técnicas 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 coordenação de 
atividades. Não foram adiante, pois eram planejamentos 
11 
 
enormes, de difícil operação, confeccionados por pessoas com 
pouco conhecimento dos negócios das 
empresas. 
Tradicionalmente os projetos eram executados considerando 
apenas prazo, custos e qualidade. A partir da década de 70, o 
quesito escopo passou a ser essencial no processo. 
Mas ainda assim aspectos como recursos humanos e clientes 
não eram considerados. 
A partir da década de 80, outros itens passaram a ser 
considerados e avaliados e, dessa forma, para se ter sucesso ou 
fracasso, passou-se a considerar também a Satisfação do 
Cliente, Metas quantitativas (escopo, prazo, custo, qualidade, 
indicadores, etc.) e Moral da equipe. 
 
Em 1987, foi publicado o primeiro guia que se tornou referência 
em conhecimento para o gerenciamento de projetos. 
Veja a seguir a ilustração da evolução do gerenciamento de 
projetos: 
 
MC: Sr. PMI, eu poderia dizer que inicialmente os projetos eram 
gerenciados apenas nos quesitos Tempo, Prazo e Custos. Em 
seguida, percebeu-se a importância de acompanhar também o 
que seria executado, ou seja, qual o escopo do projeto. E 
finalmente, nos dias atuais, além desses quesitos, temos que 
12 
 
gerenciar pessoas, compras e riscos, comunicar, entregar com 
qualidade e principalmente ter todos eles integrados. 
PMI: Isso mesmo. 
SB: Ufa! É muita coisa para um projeto só. 
Risos 
O Trabalho nas Organizações 
PR: Muito interessante. Mas como funciona o gerenciamento de 
projetos nas organizações? Todas trabalham “por projeto” ou 
“com projeto”? 
PMI: Vou explicar. 
Na realidade, todas as empresas possuem projetos e processos. 
Segundo Darci Prado, devemos considerar que, em todos os 
tipos de empresa, temos sempre a ocorrência de projetos e 
operações rotineiras e, dessa forma, precisamos avaliar a ligação 
de um destes grupos (projetos ou processos) com os negócios da 
empresa. 
Processos e projetos têm características comuns: 
• executados por pessoas; 
• restringidos por recursos limitados; 
• planejados, executados e controlados. 
O que diferencia o trabalho nas organizações pode ser observado 
a seguir: 
 
13 
 
DS: Posso dizer, então, que a nossa área de compras têm 
processos e que a implantação de um software de compras é um 
projeto? 
PMI: Exatamente. Na maioria das empresas, temos 
processos/rotinas de compras, onde métodos já foram definidos e 
implantados. Essas áreas atendem a vários setores de forma 
sempre contínua. 
Já a implantação de um software, independente de ser de 
compras, é algo novo, que deve ser tratado como um projeto. 
Origem dos Projetos 
DS: Mas qual a origem dos projetos? 
PMI: Normalmente são elaborados partindo de um problema ou 
oportunidade. Como dito anteriormente, são fatos e dados que 
foram identificados e apontados no planejamento estratégico da 
empresa. 
Diversos tipos de projetos ocorrem dentro da organização. Eles 
são elaborados partindo de: 
 
14 
 
MC: Como podemos classificar os projetos? 
PMI: As categorias mais conhecidas de projetos são: 
• Administração; 
• Pesquisa e Desenvolvimento; 
• Design; 
• Construção; 
• Manutenção; 
• Informática; 
• Desenvolvimento de Novos Produtos; 
• Eventos; 
• Instalação de Equipamentos; 
• Melhorias. 
 
Metodologia de Gerenciamento de Projetos 
SF: Gostaria de ressaltar a importância de todas essas 
informações e questionamentos, pois elas embasam a 
necessidade de utilização de uma metodologia para o 
gerenciamento de projetos. 
PMI: Existem hoje várias definições para metodologia de 
gerenciamento de projetos, mas é preciso ficar claro que a 
metodologia adotada deve ser a que se adapte melhor a sua 
empresa e aos projetos por ela gerenciados. 
Uma metodologia de Gerenciamento de Projetos tem que: 
• ser uma coleção de métodos, técnicas e ferramentas para 
desenvolvimento de programas e projetos; 
• ser o principal modelo: estabelecido no Guia PMBOK (Project 
Management Body of Knowledge) pelo Project Management 
Institute – PMI; 
• estabelecer que um projeto deva ser administrado por Gerentes 
de Projetos e sua equipe, que executarão processos de 
gerenciamento de projetos; 
• estabelecer que os processos serão executados ao longo do 
ciclo de vida; 
• estabelecer que os projetos possuam um ciclo de vida; 
• estabelecer que os projetos têm interfaces com as áreas de 
atuação gerencial da organização;e 
• Estabelecer que projetos devem ser apoiados por um Escritório 
de Projetos. 
SB: Agora não entendi nada. Sr. PMI, será que poderia explicar 
melhor as siglas e conceitos acima? 
15 
 
PMI: Perfeitamente. Iremos para um pequeno intervalo do café e 
retornaremos com a descrição geral de alguns itens importantes 
para o gerenciamento de projetos. 
 
CATEGORIAS DE PROJETOS 
 
Diversos tipos de projetos ocorrem nas organizações e, pelas 
peculiaridades de seus processos de gerenciamento, são 
naturalmente classificados em diversas categorias. As mais 
conhecidas são listadas abaixo [4]: 
 
ADMINISTRAÇÃO 
 
Estes projetos estão acontecendo freqüentemente na vida de 
qualquer organização. Alguns exemplos: 
• Campanha para redução de custos; 
• Campanha de desburocratização; 
• Reorganização de um departamento; 
• Implementação de técnicas de GQT (Gerência pela Qualidade 
Total). 
 
PESQUISA E DESENVOLVIMENTO 
 
Trata-se de projetos que objetivam, posteriormente, desenvolver 
ou melhorar um produto, serviço, processo ou método. Para 
alguns projetos dessa natureza, é difícil saber, na fase de 
planejamento, exatamente quando e como se chegará ao produto 
final e, portanto, apresentam alto nível de risco. 
Alguns exemplos: 
• Pesquisa de um novo sabor para um alimento para gato; 
• Pesquisa de um motor de automóvel mais econômico; 
• Pesquisa de uma variedade de soja mais resistente aos 
trópicos; 
• Pesquisa de um medicamento para a cura da AIDS. 
 
DESIGN 
 
Nesta categoria, temos os projetos de arquitetura, engenharia, 
vestuário, software, etc. Eles geralmente fazem parte de um 
projeto maior que envolve uma construção,o desenvolvimento de 
16 
 
um novo produto ou de um software, etc. Portanto eles vão 
somente até a geração da documentação técnica, da construção 
de um protótipo, de uma fábrica-piloto, de um modelo em escala, 
etc. 
Geralmente são precedidos por um projeto do tipo pesquisa e 
desenvolvimento. Posteriormente ao seu término, durante a 
execução definitiva, o projeto de design é seguido por um projeto 
de construção, montagem, programação, etc. Assim, as 
finalidades de um projeto de Design são: 
• Especificações detalhadas do produto. 
• Instruções sobre montagem e construção. 
• Testes em protótipos, fábrica-piloto, modelo em escala. 
Alguns exemplos: 
• Estudo arquitetônico para uma residência (no Brasil, é comum 
chamar o produto final desse estudo de “Projeto Arquitetônico”, o 
que cria uma certa confusão); 
• Estudo hidráulico para um prédio; 
• Estudo elétrico para uma fábrica; 
• Montagem de uma fábrica-piloto de uma indústria química, para 
testes. 
 
CONSTRUÇÃO 
 
Estes projetos geralmente se baseiam em um projeto de 
engenharia (design) já realizado. A duração desses projetos varia 
de meses a anos. São projetos em que é possível efetuar a 
execução de forma bem próxima ao planejado, diferentemente de 
outros tipos de projetos. Nesses projetos, é mais fácil obedecer 
aos custos planejados do que aos prazos. Aspectos de 
segurança são também de fundamental importância devido às 
severas leis governamentais. Alguns exemplos: 
• Construção de um prédio de moradia; 
• Construção de uma barragem hidroelétrica; 
• Construção de um aeroporto; 
• Construção de uma usina siderúrgica; 
• Construção de uma ponte. 
 
MANUTENÇÃO 
 
Estes projetos consistem em desmontar e reconstruir uma 
17 
 
instalação ou produto. São projetos de curta duração, em que o 
benefício da redução do tempo total em um dia pode, 
eventualmente, ser medido em milhões. O aspecto-chave aqui é 
o seqüenciamento das atividades e alocação de recursos no 
exato momento de sua necessidade. Alguns exemplos: 
• Manutenção de um alto-forno de uma usina siderúrgica; 
• Manutenção de uma torre de refinação de petróleo; 
• Revisão de aeronaves. 
 
INFORMÁTICA 
 
Trata-se de projetos relacionados com aplicações para 
computador e aqui se enquadram tanto os projetos de 
desenvolvimento de uma nova aplicação como também a 
aquisição, modificação e a instalação. Assim, alguns deles se 
assemelham a projetos de construção (nos quais é possível 
prever todas as etapas) e outros mais se assemelham a projetos 
de pesquisa nos quais é muito difícil prever antecipadamente 
todas as características do produto final e, também, como se 
chegará a ele. 
 
DESENVOLVIMENTO DE NOVOS PRODUTOS 
 
Estes projetos envolvem o desenvolvimento de um produto 
totalmente novo ou modificações em produtos já existentes. 
Certamente é uma categoria praticada em todas as empresas 
nas quais, geralmente, o processo possui um alto nível de 
padronização. Podem ser vistos de uma forma ampla, 
abrangendo a pesquisa de mercado, o design e desenvolvimento 
do produto e dos correspondentes processos de fabricação, a 
construção da nova fábrica, a produção inicial e a campanha de 
marketing. 
Alguns exemplos: 
• Desenvolvimento e lançamento de uma nova versão do 
software Windows; 
• Desenvolvimento e lançamento do automóvel Fiat Pálio; 
• Desenvolvimento e lançamento de uma nova linha de calçados. 
 
EVENTOS 
 
Devido à ampla aceitação da importância da realização de 
18 
 
eventos, essa categoria de projetos se profissionalizou muito e 
existem inúmeras empresas especializadas nela. Alguns 
exemplos: 
• Feira de vestuários; 
• Convenção de vendas; 
• Show de rock; 
• Comício político. 
 
INSTALAÇÃO DE EQUIPAMENTOS 
 
Um projeto de instalação de um equipamento pode envolver 
inúmeras ações. Por exemplo, a instalação de um grande 
computador envolve: 
• Instalação de ar condicionado em um prédio, supermercado, 
etc.; 
• Instalação de equipamentos de automação. 
 
MELHORIAS 
 
Os projetos de melhorias de indicadores de desempenho 
constituem uma imensa gama de projetos que ocorrem em 
qualquer tipo de empresa. De uma maneira ampla, eles estão 
intimamente ligados às operações rotineiras que ocorrem em 
fábricas, escritórios, lojas, etc. Seu gerenciamento geralmente 
não exige a aplicação de todo o ferramental de gerenciamento de 
projetos, mas costuma exigir bons conhecimentos de técnicas de 
estatística (six sigma black belt) para identificar claramente as 
causas do problema e apontar soluções. Geralmente as soluções 
apontadas exigem conhecimentos de técnicas de Gerenciamento 
pela Qualidade Total. Eventualmente, uma das soluções 
apontadas pode ser, por exemplo, a ampliação ou a construção 
de um novo setor na fábrica e, nesse caso, tem-se um projeto 
tradicional. Alguns exemplos de gerenciamento de melhorias: 
• Diminuição de gastos com transportes de uma empresa 
transportadora; 
• Diminuição do gasto de energia elétrica de um alto-forno 
siderúrgico; 
• Diminuição do tempo de montagem de um produto de uma 
fábrica; 
• Diminuição de re-trabalho em um setor de uma fábrica; 
19 
 
• Diminuição de perdas de peças que se quebram em uma linha 
de produção. 
 
Conceituações 
 
Na área de cofee break 
 
MC: Quanta informação importante estamos recebendo, vocês 
não acham? 
DS: Concordo. No entanto, preciso de mais fatos e dados, para 
efetivamente poder trabalhar com gerenciamento de projetos. 
PR: Não sei não. Acredito que tudo isso só vai burocratizar mais o 
meu trabalho. 
MC: Burocratizar não, Pedro Rocha. Temos de considerar que 
novos processos de trabalho, no início, são complicados, pois 
são novidades. Mas depois facilitam nossas tarefas e 
demonstram a eficiência e eficácia dos nossos resultados. 
20 
 
SB: Aí é que mora o perigo!!! 
Risos de todos 
MC: Como disse o Sr. PMI, a metodologia de gerenciamento de 
projetos traz um conjunto de métodos, técnicas e ferramentas 
para nos auxiliar na execução de programas e projetos. 
SB: São muitas informações para eu assimilar. Não acredito que 
isso vai dar certo. 
MC: Temos que estar mais abertos às mudanças. Vejam só, 
demos o primeiro passo ao elaborarmos nossa planejamento 
estratégico. 
PR: Há, mas esse trabalho ficou só no papel. 
DS: Você está precisando de óculos, Pedro. Não reparou que, em 
todos os andares da empresa, estão os quadros divulgando 
nossa identidade organizacional? 
PR: Não é que eu não reparei? 
MC: E não é só isso. Recebemos material por e-mail. Temos 
insumos suficientes para trabalharmos nossos processos, 
programas e projetos. 
DS: Mas existem muitos conceitos que ainda não estão claros. 
MC: Vamos voltar para o auditório, acredito que neste segundo 
tempo tudo será esclarecido. 
SB: Lá vamos nós de novo. 
 
1º conceito – PMI 
 
SF: Sejam bem-vindos de volta ao nosso encontro. Espero que 
tenham aproveitado esse intervalo para assimilar um pouco mais 
as informações já repassadas. 
PMI: Para aprimorar nossos conhecimentos em gerenciamento de 
projetos, vamos conceituar alguns termos importantes para vocês 
no dia-a-dia. 
Todo o nosso trabalho está conceituado conforme as melhores 
práticas em gerenciamento de projetos definidas no PMBOK, 
publicado pelo PMI. 
PR: (Em pensamento) – Lá vem ele de novo com essas siglas. 
PMI: Mas o que é PMI? 
O PMI - Project Management Institute é hoje a maior instituição 
no mundo exclusivamente dedicada ao fomento da atividade de 
Gerenciamento de Projetos. Criada em 1969 na Pensilvânia, 
21 
 
Estados Unidos, conta hoje com mais de 200.000 filiados 
distribuídos em cerca de 140 países. O PMI compartilha seus 
padrões técnicos e éticos com a comunidade internacional de 
Gerenciamento de Projetos através de organizações sem fins 
lucrativos de âmbito regional. São os Capítulos locais do PMI. 
Hoje são aproximadamente 300 capítulos. 
Com o passar do tempo, o PMI® se tornou, e continua sendo, a 
principal associação profissional em Gerenciamento de Projetos. 
Os associados e interessados em Gerenciamentode Projetos 
têm à sua disposição uma extensa relação de produtos e serviços 
oferecidos pelo PMI®. Esses produtos e serviços estão 
detalhados no site do PMI®, que vocês podem acessar a 
qualquer momento. O site é www.pmi.org. Vou entregar a vocês 
também um arquivo (LINK) com o detalhamento desses produtos 
e serviços. 
 
2º conceito – PMBOK 
 
PMI: E PMBOK? O PMBOK – “Project Management Body of 
Knowledge" (PMBOK® Guide) é um termo que abrange o 
universo do conhecimento da profissão de Gerenciamento de 
Projetos. Esse universo de conhecimento vem dos praticantes e 
acadêmicos que utilizam e desenvolvem tanto as práticas 
amplamente testadas e aprovadas quanto aquelas modernas e 
inovadoras, com aplicação mais restrita. 
Um dos principais mecanismos utilizados para compartilhamentos 
dos padrões técnicos e éticos é a publicação, sempre atualizada 
e revista, do PMBOK - Project Management Body of Knowlwdge, 
um livro que reúne 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 práticas em muitos projetos na maior parte do tempo, 
havendo consenso pelos praticantes sobre seus valores e 
aplicabilidade. Entretanto, a aceitação geral não representa a 
necessidade de aplicação uniforme em todos os projetos, 
devendo ser definido o que é apropriado para cada projeto / 
indústria. 
22 
 
O PMBOK® Guide também estabelece uma linguagem comum 
para a profissão, servindo de referência básica para qualquer um 
que se interesse pelo Gerenciamento de Projetos e, como tal, 
não deve ser encarado como um documento que contemple a 
totalidade do conhecimento de Gerenciamento de Projetos. 
Periodicamente são realizadas revisões, e novas versões são 
desenvolvidas. 
 
3º conceito – Projetos 
MC: O principal conceito de projetos vem do trabalho 
desenvolvido pelo PMI? 
PMI: Sim. Segundo PMI “Projeto é um esforço temporário 
empreendido para criar um produto, serviço ou resultado 
exclusivo”. 
Temporário, pois cada projeto tem início e fim definidos; e 
Exclusivo, pois o produto ou serviço gerado é diferente, em algum 
ponto, de qualquer produto ou serviço existente. 
23 
 
DS: Mas quais são as principais características de um projeto? 
PMI: Um projeto possui várias características, dentre as quais eu 
destaco: 
• ele é sempre Multifuncional, pois requer recursos de várias 
áreas, sejam recursos humanos, materiais ou financeiros; 
• envolve incertezas relativas a escopo, prazos e conteúdo de 
forma geral, que, no início, são grandes, mas diminuem com seu 
andamento; 
• podem sofrer Alterações de escopo, custo e prazo durante sua 
realização; 
PR: Você já classificou os projetos. Poderia me dar exemplos de 
projetos? 
PMI: É claro! Exemplos de Projetos: 
• construção de uma usina siderúrgica; 
• desenvolvimento de um software de computador; 
• construção de um prédio; 
• lançamento de um novo modelo de automóvel; 
• implantação de um Sistema da Qualidade; 
• implantação de um sistema de medição de nível do aço para 
produção de lingotes. 
 
4º conceito – Gerenciamento de Projetos 
 
PMI: Falei, na primeira parte do nosso encontro, sobre 
metodologia de gerenciamento de projetos. Agora explico a vocês 
o que é gerenciamento de projetos. 
Segundo PMI “Gerenciamento de projetos é a aplicação de 
conhecimentos, habilidades, ferramentas e técnicas às atividades 
do projeto a fim de atender aos seus requisitos”. 
Todo projeto deverá ter um responsável a quem chamamos de 
Gerente de Projeto. Este Gerente é o responsável pelo 
gerenciamento do projeto. 
Gerenciar um projeto inclui: 
1. identificar necessidades, estabelecer objetivos claros e 
alcançáveis; 
2. balancear as demandas conflitantes de qualidade, escopo, 
tempo e custo; 
3. adaptar as especificações dos planos e da abordagem às 
24 
 
diferentes preocupações e expectativas das diversas partes 
interessadas. 
SB: Em resumo, para gerenciar projetos, temos que ser um super 
herói. 
risos 
MC: Mas gerenciamento de projetos é só isso? 
SB: Só isso?! 
PMI: Segundo descrição do PMBOK, o gerenciamento de projetos 
existe em um contexto mais amplo que inclui o gerenciamento de 
programas, o gerenciamento de portfólios e o escritório de 
projetos. Normalmente, existe uma hierarquia de plano 
estratégico, portfólio, programa, projeto e subprojeto, na qual um 
programa constituído de diversos projetos associados contribuirá 
para o sucesso de um plano estratégico. 
 
5º conceito – Programas 
 
PR: Tudo muito lindo, mas ainda não sei como isto vai facilitar o 
meu trabalho. Vamos acabar misturando “alhos com bugalhos”. 
PMI: Como acabei de dizer, o gerenciamento de projetos existe 
em um contexto muito mais amplo. Dessa forma temos como 
gerenciar projetos, através de programas. 
Um Programa é um grupo de projetos relacionados entre si, 
administrados e coordenados de forma centralizada para se 
obterem benefícios e controles não disponíveis, 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 específicas de um negócio ou a tipos 
gerais, como infra-estrutura e melhoria interna de processos. 
Programas também envolvem séries repetitivas ou cíclicas de 
ações. 
Exemplos: 
25 
 
• O programa de um novo modelo de carro pode ser dividido em 
projetos de desenho técnico e atualização de cada componente 
principal (por exemplo, transmissão, motor, interior, exterior), 
enquanto a fabricação acontece na linha de montagem; 
• Empresas realizam programas de construção anual, uma 
operação regular e contínua que envolve muitos projetos. 
O gerenciamento de programas compreende a administração 
coordenada e centralizada dos projetos que o compõem, visando 
a alcançar os objetivos estratégicos e os benefícios do programa. 
A estrutura do programa precisa ser revisada e ajustada 
periodicamente, em resposta ao desempenho interno e a fatores 
externos governamentais, tecnológicos, políticos e econômicos. 
Pontos-chave a respeito de programas e projetos: 
• executar um programa é como operar um negócio; 
• ambos têm os clientes e outros envolvidos com interesse no 
resultado; 
• ambos têm uma missão contínua, um propósito e uma visão; 
• ambos também precisam de estratégias 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 são 
planejamento, orçamento, estimativas de recursos, liderança e 
coordenação; 
• o coordenador de programa deve produzir uma série de planos 
específicos e relacionados, que incluem planos estratégicos, 
execução, custos, pessoal, comunicação, negócio e tecnologia; 
• projetos bem definidos aumentam as chances de sucesso do 
programa; 
• programas são dinâmicos e requerem revisão periódica e 
ajuste. 
 
MC: Podemos afirmar que os “Programas são completamente 
dependentes dos seus projetos, subprojetos e processos, e o 
sucesso do programa global é diretamente proporcional ao 
sucesso desses elementos”? 
PMI: Exatamente. Em outras palavras, o sucesso do programa é 
diretamente proporcional ao sucesso dos projetos que o 
compõem. 
26 
 
 
6º conceito – Portfólios 
 
DS: Nem todos os conceitos estão muito claros para mim. Posso 
dizer que gerenciamento de programas é a mesma coisa que 
gerenciamento de portfólio? 
PMI: Não. Portfólio é mais amplo. Portfólio é o conjunto de 
projetos e/ou programas de uma organização, entidade ou 
gerente. Os projetos e/ou programas que compõem um portfólio 
não são necessariamente dependentes ou diretamente 
relacionados. 
PR: Agora bagunçou minha cabeça. Então para que utilizamos 
gerenciamento de programas, se podemos utilizar o 
gerenciamentode portfólios? 
PMI: As empresas utilizam o gerenciamento de portfólios quando 
já possuem uma estrutura bem consolidada de gerenciamentos 
de projetos. 
Dessa forma, o gerenciamento de portfólio passa a ser um 
processo de decisão dinâmico, através do qual uma lista de 
projetos para novos produtos (e para Pesquisa & 
Desenvolvimento) é constantemente atualizada e revisada. Neste 
processo, novos projetos são avaliados, selecionados e 
priorizados; os existentes podem ser acelerados, eliminados ou 
"despriorizados"; e recursos são alocados e realocados aos 
projetos ativos. 
Segundo Ricardo Vargas, Gerenciamento de Portfólio significa 
gerir o conjunto dos projetos e programas com um todo sistêmico. 
Mas não é um todo indiferenciado. É, sim, um sistema que 
comporta diferentes graus de contribuição estratégica. Requer 
agrupar e discriminar todas as iniciativas, permitindo: 
• a alocação diferenciada dos recursos, 
• a alocação adequada dos esforços para atingir os objetivos; e 
• a gestão ótima dos investimentos. 
DS: Mas que benefícios a empresa tem em utilizar o 
Gerenciamento de Portfólios? 
PMI: O Gerenciamento de Portfólios está diretamente vinculado às 
estratégias da empresa. Se vocês lembrarem o que eu disse 
anteriormente, as estratégias traduzem a direção da empresa 
para o alcance dos objetivos. Dessa forma temos os seguintes 
benefícios: 
27 
 
• permite validar a estratégia corporativa; 
• permite o gerenciamento de recursos; 
• liga os resultados dos projetos com as estratégias 
organizacionais; 
• mantém a visibilidade de todas as informações vitais dos 
projetos; 
• facilita o acesso e as comunicações dentro da organização; e 
• subsidia a tomada de decisões. 
SB: Tenho uma memória visual. Você não teria por acaso uma 
representação gráfica de como todas as informações estão 
relacionadas? 
PMI: Tenho sim. Veja a o próximo slide. 
 
PMI: Agora ficou mais claro? 
SB: Ficou sim. Obrigado. 
 
7º conceito – Convênios 
 
PR: Trabalhamos hoje com um volume grande de convênios. 
Podemos considerar que cada convênio é um projeto? 
PMI: Nem sempre um convênio é igual a um projeto. Vocês sabem 
a definição de convênio? 
MC: Convênio é um instrumento jurídico. São acordos firmados 
por entidades públicas de qualquer espécie, ou entre essas e 
28 
 
organizações particulares, para a realização de objetivos de 
interesse comum dos partícipes. 
PMI: Exatamente. Assim temos convênios que representam um 
projeto ou convênios que representam um programa onde 
podemos desenvolver vários projetos. 
PR: Podemos dizer que somos parceiros de entidades públicas no 
desenvolvimento de ações? 
PMI: Sim, podemos. Essas parcerias são concretizadas por meio 
de convênios que definem ações, em regime de cooperação, com 
ênfase nos aspectos relativos à qualidade, produtividade, 
inovação, capacitação, desenvolvimento de estudos, novos 
produtos e processos produtivos. 
Os convênios firmados entre as empresas e os seus parceiros 
geram ações que resultam em projetos, os quais são 
juridicamente contratualizados, especificando escopo, prazo e 
custo. 
29 
 
 
8º conceito – Contratos 
 
DS: Podemos dizer que convênio é o mesmo que contrato? 
PMI: Não. Contrato é um acordo em que os participantes têm 
interesses diversos e opostos, ou seja, quando se deseja, de um 
lado, o objeto do acordo ou ajuste, e do outro, a contraprestação 
correspondente, ou seja, o preço Contrato é um instrumento 
utilizado para firmar, perante terceiros, o compromisso de adquirir 
ou oferecer serviços, materiais e outras obrigações 
reciprocamente estabelecidas. 
Os contratos podem variar em tamanho, conteúdo e propósito. 
De forma geral, há diversos tipos de contratos, como de 
prestação de serviços e de representação, compra e venda de 
bens e/ou produtos. 
MC: Dessa forma podemos dizer que um convênio, além de definir 
um programa ou projeto, também é composto de vários contratos 
para sua execução. 
30 
 
PMI: Isso mesmo. Bem pessoal, termino aqui a minha 
apresentação. Espero ter contribuído com informações que lhes 
permitam aprofundar seus conhecimentos em gerenciamento de 
projetos. 
SF: Gostaria de agradecer a todos pela participação neste 
encontro. Tenho a certeza de que demos o primeiro passo para a 
implantação de uma boa gestão de projetos na empresa. O Sr. 
Paulo Martins Inácio estará à disposição para quaisquer 
esclarecimentos que vocês necessitem tendo em vista o bom 
desenvolvimento de suas tarefas. Desejo a vocês um ótimo 
trabalho. 
 
Organização do Gerenciamento de Projetos 
 
Na empresa: 
 
SB: Vamos almoçar? 
31 
 
DS: Ótima idéia. Toda essa conversa me deixou com fome. 
MC: Aonde vamos almoçar? 
SB: Tem um restaurante de um amigo meu, que foi inaugurado na 
semana passada. Vamos conhecê-lo? 
PR: Espero que a comida seja boa! 
Rsrs 
 
1º – Ciclo de Vida 
 
MC: Vocês conseguem observar que tudo ao nosso redor lembra 
gerenciamento de projetos? 
PR: Você já está delirando por causa da fome. 
DS: Como assim Maria Conselheira? 
MC: Observem aquelas duas árvores. Uma está seca e a outra 
está com todo vigor. 
SB: Mas o que isto tem a ver com gerenciamento de projetos? 
MC: Tudo na vida tem um ciclo de vida. Aquela árvore seca, com 
certeza, teve seu ciclo. 
32 
 
DS: Você quer dizer que ela foi plantada, cresceu, deu frutos e 
agora está morrendo? 
MC: Isso mesmo! 
PR: Faço minhas as palavras do Been. O que isso tem a ver com 
gerenciamento de projetos? 
MC: O conceito de ciclo de vida é: “Conjunto de atividades que 
caracterizam a seqüência de desenvolvimento do projeto, 
organizadas em fases e etapas”. É isso que a Delma descreveu. 
A árvore passa por várias fases e etapas, como um projeto. 
PR: Você quer dizer, então, que o ciclo de vida de uma árvore é 
igual ao ciclo de vida de um projeto? Você ficou maluca! 
MC: rsrs. Eu não disse que são iguais, e sim que possuem as 
mesmas características, ou seja, um ciclo de vida define o início e 
o fim de um projeto. 
DS: Se entendi bem, podemos dizer, então, que todos os projetos 
possuem um ciclo de vida, ou seja, nascimento, maturidade, 
velhice e morte. 
 
2º – Processos 
 
MC: Isso mesmo. Essas etapas são chamadas de processo no 
gerenciamento de projetos. 
SB: Maria Conselheira, como você sabe tudo isso? 
MC: Tenho estudado sobre o tema gerenciamento de projetos e, 
depois do encontro de hoje, muitas coisas ficaram mais claras 
para mim. 
PR: Então me explique melhor sobre o que são processos em 
gerenciamento de projetos. 
33 
 
MC: Voltando ao início da nossa conversa, observe aquele ninho 
que está na árvore. O que você vê? 
PR: Um ninho cheio de passarinhos cantando. E daí? 
MC: Veja com outros olhos e lembre o que a Delma falou. Tudo 
não passa de um ciclo. Os passarinhos nascem, aprendem a 
voar, depois acasalam, tem seus filhotes e depois morrem. 
As etapas estão ligadas umas nas outras. Os processos do 
gerenciamento de projetos também. Podemos dizer que 
processos são conjuntos de ações ou atividades 
interrelacionadas, para criar um produto ou serviço específico. 
 
3º – Processos de Gerenciamento de Projetos. 
 
SB: Mas espera aí. Os processos de Gerenciamento de projetos 
são nascimento, maturidade, velhice e morte!? 
MC: Não. Em gerenciamento de projetos, temos: 
• Nascimento = iniciação ou concepção 
• Adolescência = planejamento 
• Maturidade = execução 
• Velhice = Monitoramento e controle 
• Morte = encerramento. 
DS: Se eu entendi bem, então podemos dizer que o 
gerenciamento de projetos é uma atividade de integração desses 
processos, que devem ser executados simultaneamente, tantas 
vezes quantas necessárias. 
MC: Exatamente. 
PR: Mas para que ciclo de vida? 
MC: Lembra-se do que o Sr. PMI nos disse mais cedo? Ele disse 
que toda organização que trabalha com projetos possui uma 
metodologia à qual se adapta melhor e: 
• estabelece que os processos sejam executados ao longo do 
ciclo de vida; 
• estabelece que os projetos possuam um ciclo de vida. 
SB: Está bom. E daí? 
DS: Acho que consigoexplicar. A formalização dos processos ao 
longo do ciclo de vida permite que a organização administre seus 
projetos considerando sempre as suas características internas. 
PR: Antes que “dê um nó” na minha cabeça, posso traduzir isso 
da seguinte forma: 
34 
 
1. Ciclo de vida é formado por processos; 
2. Os processos são: processos de iniciação; processos de 
planejamento; processos de execução; processos de 
monitoramento e controle; processos de encerramento; e que 
3. O inter-relacionamento desses processos permite um bom 
gerenciamento de projetos. 
MC: Muito bom, Pedro. É exatamente isso. 
SB: Então gerenciar projetos é muito fácil! 
DS: Fácil eu não diria. Exige conhecimento e dedicação. 
SB: Já estou com muita fome. Podemos ir para o restaurante? 
DS: Boa idéia. Daqui a pouco não conseguimos nem lugar no 
restaurante para almoçar. 
PR: Então vamos todos no meu carro. Assim continuamos essa 
conversa. Este assunto está começando a me interessar. 
 
4º – Áreas de conhecimento. 
 
MC: Voltando a nosso assunto e falando em conhecimento, vocês 
se lembram do nosso programa de qualidade? 
PR: O que isso tem a ver com gerenciamento de projetos? 
35 
 
MC: Tudo! 
 
MC: Na realidade, o relacionamento dos processos é igual ao ciclo 
do PDCA, ou seja, planejamos, desenvolvemos, checamos e 
corrigimos as falhas. (Ver figura acima) 
DS: Maria, se temos todos os processos, precisamos detalhar um 
pouco mais para termos uma boa gestão dos projetos. 
MC: Segundo o PMBOK, temos nove áreas de conhecimento que 
nos ajudam na gestão de projetos. 
SB: Áreas de conhecimento? O que é isso? 
MC: As áreas de conhecimento são definidas pelo PMI. Elas 
descrevem os conhecimentos e práticas em termos de 
processos. Esses processos estão organizados em 9 (Nove) 
áreas, que são: 
1. Gerenciamento da Integração; 
2. Gerenciamento do Escopo; 
3. Gerenciamento do Tempo; 
4. Gerenciamento do Custo; 
5. Gerenciamento da Qualidade; 
6. Gerenciamento dos Recursos Humanos; 
7. Gerenciamento das Comunicações; 
8. Gerenciamento do Risco; 
9. Gerenciamento das Aquisições do Projeto (Suprimentos). 
PR: E como tudo isso está relacionado? 
MC: Espere... Tenho um material na minha pasta que pode 
exemplificar o seu questionamento. 
 
PROCESSOS, ÁREAS DE CONHECIMENTO E O CICLO DE VIDA 
36 
 
 
SB: É Delma...tenho que concordar com você. Gerenciar projetos 
exige muito conhecimento. Veja o quadro que a Maria nos 
mostrou. Até me deu mais fome. Esse quadro parece uma sopa 
de letrinhas. 
DS: Você leva tudo na brincadeira, mesmo quando o assunto é 
sério. 
Risos 
PR: Chegamos. Vou estacionar enquanto vocês entram. 
SB: OK, Rocha. Iremos procurar uma boa mesa e aguardamos 
você. 
 
 
____________________________________________________
_______________________________________ 
ÁREAS DE CONHECIMENTO 
 
Gerenciamento de Integração – processos que garantem que os 
diversos elementos do projeto estão apropriadamente 
coordenados. Consiste do desenvolvimento do plano de projeto, 
execução do plano e controle de mudanças. 
Gerenciamento de Escopo – processos necessários para garantir que 
o projeto inclui todo o trabalho requerido, e somente o trabalho 
requerido, para que seja completado com sucesso. Consiste da 
iniciação do projeto, planejamento de escopo, definição de 
escopo, verificação de escopo e controle de mudança do escopo. 
37 
 
Gerenciamento do Tempo – processos que garantem que o projeto 
seja concluído no tempo correto. Consiste de definição das 
atividades, sequenciamento de atividades, estimativas de 
duração de atividades, criação do cronograma e controle do 
cronograma. 
Gerenciamento de Custo – processos necessários para garantir que 
o projeto seja completado dentro do orçamento aprovado. 
Consiste de planejamento de recursos, estimativa de custos, 
definição de orçamento e controle de custos. 
Gerenciamento da Qualidade – processos necessários para que o 
projeto satisfaça as necessidades para as quais foi criado. 
Consiste do planejamento, asseguramento e controle da 
qualidade. 
Gerenciamento de Recursos Humanos – processos para garantir o uso 
mais eficiente das pessoas envolvidas no projeto. Consiste de 
planejamento organizacional, bem como de formação e 
desenvolvimento da equipe. 
Gerenciamento de Comunicações – processos necessários para que a 
informação do projeto seja gerada, coletada, disseminada, 
armazenada e/ou descartada da forma correta. Consiste de 
planejamento da comunicação, distribuição da informação, 
relatórios de desempenho e fechamento administrativo. 
Gerenciamento de Risco – processos que identificam, analisam e 
respondem aos riscos do projeto. Consiste de identificação de 
riscos, quantificação e qualificação de riscos e desenvolvimento e 
controle da resposta aos riscos. 
Gerenciamento de Aquisições – processos necessários para a 
aquisição de bens e serviços de terceiros. Consiste de 
planejamento de aquisições, planejamento de solicitações, 
seleção dos fornecedores, administração de contratos e 
fechamento de contratos. 
 
Desenvolvimento de Projetos: Idealização e Concepção 
38 
 
 
No Restaurante 
 
SB: Nossa, que lugar legal! 
DS: Também concordo. 
MC: Been, você conhece o dono deste restaurante, não é? 
SB: Sim, ele é meu amigo. Por que a pergunta? 
MC: Porque eu queria saber dos detalhes deste projeto. 
PR: Que projeto? 
MC: O deste restaurante, é claro!! 
SB: Agora tudo virou projeto? 
MC: Been, você acha que este restaurante foi montado sem um 
bom projeto? 
PR: Maria, você poderia nos explicar melhor? 
MC: É claro. Vamos entrar, que durante o almoço eu explico. 
39 
 
 
1º - Termo de abertura 
 
MC: Lembram:se da nossa conversa quando estávamos vindo 
para o restaurante? 
DS: Sobre o ciclo de vida? 
MC: Isto mesmo! 
SB: O que isso tem a ver com a montagem deste restaurante? 
MC: Tudo. Desenvolver um projeto é “executar o ciclo de vida”. É 
conceber, é planejar, é executar e acompanhar, é encerrar. 
DS: Maria, se eu estou entendendo bem, todo este trabalho 
depende de uma metodologia, como disse o Sr. PMI. Precisamos 
de métodos, técnicas, modelos e ferramentas para 
desenvolvimento de projetos. 
MC: Alguns documentos são essenciais para um projeto. 
Segundo o Guia PMBOK®, existem três documentos principais e 
cada um deles possui um objetivo especifico. 
PR: Quais são eles, Maria? 
MC: Termo de abertura, Declaração 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 disponíveis e define a resposta para o “problema” do 
cliente ou necessidade/oportunidade do mercado. 
PR: Maria, você não acha que toda essa “coisa” de 
gerenciamento de projetos burocratiza muito o nosso trabalho? 
MC: Claro que não, Rocha. Voltando ao termo de abertura. 
Quando o dono deste restaurante resolveu abri:lo, ele criou um 
termo de abertura, mesmo que não tenha utilizado esse nome. 
Ao fazer o termo de abertura, com certeza foi feita uma análise 
40 
 
crítica com vistas a identificar algumas características básicas 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 documentação das necessidades de negócios, da 
justificativa do projeto, do entendimento atual das necessidades 
do cliente e do novo produto, serviço ou resultado que deve 
satisfazer esses requisitos. 
SB: Oh! Maria, você falou e não disse nada. Continuo não 
fazendo nenhuma ligação do gerenciamento de projetos com a 
abertura de um restaurante. 
MC: Risos. 
 
2º - Identificação do Projeto 
MC: Muito dos nossos sonhos ficam só na nossa cabeça, outros 
tornam:se grandes idéias e transformam:se em projetos. Acho 
que foi o que aconteceu com seu amigo, Been. No caso das 
41empresas, as idéias surgem muitas das vezes da necessidade de 
progresso ou de uma oportunidade de mercado. 
 
MC: Você parece que não entendeu. Vou melhorar minha 
explicação. Ao começar a montagem deste restaurante, seu 
amigo colocou suas idéias num papel. A primeira coisa que ele 
fez foi identificar sua idéia, ou melhor, seu projeto. 
DS: Maria, veja se eu entendi bem: quando uma organização 
inicia um projeto, ela utiliza um documento de abertura deste 
projeto e nele identifica que tipo de projeto ele é. 
MC: Não 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 idéia. Então, 
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 alimentação que o 
42 
 
restaurante vai fornecer. É o que acontece com os nomes dos 
projetos. Eles identificam o projeto. 
PR: Muito fácil. E é só isso. Colocamos o nome do projeto e está 
tudo entendido. Até parece. 
DS: Não seja tão cético, Rocha. Acredito que todos os processos 
venham para facilitar nosso trabalho, desde que muito bem 
explicado. 
MC: Isso mesmo, Delma. E, no caso do Gerenciamento de 
Projetos, temos fatos e dados que comprovam isso. Além do 
mais, temos uma metodologia descrita e aprovada em nossa 
empresa. Cabe a nós colocá:la em prática. 
SB: Para que mexer em time que está ganhando, Maria? Está tão 
bem como está! 
Todos: Risos 
DS: Been, você é muito tranqüilo. Maria, mas identificar um 
projeto é só dar nome a ele e pronto? 
MC: Além do nome, identificamos quem será o gerente desse 
projeto, estabelecemos a justificativa para sua elaboração, 
fazemos uma primeira análise crítica de seus custos e benefícios, 
além de outros itens, de acordo com o Termo de Abertura que a 
empresa estabeleceu em sua metodologia. 
PR: Estava fácil demais para ser verdade. Eu não disse que isso 
tudo burocratiza nosso trabalho? 
DS: Pelo que eu estou percebendo, o termo de abertura pode ser 
considerado um resumo do projeto. 
MC: Um resumo detalhado. Veja o que mais devemos ter neste 
termo de abertura. 
 
3º - Meta - objetivo, prazo e valor 
 
SB: Acho que nós hoje só vamos almoçar projeto. Vocês não 
querem mudar de assunto? 
PR: Quero continuar esta conversa Been, pois temos que 
aproveitar o conhecimento da Maria nesse papo descontraído. 
DS: Muito bem, Rocha. Concordo com você. É melhor 
conversamos e tirarmos nossas dúvidas aqui, do que dentro da 
empresa. 
SB: Já percebi, sou voto vencido. Já que o que não tem remédio, 
remediado está,, então vamos continuar. 
MC: Você sempre brincando. Mas, como eu estava dizendo, 
quando iniciamos um projeto, precisamos ter algumas 
43 
 
informações que são 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 alcançar ou qual fraqueza interna precisamos 
minimizar. Dessa forma, assim que justificamos o porquê do 
projeto, estabelecemos o seu objetivo, o prazo para sua 
execução e quanto ele vai custar. 
PR: De prazo e custo eu entendo bem. Para estabelecermos 
prazo e quanto vai custar, não podemos simplesmente colocar no 
papel, como um “chute”. 
DS e MC: Claro que não! 
PR: Então precisamos elaborar um estudo de viabilidade a fim de 
definirmos prazo e custo para todos os projetos? Estou 
começando a gostar desse assunto. 
MC: Depende do tamanho de projeto. 
PR: Como é que é? 
MC: Desculpe, Rocha. Eu não falei direito. Dependendo do tipo do 
projeto, apenas um orçamento inicial é suficiente. 
DS: Explique melhor o que são tipos de projeto e sobre custos do 
projeto. 
MC: OK. Os projetos são 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 estratégia, gestão, suprimentos, 
envolvimento de especialistas, etc. 
PR: Mas como são feitos esses agrupamentos? 
MC: O Sr. PMI nos apresentou uma lista com esses tipos de 
projetos, lembram:se? 
SB: Disso eu me lembro. Os projetos podem ser administrativos, 
de Pesquisa, de Software, dentre outros. 
MC: Muito bem, é isto aí. Dependendo do tipo de projeto, eles vão 
apresentar diferentes necessidades. Os projetos apresentam 
sempre um grau de incerteza, necessidade de tecnologia, 
possuem prazo e têm um custo. Dessa forma um projeto 
administrativo normalmente tem um grau de incerteza e custos 
baixos, enquanto um projeto de construção tem grau de incerteza 
baixa e custos altos. Vejam este quadro: 
44 
 
 
MC: Para propiciar a escolha do nível de gerenciamento, 
planejamento e controle, além da documentação a ser utilizada, 
classificamos os projetos através do método “valor versus 
complexidade”.Os projetos podem variar desde Tipo 1 a Tipo 4, 
que significa projetos pequenos, médios, grandes e muito 
grandes. Essa variação depende da metodologia adotada por 
cada empresa, além do tipo de produto e serviços prestados. 
Dependendo da classificação do projeto, maior a necessidade do 
detalhamento de custos. Um projeto administrativo tem a 
necessidade de um orçamento, enquanto um projeto de um novo 
produto necessita de um Estudo de Viabilidade Técnica e 
Econômica, mais conhecido como EVTE. Um estudo de EVTE 
aconselhará quanto a prazo, equipe, termos de referência e 
logística. Informará a natureza e extensão de quaisquer ameaças 
ao sucesso do projeto e a extensão e conseqüências do risco. 
SB: E aí, Rocha, você bem que poderia nos dar uma aula de 
EVTE como a Maria. 
45 
 
PR: Aula, eu não sei se sou capaz, mas se vocês 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á começando a se 
interessar pelo assunto. 
PR: Maria, ainda tenho dúvidas. Como definir o tipo de projeto? 
MC: Boa pergunta. Como você gosta muito de matemática, a 
definição do tipo de projeto será uma média do grau de 
complexidade dos fatores que interferem num projeto. 
SB: Como é?! 
MC: Calma. Existem fatores que interferem muito, outros pouco e 
alguns mais ou menos. Damos peso a essas interferências e 
depois fazemos uma média dos valores. 
DS: Maria, dê-nos mais exemplos. 
MC: Certo. Vamos lá. Vou citar alguns exemplos de complexidade 
que usamos atualmente em nossa empresa. 
 adequação do prazo de entrega: a pressão sobre o tempo é 
um dos principais aspectos: quanto maior a pressão, mais complexo 
o projeto. Considerar, na avaliação, o dimensionamento da equipe; 
 influências e fatores políticos: restrições à execução 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; 
 número de clientes envolvidos: quanto maior o número de 
empresas envolvidas, maiores serão a complexidade e o desafio de 
integração entre as mesmas; 
 número de organizações envolvidas: quanto maior o número 
de organizações envolvidas, maior será a complexidade e o desafio 
de integração entre as mesmas; 
 número de pessoas da equipe envolvidas na execução: 
quanto maior a equipe executante, maior a complexidade do 
projeto; 
 financiamento: os projetos podem ter financiamento interno, 
com recursos próprios das entidades ou financiamento externo de 
organizações. Os projetos com financiamento externo têm 
46 
 
prioridade sobre os demais, refletindo:se em uma maior 
complexidade; 
 Visibilidade: grau de visibilidade que esse projeto terá em 
relação aos parceiros e clientes; 
 Aderência aos objetivos estratégicos: a quais objetivos 
estratégicos da instituição esse projeto visa atender; 
 nível de interação: grau de interação de empresas associadas 
e filiadas a sindicatos envolvidos na execução do projeto. Quanto 
menor a integraçãoentre as empresas, maior será a complexidade 
do projeto (esse nível 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; 
- Médio: Média Complexidade 
- Grande: Grande Complexidade; 
- Muito grande: Grande complexidade 
PR: E daí, o que fazemos? 
MC: Os projetos são classificados conforme seu grau de 
complexidade, levando:se em consideração critérios 
estabelecidos em uma metodologia. Cada critério é avaliado 
como sendo pequena (P), média (M) ou alta (A) complexidade; e 
recebe, em função disso, uma pontuação. Com base no valor 
médio da pontuação atribuída aos critérios, define-se um grau de 
complexidade A, B ou C para o projeto. 
47 
 
 
SB: Nossa! Agora deu um nó na minha cabeça. 
DS: Se eu estou entendendo bem, esta matriz nos dará a 
dimensão do projeto? 
MC: Mais ou menos. Na realidade, a dimensão de um projeto será 
determinada confrontando:se, em uma matriz, o valor do 
investimento necessário com a sua complexidade. 
Existem quatro dimensões possíveis: 
 
- PJ0: Muito pequeno; 
- PJ1: Pequeno; 
- PJ2: Médio; 
- PJ3: Grande; 
- PJ4: Muito grande. 
Alguns exemplos de valores e prazos para projetos: 
 Prazos: 
- Muito pequeno: 0 a 2 meses; 
- Pequeno: 3 a 4 meses; 
48 
 
- Médio: 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; 
- Médio: R$ 50.001,00 a R$ 250.000,00; 
- Grande: R$ 250.001,00 a R$ 1.000.000,00; 
- Muito grande: acima de R$ 1.000.000,00. 
 
TABELA 2: Classificação: Valores X Grau de Complexidade 
 
DS: Não podemos esquecer que essa classificação vai variar de 
empresa para empresa. 
MC: Isso mesmo. Como eu estava explicando, as empresas que 
possuem uma metodologia de gerenciamento de projetos 
definem os valores de seus projetos de acordo com o tipo de 
produto ou serviço prestado. 
DS: Objetivo, prazo e valor, posso traduzir esses conceitos como 
META de um projeto? 
MC: Exatamente. Num termo de abertura, esse item é chamado 
de Meta do projeto. 
49 
 
SB: Oh, Maria, os preços deste cardápio podem ser considerados 
como sendo o valor do projeto? 
MC: Não. Custo é aquilo que o dono do restaurante “pagou” pelos 
ingredientes e pela mão-de-obra para confecção dos pratos. Já o 
preço é o que eles nos cobra, ou seja, o custo de produção mais 
uma margem de lucro. 
PR: Maria, nesse caso o valor do projeto é o custo do projeto. 
MC: Isso mesmo. 
PR: Para calcular o valor do projeto, eu incluo os custos diretos e 
indiretos do projeto? 
MC: Inclui, sim. Uns dos maiores “estouros” no orçamento do 
projeto é justamente o esquecimento na hora de elaborar o 
detalhamento dos valores e só incluir os custos diretos. 
SB: Puxa, eu fiz uma pergunta tão simples e vocês complicaram 
tudo. Alguém pode dizer, então, como é que se calcula o valor de 
um projeto? 
DS: Pelo que eu entendi o valor do projeto é calculado pela soma 
dos custos diretos e indiretos. 
MC: Todo projeto tem um orçamento inicial na sua fase de 
concepção. Na fase de planejamento, existe o detalhamento dos 
custos, o qual chamamos gerenciamento de custos. 
SB: Você me apertou sem me abraçar. Cálculo é com o Rocha. E 
custo, para mim, é tudo igual. Eu gosto é de escrever. Tudo muito 
tranqüilo. 
Risos 
PR: Acho que posso ajuda:lo, Been. Custos diretos são facilmente 
identificados e quantificados a partir dos recursos necessários 
para a realização das atividades. Eles são diretamente atribuídos 
ao processo e não necessitam de rateio. Por exemplo, no caso 
desta refeição, as carnes, os legumes, o tempo da cozinheira são 
custos diretos. Custos indiretos são despesas gerais e gastos 
incorridos pela empresa em benefício de mais de um processo. 
Normalmente são custos relativos à manutenção do negócio. 
Aqui no restaurante, a mão-de-obra dos garçons representa 
custos indiretos. 
SB: Puxa, Rocha, você já está até gostando de projetos! 
PR: Estou passando a acreditar que gerenciamento de projetos 
não é algo tão complicado. 
MC: E não é. Como eu disse antes, temos que estudar, entender 
do assunto, conhecer a metodologia adotada pela nossa empresa 
e colocá:la em prática. Os benefícios aparecem com o tempo. 
50 
 
DS: Isso é verdade. Maria, o Rocha nos deu conceitos de custos 
específicos. Eles são os mesmos para os projetos? 
MC: São. Explicando com uma linguagem mais de projetos, os 
custos diretos normalmente são horas de trabalho, custos de 
viagens da equipe, custos dos materiais utilizados no projeto, 
dentre outros e os custos indiretos são despesas administrativas 
(salários de técnicos e administrativos; energia elétrica, telefone), 
despesas com tributos e impostos, etc. 
 
4º - Escopo Preliminar 
 
PR: Definidas as metas do projeto, já podemos planejar como 
vamos executar o projeto? 
DS: Acho que não. Pelo pouco que entendo de gerenciamento de 
projetos, o próximo passo é definir o escopo do projeto. É isso 
mesmo, Maria? 
MC: Definimos o escopo preliminar. 
SB: O que é escopo? 
MC: Segundo o Guia PMBOK®, escopo é “a soma dos produtos, 
serviços 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, serviço ou resultado 
com as características e funções especificadas”. Em outras 
palavras, escopo é a descrição dos limites do projeto. 
Caracteriza:se pela definição do trabalho que será realizado, 
definindo:se os produtos de cada etapa e as atividades 
necessárias para sua execução, e também o “que não será feito” 
dentro da abrangência, eliminando qualquer expectativa dos 
clientes e stakeholders não previstas. 
SB: Você poderia apresentar um exemplo para mim? 
MC: Claro. Vou apresentar um exemplo bem simples. Pegue o 
cardápio novamente. 
51 
 
 
SB: Peguei. E daí? 
MC: Observe como ele está distribuído. Você pode descrevê-lo? 
SB: Entradas, Prato Principal e Sobremesas. 
MC: Podemos descrever esses itens como sendo as metas do 
projeto, ou seja, eles têm um objetivo (nesse caso atender 
nossos desejos alimentares), tem um preço e um prazo para 
ficarem prontos. Em contrapartida, para cada item deste 
cardápio, existe uma lista de atividades que devem ser seguidas 
para entrega, a qual podemos descrever como escopo. 
DS: Gostei dessa comparação. Nunca imaginaria fazer essa 
correlação. 
PR: Se eu entendi bem, escopo é tudo aquilo que precisamos 
fazer para que o projeto “aconteça”. 
MC: Isso mesmo. Mas devemos lembrar que, na concepção de 
um projeto, o escopo é preliminar, pois, no detalhamento do 
planejamento do projeto, podemos ampliar ou diminuir o escopo 
inicialmente definido. 
DS: Maria, considerando nossa empresa, que presta serviços 
para o governo e que está sujeita a algumas regras do governo, 
52 
 
como por exemplo, a Lei 8.666 e a Instrução Normativa IN:97, 
que impacto isso tem no escopo de um projeto? 
MC: No escopo, nada. Esse tipo de “regra” é chamado de 
restrição. Normalmente é um evento ou limitação que impacta o 
projeto e que deve ser contornado. Uma restrição pode causar 
um risco no cronograma, mas a restrição em si não é um risco. 
As restrições são fatores que limitam as opções da equipe de 
gerenciamento de projetos e que as obrigam a trabalhar de 
maneira criativa. 
Exemplos de restrições: 
Um recurso pode não estar disponível até 30 dias após o início 
do projeto. 
Tecnologia: usar apenas tecnologias em uso na empresa. 
Recursos: não serão contratados terceiros. 
Orçamento: custo restrito. 
Data: a inauguração da obra está marcada. 
 
53 
 
 
5º - Identificação de riscos 
 
MC: Eu falei em riscos. Vocês sabem me dizer o que são riscos 
no projeto? 
SB: Acho que nosso maior risco aqui é comermosmuito e não 
darmos conta de voltar para o trabalho. 
TODOS: RISOS 
SB: Mas, agora sem brincar, para mim risco é algo que pode 
acontecer e que não temos controle sobre ele. 
MC: Muito bom Been. Você está quase certo. Risco em projetos 
corresponde a um evento ou condição incerta que, se 
efetivamente ocorrer, pode implicar efeito positivo ou negativo 
nos resultados do projeto. Dependendo do risco, podemos 
controlá-lo e até aproveitá:lo a nosso favor. 
SB: Aproveitar um risco a nosso favor!? 
MC: Sim, riscos em projetos incluem tanto oportunidades quanto 
obstáculos para atingir os resultados de um projeto. Quanto mais 
54 
 
cedo identificarmos os riscos na concepção de um projeto, mais 
fácil será gerenciá-los. 
PR: Você poderia falar mais sobre a natureza dos riscos? 
MC: Rocha, os riscos podem ser de natureza interna e externa. 
No caso de riscos externos, não temos controle e tampouco 
conseguimos mudar. No caso de riscos internos, dependendo do 
risco, podemos controlá-lo e até influenciá-lo. Mas vamos 
conversar sobre isso mais tarde. Estou ficando com fome. Vamos 
comer um pouquinho? 
 
6º - Stakeholders 
 
DS: Nossa, a comida deste restaurante é realmente muito boa. 
Seu amigo superou minhas expectativas. Dê os parabéns a ele 
por mim, Been. 
PR: Acho que superou todos nós. 
MC: Concordo com vocês. Nós, como stakeholders deste projeto, 
estamos muito satisfeitos com o resultado alcançado. 
DS: Stakeholders não são os patrocinadores do projeto? 
55 
 
MC: Também. Stakeholders são pessoas, órgãos, 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 decorrência da 
execução ou conclusão do Projeto. Os Stakeholders podem 
influenciar o Projeto, bem como os seus resultados. 
PR: Então somos “Stakeholders Clientes?” 
MC: E também usuários finais. 
SB: Quais são os principais stakeholders? 
DS: Muito bem, Been, você já está começando a se interessar 
pelo assunto. Acho que essa resposta eu sei. Principais 
Stakeholders são: Sponsor (que é que paga pelo projeto), o 
Gerente de Projeto, os clientes (indivíduo ou organização que 
adquiriu os produtos gerados pelo projeto), a Organização 
“executora” (entidade responsável pela execução do projeto), a 
equipe do projeto, os Fornecedores e os usuários finais que são 
os indivíduos ou organização que farão uso dos produtos. 
MC: Isso mesmo. Esta nossa conversa está sendo muita boa. 
Acredito que assim a utilização do Gerenciamento de Projetos 
será muito prazerosa e nos trará muitos resultados. 
DS: Também acho. E vocês, rapazes, o que acham? 
PR: Estou começando a entender o assunto e acho que poderei 
contribuir neste processo, mas ainda não sei se saberei utilizar 
este gerenciamento de projetos. 
SB: Sei não. Deixe:me conhecer um pouco mais para eu ver 
como posso contribuir e saber como utilizar o gerenciamento de 
projetos. Vamos continuar almoçando. 
 
Desenvolvimento de Projetos: Planejamento 
56 
 
 
No Restaurante 
 
SB: Que comida boa! O tempero está muito suave. 
DS: Concordo com você. Não deve ser fácil elaborar um cardápio 
tão variado e tão saboroso. 
MC: Seu amigo Been deve ter uma boa estrutura e bom 
planejamento para que tudo dê certo. 
DS: Este planejamento pode ser comparado com o planejamento 
de um projeto? 
PR: Maria, você poderia nos explicar melhor? 
MC: É claro. Vamos assentar, que durante o almoço eu explico. 
 
Plano de gerenciamento de projetos 
 
MC: Eu acredito que tudo que fazemos, seja no trabalho, seja na 
nossa vida pessoal, depende de um bom planejamento. No caso 
57 
 
do gerenciamento de projetos, temos algumas etapas e 
procedimentos que são específicas. 
PR: E quais seriam essas fases? 
MC: Lembra-se da nossa conversa quando estávamos vindo para 
cá? 
PR: Sobre as fases do ciclo de vida? 
DS: Não só sobre o ciclo de vida, mas também dos processos que 
compõem cada fase. 
MC: Isso mesmo. Todo projeto tem um ciclo de vida com suas 
respectivas fases e processos. Dessa forma temos o que 
chamamos “Plano do Projeto”. 
PR: Lá vem você novamente com mais informação. 
DS: Calma, Rocha. Deixa a Maria explicar. 
MC: Risos. Como estava dizendo, um dos maiores benefícios de 
uma metodologia de gerenciamento de projetos é ter definido o 
conjunto de normas e métodos, técnicas, modelos e ferramentas 
para desenvolvimento de projetos. Assim, o Plano do Projeto faz 
parte desse conjunto. 
DS: Mas como é composto o Plano do Projeto? 
MC: Ele é um documento composto basicamente por vários 
planos auxiliares e específicos de áreas de conhecimento, que 
são: 
- o Plano Organizacional; 
- o Orçamento de Custo; 
- o Plano da Qualidade; 
- o Plano de Comunicação; 
- o Planejamento de Suprimentos; 
- Plano de Resposta aos Riscos; 
- e o Cronograma de Execução. 
O plano inclui as ações para definir, coordenar e integrar todos os 
planos auxiliares de trabalho definidos para o projeto. 
DS: Podemos dizer que o plano define como o projeto é 
elaborado, monitorado, controlado e encerrado? 
MC: Sim. Podemos. 
PR: Maria, você poderia nos explicar o que significa cada um 
deles? 
MC: Posso tentar. 
SB: Não seja modesta, Maria. Você tem nos ajudado muito com 
seu conhecimento. Estou começando até a me interessar pelo 
assunto. 
58 
 
DS: Começando Been!? Acredito que esse processo “é um 
caminho sem volta”. 
SB: Caminho sem volta!? Que papo mais fúnebre é esse, Delma? 
DS: Você não leva jeito mesmo. Só estou querendo dizer que 
esse processo é muito importante para nós e que, ao 
trabalharmos com uma metodologia de Gerenciamento de 
Projetos, não temos como voltar para os nossos controles 
separados. 
SB: Ah bom. Assim está melhor. 
PR: Been, deixa a Maria explicar. 
MC: Vou tentar explicar o plano de projeto deste restaurante, 
aliás, o que imagino que foi. O que vocês acham? 
TODOS: Boa idéia. 
MC: Been, qual o nome do dono deste restaurante? 
SB: Luiz Otávio. 
MC: Muito bem, vamos lá. Como eu disse no início do nosso 
almoço, o primeiro passo é “idealizar” o projeto, estruturando as 
idéias e analisando sua viabilidade. O Luiz Otávio idealizou o 
restaurante, montou o projeto analisando as oportunidades e 
ameaças, bem como sua viabilidade. 
SB: Pelo jeito, o projeto do restaurante foi considerado viável, 
caso contrário não estaríamos aqui. 
MC: Isso mesmo. 
PR: Próximo passo. 
 
1º – Plano Organizacional 
MC: O próximo passo é a Elaboração do Plano Organizacional. 
DS: Com esse nome, mais parece um plano para montar uma 
empresa! 
MC: É mais ou menos isto. Na realidade, o “Plano Organizacional” 
define a estrutura de organização, gestão e a equipe executora 
do projeto. No caso da montagem do restaurante, o Luiz Otávio 
teve que contar com uma equipe de engenheiro, arquiteto, 
marceneiro, eletricista, mestre de obra, dentre outros. 
DS: A julgar pelo ambiente, ele também contou com uma 
decoradora no seu Plano Organizacional. 
PR: É só isso o Plano Organizacional? Você relaciona as pessoas 
das quais você precisa para executar seu projeto? 
MC: Quando iniciamos o projeto, já apresentamos, no nosso 
Termo de Abertura, quais profissionais de que necessitamos; e, 
quando elaboramos o Plano, já colocamos os nomes das 
59 
 
pessoas ou empresas que irão executar o projeto bem como a 
relação de hierarquia entre elas. 
DS: Mas é só isso? 
MC: No caso do restaurante sim, pois é uma empresa nova. 
Podemos dizer que é o primeiro projeto dessa empresa. 
 
1.1 – Equipe de Projeto 
 
SB: Mas, no caso da empresa, fazemos da mesma forma? 
MC: No caso da nossa empresa, temos mais alguns detalhes. 
SB: Fico só com o restaurante, falou!? 
DS: Não vou complicar. Segundo o Guia PMBOK®, planejar 
recursos humanos significa determinar funções, 
responsabilidades e relações hierárquicas do projeto, tanto em 
relação às pessoas quanto aos grupos internos ou externos à 
organização executora do projeto. Significa, ainda, incluir 
informações de como e quando os membros da equipe do projetoserão contratados ou mobilizados, critérios para sua liberação do 
projeto, identificação das necessidades de treinamento e 
identificação das necessidades de mudança na Organização 
relativas à implantação do projeto. 
PR: Não é tão 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 coerência com os objetivos estratégicos da empresa. 
DS: Maria, voltando à apresentação do Sr. PMI, um projeto é 
quase sempre multifuncional. Isso significa que, ao elaborarmos 
um Plano Organizacional, teremos pessoas de várias áreas e até 
equipe externa, caso não tenhamos profissional dentro da 
empresa? 
60 
 
 
1.2 – Capacitação 
MC: Isso mesmo, Delma. E, em alguns casos, para execução do 
projeto, “profissionais da casa” precisam de treinamentos mais 
específicos para a execução de algumas tarefas. 
PR: Mas, se precisam de treinamento, não é mais fácil 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 contratação temporária. 
PR: Não pensei por esse lado. 
MC: Assim, quando a empresa identifica as necessidades de 
capacitação da equipe, ela elabora um plano de treinamento. 
SB: E essa idéia de mudança, o que significa isso? 
 
61 
 
1.3 – Gestão da Mudança 
 
MC: Muitos projetos impactam diretamente no processo de uma 
empresa. Por exemplo, a implantação de um software de gestão, 
tipo ERP. 
SB: Muitas pessoas perdem o emprego. 
DS: Claro que não. 
PR: Maria, agora ficou mais clara sua explicação anterior. 
 
PR: Quando implantamos o ERP na empresa, fui convidado a 
participar da equipe de implantação por causa dos meus 
conhecimentos em finanças, mesmo não trabalhando diretamente 
no financeiro ou na contabilidade. 
SB: Eu me lembro disso. O software de ERP foi um projeto? 
MC: Foi. E um projeto muito bem planejado. Você lembrou bem, 
Rocha. A equipe montada para o projeto ERP tinha o 
conhecimento de que a empresa precisava, mas não dominava o 
software. Nesse caso, houve o treinamento específico. Além 
disso, foi estruturado um plano de mudanças. 
DS: Esse plano constava de toda a parte de informação sobre o 
andamento do projeto e os impactos que ele tinha em cada área. 
Foram apresentados todos os benefícios e a readequação de 
62 
 
todo o quadro de pessoal. Foram observados os tempos de 
transição e conclusão de cada etapa, sem prejudicar o 
andamento dos trabalhos e sem “rádio peão” entre os corredores. 
PR: Este foi um projeto de sucesso. Olha que eu não considerava 
que já tinha participado de um projeto e que fui útil. 
DS: Viu como as peças se encaixam quando temos os conceitos 
certos? 
MC: Isto mesmo. Se você quiser aprofundar seus conhecimentos, 
sugiro, ainda, a leitura do texto Gestão das Transições. 
Vou desenhar para vocês um modelo de Plano Organizacional. 
 
63 
 
2º – Planejamento de Escopo 
 
SB: Muito bom. Fizemos o Plano Organizacional. Qual o próximo 
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 
especificações e funções. 
SB: Mas já não fizemos isso antes? 
MC: No processo de iniciação, apresentamos um escopo 
preliminar. Esse escopo serve de base para futuras decisões do 
projeto, incluindo os critérios que avaliarão se o projeto, ou fase 
dele, foi contemplado com sucesso. 
DS: Podemos dizer, então, que agora, com o planejamento do 
escopo, determinaremos os limites do trabalho no projeto? 
MC: Isto mesmo. A esses limites, chamamos de entrega. As 
entregas são definidas no início do projeto e aceitas/aprovadas 
no final do projeto. Tornam-se marcos quando possuem uma 
característica de decisão importante. 
PR: Não entendi bem. Explique melhor. 
MC: O objetivo fundamental deste planejamento deve ser o de 
prover uma orientação 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 são: 
1 Roteiro de preparação de uma declaração detalhada do escopo 
de projeto, bem como o tratamento de suas mudanças; 
2 Procedimentos para a construção da estrutura analítica de 
projeto (EAP) com as respectivas regras para sua aprovação e 
manutenção ao longo do empreendimento; 
3 Regras sobre a aceitação formal dos entregáveis, em um 
formulário-padrão, por exemplo. 
 
PR: O que é estrutura analítica? Para que serve? 
SB: Temos formulário-padrão? 
MC: Calma. Vou responder uma questão de cada vez. Formulário-
padrão é o que chamamos de termo de abertura. Ele consta da 
nossa metodologia. Cada empresa adota um nome. Pode ser 
Project Charter ou Análise Crítica da Demanda. Lembram-se do 
que eu disse sobre termo de abertura? (O desenvolvimento do 
termo de abertura do projeto trata da documentação das 
64 
 
necessidades de negócios, da justificativa do projeto, do 
entendimento atual das necessidades do cliente e do novo 
produto, serviço ou resultado que deve satisfazer esses requisitos 
– tratar como pensamento dos participantes). Então, trata-se de 
um documento essencial para o projeto e para o planejamento do 
escopo, em particular nos estágios iniciais do empreendimento, 
pois consolida informações-chave para suporte à decisão sob 
níveis mais elevados de incerteza que caracterizam o início dos 
projetos. 
DS: Como a Maria já disse, ele é a formalização do projeto. 
MC: Isto mesmo. Continuando. Estrutura Analítica do Projeto 
(EAP) é a expressão em português para WBS (Work Breakdown 
Structure). Segundo o Guia PMBOK®, ela representa uma 
“decomposição hierárquica orientada à entrega do trabalho a ser 
executada pela equipe do projeto para atingir os objetivos do 
projeto e criar as entregas necessárias”. 
SB: E daí? 
MC: EAP pode ser definido como: 
“um agrupamento de elementos do projeto, orientados a 
produtos, que organiza e define o escopo total do trabalho”; 
1 uma representação gráfica da hierarquia do projeto; 
2 identificação de todo o trabalho a ser executado: trabalho que 
não está no WBS não faz parte do Escopo do Projeto; 
3 a base a partir da qual o projeto é construído; 
4 reflexão das pessoas sobre todos os aspectos do projeto. 
Além disso, uma EAP construída pode ser reutilizada em outros 
projetos. 
 
DS: Isto é muito bom. Só não podemos esquecer que todos os 
processos precisam ser documentados e registrados. Só assim 
poderemos aprender com os acertos e com os erros também. 
PR: Quais os benefícios desta EAP? 
MC: São vários. Vou citar quais são: 
1 Ajuda a prevenir que o trabalho se perca nos detalhes; 
2 Dá à equipe do projeto uma compreensão 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 comunicações e cooperação entre os membros da 
equipe e demais stakeholders; 
65 
 
4 Ajuda a prevenir mudanças; 
5 Focaliza a experiência da equipe naquilo que precisa ser feito, 
implicando um projeto de maior qualidade; 
6 Promove uma base para dimensionamento da equipe, 
orçamento 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 papéis. 
 
SB: Tudo isto!? 
MC: E melhor, Been, ele é visual. Parece um organograma. 
SB: Agora você falou minha língua. 
MC: Como parece com um organograma, a EAP possui níveis. 
Assim temos: 
1 Primeiro nível: o projeto; 
2 Segundo / terceiro níveis: estratégia de execução; 
3 Último nível: tarefas do trabalho 
– Atividades para elaboração de produtos do projeto (“entregas”); 
– Possui um responsável pela execução;– Pode possuir limitações de prazo e custo; 
– A partir do último nível são criadas as tarefas do cronograma. 
Após definida EAP, é importante que todos os pacotes de 
trabalho sejam estratificados em suas atividades, ou tarefas, que 
podem ser chamados também de nível de esforço. 
 
MODELO DE UMA EAP 
 
66 
 
Cronograma de Execução 
 
MC: O nosso próximo passo é estabelecer o cronograma de 
execução do projeto. Já definimos o Plano Organizacional e a 
seqüência das atividades; agora é hora de juntar as partes e 
elaborar o cronograma do projeto. 
DS: Determinar a programação de um projeto não é uma 
atividade simples? 
MC: Na verdade, não. Elaborar um cronograma requer uma 
combinação de arte e ciência. 
DS: Eu entendo que o principal objetivo desse cronograma é 
garantir que o projeto seja concluído dentro do prazo 
determinado. 
MC: É o nosso desafio. Sabemos que o tempo não pára. O 
cronograma do projeto é sempre uma restrição, até mesmo 
quando a data de término não é crítica. Se um projeto atrasa, na 
67 
 
maioria das vezes ele irá consumir um capital que ele não tinha 
previsto, comprometendo, também, o seu custo, podendo até 
mesmo causar sérias conseqüências mercadológicas para o 
produto, ou serviço, do projeto. 
SB: Lembro-me de o meu amigo Luiz Otávio dizer que ele 
estabeleceu prazo para execução da obra do restaurante de 
acordo com o projeto arquitetônico, sem estabelecer nenhuma 
folga. No entanto, ao iniciar as obras, ele viu que o prazo não era 
suficiente e, para não comprometer todo o cronograma, acabou 
contratando mais pessoas. Com isso gastou mais dinheiro. 
PR: Este foi um bom exemplo. Maria, como estabelecer um 
cronograma? 
MC: Lembra-se de que eu acabei de falar da estratificação das 
atividades? 
PR: Lembro. Mas o que são atividades? 
MC: Bem. Atividades são etapas necessárias para se contemplar 
um projeto. São executadas em uma seqüência caracterizada 
pela natureza do projeto. As atividades podem ocorrer 
seqüencialmente, ou simultaneamente. 
PR: Está bem e daí? Continuo sem entender! 
MC: O projeto vai sendo decomposto até que todas as etapas e 
entregas sejam atingidas. Os principais tipos de atividades são: 
1 – Atividades Executivas, que são aquelas relacionadas 
diretamente com a ação dentro do projeto. Exemplo: embalar 
computadores; limpar o terreno; digitar o relatório de compras; 
2 – Marcos, que representam um evento, ou condição, que 
determina a execução de um grupo de atividades relacionadas 
entre si, ou o término de uma fase de projeto. 
Servem também para identificar as entregas dos pacotes de 
trabalho e não possuem duração. São também chamados de 
etapa. Como exemplo de marcos, temos: telhado pronto 
(entrega); testes do produto realizados; recebimento da 3ª 
parcela. 
O terceiro e último tipo são as Atividades-Resumo. São 
atividades que englobam outras atividades, denominadas 
68 
 
subatividades. Elas representam um conjunto de atividades, 
totalizando duração, datas e custos das atividades a elas 
pertencentes. 
PR: Mas como se desenvolve o cronograma? 
MC: O desenvolvimento do cronograma deve ser feito 
iterativamente, ou seja, ser elaborado de forma progressiva e 
repetida até o momento em que seus resultados sejam confiáveis 
e possam atender aos objetivos do projeto. 
Assim, neste desenvolvimento, estabelecemos as datas de início 
e término das atividades. Esse processo é um dos mais 
importantes de toda a fase de planejamento, uma vez que 
consolida informações de outras áreas, tais como custo, recursos 
humanos e escopo. O nivelamento de recursos é uma das 
ferramentas utilizadas. 
DS: Mas como estimar a duração das atividades? 
MC: Segundo o Guia PMBOK®, estimar a duração das atividades 
“é obter avaliações quantitativas do número provável de períodos 
de trabalho necessários para a conclusão de uma atividade do 
cronograma”. 
Para elaboração de um cronograma, é necessário o 
desdobramento das atividades, como acabamos de falar na 
explicação da EAP. Uma das questões mais ignoradas na 
elaboração do cronograma é relativa àquelas datas que estão 
“amarradas” a determinadas situações. Por exemplo, para o Luiz 
Otávio mobiliar o restaurante, ele precisou aguardar a conclusão 
da obra. Ele simplesmente não pode colocar os móveis sem que 
antes tudo estivesse pronto. 
Outras considerações incluem saber quais os recursos serão 
utilizados, sua disponibilidade (calendários) e experiências 
vivenciadas em outros projetos similares. 
SB: Como estabelecemos a duração das atividades? 
MC: Boa pergunta. A duração de uma atividade é o tempo 
necessário para que a atividade possa ser realizada. Esse tempo 
pode ser estipulado em semanas, dias, horas e minutos, 
dependendo do tamanho de cada projeto. 
69 
 
Essa etapa tem por objetivo calcular ou determinar, corretamente, 
a quantidade de tempo necessária para executar cada atividade 
para que, ao ser integrante de um cronograma, possa determinar 
a duração do projeto. Ela é conduzida em paralelo à alocação de 
recursos nas atividades, uma vez que existe uma dependência 
intrínseca entre duração e quantidade de recursos. 
DS: Por que as estimativas variam tanto? 
MC: Porque desconhecemos quais fatores influenciarão a 
duração. Então não é possível saber exatamente quanto tempo 
será consumido. 
Outro fato importante é que muitas vezes, ao elaborarmos um 
cronograma, não envolvemos quem irá executar a tarefa. 
DS: Você está dizendo que quem deverá preparar as estimativas 
são as pessoas que executam as atividades? 
MC: Exatamente. Quem sabe o tempo é quem faz. 
PR: Realmente é uma etapa bem difícil. 
MC: Apesar de ser “difícil”, o envolvimento da equipe do projeto 
desde a concepção é fundamental para o sucesso. 
PR: Você falou que os prazos das atividades estão “amarrados”. 
Explique um pouco melhor. 
MC: Está certo. Acho que empolguei um pouco e acabei pulando 
uma explicação fundamental nesta fase. 
Quando disse que as atividades estão inter-relacionadas, estava 
tentando explicar que temos de estabelecer precedentes para 
que atividades interdependentes sejam identificadas e o 
cronograma do projeto seja determinado. 
DS: Maria, li alguma coisa sobre isso. Veja se entendi 
corretamente: Uma atividade que comece ou finalize antes que 
outra atividade possa começar é chamada predecessora. Uma 
atividade que dependa do início ou do final de outra atividade é 
chamada de sucessora. 
MC: Isto mesmo. 
SB: E como definimos esta “relação de amor é ódio”? 
70 
 
DS: Amor e ódio é por sua conta. 
RISOS 
MC: É necessário estabelecermos alguns parâmetros 
importantes. São eles: 
 Data de início do projeto: é o primeiro dia da primeira 
atividade a ser desenvolvida. Normalmente essa data é definida 
quando apresentamos a proposta do projeto, ou seja, juntamente 
com o objetivo do projeto. 
 Data de término do Projeto – é o último dia da última atividade 
a ser desenvolvida. Normalmente é calculada pelo detalhamento do 
plano do projeto. 
 Início da atividade – é a data e a hora em que a atividade se 
inicia. Pode ser um dado fixo do projeto ou calculada em 
conseqüência de suas atividades predecessoras. 
 Término da Atividade – é a data e a hora em que atividade 
termina. Normalmente, é calculada a partir da data de início da 
atividade e de sua duração. 
 Calendários – os calendários são utilizados para determinar e 
selecionar os dias de trabalho, ou folga, do projeto. Os calendários 
também devem ser utilizados para indicar horas específicas de 
trabalho para um determinado recurso. 
 Feriados e Dias Especiais – Devem ser sempre inseridos para 
que não ocorram erros no gerenciamento das atividades. Por 
exemplo, férias coletivas, feriados municipais, véspera de Natal e 
Ano Novo, dentre outros. 
DS: E férias dos participantes dos projetos? 
MC: Boa lembrança. Um projeto pode ter datas especiais para 
diferentes participantes do projeto, de acordo com cronograma de 
férias de cada um. 
SB: Existe alguma forma visual demontar um cronograma, ou 
basta detalhar no papel? 
MC: Você pode apenas detalhar no papel, no entanto, temos hoje 
o que chamamos de diagrama de Gantt. 
SB: Muito prazer, Sr. Gantt, eu sou o Sr. Been. 
71 
 
MC: Não brinque! Diagrama de Gantt, ou diagrama de barras, é 
hoje a forma mais utilizada para representação gráfica de um 
cronograma. 
O diagrama utiliza barras horizontais, colocadas dentro de uma 
escala de tempo. O comprimento relativo das barras determina a 
duração da atividade. As linhas conectando as barras individuais 
em um diagrama de Gantt refletem as relações entre as 
atividades. 
DS: O Diagrama de Gantt já foi desenvolvido em software? 
MC: Sim. O Diagrama de Gantt é a visualização-padrão da 
maioria dos softwares de gerenciamento de projetos. 
PR: O software facilita a elaboração do cronograma! 
MC: Facilita não, ajuda e muito. Mas temos de lembrar que temos 
uma metodologia, e é ela quem facilita o nosso trabalho. O 
software é apenas uma ferramenta que nos auxilia na construção 
do cronograma. 
 
Orçamento de Custos 
SB: E agora, o que fazemos? 
MC: O próximo passo é saber quanto custa o nosso projeto. 
PR: Mas isto eu já sei. Fizemos o estudo de viabilidade ou 
orçamento inicial. 
MC: Vamos voltar ao exemplo deste restaurante. O Luiz Otávio 
elaborou o projeto e fez o estudo de viabilidade. Os valores 
projetados foram transportados para o plano orçamento do 
projeto. 
PR: O que fazemos agora então é detalhar os valores iniciais, de 
acordo com as necessidades de gasto do projeto? 
MC: Segundo Ricardo Vargas, a orçamentação do projeto é o 
processo que envolve a alocação das estimativas de custos a 
cada item de trabalho, de modo a estabelecer uma linha de base 
de custos para medir a performance do projeto. Nesse processo, 
o fluxo de caixa do projeto é determinado. 
DS: Trocando em miúdos, fizemos uma estimativa inicial de 
quanto seria o nosso projeto. Agora iremos detalhar os valores 
agregando-os por rubrica e o cronograma de desembolso? 
MC: Isso mesmo. 
SB: Já falei que números não são a “minha praia”. Vocês podem 
me explicar em bom português? 
72 
 
MC: Desculpe, Been. Vou explicar melhor. Rubricas são contas, 
ou grupo de contas. 
Desta forma, ao elaborarmos o orçamento do projeto, iremos 
detalhá-lo da seguinte forma: 
• Salários, Adicionais e Encargos e Benefícios. 
• Infraestrutura 
• Materiais de Consumo 
• Despesas de Viagens 
• Serviços 3º – Pessoa Jurídica 
• Comunicação e Marketing 
• Serviços 3º – Pessoa Física 
• Bolsistas e Estagiários 
• Despesas Financeiras 
• Impostos, Taxas e Contribuições 
• Despesas Operacionais 
• Investimentos 
SB: O que estão 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 execução. Cada etapa tem um 
valor a ser gasto, desta forma temos: 
1) Reforma do Espaço 
Execução de projeto arquitetônico 
Contratação de projetos complementares juntamente com a obra 
Fiscalização da Obra 
Recebimento da Obra 
2) Compra de equipamentos 
Não vou entrar no detalhe, pois não conheço o projeto, apenas 
listei alguns itens que poderiam compor o escopo do projeto. 
Portanto: 
Para reforma do Espaço, existe a necessidade de contratação do 
arquiteto (lembramse, está no plano organizacional e faz parte da 
equipe). Ele irá calcular o valor do projeto arquitetônico da 
seguinte forma: 
Contratação de serviços de terceiros: 
Obs.: ele pode pagar por hora trabalhada ou pelo valor do projeto 
fechado. Neste caso, irei apresentar o cálculo por hora: 
73 
 
Been, você sabe quanto tempo durou a obra deste restaurante? 
SB: Aproximadamente uns quatro meses, entre o início das obras 
e a inauguração. 
MC: OK. Então, como exemplo: 
Premissas da contratação: 
Tempo: 3 meses, 4h/dia, 3 dias/semana 
Valor da hora: R$ 120,00 (já incluídos os valores com encargos e 
tributos, pois é contratação de terceiros) 
Total a ser pago: 
R$ 120,00 x 4 x 3 x 4,5 x 3 = R$ 19.440,00 
Para compra de equipamentos, temos: 
Investimentos (bens duráveis) 
 
Até o momento, o valor do orçamento do Luiz Otávio é: 
SERVIÇOS DE 3º - PJ = R$ 19.440,00 
INVESTIMENTOS = R$ 8.630,00 
DS: Boa parte dos nossos projetos envolve viagens, dessa forma, 
ao elaborarmos o nosso orçamento, podemos considerar: 
passagens, hospedagem, alimentação e locomoção. 
MC: Isso mesmo. 
PR: Deixe-me calcular no papel para ver se eu entendi. 
Premissas: 
74 
 
Duração da viagem: 3 dias 
Passagem: R$ 800,00 (ida e volta) 
Locomoção: R$ 80,00/dia 
Alimentação: R$ 80,00/dia 
Hospedagem: R$ 150,00/diária 
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 orçamento 
deverão ser coerentes com os objetivos do projeto. Lembrem-se 
também dos custos indiretos, que muitas vezes são valores 
econômicos, como, por exemplo, o custo de um telefonema, as 
horas da equipe administrativa. 
DS: Maria, você já falou, mas não custa reforçar. Muitos dos 
estouros dos orçamentos dos projetos estão 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 
memória de cálculo; 
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 não sendo recuperados, porque têm interesse em atingir 
uma meta de longo prazo para a organização; e 
4 a forma de identificar o nível de recursos necessários, quando 
eles estarão disponíveis e quem são os seus responsáveis, é vital 
para todo o processo de estimativas de custos e orçamentação. 
 
DS: Mas, Maria, são muitas informações. Confesso que já estou 
ficando preocupada se daremos conta de elaborar tudo isto e 
também de acompanhar. 
PR: Puxa, achei que o medo era só meu. 
MC: A principio, tudo parece difícil. Eu acabei de comentar sobre a 
gestão da mudança. E é isto que estamos fazendo, uma 
mudança no nosso processo. E a nossa empresa está 
trabalhando a gestão da mudança. 
PR: Está certa, Maria. Só agora estou me dando conta disso. Na 
implantação do ERP foi assim e agora, com o Gerenciamento de 
75 
 
Projetos, também está sendo. Ainda bem que temos você, assim 
a transição fica mais fácil. 
DS: Concordo com você. 
SB: Quando será que este novo processo vai me interessar? 
MC: Acho que, a partir de agora, você vai poder contribuir muito, 
Been. 
 
Plano da Qualidade 
SB: Oba! O que vem agora? 
MC: Qualidade do Projeto! 
SB: Esse assunto me interessa. 
MC: Não adianta estabelecermos metas se não acompanharmos. 
O próximo passo no planejamento de um projeto é o plano de 
qualidade. 
SB: Significa que iremos trabalhar com indicadores? 
MC: Exatamente. O Planejamento da Qualidade do projeto 
caracteriza-se pela definição dos indicadores que deverão ser 
monitorados, a freqüência e a forma de medição. 
SB: O Plano de Qualidade trabalha, então, com Gestão à Vista, 
Gráfico de Desempenho? 
DS: Puxa, até que enfim alguma coisa lhe chamou a atenção! 
SB: Sou muito visual. Números, números e mais números 
embaralham a minha vista. Gosto de ver cores. 
PR: O conceito de qualidade total é o mesmo para qualidade em 
projetos? 
MC: O objetivo é o mesmo. O mais importante dessa área é 
garantir que o projeto será concluído dentro da qualidade 
desejada, com a satisfação das necessidades de todos os 
envolvidos. 
SB: Acho que posso contribuir. 
MC: Vamos lá. 
SB: A qualidade envolve inúmeras dimensões. Mas acredito que 
duas são fundamentais para o Gerenciamento de Projetos: 
• Fazer correto desde o início. Neste caso o planejamento inicial e 
fundamental. O gerenciamento da qualidade garante que cada 
ação seja desenvolvida corretamente na primeira vez. O 
processo de correção é váriasvezes mais caro que o processo 
de planejamento. 
• Satisfação do cliente. Aqui existe a necessidade de garantir que 
o produto ou serviço seja transferido para o cliente de maneira 
correta. 
76 
 
MC: Obrigada pelas informações. É muito importante o 
envolvimento de todos no processo de gerenciamento de 
projetos. É como venho dizendo o tempo todo: cada um tem uma 
“qualidade” que pode contribuir para todo o processo. 
DS: Existem indicadores fixos? 
MC: Sim. Existem dois tipos de indicadores: 
1 Básicos: normalmente estabelecidos na Metodologia de 
Gerenciamento de Projetos para custo, prazo, esforço. 
2 Específicos: definidos pelo gerente/coordenador e dirigidos aos 
produtos, considerando suas características técnicas. 
 
SB: Podemos dizer que o Plano de gerenciamento da qualidade 
descreve como a equipe de gerenciamento de projetos 
implementará a política de qualidade da organização 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 genérico, dependendo dos requisitos do 
projeto. 
 
MC: Isto mesmo. Estou gostando de ver seu interesse. 
PR e DS: Nós também. 
 
Plano de Comunicação 
SB: Alguém quer sobremesa? 
MC: Eu quero. Adoro doce. 
DS: Saiu no jornal uma reportagem sobre as delícias das 
sobremesas ligths elaboradas por este restaurante. Eu também 
quero conhecer. 
MC: Já que estamos falando de reportagem, vamos falar um 
pouco de comunicação? 
SB: Comunicação em projetos? 
MC: Gerenciamento das comunicações. Nossa próxima etapa. 
DS: Há uma frase de David I. Cleland, que diz: “A grande maioria 
dos atritos, frustrações e ineficiências em nossas relações com 
as outras pessoas é causada pela pobreza nas comunicações” 
MC: Segundo o Guia PMBOK®, o gerenciamento das 
comunicações subdivide em quatro processos: o Planejamento 
das Comunicações, a Distribuição de Informações, os Relatórios 
de Desempenho ou Performance e o Gerenciamento das Partes 
Interessadas. 
77 
 
Ainda, segundo o Guia, “o Planejamento da Comunicação é o 
processo onde será determinada a necessidade de informações 
de cada parte interessada do projeto, bem como o modo como 
essa informação será levada ao mesmo e qual o seu nível do 
detalhe”. 
SB: Posso dizer, então, que o Plano de Comunicação estabelece 
os meios e instrumentos para a comunicação de dados e 
informações do projeto, de acordo com as necessidades dos 
stakeholders. 
DS: E quais seriam esses meios e instrumentos? 
MC: Os meios podem ser mediante correspondências (e-mails, 
cartas, fax), mídia impressa (encartes, releases, notas e matérias 
jornalísticas), mídia eletrônica (intranet, sistema de informação) e 
os seguintes relatórios (Progresso, Desempenho, Executivo, 
Divulgação e gráficos de gestão a vista). E através de eventos. 
Os eventos de comunicação são as reuniões realizadas entre os 
envolvidos, como por exemplo: “Kick-off”; Acompanhamento de 
progresso; Reunião de encerramento. 
PR: Quais os propósitos de um plano de comunicação? 
MC: O desenvolvimento de um plano de comunicação eficaz deve 
ter em mente atingir os seguintes propósitos: 
1 Assegurar que as informações 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 empolgação com o projeto; 
4 Facilitar a tomada de decisão e o controle de mudanças; 
5 Oferecer um processo específico para feedback e resolução de 
conflitos; 
6 Melhorar e facilitar o trabalho em equipe, a cooperação e 
colaboração. 
 
DS: Maria, você poderia explicar um pouco mais sobre os eventos 
e também quais aspectos temos que observar ao elaborarmos 
um plano de comunicação? 
MC: Os Planos de Comunicação podem variar de acordo com a 
complexidade, tamanho e duração do projeto, mas, de qualquer 
forma, é preciso observar os seguintes aspectos: 
1 Propósito: os objetivos da comunicação do projeto, sendo esse 
propósito formal ou informal; 
78 
 
2 Métodos: os mecanismos e formatos da comunicação no 
projeto; 
3 Freqüência: o momento (data e evento) e a freqüência das 
atividades formais de comunicação. 
Sobre os eventos, posso dizer: 
o Reunião de Partida (kick-off meeting): essa reunião formaliza 
e dá início de fato ao projeto, justificando-se pelos seguintes 
motivos: impõe o planejamento no início do ciclo de vida do projeto, 
ajuda na formação de consenso, estimula engajamento e integração 
da equipe e, principalmente, ajuda a quebrar a inércia que sempre 
ocorre no começo do projeto. 
o Reunião de Acompanhamento: essa reunião é usada para 
acompanhar e verificar o andamento do mesmo, e ocorre 
periodicamente com a freqüência combinada, acontecendo também 
reuniões de emergência, sempre que um fato ou acontecimento 
assim o justificar. 
o Reunião de Encerramento ou de Entrega do Projeto: essa 
reunião caracteriza e formaliza o fim do projeto bem como todo o 
envolvimento do gerente e sua equipe com o mesmo; assim, ao seu 
final, o projeto é considerado entregue e funcionando a contento. 
Esses eventos variam de empresa para empresa de acordo com 
a metodologia utilizada. 
DS: Então existem outros eventos? 
MC: Sim. Podemos ter reuniões periódicas com os stakeholders, 
Reuniões de Avaliação de Desempenho e outros eventos que a 
empresa julgar necessários para execução de seu projeto. 
DS: Maria, você poderia desenhar para nós um modelo de 
Planejamento de Comunicação. 
MC: Claro. Aqui está. 
 
79 
 
MC: Primeiro devemos informar o nosso público-alvo, ou seja, 
qual stakeholder. Vocês se lembram quais são? 
SB: Eu acho que lembro. Eles são: 
- o Sponsor; 
- o Gerente de Projeto; 
- os clientes; 
- a Organização “executora”; 
- a equipe do projeto; 
- os Fornecedores; 
- e os usuários finais. 
MC: Isto mesmo Been. Devemos planejar as informações sobre o 
projeto para cada parte interessada. O próximo item é definir qual 
evento, conforme falei há pouco. 
DS: Pelo que eu estou vendo, se possível, devemos colocar o 
nome dos participantes. 
MC: Exatamente. E por fim colocar de quanto em quanto tempo 
irá ocorrer ou quando irá ocorrer. É um modelo simples, no 
entanto, é muito importante. E mais uma coisa, para cada 
metodologia adotada, este modelo muda, dependendo, inclusive, 
do tamanho do projeto. 
 
Plano de Suprimentos ou Plano de Aquisições 
SB: Agora podemos comer nossa sobremesa? 
MC: Podemos. 
Risos 
PR: Estou sentindo falta de mais uma etapa. 
SB: O que, Rocha? 
PR: Eu não sei se entendi direito ou se realmente está faltando. 
Ao elaborarmos o cronograma de execução, também devemos 
elaborar o plano de compras? 
MC: No cronograma de execução, nós inserimos o que e quando 
precisamos de um determinado recurso, mas existe também a 
necessidade de um Plano de Suprimentos. 
DS: O que seria esse Plano? 
MC: Este plano contempla a aquisição de equipamentos, materiais 
e serviços; considera o estoque, as necessidades do projeto, 
fornecedores bem como qualidade de produto. E, principalmente, 
define os “lead time” para aquisição dos serviços e 
equipamentos. 
SB: Define o quê? 
80 
 
MC: Ao pé da letra “levar tempo”, ou seja, o tempo necessário 
para aquisição de produtos e serviços. Dessa forma, não 
corremos o risco de precisar de algo que não foi comprado ou 
contratado. 
DS: Significa que um plano de aquisições mal elaborado pode 
atrasar o nosso cronograma? 
MC: Sem dúvidas. Eu disse mais cedo que temos convênios com 
o Governo e, por isso, estamos sujeitos à Lei de Licitações 8.666. 
O Plano de Suprimentos tem que considerar esse aspecto. 
Segundo o Guia PMBOK®, o gerenciamento das aquisições em 
um projeto implica a necessidade de condução de processos de 
planejamento (planejar compras e aquisições, bem como planejar 
contratações), processos de execução (solicitar respostas de 
fornecedores e selecionar fornecedores), processo de 
monitoramento e controle (administração de contrato) e processo 
de conclusão (encerramentode contrato). 
SB: Puxa tudo isto? 
MC: Tudo isto! Iremos conversar um pouco mais sobre Plano de 
Aquisições quando estiver explicando sobre execução e controle 
de projetos. Acredito que os exemplos ficarão mais claros. 
SB: Puxa, adorei “adquirir” esta sobremesa. Sem dúvidas, ela 
está completando o meu “projeto alimentar” de hoje. 
 
Plano de Resposta aos Riscos 
 
DS: Maria, acho que você já falou de todos os Planos! 
MC: Ainda não, falta falarmos sobre o Plano de Resposta aos 
Riscos. 
PR: Você já falou alguma coisa sobre riscos, que eles podem ser 
internos ou externos, mas não me lembro de termos relacionado 
nenhum. 
MC: Na verdade não relacionei. Ainda não encontrei bons 
exemplos para que eu possa relacionar. Vamos continuar 
conversando. No momento certo, eu voltarei com este assunto. 
PR: OK. 
 
Execução e Controle 
81 
 
 
No Restaurante 
 
DS: Maria, como eu acabei de dizer, elaboramos todos os planos. 
Agora, como executamos e controlamos tudo o que planejamos? 
PR: Boa pergunta! Tenho várias dúvidas de como colocamos em 
prática tudo que planejamos. 
MC: Vamos com calma. Explicarei os processos de 
acompanhamento e controle. 
SB: Estou começando a gostar deste assunto. 
MC: Apenas como introdução da nossa conversa, gostaria de 
ressaltar que o planejamento bem como a execução e controle 
são processos interdependentes e essenciais para o sucesso do 
projeto. 
PR: Você quer dizer que, com a elaboração dos planos, temos o 
norte a seguir; e que a execução e controle nos indicam se 
estamos trabalhando ou não corretamente? 
MC: Além de nos indicar se estamos no caminho certo, essas 
estratégias nos permitem detectar os desvios e propor a 
implantação de medidas corretivas. 
82 
 
 
 
1º: O que controlar e acompanhar 
 
SB: Já entendi que esta fase é muito importante para o sucesso 
do projeto, mas como estão relacionados? 
MC: Been, segundo o Guia PMBOK®, o monitoramento contínuo 
permite que a equipe de gerenciamento de projetos tenha uma 
visão clara da saúde do projeto e identifica as áreas que exigem 
atenção especial. Ainda segundo o Guia, o processo Monitorar e 
controlar o trabalho do projeto está relacionado: 
• à comparação do desempenho real do projeto com o plano de 
gerenciamento do projeto; 
• à avaliação do desempenho para determinar se são indicadas 
ações preventivas ou corretivas e recomendar essas ações 
conforme necessário; 
• à análise, 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; 
• à manutenção de uma base de informações precisas e corretas 
relativas ao produto do projeto e a sua documentação associada 
até o término do projeto; 
• ao fornecimento de informações para dar suporte a relatórios de 
andamento, medições de progresso e previsões; 
• ao fornecimento de previsões para atualizar o custo atual e as 
informações sobre o cronograma atual; 
• ao monitoramento da implementação de mudanças aprovadas 
quando e conforme ocorrem. 
PR: Maria, não entendi muito bem, você poderia explicar melhor? 
MC: Vocês se lembram da apresentação do Sr. PMI? 
SB: Sobre a evolução do Gerenciamento de Projetos? 
MC: Isso mesmo, Been. 
SB: Se eu me lembro bem, o Sr. PMI disse que inicialmente os 
projetos eram gerenciados apenas nos quesitos Tempo, Prazo e 
Custos. Em seguida, percebeu-se a importância de acompanhar 
também o que seria executado, ou seja, qual o escopo do projeto. 
E atualmente temos que gerenciar pessoas, compras, riscos, 
comunicar, entregar com qualidade e, principalmente, precisamos 
ter tudo isso integrado. 
83 
 
MC: Puxa Been, você explicou muito bem. Vejo que o assunto 
está lhe interessando! 
DS: Acredito que quanto mais integrado nós estivermos, mais fácil 
será a implantação 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 
- Informações das ações 
- Riscos 
- Planos de Ação 
 Realizar: 
- Comunicação 
- Gestão de stakeholders. 
- Documentação das ações 
 
DS: Maria, eu entendo que todo esse acompanhamento deve ser 
aprovado e/ou autorizado. Mas como isso ocorre? 
MC: Você fez uma pergunta referente a um assunto que até agora 
eu não tinha comentado. É muito importante que, para cada fase, 
tenha um marco; e que, para cada marco, seja determinada a 
aprovação de uma instância superior. 
PR: Isto em se tratando de uma grande empresa. E aqui no 
restaurante? 
MC: Não só em grandes empresas. Independente do tamanho da 
empresa, todo projeto deverá ser aprovado e autorizado. No caso 
do restaurante, pense no Luiz Otávio como o presidente da 
empresa, desta forma em algumas ações ele aprova e em outras 
ele autoriza. 
PR: Não entendi. Como ele aprova em alguns casos e, em outros, 
autoriza? 
MC: Vou tentar dar um exemplo prático. Todo projeto tem fase de 
iniciação, fase de planejamento, fase de execução e controle e 
fase de encerramento. 
84 
 
No caso do restaurante, o Luiz Otávio, como único dono, aprovou 
todo o projeto e o marco de cada fase. Por se tratar de uma 
pequena empresa, ele também foi o gerente do projeto e, neste 
caso, autorizou as ações de cada fase. 
DS: Refaço a minha pergunta. Como acontece o 
acompanhamento dos projetos? 
MC: Depende da metodologia adotada! 
SB: Lá vem você de novo com metodologia. 
MC: Been, a metodologia nos ajuda muito. Assim, apenas como 
exemplo, podemos dizer que o acompanhamento de um projeto 
pode ocorrer em três etapas: 
 
1ª - Etapa - Acompanhamento de progresso 
Nesta etapa, é realizado o acompanhamento operacional, para 
identificar o andamento da execução das atividades, a 
atualização dos dados de prazo, custo e escopo, a atualização 
dos indicadores, acompanhamento dos planos de ação e de 
respostas aos riscos. 
Esse acompanhamento normalmente ocorre em reunião 
semanal, realizada entre o gerente do projeto e a equipe 
executora. 
Os indicadores acompanhados são os de custo, prazo, esforço e 
específicos, criados no plano de qualidade para cada projeto. 
 
2ª Etapa - Acompanhamento de desempenho 
Nesta etapa, é realizado o acompanhamento tático para verificar 
se a execução está de acordo com o planejado, analisando-se os 
indicadores e se os desvios identificados estão sendo tratados 
com planos adequados. Realiza-se, também, análise crítica da 
utilização da metodologia. 
Esse acompanhamento normalmente ocorre em reunião mensal, 
realizada entre o gerente do projeto e a equipe do escritório de 
projetos. Nessa reunião, são analisados os dados de execução, 
das informações colhidas nas reuniões de acompanhamento de 
progresso e da documentação do projeto. 
DS: Agora estou com dúvidas. O que é escritório de projetos? Não 
estou me lembrando de termos falado sobre ele! 
85 
 
MC: Também não estou me lembrando. Em todo caso, vou 
conceituar. Segundo Ricardo Vargas, Escritório de Projetos, ou 
PMO (Project Management Office) é um local central para 
conduzir, planejar, organizar, controlar e finalizar as atividades do 
projeto. Suas principais funções são: 
• orientar e apoiar a organização no desenvolvimento de seus 
projetos 
• desenvolver e manter atualizada uma metodologia de 
gerenciamento de projetos 
• integrar e coordenar a gestão de projetos 
• fornecer informações estratégicas à Alta Administração, 
Stakeholders, Gerentes de Projetos e organização. 
SB: Temos um escritório de projetos na empresa? 
MC: Está em fase de implantação juntamente com a metodologia. 
Voltando à explicação anterior, a terceira etapa é: 
 
3ª Etapa - Acompanhamento executivo 
Nesta etapa, é realizado o acompanhamento estratégico para 
apresentar os resultados dos projetos. 
Esse acompanhamento normalmente ocorre em reunião mensal, 
realizada entre o escritório de projetos (PMO) e a Alta 
Administração. 
 
 
2º: Ferramentas 
 
PR: Maria,da mesma forma que temos modelos de formulários 
para o planejamento, temos também para o acompanhamento e 
execução do projeto? 
MC: Temos sim, Pedro. De acordo com a metodologia adotada, 
teremos ferramentas específicas. Segundo o Guia PMBOK®, 
ferramenta pode ser entendida como “Alguma coisa tangível, 
como um modelo ou um programa de software, usada na 
realização de uma atividade para produzir um produto ou 
resultado”. 
DS: Quais são as ferramentas mais utilizadas? 
MC: Hoje temos a técnica do valor agregado, o diagrama de causa 
e efeito, diagrama de pareto, a matriz de responsabilidades, além 
das nossas velhas conhecidas planilhas de custos, planilhas de 
acompanhamento físico e financeiro. 
86 
 
PR: Maria, fale um pouco de cada uma, por favor. 
MC: Claro. 
(Conceito extraído do livro Fundamentos do Gerenciamento de Projetos / André 
Birrencourt do Valle, Carlos Alberto Pereira Soares, José Finocchio Jr., Lincoln de Souza 
Firmino da Silva.: Rio de Janeiro: Editora FG, 2007) 
A Técnica do Valor Agregado (TVA), também conhecida como 
análise do valor agregado, é uma ferramenta de gerenciamento 
da integração, do tempo e do custo de projetos que, segundo 
Ricardo Vargas, “tem como foco a relação entre os custos reais 
consumidos e o produto físico obtido no projeto por meio de uma 
quantidade específica de trabalho, ou seja: o que foi obtido pelo 
projeto em relação à quantidade de capital consumido para atingir 
esse resultado”. 
A TVA possibilita uma análise integrada do escopo, prazos e 
custos do projeto, permitindo verificar atrasos ou adiantamentos 
do cronograma, identificar extrapolações do orçamento, medir a 
eficiência do uso do tempo e dos recursos, além de possibilitar 
inferências sobre estimativas de conclusão e custo do projeto. 
Segundo pesquisa efetuada pelo ICPMA (2002), a TVA apresenta 
os seguintes benefícios: 
• proporciona uma clara percepção do status real do projeto; 
• beneficia o controle; 
• possibilita a estimativa de previsões; 
• facilita o processo de tomada de decisões 
gerenciais/capacidade de gerenciar projetos; 
• fornece uma fonte independente de informação/método; 
• melhora a eficiência do projeto; 
• melhora o ambiente; 
• proporciona um aviso prévio em relação aos problemas; 
• possui uma clara aplicabilidade/alinhamento com a companhia; 
• possibilita a otimização do trabalho (por exemplo, horas 
reduzidas, conflitos, etc) 
• possui alta capacidade de receber informações. 
 
Outra ferramenta é o nosso velho conhecido Diagrama de Causa 
e Efeito, também conhecido como diagrama de espinha de peixe. 
É uma representação gráfica utilizada para identificar os fatores 
que contribuem para um resultado ou as causas de um 
determinado problema. As relações de causa e efeito são 
87 
 
descritas por meio de um diagrama parecido com uma espinha 
de peixe, sendo utilizado para analisar as causas que produzem 
efeitos tanto benéficos quanto maléficos. 
O Diagrama de Pareto é a representação gráfica utilizada para 
evidenciar os fatores que contribuem para ressaltar a importância 
relativa entre vários problemas ou de determinadas situações. 
Baseia-se no princípio de Pareto, onde 20% dos fatores 
respondem por 80% dos resultados. 
Apresenta as seguintes contribuições: 
• o diagrama sugere atenção a elementos críticos do processo. 
Passa, assim, a noção de prioridade a determinados aspectos. O 
diagrama ajuda a identificálos; 
• o diagrama permite classificar (em ordem decrescente) os 
elementos do processo segundo a importância da contribuição de 
cada um para o processo inteiro. Permite, também, organizar 
esses elementos em categorias, classes ou grupos; 
• o diagrama investe na visualização global do processo, 
passando a idéia de que essa visão abrangente é fundamental 
para decisões nesse nível, sempre de porte amplo; 
• a ferramenta mostrará onde se devem priorizar as ações de 
melhorias. O diagrama causa e efeito usará como base de ação 
esses dados. 
Contudo deve-se dar especial atenção ao fato de que nem 
sempre os problemas mais freqüentes são os que apresentam 
maiores custos. 
E há a Matriz de Responsabilidades, que é “uma estrutura que 
relaciona o organograma do projeto com a estrutura analítica do 
projeto para ajudar a garantir que cada componente do escopo 
de trabalho do projeto seja atribuído a uma pessoa responsável”. 
É uma ferramenta gerencial que auxilia o processo de 
determinação e visualização das responsabilidades de cada 
membro da equipe do projeto. 
PR: Eu entendo que, no caso dessa matriz, fica clara a 
responsabilidade de cada membro na execução das ações. 
MC: Esta é uma das vantagens da matriz. 
SB: Quais as outras vantagens? 
88 
 
MC: Como disse o Pedro, a matriz possibilita que sejam 
evidenciados de forma clara e concisa a responsabilidade, a 
autoridade e os canais de comunicação. Além disso: 
• ressalta indivíduos e/ou organizações sobrecarregados; 
• aponta deficiências de falta de pessoal habilitado ou disponível; 
• facilita o julgamento sobre a necessidade de remanejamento do 
pessoal; 
• facilita a visualização do relacionamento de cada atividade ou 
fase do projeto com as equipes ou órgãos responsáveis por 
algum tipo de ação no projeto; 
• auxilia na negociação com outras organizações. 
 
PR: Maria, todas essas ferramentas estão informatizadas e em um 
único sistema? 
 
MC: Não necessariamente. Entre as ferramentas informatizadas 
mais simples, temos planilhas eletrônicas e gerenciadores de 
banco dados. 
As planilhas eletrônicas, muitas vezes, são criadas em softwares 
como MS Excel, Word e são utilizadas para o planejamento e 
controle de recursos, para elaboração de orçamentos, para o 
gerenciamento da apropriação de dados, a elaboração de 
gráficos 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 são os softwares MS Project e o Primavera. 
DS: Esses programas são normalmente interativos e possibilitam 
que as informações sejam associadas e transferidas de um para 
outro, automatizando parte do processo de gerenciamento. 
MC: Isso mesmo. Vou mostrar para vocês um exemplo de um 
projeto detalhado no MS Project. 
89 
 
 
 
3º: Gerenciamento 
DS: Maria, falamos das ferramentas de execução e controle, mas 
agora relacione-as com os planos elaborados. 
MC: OK, vou tentar. Vamos voltar à nossa conversa de quando 
estávamos vindo para o restaurante. A fase de execução e 
controle é um ciclo PDCA. Assim temos: 
 
1 - Gerenciamento de Prazo: 
Lembrando da obra do Restaurante Bem Viver, podemos simular 
o acompanhamento do prazo. Vejam o desenho que eu fiz. 
90 
 
 
2 - Gerenciamento de Custos: 
 
91 
 
O progresso do projeto deve freqüentemente ser comparado com 
a sua linha de base. 
Os desvios mais significativos devem ser comunicados de acordo 
com seu impacto até o nível hierárquico adequado do projeto e, 
em caso de desvios significativos, ações corretivas devem ser 
identificadas e implementadas. 
DS: O que é linha de base? 
MC: Linha de base é o conjunto de informações iniciais 
aprovadas para o trabalho do projeto, em relação às quais é 
comparada a execução do projeto e são medidos os desvios para 
o controle do gerenciamento. A linha de base da medição de 
desempenho normalmente integra parâmetros de escopo, 
cronograma, trabalho e custo, mas também pode incluir 
parâmetros técnicos e de qualidade. 
PR: Juntamente com gerenciamento de custos, acompanhamos 
também o planejamento das aquisições? 
MC: Sim, Rocha. Os contratos com os fornecedores têm que ser 
administrados, de forma que o progresso do escopo contratado 
seja verificado e conciliado com pagamentos e disposições do 
contrato. 
 
3 - Gerenciamento de Qualidade: 
SB: E o gerenciamento da qualidade, como acontece? 
MC: Esta é a sua praia. 
SB: Dessa parte eu realmente gosto. 
MC: O gerenciamento da qualidade está em todoo processo. 
Mas, na prática, a qualidade é implementada através de 
atividades ou características típicas de melhoria contínua, como, 
por exemplo: 
• atividades de garantia da qualidade; 
• parâmetros quantificáveis para definir como o sucesso será 
medido; 
• realização de comitês de projeto, com informações sobre o 
andamento do projeto, assegurando a realização de revisões (ou 
controles) para manter o projeto alinhado com suas metas; 
• aceitação, por parte da alta administração, da necessidade de 
realizar ajustes, com base na experiência e recomendações dos 
gerentes de projeto. 
SB: No meu vasto conhecimento em qualidade... 
92 
 
PR: Modesto. 
RISOS 
SB: Continuando meu raciocínio... apesar de o suporte da alta 
administração ser necessário para uma implantação bem 
sucedida de processos de gestão da qualidade, toda empresa 
precisa de diretrizes e processos para transformar políticas de 
qualidade em satisfação do cliente. 
DS: E satisfação do cliente é um grande passo para o sucesso 
dos projetos. 
 
4 - Gerenciamento de Stakeholders 
 
MC: A satisfação de clientes é função de uma adequada e 
detalhada análise de necessidades. 
PR: Posso considerar que um dos nossos principais clientes são 
os stakeholders clientes? 
MC: Sim. Relembrando o conceito, Stakeholders são pessoas, 
órgãos, 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 gestão da 
qualidade. 
Envolve os seguintes aspectos: 
 identificação dos stakeholders; 
 entendimento do conhecimento e habilidades dos stakeholders; 
 análise do Projeto de forma a assegurar que as necessidades 
dos stakeholders serão atendidas. 
 mobilização e envolvimento dos stakeholders no Projeto através 
de: 
• alocação de trabalho para os stakeholders; 
• utilização dos mesmos como especialistas; 
• informações sobre o Projeto; 
• envolvimento dos stakeholders em mudanças no Projeto; 
• criação de lições aprendidas através dos mesmos; 
93 
 
 obtenção de aceitação formal do Projeto pelos stakeholders 
quando do encerramento. 
 
5 - Gerenciamento de Escopo. 
 
PR: O bom gerenciamento dos stakeholders garante o bom 
gerenciamento do escopo? 
MC: O Gerenciamento de Stakeholders é apenas uma parte. 
O Gerenciamento de Escopo de Projetos envolve os processos 
necessários 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 ações e trabalhos necessários e 
que na execução somente o que foi proposto seja executado. 
Assim, o foco principal consiste em definir e controlar o que está 
e o que não está incluído no projeto. 
Em última análise, Gestão de Escopo significa: 
1. fazer uma constante verificação no sentido de assegurar que 
todo o trabalho está sendo executado; 
2. dizer “não” a trabalhos adicionais, não incluídos no projeto ou 
não 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 relação às 
especificações, e as mudanças fora do acordado na definição do 
projeto. 
 
4º: Controle de Mudanças 
 
DS: E como gerenciamos a mudança no escopo? 
MC: O gerenciamento das mudanças protege a viabilidade do 
projeto e os requerimentos de negócio aprovados. Esse processo 
fornece as informações apropriadas ao sponsor para decidir se 
as modificações devem ser aprovadas com base no impacto do 
projeto em termos de custo e cronograma. 
É razoável esperar que mudanças ocorram em vários momentos 
do projeto, sendo conveniente estar preparado para isso e definir 
94 
 
um processo para gerenciá-las. A questão da comunicação será 
um dos pontos básicos no tratamento do assunto. 
Existem vários tipos de mudança (escopo, qualidade, prazo, 
custos, etc) que levam em conta dois aspectos fundamentais: 
Mudanças necessárias (requeridas): normalmente surgem de 
problemas de processos, atrasos de cronograma, questões 
técnicas ou falta de recursos para o projeto (humanos ou 
financeiros). Essas questões necessitam de uma forte atenção 
dos gerentes do projeto e eles precisam reagir a elas com 
modificações no plano do projeto, no orçamento, no cronograma, 
nas entregas ou em algum outro aspecto dos processos do 
projeto; 
Mudanças solicitadas: é bastante comum que os requisitos 
técnicos ou de negócios se alterem durante a vida de um projeto, 
demandando certa flexibilidade dos responsáveis pelo projeto e 
pelas partes interessadas. Ainda que nem toda solicitação de 
mudança seja (ou deva ser) aceita e implementada, precisa haver 
um processo onde possa ser tratada. 
 
5º: Comunicação 
 
SB: Da mesma forma que o gerenciamento de qualidade, o 
gerenciamento de comunicação está presente em todo o 
processo de elaboração e execução do projeto. 
MC: Segundo o Guia PMBOK®, à medida que ocorre a fase de 
execução do projeto, estará sendo realizada a implementação do 
gerenciamento de comunicações, por meio das ações previstas 
no plano de comunicação. A distribuição da informação envolve 
“colocar as informações à disposição das partes interessadas no 
projeto no momento oportuno, além de responder às solicitações 
de informações não previstas”. 
São encaminhados e-mails, cartas, fax e, dependendo do projeto, 
ocorre também a publicação no jornal. Para o público interno, 
geralmente a divulgação é feita na intranet. 
De acordo com a programação das reuniões, elaboramos os 
relatórios de Progresso, Desempenho, Executivo, Divulgação e 
gráficos de gestão à vista. 
95 
 
 
6º: Falhas em Projetos 
 
DS: Com todo esse planejamento e controle, por que existem 
tantas falhas em projetos? 
SB: Gostei da pergunta. Deve ser porque as empresas querem 
tudo para ontem e esquecem que muitas atividades só podem 
ocorrer amanhã. 
Risos. 
MC: Na realidade existem vários fatores: 
 
 falha no planejamento e na antecipação de riscos e incertezas; 
 comunicação com a equipe deficiente; 
 falta de liderança; 
 suporte inconsistente (alocação de pessoas, conflitos, sistemas e 
procedimentos para suporte ao planejamento e ao controle); 
 falta de comprometimento dos times com o sucesso dos 
Projetos; 
 nível do desafio; 
 Stakeholders não envolvidos nos momentos certos 
 objetivos não claros; 
 definição de papéis e responsabilidades vagas ou inexistentes; 
 necessidades de recursos incompletas ou imprecisas; 
 compromissos-chave do Projeto não identificados ou não 
institucionalizados; 
 falta de um processo formal de comunicação; 
 monitoramento do progresso do Projeto imprecisa ou tardia; 
 falta de sistematização da gestão da performance, do 
reconhecimento e da recompensa das pessoas; 
DS: Mas tudo isso pode ser evitado ou minimizado com uma 
metodologia. 
MC: Só a metodologia não basta. A metodologia tem que ser 
conhecida e aplicada por todos os envolvidos em gerenciamento 
de projetos. 
 
6º: Fatores Críticos de Sucesso 
 
DS: Então, Maria, eu entendo que os fatores críticos para um 
resultado positivo na execução dos nossos projetos sejam: 
 meta claramente definida; 
96 
 
 gerente e Equipe do projeto experiente; 
 comprometimento das partes envolvidas; 
 eficiente sistema de comunicações; 
 planejamento e controle adequados; 
 inexistência de item de alto risco; 
 estrutura organizacional adequada; 
 acordo entre a equipe do projeto, o cliente e a gerência em 
relação aos objetivos do projeto; 
 plano com caminho, responsabilidades claras, estruturado para 
se fazer medições; 
 comunicação constante; 
 controle eficientee adequado de escopo, prazo e custos. 
MC: Em outras palavras, eu diria: é a gestão eficiente de Escopo, 
Prazo, Custos, Qualidade e Stakeholders aliada à boa 
Comunicação, Gestão de Riscos e Controle de Mudanças que 
definem o sucesso dos nossos projetos. 
 
 
Gerenciamento de Escopo 
97 
 
 
No Restaurante 
 
DS: Maria, estou um pouco confusa. Nós 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 não está muito clara. Será que podemos 
conversar um pouco mais sobre ela? 
MC: Claro que sim, Delma. Todas as dúvidas devem ser 
compartilhadas. Precisamos sempre conversar e trocar 
experiências para que tenhamos um bom gerenciamento dos 
nossos projetos. 
PR: Meninas, podemos pedir a conta? 
MC e DS: Claro. 
MC: Continuamos nossa conversa no carro. 
 
98 
 
Conceitos 
 
DS: Então, Maria, reforçando o conceito de escopo, posso dizer 
que escopo é a maneira como nós descrevemos os limites do 
projeto. Caracteriza-se pela definição do trabalho que será 
realizado, estabelecendo os produtos de cada etapa e as 
atividades necessárias para sua execução, e também o “que não 
será feito” dentro da abrangência, eliminando qualquer 
expectativa não prevista dos clientes e dos stakeholders. 
MC: Isso mesmo. Um escopo bem elaborado reduz 
consideravelmente o nível de incerteza quanto aos resultados de 
um projeto no seu início. 
PR: O que vocês disseram reforça a necessidade de termos tudo 
bem documentado entre as partes a respeito dos objetivos, 
restrições, premissas e interfaces. 
SB: Maria, o detalhamento do escopo está relacionado com o 
tamanho do projeto? 
MC: Boa lembrança, Been. Lembram-se do início das nossas 
conversas, quando falei da complexidade dos projetos? Então, o 
nível de detalhamento do escopo deve corresponder às 
demandas do porte do projeto (valor x complexidade). 
DS: Fico muito preocupada com essa definição de escopo, pois 
entendo que muitas vezes não existe consenso no entendimento 
sobre o produto final do projeto. 
MC: Você está certa, Delma. Por isso todas as etapas são 
importantes. Veja este desenho, que retrata, de forma engraçada, 
como é importante o detalhamento do escopo. 
 
RISOS 
 
ESCOPO 
99 
 
 
-> Da esquerda para direita: Como o cliente explicou sua necessidade; Como o 
gerente de projeto entendeu; Como a equipe projetou; O que foi executado; A 
expectativa dos stakeholders; Como o projeto foi documentado; Como o cliente foi 
cobrado; Do que o cliente realmente precisava; Como o projeto foi suportado; 
Quais os recursos que foram alocados. 
 
RISOS 
100 
 
 
Considerações 
 
PR: Reforçando as informações: o processo de gerenciamento do 
escopo é realizado para controlar os deliverables, (entregas) 
quantidade e conformidade em relação às especificações e às 
mudanças fora do acordado na definição do projeto. 
SB: “Peraí”. Entendi quase tudo, mas reforça um pouco essa tal 
de mudança. 
MC: “Essa tal de mudança” é o gerenciamento das mudanças. Ele 
protege a viabilidade do projeto e os requerimentos de negócio 
aprovados. Quando o projeto é definido, determinadas premissas 
são feitas a respeito daquilo que será produzido. 
Estas são 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 alteração de 
um item acordado. Então as estimativas para o custo, o esforço e 
a duração serão alterados. 
101 
 
Se o sponsor concordar em incluir o trabalho adicional, o 
coordenador terá o direito de alterar custo, horas de trabalho e a 
duração, para refletir esse trabalho. Essa nova estimativa de 
custo, o esforço e a duração agora se transformam na nova meta 
aprovada. 
O coordenador e a equipe de projeto devem reconhecer quando 
essas mudanças são solicitadas. Então elas devem seguir um 
processo predefinido de mudança do escopo. 
Esse processo fornece as informações apropriadas ao sponsor 
para decidir se as modificações devem ser aprovadas com base 
no impacto no projeto em termos de custo e cronograma. 
 
Mudança de Escopo 
 
SB: Maria, apresente um exemplo prático do que você acabou de 
falar. Acho que fica mais claro. 
MC: Deixe-me pensar. 
PR: Puxa, pessoal, tem uma obra na avenida principal. Vou 
precisar mudar o caminho e talvez atrasaremos para chegar à 
empresa. 
MC: Olha aí nosso exemplo! 
102 
 
 
SB: Que exemplo? 
MC: Acompanhem meu raciocínio. Quando saímos para o almoço, 
tínhamos um roteiro pré-definido. 
DS: – Você quer dizer que o nosso almoço é um projeto? 
MC: Sim. É um evento com início e fim definido (horário do 
almoço), além de um resultado exclusivo (almoço dos colegas do 
setor). Também pode sofrer alterações (como acabou de 
acontecer). 
SB: Continuo não entendendo. 
MC: Nosso almoço 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 almoço; 
- pedir a sobremesa; 
- pagar pela refeição; 
- voltar ao Carro; 
103 
 
- retornar à empresa pelas avenidas principais; 
- chegar à empresa às 14 horas. 
 
PR: Vamos seguir esse raciocínio. Nosso projeto teve duração de 
2 horas, ao custo total de R$ 100,00 (R$ 25,00 p/ pessoa). Isso 
com a nossa total satisfação, uma vez que o restaurante atendeu 
as nossas expectativas. 
MC: Sim. No entanto nem todas as atividades definidas serão 
cumpridas. 
PR: Como não serão? 
MC: Você acabou de nos dizer que existem obras na avenida 
principal. Assim teremos que pegar um caminho alternativo para 
chegar à empresa. 
DS: Isso significa que alteramos o escopo do projeto? 
MC: Exatamente. Do escopo proposto, alteraremos as duas 
últimas atividades. Assim teremos: 
- retornar à empresa pelas vias secundárias; 
- chegar à empresa às 14h30min. 
DS: Eu entendo que essas alterações devam ser acordadas por 
todas as partes interessadas. 
MC: No meu exemplo, as partes interessadas somos nós 
mesmos. E essas alterações não prejudicaram nosso projeto. 
Ocorrerá apenas o atraso na entrega. 
PR: Este foi um exemplo muito simples. 
MC: Foi, Rocha. O que eu quero reforçar é que mudanças sempre 
podem ocorrer e que temos de estar prontos para os impactos 
que elas irão trazer para nossos projetos. 
DS: – Então, trabalhar com controle do escopo quase sempre é 
lidar com o controle das mudanças de escopo. 
SB: Só por curiosidade, temos de documentar tudo isso também? 
MC: Claro. Toda a solicitação de mudança deve ser registrada. É 
importante que os registros contenham: 
- data; 
- local, atividade ou fase do projeto de ocorrência da mudança; 
- estado de origem, antes da mudança, e estado de destino, 
depois da mudança implementada; 
- grau de importância da mudança; 
- solicitante. 
SB: Maria, desenhe um modelo para mim. 
MC: No carro é difícil. Acho que tenho um modelo aqui na minha 
pasta. Aqui está. 
104 
 
 
105 
 
Modelo de EAP 
 
DS: Maria, você falou mais cedo sobre a decomposição do 
escopo numa estrutura analítica, mais conhecida por EAP. 
Explique um pouco mais, por favor. 
MC: Legal. Acho que vale a pena retornarmos a esse assunto. 
EAP representa uma “decomposição hierárquica orientada à 
entrega do trabalho a ser executada pela equipe do projeto para 
atingir os objetivos e criar as entregas necessárias”. 
A organização 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, conseqüentemente, 
do que será monitorado e controlado. 
DS: Essa decomposição hierárquica subdivide o escopo do 
projeto e as entregas do projeto em componentes menores? 
MC: Sim. Segundo o glossário do PMI, a decomposição é “uma 
técnica que subdivideo escopo do projeto e as entregas do 
projeto em componentes menores e mais facilmente gerenciáveis 
até que o trabalho do projeto associado à realização do escopo 
do projeto e ao fornecimento das entregas seja definido em 
detalhes suficientes para dar suporte à execução, ao 
monitoramento e ao controle do trabalho”. 
SB: Existe algum passo-a-passo para decomposição de uma 
EAP? 
DS: Você explicou o que era EAP e nos mostrou um exemplo. 
Existe uma EAP padrão que podemos utilizar? 
MC: Como eu havia dito anteriormente, a EAP possui três níveis: 
• Primeiro nível: representa o tema do projeto; 
• Segundo nível: representa o tema delimitado, a estratégia de 
execução; 
• Terceiro nível: normalmente, representa o trabalho a ser 
realizado: 
− define os produtos do projeto (deliverables); 
− possui um responsável pela execução; e 
− pode possuir limitações de prazo e custo. 
 
Assim, adotamos a seguinte EAP para elaboração do escopo do 
projeto: 
106 
 
 
SB: Você poderia detalhar cada um desses passos? 
MC: Vejamos: 
1º) Escrever o nome do projeto no primeiro nível (nível 0) da EAP: 
 
2º) Iniciar o segundo nível com uma entrega denominada 
gerenciamento do projeto: 
 
3º) Acrescentar as fases do ciclo de vida (entrega completa da 
fase) ou maiores entregas provenientes da decomposição inicial 
do escopo do projeto no segundo nível: 
 
4º) Acrescentar no segundo nível, ao final, uma entrega 
denominada fechamento: 
107 
 
 
5º) Acrescentar as entregas (produtos) e subprodutos (entregas 
parciais) que as compõem: 
 
6º) Decompor as entregas parciais até um nível de detalhe que 
viabilize o planejamento e controle em termos de tempo, custo, 
qualidade, risco, atribuição de responsabilidade e contratação, se 
for o caso. 
108 
 
 
Os componentes que não estão dentro de uma caixa estão 
expressos no nível mais baixo de cada ramo da EAP. Esses 
componentes são denominados pacotes de trabalho e devem ser 
detalhados no dicionário da EAP. 
DS: – O que é dicionário da EAP. 
MC: É um documento complementar à EAP. Apresenta uma breve 
especificação do pacote de trabalho e seu critério de aceitação. 
DS: – Esse dicionário é obrigatório? 
MC: O guia PMBOK sugere que todos os pacotes de trabalho 
estejam detalhados no dicionário EAP. No meu entendimento, 
projetos pequenos não precisam dessa obrigação, desde que o 
enquadramento do projeto na metodologia de gerenciamento do 
projeto da empresa indique esse documento como opcional. 
SB: Maria, quando elaboramos um escopo, fazemos também sua 
representação através da EAP. Você nos mostrou um exemplo 
disso. Quando fazemos mudança, nossa EAP também muda? 
MC: Claro. Deverá ser elaborada uma nova EAP com as 
alterações. 
PR – Estamos chegando à empresa. Podemos continuar a 
conversa depois? 
MC: Claro, Rocha. 
 
Gerenciamento de Riscos 
109 
 
 
No Carro 
 
PR: Puxa, como o tempo está mudando. Parece que vai cair uma 
chuva daquelas. 
SB: Vai mesmo. Tomara que você consiga estacionar o carro no 
estacionamento coberto. 
PR: Também espero. Faz tanto tempo que não chove, que, pelo 
jeito, vai ser chuva de granizo. Vai ser um risco deixar o carro do 
lado de fora. 
MC: Rocha, que exemplo legal você acabou de dar sobre risco! 
PR: Como é que é!? 
MC: Continuamos nossa conversa no carro. 
 
1º - Conceitos 
 
MC: Você se lembra do conceito de riscos em projetos? 
110 
 
PR: Sim. Risco em projetos corresponde a um evento ou condição 
incerta que, se efetivamente ocorrer, pode implicar efeito positivo 
ou negativo nos resultados do projeto. 
MC: Isso mesmo. Até agora não havia falado muito de riscos, mas 
você me deu um exemplo que podemos explorar para falar um 
pouco de riscos. 
DS: Outro conceito de risco é a probabilidade de um evento 
ocorrer associado ao impacto (conseqüência da ocorrência). 
MC: Devemos lembrar que o risco pode ser de natureza interna ou 
externa. A chuva representa um risco de natureza externa e não 
temos controle sobre ele. No entanto o local aonde iremos 
estacionar o carro pode ser considerado um risco. Como é um 
risco de natureza interna, temos controle sobre ele. 
DS: De acordo com as nossas conversas, podemos dizer que o 
risco é composto pelo evento, sua causa e o efeito da ocorrência. 
MC: Apenas complementando a sua informação, temos: 
• Evento: acontecimento, eventualidade. 
• Causa: aquilo ou aquele que ocasiona um acontecimento ou faz 
com que algo exista; princípio; origem; motivo, razão, pretexto; 
partido. 
• Efeito: conseqüência; produto de uma causa, fim, destino, 
aplicação. 
PR: Se entendi bem, se eu estacionar o carro no estacionamento 
descoberto, corro o risco de ter o meu carro amassado, caso a 
chuva seja de granizo. 
MC: Exatamente. Na medida em que eu explicar um pouco mais 
sobre riscos, irei fazendo as comparações. Acredito que assim 
ficará mais claro. 
DS: OK. Você vai explicar um pouco mais sobre todas as etapas 
do gerenciamento de riscos. 
MC: Vou. 
 
2º: Etapas do Gerenciamento de Riscos 
 
SB: Viver é um risco. 
DS: Viver é assumir risco. 
PR: Nossa! Vocês dois estão viajando. Vamos deixar a Maria 
explicar. 
MC: Hoje em dia, uma das áreas de conhecimento do 
gerenciamento de projetos que está sendo mais estudada é a do 
Gerenciamento de riscos. 
111 
 
O gerenciamento de riscos tem como objetivo maximizar os 
resultados de ocorrências positivas e minimizar as conseqüências 
de ocorrências negativas. O gerenciamento de riscos é composto 
por seis etapas. São elas: 
1. Planejar a gerência de risco: determinar qual a abordagem e 
planejar as atividades de gerência de risco que serão executadas 
para o projeto. 
2. Identificar riscos: determinar quais riscos podem afetar o 
projeto e documentar as suas características. 
3. Analisar riscos qualitativamente: avaliar, determinar e compor 
os fatores de impacto e probabilidade, bem como priorizar seus 
efeitos nos objetivos do projeto. 
4. Analisar riscos quantitativamente: analisar os riscos 
priorizados, associando a eles um número que permitirá avaliar, 
sobretudo financeiramente, as implicações caso esses riscos 
venham a ocorrer. 
5. Planejar as respostas aos riscos: desenvolver procedimentos e 
técnicas para avaliar oportunidades e reduzir as ameaças aos 
objetivos do projeto. 
6. Controlar e monitorar riscos: executar planos de respostas e 
identificar novos, monitorar riscos residuais e avaliar efeitos no 
ciclo de vida do projeto. 
 
SB: Está bem. Mas como identifico riscos, analiso, controlo, etc.? 
Isso não é fácil. 
MC: Não disse que era. No entanto, como já conversamos 
anteriormente, existem formas de identificar riscos. 
DS: Então identificar riscos é determinar o evento, a causa e o 
efeito. 
MC: Isso mesmo. Assim, há uma causa para cada risco e um 
efeito se o risco ocorrer. A causa é uma situação 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 
provável da ocorrência do risco. 
PR: Posso dizer, então, que a causa, neste caso, é o 
estacionamento lotado. O resultado disso é que meu carro pode 
ou não ficar exposto ao tempo. 
MC: Grosso modo, pode sim. 
SB: Existe alguma técnica para identificar riscos, ou trabalhamos 
no “achômetro”? 
MC: Been, em projetos “não achamos” nada. 
112 
 
DS: É tudo preto no branco. 
 
3º: Identificação dos riscos 
 
MC: Existe uma grande variedade de técnicas para identificar 
riscos. Dentre elas, temos: check-list, comparação análoga, 
análise de premissas, decomposição, entrevista com 
especialistas, técnicas de diagramação e Delphi. Algumas das 
técnicas são focadas em uma saída específica, por exemplo: se a 
incerteza estiver relacionada aos custos, a técnica pode ser a de 
análise da EAP. 
PR: Maria, explique um pouco mais essas técnicas. 
MC: Vou explicar as técnicas que podem ser aplicadas a todas as 
saídas do projeto: custo, trabalho, prazo e qualidade. 
A primeira técnica é o check-list. Nesta técnica, utilizam-se listas 
prontas para identificar os riscos.O check-list pode ser 
desenvolvido com base nas informações históricas, no 
conhecimento acumulado dos projetos e na experiência de 
especialistas. Veja esta folha com um exemplo de check-list: 
113 
 
 
114 
 
 
115 
 
 
SB: Puxa, que lista comprida. Temos que usar essa lista sempre? 
MC: Não, Been. Como eu disse, ela é um check list e nos auxilia 
na identificação dos riscos de um projeto. 
Continuando. Outra técnica é a Comparação Análoga. Essa 
técnica identifica riscos com base na idéia de que nenhum projeto 
representa um sistema totalmente novo, independente do quão 
complexo ele seja. Para tanto, a técnica prevê a identificação de 
projetos similares, cujos dados possam ser utilizados para a 
revisão ou para a elaboração dos novos projetos. 
A identificação de projetos similares envolve a determinação de 
características comuns, por exemplo, tecnologia, funcionalidade, 
estratégia de contrato e processo de desenvolvimento. 
DS: Mas qual a vantagem dessa técnica? 
MC: Na realidade, existem vantagens e desvantagens. Uma 
vantagem da comparação análoga é que ela é fácil de ser 
utilizada. Como desvantagem, tem-se que sua precisão depende 
dos dados históricos, da interpretação desses dados e do nível 
de detalhe em que estão descritos. 
DS: Significa que, para utilizarmos essa técnica, os projetos 
anteriores têm que estar bem documentados? 
MC: Isso mesmo. Outra técnica é a análise de premissas. Na 
análise de premissas, cada projeto é concebido e desenvolvido 
com base em um conjunto de premissas. 
Esta é uma técnica que explora as incertezas do projeto pela 
existência de premissas que foram assumidas, e que podem não 
ser verdadeiras. As premissas imprecisas, inconsistentes ou 
incompletas deverão ser identificadas. 
116 
 
DS: Relembrando. Premissas são fatores que, para os propósitos 
do planejamento, consideram-se como verdadeiros, como reais 
ou como mais prováveis, como o exemplo que você deu para o 
projeto do restaurante. 
 
MC: A outra técnica muito utilizada é a análise causal. 
A análise causal mostra a relação entre um efeito e sua possível 
causa, para que seja verificada a origem do risco. 
Da mesma forma que é utilizada para o acompanhamento do 
projeto, aqui também o conhecido “diagrama de causa e efeito” 
ou “espinha de peixe” será útil para identificar as causas dos 
riscos. A filosofia da análise causal sustenta que, se um erro 
ocorrer, ele irá acontecer novamente, a menos que se faça 
alguma coisa para evitá-lo. 
PR: E daí? Identificamos os riscos. O que fazemos agora? 
 
4º: Análise dos Riscos 
 
MC: No processo de análise de risco, fazemos análise qualitativa 
e análise quantitativa. 
SB: Como é que é? 
MC: Analisar qualitativamente um risco é qualificá-lo quanto à sua 
pontuação: 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 ação. 
PR: Trabalhamos, então, com probabilidades? 
MC: Probabilidade x Impacto. Fazemos a análise da seguinte 
forma: 
Primeiro, temos o referencial de probabilidade de ocorrência. 
Riscos têm 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, 
então é um fato (e talvez uma restrição). 
117 
 
DS: Temos referências estabelecidas? 
MC: Temos as referências mais utilizadas, que são: 
• Alta chance de ocorrer 0.75 
• Média chance de ocorrer 0.50 
• Baixa chance de ocorrer 0.25 
• Muito baixa chance de ocorrer 0.10 
 
PR: Então agora temos o referencial de impacto? 
MC: Exato. As referências mais utilizadas são: 
• Muito alto 5.0 
• Alto 4.0 
• Médio 3.0 
• Baixo 2.0 
• Muito baixo 1.0 
 
PR: Pelo meu conhecimento em probabilidade, considero que, 
para um bom entendimento, devemos colocar essas informações 
em uma matriz e classificá-las. 
MC: Sim. Fazemos uma pontuação para cada risco específico, 
baseada em uma matriz Probabilidade x Impacto. 
DS: Dessa forma os riscos serão classificados de acordo com 
grau de importância? 
MC: Classificaremos os riscos em baixo, médio e alto e, assim, 
podemos traçar o planejamento de respostas aos riscos. 
PR: Você acabou de falar sobre a classificação dos riscos. Mas 
como eu os classifico em baixo, médio ou alto? 
MC: Desculpe-me. Esqueci de dizer. Os riscos do projeto podem 
ser classificados em: 
• Baixo risco 0,10 a 0,75 
• Médio risco 0,95 a 1,90 
• Alto risco 2,00 a 3,75 
Vejam esta figura. Ela é a representação de uma matriz de 
probabilidade x impacto. 
118 
 
 
 
5º: Fontes de risco 
 
SB: Está tudo muito bem explicado. Mas como identifico um risco? 
Existe alguma fonte específica? 
MC: Existem fontes de riscos, que é um grupo de características 
semelhantes que originam os riscos. Por exemplo, pessoas, 
tecnologia, escopo e mercado. 
SB: Você poderia explicar um pouco melhor sobre essas fontes 
de riscos? 
MC: Claro. Hoje as fontes mais comuns são: 
• Aquisições: riscos relacionados ao tempo para aquisição de 
compras de bens e serviços; 
• Cliente: riscos relacionados ao envolvimento do cliente e às 
relações entre os clientes; 
• Comunicação: riscos de não comunicar bem o andamento do 
projeto; 
• Complexidade do projeto (Escopo): riscos relacionados ao grau 
de dificuldade para o desenvolvimento do projeto; 
• Composição 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 (funcionários, subcontratados, estagiários), 
podem influenciar o andamento do projeto, pois a diversidade 
pode trazer para a equipe de desenvolvimento problemas como 
comparações salariais e diferentes níveis de comprometimento 
entre os seus membros; 
• Equipe do Projeto: riscos relacionados à habilidade dos 
técnicos, ao relacionamento da equipe e à motivação para o 
trabalho; 
119 
 
• Gerência de projetos: riscos relacionados à habilidade do 
coordenador e às atividades próprias de gerência de projetos; 
• Política organizacional: riscos relativos aos aspectos culturais e 
políticos da organização; 
• Prazo (Tamanho e duração do projeto): riscos relativos ao 
tamanho e à duração (prazo) do projeto. Trata-se de aspectos 
significativos para o aumento da complexidade, que requerem 
uma análise da influência desses 
fatores no risco de prazo do projeto; 
• Processo (Qualidade): riscos relacionados ao processo, ou seja, 
todos os processos necessários para a produção dos produtos do 
projeto com qualidade. Portanto a categoria, ao invés 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 esforço para manutenção da 
comunicação entre os seus membros, exigindo maior 
coordenação do gerente de projeto, o que torna seu trabalho 
mais complexo; 
• Tempo de dedicação do coordenador ao projeto: riscos relativos 
aos aspectos de performance do projeto. Pode ser afetada pelo 
número de projetos pelos quais o coordenador de projeto é 
responsável ou o seu tempo de dedicação ao projeto. 
 
PR: Maria, você poderia listar alguns riscos potenciais? 
MC: Conheço alguns. Posso destacar: 
Relativos ao Cliente 
• Ausência da participação do cliente 
• Cliente resistente a mudanças 
• Conflitos entre clientes 
• Clientes com atitudes negativas em relação ao projeto 
• Clientes não comprometidos com o projeto 
Relativos à Equipe de Desenvolvimento 
• Ausência de cooperação entre os membros da equipe 
• Conflitos entre cliente e equipe de desenvolvimento 
• Membros da equipe de desenvolvimento treinados 
inadequadamente 
• Ausênciade comprometimento dos membros da equipe de 
desenvolvimento em relação ao projeto 
• Membros da equipe inexperientes 
120 
 
• Falta de boas práticas da equipe técnica 
• Conflitos entre os membros da equipe de desenvolvimento 
• Freqüente rotação de pessoal na equipe de projeto 
• Equipe de desenvolvimento não familiarizada com as 
ferramentas 
• Membros da equipe de desenvolvimento não familiarizados com 
o negócio do cliente 
• Atitudes negativas da equipe de desenvolvimento 
• Ausência de perfil especializado na equipe de projeto para 
atender aos requisitos do projeto 
Relativos a Políticas Organizacionais 
• Recursos retirados do projeto por causa de mudanças nas 
prioridades organizacionais 
• Mudanças na gerência da organização durante o projeto 
• Políticas corporativas com efeito negativo no projeto 
• Influência política no projeto (externa) 
• Ambiente organizacional instável 
• Reestruturação organizacional durante o projeto 
• Ausência de suporte gerencial de alto nível para o projeto 
• Ausência ou perda do comprometimento organizacional com o 
projeto 
Relativos à Complexidade do Projeto 
• Dependência de fornecedores externos 
• Muitos fornecedores externos envolvidos com o projeto de 
desenvolvimento 
• Alto nível de complexidade técnica 
• Tarefas altamente complexas a serem automatizadas 
• Projeto afetando um grande número de departamentos ou 
unidades do cliente 
• Grande quantidade de interação com outros sistemas 
• Projeto envolvendo o uso de novas tecnologias 
• Inadequada transferência de tecnologia para o projeto 
• Condições de trabalho inadequadas 
Relativos a Processo: 
• Padrões, políticas e metodologias de engenharia de software 
inadequados 
• Métodos e ferramentas de engenharia de software inadequados 
• Burocracia excessiva 
• Falta de suporte para a resolução de problemas técnicos 
• Falta de infra-estrutura para reuso 
• Falta de prática de reuso 
121 
 
• Repositórios de projeto e controle de configuração inadequados 
• Ausência de uma metodologia efetiva de gerência de projetos 
Relativos à Gerência de Projetos: 
• Planejamento inadequado do prazo 
• Planejamento inadequado dos recursos necessários 
• Planejamento inadequado do orçamento 
• Pressão excessiva de prazo 
• Baixa produtividade 
• Baixa qualidade dos produtos intermediários e finais 
• Ausência de “pessoas com perfil” para liderar o projeto 
• Acompanhamento do progresso do projeto insuficiente 
• Fraco planejamento de projeto 
• Falta de definição dos marcos do projeto 
• Ineficiência do gerente do projeto 
• Inexperiência do gerente de projeto 
• Comunicação ineficiente 
Relativos a Requisitos: 
• Mudanças contínuas dos objetivos e escopo do projeto 
• Requisitos conflitantes 
• Mudanças contínuas dos requisitos 
• Requisitos não definidos de forma adequada 
• Falta de clareza dos requisitos 
• Requisitos incorretos 
• Deficiência no entendimento dos usuários quanto às limitações 
ou capacidades do sistema 
SB: Puxa. Será que iremos conseguir tratar esse assunto? 
PR: Por que não? 
SB: São muitas informações e não me sinto seguro em determinar 
quais riscos são mais ou menos impactantes. 
DS: Estamos iniciando o processo de gerenciamento de projetos. 
Acredito que tudo é uma questão de prática. 
MC: Concordo com a Delma. Apenas com o tempo, teremos 
conhecimento e maturidade para realizarmos uma gestão de 
projetos eficiente e eficaz. 
122 
 
 
 
6º: Planejamento das respostas 
 
DS: Entendo que, depois de identificarmos os riscos, como você 
acabou de dizer, teremos que planejar como administrar os 
riscos, caso eles ocorram. 
PR: Como fazemos esse planejamento? 
MC: É simples. O planejamento das respostas consiste da 
determinação da estratégia de como gerenciar o risco e elaborar 
um plano de ação para tratá-lo. Esse processo é aplicado 
obrigatoriamente nos projetos de dimensão PJ4, PJ3, PJ2 e é 
opcional nos projetos PJ1. 
SB: Por que é opcional nos projetos PJ1? 
 
MC: Porque são projetos de curta duração e de valores 
financeiros muito pequenos. Os riscos, nesse caso, quase são 
imperceptíveis ou não existem. 
123 
 
PR: Existem estratégias específicas para tratar os riscos? 
MC: Existem alguns tipos de estratégia que podem ser adotadas 
como resposta a riscos. São elas: 
• Evitar o risco: essa estratégia deve ser considerada para risco 
de alta probabilidade e com severas conseqüências; 
• Transferir o risco: implica repassar para um terceiro a 
responsabilidade por sua gestão. Não implica sua eliminação. O 
plano de resposta, quando elaborado, consiste da identificação e 
contratação de terceiro, que assumirá as responsabilidades do 
risco; 
• Mitigar o risco: visa à redução da probabilidade e do impacto do 
risco; 
• Aceitar o risco: implica aceitar as conseqüências do evento de 
risco. O plano de resposta, quando elaborado, inclui a 
contingência; 
• Alavancar o risco: implica maximizar as chances dos riscos 
positivos para o sucesso do projeto. 
 
SB: O que é incluir a contingência? 
PR: Se entendo bem, contingência deve ser uma reserva 
financeira. 
MC: Exato. Contingência, nesse caso, é a reserva monetária 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 ocorrência sobre o 
valor monetário relativo às atividades impactadas pelo risco. 
Quando não identificamos os riscos, geralmente devemos 
contingenciar 5% do orçamento total do projeto. 
 
7º: Controle 
 
SB: Legal. Gostei deste assunto. 
PR: Até que enfim. 
RISOS 
DS: Todos estes processos são muito importantes. 
MC: São realmente importantes. E, para finalizarmos este 
assunto, temos o controle da gestão de riscos. 
SB: Pelo que conversamos, o controle de riscos tem que ser 
acompanhado o tempo todo. 
MC: Isto mesmo, Been. O controle de respostas a riscos é um 
processo contínuo ao longo do ciclo de vida, uma vez que o 
124 
 
gerenciamento de riscos é um processo dinâmico. É realizado por 
meio do acompanhamento dos planos de respostas, do 
monitoramento dos riscos residuais e da identificação de novos 
riscos. 
SB: Estaremos num ciclo PDCA. 
MC: Exatamente. 
PR: Pessoal, chegamos. Será que vou conseguir estacionar? 
 
DS: Vamos lá. A probabilidade é grande de conseguir. 
SB: Olha lá, Rocha, uma vaguinha no estacionamento coberto 
esperando por você. 
PR: Legal. Assim, nem o carro nem nós corremos o risco de nos 
molhar. 
 
Gerenciamento de Stakeholders 
125 
 
 
No Estacionamento da Empresa 
 
DS: Nossa, que chuva. Ainda bem que já chegamos. 
PR: É. E estamos protegidos. 
SB: Maria, aproveitando que já chegamos e estamos protegidos, 
gostaria que você falasse um pouco mais sobre os stakeholders. 
Considero que sua gestão seja também muito importante. 
MC: E é muito importante. Você se lembra do conceito de 
stakeholders? 
SB: Stakeholders são pessoas, órgãos, entidades ou empresas 
interessadas nos resultados do projeto. 
MC: Isto mesmo. Mas executar um projeto com sucesso requer 
um alto grau de integração com os stakeholders. 
Stakeholder é qualquer um dos atores que esteja interessado em 
seu projeto ou que possa impactar no andamento ou vir a ser 
afetado por seus produtos. É importante entender os valores e os 
126 
 
assuntos relacionados aos stakeholders, para focá-los e mantê-
los integrados ao projeto. 
 
1º - Principais Stakeholders e suas Funções 
 
DS: Mas cada stakeholder possui valores e desejos diferentes? 
MC: Sim. Lembra-se do que eu disse na hora do almoço? Temos 
que nos antecipar em atender os desejos de nossos 
stakeholders. 
PR: Então, para cada stakeholder, teremos desejos diferentes. 
MC: Além disso, cada stakeholder envolvido terá uma função 
definida, assim, as expectativas também serão diferentes. 
SB: Maria, dê exemplos. 
MC: OK. Lembra-se quando conversamos sobre os principais 
stakeholders e eu citei alguns? 
SB: Sim, você citou: sponsor, gerente de projeto, clientes, 
organização executora, equipe de projeto,fornecedores e 
usuários finais. 
127 
 
MC: Muito bem Been, e como acabamos de comentar, cada um 
tem sua característica e sua função específica. 
SB: E quais são? 
MC: Vou explicar. 
 
1.1- Sponsor 
 
MC - Temos, em primeiro lugar, o Sponsor. Ele é o indivíduo ou 
entidade que disponibiliza os recursos financeiros (patrocinador) 
para a execução do projeto. 
Usualmente, essa função é desempenhada por um agente 
financeiro. 
As principais funções do sponsor são: 
• caracterizar a demanda e os produtos esperados com o projeto; 
• apresentar a caracterização do projeto para todos os 
participantes do programa; 
• participar com a equipe do projeto na definição do escopo do 
128 
 
projeto; 
• aprovar o escopo definido para o projeto; 
• garantir foco e direcionamento do projeto; 
• analisar e aprovar as propostas do grupo. 
 
DS: Posso dizer que o Senhor Fortunato, presidente da nossa 
empresa, é um sponsor? 
MC: Pode sim, Delma. Hoje, parte dos nossos projetos é de 
melhoria interna, e quem disponibiliza recursos é o Sr. Fortunato. 
PR: Sem dúvida, os dirigentes são partes interessadas. 
DS: Mas, sem sombra de dúvidas, uma das partes interessadas 
mais importante é o próprio gerente do projeto. 
MC: Isso é verdade. 
 
1.2 - Gerente de Projeto 
 
SB: Quais são suas principais funções? 
MC: Suas funções são: 
129 
 
• definir o escopo do projeto; 
• identificar e selecionar os recursos (equipe e recursos 
materiais); 
• liderar a equipe nas fases do projeto; 
• estimar e criar o orçamento; 
• identificar e gerenciar todas as questões e riscos do projeto; 
• criar e manter o plano do projeto; 
• gerenciar todas as mudanças no projeto; 
• gerenciar a documentação do projeto; 
• realizar a prestação de contas mensal e final do projeto; 
• comunicar e manter os relatórios de progresso nas reuniões de 
acompanhamento; 
• produzir o produto / serviço de acordo com as especificações 
técnicas, no prazo e custos orçados e com os recursos 
disponíveis na organização; 
• recomendar o término do projeto ou solução alternativa caso os 
objetivos não possam ser atingidos e as obrigações contratuais 
permitam; 
• tomar ou forçar as decisões 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 necessário; 
• promover as articulações com os stakeholders internos. 
 
SB: Ele é um super herói e o escritório de projetos é a liga da 
justiça. 
Risos 
MC: Você não perde a oportunidade de brincar. Na realidade, o 
gerente de projetos deve possuir um conjunto básico de 
conhecimentos para que ele possa desempenhar suas funções. 
PR: E quais seriam esses conhecimentos? 
MC: Como eu disse, é um conjunto de conhecimentos. Eu 
destacaria os seguintes: 
1. o conjunto de conhecimento em técnicas de gerenciamento de 
projetos; 
2. conhecimento básico da área onde estará gerenciando o 
projeto. Por exemplo, normas e regulamentos das áreas de 
aplicação, ou seja, áreas como petróleo e gás, setor automotivo, 
biotecnologia, serviços, dentre outros; 
130 
 
3. conhecimento e habilidades de gerenciamento geral; e 
4. habilidades interpessoais. 
DS: O que seriam habilidades interpessoais? 
MC: As habilidades interpessoais incluem: 
• liderança; 
• comunicação eficaz; 
• influência sobre a organização; 
• motivação; 
• negociação e gerenciamento de conflitos; 
• resolução de problemas. 
SB: Eu não disse? Um super herói! 
RISOS 
MC: Veja este desenho. Se a empresa não souber identificar as 
habilidades e competências dos seus funcionários, corre o risco 
de perder excelentes profissionais. 
 
1.3 - Equipe do Projeto 
 
PR: Mas esse super-herói não trabalha sozinho. Ele conta com 
uma legião de colaboradores para ajudá-lo. 
131 
 
MC: Isso mesmo. O gerente de projeto não trabalha sozinho, e a 
montagem de sua equipe é fundamental para o sucesso dos 
projetos. 
PR: Quais os benefícios na montagem de uma equipe? 
MC: Eu não diria benefícios e, sim, vantagens. Quando montamos 
uma equipe, temos: 
1. criatividade na solução de problemas, por meio do enfoque 
multidisciplinar; 
2. especialização e divisão do trabalho, promovendo economias 
de escala e aprendizagem bem como minimizando os custos do 
projeto; 
3. comprometimento da equipe com o sucesso do projeto, já que 
este implica o sucesso pessoal de cada um deles. 
DS: Mas montar uma equipe não deve ser uma tarefa fácil. 
MC: Realmente não é fácil, pois o gerente precisa administrar uma 
equipe heterogênea e multidisciplinar. Alguns autores identificam 
cinco fases para a composição de uma equipe de projetos. 
1ª fase: formação: nessa fase, os membros da equipe podem não 
ter papéis claros e provavelmente não se conhecem ou se 
conhecem apenas de cumprimentar. Nessa fase, existe um nível 
de desconfiança. É importante que o gerente exerça sua 
autoridade formal para orientar a equipe; 
2ª fase: conflito: nessa fase, os membros da equipe podem 
desafiar a autoridade do líder, já que a existência do grupo tende 
a limitar a sua expressão individual. São comuns nessa fase as 
lutas de poder, determinando as relações e hierarquia final do 
grupo; 
3ª fase: normas: nessa fase, as regras de conduta ou normas 
determinam papéis e responsabilidades, criando um sentimento 
de trabalho de grupo e coesão; 
4ª fase: desempenho: o grupo se transforma em equipe, onde cada 
um dos membros se dedica a uma tarefa específica, buscando 
alcançar os objetivos do projeto; e 
5ª fase: encerramento: essa fase é alcançada quando o projeto é 
encerrado, causando a dissolução do grupo. O líder deve fazer 
um balanço da experiência, debater lições aprendidas, aprender 
com os erros e se preparar para o próximo projeto. 
 
PR: Realmente não é uma tarefa fácil. 
DS: Gerenciar pessoas é muito difícil. 
132 
 
SB: Beleza. Montamos a equipe, desmontamos a equipe, mas 
quais são suas funções? 
MC: As funções da equipe do projeto são: 
• executar as atividades do cronograma físico; 
• subsidiar o gerente com informações do projeto; 
• dar suporte ao cliente; 
• na figura do relator, gerar e manter a documentação durante o 
ciclo de vida do projeto, como e-mails e atas de reuniões; 
• executar as decisões requeridas para assegurar que os 
objetivos do projeto sejam atingidos. 
 
1.4 - Cliente 
 
SB: Todos os stakeholders têm funções definidas? 
MC: Não necessariamente. Temos algumas funções esperadas ou 
desejadas. 
No caso dos clientes, temos as seguintes funções: 
• caracterizar a demanda e os produtos esperados com o projeto; 
• aprovar o escopo definido para o projeto; 
• aprovar as mudanças no projeto; 
• dar feedback sobre o desenvolvimento do projeto. 
Para os fornecedores, esperamos as seguintes funções: 
• fornecer o produto segundo as especificações contratuais; 
• informar sobre o andamento do projeto. 
 
PR: Maria, um projeto pode ter stakeholders que sejam 
específicos para sua realidade, e que não se apliquem a outros 
projetos? 
MC: Sim, Rocha. Como disse anteriormente, é muito importante 
identificarmos os stakeholders de cada projeto. Só assim 
poderemos nos antecipar as expectativas deles. 
DS: Para mim, a importância de identificar os stakeholders é que, 
além de serem afetados pelo projeto, eles podem ter uma 
influência direta ou indireta no seu resultado. Uma falha nesta 
identificação significará que o gerente de projeto não estará 
pensando nas necessidades de todos os envolvidos, e isto é um 
fator de risco para o projeto. 
MC: Você está certíssima, Delma. Posso dar dois exemplos 
simples desta situação: 
133 
 
• Um projeto que envolve uma obra em via pública deve 
considerar as necessidades da comunidade que será afetada 
pelo barulho e pelos transtornos (mesmo que a obra seja em 
benefício da comunidade), ou será alvo de reclamações que 
poderão levar a atrasos no cronograma. 
• Dentro de uma organização, um projeto pode gerar um 
resultado que fortalecealgumas áreas em detrimento de outras. 
Mesmo que essas áreas não participem do projeto, é importante 
entender as relações de poder envolvidas, já que os que serão 
afetados negativamente poderão tentar boicotar o projeto. 
Ao mesmo tempo, o gerente de projeto deve ter cuidado em não 
procurar stakeholders por todos os lados, ou ficará com um 
cenário difícil de gerenciar. É necessário um limite lógico para a 
identificação de quem afeta ou é afetado pelo projeto. 
 
 
134 
 
2º - O Gerenciamento 
 
SF: Boa tarde! 
Todos: Boa tarde. 
SF: Gostaram da apresentação do Sr. PMI? 
MC: Sim, foi ótima. Mostrou a todos a importância da utilização do 
gerenciamento de projetos. 
PR: Continuamos a conversar durante o almoço, e a Maria 
reforçou a apresentação do Sr. PMI, com várias informações que 
nos serão úteis no nosso dia-a-dia. 
SB: Agora mesmo, estávamos conversando sobre os 
stakeholders dos nossos projetos. 
SF: Temos projetos de várias dimensões e isso implica 
stakeholders diversos. A satisfação dos envolvidos no projeto é 
função de uma adequada e detalhada análise de necessidades. 
Assim, o gerenciamento de stakeholders é uma atividade 
eminentemente pró-ativa. 
DS: Sem sombra de dúvidas. 
SF: Fiquem à vontade. Um bom trabalho para vocês. 
Todos: Obrigado (a) 
MC: Devemos procurar incorporar as necessidades dos 
stakeholders como parte integrante do escopo do projeto e os 
requisitos dos mesmos como base para o gerenciamento da 
qualidade e da comunicação. 
DS: Eu entendo que, sem uma definição e entendimento comuns 
entre os stakeholders, não há garantia de obtenção de resultados 
esperados porque os critérios para o sucesso não foram 
compartilhados. 
SB: Então devemos elaborar também um planejamento para 
gerenciar os stakeholders? 
MC: Não necessariamente. É importante que o gerente de 
projetos desenvolva um plano de como o projeto pretende 
atender às expectativas do patrocinador e dos demais 
stakeholders. Desta forma, ele conseguirá coletar, entender e 
gerenciar as expectativas de todos os stakeholders. 
PR: Quais os passos o gerente de projetos deverá seguir? 
MC: Não existe um roteiro pré-definido, mas os gerentes de 
projetos, do meu ponto de vista, devem procurar: 
1. identificar os stakeholders; 
2. entender o conhecimento e habilidades dos stakeholders; 
3. analisar o projeto, de forma a assegurar que as necessidades 
135 
 
dos stakeholders sejam atendidas; 
4. mobilizar e envolver os stakeholders no projeto, por meio de: 
• alocação de trabalho para os stakeholders; 
• utilização dos mesmos como especialistas; 
• informações sobre o projeto; 
• envolvimento dos stakeholders em mudanças no projeto; 
• criação de lições aprendidas através dos mesmos; 
5. obter a aceitação 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 envolverão mais com 
metas e objetivos bem definidos desde o início e ajudarão 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 alcançar as 
metas e os objetivos do projeto. Estes devem ser comunicados 
claramente aos stakeholders, e esforços devem ser feitos para 
assegurar que haja uma compreensão clara relativa à qualidade 
e composição de cada deliverable. 
9. garantir que o gerenciamento da comunicação seja claro com 
os stakeholders. Uma vez que o projeto esteja em execução, 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 relatórios 
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 repositório central disponível a todos. 
PR: Maria, explique um pouco o que seria necessidades x 
desejos. 
MC: OK. Nos casos em que existam divergências entre as 
necessidades dos diferentes stakeholders, estas devem ser 
solucionadas em favor do cliente do projeto. 
Expectativas de stakeholders são mais ambíguas do que 
requisitos e podem estar “implícitas” de forma intencional ou não 
intencional. As expectativas dos stakeholders devem ser 
identificadas, documentadas e gerenciadas ao longo do ciclo de 
vida do projeto, da mesma forma que os requisitos. 
136 
 
DS: Puxa, apesar do gerenciamento de stakeholders não ser uma 
das nove áreas de conhecimento, ela exige do gerente de 
projetos o mesmo esforço e dedicação! 
MC: Isso é verdade. Mas, mesmo assim, como eu acabei de dizer, 
o gerenciamento de stakeholders encontra-se presente em todas 
as fases, ou seja, no início do projeto, no seu planejamento, na 
execução e no encerramento. 
SB: Gostei muito desta nossa conversa. Maria, você não teria 
nenhum livro ou texto que pudéssemos ler para ajudar a 
complementar esse assunto? 
MC: Na realidade, saiu recentemente um artigo sobre 
gerenciamento de stakeholders. Tenho uma cópia aqui no meu 
computador. Vou encaminhá-la para vocês, pois julgo importante 
essa leitura. 
Este artigo contempla o que acabamos de conversar. Tenho 
certeza de que vocês irão gostar muito. (LEITURA 
OBRIGATÓRIA: TEXTO “Administrando Conflitos em Projetos, via 
Gerenciamento de Stakeholders”: próxima lição) 
PR: Vamos colocar a mão na massa. Temos muito trabalho pela 
frente. 
SB: Maria, quando iremos conversar sobre a fase de 
encerramento do projeto? 
MC: Primeiro leiam o texto que indiquei e amanhã retornaremos 
com esse assunto. 
SB: OK. Vamos ao trabalho. 
 
Administrando Conflitos em Projetos, via Gerenciamento 
de Stakeholders 
Artigo publicado na Revista Mundo PM: número 16: Ago/Set 2007 
 
Flávia Dias Moreira: Administradora: ESHO: Grupo Amil 
Cristiane Jourdan: Médica especializada em Endocrinologia e 
bacharel em Direito: Amil Assistência Médica Internacional 
Eduardo Andrade: Administrador Andrade: Seaworld 
Mariela Baraibar: Bacharel em Comunicação Social: Universidad 
DeLa Republica Del Urugay 
Arthur Macedo: Engenheiro Civil: Amil Assistência Médica 
Internacional 
 
Abstract 
137 
 
 
Este artigo apresenta o importante papel do gerenciamento dos 
stakeholders e seus interesses para o sucesso do projeto. Trata 
as diversas habilidades do gerente de projetos no relacionamento 
com os stakeholders, como: identificação e conhecimento dos 
interesses dos stakeholders; estratégia de comunicação junto aos 
envolvidos; desenvolvimento, motivação e apoio ao principal 
stakeholder: a equipe; administração dos conflitos de interesse; e 
a importância da inteligência emocional associada às habilidades 
técnicas do gerente. 
Os projetos surgem para atender às necessidades do mercado, 
legislação, visão da empresa e são demandados essencialmente 
pelo cliente/patrocinador. Este quando fica satisfeito significa uma 
combinação vitoriosa, indicando que o produto/serviço foi 
entregue no valor e tempo certos e de acordo com as 
expectativas. Porém, o cliente é um dos stakeholders dentro dos 
vários envolvidos no projeto e, como os demais, requer 
relacionamento específico de acordo com seus interesses, 
influência e expectativas. 
Os stakeholders são os envolvidos que influenciam o projeto (ou 
são 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, são 
elas: 
• Pouca atenção dedicada ao melhor entendimento dos 
envolvidos sobre o projeto durante a análise de viabilidade e 
planejamento. 
• Desconhecimento dos envolvidos e de seus interesses por parte 
do gerente de projeto. 
• Porvezes, os gerentes de projetos não possuem habilidades 
em comunicação, motivação, negociação, administração de 
conflitos e de liderança. 
O gerenciamento de stakeholders abrange a identificação, 
análise, desenvolvimento de ações, comunicações e interfaces 
com cada um dos envolvidos no projeto. 
 
138 
 
O sucesso do projeto depende da participação de suas partes 
interessadas e, por isso, é necessário assegurar que suas 
expectativas e necessidades sejam conhecidas e consideradas 
pelo gerente de projeto. 
 
Os interesses e os objetivos 
 
Podemos considerar como um dos fatores determinantes para o 
sucesso ou fracasso de um projeto, o relacionamento que o 
Gerente do Projeto tem com seus stakeholders, procurando 
sempre atender a todos sem perder de vista o objetivo final do 
projeto. 
Segundo HELDMAN (2006), “stakeholders são aqueles que têm 
algo a ganhar ou a perder com a implementação do projeto e, 
como tal, têm diferentes interesses, necessidades e objetivos”. 
Portanto, além de cuidar para que tudo saia conforme o 
combinado, atendendo às expectativas do cliente, o Gerente de 
Projeto tem como uma de suas principais missões equilibrar os 
diversos interesses dos stakeholders. 
No relacionamento com os stakeholders, o gerente de projeto 
deve traçar um plano baseado nas seguintes tarefas: 
• Identificar quem são 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 avaliação, ou SAM: Stakeholders 
Assessment Map, de ELLIOT (2001), para conhecer melhor os 
interesses, objetivos, grau de influência e responsabilidade de 
cada envolvido. 
• Certificar-se da documentação e da comunicação do projeto, 
identificando a melhor forma de atuar e trocar informações de 
acordo com as necessidades de cada envolvido. 
• Certificar-se de manter a informação organizada e filtrada. É 
fundamental ter cuidado com o excesso de informação. Ninguém 
gosta de ter de ler um relatório inteiro para verificar um único item 
de seu interesse. 
O mapa de avaliação de stakeholders deve conter as seguintes 
informações, conforme tabela 1: 
139 
 
• Quem são os stakeholders-chave? 
• Quais são seus objetivos, metas, motivações e interesses? 
• Qual o poder de influência de cada um na organização? 
• Qual a importância e o impacto de cada um no projeto? 
• Quais os papéis e responsabilidades de cada um no projeto? 
• Como trabalhar com cada um buscando o sucesso do projeto 
(sintonia fina)? 
• Quais serão as estratégias adotadas na relação de cada 
stakeholders-chave? 
 
Tabela I: Mapa de avaliação dos stakeholders. 
Fonte: Use these two forms to analyse your stakeholders, de 
Elliot (2001). 
 
Essas informações podem ser verificadas junto à equipe do 
projeto, ao sponsor, documentação histórica, relatórios, atas, 
apresentações, observações, network, entre outros, e exige 
fundamentalmente habilidade emocional na busca pela melhor 
forma de se relacionar e administrar os envolvidos no projeto. 
 
A importância da comunicação no relacionamento com os stakeholders 
 
Além de identificar e conhecer os interesses, objetivos e 
motivações de seus stakeholders, o gerente de projetos precisa 
administrar as comunicações para satisfazer às necessidades 
das partes interessadas no projeto e resolver problemas com 
elas. 
Criar uma matriz de relatórios com critérios de distribuição de 
informações, ou SRM: Stakeholders Relationship Management de 
ELLIOT (2001), é fundamental para não se transmitir informações 
nem a mais nem a menos. 
140 
 
A matriz de relatórios deve conter as seguintes informações, 
conforme tabela 2: 
• Relatórios a receber (área de interesse); 
• Volume/nível de detalhe; 
• Melhor formato; 
• Freqüência; 
• Mecanismo de entrega. 
 
Existem outras ferramentas tradicionais e vastamente conhecidas 
que podem ajudar a traçar planos de comunicação, como, por 
exemplo, a análise SWOT: Strenghts, Weaknesses, 
Opportunities, Threats: dos envolvidos, que ajuda a identificar os 
pontos fortes, fracos, as ameaças e oportunidades daquele 
stakeholders perante o projeto. 
Associado às habilidades técnicas 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 
comunicação é uma das partes mais importantes em todo projeto 
e o gerente de projeto é o responsável por fazer o projeto 
acontecer, mantendo a comunicação transparente, precisa e 
fluida. 
Fluidez nesse caso significa troca de informações e garantia de 
que os stakeholders não terão dificuldade de entendimento das 
mensagens recebidas e enviadas (feedbacks). O uso de uma 
terminologia comum é fundamental para o gerenciamento das 
comunicações em um projeto. 
Segundo COUTO (2002), toda comunicação possui cinco 
elementos básicos: São eles: 
• Emissor: é quem emite uma informação, é o responsável para 
que as informações cheguem ao receptor de uma forma 
adequada, para este entendê-las corretamente. 
141 
 
• Receptor: é a pessoa a qual a mensagem é enviada. As 
informações são filtradas pelos receptores, por meio do 
conhecimento que têm do assunto, influências culturais, idioma 
emoções, gestos, etc. 
• Mensagem: é a informação 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 interpretação das mensagens 
enviadas e recebidas, a comunicação 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 apresentação e transmissão a adotar. 
A habilidade de comunicar não está só em saber transmitir e 
codificar a mensagem corretamente, mas também em saber 
ouvir. 
A comunicação pode ser formal ou informal, oral ou escrita, ou 
até corporal (a comunicação não-verbal compõe mais da metade 
da comunicação humana), mas apesar da comunicação oral ser 
mais fácil que a escrita, esta é mais adequada para transmitir 
mensagens complexas, minuciosas e a muitas pessoas, 
permitindo-se revê-las, ficam inesquecíveis. 
 
Administrando os conflitos 
 
O conflito é uma divergência, formada por idéias, objetivos e 
relacionamento e personalidades diferentes, que cria uma 
situação de oposição. Seja como colaborador, supervisor ou 
subordinado, o ambiente de trabalho e as diferentes 
metodologias e formas de produção de bens e serviços, bem 
como interesses pessoais, incrementam a possibilidade de atritos 
de diversas naturezas. 
Os conflitos estão diretamente relacionados a pessoas e crescem 
de acordo com expectativas e objetivos particulares, sendo 
agravados caso não estejam em sintonia com os objetivos do 
grupo e do projeto. Também influem diferentes tipos de 
personalidade, formação técnica e culturas organizacionais. 
Entretanto, os conflitos não são unicamente prejudicais. Certas 
142 
 
situações podem inclusive, estimular a busca de soluções 
criativas para muitos problemas, proporcionando ganhos tanto 
para o projeto quanto para os indivíduos pessoalmente, seja na 
forma de crescimento profissional seja na melhoria nos 
relacionamentos. 
Os conflitos são benéficos quando estabelecem um desafio para 
a busca de soluções, motivam grupos a resolver problemas em 
conjunto, aumentam o conhecimento após a experiência, 
melhoram a iniciativa dos integrantes do grupo e facilitam o 
alcance do objetivo comum. Ao contrário, quando uma situação 
cria um ambiente de tensão e pressão excessiva, tornando o 
trabalho improdutivo, distorce o comportamento dos indivíduos 
gerando sensação de perda de confiança e permite 
demonstrações de poder desnecessárias, o conflito é prejudicial. 
Um dos grandesdesafios do gerente do projeto é saber identificar 
a existência de conflitos e implementar as técnicas 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 várias 
origens” e classificamos nos seguintes tipos: 
 
• De ordem pessoal. 
• De relacionamento com outros indivíduos. 
• De ordem organizacional. 
Qualquer pessoa possui condições internas que, em dado 
momento, influenciam seu desempenho e suas reações, e podem 
fazê-las entrar em choque com seus pares. 
Questões de ordem pessoal, psicológicas, de difícil identificação, 
são problemas complexos de resolver. Além de prejudicar os 
relacionamentos, influenciam também na vida diária da pessoa, 
interferindo na capacidade de concentração, no raciocínio, na 
motivação e, principalmente, no equilíbrio emocional. 
Os conflitos de relacionamento com outros indivíduos ocorrem 
por opiniões antagônicas, falhas na comunicação, problemas de 
personalidade ou objetivos conflitantes. Todos têm necessidades 
diferentes, entretanto, o reconhecimento do trabalho, a 
valorização como indivíduo, a auto-estima, o respeito e a 
143 
 
segurança são características desejadas por todos e muito 
necessárias para a manutenção do equilíbrio. 
Preservar valores e evoluir, profissional e pessoalmente, é 
determinante para o ser humano. Entretanto, os valores 
constituídos através do desenvolvimento pessoal, não adiantam 
se, em conjunto a eles, o indivíduo não possuir a capacidade de 
aceitar diferenças e encontrar caminhos satisfatórios de 
convivência com os outros. 
Em complemento ao estado pessoal interno e as características 
individuais, muitas vezes a razão dos conflitos está relacionada a 
fatores ambientais. Novas diretrizes e políticas organizacionais, 
reestruturações, escassez de recursos, choques culturais, 
influências políticas, entre outros, são motivos muito encontrados. 
Objetivos conflitantes entre grupos, departamentos e pessoas, 
sejam de liderança ou não, criam e aumentam situações de 
tensão que exigem a adoção de técnicas específicas de 
administração de conflitos. 
A administração de conflitos permite que uma solução seja 
encontrada e implementada, tanto para um simples problema ou 
para causas complexas. 
De forma geral, o enfoque deve ser sempre o da solução. Atuar 
de forma positiva, buscando o equilíbrio no resultado entre as 
partes é fundamental para a conservação do estado de confiança 
da equipe e manutenção dos objetivos do projeto. 
O gerente de projetos é, além de um coordenador, um 
negociador que deve ter grande capacidade de comunicação, 
uma vez que, boa parte do seu tempo será empregado nessa 
tarefa. 
Saber identificar características pessoais, comportamentos 
situacionais e situações 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 Conexão, 
Legítimo, de Informação, de Referência ou Especialização e, 
dessa forma, encontrar a solução adequada, é parte fundamental 
das habilidades do gerente de projetos. Ele deverá julgar qual a 
144 
 
melhor alternativa considerando os tipos de comportamento e 
poder variados. 
Além da capacidade acima descrita, dificilmente um gerente de 
projetos poderá desempenhar bem suas funções se não 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 
soluções. Na mesma linha, ter a competência para identificar 
soluções. 
Na mesma linha, ter a competência para identificar cenários, 
possuir conhecimento do assunto e saber se relacionar, são 
habilidades que permitirão ao gerente a correta inserção no 
contexto do problema. Para identificar os cenários, é necessário 
ter a capacidade de interpretar questões de ordem pessoal, 
psicológicas, familiares, culturais e econômicas. Conhecer o que 
está sendo negociado facilitará a distinção entre o que é bom e o 
que não é como alternativa. Em complemento, e como fator 
crítico para o êxito na negociação, está o relacionamento 
interpessoal. 
A fusão entre a habilitação técnica, as competências de 
comunicação, negociação e as técnicas de administração de 
conflitos, irá proporcionar a identificação das melhores 
alternativas e a conclusão das negociações através da adoção da 
melhor solução, de forma convincente e satisfatória, apoiada em 
argumentos legítimos e coerentes. 
 
A equipe: o principal stakeholder 
 
O principal stakeholder em todos os projetos é a equipe envolvida 
na execução do projeto. Todo projeto deve se iniciar pela perfeita 
compreensão do seu escopo, ter uma boa idéia do mercado onde 
se insere e conhecer em detalhes o papel, as características e as 
responsabilidades da equipe envolvida. 
Equipe é um conjunto de pessoas diferentes, com personalidades 
diversas, motivadas a uma missão e objetivos comuns por um 
líder. Cabe ao gerente de projeto assumir este papel de liderança 
junto à equipe. 
145 
 
A formação da equipe de projeto deve considerar as 
competências individuais necessárias para o desenvolvimento 
das atividades e alcance das metas. Os indivíduos da equipe 
devem ser escolhidos com base em sua capacidade reconhecida 
de exercer a função necessária, 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 
multiplicação das capacidades individuais e a garantia de um 
projeto bem-sucedido. 
O gerente de projeto exerce um papel fundamental de liderança. 
Segundo COUTO (2002), “ele é responsável pelos aspectos da 
administração das personalidades e dos egos envolvidos” e, por 
isso, deve atentar para os diversos aspectos fundamentais ao 
sucesso do projeto: 
• Motivação. Um dos pontos cruciais do papel de liderança é a 
motivação do time. Somente com uma equipe motivada é que se 
completa um objetivo. Pessoas motivadas executam trabalhos de 
qualidade e mantêm um compromisso com o resultado. O 
gerente de projetos deve possuir a capacidade de percepção 
para medir o grau de envolvimento dos integrantes, assim como o 
resultado dos seus trabalhos. 
O acompanhamento e avaliação da consecução das ações do 
projeto de acordo com as responsabilidades específicas de cada 
integrante passam necessariamente pela sensibilidade do 
gerente em perceber, assimilar e reconhecer o grau de motivação 
e de resultados gerados pela equipe. 
• Comunicação. Cabe ao líder da equipe estabelecer e gerenciar a 
comunicação, de forma clara e transparente. As informações 
devem fluir livremente na equipe, que deve se sentir informada e 
com um bom canal de comunicação. Manter um bom canal de 
comunicação com informações de tudo que acontece e das 
modificações porventura realizadas é um feedback esperado no 
trabalho de equipe. Cabe no item comunicação, a gestão do 
conhecimento do projeto para a formação de quadros 
capacitados, incrementando os ativos intangíveis da organização 
e facilitando a execução do projeto. 
• Ambiente. O ambiente de trabalho é também considerado um 
fator decisivo para o sucesso de um projeto. Deve ser percebido 
146 
 
pela equipe um ambiente flexível, agradável, criativo e 
incentivador das realizações pessoais. A questão do clima 
organizacional e conseqüentemente do ambiente de projetos e 
fundamental para o aumento da melhoria da qualidade do 
trabalho e eficiência das ações-chave do projeto. Quando um 
indivíduo se sente mais confortável 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. 
Criarmecanismos de motivação e desenvolvimento da equipe, 
manter um canal de comunicação em ambas as direções, cuidar 
do ambiente de trabalho são atitudes que contribuem para a 
manutenção de uma equipe engajada no sucesso da empreitada. 
 
A inteligência emocional no relacionamento com os stakeholders 
 
Cada vez mais, não somente no campo profissional, mas também 
no pessoal, a inteligência está associada ao controle das 
emoções. A capacitação técnica não é mais suficiente para que 
alguém desempenhe suas funções plenamente. 
O melhor desempenho das habilitações técnica, humana e 
conceitual está condicionado também à capacidade de controle 
das emoções. A competência 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 satisfatória com outras pessoas e com o ambiente. 
Controlando melhor os impulsos emocionais, será possível ser 
melhor sucedido profissionalmente e como indivíduo, 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 próprias emoções 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 questão principal e da sua correspondente solução. A busca 
por resultados finais favoráveis através do entendimento do 
147 
 
contexto e como cada decisão afetará as partes, proporcionará o 
entendimento real da questão e a identificação da melhor 
proposta. 
Além disso, empresas com maior grau de maturidade técnica em 
gestão de projetos estão se voltando à gestão comportamental 
em vez da gestão técnica, em que a liderança situacional, de 
HERSEY e BLANCHARD (1986), está em voga. Segundo 
HELDAMN (2006), “a característica fundamental para o sucesso 
na gestão de projetos é a tolerância em relação a eventos 
externos e tolerância em relação à personalidade das pessoas”. 
Na liderança situacional, a empatia é “motor” das relações com 
os stakeholders, pois nela o gerente de projeto lida com situações 
diferentes das lideranças funcionais. 
Seguem alguns exemplos de situações: 
• Relacionamentos de múltipla subordinação. 
• Escassez de autoridade real. 
• Não participação na avaliação de desempenho dos funcionários. 
• Posição temporária devido a natureza do projeto. 
• Posição hierárquica 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 
questões comportamentais, sendo elas; desmotivação dos 
membros da equipe; relacionamentos interpessoais negativos, 
baixa produtividade, comunicações truncadas e ausência de 
comprometimento com os objetivos do projeto. 
O gerenciamento pró-ativo dos stakeholders aumenta a 
probabilidade do projeto não desviar de seu curso por causa de 
problemas não resolvidos dos mesmos, além disso, aumenta a 
capacidade das pessoas operarem em sinergia e limita 
interrupções durante o projeto. 
Ter a capacidade de minimizar conflitos e encontrar alternativas 
positivas e viáveis para todos é o desafio constante. Dessa 
forma, habilidades como comunicação, inteligência emocional, 
administração de conflitos, negociação, motivação e 
148 
 
desenvolvimento da equipe são requisitos básicos exigidos ao 
bom gerente de projetos. 
Encerramento do Projeto 
 
No dia seguinte 
 
MC: Bom dia a todos! E aí, gostaram dos textos que eu passei 
para vocês? 
DS: Como disse o Pedro e pelas nossas conversas, temos muito 
trabalho pela frente. Os textos ajudaram muito a clarear algumas 
dúvidas. 
PR: Para mim, que estava bem receoso, achei a leitura muito 
produtiva. 
SB: OK. Tenho que admitir. Todo este assunto é muito 
interessante. Muita coisa para fazer, mas sem dúvidas irá 
contribuir muito para o nosso dia-a-dia. Vamos ao trabalho. 
DS: Até que enfim, Been. Você agora percebeu a importância 
deste processo. 
PR: Antes tarde do que nunca. 
149 
 
DS: Elaboramos, planejamos, executamos e avaliamos projetos. 
E agora? O que falta conhecermos sobre gerenciamento de 
projetos? 
MC: Lembra-se do ciclo de vida? 
DS: Sim. Concepção, Planejamento, Execução e Controle, bem 
como Encerramento. 
MC: Então 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 
formalização do aceite do projeto e são encerrados os contratos 
gerados durante sua execução. Outro ponto importante consiste 
da medição e análise dos resultados após seu encerramento. 
SB: Acabou o projeto. Ótimo. Toda a documentação gerada, 
todos os problemas solucionados, o que fazemos com essas 
informações? 
MC: Registramos e documentamos como Lições Aprendidas. 
PR: Mas como fazemos tudo isso? 
MC: Vamos com calma. Uma coisa de cada vez. 
 
1º – Encerramento de contratos (encerramento administrativo) 
 
SB: Como dizem os mineiros “vamos comer o boi aos bifes”. 
PR: Been, não é hora de brincadeiras. 
MC: Não esquenta, Rocha. Como eu estava dizendo, esta é a 
última etapa do gerenciamento de projetos. É uma etapa muito 
simples, no entanto é uma etapa muitas vezes esquecida ou 
negligenciada. 
PR: Como assim esquecida?! 
MC: A etapa final da condução de um projeto é geralmente 
negligenciada pela maioria das empresas. Ao aproximar-se o 
término dos trabalhos, os membros da equipe vão sendo 
desligados e alocados em outras atividades; além disso, existe a 
tendência natural de “relaxamento” com a falta de exigências de 
prazos que a etapa de execução vinha demandando. 
150 
 
Muitos gerentes de projetos entendem que, após a entrega do 
projeto, este já está encerrado, e que mais nada precisa ser feito. 
Não existe uma cobrança formal para o encerramento do projeto. 
PR: O que é o encerramento administrativo? 
MC: O encerramento administrativo consiste em documentar os 
resultados do projeto para formalizar a aceitação do produto do 
projeto pelos patrocinadores ou clientes. Isso inclui: 
• a coleta dos registros do projeto, garantindo que eles reflitam as 
especificações finais; 
• análise do sucesso, efetividade do projeto; 
• lições aprendidas e o arquivamento dessas informações para 
uso futuro. 
As atividades do encerramento administrativo não devem ser 
retardadas até a conclusão do projeto. Cada fase do projeto deve 
ser apropriadamente encerrada para assegurar que as 
informações úteis e importantes não sejam perdidas. 
DS: Você poderia explicar melhor? 
MC: Claro. Vou tratar este assunto apresentando os 
procedimentos desta fase. Acredito que assim o entendimento 
seja melhor. 
Em primeiro lugar, temos o Procedimento de encerramento 
administrativo. Esse procedimento consiste das atividades para 
encerrar o projeto internamente na organização. 
PR: Quais são essas atividades? 
MC: Trata-se da Documentação da medição do desempenho, 
Documentação do Produto e outros registros inerentes ao projeto. 
DS: Dê alguns exemplos. 
MC: Temos então: 
1. Documentação da medição do desempenho: toda a documentação 
produzida para registro e análise do desempenho do projeto, 
incluindo os documentos de planejamento que estabeleceram a 
estrutura da medição do desempenho, deve estar disponível para 
revisões durante o encerramento administrativo. 
2. Documentação do produto: os documentos produzidos para 
descrever o produto do projeto (planos, especificações, 
documentação técnica, plantas, arquivos eletrônicos, etc.) devem, 
também, estar disponíveis para revisões durante o encerramento 
administrativo. 
3. Outros registros do projeto: os registros devem incluir 
151 
 
correspondências, memorandos, relatórios e outros documentosque descrevem o projeto. Essas informações devem, na medida 
do possível, ser mantidas de modo organizado. Relatórios 
formais do status do projeto e/ou pendências. E também 
Apresentações do Projeto, onde a equipe do projeto fornece 
informações formalmente e informalmente, para alguns ou todas 
as partes envolvidas no projeto. A informação é relevante para as 
necessidades de audiência e o método de apresentação 
apropriado. 
DS: Esta documentação reunida compõe o encerramento 
administrativo. 
MC: Exatamente. Mas temos também o Procedimento de 
encerramento de contratos, que aborda os termos e condições 
para finalizar os contratos de fornecimento realizados durante o 
projeto. 
Para os projetos nos quais se faz necessária a aquisição de bens 
e serviços e, portanto, o gerenciamento de contratos entre cliente 
e fornecedor, é também de suma importância o adequado 
encerramento do contrato. 
PR: O encerramento de contratos em gerenciamento de projetos é 
diferente do encerramento no caso de aquisições nos nossos 
processos internos? 
MC: Na verdade, é basicamente a mesma coisa. Mas alguns 
aspectos devem ser levados em conta. 
PR: Quais aspectos? 
MC: São basicamente os seguintes: 
• a documentação para encerramento do contrato; 
• Nota de Rescisão (quando for o caso), 
• verificação de conformidade com procedimentos; 
• auditoria de aquisições; 
• aceitação e pagamento final; e 
• arquivo do contrato. 
DS: Você poderia explicar um pouco mais? 
MC: Vamos lá. 
(O texto a seguir foi extraído do seguinte livro: XAVIER, Carlos Magno da Silva et. 
al. Gerenciamento de Aquisições 
em Projetos. Rio de Janeiro: Editora FG, 2007) 
 
 
A documentação para encerramento do contrato 
152 
 
São documentos necessários para o encerramento do contrato, 
sob as perspectivas tanto do contratante quanto do contratado. 
São exemplos de documentos usados no encerramento de 
contratos: 
• emitidos pelo contratante – relatório de encerramento do 
contrato e termo de aceite; 
• emitidos pelo contratado – atestado de inexistência de 
reivindicações e relatório de encerramento do contrato. 
 
Nota de rescisão 
 
A nota de rescisão é um instrumento emitido unilateralmente pela 
parte contratante que se sentiu prejudicada, independente de 
notificação judicial ou extrajudicial. Ela é, portanto, uma 
notificação para cancelar o contrato, decorrente da quebra do 
mesmo. 
 
Verificação de conformidade com procedimentos 
 
É necessário verificar se os procedimentos estabelecidos para 
encerramento do contrato sob o prisma administrativo foram 
observados. Por exemplo, no caso do cliente, não se deve 
proceder ao pagamento final do fornecedor se este não houver 
concluído todos os procedimentos administrativos estabelecidos 
no contrato, tais como: devolução de ativos de propriedade do 
contratante, encerramento e ajustes com subcontratados e 
adequada disponibilização de aspectos considerados propriedade 
intelectual. 
 
Auditoria de aquisições 
 
Auditorias de aquisições são uma análise estruturada de todos os 
processos de aquisições desde a decisão de contratar ou não até 
o encerramento de contratos, visando à identificação de lições 
aprendidas e à correção de procedimentos. São identificados os 
pontos positivos e os negativos (lições aprendidas), que poderão 
ser aplicados na aquisição de outros itens do projeto em questão 
ou até em um novo projeto. 
 
Aceitação e pagamento final 
153 
 
 
O cliente procede à aceitação formal dos produtos ou serviços 
objeto do fornecimento e efetiva o pagamento final ao fornecedor. 
É verificado se todos os produtos e serviços constantes do 
escopo do contrato foram entregues. 
O fornecedor, após o recebimento da última fatura, deve fazer a 
liberação de seguros-garantia ou carta de crédito. 
 
Arquivo do contrato 
 
A equipe do projeto deve manter uma série de pastas, ou um 
arquivo, como referência do contrato, com finalidade de facilitar 
auditorias ou revisões. A pasta e o índice representam a atividade 
de um contrato com um fornecedor. O índice mínimo para uma 
pasta do contrato é: 
– RFP (Request for proposal) – documento de solicitação de 
cotação; 
– Contrato; 
– Cronogramas; 
– Alterações solicitadas e aprovadas; 
– Documentações técnicas; 
– Aditivos ao contrato; 
– Ordens de trabalho; 
– Aprovação dos deliverables; 
– Correspondências do contrato; 
– Avaliações do contratado; 
– Relatórios de desempenho; 
– Cópias das faturas e pagamentos; 
– Resultados de fiscalizações. 
 
A destruição dos arquivos relacionados com o fornecimento de 
produtos e serviços só deverá ser efetivada pelas empresas 
contratantes depois de ultrapassado o período de garantia 
contratual ou legal. Uma vez reivindicada a responsabilidade de 
qualquer das partes neste particular, elas poderão se defender 
utilizando todos os elementos e documentos gerados no âmbito 
da referida contratação. 
SB: Nossa, isto é que é explicação, o resto é bobagem. 
MC: Encerramento administrativo, Encerramento de Contratos... 
Estou sentido falta do Encerramento junto ao nosso cliente. Estou 
certa? Falta essa etapa? 
154 
 
MC: É a minha próxima explicação. 
 
2º - Formalização do encerramento 
 
SB: Você parece que lê nossos pensamentos, Maria. 
MC: Não é isso. Apenas as explicações seguem uma linha de 
raciocínio, em que as etapas são complementares. 
PR: Been, deixa a Maria continuar as explicações. 
SB: Está bem. Eu deixo. 
MC: Todo projeto tem um cliente, que é a pessoa ou entidade que 
demandou o projeto. Dessa forma, para esse cliente, a fase de 
conclusão é uma das mais importantes, uma vez que é nela que 
se dará a “entrega final” dos produtos e serviços gerados. 
A fase de encerramento do projeto é conduzida de forma que os 
produtos e serviços constantes do escopo delineado sejam 
disponibilizados para o cliente, sendo que esse momento é 
acompanhado da caracterização e oficialização da conclusão e 
aceitação do projeto. 
DS: A formalização do encerramento acontece somente por 
ocasião do término do projeto? 
MC: Não. 
SB: Como não?! 
MC: Um contrato pode ser encerrado, não só quando termina a 
execução, mas das seguintes formas: 
• em primeiro lugar, pelo término das atividades estabelecidas 
contratualmente (terminação); 
• pelo acordo mútuo entre as partes; ou 
• pela não-observância das obrigações contratualmente 
estabelecidas. 
 
DS: Maria, eu entendo que o encerramento do contrato aconteça 
pelo término das atividades contratadas, mas os demais 
encerramentos, como se caracterizam? 
MC: Vou explicar como se dá todos os encerramentos. 
(O texto a seguir foi extraído do seguinte livro: XAVIER, Carlos Magno da Silva et. 
al. Gerenciamento de Aquisições 
em Projetos. Rio de Janeiro: Editora FG, 2007) 
155 
 
 
O término das atividades estabelecidas no contrato, também chamado 
de terminação, se caracteriza pelo encerramento natural do 
contrato, em decorrência do término de todas as obrigações ali 
estabelecidas. As partes satisfeitas acertam as pendências finais 
e dão-se quitações mútuas para nada mais reclamarem uma da 
outra, seja a que título for, por si, seus herdeiros e sucessores. 
Nessa oportunidade, o cliente emite a aceitação definitiva do 
fornecimento e paga a integralidade do preço. Assim, se o 
fornecedor tiver apresentado qualquer tipo de garantia (por 
exemplo, uma caução bancária), esta retorna para o seu 
patrimônio, ou parte dela é liberada, ficando apenas um 
percentual para dar cobertura à garantia que ultrapassa o prazo 
do contrato e se estende até o término do período e vigência ali 
estabelecido. A situação se caracteriza pelo desempenho 
satisfatório das partes, que se configura pelo fiel cumprimento de 
todas as condições contidas no escopo do trabalho. 
O acordo mútuo entre as partes, também chamado de resilição, é 
a condição que envolve a vontade de ambas as partes na 
extinção do contrato e que abrange não só a terminação, mas a 
156 
 
resolução. São situações em que as partes podem concordar em 
encerrar o contrato,mesmo que os objetivos iniciais não tenham 
sido atingidos. Nessa hipótese, as partes contratantes acertam a 
forma de conclusão dos trabalhos pendentes, o recebimento de 
parcelas devidas e o período predeterminado, quando elas se 
obrigam a dar total quitação para as pendências cumpridas. 
Neste caso, o cliente poderá contratar a finalização dos serviços 
junto a terceiros, não podendo o ex-fornecedor exigir qualquer 
indenização, seja a que título for. 
A não-observância das condições no contrato, ou Resolução e 
Rescisão, efetivam-se de forma unilateral e independente de 
notificação judicial ou extra-judicial, gerando, como 
conseqüência, o direito da parte prejudicada de exigir da outra o 
pagamento de indenização por danos morais e/ou materiais. 
Resolução é o evento que resolve o contrato em decorrência do 
descumprimento de suas cláusulas e condições, porém 
estabelece um prazo de aviso prévio para que as atividades em 
andamento sejam concluídas. Rescisão é a ruptura do ajuste por 
interesse de uma das partes, por descumprimento das 
obrigações pela outra. 
 
PR: Maria, existe algum modelo ou formulário padrão para 
utilização na formalização do encerramento do contrato? 
MC: Eu expliquei, de forma genérica, a formalização 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 vocês verem. 
157 
 
 
158 
 
3º - Documentação das lições aprendidas 
 
SB: Então, pela lógica, temos agora que documentar tudo o que 
ocorreu com o nosso projeto? 
MC: Isto mesmo, Been. Agora é hora de registrarmos toda a 
aprendizagem obtida no processo de realização do projeto. Esse 
documento é também chamado de registro das lições aprendidas. 
PR: Como fazemos isso? 
MC: É simples. Como disse agora mesmo, é muito importante que 
“Cada fase do projeto deve ser apropriadamente encerrada para 
assegurar que as informações úteis e importantes não sejam 
perdidas”. Dessa forma já estamos armazenado as informações 
para o relato final. 
A teoria diz que documentar lições aprendidas é uma atividade 
importantíssima durante qualquer projeto. Qualquer gerente de 
projeto concordará com isso, mas nem sempre esta atividade é 
realmente executada com a seriedade necessária. 
DS: Sendo um aspecto tão positivo, por que isso acontece? 
MC: É fácil entender porque as lições aprendidas são muitas 
vezes deixadas de lado: 
• Pressões 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 execução e controle 
é mais cobrada, mas, depois de o produto ser entregue, existe 
um relaxamento natural. 
• Mudança de foco ao terminar um projeto: as pessoas e 
organizações acabam mais concentradas no próximo projeto do 
que no fechamento correto do projeto anterior. 
• Falta de interesse da alta gestão neste tipo de documentos. 
• Problemas culturais na empresa: levam o gerente a acreditar 
que documentar lições aprendidas é uma perda de tempo, já que 
não terá verdadeira influência sobre os próximos projetos da 
organização. 
 
SB: Nós sabemos que isso não é verdade. Pelos princípios da 
qualidade, toda documentação é importante para rastreamentos e 
confiabilidade das informações. É 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 nós, da equipe de projeto, não deixar que isso 
159 
 
ocorra e efetivamente trabalhar para uma boa documentação das 
nossas atividades. 
PR: Para mim, eu entendo que independente de todos esses 
fatores, o gerente de projeto deve entender que as lições 
aprendidas são uma ferramenta essencial para seu crescimento 
profissional e para a melhoria contínua da organização. 
SB: Falou o filósofo Rocha. Muito bom. 
DS: Been, não começa. 
MC: Vejo que vocês estão bem afinados com o nosso propósito. 
Resumindo o que acabamos de falar, o registro das lições 
aprendidas é muito mais do que um documento para cumprir a 
formalidade do projeto. São as informações que permitirão que os 
erros passados não se repitam e os acertos possam ser feitos 
novamente. 
DS: Por isso é importante registrar tanto as boas quanto as más 
experiências do projeto. Esses registros ajudarão a moldar as 
atividades e controles dos projetos futuros. 
MC: Isso mesmo. 
PR: Qual a melhor forma de fazermos isso? 
MC: Segundo Luiz de Paiva, Consultor em Gerenciamento de 
Projetos, a forma de fazer a documentação de lições 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, não possuem 
uma forma única de criar esses registros. Cabe ao gerente de 
projeto tomar a iniciativa para criar algo que seja: 
• útil: se a informação não ajudará a empresa, equipe e gerente 
nos próximos projetos, provavelmente não vale a pena registrá-la. 
• prático: a forma de registro deve ser simples, ou a burocracia 
tornará difícil o acompanhamento das lições aprendidas. 
• compreensível: é importante que o gerente lembre que as 
informações são para todos e que não deve cometer o erro de 
documentar as informações de tal forma que somente ele 
compreenderá. 
DS: Na nossa metodologia, temos algum modelo que devamos 
seguir? 
MC: Temos, sim. Nesse modelo, avaliamos as áreas de 
conhecimento em relação ao projeto executado. 
DS: Como seria esse modelo? 
MC: Aqui está. Nele descrevemos os aspectos positivos e 
negativos em relação a cada item analisado. 
160 
 
 
161 
 
 
PR: Esse modelo vai nos ajudar muito. 
DS: Com certeza. 
 
4º - Análise de indicadores de desempenho 
 
SB: Maria, terminamos ou já falamos de todas as etapas? 
MC: Falamos de tudo. Você está sentindo falta de mais alguma 
coisa? 
SB: Estou, sim. Da análise dos nossos indicadores de 
desempenho. 
MC: Been, muito bem lembrado. Eles também compõem a lista do 
encerramento dos projetos. 
DS: Mas os indicadores não estão contidos no plano de qualidade 
e são avaliados constantemente para realizarmos o ciclo PDCA? 
MC: Isto mesmo, Delma. No entanto, ao encerramos o projeto, é 
necessário apresentar os resultados obtidos através da análise 
desses indicadores. 
PR: Mas existem indicadores específicos para essa análise final? 
MC: Não. Depende de cada empresa. Para o nosso trabalho de 
gerenciamento de projetos, utilizaremos os indicadores de custo, 
prazo e receitas. Assim temos: 
162 
 
 
PR: Esses são os indicadores mais avaliados hoje. 
SB: Sem sombra de dúvidas. 
MC: É isso aí, pessoal. Hora de colocar a mão na massa. 
DS: Já temos alguma demanda específica? 
MC: Temos sim, Delma. 
DS: O que é? 
MC: O Sr. Fortunato quer que elaboremos um Curso sobre 
Gerenciamento de Projetos para divulgação na empresa. E aí, 
vocês aceitam o desafio? 
Todos: Claro que sim. 
MC: Então mãos-à-obra. Primeiro passo? 
SB: Elaboração do projeto para aprovação do Sr. Fortunato. 
MC: Depois? 
DS: Projeto aprovado, é hora de planejarmos. 
PR: Vamos agora executar. 
MC: Isso aí. Vamos depois registrar o nosso trabalho. Parabéns. 
Vejo que entramos em sintonia. 
PR: Parabéns a você, que tanto contribuiu para que 
aprendêssemos a importância deste trabalho. 
DS: Concordo com o Pedro. 
SB: Eu também. 
MC: Obrigada. Então vamos deixar de conversa e começar a 
escrever o nosso primeiro projeto na metodologia da nossa 
empresa. 
 
Bibliografia/Links Recomendados 
 
 VERZUH, Eric. MBA Compacto: Gestão de Projetos. 5ª ed. 
Rio de Janeiro: Campus, 2000. 398 p. 
 DINSMORE, Paul C. Gerência de Programas e Projetos. São 
Paulo: Pini, 1992. 176 p. 
 CLELAND, D. I.; IRELAND, L. R. Gerência de Projetos. Rio 
de Janeiro: Reichmann & Affonso, 2002. 
163 
 
 HARRIS, Simon. Powerful Magic with Gantt-Charts, 
Microsoft Project and Excel. Project Manager Today, [s.l.], [s.n.],p. 
27-29, may 2010. [Apresenta várias 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 não costumam ser explicitadas nos cronogramas e EAPs.] 
 VARGAS, Ricardo V. Gerenciamento de Projetos: 
Estabelecendo Diferenciais Competitivos. 6ª ed. Rio de Janeiro: 
Brasport, 2005. 
 Vargas, Ricardo. Plano de Projeto – 3.ed. Rio de Janeiro: 
Brasport, 2007. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
164