Sei sulla pagina 1di 51

1

Sobre a autora e a PM Story


A PM Story existe formalmente desde 2006 com a marca D&B Consultoria, especializada em
solues e treinamentos na rea de gesto.
Fabiana Bigo Silva scia-proprietria da D&B Consultoria e criadora da PM Story.
Ela doutoranda em Cincia da Informao (UFMG), Bacharel e Mestre em Cincia
da Computao (UFMG), Project Management Professional (PMP) e certificada como
implementadora MPS.BR, equivalente ao CMMI.
Fabiana professora da Fundao Dom Cabral (FDC) em programas de especializao e
aperfeioamento, professora do IBMEC nos MBAs de Gerenciamento de Projetos, cursos de
curta durao e de aperfeioamento, professora do IEC Instituto de Educao Continuada
da PUC Minas na ps-graduao de Gerenciamento de Projetos, e professora da psgraduao em Gerenciamento de Projetos de Software do Instituto de Gesto em Tecnologia
da Informao (IGTI). Tambm atuou em coordenaes de MBAs em Gerenciamento de
Projetos.
Junto ao PMI-MG, foi voluntria como professora do curso preparatrio para o exame
PMP. Desde 2006 atua como palestrante em empresas e em diversos Congressos de
Gerenciamento de Projetos do PMI. Fabiana tambm autora de livros e artigos em
gerenciamento de projetos.
Como consultora, Fabiana atua em empresas no desenvolvimento de processos de
gerenciamento de projetos e portflios, na implantao de PMOs, na gesto de requisitos,
qualidade e medies, bem como em treinamentos customizados in company.
Mais informaes sobre a PM Story:
www.pmstory.com.br

Agradecimentos
Sempre utilizei recursos de storytelling em minhas aulas, utilizando vdeos de
histrias contadas por outras pessoas. A ideia de criar uma animao com a
minha cara existe h muito tempo, mas os recursos de tempo e especialmente
financeiros necessrios para concretizar a ideia so altos. Muitos me inspiraram
na elaborao do vdeo e do e-book, e muitos colaboraram ativamente.
Agradeo em primeiro lugar o Lucas Alves e Alexandre Martins da Ideia Clara
(www.ideiaclara.com). O Lucas fez a animao e edio do vdeo. O Alexandre
fez todas as ilustraes e fiquei muito feliz ao ver que a Fabig (meu alter ego) era
uma moa com cara de simptica e principalmente magra. Agradeo ao Julio
Csar de Jesus pela gravao do som.
O professor Jos Finocchio merece um agradecimento muito especial no
apenas pelo apoio na divulgao da PM Story, como pelas dicas e por me inspirar
a contar a histria de uma maneira muito mais didtica usando o PM Canvas.

Agradeo a todos os meus colegas da comunidade de gerenciamento de


projetos do Twitter. Muitas das frases e ensinamentos que esto na PM Story so
fruto de interaes com esses colegas: Ricardo Viana Vargas, Gerente no Buteco,
Farhad Abdollahyan, Maurcio Cabral, Marcus Gregrio, Patrcia Bracco, Marlia
Balb, Giselle Coelho, Camille Silva, Mrio Henrique Trentim, Alexandre Paiva.
Muito do que contm nas histrias so realidades contadas pelos meus clientes,
e agradeo a oportunidade de ter estado em cada um deles, onde aprendi e
ensinei gerenciamento de projetos na prtica.
Por fim quero agradecer o meu brao 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.

Sumrio
Cap. 1 Introduo

Cap. 2 - A iniciao do projeto

Cap. 3 O planejamento do projeto

24

Cap. 4 A integrao das restries do projeto

36

Cap. 5 A execuo e monitoramento do projeto

40

Cap. 6 O encerramento do projeto

44

Cap. 7 A estrutura organizacional em que o projeto est inserido

45

Cap. 8 O sucesso do projeto

47

Cap. 9 Concluses

49

Referncias

50
4

Captulo 1 - Introduo
A PM Story surgiu de uma necessidade pessoal, como professora e consultora na rea de gerenciamento
de projetos, de mostrar como a dinmica da conduo de um projeto de maneira mais prtica. Quais
so as situaes que o gerente e a equipe de projetos passa e quais seriam os possveis comportamentos
que deveramos adotar para passar pela tenebrosa ponte que transporta as necessidades e demandas
no atendidas dos clientes at os benefcios gerados pelas entregas do projeto.
Gerenciar projetos no fcil e, dependendo da complexidade e tamanho do projeto, no exige tcnicas
sofisticadas e que demandam alto nvel de inteligncia e perspiccia. O gerenciamento de projetos,
em geral, muito mais uma questo de atitude colaborativa, voltada correta obteno, organizao
e compartilhamento de informaes 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 no possuem essa necessidade.
A Fabig, protagonista da PM Story, no nenhum gnio, nem especialista de destaque, mas possui
caractersticas e comportamento necessrios boa conduo de um projeto. Em primeiro lugar, ela
voltada entrega, ela se compromete com a misso (a partir do momento em que ela no conseguiu
fugir dela!), e se preocupa com sua reputao de fazer uma boa entrega. Uma caracterstica muito
importante o fato de sempre buscar cooperao de todos os stakeholders. Atualmente a conduo
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 no faro isso de
boa vontade e por iniciativa prpria se no foram devidamente envolvidos pelo condutor do projeto.
A Fabig promove a cooperao na reunio 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 informaes de maneira til para cobrar responsabilidades, reportar status, obter aceitaes.

