PM Story: Gerenciamento de Projetos na Prática

Prévia do material em texto

1
2
Sobre a autora e a PM Story
A PM Story existe formalmente desde 2006 com a marca D&B Consultoria, especializada em 
soluções e treinamentos na área de gestão. 
Fabiana Bigão Silva é sócia-proprietária da D&B Consultoria e criadora da PM Story. 
Ela é doutoranda em Ciência da Informação (UFMG), Bacharel e Mestre em Ciência 
da Computação (UFMG), Project Management Professional (PMP) e certificada como 
implementadora MPS.BR, equivalente ao CMMI.
Fabiana é professora da Fundação Dom Cabral (FDC) em programas de especialização e 
aperfeiçoamento, professora do IBMEC nos MBAs de Gerenciamento de Projetos, cursos de 
curta duração e de aperfeiçoamento, professora do IEC – Instituto de Educação Continuada 
da PUC Minas – na pós-graduação de Gerenciamento de Projetos, e professora da pós-
graduação em Gerenciamento de Projetos de Software do Instituto de Gestão em Tecnologia 
da Informação (IGTI). Também atuou em coordenações de MBAs em Gerenciamento de 
Projetos.
Junto ao PMI-MG, foi voluntária como professora do curso preparatório para o exame 
PMP. Desde 2006 atua como palestrante em empresas e em diversos Congressos de 
Gerenciamento de Projetos do PMI. Fabiana também é autora de livros e artigos em 
gerenciamento de projetos.
Como consultora, Fabiana atua em empresas no desenvolvimento de processos de 
gerenciamento de projetos e portfólios, na implantação de PMOs, na gestão de requisitos, 
qualidade e medições, bem como em treinamentos customizados in company.
Mais informações sobre a PM Story: 
www.pmstory.com.br
3
Agradecimentos
Sempre utilizei recursos de storytelling em minhas aulas, utilizando vídeos de 
histórias contadas por outras pessoas. A ideia de criar uma animação com a 
minha cara existe há muito tempo, mas os recursos de tempo e especialmente 
financeiros necessários para concretizar a ideia são altos. Muitos me inspiraram 
na elaboração do vídeo e do e-book, e muitos colaboraram ativamente.
Agradeço em primeiro lugar o Lucas Alves e Alexandre Martins da Ideia Clara 
(www.ideiaclara.com). O Lucas fez a animação e edição do vídeo. O Alexandre 
fez todas as ilustrações e fiquei muito feliz ao ver que a Fabig (meu alter ego) era 
uma moça com cara de simpática e principalmente magra. Agradeço ao Julio 
César de Jesus pela gravação do som.
O professor José Finocchio merece um agradecimento muito especial não 
apenas pelo apoio na divulgação da PM Story, como pelas dicas e por me inspirar 
a contar a história de uma maneira muito mais didática usando o PM Canvas.
Agradeço a todos os meus colegas da comunidade de gerenciamento de 
projetos do Twitter. Muitas das frases e ensinamentos que estão na PM Story são 
fruto de interações com esses colegas: Ricardo Viana Vargas, Gerente no Buteco, 
Farhad Abdollahyan, Maurício Cabral, Marcus Gregório, Patrícia Bracco, Marília 
Balbé, Giselle Coelho, Camille Silva, Mário Henrique Trentim, Alexandre Paiva.
Muito do que contém nas histórias são realidades contadas pelos meus clientes, 
e agradeço a oportunidade de ter estado em cada um deles, onde aprendi e 
ensinei gerenciamento de projetos na prática.
Por fim quero agradecer o meu braço direito, Ricardo Avelar Drummond, que 
me ajudou muito com a ideia do novo site, deste e-book, e sempre me apoia nas 
minhas iniciativas profissionais.
4
Sumário
Cap. 1 – Introdução
Cap. 2 - A iniciação do projeto
Cap. 3 – O planejamento do projeto
Cap. 4 – A integração das restrições do projeto
Cap. 5 – A execução e monitoramento do projeto
Cap. 6 – O encerramento do projeto
Cap. 7 – A estrutura organizacional em que o projeto está inserido
Cap. 8 – O sucesso do projeto
Cap. 9 – Conclusões
Referências
5
8
24
36
40
44
45
47
49
50 
5
Capítulo 1 - Introdução
A PM Story surgiu de uma necessidade pessoal, como professora e consultora na área de gerenciamento 
de projetos, de mostrar como é a dinâmica da condução de um projeto de maneira mais prática. Quais 
são as situações que o gerente e a equipe de projetos passa e quais seriam os possíveis comportamentos 
que deveríamos adotar para passar pela tenebrosa ponte que transporta as necessidades e demandas 
não atendidas dos clientes até os benefícios gerados pelas entregas do projeto.
Gerenciar projetos não é fácil e, dependendo da complexidade e tamanho do projeto, não exige técnicas 
sofisticadas e que demandam alto nível de inteligência e perspicácia. O gerenciamento de projetos, 
em geral, é muito mais uma questão de atitude colaborativa, voltada à correta obtenção, organização 
e compartilhamento de informações do que o uso de ferramentas sofisticadas. Dependendo da 
complexidade do projeto, o uso de ferramentas e conhecimento mais sofisticado será essencial, mas a 
grande maioria dos projetos que lidamos não possuem essa necessidade.
A Fabig, protagonista da PM Story, não é nenhum gênio, nem especialista de destaque, mas possui 
características e comportamento necessários à boa condução de um projeto. Em primeiro lugar, ela é 
voltada à entrega, ela se compromete com a missão (a partir do momento em que ela não conseguiu 
fugir dela!), e se preocupa com sua reputação de fazer uma boa entrega. Uma característica muito 
importante é o fato de sempre buscar cooperação de todos os stakeholders. Atualmente a condução 
de projetos deixou de ser uma tarefa de responsabilidade apenas do gerente do projeto e sua equipe e 
passou a contar com o envolvimento e comprometimento de todos. Mas as pessoas não farão isso de 
boa vontade e por iniciativa própria se não foram devidamente envolvidos pelo condutor do projeto. 
A Fabig promove a cooperação na reunião de abertura, no kick-off do projeto, no acompanhamento 
semanal e nos marcos do projeto, junto ao sponsor. Por fim, a Fabig conta com uma certa dose de 
atrevimento. Sim, às vezes ela engole sapos (desde que seja acompanhado de cerveja), mas ela é muito 
bem fundamentada nos planos e compromissos que foram estabelecidos com todos. Com isso, ela usa 
essas informações de maneira útil para cobrar responsabilidades, reportar status, obter aceitações.
6
Uma das coisas que a Fabig faz melhor, dentro da simplicidade do exemplo 
apresentado, é usar a informação como sua aliada na condução dos 
projetos. Em primeiro lugar, a informação é obtida para criar significado 
do projeto, para compreender por que o projeto deve acontecer, os 
benefícios pretendidos e o que é necessário entregar para atingir esses 
benefícios. Nesse momento, é dado sentido ao projeto. Segundo, ela 
constrói conhecimento a cerca do projeto. Isso é feito de forma colaborativa, 
através da interação com todos os stakeholders para entender e registrar 
as informações necessárias para a entrega do projeto com sucesso. É 
nesse momento que o plano do projeto é construído. Existe uma forte 
preocupação da Fabig para que o plano seja real. Isso é demonstrado em 
vários momentos: 
a) Na reunião de abertura através do preenchimento, com a 
participação de todos, do PM Canvas que contém as principais 
informações do projeto.
b) Na interação constante com vários stakeholders durante a 
construção do plano detalhado.
c) Na reunião de kick-off para repassar o plano detalhado e obter o 
comprometimento de todos. Nesse momento, alguns aspectos do 
plano são questionados e ele é ajustado para contemplar todas as 
observações dos envolvidos.
A terceira forma com que a Fabig usava bem a informação é para tomada 
de decisões. Todas as decisões são tomadas com base em fatos e dados. 
O estabelecimento e acompanhamento do plano do projeto de forma 
colaborativa fez reduzir a incerteza e complexidade que envolvem a tomada 
de decisões, que eram orientadas por regras e norteadas por informações 
atualizadas. Isso dava legitimidade ao projeto, e demonstravam um 
comportamento responsável. Os principais momentos em que as decisões 
eram tomadas naPM Story foram:
a) No acompanhamento semanal para verificar o cumprimento do 
plano por parte da equipe, identificar desvios e solucionar problemas.
b) No acompanhamento formal das mudanças, fazendo uma análise 
de impacto antes de aprovar qualquer alteração do plano.
Um desafios que nós, professores e consultores da área de gerenciamento 
de projetos, temos encontrado é conseguir explicar de maneira clara 
a forma de trabalhar com o projeto de modo a nos trazer benefícios a 
partir do bom gerenciamento. Ensinar gerenciamento na prática não é 
fácil. O uso de uma história animada foi um artifício usado para facilitar 
a conversão do conhecimento explícito a cerca de gerenciamento de 
projetos em conhecimento tático. O conhecimento explícito é todo aquele 
conhecimento presente nos livros, vídeos, formalizado em palavras e 
transmitido através de aulas, palestras. O conhecimento tácito está associado 
ao know-how, à experiência, ao sabe fazer, e é muitas vezes difícil de ser 
expressado através de palavras. 
7
No gerenciamento de projetos, existe um desafio muito grande em 
fazer com que os indivíduos internalizem o conhecimento na forma de 
modelos mentais e rotinas de trabalho. O uso de storytelling procura 
afrouxar essa barreira na internalização do conhecimento a partir de uma 
visão compartilhada dos acontecimentos que se passam em uma história.
Esse livro surgiu como apoio à animação PM Story disponível no youtube 
(http://youtu.be/QVEdvQV8GqU). O objetivo do livro fazer um link da 
história apresentada com os conceitos de gerenciamento de projetos 
que se aplicam. Não temos a intenção de entrar em profundidade em 
nenhuma prática do gerenciamento de projetos, mas sim dar a visão de 
cima, a visão do todo, apresentar em linhas gerais a dinâmica da condução 
de um projeto do início ao fim. Esperamos que seja mais um recurso 
didático para o aprendizado de gerenciamento de projetos. 
Boa leitura!
8
Capítulo 2 - A iniciação do projeto
O projeto apresentado pela PM Story iniciou informalmente quando o presidente 
da empresa chamou a Fabig em sua sala, apresentou suas necessidades e 
demandas não atendidas da empresa e a pediu que gerenciasse os esforços para 
ter a nova filial de Viçosa em funcionamento no prazo de 6 meses.
Abertura do projeto
Normalmente, na abertura do projeto, sua justificativa, objetivo (delimitado no 
tempo) e benefícios esperados são apresentados a todos. Os projetos em geral 
são selecionados e executados para atender uma demanda ou necessidade da 
empresa. Ou seja, todo projeto deve ter uma justificativa, a motivação para que 
ele seja iniciado. Se um projeto não possui justificativa clara, existe uma grande 
chance de ser cancelado futuramente, ou sua prioridade ser reduzida diante de 
outras demandas da organização.
9
Além da justificativa, o objetivo do projeto deve ser conhecido por todos os 
envolvidos. O objetivo da PM Story foi específico, ou seja, com qualificadores 
suficientes para esclarecer o que o projeto pretendia fazer. Utilizou números, 
tornando-o mensurável, podendo ser medido ao final do projeto. Além disso, o 
objetivo do projeto era alcançável, sendo possível ser realizado com os recursos 
da organização. Também era realista, dentro das competências, recursos e tempo 
de que a organização dispunha. Por fim, o objetivo era delimitado no tempo, 
possuindo data limite para ser cumprido.
10
O objetivo do projeto sempre deve levar o projeto da situação atual, com 
demandas não atendidas, para uma situação futura de benefícios obtidos a 
partir do cumprimento do objetivo. Dessa forma, o objetivo do projeto deve 
ser a ponte que leva a organização de uma situação com necessidades não 
atendidas para uma situação em que apresente uma melhoria de coisas boas 
(aumento de clientes, aumento de receita, aumento de lucro, melhoria da 
imagem) ou redução de coisas ruins (redução de custos, de retrabalho ou de 
recursos necessários).
11
A abertura do projeto também tem como objetivo dar 
autoridade ao gerente do projeto. A abertura de um projeto 
pode se dar de diversas formas. Há quem mande apenas um 
e-mail formalizando o início do projeto e dando autoridade ao 
gerente. Existem aberturas formais, com a emissão do Termo 
de Abertura e reunião envolvendo todos os stakeholders. 
Existem projetos em que a abertura é feita em várias etapas, 
com reunião interna, reunião com cliente e emissão do Termo 
de Abertura formal assinado por todos. Não importa como a 
abertura do projeto seja feita. É importante o projeto ser aberto 
formalmente e o gerente do projeto ser designado. A abertura 
do projeto é a certidão de nascimento do mesmo.
Na PM Story, a abertura aconteceu de maneira informal no 
início da história. Depois houve uma reunião onde vários outros 
detalhes a cerca do projeto foram definidos, com a participação 
de todos os stakeholders e equipe. Essa foi uma reunião formal 
de abertura, e aproveitou-se o momento para colher mais 
informações que deram base para o plano do projeto.
12
Identificação dos stakeholders
Antes de acontecer a reunião formal de abertura, a Fabig procurou saber 
quais pessoas e áreas estariam envolvidas, podendo afetar ou serem 
afetadas pelo projeto. Como o projeto significa mudança, é necessário 
que o gerente de projetos tenha a capacidade de lidar com aspectos 
humanos e comportamentais envolvidos com a mudança. O benefício de 
qualquer iniciativa nova implantada nas organizações não se dá apenas 
pela implementação técnica, mas também pelo seu pleno uso. Para que se 
atinja esse objetivo, é necessário trabalhar também as pessoas envolvidas 
com a mudança. 
Além do gerente de projetos, em qualquer processo de mudança é 
fundamental e crítica a existência de um patrocinador, também conhecido 
como sponsor, que é quem dá legitimidade à mudança. Não existe 
mudança bem sucedida sem patrocinador, pois é ele quem fornece 
recursos, financeiros ou não, para o projeto. O presidente da empresa que 
solicitou a nova filial de Viçosa era o sponsor desse projeto da PM Story. 
13
As pessoas, grupos de pessoas e organizações que estão envolvidas no projeto 
ou cujos interesses possam ser afetados de forma positiva ou negativa com o 
resultado da execução ou conclusão do projeto são chamadas de envolvidos, 
interessados ou stakeholders. Eles podem também exercer influência sobre o 
projeto e seus resultados. 
Através da conversa com o Lopes, a Fabig conseguiu identificar o stakeholders 
externos, ou seja, aquelas áreas ou pessoas que não produziam entregas no 
projeto, mas que poderiam afetar ou serem afetadas pelo projeto. 
14
Através da mesma conversa com o Lopes, a Fabig também identificou aquelas 
áreas ou pessoas que seriam responsáveis por produzir alguma entrega no 
projeto. Essas pessoas ou áreas faziam parte da equipe. Apesar de estarmos 
na iniciação do projeto, várias informações de planejamento podem ser 
levantadas, e a equipe foi uma delas.
15
No capítulo 3, ao falarmos sobre o planejamento do projeto, detalhamos cada pessoa ou área que fazem parte da equipe do projeto, bem como suas 
responsabilidades. No capítulo 7 falamos sobre a estrutura organizacional do projeto e explicamos mais detalhadamente sobre a equipe e stakeholders da PM Story.
Para a implantação de um novo projeto, é necessário identificar todo o universo de stakeholders e analisar sua posição perante o projeto. A posição do stakeholder 
pode ser analisada com base no seu grau de interesse e no seu poder de influência no projeto. Identificando essas duas variáveis, é possível definir estratégias 
de como lidar com as pessoas. À medida que a Fabig interagia com essas áreas e pessoas, mais informações a respeito delas eram obtidas. Com isso, foi possível 
elaborar o gráfico de stakeholders e identificar quem tinha interesse positivo ou negativo no projeto, bemcomo sua influência nos resultados do projeto.
16
Por que realizar uma análise de stakeholders no projeto? 
Para identificar os interesses dos stakeholders relativos aos problemas 
que o projeto aborda, para identificar conflitos de interesse entre 
stakeholders, identificar as relações que podem ser construídas para 
viabilizar coligações de apoio.
Por que avaliar o interesse de cada stakeholder? 
O sucesso do projeto é particularmente importante para alguns 
stakeholders (por exemplo, os beneficiários de projetos ou os seus 
financiadores) o que se torna mais óbvio quando os interesses dos 
stakeholders convergem com os objetivos do projeto.
Por que avaliar a influência/importância/poder de cada 
stakeholder? 
Alguns stakeholders detêm maior poder sobre as decisões de um projeto 
e podem exercer um controle que influencie o desenho, implementação 
e resultado desse projeto. A influência pode ser negativa ou positiva.
17
A reunião formal de abertura do projeto – PM Canvas
Na reunião formal de abertura do projeto toda equipe, já identificada anteriormente, 
participou. O objetivo dessa reunião era, além de reforçar e comunicar a todos a justificativa, 
objetivo e benefícios esperados, fazer com que todos compreendessem a lógica do projeto 
e esclarecer as informações importantes para sua condução, especialmente a declaração do 
escopo. Isso foi feito através do preenchimento do Project Model Canvas do projeto.
18
O Project Model Canvas (www.pmcanvas.com.br) 
é uma metodologia de gerenciamento de projetos 
em que uma “tela” com as principais informações 
do projeto é preenchida de forma colaborativa. No 
vídeo da PM Story, o PM Canvas está sendo usado 
para abrir formalmente o projeto junto a todos os 
participantes, como também para obter informações 
críticas que dão respaldo ao planejamento 
detalhado, feito mais adiante. Cabe ressaltar que 
nesse momento o presidente da empresa também 
deu autoridade à Fabig para gerenciar o projeto.
Dentre as principais informações necessárias ao 
planejamento do projeto, o produto do projeto 
merece destaque. O produto é a sintetização sobre 
o que será entregue para o cliente. O sucesso do 
projeto é medido, entre outros critérios, pela entrega 
do produto completo, com todos os requisitos. Os 
requisitos são as necessidades do cliente em relação 
às especificidades do produto. São as qualidades do 
produto, considerações a respeito do desempenho, 
confiabilidade, entre outras. 
19
A Fabig também deixou claro nessa reunião o contra-escopo do 
projeto, ou seja, as exclusões, o que não fazia parte do escopo que 
ela tinha que entregar. O seguro da nova filial, de responsabilidade da 
área financeira, a parte fiscal relacionada à obtenção de licenças e o 
projeto contra incêndio, de responsabilidade da área de patrimônio, 
faziam parte do contra-escopo e foi deixado claro por ela. Devido ao 
fato desses itens estarem fora do escopo do projeto, as áreas Fiscal, 
Financeira e Patrimônio foram consideradas stakeholders externos. Eles 
deveriam ser informados sobre a situação do projeto para executarem 
suas respectivas atividades.
Outras duas informações que impactam diretamente o planejamento 
do projeto são as premissas e restrições. 
As premissas são fatores assumidos como verdade para a execução 
do projeto. Normalmente são assumidas pela equipe do projeto 
sobre o mundo externo e por isso o projeto não possui controle sobre 
elas. Elas podem ser geradoras de riscos uma vez que podem deixar 
de ser verdade. Por isso devem ser documentadas e formalizadas e 
constantemente monitoradas. Os stakeholders externos associados às 
premissas devem estar cientes delas e se comprometerem com elas.
.
20
As restrições são fatores que limitam as opções da equipe do projeto 
e dos quais o projeto tem o controle. Elas podem ter origens internas 
ou externas, normalmente são determinadas pelo cliente, e estão 
relacionadas a limitantes de custo, prazo ou recursos do projeto. Caso 
o projeto não consiga atender uma restrição, devemos verificar se ela 
pode ser negociada. Existem restrições que não podem ser negociadas 
e algumas vezes, para atende-las, o projeto sofrerá impactos nos custos, 
prazos ou recursos. Devemos ter em mente que o plano do projeto 
deve encontrar um caminho que satisfaça as restrições, sob a pena de o 
projeto ser inviável.
.
21
A partir do produto, requisitos e disponibilidade da equipe, é 
possível definir as grandes entregas que o projeto deve ter. É 
importante esclarecer que os requisitos são as necessidades 
do cliente relacionadas ao produto, a demanda do cliente 
que precisa ser atendida. As entregas consistem da oferta 
do projeto para atender a demanda. As entregas são 
estabelecidas pela equipe, elas são um desmembramento do 
produto, e cada entrega deve ter um representante da equipe 
responsável por produzi-la. 
Na reunião de abertura formal da PM Story, foi identificado 
que a filial deveria ter uma identificação visual grande e 
elegante do lado de fora. A área de Marketing é responsável 
pela identificação visual e foi inserida na equipe tão logo esse 
requisito foi levantado. Essa área não tinha sido inserida antes, 
visto que os requisitos foram melhor explicados nesta reunião. 
Com isso, duas entregas foram criadas de responsabilidade do 
Marketing: Contratação da identificação visual e Instalação da 
identificação visual.
22
Por fim, a linha do tempo foi estabelecida para cada entrega. O 
objetivo da linha do tempo nesse momento do projeto não é criar um 
cronograma detalhado e sim fazer uma estimativa de alto nível do tempo 
demandado por cada entrega e do momento em que essas entregas 
estariam prontas. Os custos também foram estimados apenas para 
as entregas que consistiam de compra de móveis e equipamentos e 
contratações de pessoal. O custo das outras entregas estava relacionado 
ao esforço da equipe interna na execução das atividades para produzir as 
entregas e não foi contabilizado.
23
A reunião de abertura foi finalizada com o PM Canvas totalmente preenchido e integrado. Dessa reunião, as principais informações relacionadas à declaração do 
escopo do projeto foram levantadas. A principal vantagem do uso da metodologia do PM Canvas foi a oportunidade de esclarecer as informações do projeto de forma 
colaborativa, onde todos pudessem contribuir e questionar.
A abertura do projeto deve ser feita para 
todos os interessados, de preferência 
presencialmente. O momento da abertura 
do projeto é uma excelente oportunidade 
para esclarecer pontos obscuros do 
projeto e complementar informações. Isso 
reduz substancialmente as solicitações 
de mudanças futuras, bem como 
cancelamentos. Além disso, o momento 
da abertura propicia conhecer o ponto 
de vista, as necessidades e expectativas 
dos diferentes stakeholders do projeto, 
bem como obter comprometimento das 
pessoas envolvidas.
24
Capítulo 3 – O planejamento do projeto
O plano formal e descritivo do projeto foi elaborado pela Fabig com a 
ajuda do Lopes, de informações históricas e com a ajuda de todos os 
envolvidos para definir o escopo, cronograma, responsabilidades, riscos, 
comunicações, entre outras informações relevantes. O plano integrado, 
com todas as informações consistentes entre si, só ficou pronto após uma 
série de interações e validações com pessoas diferentes.
O envolvimento de todos os interessados no projeto nos processos de 
planejamento cria um ambiente propício à contribuição de todos, com 
seus diferentes pontos de vista, suas diferentes experiências e expectativas, 
gerando criação a partir das diferenças.
Cabe ressaltar que algumas atividades de planejamento foram executadas 
durante a etapa inicial do projeto, desde o momento em que a Fabig 
conversa com o Lopes e especialmente durante a reunião de abertura 
formal, quandoo PM Canvas do projeto foi desenvolvido.
Como o projeto tinha uma complexidade que não podia ser ignorada, 
com uma equipe de treze pessoas / áreas, dentre as quais alguns 
opositores dentro da organização, muitos fornecedores externos e 
praticamente todos fora da área de influência da Fabig, ela optou 
por desenvolver documentação formal e detalhada que a auxiliasse a 
monitorar o projeto durante a execução.
25
Dessa forma, a partir dos requisitos levantados e das grande entregas definidas no PM Canvas durante a reunião de abertura formal, a especificação do 
escopo e estrutura analítica do projeto (EAP) foi desenvolvida.
Na especificação (ou declaração) do escopo, praticamente todas as informações levantadas durante a reunião do PM Canvas são formalizadas e 
complementadas, caso mais detalhes a cerca do projeto apareçam. Uma sugestão de declaração do escopo é apresentada abaixo.
1. Sumário executivo 
a. Justificativa para sua realização 
b. Objetivo SMART do projeto 
c. Requisitos do produto, resultado ou serviço
d. Especificações técnicas, funcionais e operacionais 
c. Benefícios esperados
2. Lista das principais entregas do projeto 
3. Premissas 
4. Restrições 
5. Exclusões do projeto 
6. Marcos do projeto / cronograma 
7. Estimativas de custos 
8. Principais riscos
26
A EAP é uma estrutura hierárquica, utilizada em um projeto para definir o trabalho do projeto em termos de suas entregas bem como na decomposição das 
suas entregas em componentes. Ela pode ser vista como uma estrutura única de “explicação” do projeto. Neste sentido, deve informar, em “uma única folha”, 
o escopo do projeto.
A decomposição da EAP consiste em ir detalhando os subprodutos em componentes menores, até que eles estejam em um nível de detalhe que permita o 
gerenciamento (planejamento, execução e controle) do trabalho do projeto.
27
A partir da EAP, e considerando a equipe já identificada durante a iniciação do projeto, o cronograma foi elaborado. No cronograma, todas as atividades que 
deveriam ser executadas para atender o escopo definido pela EAP, a ordem em que deveriam acontecer para atender as restrições do projeto, os responsáveis 
por executá-las, as durações e restrições de calendário foram definidos. As fases do projeto foram representadas no cronograma de forma coerente com o 
primeiro nível de decomposição da EAP.
Um dos pontos cruciais na elaboração do cronograma é a estimativa dos prazos das atividades, que impacta diretamente na estimativa do prazo do projeto 
inteiro. Neste projeto, a Fabig não teve problemas em relação às estimativas porque ela contou com a organização da equipe da Charlote, que guardava as 
durações e custos de projetos anteriores desenvolvidos com os mesmos fornecedores que iriam participar do projeto da Filial de Viçosa. Além disso, o Lopes, 
que dava assistência à Fabig nas atividades de 
gerenciamento de projetos, também ajudou a estimar 
os prazos das atividades da equipe interna. 
É importante lembrar que estimativas de prazos são 
projeções futuras. Só sabemos exatamente a duração 
de uma atividade depois que ela aconteceu. Podemos 
estimar as durações das atividades com maior ou 
menor precisão, e existem diversas técnicas para isso. 
O risco é inversamente proporcional à precisão, ou 
seja, quanto maior a precisão da estimativa, menor 
é o risco. Porém, pode sair caro para o projeto fazer 
estimativa com grande precisão, pois isso implica em 
um esforço maior e técnicas mais sofisticadas. Dessa 
forma, o custo é diretamente proporcional à precisão. 
A equipe do projeto deve sempre equilibrar precisão x 
custo x risco.
As grandes etapas do projeto são apresentadas no 
cronograma resumido ao lado.
28
O cronograma detalhado é apresentado a seguir:
29
No cronograma, todas as áreas e pessoas responsáveis por executar 
as atividades foram explicitamente associadas às suas atividades 
correspondentes. Além disso, uma seção separada no plano do projeto 
com a lista de pessoas e áreas, bem como suas responsabilidades foi 
claramente formalizada. Essas pessoas fazem parte da equipe, e o que 
se espera delas no projeto deve ser claramente comunicado.
30
A animação da PM Story não deixa claro o planejamento detalhado 
dos custos do projeto e fez a estimativa de alto nível apenas para os 
custos de contratação e aquisição no momento da reunião do PM 
Canvas. Através da numeração dos itens de custo no PM Canvas, 
pode-se associar a quais entregas os custos estão relacionados. A 
Fabig mencionou durante o planejamento do projeto que usou 
informações históricas de projetos anteriores da Charlote para 
estimar durações e custos das atividades do projeto.
31
As principais comunicações formais 
do projeto foram planejadas. Todos os 
envolvidos no projeto devem entender 
como as comunicações afetam o projeto 
como um todo. Os gerentes de projetos 
podem gastar um tempo excessivo na 
comunicação com todos os interessados. 
Dessa forma, se houver um alinhamento 
durante a fase de planejamento em 
relação às necessidades de informações 
dos stakeholders, o momento e a forma 
com que as informações devem ocorrer, o 
tempo e esforço gasto nas comunicações 
pode ser otimizado.
O planejamento das comunicações, em 
linhas gerais aborda qual informação é 
necessária e deve ser comunicada, quem 
é o responsável por prover a informação, a 
quem ele deve a informação, de que forma 
ela deve ser comunicada e quando.
32
Para que não houvesse falhas de 
comunicação, todos os envolvidos no 
projeto foram identificados e listados, bem 
como seus contatos.
33
Os principais riscos do projeto foram levantados. Riscos são as incertezas do projeto, são eventos que podem ou não ocorrer. Caso ocorram, podem trazer 
impactos positivos ou negativos ao projeto. Os riscos que trazem impactos positivos são denominados oportunidades. Os riscos que trazem impactos negativos 
são denominados ameaças. Muitas vezes dedicamos esforços para gerenciar apenas os riscos negativos, tentando minimizar a probabilidade e / ou o impacto 
desse tipo de risco. A probabilidade de um risco diz respeito à chance desse risco ocorrer. O impacto do risco diz respeito ao valor em jogo caso o risco ocorra.
34
As origens ou fontes dos riscos podem ser as mais diversas 
possíveis. Podemos ter riscos relacionados à equipe desmotivada 
ou incapacitada, a requisitos mal levantados, a projeto mal 
gerenciado, a fornecedores problemáticos, a clientes ausentes, 
bem como a fatores organizacionais.
Para todos os riscos, uma análise qualitativa deve ser feita. 
Essa análise serve para priorizar os riscos. Dependendo da 
complexidade e tamanho do projeto, a lista de riscos pode ser 
imensa e podemos não dispor de “braço” para gerenciar todos 
eles. Por isso a priorização é importante. Para fazer a priorização 
dos riscos do projeto da nova filial de Viçosa, a Fabig usou uma 
escala de 1-5 para definir tanto probabilidade quanto impacto. A 
multiplicação dos dois valores gerou o grau de exposição do risco. 
Riscos com maior grau de exposição era priorizados em relação 
aos riscos com menor grau de exposição.
Para cada risco, ações para mitigar (reduzir) a causa ou a 
consequência foram estabelecidas, bem como ações de 
contingência. As respostas de contingência são planejadas para 
serem usadas apenas quando os riscos ocorrerem. Por fim, os 
donos dos riscos foram identificados. Os riscos do projeto devem 
ser constantemente monitorados ao longo da execução do 
projeto, pois sua probabilidade e impacto podem ser alterados, 
novos riscos podem surgir e riscos podem deixar de existir. Por 
exemplo, a partir do momento em que a equipe de projetos 
civis elaborou e aprovou todos os desenhos técnicos, o risco 
relacionado ao atraso desses desenhos deixa de fazer sentido.
As aquisições do projeto não foram tratadas no planodo projeto. 
A contratação de fornecedores para execução das obras era de 
responsabilidade da Charlote, e a aquisição de móveis e equipamentos 
era de responsabilidade da área de compras. Dessa forma, a Fabig se 
eximiu desses controles e todas as prestações de contas referentes a 
fornecedores eram feitas pelas pessoas e áreas responsáveis.
Da mesma forma, o planejamento e gerenciamento da qualidade não 
ficaram explícitos na animação. O controle da qualidade das principais 
entregas do projeto ficaram a cargo da Charlote, no caso dos desenhos 
técnicos e dos executores, como também a cargo da área de Compras, 
responsável por adquirir móveis e equipamentos.
35
A reunião de kick-off
Ao final do planejamento do projeto, a reunião de kick-off 
foi feita. A reunião de kick-off ocorre antes da execução do 
projeto. Nesse momento, toda equipe é mobilizada para 
rever o plano e se comprometer com ele. Como muitos 
se envolveram durante o planejamento, o kick-off da PM 
Story foi rápido. Durante essa reunião, alguns detalhes do 
projeto integrado ainda podem ser repassados e novas 
informações que podem levar ao replanejamento podem 
ser levantadas.
No caso da PM Story, por exemplo, a área de marketing 
levantou informações históricas a respeito do atraso 
na instalação da identificação visual e isso levou ao 
replanejamento de uma atividade do cronograma, bem 
como revisão de um risco do projeto. Essas observações e 
questionamentos a respeito do plano por parte da equipe 
são importantes, pois no momento em que a equipe se 
compromete com o plano antes da execução ela deve 
acreditar que o plano é realista e pode ser executado 
nas condições colocadas. O comprometimento da 
equipe deve ser REAL e ela deve estar segura para se 
comprometer. Esse é mais um motivo para o plano ser 
elaborado com o envolvimento de todos.
36
Capítulo 4 – A integração das restrições do projeto
Na PM Story é mencionado que, até o plano integrado e consistente do 
projeto estar pronto, a Fabig precisou de envolver e consultar várias pessoas 
para estimar esforços e custos, colocar atividades para serem executadas 
em paralelo, alinhar responsabilidades, identificar donos dos riscos, validar 
comunicações, entre outras questões que precisavam ser fechadas. Idealmente, 
o plano do projeto deve ser feito de forma colaborativa e, quanto mais os 
participantes do projeto estiverem envolvidos, menores são as chances de 
alterações futuras no plano. Alterações no plano do projeto durante a execução 
são inevitáveis na maioria das vezes, devido a novos requisitos que surgem, 
mudanças de mercado ou organizacionais que impactam no projeto. Muitas 
vezes não é possível evitar algumas alterações, mas esforços devem ser feitos 
para minimizá-las. 
O primeiro esforço para minimizar a possibilidade de alterações futuras 
no plano do projeto é elaborar um plano realista, com a colaboração e 
concordância de todos de que o plano é factível dentro dos recursos que a 
organização dispõe para atender aos requisitos de escopo, qualidade e tempo 
do projeto. O plano só é realista se ele aborda todos os requisitos do cliente, 
dentro das restrições impostas no projeto, com os recursos de tempo, pessoas, 
materiais e dinheiro que dispomos. Recursos que são sempre escassos, por sinal. 
Não, isso não é exclusividade do seu projeto. Todas as pessoas desse mundo 
executam projetos com menos recursos do que gostariam para fazê-lo. E temos 
que lidar com isso.
37
Abordar e explicitar todos os requisitos do projeto não é tarefa 
fácil. Primeiro porque ninguém dispõe de tempo para levantar e 
validar os requisitos. Tampouco de elaborar cronograma, plano de 
riscos, comunicações, dentre outros. A ansiedade de começar a 
executar o projeto é tão grande que muitas vezes o planejamento, 
que deve ser totalmente norteado pelas necessidades dos 
clientes, é relegado. Mas espere um pouco. Se um critério que 
define o sucesso de um projeto é entregar valor, é atender às 
necessidades do cliente, como sua execução pode ser iniciada 
antes de determinar essas necessidades? Qual é a justificativa de 
não termos tempo para levantar requisitos se são justamente eles 
que nortearão o planejamento de todo projeto? Se a justificativa 
é começar o projeto mais rápido, devemos ter em mente que, 
no momento de levantamento de requisitos, já começamos 
o projeto. E uma lista incompleta de requisitos gera um plano 
incompleto e gera, necessariamente, solicitações de mudanças 
ao longo da execução do mesmo. Quanto mais solicitações de 
mudanças ao longo da execução, maior será o prazo para finalizar 
o projeto dentro do escopo, que será constantemente alterado. 
Dependendo do momento em que as mudanças forem 
solicitadas, será necessário retrabalho para atender à solicitação de 
mudança. Isso vai fazer o projeto custar mais, e gastar mais tempo 
também, pois atividades que já foram realizadas terão que ser 
executadas novamente para atender à mudança.
38
Muitas vezes o levantamento de requisitos e, consequentemente, o 
planejamento do projeto é desprezado porque um prazo desafiador é 
imposto pelo cliente durante a contratação do projeto. Mas devemos 
entender o conceito de restrições do projeto, que estão relacionadas 
entre si. 
Todo projeto deve entregar, a partir de um conjunto de requisitos do 
cliente, um determinado escopo. Os requisitos são as necessidades, a 
demanda que o cliente tem em relação ao produto, serviço ou resultado 
que o projeto deve gerar. E todo projeto possui recursos finitos de 
pessoas, materiais, máquinas e dinheiro. Conseguimos atender o escopo 
do projeto dentro da qualidade desejada dos seus resultados com os 
recursos que dispomos em um determinado prazo. Logo, o escopo, 
qualidade, custos (relacionados aos recursos) e prazos do projeto estão 
intimamente relacionados. 
Se um escopo é fechado com um grau de qualidade desejado e 
os custos são controlados, então conseguimos atender a essas três 
restrições dentro de um determinado prazo. Se o cliente deseja que o 
prazo seja menor, não há mágica a fazer – teremos que cortar escopo 
ou reduzir o grau de qualidade de entregas ou aumentar recursos 
(custos) para conseguir terminar o escopo no prazo menor. É importante 
salientar que isso pode aumentar os riscos do projeto e trazer um 
impacto negativo em relação a satisfação do cliente. 
39
Por outro lado, se uma mudança é solicitada através de 
um aumento de escopo, é natural que essa mudança 
impactará o aumento dos custos do projeto, pois 
precisaremos de recursos para executar as atividades 
relacionadas ao escopo dessa mudança. O prazo do 
projeto também poderá ser impactado. A não ser que 
possamos realizar atividades em paralelo ou retirar outra 
parte do escopo cujos esforços sejam compatíveis com o 
que estamos adicionando.
O conceito de restrições do projeto e como elas se 
relacionam é crucial para entender e explicar a lógica 
do projeto aos stakeholders. O PM Canvas, usado na 
abertura da nova filial de Viçosa da Pm Story, é um ótimo 
instrumento que facilita a visualização de relacionamento 
entre as restrições do projeto. No PM Canvas, associamos 
as entregas (escopo) à equipe (recursos), aos custos 
e à linha do tempo. Todas as entregas devem ser 
explicitadas de forma a atender aos requisitos do projeto. 
Se a orientação é para reduzir custos, por exemplo, será 
necessário reduzir o grau de qualidade com que uma 
entrega é feita ou eliminar uma entrega. A lógica do 
projeto fica clara e através das informações integradas é 
possível justificar as decisões de planejamento. 
40
Capítulo 5 – A execução e monitoramento do projeto
Na execução do projeto, grande parte dos 
esforços partem da equipe do projeto, que 
executa atividades de construção do produto, 
desenvolvimento do serviço ou resultado a que o 
projeto pretende. Duranteessa etapa, o gerente 
do projeto tem a responsabilidade de mobilizar e 
gerenciar a equipe e o trabalho do projeto. 
Durante a execução, a Fabig monitorava as 
atividades e problemas do projeto junto à equipe e 
reportava, em marcos específicos, o desempenho 
do projeto junto ao presidente. 
O monitoramento das atividades junto à equipe 
tratava de questões do dia-a-dia do projeto, de 
verificação do cumprimento das atividades do 
cronograma, dos porquês do não cumprimento, da 
resolução do problemas que surgiam, da verificação 
dos riscos, do estabelecimento de planos de ações. 
No contexto da PM Story, esse acompanhamento 
acontecia semanalmente. Nesses momentos, o 
projeto era “regado”, cuidado nos detalhes, a grama 
aparada, as flores podadas. Questões miúdas são 
tratadas aqui junto a quem estava trabalhando nas 
atividades e entregas do projeto. 
41
O acompanhamento de marcos junto ao presidente 
era diferente. Ele acontecia em momentos mais 
espaçados e tratava principalmente de verificar se as 
entregas planejadas para o marco foram feitas, além 
de fornecer uma informação geral da situação do 
projeto. Nesse acompanhamento de marcos, além 
de verificar as entregas, pode-se fazer uma análise 
da viabilidade do projeto continuar. Por exemplo, se 
já gastamos 50% do tempo do projeto, produzimos 
20% do escopo e gastamos 80% do dinheiro, vale 
a pena continuar? Qual é a comparação do que foi 
produzido em termos de escopo, gasto em termos 
de tempo e recursos em relação ao planejado? 
Qual foi a variação? Essa variação está dentro 
das margens de variação permitidas? Com base 
nessas informações, vamos continuar ou é melhor 
cancelarmos, ou talvez renegociarmos os objetivos 
do projeto?
42
O acompanhamento do projeto pode assumir 
vários vieses. Muitas vezes vemos gerentes de 
projetos elaborando um único tipo de relatório de 
acompanhamento e enviando a pessoas e áreas 
com interesses diferentes a cerca do projeto. Ou 
seja, são fornecidas informações que não interessam 
a audiência. Fabig emitia relatórios diferentes 
dependendo do seu público. Junto à equipe, 
o acompanhamento era detalhado, a nível de 
atividades, problemas, riscos. Com o presidente, as 
informações era relacionadas a entregas, previsão de 
término e custos.
Além das atividades de monitoramento e report 
do projeto, durante a execução a Fabig também 
controlava as mudanças que poderiam surgir 
no projeto. A principal mudança que surgiu 
explicitamente no contexto da PM Story foi uma 
solicitação do presidente que impactava em 7 
dias e R$10.000 a mais. A mudança foi recebida 
formalmente, os impactos foram avaliados e 
apenas depois da aprovação da mudança a nova 
linha de base do plano do projeto foi criada, e o 
monitoramento do projeto passou a perseguir os 
dados de planejamento desse novo plano.
43
Como diz Ricardo Vargas, projeto nasceu para dar errado, está no DNA do 
projeto. Se quisermos boicotar um projeto que estamos conduzindo, basta 
ficar quieto, não precisamos fazer nenhum esforço para isso. E todas as 
informações a respeito do projeto estão muito bom conectadas. Sem os 
requisitos não conseguimos elaborar um plano. Por mais especialista que 
você seja em definir um bom escopo, cronograma e orçamento, envolver 
as pessoas, cuidar dos riscos, se não dispõe de todas as necessidades do 
projeto formalizadas através dos requisitos, o projeto não entregará o valor 
que deveria. E se você não tem um plano real, suas chances de concluir um 
projeto com sucesso são praticamente nulas. 
Por outro lado, apenas um bom plano realista não lhe garante uma boa 
entrega. Tem que cuidar, tem que vigiar durante a execução. Cuidar 
significa verificar se as coisas estão acontecendo conforme o plano. 
Comparar. Identificar desvios e o tamanho desses desvios. Saber os 
porquês. Tomar ações. Evitar novos desvios. Prever riscos e se precaver 
em caso de impactos negativos que eles possam gerar. Isso exige muita 
organização, sentido de controle, aferição. Exige cuidado com o projeto. 
Exige saber onde buscar as informações de execução, como organizá-
las e principalmente como usá-las para te ajudar a entregar dentro da 
performance desejada. 
Nesse ponto cabe ressaltar que o gerenciamento de um projeto envolve 
dispor das informações corretas, atualizadas e no tempo certo para 
processá-las, tomar ações e decisões, e entregar os resultados das suas 
ações a quem precisar.
Ninguém disse que é fácil. Mas certamente não exige habilidades de 
nenhum gênio.
Antes de conhecer qualquer tarefa, temos 
de aprender a fazer a pergunta: “De que 
tipo de informação eu necessito, sob 
que forma e quando? [...] As perguntas 
seguintes que as pessoas precisam 
aprender a fazer é: “A quem devo que tipo 
de informação? Quando e onde”
Peter Druker
44
Capítulo 6 – O encerramento do projeto
A PM Story não deixa claro sobre as atividades que a Fabig fez 
no encerramento do projeto. Foram destacados apenas o 
coquetel de comemoração, evento muito importante por sinal, 
e o feedback do presidente em relação ao resultado do projeto.
Apesar de muitos projetos serem abandonados ao invés de 
finalizados, muitas ações pertinentes acontecem nessa etapa 
do projeto:
• Aceitação formal do cliente ou patrocinador.
• Documentação das lições aprendidas.
• Arquivamento de todos os documentos relevantes.
• Revisão pós-projeto.
• Registro dos impactos da adequação de qualquer 
processo.
• Aplicação das atualizações apropriadas aos ativos de 
processos organizacionais.
• Encerramento das aquisições.
Além disso, todas as pendências devem ter sido resolvidas, os 
recursos formalmente liberados e o encerramento formalmente 
comunicado.
45
Capítulo 7 – A estrutura organizacional em que o 
projeto está inserido
Os projetos normalmente fazem parte 
de uma organização que é maior que o 
projeto. A maturidade da organização 
em relação ao seu sistema de 
gerenciamento de projetos, sua cultura, 
seu estilo, sua estrutura organizacional 
podem influenciar o projeto e o grau de 
autoridade que o gerente de projetos 
pode ter. A estrutura da organização 
geralmente limita a disponibilidade 
de recursos para o desempenho das 
atividades dos projetos. Os tipos de 
estrutura organizacional variam desde 
uma estrutura funcional a uma estrutura 
por projeto, tendo diversas estruturas 
matriciais intermediárias. 
A estrutura matricial da organização 
onde a Fabig trabalha é tipicamente 
matricial.
46
A empresa está organizada por departamentos (TI, Projetos Civis, 
Comercial, Administrativo), e cada departamento possui funcionários 
com a mesma especialidade. Projetos podem surgir dentro dos 
departamentos, como também pode acontecer de um projeto ser 
iniciado (como foi o caso da nova filial de Viçosa), e a equipe se formar a 
partir de vários departamentos.
Consideramos equipe todas as pessoas ou áreas que produzem alguma 
entrega no projeto. A Fabig nesse caso era a gerente do projeto e 
o restante da equipe tinha que se reportar a ela no que diz respeito 
às atividades e responsabilidades do projeto. O Lopes fazia parte da 
equipe pois auxiliava a Fabig em todas as atividades de gerenciamento. 
Interessante notar que a Charlote, que coordenava toda área de 
Projetos Civis, junto com seus subordinados, faziam parte da equipe 
deste projeto e deveriam se reportar à Fabig nas questões pertinentes 
ao projeto, mesmo a Fabig não possuindo cargo de coordenação na 
estrutura hierárquica da empresa. Basicamente as entregas deles diziam 
respeito aos desenhos técnicos da nova filial. 
Dentro da gerência comercial, uma pessoa do departamento de 
marketing também fazia parte da equipe porque estava responsável 
pela contratação e instalação da identificação visual. Dentro da 
gerência administrativa, uma pessoa do departamento de RH tinha aresponsabilidade de selecionar, contratar, integrar e treinar os novos 
funcionários da filial. E o departamento de compras, também dentro da 
gerência administrativa, tinha a responsabilidade de orçar e comprar os 
novos móveis equipamentos.
Os executores dos projetos civil, hidráulico, climatização, dados e voz 
também são considerados equipe na medida em que produzem 
entregas no projeto, mesmo sendo fornecedores externos à 
organização. No caso da PM Story, eles eram selecionados pela Charlote 
e deveriam se reportar a ela.
Dentro da estrutura organizacional da empresa, existiam pessoas e 
outros departamentos que estavam envolvidos com os resultados do 
projeto mas não faziam parte da equipe pois não produziam entregas 
do escopo. Esse era o caso da área fiscal, que cuidava das licenças 
ambientais, do financeiro, que cuidava do seguro e patrimônio, que 
cuidava do projeto contra incêndio. Esses três itens estavam fora do 
escopo do projeto, eram exclusões do projeto, mas essas áreas tinham 
que ser informadas do andamento do projeto para cumprirem com 
suas responsabilidade. O fato de serem stakeholders externos também 
fazia com que uma série de premissas relacionadas a eles fossem 
assumidas. Por exemplo, era assumido que a licença da Prefeitura, de 
responsabilidade do fiscal, seria obtida para a construção da filial. O 
presidente da empresa, demandante e sponsor do projeto, também 
era um stakeholder externo pois não produzia entregas do projeto, mas 
patrocinava o projeto provendo recursos para a execução do mesmo. 
47
Capítulo 8 – O sucesso do projeto
 “Sucesso significa diferentes coisas para diferentes pessoas. Um 
arquiteto pode considerar sucesso em termos de aparência 
estética, um engenheiro em termos de competência técnica, um 
contador em termos de dólar gasto no orçamento, um gerente de 
recursos humanos em termos de satisfação dos empregados. Os 
executivos avaliam seu sucesso em termos de ações de mercado.” 
(Freeman e Beale, 1992).
A PM Story terminou com a Fabig feliz pelo projeto ter terminado 
com sucesso, mesmo sem ter recebido elogios do chefe em relação 
ao bom gerenciamento do projeto. Nesse aspecto, a vida do 
gerente de projetos é desafiadora, pois muitas vezes ele é cobrado e 
responsabilizado pelo fracasso do projeto e outras vezes não recebe 
o crédito devido pelo sucesso. Ou seja, quando o projeto termina 
bem, ninguém lembra que o gerenciamento existiu. Quando o 
sucesso fica comprometido, a culpa é do mau gerenciamento.
Mas o que é sucesso de um projeto? O conceito de sucesso é muito 
controverso, interpretado diferentemente pelas pessoas e precisa 
ser constantemente alinhado com os stakeholders antes do projeto 
iniciar e durante a execução do mesmo.
48
Farias e Almeida (2010) publicaram o artigo intitulado Definindo o sucesso 
de projetos, onde fizeram um apanhado sobre os diversos critérios usados 
para definir sucesso de projetos. Ao todo, os autores encontraram oito 
definições diferentes para sucesso de projetos! Em muitas dessas definições, 
os critérios de sucesso mais usados foram:
• Eficiência do projeto: alcances de escopo, custo e prazo, se o projeto 
for completado de acordo com o plano. 
• Impacto e satisfação do cliente: percepção das principais partes 
interessadas em relação ao projeto. Essa dimensão especifica como 
os resultados do projeto melhorarão a vida e os negócios e como as 
necessidades dos clientes serão atendidas. 
• Impacto no time: reflete como o projeto afetará seus membros 
em termos de satisfação do time, moral, lealdade do time com a 
organização e a retenção depois que ele for finalizado, bem como 
o investimento indireto da organização no time, seu aprendizado, 
crescimento e capacidades. 
• Sucesso direto e nos negócios: impacto direto e imediato do projeto 
na organização principal: nível de vendas, receitas, lucros, fluxo de 
caixa e outras medidas financeiras. 
• Preparação para o futuro: diz respeito aos resultados de longo prazo, 
tais como criar um novo mercado, uma nova linha de produtos, uma 
nova tecnologia. 
• Sucesso do gerenciamento de projeto: qualidade do processo de 
gerenciamento levando a atingir os objetivos de escopo, prazos e 
custo. Satisfação das partes interessadas no que se refere à condução 
do projeto.
• Sucesso do produto: ir ao encontro dos objetivos estratégicos da 
organização, satisfazer as necessidades dos usuários, satisfazer as 
partes interessadas no que se refere ao produto.
Como podemos ver, a definição de sucesso pode envolver uma série de 
critérios, que muitas vezes podem ser diferentes para as diversas pessoas 
envolvidas no projeto. Como então perseguir de maneira acertada o sucesso 
do projeto que estamos conduzindo? A primeira coisa a fazer é perguntar 
ao cliente, patrocinador ou outra parte interessada importante quais são os 
critérios de sucesso deles. A cada mudança ou marco, confirme novamente 
quais são os critérios de sucesso.
Uma abordagem integradora de sucesso de projetos pode ser resumida da 
seguinte forma:
“Um projeto de sucesso é aquele que é concluído 
dentro do prazo e dos custos estabelecidos conforme 
planejado, e em um nível de qualidade de seus 
resultados e produtos que leve à plena satisfação de 
seus clientes e atendimento objetivos de negócio!”
49
Capítulo 9 – Conclusões
Todas as pessoas e organizações desejam finalizar seus projetos atendendo todas as 
necessidades para as quais eles foram iniciados, dentro dos prazos impostos cliente, sem 
retrabalho, utilizando o menor número de recursos possível. Ou seja, todos os clientes querem 
comprar sonhos e muitas vezes, mesmo sem dispor de todas as informações para isso, 
acabamos vendendo o sonho, sabendo que não vamos conseguir entregar. Por que fazemos 
isso? Porque temos medo de perder o cliente?
Suspeito que o principal motivo pelo qual vende-se sonho é o desconhecimento sobre as 
informações do projeto e como usá-las para conduzir bem o projeto. Não se sabe usar as 
restrições do projeto para justificar prazos, necessidades de recursos, riscos.
A PM Story procura mostrar como vender e conduzir um projeto de maneira realista e 
colaborativa. O gerenciamento de projetos deve ser útil, desejado e trazer resultados positivos 
aos projetos. Mas certamente não tem a pretensão de agradar a todos.
Os clientes só deixarão de comprar sonhos quando deixarmos de vender fantasia. 
Nenhum cliente vai descobrir que não vendemos milagres se não deixarmos de 
tentar fazer milagres. Vender sonho e entregar realidade só tem uma consequência: 
fazer os clientes pensarem que somos incompetentes. Tornar o gerenciamento 
de projetos área séria e confiável depende de uma única coisa: vender realidade e 
entregar realidade. 
Paulo Márcio Brandi Rezende
Para todos os próximos projetos dos quais passaremos a participar, podemos escolher entre 
continuar vendendo sonho e entregando realidade ou vender realidade e entregar realidade. 
A escolha é toda nossa. Bons projetos a todos!
50
Referências
CHOO, Chun Wei. The knowing organization: how organizations use information to construct meaning, create knowledge and make decisions. 
New York: Oxford University Press, 2006.
DAVENPORT, Thomas; PRUSAK Laurence. Conhecimento empresarial: como as organizações gerenciam seu capital intelectual. Rio de Janeiro: 
Campus, 1998.
DRUCKER, Peter. Sociedade pós-capitalista. 7. ed. São Paulo: Editora Pioneira, 1998.
FARIA FILHO, J., R.; ALMEIDA, N. O. Definindo sucesso em projetos. Revista de Gestão e Projetos - GeP, São Paulo, v. 1, n. 2, p 68-85, jul./dez. 2010.
FINOCCHIO JÚNIOR, J. Project Model Canvas. Rio de Janeiro: Elsevier, 2013.
FREEMAN, M. and BEALE, P. (1992). Measuring project success. Project Management Journal, 1, 8– 17.
LEVIN, Ginger. Knowledge mangement success equals project management success. PMI Global Congress 11. Washington D.C, 2010.LIERNI, Peter C.; RIBIERE, Vincent M. The relationship between improving the management of projects and the use of KM. The Journal of Information 
and Knowledge Management Systems, vol 38, no. 1, 133-146, 2008.
NONAKA, I.; TAKEUCHI, H. Theory of knowledge creation. In: The knowledge-creating company: how Japanese companies create the dynamics of 
innovation. New York: Oxford University Press, 1995.
PMI - PROJECT MANAGEMENT INSTITUTE. Guide to the Project Management Body of Knowledge (Guide to the PMBoK®). Quinta Edição. Newton 
Square, PA, EUA: 2012.
VARGAS, Ricardo Viana. Gerenciamento de projetos: estabelecendo diferenciais competitivos. 6. ed. Rio de Janeiro: Brasport, 2006. 250 p. 
51