Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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.
Sumrio
Cap. 1 Introduo
24
36
40
44
45
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:
Boa leitura!
Abertura do projeto
10
11
12
13
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
16
17
18
19
20
21
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.
23
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
4. Restries
5. Excluses do projeto
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
28
29
30
31
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
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
36
37
38
39
40
41
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.
43
44
45
46
47
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.
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