Uma das coisas que a Fabig faz melhor, dentro da simplicidade do exemplo
apresentado, usar a informao como sua aliada na conduo dos
projetos. Em primeiro lugar, a informao obtida para criar significado
do projeto, para compreender por que o projeto deve acontecer, os
benefcios pretendidos e o que necessrio entregar para atingir esses
benefcios. Nesse momento, dado sentido ao projeto. Segundo, ela
constri conhecimento a cerca do projeto. Isso feito de forma colaborativa,
atravs da interao com todos os stakeholders para entender e registrar
as informaes necessrias para a entrega do projeto com sucesso.
nesse momento que o plano do projeto construdo. Existe uma forte
preocupao da Fabig para que o plano seja real. Isso demonstrado em
vrios momentos:
a) Na reunio de abertura atravs do preenchimento, com a
participao de todos, do PM Canvas que contm as principais
informaes do projeto.
b) Na interao constante com vrios stakeholders durante a
construo do plano detalhado.
c) Na reunio de kick-off para repassar o plano detalhado e obter o
comprometimento de todos. Nesse momento, alguns aspectos do
plano so questionados e ele ajustado para contemplar todas as
observaes dos envolvidos.

A terceira forma com que a Fabig usava bem a informao para tomada
de decises. Todas as decises so 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 decises, que eram orientadas por regras e norteadas por informaes
atualizadas. Isso dava legitimidade ao projeto, e demonstravam um
comportamento responsvel. Os principais momentos em que as decises
eram tomadas na PM 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 mudanas, fazendo uma anlise
de impacto antes de aprovar qualquer alterao do plano.

Um desafios que ns, 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 benefcios a
partir do bom gerenciamento. Ensinar gerenciamento na prtica no
fcil. O uso de uma histria animada foi um artifcio usado para facilitar
a converso do conhecimento explcito a cerca de gerenciamento de
projetos em conhecimento ttico. O conhecimento explcito todo aquele
conhecimento presente nos livros, vdeos, formalizado em palavras e
transmitido atravs de aulas, palestras. O conhecimento tcito est associado
ao know-how, experincia, ao sabe fazer, e muitas vezes difcil de ser
expressado atravs de palavras.

No gerenciamento de projetos, existe um desafio muito grande em


fazer com que os indivduos internalizem o conhecimento na forma de
modelos mentais e rotinas de trabalho. O uso de storytelling procura
afrouxar essa barreira na internalizao do conhecimento a partir de uma
viso compartilhada dos acontecimentos que se passam em uma histria.
Esse livro surgiu como apoio animao PM Story disponvel no youtube
(http://youtu.be/QVEdvQV8GqU). O objetivo do livro fazer um link da
histria apresentada com os conceitos de gerenciamento de projetos
que se aplicam. No temos a inteno de entrar em profundidade em
nenhuma prtica do gerenciamento de projetos, mas sim dar a viso de
cima, a viso do todo, apresentar em linhas gerais a dinmica da conduo
de um projeto do incio ao fim. Esperamos que seja mais um recurso
didtico para o aprendizado de gerenciamento de projetos.

Boa leitura!

Captulo 2 - A iniciao 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 no atendidas da empresa e a pediu que gerenciasse os esforos para
ter a nova filial de Viosa em funcionamento no prazo de 6 meses.

Abertura do projeto

Normalmente, na abertura do projeto, sua justificativa, objetivo (delimitado no


tempo) e benefcios esperados so apresentados a todos. Os projetos em geral
so selecionados e executados para atender uma demanda ou necessidade da
empresa. Ou seja, todo projeto deve ter uma justificativa, a motivao para que
ele seja iniciado. Se um projeto no possui justificativa clara, existe uma grande
chance de ser cancelado futuramente, ou sua prioridade ser reduzida diante de
outras demandas da organizao.

Alm da justificativa, o objetivo do projeto deve ser conhecido por todos os


envolvidos. O objetivo da PM Story foi especfico, ou seja, com qualificadores
suficientes para esclarecer o que o projeto pretendia fazer. Utilizou nmeros,
tornando-o mensurvel, podendo ser medido ao final do projeto. Alm disso, o
objetivo do projeto era alcanvel, sendo possvel ser realizado com os recursos
da organizao. Tambm era realista, dentro das competncias, recursos e tempo
de que a organizao dispunha. Por fim, o objetivo era delimitado no tempo,
possuindo data limite para ser cumprido.

O objetivo do projeto sempre deve levar o projeto da situao atual, com


demandas no atendidas, para uma situao futura de benefcios obtidos a
partir do cumprimento do objetivo. Dessa forma, o objetivo do projeto deve
ser a ponte que leva a organizao de uma situao com necessidades no
atendidas para uma situao em que apresente uma melhoria de coisas boas
(aumento de clientes, aumento de receita, aumento de lucro, melhoria da
imagem) ou reduo de coisas ruins (reduo de custos, de retrabalho ou de
recursos necessrios).

10

A abertura do projeto tambm 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 incio do projeto e dando autoridade ao
gerente. Existem aberturas formais, com a emisso do Termo
de Abertura e reunio envolvendo todos os stakeholders.
Existem projetos em que a abertura feita em vrias etapas,
com reunio interna, reunio com cliente e emisso do Termo
de Abertura formal assinado por todos. No 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 certido de nascimento do mesmo.
Na PM Story, a abertura aconteceu de maneira informal no
incio da histria. Depois houve uma reunio onde vrios outros
detalhes a cerca do projeto foram definidos, com a participao
de todos os stakeholders e equipe. Essa foi uma reunio formal
de abertura, e aproveitou-se o momento para colher mais
informaes que deram base para o plano do projeto.

11

Identificao dos stakeholders


Antes de acontecer a reunio formal de abertura, a Fabig procurou saber
quais pessoas e reas estariam envolvidas, podendo afetar ou serem
afetadas pelo projeto. Como o projeto significa mudana, necessrio
que o gerente de projetos tenha a capacidade de lidar com aspectos
humanos e comportamentais envolvidos com a mudana. O benefcio de
qualquer iniciativa nova implantada nas organizaes no se d apenas
pela implementao tcnica, mas tambm pelo seu pleno uso. Para que se
atinja esse objetivo, necessrio trabalhar tambm as pessoas envolvidas
com a mudana.
Alm do gerente de projetos, em qualquer processo de mudana
fundamental e crtica a existncia de um patrocinador, tambm conhecido
como sponsor, que quem d legitimidade mudana. No existe
mudana bem sucedida sem patrocinador, pois ele quem fornece
recursos, financeiros ou no, para o projeto. O presidente da empresa que
solicitou a nova filial de Viosa era o sponsor desse projeto da PM Story.

12

As pessoas, grupos de pessoas e organizaes que esto envolvidas no projeto


ou cujos interesses possam ser afetados de forma positiva ou negativa com o
resultado da execuo ou concluso do projeto so chamadas de envolvidos,
interessados ou stakeholders. Eles podem tambm exercer influncia sobre o
projeto e seus resultados.
Atravs da conversa com o Lopes, a Fabig conseguiu identificar o stakeholders
externos, ou seja, aquelas reas ou pessoas que no produziam entregas no
projeto, mas que poderiam afetar ou serem afetadas pelo projeto.

13

Atravs da mesma conversa com o Lopes, a Fabig tambm identificou aquelas


reas ou pessoas que seriam responsveis por produzir alguma entrega no
projeto. Essas pessoas ou reas faziam parte da equipe. Apesar de estarmos
na iniciao do projeto, vrias informaes de planejamento podem ser
levantadas, e a equipe foi uma delas.

14

No captulo 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 captulo 7 falamos sobre a estrutura organizacional do projeto e explicamos mais detalhadamente sobre a equipe e stakeholders da PM Story.
Para a implantao de um novo projeto, necessrio identificar todo o universo de stakeholders e analisar sua posio perante o projeto. A posio do stakeholder
pode ser analisada com base no seu grau de interesse e no seu poder de influncia no projeto. Identificando essas duas variveis, possvel definir estratgias
de como lidar com as pessoas. medida que a Fabig interagia com essas reas e pessoas, mais informaes a respeito delas eram obtidas. Com isso, foi possvel
elaborar o grfico de stakeholders e identificar quem tinha interesse positivo ou negativo no projeto, bem como sua influncia nos resultados do projeto.

15

Por que realizar uma anlise 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 relaes que podem ser construdas para
viabilizar coligaes de apoio.

Por que avaliar o interesse de cada stakeholder?

O sucesso do projeto e particularmente importante para alguns


stakeholders (por exemplo, os beneficirios 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 influncia/importncia/poder de cada


stakeholder?

Alguns stakeholders detm maior poder sobre as decises de um projeto


e podem exercer um controle que influencie o desenho, implementao
e resultado desse projeto. A influncia pode ser negativa ou positiva.

16

A reunio formal de abertura do projeto PM Canvas


Na reunio formal de abertura do projeto toda equipe, j identificada anteriormente,
participou. O objetivo dessa reunio era, alm de reforar e comunicar a todos a justificativa,
objetivo e benefcios esperados, fazer com que todos compreendessem a lgica do projeto
e esclarecer as informaes importantes para sua conduo, especialmente a declarao do
escopo. Isso foi feito atravs do preenchimento do Project Model Canvas do projeto.

17

O Project Model Canvas (www.pmcanvas.com.br)


uma metodologia de gerenciamento de projetos
em que uma tela com as principais informaes
do projeto preenchida de forma colaborativa. No
vdeo da PM Story, o PM Canvas est sendo usado
para abrir formalmente o projeto junto a todos os
participantes, como tambm para obter informaes
crticas que do respaldo ao planejamento
detalhado, feito mais adiante. Cabe ressaltar que
nesse momento o presidente da empresa tambm
deu autoridade Fabig para gerenciar o projeto.

Dentre as principais informaes necessrias ao


planejamento do projeto, o produto do projeto
merece destaque. O produto a sintetizao sobre
o que ser entregue para o cliente. O sucesso do
projeto medido, entre outros critrios, pela entrega
do produto completo, com todos os requisitos. Os
requisitos so as necessidades do cliente em relao
s especificidades do produto. So as qualidades do
produto, consideraes a respeito do desempenho,
confiabilidade, entre outras.

18

A Fabig tambm deixou claro nessa reunio o contra-escopo do


projeto, ou seja, as excluses, o que no fazia parte do escopo que
ela tinha que entregar. O seguro da nova filial, de responsabilidade da
rea financeira, a parte fiscal relacionada obteno de licenas e o
projeto contra incndio, de responsabilidade da rea de patrimnio,
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 Patrimnio foram consideradas stakeholders externos. Eles
deveriam ser informados sobre a situao do projeto para executarem
suas respectivas atividades.
Outras duas informaes que impactam diretamente o planejamento
do projeto so as premissas e restries.

As premissas so fatores assumidos como verdade para a execuo


do projeto. Normalmente so assumidas pela equipe do projeto
sobre o mundo externo e por isso o projeto no 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.
.

19

As restries so fatores que limitam as opes da equipe do projeto


e dos quais o projeto tem o controle. Elas podem ter origens internas
ou externas, normalmente so determinadas pelo cliente, e esto
relacionadas a limitantes de custo, prazo ou recursos do projeto. Caso
o projeto no consiga atender uma restrio, devemos verificar se ela
pode ser negociada. Existem restries que no 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 satisfaa as restries, sob a pena de o
projeto ser invivel.
.

20

A partir do produto, requisitos e disponibilidade da equipe,


possvel definir as grandes entregas que o projeto deve ter.
importante esclarecer que os requisitos so 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 so
estabelecidas pela equipe, elas so um desmembramento do
produto, e cada entrega deve ter um representante da equipe
responsvel por produzi-la.

Na reunio de abertura formal da PM Story, foi identificado


que a filial deveria ter uma identificao visual grande e
elegante do lado de fora. A rea de Marketing responsvel
pela identificao visual e foi inserida na equipe to logo esse
requisito foi levantado. Essa rea no tinha sido inserida antes,
visto que os requisitos foram melhor explicados nesta reunio.
Com isso, duas entregas foram criadas de responsabilidade do
Marketing: Contratao da identificao visual e Instalao da
identificao visual.

21

Por fim, a linha do tempo foi estabelecida para cada entrega. O


objetivo da linha do tempo nesse momento do projeto no criar um
cronograma detalhado e sim fazer uma estimativa de alto nvel do tempo
demandado por cada entrega e do momento em que essas entregas
estariam prontas. Os custos tambm foram estimados apenas para
as entregas que consistiam de compra de mveis e equipamentos e
contrataes de pessoal. O custo das outras entregas estava relacionado
ao esforo da equipe interna na execuo das atividades para produzir as
entregas e no foi contabilizado.

22

A reunio de abertura foi finalizada com o PM Canvas totalmente preenchido e integrado. Dessa reunio, as principais informaes relacionadas declarao do
escopo do projeto foram levantadas. A principal vantagem do uso da metodologia do PM Canvas foi a oportunidade de esclarecer as informaes do projeto de forma
colaborativa, onde todos pudessem contribuir e questionar.

A abertura do projeto deve ser feita para


todos os interessados, de preferncia
presencialmente. O momento da abertura
do projeto uma excelente oportunidade
para esclarecer pontos obscuros do
projeto e complementar informaes. Isso
reduz substancialmente as solicitaes
de mudanas futuras, bem como
cancelamentos. Alm 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.

23

Captulo 3 O planejamento do projeto


O plano formal e descritivo do projeto foi elaborado pela Fabig com a
ajuda do Lopes, de informaes histricas e com a ajuda de todos os
envolvidos para definir o escopo, cronograma, responsabilidades, riscos,
comunicaes, entre outras informaes relevantes. O plano integrado,
com todas as informaes consistentes entre si, s ficou pronto aps uma
srie de interaes e validaes com pessoas diferentes.
O envolvimento de todos os interessados no projeto nos processos de
planejamento cria um ambiente propcio contribuio de todos, com
seus diferentes pontos de vista, suas diferentes experincias e expectativas,
gerando criao a partir das diferenas.
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 reunio de abertura
formal, quando o PM Canvas do projeto foi desenvolvido.
Como o projeto tinha uma complexidade que no podia ser ignorada,
com uma equipe de treze pessoas / reas, dentre as quais alguns
opositores dentro da organizao, muitos fornecedores externos e
praticamente todos fora da rea de influncia da Fabig, ela optou
por desenvolver documentao formal e detalhada que a auxiliasse a
monitorar o projeto durante a execuo.

24

Dessa forma, a partir dos requisitos levantados e das grande entregas definidas no PM Canvas durante a reunio de abertura formal, a especificao do
escopo e estrutura analtica do projeto (EAP) foi desenvolvida.
Na especificao (ou declarao) do escopo, praticamente todas as informaes levantadas durante a reunio do PM Canvas so formalizadas e
complementadas, caso mais detalhes a cerca do projeto apaream. Uma sugesto de declarao do escopo apresentada abaixo.

1. Sumrio executivo

a. Justificativa para sua realizao


b. Objetivo SMART do projeto
c. Requisitos do produto, resultado ou servio
d. Especificaes tcnicas, funcionais e operacionais
c. Benefcios esperados

2. Lista das principais entregas do projeto


3. Premissas

4. Restries

5. Excluses do projeto

6. Marcos do projeto / cronograma


7. Estimativas de custos
8. Principais riscos

25

A EAP uma estrutura hierrquica, utilizada em um projeto para definir o trabalho do projeto em termos de suas entregas bem como na decomposio das
suas entregas em componentes. Ela pode ser vista como uma estrutura nica de explicao do projeto. Neste sentido, deve informar, em uma nica folha,
o escopo do projeto.
A decomposio da EAP consiste em ir detalhando os subprodutos em componentes menores, at que eles estejam em um nvel de detalhe que permita o
gerenciamento (planejamento, execuo e controle) do trabalho do projeto.

26

A partir da EAP, e considerando a equipe j identificada durante a iniciao 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 restries do projeto, os responsveis
por execut-las, as duraes e restries de calendrio foram definidos. As fases do projeto foram representadas no cronograma de forma coerente com o
primeiro nvel de decomposio da EAP.
Um dos pontos cruciais na elaborao do cronograma a estimativa dos prazos das atividades, que impacta diretamente na estimativa do prazo do projeto
inteiro. Neste projeto, a Fabig no teve problemas em relao s estimativas porque ela contou com a organizao da equipe da Charlote, que guardava as
duraes e custos de projetos anteriores desenvolvidos com os mesmos fornecedores que iriam participar do projeto da Filial de Viosa. Alm disso, o Lopes,
que dava assistncia Fabig nas atividades de
gerenciamento de projetos, tambm ajudou a estimar
os prazos das atividades da equipe interna.
importante lembrar que estimativas de prazos so
projees futuras. S sabemos exatamente a durao
de uma atividade depois que ela aconteceu. Podemos
estimar as duraes das atividades com maior ou
menor preciso, e existem diversas tcnicas para isso.
O risco inversamente proporcional preciso, ou
seja, quanto maior a preciso da estimativa, menor
o risco. Porm, pode sair caro para o projeto fazer
estimativa com grande preciso, pois isso implica em
um esforo maior e tcnicas mais sofisticadas. Dessa
forma, o custo diretamente proporcional preciso.
A equipe do projeto deve sempre equilibrar preciso x
custo x risco.
As grandes etapas do projeto so apresentadas no
cronograma resumido ao lado.

27

O cronograma detalhado apresentado a seguir:

28

No cronograma, todas as reas e pessoas responsveis por executar


as atividades foram explicitamente associadas s suas atividades
correspondentes. Alm disso, uma seo 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.

29

A animao da PM Story no deixa claro o planejamento detalhado


dos custos do projeto e fez a estimativa de alto nvel apenas para os
custos de contratao e aquisio no momento da reunio do PM
Canvas. Atravs da numerao dos itens de custo no PM Canvas,
pode-se associar a quais entregas os custos esto relacionados. A
Fabig mencionou durante o planejamento do projeto que usou
informaes histricas de projetos anteriores da Charlote para
estimar duraes e custos das atividades do projeto.

30

As principais comunicaes formais


do projeto foram planejadas. Todos os
envolvidos no projeto devem entender
como as comunicaes afetam o projeto
como um todo. Os gerentes de projetos
podem gastar um tempo excessivo na
comunicao com todos os interessados.
Dessa forma, se houver um alinhamento
durante a fase de planejamento em
relao s necessidades de informaes
dos stakeholders, o momento e a forma
com que as informaes devem ocorrer, o
tempo e esforo gasto nas comunicaes
pode ser otimizado.
O planejamento das comunicaes, em
linhas gerais aborda qual informao
necessria e deve ser comunicada, quem
o responsvel por prover a informao, a
quem ele deve a informao, de que forma
ela deve ser comunicada e quando.

31

Para que no houvesse falhas de


comunicao, todos os envolvidos no
projeto foram identificados e listados, bem
como seus contatos.

32

Os principais riscos do projeto foram levantados. Riscos so as incertezas do projeto, so eventos que podem ou no ocorrer. Caso ocorram, podem trazer
impactos positivos ou negativos ao projeto. Os riscos que trazem impactos positivos so denominados oportunidades. Os riscos que trazem impactos negativos
so denominados ameaas. Muitas vezes dedicamos esforos 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.

33

As origens ou fontes dos riscos podem ser as mais diversas


possveis. Podemos ter riscos relacionados equipe desmotivada
ou incapacitada, a requisitos mal levantados, a projeto mal
gerenciado, a fornecedores problemticos, a clientes ausentes,
bem como a fatores organizacionais.
Para todos os riscos, uma anlise qualitativa deve ser feita.
Essa anlise serve para priorizar os riscos. Dependendo da
complexidade e tamanho do projeto, a lista de riscos pode ser
imensa e podemos no dispor de brao para gerenciar todos
eles. Por isso a priorizao importante. Para fazer a priorizao
dos riscos do projeto da nova filial de Viosa, a Fabig usou uma
escala de 1-5 para definir tanto probabilidade quanto impacto. A
multiplicao dos dois valores gerou o grau de exposio do risco.
Riscos com maior grau de exposio era priorizados em relao
aos riscos com menor grau de exposio.
Para cada risco, aes para mitigar (reduzir) a causa ou a
consequncia foram estabelecidas, bem como aes de
contingncia. As respostas de contingncia so 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 execuo 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 tcnicos, o risco
relacionado ao atraso desses desenhos deixa de fazer sentido.

As aquisies do projeto no foram tratadas no plano do projeto.


A contratao de fornecedores para execuo das obras era de
responsabilidade da Charlote, e a aquisio de mveis e equipamentos
era de responsabilidade da rea de compras. Dessa forma, a Fabig se
eximiu desses controles e todas as prestaes de contas referentes a
fornecedores eram feitas pelas pessoas e reas responsveis.
Da mesma forma, o planejamento e gerenciamento da qualidade no
ficaram explcitos na animao. O controle da qualidade das principais
entregas do projeto ficaram a cargo da Charlote, no caso dos desenhos
tcnicos e dos executores, como tambm a cargo da rea de Compras,
responsvel por adquirir mveis e equipamentos.

34

A reunio de kick-off
Ao final do planejamento do projeto, a reunio de kick-off
foi feita. A reunio de kick-off ocorre antes da execuo 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 rpido. Durante essa reunio, alguns detalhes do
projeto integrado ainda podem ser repassados e novas
informaes que podem levar ao replanejamento podem
ser levantadas.
No caso da PM Story, por exemplo, a rea de marketing
levantou informaes histricas a respeito do atraso
na instalao da identificao visual e isso levou ao
replanejamento de uma atividade do cronograma, bem
como reviso de um risco do projeto. Essas observaes e
questionamentos a respeito do plano por parte da equipe
so importantes, pois no momento em que a equipe se
compromete com o plano antes da execuo ela deve
acreditar que o plano realista e pode ser executado
nas condies 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.

35

Captulo 4 A integrao das restries do projeto


Na PM Story mencionado que, at o plano integrado e consistente do
projeto estar pronto, a Fabig precisou de envolver e consultar vrias pessoas
para estimar esforos e custos, colocar atividades para serem executadas
em paralelo, alinhar responsabilidades, identificar donos dos riscos, validar
comunicaes, entre outras questes 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 so as chances de
alteraes futuras no plano. Alteraes no plano do projeto durante a execuo
so inevitveis na maioria das vezes, devido a novos requisitos que surgem,
mudanas de mercado ou organizacionais que impactam no projeto. Muitas
vezes no possvel evitar algumas alteraes, mas esforos devem ser feitos
para minimiz-las.
O primeiro esforo para minimizar a possibilidade de alteraes futuras
no plano do projeto elaborar um plano realista, com a colaborao e
concordncia de todos de que o plano factvel dentro dos recursos que a
organizao dispe 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 restries impostas no projeto, com os recursos de tempo, pessoas,
materiais e dinheiro que dispomos. Recursos que so sempre escassos, por sinal.
No, isso no 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.

36

Abordar e explicitar todos os requisitos do projeto no tarefa


fcil. Primeiro porque ningum dispe de tempo para levantar e
validar os requisitos. Tampouco de elaborar cronograma, plano de
riscos, comunicaes, dentre outros. A ansiedade de comear a
executar o projeto to grande que muitas vezes o planejamento,
que deve ser totalmente norteado pelas necessidades dos
clientes, relegado. Mas espere um pouco. Se um critrio que
define o sucesso de um projeto entregar valor, atender s
necessidades do cliente, como sua execuo pode ser iniciada
antes de determinar essas necessidades? Qual a justificativa de
no termos tempo para levantar requisitos se so justamente eles
que nortearo o planejamento de todo projeto? Se a justificativa
comear o projeto mais rpido, devemos ter em mente que,
no momento de levantamento de requisitos, j comeamos
o projeto. E uma lista incompleta de requisitos gera um plano
incompleto e gera, necessariamente, solicitaes de mudanas
ao longo da execuo do mesmo. Quanto mais solicitaes de
mudanas ao longo da execuo, maior ser o prazo para finalizar
o projeto dentro do escopo, que ser constantemente alterado.
Dependendo do momento em que as mudanas forem
solicitadas, ser necessrio retrabalho para atender solicitao de
mudana. Isso vai fazer o projeto custar mais, e gastar mais tempo
tambm, pois atividades que j foram realizadas tero que ser
executadas novamente para atender mudana.

37

Muitas vezes o levantamento de requisitos e, consequentemente, o


planejamento do projeto desprezado porque um prazo desafiador
imposto pelo cliente durante a contratao do projeto. Mas devemos
entender o conceito de restries do projeto, que esto relacionadas
entre si.
Todo projeto deve entregar, a partir de um conjunto de requisitos do
cliente, um determinado escopo. Os requisitos so as necessidades, a
demanda que o cliente tem em relao ao produto, servio ou resultado
que o projeto deve gerar. E todo projeto possui recursos finitos de
pessoas, materiais, mquinas 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 esto
intimamente relacionados.
Se um escopo fechado com um grau de qualidade desejado e
os custos so controlados, ento conseguimos atender a essas trs
restries dentro de um determinado prazo. Se o cliente deseja que o
prazo seja menor, no h mgica 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 relao a satisfao do cliente.

38

Por outro lado, se uma mudana solicitada atravs de


um aumento de escopo, natural que essa mudana
impactar o aumento dos custos do projeto, pois
precisaremos de recursos para executar as atividades
relacionadas ao escopo dessa mudana. O prazo do
projeto tambm poder ser impactado. A no ser que
possamos realizar atividades em paralelo ou retirar outra
parte do escopo cujos esforos sejam compatveis com o
que estamos adicionando.
O conceito de restries do projeto e como elas se
relacionam crucial para entender e explicar a lgica
do projeto aos stakeholders. O PM Canvas, usado na
abertura da nova filial de Viosa da Pm Story, um timo
instrumento que facilita a visualizao de relacionamento
entre as restries 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 orientao para reduzir custos, por exemplo, ser
necessrio reduzir o grau de qualidade com que uma
entrega feita ou eliminar uma entrega. A lgica do
projeto fica clara e atravs das informaes integradas
possvel justificar as decises de planejamento.

39

Captulo 5 A execuo e monitoramento do projeto


Na execuo do projeto, grande parte dos
esforos partem da equipe do projeto, que
executa atividades de construo do produto,
desenvolvimento do servio ou resultado a que o
projeto pretende. Durante essa etapa, o gerente
do projeto tem a responsabilidade de mobilizar e
gerenciar a equipe e o trabalho do projeto.
Durante a execuo, a Fabig monitorava as
atividades e problemas do projeto junto equipe e
reportava, em marcos especficos, o desempenho
do projeto junto ao presidente.
O monitoramento das atividades junto equipe
tratava de questes do dia-a-dia do projeto, de
verificao do cumprimento das atividades do
cronograma, dos porqus do no cumprimento, da
resoluo do problemas que surgiam, da verificao
dos riscos, do estabelecimento de planos de aes.
No contexto da PM Story, esse acompanhamento
acontecia semanalmente. Nesses momentos, o
projeto era regado, cuidado nos detalhes, a grama
aparada, as flores podadas. Questes midas so
tratadas aqui junto a quem estava trabalhando nas
atividades e entregas do projeto.

40

O acompanhamento de marcos junto ao presidente


era diferente. Ele acontecia em momentos mais
espaados e tratava principalmente de verificar se as
entregas planejadas para o marco foram feitas, alm
de fornecer uma informao geral da situao do
projeto. Nesse acompanhamento de marcos, alm
de verificar as entregas, pode-se fazer uma anlise
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 comparao do que foi
produzido em termos de escopo, gasto em termos
de tempo e recursos em relao ao planejado?
Qual foi a variao? Essa variao est dentro
das margens de variao permitidas? Com base
nessas informaes, vamos continuar ou melhor
cancelarmos, ou talvez renegociarmos os objetivos
do projeto?

41

O acompanhamento do projeto pode assumir


vrios vieses. Muitas vezes vemos gerentes de
projetos elaborando um nico tipo de relatrio de
acompanhamento e enviando a pessoas e reas
com interesses diferentes a cerca do projeto. Ou
seja, so fornecidas informaes que no interessam
a audincia. Fabig emitia relatrios diferentes
dependendo do seu pblico. Junto equipe,
o acompanhamento era detalhado, a nvel de
atividades, problemas, riscos. Com o presidente, as
informaes era relacionadas a entregas, previso de
trmino e custos.
Alm das atividades de monitoramento e report
do projeto, durante a execuo a Fabig tambm
controlava as mudanas que poderiam surgir
no projeto. A principal mudana que surgiu
explicitamente no contexto da PM Story foi uma
solicitao do presidente que impactava em 7
dias e R$10.000 a mais. A mudana foi recebida
formalmente, os impactos foram avaliados e
apenas depois da aprovao da mudana 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.

42

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, no precisamos fazer nenhum esforo para isso. E todas as
informaes a respeito do projeto esto muito bom conectadas. Sem os
requisitos no conseguimos elaborar um plano. Por mais especialista que
voc seja em definir um bom escopo, cronograma e oramento, envolver
as pessoas, cuidar dos riscos, se no dispe de todas as necessidades do
projeto formalizadas atravs dos requisitos, o projeto no entregar o valor
que deveria. E se voc no tem um plano real, suas chances de concluir um
projeto com sucesso so praticamente nulas.
Por outro lado, apenas um bom plano realista no lhe garante uma boa
entrega. Tem que cuidar, tem que vigiar durante a execuo. Cuidar
significa verificar se as coisas esto acontecendo conforme o plano.
Comparar. Identificar desvios e o tamanho desses desvios. Saber os
porqus. Tomar aes. Evitar novos desvios. Prever riscos e se precaver
em caso de impactos negativos que eles possam gerar. Isso exige muita
organizao, sentido de controle, aferio. Exige cuidado com o projeto.
Exige saber onde buscar as informaes de execuo, como organizlas e principalmente como us-las para te ajudar a entregar dentro da
performance desejada.

Antes de conhecer qualquer tarefa, temos


de aprender a fazer a pergunta: De que
tipo de informao eu necessito, sob
que forma e quando? [...] As perguntas
seguintes que as pessoas precisam
aprender a fazer : A quem devo que tipo
de informao? Quando e onde
Peter Druker

Nesse ponto cabe ressaltar que o gerenciamento de um projeto envolve


dispor das informaes corretas, atualizadas e no tempo certo para
process-las, tomar aes e decises, e entregar os resultados das suas
aes a quem precisar.
Ningum disse que fcil. Mas certamente no exige habilidades de
nenhum gnio.

43

Captulo 6 O encerramento do projeto


A PM Story no deixa claro sobre as atividades que a Fabig fez
no encerramento do projeto. Foram destacados apenas o
coquetel de comemorao, evento muito importante por sinal,
e o feedback do presidente em relao ao resultado do projeto.
Apesar de muitos projetos serem abandonados ao invs de
finalizados, muitas aes pertinentes acontecem nessa etapa
do projeto:
Aceitao formal do cliente ou patrocinador.
Documentao das lies aprendidas.
Arquivamento de todos os documentos relevantes.
Reviso ps-projeto.
Registro dos impactos da adequao de qualquer
processo.
Aplicao das atualizaes apropriadas aos ativos de
processos organizacionais.
Encerramento das aquisies.
Alm disso, todas as pendncias devem ter sido resolvidas, os
recursos formalmente liberados e o encerramento formalmente
comunicado.

44

Captulo 7 A estrutura organizacional em que o


projeto est inserido
Os projetos normalmente fazem parte
de uma organizao que maior que o
projeto. A maturidade da organizao
em relao 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 organizao
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 intermedirias.
A estrutura matricial da organizao
onde a Fabig trabalha tipicamente
matricial.

45

A empresa est organizada por departamentos (TI, Projetos Civis,


Comercial, Administrativo), e cada departamento possui funcionrios
com a mesma especialidade. Projetos podem surgir dentro dos
departamentos, como tambm pode acontecer de um projeto ser
iniciado (como foi o caso da nova filial de Viosa), e a equipe se formar a
partir de vrios 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 questes pertinentes
ao projeto, mesmo a Fabig no possuindo cargo de coordenao na
estrutura hierrquica da empresa. Basicamente as entregas deles diziam
respeito aos desenhos tcnicos da nova filial.
Dentro da gerncia comercial, uma pessoa do departamento de
marketing tambm fazia parte da equipe porque estava responsvel
pela contratao e instalao da identificao visual. Dentro da
gerncia administrativa, uma pessoa do departamento de RH tinha a
responsabilidade de selecionar, contratar, integrar e treinar os novos
funcionrios da filial. E o departamento de compras, tambm dentro da
gerncia administrativa, tinha a responsabilidade de orar e comprar os
novos mveis equipamentos.

Os executores dos projetos civil, hidrulico, climatizao, dados e voz


tambm so considerados equipe na medida em que produzem
entregas no projeto, mesmo sendo fornecedores externos
organizao. 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 no faziam parte da equipe pois no produziam entregas
do escopo. Esse era o caso da rea fiscal, que cuidava das licenas
ambientais, do financeiro, que cuidava do seguro e patrimnio, que
cuidava do projeto contra incndio. Esses trs itens estavam fora do
escopo do projeto, eram excluses do projeto, mas essas reas tinham
que ser informadas do andamento do projeto para cumprirem com
suas responsabilidade. O fato de serem stakeholders externos tambm
fazia com que uma srie de premissas relacionadas a eles fossem
assumidas. Por exemplo, era assumido que a licena da Prefeitura, de
responsabilidade do fiscal, seria obtida para a construo da filial. O
presidente da empresa, demandante e sponsor do projeto, tambm
era um stakeholder externo pois no produzia entregas do projeto, mas
patrocinava o projeto provendo recursos para a execuo do mesmo.

46

Captulo 8 O sucesso do projeto


Sucesso significa diferentes coisas para diferentes pessoas. Um
arquiteto pode considerar sucesso em termos de aparncia
esttica, um engenheiro em termos de competncia tcnica, um
contador em termos de dlar gasto no oramento, um gerente de
recursos humanos em termos de satisfao dos empregados. Os
executivos avaliam seu sucesso em termos de aes 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 relao
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 no recebe
o crdito devido pelo sucesso. Ou seja, quando o projeto termina
bem, ningum 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 execuo do mesmo.

47

Farias e Almeida (2010) publicaram o artigo intitulado Definindo o sucesso


de projetos, onde fizeram um apanhado sobre os diversos critrios usados
para definir sucesso de projetos. Ao todo, os autores encontraram oito
definies diferentes para sucesso de projetos! Em muitas dessas definies,
os critrios de sucesso mais usados foram:
Eficincia do projeto: alcances de escopo, custo e prazo, se o projeto
for completado de acordo com o plano.
Impacto e satisfao do cliente: percepo das principais partes
interessadas em relao ao projeto. Essa dimenso especifica como
os resultados do projeto melhoraro a vida e os negcios e como as
necessidades dos clientes sero atendidas.
Impacto no time: reflete como o projeto afetar seus membros
em termos de satisfao do time, moral, lealdade do time com a
organizao e a reteno depois que ele for finalizado, bem como
o investimento indireto da organizao no time, seu aprendizado,
crescimento e capacidades.
Sucesso direto e nos negcios: impacto direto e imediato do projeto
na organizao principal: nvel de vendas, receitas, lucros, fluxo de
caixa e outras medidas financeiras.
Preparao 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. Satisfao das partes interessadas no que se refere conduo
do projeto.
Sucesso do produto: ir ao encontro dos objetivos estratgicos da
organizao, satisfazer as necessidades dos usurios, satisfazer as
partes interessadas no que se refere ao produto.

Como podemos ver, a definio de sucesso pode envolver uma srie de


critrios, que muitas vezes podem ser diferentes para as diversas pessoas
envolvidas no projeto. Como ento 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 so os
critrios de sucesso deles. A cada mudana ou marco, confirme novamente
quais so os critrios de sucesso.
Uma abordagem integradora de sucesso de projetos pode ser resumida da
seguinte forma:

Um projeto de sucesso aquele que concludo


dentro do prazo e dos custos estabelecidos conforme
planejado, e em um nvel de qualidade de seus
resultados e produtos que leve plena satisfao de
seus clientes e atendimento objetivos de negcio!

48

Captulo 9 Concluses
Todas as pessoas e organizaes desejam finalizar seus projetos atendendo todas as
necessidades para as quais eles foram iniciados, dentro dos prazos impostos cliente, sem
retrabalho, utilizando o menor nmero de recursos possvel. Ou seja, todos os clientes querem
comprar sonhos e muitas vezes, mesmo sem dispor de todas as informaes para isso,
acabamos vendendo o sonho, sabendo que no 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
informaes do projeto e como us-las para conduzir bem o projeto. No se sabe usar as
restries 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 no tem a pretenso de agradar a todos.

Os clientes s deixaro de comprar sonhos quando deixarmos de vender fantasia.


Nenhum cliente vai descobrir que no vendemos milagres se no deixarmos de
tentar fazer milagres. Vender sonho e entregar realidade s tem uma consequncia:
fazer os clientes pensarem que somos incompetentes. Tornar o gerenciamento
de projetos rea sria e confivel depende de uma nica coisa: vender realidade e
entregar realidade.
Paulo Mrcio Brandi Rezende

Para todos os prximos 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!

49

Referncias
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 organizaes gerenciam seu capital intelectual. Rio de Janeiro:
Campus, 1998.
DRUCKER, Peter. Sociedade ps-capitalista. 7. ed. So Paulo: Editora Pioneira, 1998.
FARIA FILHO, J., R.; ALMEIDA, N. O. Definindo sucesso em projetos. Revista de Gesto e Projetos - GeP, So Paulo, v. 1, n. 2, p 68-85, jul./dez. 2010.
FINOCCHIO JNIOR, 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 Edio. Newton
Square, PA, EUA: 2012.
VARGAS, Ricardo Viana. Gerenciamento de projetos: estabelecendo diferenciais competitivos. 6. ed. Rio de Janeiro: Brasport, 2006. 250 p.

50

51

Potrebbero piacerti anche