INTRODUÇÃO

Todos nós batalhamos por projetos pessoais. Fazemos uma separação,

os projetos desafiadores e arriscados são separados da vida corriqueira e
usamos outra maneira de gerir esses projetos, mesmo sem perceber. É
razoável imaginar que pessoas muito empreendedoras acalentam mais
projetos pessoais. Em um horizonte de médio prazo, as suas vidas passam
por significativa transformação. O mesmo ocorre nas organizações.
Pessoas que atuam no setor privado, público ou social costumam
liderar projetos: as realizações temporárias, desafiadoras e arriscadas que
promovem transformação na organização. Contudo, poucos
profissionais foram educados no gerenciamento de projetos.
A especialização em projetos amplia a mobilidade vertical de
profissionais, com alvo em posições de direção, e amplia a mobilidade
horizontal, uma vez que esses profissionais poderão atuar em quaisquer
tipos de projetos. Além disso, especializar-se em projetos amplia a
capacidade empreendedora, gerando implicações tanto na vida pessoal
quanto na profissional.
SUMÁRIO
MÓDULO I – INICIAÇÃO ........................................................................................................................ 9

PROJETOS PESSOAIS .......................................................................................................................... 9

Ambições e transformações..................................................................................................... 9
Gerenciar projetos é essencial ............................................................................................... 10
Projetos transformam as nossas vidas ................................................................................. 10
Projetos são únicos, desafiadores e temporários ............................................................... 13
MAPA MENTAL DE PROJETOS ......................................................................................................... 14
Como fazemos na vida pessoal? ............................................................................................ 14
Projetos pessoais e profissionais .......................................................................................... 14
A metodologia é a mesma ...................................................................................................... 14
Benefícios dos projetos ........................................................................................................... 15
CONCEITO E CICLO DE VIDA DE PROJETOS .................................................................................. 15
Iniciar ou acabar? ..................................................................................................................... 15
Método não é lei ...................................................................................................................... 15
Ciclo de vida complexo ........................................................................................................... 16
Experimente e crie o seu repertório ..................................................................................... 19
TERMO DE ABERTURA DO PROJETO .............................................................................................. 19
O que é o projeto? ................................................................................................................... 19
Um esquemático ...................................................................................................................... 20
Termo de abertura: solução essencial .................................................................................. 20
Canvas, abordagem fecunda .................................................................................................. 21
Modo sintético e artístico de elaborar .................................................................................. 22
Termo de abertura não é plano do projeto ......................................................................... 24

MÓDULO II – PLANEJAMENTO............................................................................................................ 25

PROCESSOS DE GESTÃO PMBOK GUIDE ........................................................................................ 25

MULTIDISCIPLINAR .......................................................................................................................... 25
DEFINIÇÃO CASO A CASO ............................................................................................................... 26
PROCESSOS DE GESTÃO ................................................................................................................. 26
HIPERCOMPETÊNCIA ....................................................................................................................... 34
ABORDAGEM ÁGIL DE GERENCIAMENTO DE PROJETOS ............................................................ 35
Substitui ou complementa? .................................................................................................... 35
Da engenharia ao desenvolvimento de softwares ............................................................... 35
Questão de mentalidade, não de ferramentas ................................................................... 36
Cada coisa no seu lugar .......................................................................................................... 38
PLANO DE GERENCIAMENTO DO PROJETO .................................................................................. 39
Iniciar sempre, acabar talvez.................................................................................................. 39
Sem planos, tudo é aventura ................................................................................................. 39
 Síntese de muitos planos ........................................................................................................ 40
O que não se deve fazer ao planejar .................................................................................... 41
ESTRATÉGIAS DE EXECUÇÃO DE PROJETOS .................................................................................. 41
Questão de sagacidade ........................................................................................................... 41
Questões estratégicas ............................................................................................................. 42
Combine mais de uma estratégia .......................................................................................... 42
Primeiro a estratégia, depois a tática.................................................................................... 46
ESCOPO EM PROJETOS .................................................................................................................... 46
Você conhece o conceito de escopo? .................................................................................... 46
Necessário gerir escopos ........................................................................................................ 46
“Esculpindo” escopos............................................................................................................... 47
Sem definir não se controlam os escopos ........................................................................... 49
GESTÃO DE INTERESSADOS DO PROJETO .................................................................................... 49
Com quem contar? .................................................................................................................. 49
Envolvidos e afetados.............................................................................................................. 49
Mais que cliente ....................................................................................................................... 49
Boa política ............................................................................................................................... 52
ESTRATÉGIA DE COMUNICAÇÃO EM PROJETOS .......................................................................... 52
Comunicação é tudo................................................................................................................ 52
Uma qualidade vasta e essencial........................................................................................... 52
Eficiência depende de planejamento: efetividade de competência ................................. 53
A verdadeira liderança comunica .......................................................................................... 57

MÓDULO III – PLANEJAMENTO: COMPLEMENTAÇÃO ...................................................................... 59

GESTÃO DE RISCOS: AMEAÇAS E OPORTUNIDADES ................................................................... 59

PRECISA DE SORTE? ......................................................................................................................... 59
DESAFIANDO DEUSES ...................................................................................................................... 60
AMEAÇAS E OPORTUNIDADES: COMO QUEREMOS RESPONDER? ........................................... 60
SAGACIDADE É ESSENCIAL .............................................................................................................. 66
GESTÃO DE CRONOGRAMA DO PROJETO .................................................................................... 67
Pontualidade ............................................................................................................................ 67
Sempre falta tempo ................................................................................................................. 67
Sistema dinâmico para assegurar pontualidade ................................................................. 67
Cronograma é um guia, não um dever ................................................................................. 70
CASO PLANO DE GERENCIAMENTO DO PROJETO ....................................................................... 70
Iniciando o projeto................................................................................................................... 70
Planejar é otimizar e antever problemas ............................................................................. 71
Plano de Gestão do Projeto SARAU ....................................................................................... 71
Sumário Executivo .............................................................................................................. 71
Plano de gestão de interessados ..................................................................................... 74
Plano de gestão da comunicação ..................................................................................... 75
 Plano de gestão de riscos .................................................................................................. 77
Plano de gestão da qualidade .......................................................................................... 78
Plano de gestão de aquisições ......................................................................................... 79
Plano de gestão de recursos humanos ........................................................................... 80
Plano de gestão de escopos.............................................................................................. 81
Plano de gestão de custos................................................................................................. 83
Plano de gestão de cronograma ...................................................................................... 83
Plano de promoção de ética ............................................................................................. 84
Anexos.................................................................................................................................. 85
Referência para controle ........................................................................................................ 85

MÓDULO IV – MONITORAMENTO, CONTROLE E ENCERRAMENTO ............................................... 87

CONTROLE E ACEITE DO PROJETO ................................................................................................. 87

Planejar mais controlar ........................................................................................................... 87
Monitorar não é controlar ...................................................................................................... 88
Monitorar e controlar para aceitar o projeto ....................................................................... 88
Revalorizando o controle ........................................................................................................ 90
CASO MONITORAMENTO E CONTROLE DO PROJETO ................................................................ 90
Executando o projeto .............................................................................................................. 90
Controle baseado em monitoramento ................................................................................. 91
Relatório de Status – 30 de junho de 2018 ........................................................................... 91
Relatório de progresso – 30 de setembro de 2018 ............................................................. 92
Relatório de tendências – 30 de dezembro de 2018........................................................... 94
Foco é o controle, não a divulgação ...................................................................................... 95
GESTÃO PELO VALOR AGREGADO (EARNED VALUE) ..................................................................... 95
Em retrospecto gastamos, e daí?........................................................................................... 95
Não um indicador para análise, mas, sim, uma filosofia de gestão ................................. 95
Valor agregado e índices de desempenho ........................................................................... 96
Agregando valor ....................................................................................................................... 99
GESTÃO DO CONHECIMENTO EM PROJETOS............................................................................... 99
Como aprender a gerenciar projetos? .................................................................................. 99
Gerir conhecimentos ............................................................................................................ 100
Gerir projetos requer gerir conhecimentos ...................................................................... 100
Confiança, contato e reconhecimento ............................................................................... 103
CÓDIGO DE ÉTICA E CONDUTA PROFISSIONAL: PMI ............................................................... 104
Ética existe?............................................................................................................................ 104
Moral não é o mesmo que ética ......................................................................................... 104
Código promove valores e condutas ................................................................................. 104
Normas elevadas que aspiramos cumprir ........................................................................ 105
MÓDULO V – EXECUÇÃO ................................................................................................................... 107

GOVERNANÇA EM PROJETOS ...................................................................................................... 107

Delegar ................................................................................................................................... 107
Governança define a gestão ................................................................................................ 108
Mais que estrutura ............................................................................................................... 108
Governabilidade requer a boa governança ...................................................................... 110
GESTÃO DE RECURSOS DO PROJETO ......................................................................................... 110
Todo tipo de recursos .......................................................................................................... 110
Trabalho em equipe não é luxo, é necessidade ............................................................... 110
Recursos físicos e humanos ................................................................................................ 111
Equipe coesa, mesmo que virtual ...................................................................................... 113
ORGANIZAÇÃO: TIPOS .................................................................................................................. 114
A sua organização é de qual tipo? ...................................................................................... 114
Somos arquitetos de organizações .................................................................................... 114
Projetos, matrizes e redes como alternativa à hierarquia .............................................. 114
Estrutura a serviço das pessoas ......................................................................................... 117
ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS (EGP OU PMO) .......................................... 118
Demasiados projetos ........................................................................................................... 118
Escritório ou pessoa?............................................................................................................ 118
Diferentes escritórios, cada qual com a sua finalidade ................................................... 119
Mais de um EGP .................................................................................................................... 120
COMPETÊNCIAS EM GESTÃO DE PROJETOS .............................................................................. 120
O que é especial merece tratamento especial ................................................................. 120
Um perfil especial de competências .................................................................................. 121
Competências brandas e duras .......................................................................................... 121
Dicas para aprimorar competências .................................................................................. 125
Dura uniformiza, branda diferencia ................................................................................... 126

BIBLIOGRAFIA .................................................................................................................................... 127

PROFESSOR-AUTOR ........................................................................................................................... 131

MÓDULO I – INICIAÇÃO

O módulo 1 introduz o conceito de projeto, com exemplos da vida pessoal e da vida

organizacional. Será o momento de formar grupos e eleger o projeto em que as técnicas serão
aplicadas.
Ao final, esperamos que você seja capaz de:
compreender que na vida pessoal os projetos promovem transformação;
compreender o conceito de projeto como oposto às atividades rotineiras e
perceber a necessidade e a forma de oficializar projetos para que sejam executados.

Projetos pessoais
Ambições e transformações
Como você realiza as suas ambições pessoais? Você teve ou tem “projetos pessoais”? O
tratamento que dispensa aos seus projetos pessoais é diferente do que dá às obrigações corriqueiras?
Por que o tratamento dado aos projetos é tão diferenciado?
Muitos não percebem o que fazem intuitivamente: filtram sonhos, elegem quais deles se
tornarão projetos, assumem compromisso de realizá-los e ainda adotam atitudes e métodos muito
diferentes da sua vida rotineira.
Hoje, você tem muitos projetos pessoais? Se os tem, significa que tem muitas ambições
viáveis; significa que tem perfil similar ao de empreendedores. Nesse caso, a sua vida se transformará
bastante no médio prazo. Reflita sobre o que e como faz nos seus projetos pessoais e pense na sua
atuação profissional: você está envolvido em projetos? Lidera projetos na organização onde atua?
Como os gerencia, do mesmo modo que nos seus projetos pessoais?
Gerenciar projetos é essencial
Muitos desejam desenvolver a atitude empreendedora, e muitas organizações incluem isso na
lista de competências organizacionais. Contudo, não basta ter a atitude de um empreendedor se
não tiver as habilidades exigidas para levar os projetos ao sucesso. É leviano incentivar as pessoas a
empreender sem lhes dar condições de método e ferramentas que lhes permitam ter sucesso como
empreendedores. É como instilar pessoas a “assumir” riscos – julgo leviandade isso.
Por isso, prefiro estimular que as pessoas tenham projetos, na sua vida pessoal e profissional.
Aprendendo a enquadrar como projetos as nossas ambições, e aprendendo a gerenciar esses projetos,
o resultado efetivo é o de ampliar a capacidade de transformação da vida da pessoa e da organização.
É a melhor maneira de incentivar o empreendedorismo.

Projetos transformam as nossas vidas

Vivemos em uma sociedade que valoriza o esforço e a ambição. Costumamos dizer sobre
quem não tem projetos pessoais: “Está deixando a vida passar”, “Não tem ambição alguma”, “Não
sabe o que quer”. Há um dito bastante popular o qual afirma que “O ser humano, para se completar,
necessita realizar três coisas na vida: ter um filho, plantar uma árvore e escrever um livro”. São
exemplos de projetos pessoais.
Mas o que são de fato os projetos pessoais? O que eles têm de tão distintivo na nossa vida? A
lista a seguir fornece exemplos. Compare-os com os seus próprios projetos pessoais:
Criar o seu próprio negócio.
Adquirir ou reformar um imóvel.
Casar e ter filhos.
Fazer uma longa viagem ao exterior.
Obter um título acadêmico, de mestre ou doutor.
Escalar posição na carreira profissional.
Projetos para o pós-emprego: atuação social, filantrópica, artística ou recreativa.

Note que criar negócio é o exemplo mais estrito de empreendedorismo, e é projeto pessoal.
Portanto, desde já enfatizo: empreendimento é sinônimo de projeto. Curiosamente, nem
empreendedores nem gestores de projetos pertencentes a organizações percebem assim, dado que
são campos que floresceram independentemente um do outro.
É curioso que para algumas pessoas casar ou ter filhos não é considerado projeto: é algo que
ocorre acidentalmente, ou então é algo que se presume que vai de fato ocorrer, sem esforço. Porém,
para a maioria, casar requer cuidadosa preparação e esforço. Isso indica a característica primordial
dos projetos pessoais: se “deixar rolar”, eles tendem a não ocorrer.

10
 Outra curiosidade: uma viagem só é considerada projeto se for longa ou a lugares exóticos.
Passar os fins de semana em um sítio ou na praia quase nunca é tido como projeto. Isso indica que
cada pessoa escolhe deliberadamente aquilo que considera projeto pessoal, isolando-o dos demais
aspectos da sua vida corriqueira.
Por que precisamos de projetos? Porque há coisas que requerem empenho pessoal: envolvem
recursos escassos e desafio arriscado – não queremos que sejam confundidos com assuntos
corriqueiros. Viajantes de negócios não relacionam viagens longas a projetos. Para um milionário,
viajar ao exterior ou adquirir um imóvel é parte do seu cotidiano, e não um projeto. Para quem
casou três vezes, o casamento seguinte será corriqueiro. Para nós, os “normais”, é preferível realizar
essas atividades na forma de projetos.
Note outra questão curiosa, retomando o exemplo de projeto relacionado a filhos. O primeiro
filho costuma ser um importante projeto da família. Desde o momento em que a mulher engravida
já prepara o enxoval do bebê. Mais tarde, o quarto do bebê é mobiliado, e o lar é preparado para
receber o bebê. Depois que nasce a criança, ainda continua o projeto: há o “diário do bebê”, tudo
é registrado em uma profusão de filmes e fotos, há festas, etc.
Curioso: nas mesmas famílias que assim procedem com o primogênito, o terceiro filho tem
tratamento distinto – há pais os quais afirmam que o seu último filho foi “criado pelos irmãos”.
Não há diferença de amor paterno, mas a diferença essencial é que o primeiro filho foi um projeto,
e o último, por nada mais apresentar de desconhecido, incorporou-se à família e foi administrado
como rotina. Portanto, todo projeto tem algo de único, inusitado ou desconhecido, e é isso que os
torna desafiadores.
Casar, viajar ou titular-se são projetos pessoais com horizonte de curto ou médio prazo. Aliás,
sempre há expectativa de prazo para os nossos projetos. Além disso, há objetivos de custo, qualidade,
desempenho e resultados esperados. Um projeto, para valer a pena, envolve objetivos claros a
perseguir. Ora, se há metas de prazo a serem realizadas, significa que os projetos são temporários e,
se são temporários, há um ciclo de vida: projetos são concebidos, evoluem até a sua maturidade,
apresentam declínio e, em algum momento, são concluídos. Note bem: para ser um projeto é
preciso que tenha uma data de término – veremos que nas organizações isso costuma ser um
problema, embora de fácil solução.
Note que não foi citado como exemplo de projeto ganhar na loteria. Se isso fosse projeto,
haveria determinação e preparo, e a elaboração de apostas somente nas condições mais favoráveis.
Há quem estude as probabilidades de acerto, as combinações mais adequadas, etc. Porém, para a
maioria das pessoas, a loteria não é projeto, é apenas um sonho (devaneio ou fantasia). Sonhar é
essencial, porque é manifestação da nossa riqueza emocional. Contudo, misturar sonhos com
realidade não é sintoma de saúde mental.
Portanto, projetos pessoais não pertencem ao cotidiano nem são sonhos. Estão a meio
caminho – podem ser considerados sonhos viáveis –, passaram pelo filtro da viabilidade, o que

11
sustenta o esforço com que são perseguidos. Assim, projetos pessoais envolvem algo único e
desafiador, embora viáveis, e desse modo só são alcançados se forem planejados.
Enquanto na vida corriqueira a surpresa é agradável porque rompe a monotonia, nos projetos
a surpresa costuma ser desastrosa e precisa ser evitada. Por isso planejamos a execução de projetos,
que não pode ser deixada ao improviso. Nos projetos sempre há riscos e incerteza, que precisam ser
enfrentados. Essa característica de envolver elevados riscos e incerteza é o que faz com que tanta
gente acalente os seus projetos pessoais solitária e sigilosamente. Não os compartilham com
ninguém, pelo temor de insucesso. Também há outro atributo que os diferencia das atividades
corriqueiras: há rituais de iniciação e de encerramento.
O que há em comum entre os exemplos de projetos pessoais comentados? Todos eles
apresentam as mesmas características:
São oportunidades que, se “deixar rolar”, tendem a não ocorrer – projetos requerem
esforço deliberado e compromisso.
Envolvem interesses elevados – vontade, ambição e preocupação com o futuro.
Não são devaneios, são sonhos viáveis em que há o compromisso de realizar.
São temporários, com ciclo de vida e horizonte de médio prazo.
Envolvem recursos escassos, o que os transforma em desafios.
São únicos, incomuns ou extraordinários.
Sempre envolvem muito risco e incerteza.
São conquistas memoráveis que geram satisfação.

Rememorando os exemplos de projetos pessoais, note que eles compõem as ações mais
especiais que protagonizamos nas nossas vidas. Por isso, a capacidade de realizar projetos com êxito
resulta na capacidade de transformar a própria vida.
Há indivíduos muito empreendedores, capazes de lidar com mais de cinco projetos pessoais
desafiadores em dado momento. Em um período de cinco a sete anos, a vida deles muda
significativamente por força dos êxitos alcançados. Pessoas razoavelmente empreendedoras lidam
com dois a quatro projetos pessoais. Pessoas pouco empreendedoras têm apenas um, ou nenhum,
projeto em andamento. Se bem que essa classificação de grau de empreendedorismo não é precisa:
há quem tenha apenas um projeto pessoal, mas tão desafiador que ocupa toda a sua energia por
décadas – e isso não retira dessa pessoa o atributo de ser empreendedora.
Porém, se temos mais de um projeto desafiador em andamento, ocorre um problema: como
repartir recursos e energia empreendedora? Surge aqui outra questão importante. Quando há
muitos projetos, mentalmente estabelecemos prioridades: maior atenção é dada às prioridades desse
portfólio. Outra questão usual: quando uma das prioridades perde viabilidade – passa o tempo e
não conseguimos viabilizar a aquisição de imóvel, por exemplo –, o que fazemos?

12
 Ocorre uma compensação psicológica. Abandonar projetos – ou, como dizemos
popularmente, abortar – causa tanta frustração, pois há o comprometimento psicológico para
realizar tal projeto, que evitamos ao máximo essa possibilidade. Se um projeto perde viabilidade,
alteramos as suas metas, prorrogando duração, ampliando orçamento, reduzindo expectativas de
resultados. Modificada alguma meta, isso nos obriga a rever as prioridades. Alterando prioridades,
privilegiamos algum projeto mais viável ou que traga mais resultados. No fim da lista de prioridades,
restarão aqueles projetos pessoais aos quais pouco nos dedicamos ou que são quase devaneios, ou
desvarios que o tempo se encarregará de eliminar.
Veremos que tal situação também ocorre nas organizações, isto é, nos projetos profissionais.
Eles têm características equivalentes às dos projetos pessoais. A metodologia que adotamos
profissionalmente para lidar com os projetos é similar à que intuitivamente adotamos nos nossos
projetos pessoais, o que veremos mais detalhadamente nos próximos módulos. Administrar
prioridades é a essência da gestão de portfólio.
E quem não tem projetos pessoais? Quer dizer que nada ambiciona? Não, mas nesse caso as
suas ambições dependem mais da sorte que do esforço pessoal. Às vezes, os ganhos caem do céu;
outras vezes, as dificuldades os levam ao inferno. O tempo passa, não sobra tempo para construir o
futuro, ocupados com seu dia a dia. Quando se dão conta, pouco realizaram.
Há momentos de balanço ou retrospectiva quando atingimos o ápice da maturidade. Nesses
momentos, só nos recordamos dos nossos projetos pessoais, dos sucessos e dos insucessos – nada
mais é lembrado. Com método, nós é que realizamos o futuro. Com método para os projetos
pessoais, nós é que estabelecemos a sorte.
Considero que a gestão profissional dos nossos projetos pessoais é a chave para a autorrealização
e a satisfação plena nas nossas vidas. Mais que credenciar para a competência em projetos profissionais,
é nos projetos pessoais que vislumbro a maior aplicação das ideias deste material.

Projetos são únicos, desafiadores e temporários

Quem já adquiriu a mentalidade de projeto percebe que a vida em si é um projeto: é
temporária, única, tem objetivos elevados, escopo progressivamente elaborado, recursos escassos,
riscos e a incerteza maior – o mistério da vida. Contudo, diferentemente dos projetos profissionais,
no projeto de vida ninguém quer terminar antes do prazo, a equipe do projeto é você mesmo, e
qualidade de vida é fundamental. O maior benefício do projeto é fomentar outros “projetos de
vida” além do seu: é o legado que deixamos aos nossos descendentes.
Que tal aplicar a metodologia de projetos em TODOS os seus projetos pessoais? Garanto
que a chance de sucesso será maior, além de criar um hábito saudável, ou seja, uma melhor prática
de gestão, que você certamente usará na sua vida profissional. Experimente, invista nisso e avalie se
o seu desempenho ao executar um projeto pessoal melhorou.

13
Mapa mental de projetos
Como fazemos na vida pessoal?
Há alguma relação entre gerenciar projetos pessoais e gerenciar projetos no mundo
profissional? De fato, as características desses dois tipos de projetos são muito diferentes? Se são, o
que diferencia a gestão de cada tipo de projeto?

Projetos pessoais e profissionais

Muitos acreditam que no plano pessoal não precisamos de disciplina, nem de registros, até
porque queremos distância da burocracia e dos controles usuais nas organizações. Contudo, são as
características dos projetos que determinam a melhor forma de lidar com eles.
Projetos pessoais e profissionais têm as mesmas características: são incomuns, únicos, temporários,
envolvem recursos escassos, representam desafios e apresentam elevado risco e incerteza. Diante dessas
características, a melhor maneira de gerir a sua execução é similar: tanto projetos pessoais quanto
profissionais requerem a mesma mentalidade e o mesmo conjunto de competências.
Por essa razão, quanto mais projetos pessoais conduzirmos, melhor será a competência para
lidar com projetos profissionais, e vice-versa.

A metodologia é a mesma
Nem todo sonho ou ideia torna-se um projeto. Apenas aqueles que passaram por um filtro
de avaliação de viabilidade tendem a se tornar projetos pessoais. Na realidade, também os projetos
profissionais passam pelo filtro da viabilidade, mas é preciso agregar outro filtro: o dos valores da
organização. No caso pessoal, como os valores comandam as nossas atitudes, não é preciso ter um
filtro específico para eles, a coerência é intuitiva.
A gestão de qualquer projeto inclui os seguintes fatores: ritual, compromisso, planejamento,
controle e tenacidade na sua execução. Nos projetos pessoais, isso ocorre tão natural ou
intuitivamente que não nos damos conta (awareness). Porém, quanto maior a disciplina de explicitar
esses fatores, documentando-os, maior a chance de sucesso nos projetos pessoais.
Liderar projetos causa eustresse, o estresse positivo que revigora e rejuvenesce. Quando o
indivíduo está desanimado, a sua vida perdeu o “sabor”, as obrigações matam os desejos e as
vontades – nada melhor que criar e gerenciar um projeto pessoal, com o benefício de melhorar o
ânimo, a vitalidade e a vontade de realizar ambições.
Nas organizações, há um benefício adicional para o estresse trazido pelos projetos em
andamento: criam conquistas memoráveis, ampliam a satisfação de interessados (stakeholders) e
promovem valor tangível (valor do negócio) e intangível (imagem, atração de talentos,
capacidade empreendedora).

14
Benefícios dos projetos
Quanto maior a quantidade de projetos pessoais que realizamos, maior o empreendedorismo
na nossa sociedade, maior a capacidade de inovar. Portanto, isso leva à maior transformação pessoal
e ao dinamismo da sociedade. De modo análogo, quanto mais projetos uma organização realiza,
maior a criação de valor sustentável, para a própria organização e também para a sociedade.
Você tem muitos projetos pessoais? Experimente e verá.

Conceito e ciclo de vida de projetos

Iniciar ou acabar?
Você prefere iniciar, executar continuamente ou terminar projetos? Sei que precisamos ir do
início ao final de um projeto, porém cada indivíduo tem maior vocação para uma dessas partes do
ciclo de vida de projetos. Os que gostam de iniciar projetos têm vocação para gerar e filtrar ideias,
estudando a viabilidade delas – depois de iniciada a execução, elas perdem o entusiasmo, à medida
que os problemas se avolumam.
Os que preferem a execução contínua – esses são a maioria, porque fomos educados para
processos permanentes – sentem-se desconfortáveis nos estudos de pré-projeto e ficam ansiosos
quando a execução vai chegando ao final. São raros os que têm vocação para concluir projetos, por
isso são valorizados: esses detestam as listas de pendências e fazem planos para o porvir, para os seus
novos desafios.
Avalie a sua preferência, porque essa vocação significa maior facilidade ou dificuldade na
execução de projetos. É um desafio existencial desenvolver igual aptidão em todas as etapas do ciclo
de vida de projetos.

Método não é lei

O Project Management Institute (PMI) deu um nome sugestivo à sua norma de como
gerenciar projetos: PMBOK Guide. Não é book, o “livro” da gestão, é bok, que significa body of
knowledge. Aristóteles chamou de “corpo de conhecimentos” a reunião do que é substantivo em
um dado campo – quem domina o corpo de conhecimentos, afirmou o filósofo, atingiu o
“estado de arte”, ou seja, tem o domínio profundo e um estilo pessoal sobre o uso dos
conhecimentos e técnicas.
Chamar a norma de “um guia para o corpo de conhecimentos” traduz o desejo de que a norma
não seja aplicada literalmente. Por isso, a norma não é taxativa nem contém formulários (templates).
Por ser um “guia”, essa norma não pretende ser completa nem definitiva; está em constante evolução,
para incorporar a inovação que se soma a práticas “amplamente reconhecidas”.

15
Ciclo de vida complexo
O PMBOK Guide – 5ª edição define projetos como “esforços temporários empreendidos para
criar produtos, serviços ou resultados únicos”. Dessa definição derivam as seguintes características
de um projeto (note a similaridade com atributos de projetos pessoais):
Envolve ambição e vontade empreendedora.
É ambicioso e desafiador, embora viável (endeavour).
É temporário, tem ciclo de vida pré-determinado (time-limited).
É marcado por objetivos (goal-driven).
É único, não se confunde com a rotina (one-shot).
Sempre contém riscos e incerteza.

Gerenciar projetos “é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às

atividades do projeto a fim de atender aos seus requisitos. É realizado por meio da aplicação e
integração dos processos (de gestão) de iniciação, planejamento, execução, monitoramento e
controle, e encerramento”. Para atender aos requisitos, a norma sugere alguns princípios:

identificação de necessidades;
estabelecimento de objetivos claros e alcançáveis;
balanceamento de demandas conflitantes de qualidade, escopo, tempo e
custo e
adaptação das especificações, dos planos e da abordagem às diferentes
preocupações e expectativas dos diversos interessados (stakeholders).

Para explicar as “demandas conflitivas”, veja quais são elas. Atender aos requisitos e objetivos
é o principal critério de sucesso na execução de projetos. São objetivos de um projeto:
Custo ou investimento – todo projeto requer o estabelecimento de um orçamento de
referência. Orçamento é uma estimativa de custo convertida em compromisso para
a execução.
Tempo – todo projeto tem um prazo limite ou diversos prazos, um para cada etapa de
execução. Há eventos importantes chamados de datas-marco (milestone no inglês), porque
balizam a execução.
Qualidade – é sempre objetivo – qualidade do produto do projeto, qualidade do projeto
(implantação e gestão) e qualidade percebida. No primeiro caso, trata-se da conformidade
com relação às especificações. O segundo envolve a execução harmônica, econômica e
promotora de aprendizagem. O terceiro envolve a percepção que induz à satisfação de
partes interessadas do projeto.

16
 Desempenho – há objetivos sejam eles de produtividade ou efetividade da gestão, sejam
de desempenho do produto depois de implantado o projeto.
Resultados esperados – se voltado para o lucro, o benefício de um projeto pode ser explorar
oportunidade mercadológica e obter retorno para o investimento. Se voltado para o social,
daí decorre e efetividade da execução – atender à demanda social. Sempre há também
objetivos ligados à aprendizagem e à evolução da metodologia de gestão.

O que há de complexo na gestão é que essas demandas são conflitivas. Por exemplo, prazos
muito curtos podem aviltar a qualidade, prazos folgados prejudicam a rentabilidade do projeto. Há
outro fator relevante, ligado à flutuação de ênfases: no início da execução, o prazo é o que mais
importa; durante a execução, os custos são enfatizados, mas, depois de concluído o projeto, só o
desempenho e o resultado importam. A norma recomenda que o gerenciador estabeleça um
agrupamento de objetivos coerentes entre si e convença a todos que de nada adianta maximizar um
ou outro desses objetivos em detrimento dos demais.
A 5ª edição da norma apresenta uma novidade promissora. Afirma que o principal propósito
da gestão é assegurar “valor do negócio (business value)”, definido como “o valor total do negócio;
a soma de elementos tangíveis e intangíveis. Exemplos de tangíveis: ativos monetários, ações.
Exemplos de intangíveis: good will (capital intelectual), reconhecimento da marca, benefício público
e valor da marca”. A mentalidade de valor agregado revela que os projetos deixaram de ser assunto
operacional para ser questão estratégica.
Note que a gestão do projeto é realizada por meio de processos. Cria uma questão ardilosa:
os projetos são únicos, mas os processos de gestão podem ser padronizados, mesmo que admitam
“adaptação às preocupações e expectativas dos interessados”. A mentalidade é focar em resultados
únicos, mas a gestão é padronizável.

17
 Os processos de gestão, como vimos, agrupam-se em cinco grupos. Muitos erroneamente
acreditam que são essas as fases de execução de um projeto. A norma alerta que, caso a execução
seja repartida em fases, cada etapa tem os cinco grupos de processos – portanto, não são fases.

Uma visão ingênua e utópica indicaria que primeiro iniciamos, depois planejamos, depois
executamos, para enfim terminar o projeto. Contudo, na vida real, depois de lançado o projeto
começa a execução, fazendo com que todos os grupos de processos ocorram em paralelo, como
mostra a figura.

18
 Para dar uma ideia de tempos, a iniciação tem o seu pico uma semana depois de iniciado, para
que o sistema de gestão seja estabelecido, os interessados sejam identificados e o Termo de Abertura do
Projeto seja produzido. O pico do planejamento ocorre a um mês do início: são produzidos pelo menos
oito planos, reunidos no Plano do Projeto. O monitoramento e controle ocorre desde o primeiro até o
último dia da execução. A execução inicia no primeiro dia, mas termina antes do fim. Para terminar,
são realizados testes para a emissão do Termo de Aceite do Projeto – o grupo de processos de
encerramento começou muito antes, para que fosse planejado o aceite.
Há mais uma questão sobre o ciclo de vida, evidenciada nesta outra figura extraída da norma.
No primeiro dia, a influência dos interessados sobre a execução é máxima, e o custo de qualquer
mudança é reduzido. À medida que a execução avança, a influência dos interessados diminui, até
porque decisões firmes são tomadas: os Requisitos são coletados e definidos, os Planos são aprovados
e divulgados, contratos são firmados e datas-marco são atingidas, evidenciando alguns entregáveis
(deliverables). Contudo, o custo de qualquer mudança cresce vertiginosamente. Não é fácil mudar
algo no momento do Aceite.
Diante desse ciclo de vida, a norma recomenda a proatividade: a execução é otimizada quando
se antecipam decisões e ações. Não se deixa para depois o que podemos fazer logo.

Experimente e crie o seu repertório

A norma PMBOK foi produzida nos anos 1980, coletando-se melhores práticas de gestão de
projetos nos principais países. Daí deriva a sua aplicação universal. Portanto, é adequada à realidade
brasileira, com uma exceção: a legislação sobre aquisições e contratos. Como a norma vem sendo
revisada a cada quatro anos, ela incorpora inovação. As mais recentes são a ênfase no valor do
negócio e na gestão de interessados (stakeholders).
Como a norma não é de uso obrigatório, nem aplicação completa dos 47 processos de gestão
nela detalhados, cabe a você avaliar a sua aplicabilidade no tipo de projetos em que está envolvido.
Livre-se de preconceitos, experimente aplicar essas ideias.
Naquilo que a norma o ajudar a ampliar a chance de sucesso na execução, incorpore ao seu
repertório de gestão. Você é quem dirá se vale a pena.

Termo de abertura do projeto

O que é o projeto?
Você já foi envolvido em algum projeto em que não havia nenhum documento formal que
definisse de que se tratava? Isso é mais comum do que racionalmente parece. Ou porque os estudos
anteriores são cercados de sigilo ou porque culturalmente há pouca ênfase em documentação.
Quanto mais estratégico, corporativo e especial for o projeto, maior a chance de isso ocorrer.

19
Um esquemático
Como oficializar um projeto? Antes de chegar esse momento alguns estudos foram feitos, ou
deveriam ter sido feitos para demonstrar a viabilidade do projeto. Alguns os chamam de Estudo de
Viabilidade, outros preferem o termo Caso de Negócio (Business Case), outros preparam apenas
apresentações que foram levadas a discussões.
Nada disso substitui a necessidade de criar um documento como o Termo de Abertura do
Projeto, que o PMBOK Guide chama de Project Charter, em inglês, que literalmente significa
“esquemático do projeto”. Na ausência de metodologia de projetos, a maioria das organizações usa
Atas de Reunião de Diretoria com igual propósito.

Termo de abertura: solução essencial

Entre os problemas mais citados por gerenciadores de projetos, destaco alguns. A falta de
alinhamento e comprometimento dos envolvidos muitas vezes se deve à má divulgação da existência
do projeto. Sabemos que os escopos de um projeto são “progressivamente detalhados”, o que implica
mudanças ao longo do tempo. Contudo, por “escopos mutantes” considero usual a perda de controle
sobre os escopos durante a execução. Como todo projeto contém incerteza e riscos, imprevistos
ocorrem o tempo todo, tornando obsoletos os planos existentes. Daí deriva outro problema frequente
relacionado ao planejamento: falta tempo, pessoas e dedicação para revisar planos.
Diante desses problemas, a taxa de sucesso inquestionável é muito baixa. É comum ouvirmos
que “projetos sempre atrasam”, “orçamentos nunca são suficientes”, “os resultados foram os
possíveis”. No entanto, a enorme soma de recursos financeiros investida em projetos determina
uma expectativa de sucesso acima de 90%. Como atingir esse nível? Só vejo uma solução: a
existência de uma metodologia única na organização, conhecida por todos os envolvidos e aplicada
em 100% dos projetos. Isso implica adotar regularmente a existência dos três documentos principais
na vida de um projeto, no entendimento do PMBOK Guide: Termo de Abertura, Plano do Projeto
e Termo de Aceite do Projeto.
Vejamos o que é o Termo de Abertura do Projeto: é um documento sintético que apresenta
as definições básicas do projeto. Em geral, ele não tem mais que três páginas, para assegurar que a
visão do todo não se perca em detalhes. Ele pode ser produzido por qualquer pessoa da organização;
contudo, precisa ser aprovado por alguém habilitado para tomar decisões de investimento: um
diretor, um comitê ou o dirigente.
O nome oficial em português afirma: é um “Termo” porque precisa ser assinado; é um Termo
porque oficializa a existência do projeto e permite que a execução dele seja iniciada; é um Termo
porque designa pelo menos o patrocinador ou o gerenciador do projeto, que assim fica investido da
autoridade e responsabilidade de executar o projeto. Por isso é “de Abertura”.
A ausência desse documento impede que o gerenciador tenha autoridade suficiente para ser
o protagonista da execução. Pior: a ausência de um documento oficial impede a organização de

20
definir exatamente o que deseja realizar – sem uma referência oficial, o projeto pode mudar ao sabor
dos acontecimentos: sem planos, sem baseline ou referência de controle; portanto, sujeito a
alterações ditadas por quem quer que seja. Se não existe Termo de Abertura ou documento
equivalente, não existe gestão como a desejamos.
Como produzir o Termo de Abertura? Quem o fará usará informação derivada de estudos
anteriores e formatará o termo de um modo claro e consistente. Julgo necessário definir um
conteúdo mínimo para o Termo de Abertura, supondo que centenas ou milhares de termos serão
levados aos decisores em um ano típico. Se cada documento for muito diferente do outro, como
criar uma capacidade de decidir objetivamente?
O PMBOK Guide não considera padrões (templates), mas sugere que alguns conteúdos são
usuais em Termos de Abertura de Projetos:

Finalidade ou justificativa do projeto; Objetivos mensuráveis do projeto e

critérios de sucesso relacionados; Requisitos de alto nível; Premissas e
restrições; Descrição de alto nível do projeto e seus limites; Riscos de alto
nível; Resumo do cronograma de marcos; Resumo do orçamento; Lista das
partes interessadas; Requisitos para aprovação do projeto; Gerente do
projeto, responsabilidade, nível de autoridade designados, e Nome e
autoridade do patrocinador ou outra(s) pessoa(s) que autoriza(m) o termo
de abertura do projeto.

Canvas, abordagem fecunda

No inglês, canvas representa a tela onde o artista cria a sua arte. É um nome promissor para
uma técnica que primeiro “delineia” a imagem que está na mente do artista para depois detalhar
(ou planejar) e executar o trabalho.
Reportagem recente da revista Exame1 indica haver dezenas de Canvas em uso. Segundo Felipe
Scherer, todas as opções, usadas em inúmeros campos, tiveram por origem o livro dos suíços
Osterwalder e Pigneur publicado em 2010 para criar planos de negócios com inovação. Esse livro se
insere na nova corrente do design thinking, que os autores traduzem para “mentalidade de design”. O
Canvas revela o valor do pensamento visual, usando uma tela em que um grupo organiza post-its.
A sua ligação com a arte e a visão sistêmica, imagética e espacial, defendem os seus autores,
permite idealizar mais que usando quadros e tabelas, que remetem ao pensamento analítico. O
Canvas usa uma “gramática visual”, que “captura a visão geral”, “enxergando relações”. Enquanto
processo grupal, ela estabelece um “ponto de referência coletivo” e uma “linguagem comum” que
favorece a “compreensão compartilhada”.

1
Ver http://exame.abril.com.br/rede-de-blogs/inovacao-na-pratica/2014/04/27/15-canvas-para-fazer-a-inovacao-decolar.

21
Modo sintético e artístico de elaborar
O benefício de usar a técnica do Canvas para estruturar o projeto é evidente. Contudo, em
minha opinião, o Canvas do projeto substitui o Termo de Abertura, e não o planejamento do
projeto, que ainda precisará ser feito.
Experimente reunir um grupo e estruturar o seu projeto usando Canvas. Para cada parte da
tela, lance o desafio e peça ao grupo para registrar uma ideia em cada post-it, para depois pregar
sobre a tela, eliminando redundâncias, fundindo ou sintetizando ideias.
Comece pela descrição macro do projeto e a sua justificativa: por que o projeto é importante,
oportuno ou valioso? Faça também alguma referência ao passado: ocorreu algo que justifica investir
atualmente nesse projeto?
Depois, defina quais são os objetivos do projeto. Não é obrigatório que exista apenas um, mas
escreva os objetivos na forma SMART – eSpecífico, Mensurável, Atingível, Relevante e Temporal.
Para denotar ação, escreva os objetivos na forma verbal. Os objetivos ditam o rumo a seguir, a
ambição pela qual vale a pena realizar. Os resultados esperados derivam dos objetivos. Sempre que
possível, também escritos na forma SMART. Para denotar realização, escreva no particípio passado.
Os benefícios se originam dos resultados, que quase sempre são pouco tangíveis e obtidos no médio
prazo, depois que o projeto terminou. Em projetos sociais, os benefícios costumam ser mais
relevantes que os resultados diretos, mas costumam ser negligenciados pela equipe do projeto que
não faz avaliação de impactos.
Na sequência, gosto de definir a Governança e Equipe do Projeto. Governança é quem decide
e comanda: patrocinadores (sponsors), comitês de decisão, eventualmente diretores. A equipe do
projeto pode ser multidisciplinar e pode envolver pessoal externo, o que recomenda que o critério
de formação da equipe seja definido ainda no Termo de Abertura.

22
 Fazemos a distinção entre “stakeholders externos” e a “equipe do projeto”, mas ressalto que
ambos são stakeholders, e a separação entre externo e interno só se justifica para enfatizar quem é
contável pela execução do projeto. No campo dos stakeholders externos, sugiro listar clientes,
usuários, beneficiários, envolvidos na execução e afetados. Em ambos os campos, sempre que
possível, liste cada um pelo nome, em favor da accountability.

Na sequência, sugiro preencher os campos dedicados a premissas e a restrições. Premissas

(assumptions) são fatores considerados verdadeiros para fins de definição do projeto. São as suposições
que fazemos, e costumamos falar delas como: “estamos assumindo que...” É importante registrar o
máximo de premissas porque, durante a execução, se uma delas não se mostra verdadeira, força a
revisão do planejamento do projeto. Restrições são limitações ou fatores que a equipe do projeto não
tem a liberdade de definir. São questões de cumprimento obrigatório: leis, normas, regulamentos.
Não confunda restrições obrigatórias com fatores críticos para o sucesso. Esses poucos fatores
representam os maiores riscos do projeto – listá-los é indicativo de profissionalismo.
Seguindo a lógica de desenho, é o momento de definir o escopo do projeto e os seus
entregáveis. O escopo do projeto envolve duas questões: a definição de estratégias de implantação
que visam a mitigar riscos e incerteza; e a lista de atividades cuja execução permite alcançar os
objetivos e gerar os resultados esperados. A partir do escopo do projeto, é interessante preencher os

23
entregáveis (deliverables): todos os produtos e resultados tangíveis e controláveis que resultam da
execução do projeto.
Definido o escopo do projeto, o Canvas se completa ao preencher as datas-marco principais
(milestones): datas de início, marcos principais e de término. Também como decorrência do escopo,
podemos fazer uma estimativa de custo, melhor dizendo, investimento no projeto.
Enquanto processo grupal de idealização e organização de ideias, o Canvas é um instrumento
poderoso. Contudo, como envolve 14 partes, pode ocorrer de escrevermos um mosaico de ideias
disparatadas. Por essa razão, não interrompa o processo quando a última parte for preenchida. Use
a cognição do grupo para verificar se há coerência entre as partes.
Primeiro, ateste a coerência entre objetivos, resultados e benefícios. Depois, verifique se a
justificativa é coerente com eles. Verifique a coerência entre premissas/restrições e escopo do
projeto. Verifique se os entregáveis são coerentes com eles e também com os objetivos e resultados
esperados. A partir dos entregáveis e do escopo, é possível verificar a coerência com a linha do tempo
e com o investimento associado. Já a consistência dos fatores críticos requer a mente flutuante e a
idealização de como se dará a execução do projeto.

Termo de abertura não é plano do projeto

O Termo de Abertura retrata o projeto e permite iniciar a sua execução com alguma
segurança. Também é o documento mais usado na comunicação com todos os interessados
(stakeholders) do projeto, desde o início e até o fim da execução. Por ser uma referência de controle,
ele não costuma admitir revisões.
Uma cautela é necessária: ele não é um plano nem substitui um plano. Sem planejar
adequadamente, nada garante que o projeto será executado exatamente como indica o Termo de
Abertura, nem garante que os resultados e benefícios esperados sejam obtidos.

24
MÓDULO II – PLANEJAMENTO

O módulo 2 e o 3 destinam-se a apresentar as principais técnicas de planejamento de projetos.

Partimos de duas premissas. A primeira: como projetos são por definição únicos, o planejamento não
só é exigido como também é a principal fonte para obter sucesso na execução. A segunda: só se aprende
a gerenciar projetos por meio da prática metódica, mais que pelo estudo – por isso experimentaremos
as principais técnicas de planejamento. Para isso, será usado o Termo de Abertura produzido na aula 1.
Ao final, esperamos que você seja capaz de:
diferenciar Plano de Gestão do Termo de Abertura do Projeto;
compreender a diferença entre Escopo do Produto e Escopo do Projeto;
desenvolver habilidade de organizar escopos de projetos;
aprender diferentes estratégias para executar projetos e
desenvolver plano de comunicação interna e externa para o projeto.

Processos de gestão pmbok guide

Multidisciplinar
Muitos profissionais de projeto perceberam que gerir um projeto é como gerir uma pequena
empresa: temos de lidar com finanças, tempo, qualidade, recursos humanos, aquisições, etc. Se você
concorda com isso, deve aceitar que a norma Guia PMBOK apresente um número tão variado de
processos de gestão.
Definição caso a caso
A gestão do projeto é multidisciplinar: envolve 10 áreas de conhecimento, também
organizadas em cinco grupos de processos. Cabe ao gestor de cada projeto definir quais desses
processos de gestão ele deve adotar caso a caso.

Processos de gestão
O Guia PMBOK envolve 49 processos de gestão organizados matricialmente: por área de
conhecimento e por grupo de processo. Em cada área de conhecimento, há processos de iniciação,
ou de planejamento, ou de execução, ou de monitoramento e controle ou de encerramento. A figura
a seguir apresenta os 49 processos associados aos cinco grupos de processos no ciclo de vida do projeto.

Todos os processos de gestão que não são exclusivos de alguma área de conhecimento
(escopos, cronograma e custos, por exemplo) pertencem à área de integração. Gerir a integração
significa integrar e coordenar processos de gestão de todas as áreas. Para coordenar de fato a
execução, o Termo de Abertura e os outros documentos são cruciais: o Plano de Gerenciamento do
Projeto, com caráter integrador e nível estratégico; e o sistema de Controle Integrado de Mudanças,
em que o impacto de cada mudança é analisado na visão sistêmica.

26
 Os processos vinculados a essa área do conhecimento são indicados no quadro a seguir. A essência
do gerenciamento é a integração, por isso essa área do conhecimento inclui outros processos cruciais:
gerir conhecimentos, dirigir e liderar o projeto, verificar e controlar a execução. Ainda não interessa
definir quem faz o quê: a equipe (como um todo) do projeto é responsável por esses processos.

Área de
Processo Finalidade
conhecimento

Desenvolver Processo de desenvolver um documento que formalmente

Integração termo de autoriza a existência de um projeto e fornece ao gerenciador
abertura deste a autoridade para aplicar os recursos alocados ao projeto.

Desenvolver
Processo de definir, preparar e coordenar todos os
plano de
Integração componentes do plano e consolidá-los em um plano integrado
gerenciamento
de gerenciamento do projeto.
do projeto

Orientar e Processo de liderar e realizar o trabalho definido no Plano de

Integração gerenciar o Gerenciamento do Projeto e a implementação das mudanças
trabalho aprovadas, para atingir os objetivos do projeto.

Gerenciar o Processo de utilizar os conhecimentos existentes e criar novos

Integração conhecimento do conhecimentos para alcançar os objetivos do projeto e
projeto contribuir para a aprendizagem organizacional.

Monitorar e Processo de acompanhar, analisar e relatar o progresso geral

Integração controlar o para atingir os objetivos de desempenho definidos no Plano de
trabalho Gerenciamento do Projeto.

Processo de revisar todas as solicitações de mudança, aprovar

Realizar controle mudanças e controlar mudanças em entregáveis, ativos de
Integração integrado de processos organizacionais, documentos do projeto e Plano de
mudanças Gerenciamento do Projeto, além de comunicar a decisão sobre
eles.

Encerrar projeto Processo de finalizar todas as atividades para o projeto, a fase

Integração
ou fase ou o contrato.

Gerir escopos envolve gerenciar todo o trabalho, e apenas o trabalho requerido para atingir os
objetivos do projeto. Envolve coletar requisitos para definir escopos, organizá-los e depois verificar
e controlar as mudanças de escopos. Escopos incluem não só as atividades a executar, assim como
os produtos do projeto.

27
 É importante distinguir o Escopo do Produto (componentes e partes) do Escopo do Projeto:
atividades a executar. O PMI adota o conceito de entregável (deliverable) para fazer com que cada
conjunto de atividades (trabalho) se torne tangível por meio de algum tipo de “entrega”: um
relatório, uma aprovação, um evento, etc. Tangibilizar partes do escopo resulta em maior controle
sobre a execução do projeto, sobretudo quando ele envolve atividades de cunho intelectual. O
quadro a seguir lista processos e finalidades dessa área do conhecimento.
Note que o processo “Definir escopo” envolve detalhar escopos aprovados no Termo de
Abertura do Projeto. Se os escopos são progressivamente elaborados, é raro um projeto iniciar com
o escopo suficientemente claro. Esse fato obriga a organizar o escopo de modo estruturado, o que
corresponde ao processo “Criar EAP”, técnica reputada como muito importante.

Área de
Processo Finalidade
conhecimento

Planejar Processo de criar um plano de gerenciamento do escopo que

Escopo gerenciamento documenta como os escopos do projeto e do produto serão
do escopo definidos, validados e controlados.

Coletar Processo de definir e documentar as necessidades e requisitos

Escopo
requisitos dos interessados a fim de atender aos objetivos do projeto.

Processo de desenvolver uma descrição detalhada do projeto e

Escopo Definir escopo
do produto.

Criar EAP –
EAP, no inglês WBS – Work Breakdown Structure, é a subdivisão dos
Estrutura
Escopo principais entregáveis e do trabalho do projeto em componentes
Analítica do
menores e mais facilmente gerenciáveis.
Projeto

Processo de formalizar a aceitação das entregas concluídas do

Escopo Validar escopo
projeto.

Processo de monitorar o estado do escopo do projeto e do

Controlar
Escopo produto e gerenciar as mudanças feitas na linha de base
escopo
(baseline) do escopo.

Gerir cronogramas compreende os processos para gerenciar o término pontual do projeto. O

objetivo central é otimizar prazos e recursos, evitando desperdícios, conturbações, etc. O quadro a
seguir relaciona processos dessa área do conhecimento, que estabelecem uma sequência lógica e
cronológica de execução.

28
 Área de
Processo Finalidade
conhecimento

Planejar Processo de estabelecer políticas, procedimentos e

Cronograma gerenciamento documentação exigida para planejar, desenvolver, gerenciar,
do cronograma executar e controlar o cronograma do projeto.

Processo de identificar e documentar atividades específicas

que precisam ser realizadas para produzir as entregas do
Cronograma Definir atividades
projeto. Na prática, significa detalhar as atividades (ou
pacotes de trabalho) do escopo do projeto.

Processo de identificar e documentar relacionamentos entre

as atividades do cronograma. Para cada atividade, definem-
Sequenciar
Cronograma se as suas precedentes e o tipo de ligação entre elas, que
atividades
pode ser: término-início; início-início e término-término, com
ou sem retardos/antecipações entre elas.

Processo de estimar o número de períodos de trabalho

Estimar durações necessários para terminar as atividades individuais do
Cronograma
das atividades cronograma com os recursos estimados. Para estimar é
preciso considerar condições normais de produtividade.

Processo de analisar sequências de atividades, durações,

Desenvolver requisitos de recursos e restrições do cronograma do
Cronograma
cronograma projeto. Inclui o nivelamento de recursos e a administração
de folgas das atividades não críticas.

Processo de monitorar o estado do projeto para atualizar o

Controlar
Cronograma cronograma e gerenciar mudanças na linha de base do
cronograma
mesmo.

Note que as metas de prazo não podem ser alteradas sem prévia anuência de interessados
relevantes, mas isso não significa que o cronograma precise ser “congelado”. Em ambiente de
incerteza, há imprevistos que afetam a execução. Por isso, o gerenciador revê o cronograma sempre
que necessário, mas evita alterar metas antes aprovadas.
Gerir custos compreende os processos usados em planejamento, estimativa, orçamento,
financiamento, gerenciamento e controle de custos. O objetivo é otimizar custos, visando a impedir
estouros nos gastos em relação ao orçamento aprovado. Note que a norma desafortunadamente

29
 trata de custos, e não de investimentos. Gerir investimentos compreende não apenas controlar gastos,
como também controlar as fontes de financiamento do projeto e os retornos obtidos. A maioria dos
projetos tem investimento, e não custo. O quadro a seguir relaciona processos e finalidades.

Área de
Processo Finalidade
conhecimento

Planejar
Processo de definir como os custos do projeto serão
Custos gerenciamento
estimados, orçados, gerenciados, monitorados e controlados.
dos custos

Processo de desenvolver uma aproximação dos recursos

Custos Estimar custos
financeiros necessários para terminar o trabalho do projeto.

Processo de agregar custos estimados de atividades

Determinar
Custos individuais ou pacotes de trabalho para estabelecer uma linha
orçamento
de base (ou referência) de custos.

Controlar Processo de monitorar o estado do projeto para atualizar o

Custos
custos orçamento e gerenciar mudanças na linha de base de custos.

Gerir qualidade compreende a qualidade do produto (conformidade com as especificações,

ausência de defeitos que prejudiquem o desempenho ou a vida útil do produto do projeto) e a
qualidade do projeto (execução e, portanto, da gestão do projeto). Há outra dimensão não explícita
no guia PMBOK: a qualidade percebida (satisfação dos interessados), contudo, a norma menciona
que “satisfazer interessados deveria ser um objetivo-chave”. Gerir qualidade também inclui suporte
às atividades de melhoria contínua de processos da organização. O quadro a seguir relaciona os
processos dessa área.

Área de
Processo Finalidade
conhecimento

Planejar Processo de identificar requisitos ou padrões de qualidade do

Qualidade gerenciamento projeto e dos seus entregáveis, e documentar como o projeto
da qualidade demonstrará conformidade com eles.

Processo de transformar o plano de gerenciamento da qualidade

Gerenciar
Qualidade em atividades da qualidade executáveis, que incorporam no
qualidade
projeto as políticas de qualidade da organização.

Processo de monitorar e registrar resultados da execução das

Controlar atividades de gerenciamento da qualidade para avaliar
Qualidade
qualidade desempenho e garantir que as saídas do projeto sejam
completas, corretas e atendam às expectativas do cliente.

30
 Gerir recursos do projeto inclui os processos para identificar, adquirir e gerenciar os recursos
necessários para a conclusão do projeto. Por recursos, a sexta edição do Guia PMBOK inclui equipe,
instalações, equipamentos, materiais, suprimentos e outros. As pessoas voltam a ser consideradas
mais um “recurso” para executar o projeto, infelizmente. Contudo, ao somar a gestão de outros
recursos, cobre-se uma lacuna.

Área de
Processo Finalidade
conhecimento

Planejar
Processo de definir como estimar, adquirir, gerenciar e utilizar
Recursos gerenciamento
recursos físicos e de equipe.
dos recursos

Estimar Processo de estimar recursos da equipe, o tipo e as quantidades

Recursos recursos das de materiais, equipamentos e suprimentos necessários para
atividades realizar o trabalho do projeto.

Processo de obter membros da equipe, instalações,

Adquirir
Recursos equipamentos, materiais, suprimentos e outros recursos
recursos
necessários para concluir o projeto.

Desenvolver Processo de melhoria de competências, interação da equipe e do

Recursos equipe (team ambiente geral da equipe para aprimorar o desempenho do
building) projeto.

Processo de garantir que os recursos físicos atribuídos e alocados

Controlar ao projeto estejam disponíveis conforme planejado, bem como
Recursos
recursos monitorar o uso planejado versus o uso real de recursos, e
executar ações corretivas conforme necessário.

Comunicação, em minha opinião, é a principal área de conhecimento: quando falta

entendimento e informação, quando as decisões atrasam ou são inadequadas, quando há conflitos,
tudo decorre de problemas de comunicação. Essa área de conhecimento trata de relacionamentos, e
não apenas de informação. É a comunicação que torna a equipe coesa, que enfrenta conflitos e crises
e que gera satisfação dos interessados.
Note que, em muitos projetos, a comunicação com o cliente final é parte das ações
operacionais, há campanhas de marketing. Nesse caso, o plano de comunicação inclui apenas a
comunicação com os demais interessados. Outra questão que julgo relevante: na falta de outro lugar
onde planejar as ações educacionais para o usuário, cliente ou beneficiário do projeto, eu as incluo
no plano de comunicação.

31
 Área de
Processo Finalidade
conhecimento
Processo de desenvolver uma abordagem e um plano para as
Planejar
comunicações do projeto baseadas nas necessidades de
Comunicação gerenciamento
informação de cada interessado ou grupo, nos ativos
da comunicação
organizacionais disponíveis e nas necessidades do projeto.
Processo de criar, coletar, distribuir, armazenar, recuperar,
Gerenciar
Comunicação monitorar e cuidar da disposição final da informação do
comunicação
projeto, de forma oportuna e adequada.
Monitorar Processo de garantir que as necessidades de informação do
Comunicação
comunicação projeto e de interessados sejam atendidas.

Gerir riscos envolve os processos de: planejar a gestão de riscos; identificar ameaças e
oportunidades; analisar riscos (quali ou quantitativamente), visando a estabelecer graus de
severidades; planejar respostas (Planos A e B) para cada ameaça e oportunidade severas e controlar
se os riscos tornam-se realidade, se as respostas são eficazes ou se há riscos posteriores a gerir.

Área de
Processo Finalidade
conhecimento
Planejar
Processo de decidir como conduzir as atividades de
Riscos gerenciamento
gerenciamento de riscos de um projeto.
dos riscos
Processo de identificar riscos individuais e fontes de risco geral
Riscos Identificar riscos
do projeto, e de documentar as suas características.
Processo de priorizar riscos para a análise ou ação posterior
Realizar análise
Riscos por meio de avaliação combinada da sua probabilidade de
qualitativa
ocorrência e impacto.
Processo de analisar numericamente o efeito dos efeitos
Realizar análise
Riscos combinados de riscos individuais identificados e outras fontes
quantitativa
de incerteza nos objetivos do projeto.
Planejar Processo de desenvolver alternativas, selecionar estratégias e
Riscos respostas aos acordar ações para ampliar oportunidades e reduzir ameaças
riscos aos objetivos do projeto.
Implementar
Processo de implementar planos acordados de respostas a
Riscos respostas a
riscos.
riscos
Processo de monitorar a implementação dos planos
Monitorar os acordados, acompanhar riscos identificados, identificar e
Riscos
riscos analisar novos riscos, e avaliar a eficácia do processo de risco
ao longo da execução do projeto.

32
 Gerir aquisições envolve comprar produtos e serviços, gerindo contratos de fornecimento e de
prestação de serviços. Por questões de compliance, na maioria das organizações, a realização de
compras e contratações cabe exclusivamente ao setor de Compras, contudo, são atividades que
fazem parte do escopo do projeto. Os propósitos gerais são: repartir riscos com os contratados,
repartir responsabilidades, otimizar custos de contratação e gastos contratuais. Os contratos são
entendidos como instrumentos de gestão, e não apenas como burocracia para a proteção jurídica.
Note que essa área do conhecimento é fortemente afetada pela legislação de cada país e região.
Por esse motivo, cabem adaptações caso a caso. Note que Conduzir Aquisições são processos que nos
países latinos e no setor público são conhecidos como processos de Licitação. Note que a sexta edição
eliminou o processo de “encerrar aquisições”, na premissa de que ela faz parte do “controlar aquisições”.

Área de
Processo Finalidade
conhecimento

Planejar Processo de documentar as decisões de compras do

Aquisição gerenciamento projeto, especificando a abordagem, e identificando
das aquisições potenciais fornecedores.

Conduzir Processo de obter propostas de fornecedores, selecionar

Aquisição
aquisições fornecedor e adjudicar contrato.

Processo de gerenciar as relações contratuais, monitorar

Controlar
Aquisição desempenho de contratos, e realizar mudanças e correções
aquisições
quando necessário, e de encerrar contratos.

Gerir interessados (stakeholders) é a décima área de conhecimento e visa ao engajamento de

todos os envolvidos na concepção e execução do projeto. O Guia PMBOK considera que engajar
envolve estratégias especiais e diferentes das estratégias de comunicação usuais. No grupo de
iniciação, há o processo de “identificar interessados”, os demais processos são insumos para elaborar
e controlar o plano de comunicação do projeto.

33
 Área de
Processo Finalidade
conhecimento

Processo de identificar regularmente os interessados

Identificar (stakeholders) do projeto, analisando e documentando
Interessados
interessados informação relevante sobre interesses, envolvimento,
interdependências, influência e impacto potencial no projeto.

Planejar Processo de desenvolver abordagens adequadas para

engajamento envolver os interessados, baseado nas necessidades, nas
Interessados
de expectativas, nos interesses e no impacto potencial sobre o
interessados projeto.

Gerenciar
Processo de comunicar e trabalhar com interessados para
engajamento
Interessados atingir as suas necessidades/expectativas e adaptar
de
estratégias de engajamento, modificando planos.
interessados

Monitorar
engajamento Processo de monitorar os relacionamentos com interessados
Interessados
de do projeto, ajustando estratégias e planos para engajá-los.
interessados

Como se nota, há apenas alguns documentos formais produzidos e revisados ao longo do

ciclo de vida do projeto. Eles não derivam da burocracia, e sim do profissionalismo na gestão, e
servem para a gestão do conhecimento. São eles:
Termo de Abertura do projeto;
Plano de gestão do projeto;
Termos de contrato;
Relatórios e
Termos de aceite (provisório e definitivo).

Hipercompetência
O Guia PMBOK relaciona, portanto, 49 processos de gestão na sexta edição. Não é exagero
complicar tanto a gestão de um projeto? Tenho o receio de que, ao revisar a norma a cada quatro
anos, como faz o PMI desde 2000, há uma tendência de fazê-la crescer sempre. Os processos de
gestão de cronograma poderiam ser reduzidos a dois, e não foram; o erro de considerar custos, e
não investimentos, permanece. Embora não sejam de adoção obrigatória, tal quantidade de
processos fomentou a criação de metodologias “ágeis” em outros campos de aplicação.

34
 Se cada processo de gestão for associado a pelo menos uma competência, cria-se um
problema: o gerenciador e a equipe do projeto precisariam de pelo menos 49 competências. É um
desafio. Agora, você pode avaliar em quantos desses processos você se julga competente. Isso
incentivará o seu autodesenvolvimento.

Fonte
PMI – Project Management Institute. Guia PMBOK: um guia para o conjunto de conhecimentos em gerenciamento
de projetos. 6. ed. Newtown Square: PMI, 2017.

Abordagem ágil de gerenciamento de projetos

Substitui ou complementa?
Quem não quer uma metodologia ágil para gerenciar os seus projetos? Ágil porque cria
mentalidade diferente da convencional, reduzindo o peso da documentação e do esforço de
planejamento e controle. Contudo, essa nova tendência precisa ser classificada para definir se
substitui ou complementa as metodologias hegemônicas.

Da engenharia ao desenvolvimento de softwares

A metodologia de gerenciamento de projetos nasceu nos anos 1950 nos EUA, no setor de
defesa espacial, e logo foi seguido pelo setor de obras de infraestrutura. Tanto é que o PMI nasceu
em 1969, pelo esforço de sete engenheiros.
Esse tipo de projeto – diria até megaprojeto – é caracterizado por: elevados investimentos, prazos
longos, múltiplos envolvidos e enorme esforço de execução. A metodologia criada pelo PMI em 1984
e ainda hoje hegemônica segue a doutrina clássica de Henry Fayol pautada por cinco elementos:
planejar, organizar, comandar, coordenar e controlar. Depois de um longo esforço de planejamento em
que se organiza a equipe temporária responsável pela execução do projeto, o gerenciador comanda,
coordena e controla. A farta documentação completa essa abordagem de gestão.
Desde os anos 1990, a metodologia de projetos se tornou universal: foi adotada pelos setores
de tecnologia, consultoria e desenvolvimento de produtos; foi adotada em todo o terceiro setor e
até no primeiro setor, em projetos de desenvolvimento econômico. Ampliando o segmento, era
natural que surgissem variantes e até mesmo novas metodologias.
Atualmente, a maioria dos filiados do PMI em mais de uma centena de países não tem a
formação de engenheiro: atua em tecnologia de informação e telecomunicações. Nesses setores, os
projetos são bem diferentes: curto prazo, pequeno investimento, poucos envolvidos e muita
dificuldade de definir e preservar o escopo de execução dos projetos. É nesse contexto que surgiu
em 2001 o gerenciamento de projetos “ágil” para o desenvolvimento de produtos tecnológicos.

35
Questão de mentalidade, não de ferramentas
Para a evolução do conhecimento, é sempre útil questionar o conhecimento hegemônico,
como o é a norma PMBOK Guide do PMI hoje no mundo. É essa a maior contribuição de
Highmisth e colegas. Em 2001, eles publicam o “Manifesto Ágil”:

Nós estamos desvelando melhores maneiras de desenvolver produtos pela

prática e pela ajuda a outros. Por meio desse trabalho nós passamos a
valorizar:
indivíduos e interações em relação a processos e ferramentas;
software funcional em relação à documentação abrangente;
colaboração com o cliente em relação à negociação contratual;
responder a mudanças em relação a seguir planos.
Ou seja, enquanto há valor nos subitens à direita, nós valorizamos mais os
subitens à esquerda.

Decorridos alguns anos, Highsmith pondera: “agilidade é mais atitude que processo, mais
ambiente que metodologia”. Reagindo às principais incompreensões sobre o “ágil”, o autor ressalta:
“não quer dizer que as ferramentas, processos, documentos, planos e contratos sejam
desimportantes [...] Ferramentas são críticas para acelerar e reduzir custos. Contratos são vitais para
iniciar relacionamentos. Documentação auxilia a comunicação”.
Na formação dessa nova mentalidade, Highsmith estabelece três valores críticos:
Fornecer valor ao invés de cumprir restrições.
Liderar a equipe ao invés de gerenciar tarefas.
Adaptar-se a mudanças ao invés de cumprir planos.

Ao enfatizar valores sobre restrições, Highsmith afirma que não é o detalhamento de

requisitos do projeto que fornece indicadores de resultados. Pragmaticamente, sugere a “fórmula
de sucesso: entregue hoje, adapte amanhã”. Para entregar valor aos clientes, remete a três questões:
focar na inovação mais que na eficiência e otimização; concentrar-se na execução; e pensamento
enxuto. Sobre o controle, sugere que “o controle é historicamente centrado em correção mais que
em aprendizagem”, por isso a ênfase na adaptação durante a execução, mais que o viés de
planejamento-e-controle.

36
 Ao enfatizar a liderança em relação à gestão, o autor explica: “líderes, e não gestores,
encorajam a mudança – criando possibilidades de visões de futuro e interagindo com muita gente”.
Além disso, confronta os paradigmas tradicionais de controle, de previsibilidade do futuro, de
repetição de melhores práticas, da importância de medir, e de que ao reduzir incertezas as certezas
aumentam. Note como as suas ideias são refrescantes:
Comandantes conhecem objetivos, líderes compreendem a direção.
Comandantes ditam, líderes influenciam.
Controladores demandam, colaboradores facilitam.
Controladores fazem microgestão, colaboradores encorajam.
Gestores que abraçam o modelo liderança-colaboração compreendem que seu principal
papel é estabelecer direção, guiar e facilitar a conexão entre pessoas e equipes.

Ao enfatizar mudanças sobre planos, fico aliviado com a afirmação do autor: “Ambos
gerenciadores ágeis e tradicionais consomem uma boa quantidade de tempo planejando”. Qual é a
diferença: adaptar-se ao invés de conformar-se com os planos. Os planos deixam de ser algo a ser
cumprido para se tornarem guias constantemente revisados.
Afirma que “os gerenciadores de projetos tradicionais focam em seguir os planos com o
mínimo de mudanças, enquanto o líder ágil foca em adaptar-se com sucesso às mudanças
inevitáveis”. É de fato uma crítica profunda à escola clássica de Administração, mas como seria
possível realizar projetos em ambiente de risco e incerteza sem fazer análises metódicas de riscos
como parte do esforço de planejamento? O autor responde: “ambos, líderes tradicionais e ágeis
precisam utilizar práticas de gestão de riscos”, reafirmando que não há ferramentas exclusivas da
abordagem ágil e da tradicional.
Outro conceito que é confrontado na abordagem ágil: o tradicional triângulo de gestão
composto de escopo, custo e cronograma. A abordagem ágil coloca no topo as metas de valor
(entregar um produto), qualidade (produzir produto confiável e adaptável) e restrição (atingir metas
de valor e qualidade dentro de restrições aceitáveis). Note que o PMI, na quinta edição do PMBOK
Guide, passa a mencionar o objetivo último de qualquer projeto: agregar valor de negócio.
Desde o início do movimento ágil, muitos dos pioneiros criaram as suas próprias abordagens
ou metodologias ágeis. As mais difundidas são: Metodologia Scrum, Extreme Programming (XP) e
Feature Driven Development (FDD). Todas elas interativas e aderentes ao pensamento ágil.
Highsmith criou uma moldura conceitual suficientemente ampla para abranger todas essas
opções. A moldura ágil consiste em: Governança de Portfólio no topo, abaixo da qual figuram
respectivamente (como degraus de uma escada): Gerenciamento do Projeto, Gestão Interativa e
Práticas Técnicas.
A governança, seja na abordagem ágil e tradicional, enfoca duas preocupações: investimento
e riscos. A camada de gerenciamento envolve a produção de planos, no qual inclui planos de riscos
e de contratos. A novidade é a ênfase na camada de interação que enfoca o planejamento, a execução

37
e a liderança durante curtos períodos de interação. Já a camada técnica enfoca as técnicas específicas
de cada campo de aplicação de projetos.
Para Highsmith, “processos não são tão importantes quanto pessoas, mas estão longe de
serem desimportantes”. Por isso, fornece um macroprocesso de gerenciamento ágil, composto de
cinco fases:
Envisionamento – definindo o produto, os objetivos, a comunidade e como a equipe operará.
Especulação – desenvolvendo planos para fornecer a visão.
Exploração – planejando e entregando em curtas interações, constantemente buscando
mitigar riscos e incerteza.
Adaptação – revisando resultados, desempenhos e situações para fazer adaptações.
Encerramento – concluir o projeto, revendo lições aprendidas e celebrando.

Compare com os grupos de processos definidos no PMBOK Guide: iniciação, planejamento,

execução, monitoramento e controle e encerramento. São muito semelhantes, a postura que é diferente.
Não vejo porque detalhar as técnicas usadas na metodologia ágil, seria desmerecer a grande quebra
de paradigma.

Cada coisa no seu lugar

Highsmith menciona que a gestão interativa pregada pela abordagem ágil não é nova, existe
desde os anos 1950 no desenvolvimento de produtos. Também afirma: “gerenciamento ágil de
projetos não serve para qualquer projeto; não é uma melhor prática universal”. Aqui está o fulcro
da discussão: para que tipo de projetos essa abordagem é funcional, portanto, preferível à
abordagem tradicional?
Seria possível executar um empreendimento de infraestrutura envolvendo milhares de
operários, de desenhos de engenharia e de fornecedores sem um cronograma detalhado, uma matriz
de responsabilidades, requisitos, escopos e entregáveis claramente definidos? Creio que não, mas
esses planos só são úteis porque houve um estudo prévio – anteprojeto e estudo de viabilidade –
que tornou os planos mais consistentes.
Seria possível fazer planos com igual conteúdo e detalhamento para desenvolver e lançar
novos produtos, sobretudo os inovadores? Creio que não. Quanto mais inovador, mais difícil é
definir escopos, fixar metas, detalhar atividades.

38
 Dessa forma, o critério para adotar a abordagem tradicional e a abordagem ágil é clara: onde
há maior incerteza vale a pena a mentalidade ágil. Os tipos de projetos onde se percebe essa
condição são:
projetos de desenvolvimento de produtos, processos, mercados e organizações inovadores;
projetos de mudança cultural planejada em grandes organizações;
projetos de natureza política: campanhas políticas, engajamento de interessados;
projetos de desmonte, intervenção e recuperação de crises.

A abordagem ágil resolve muitas preocupações que os mais antigos gerenciadores de projetos –
como eu – tinham, e abre caminhos promissores para a criação de novas técnicas, criando de fato um
novo modelo de gestão.

Plano de gerenciamento do projeto

Iniciar sempre, acabar talvez
A naturalidade com que brasileiros valorizam o “jeitinho” e o improviso denota um traço
cultural: não gostamos de planejar. Isso explica porque tantos projetos de infraestrutura iniciam
sem uma boa engenharia básica; porque tantos empreendedores iniciam novos negócios afoitamente
e sem adequado preparo; porque tantas organizações prezam mais as “iniciativas” que as
“acabativas” nos projetos.

Sem planos, tudo é aventura

Mesmo que exista um Termo de Abertura baseado nos estudos que antecederam o projeto, é
imprescindível planejar a sua execução. As condições externas e de contexto mudam; a
governabilidade resulta da governança estabelecida; o gerenciador designado tem o seu próprio
estilo e a sua maneira de executar o projeto.
O Plano do Projeto otimiza a aplicação dos recursos no projeto; escolhe estratégias de
execução; responde a riscos, sejam ameaças sejam oportunidades; revisa o escopo e o investimento
antes definidos, e cuida de alguns aspectos nem sempre presentes no Termo de Abertura: qualidade,
comunicações, engajamento de interessados e aquisições. Executar o projeto sem o respaldo de
um Plano do Projeto é pura aventura.

39
Síntese de muitos planos
O PMBOK Guide afirma que: “o plano de gerenciamento do projeto é o documento que
descreve como o projeto será executado, monitorado e controlado. Ele integra e consolida todos os
planos de gerenciamento e linhas de base” de escopo, custos e cronograma, entre outras. É um
documento completo (portanto, detalhado), cuja coerência é assegurada entre os nove planos que
o compõem e é atual, porque revisado sempre que a realidade torna obsoleta a versão existente.
Para produzir o Plano do Projeto, julgo necessário um esforço coletivo: são vários planos que
afetam uns aos outros. Além do mais, o planejamento requer discussão; pelo debate, as melhores
opções são desenvolvidas. Um bom planejamento requer expertises diferentes; por isso, julgo valioso
agregar outras pessoas além da equipe do projeto. Nem sempre a equipe do projeto foi totalmente
mobilizada nesse momento de início da execução do projeto, ressalto. Seria proveitoso contar com
a participação do Escritório de Projetos, se existir; do patrocinador, mesmo que apenas em
momentos especiais; e de especialistas convidados do jurídico, da auditoria, do financeiro, de áreas
técnicas, e até mesmo parceiros externos.
O conteúdo básico do Plano do Projeto é a reunião dos planos das nove áreas do
conhecimento: escopo, tempo, custo, qualidade, recursos humanos, interessados, comunicação,
risco e aquisição. Contudo, como a norma do PMI não fornece padrões (templates), podemos
adicionar outros planos. Em projetos entre organizações, adiciono um plano de ética e conduta; em
que a questão ambiental está colocada, devo adicionar um plano para ela; onde for oportuno, um
plano para gerir o conhecimento gerado pode ser proveitoso.
O PMBOK Guide sugere que podem ser adicionados ao conteúdo citado: o ciclo de vida
selecionado para o projeto; detalhes das decisões relativas às adequações especificadas pela equipe
de gerenciamento; um plano de gerenciamento de mudanças que documenta como as mudanças
serão monitoradas e controladas; um plano de gerenciamento de configuração que documenta
como o gerenciamento de configuração será realizado; e como o plano será revisado abordando
questões em aberto e decisões pendentes.
Como cada plano afeta os demais, não há uma sequência ótima de execução. Minha
preferência é iniciar por interessados, comunicação e riscos; e terminar por cronograma e recursos
humanos. São planos tão intrincados que é necessário que sejam feitos todos na mesma ocasião.
Sugiro reservar o primeiro mês do projeto para conduzir algumas atividades de execução enquanto
se planeja o projeto. Nessa época, podem faltar informações que serão produzidas no futuro. Para
evitar que a ausência delas comprometa a consistência do plano é que se adicionam as “questões em
aberto e pendências”.
O quebra-cabeças mostrado no mapa mental inclui além dos planos, um capítulo muito
importante: o Sumário Executivo, habitual em planos de negócios produzidos por norte-
americanos. Como um sumário do que há de mais importante nos planos, ele cria uma
oportunidade fantástica. Comparando o Sumário Executivo do Plano do Projeto com o documento

40
anterior que é o Termo de Abertura, podemos a qualquer tempo avaliar o quanto o projeto mudou
por força do planejamento, em comparação com a referência. Quanto maior a defasagem entre
Sumário Executivo e Termo de Abertura, maior é a necessidade de aprovar novamente o Plano.
O Plano do Projeto na visão PMI assemelha-se a um tipo de Plano de Negócio (Business
Plan): aquele que não só explica o escopo do produto (comum em empreendimentos imobiliários),
não enfoca apenas a viabilidade econômica (comum quando visa a atrair investidores), não apenas
define a tecnologia, mas enfoca principalmente como será executado e controlado o projeto.

O que não se deve fazer ao planejar

Entre os vícios mais frequentes na produção de planos, encontram-se:
Elaboração a quatro paredes, excluindo os principais executores.
Imposição do plano a executores e afetados, criando verdades absolutas.
Divulgação restrita, tanto informal quanto burocrática.
Ausência de consenso real sobre estratégias preconizadas retira a credibilidade.
Abrangência incompleta impede que se tenha a visão do todo.
Detalhamento inadequado – macroscópico ou microscópico demais ou então desnivelado.
Pouco flexível, não comporta nuanças e pequenas mudanças.
Estático e “congelado”, não é revisado nem serve para efetuar simulações e projeções
de impacto.

Estratégias de execução de projetos

Questão de sagacidade
Uma das principais questões a resolver quando planejamos um projeto é definir as estratégias
de execução que ampliem a chance de sucesso. Essa tarefa exige muita sagacidade do gerenciador:
uma escolha errônea fará o projeto se arrastar por mais tempo, forçará um excesso de mudanças de
escopo e dificultará as relações, porque evoca a falta de profissionalismo do gerenciador do projeto.
Quantas estratégias de execução de projetos você conhece e utiliza porque formaram o
seu repertório?

41
Questões estratégicas
Definir estratégias de execução de projetos requer, como sempre, uma disciplina mental.
Primeiro, é preciso definir com qual parcela do escopo o projeto inicia e termina, porque isso não
foi pensado no pré-projeto e na elaboração do Termo de Abertura. O projeto só inicia depois de
escolhida a solução, ou ele inicia com o estudo de diferentes soluções e em algum momento seguinte
será escolhida a solução que será implantada? O projeto termina com o lançamento do produto do
projeto ou será prolongado por mais algumas semanas, para que a equipe do projeto forneça apoio
aos usuários? Essas são questões estratégicas.
Outras questões estratégicas: devemos testar o produto do projeto em um campo limitado,
para ter certeza dos resultados antes de lançar esse produto no mercado? Devemos segmentar a
equipe do projeto na fase de implantação ou contratar terceiros para suprir pessoal em momentos
de sobrecarga?
O projeto pode iniciar somente quando a especificação estiver aprovada ou então pode incluir
esse trabalho no seu escopo. Pode iniciar com solução já definida ou a seleção da solução pode
compor a fase inicial de execução. O projeto pode terminar na fase de concepção e estudos,
remetendo a implantação para um projeto posterior. Pode terminar no fim da implantação ou pode
prolongar-se até a fase de pós-implantação, mas todo projeto precisa terminar para demarcar que a
partir daquele ponto o produto do projeto entrará em operação rotineira.

Combine mais de uma estratégia

O próximo quadro compila as mais usadas estratégias de execução de projetos, cada qual em
resposta a uma situação. A primeira estratégia é a única mencionada no PMBOK Guide: quanto
mais riscos e incerteza há no projeto, melhor repartir em muitas fases; se cada fase terminar com
um entregável, ela se torna um “ponto de controle” em que se pode tomar a decisão “go/no go” –
vale continuar ou não?
Se a organização tem dúvidas sobre o projeto, vale a pena adotar a segunda estratégia: leve o
estudo para dirimir a dúvida para dentro do projeto, criando uma fase de concepção, que termina
com a decisão “go/no go”. O mesmo ocorre se há controvérsias sobre a solução ou produtos do
projeto: uma fase inicial estuda soluções e culmina com a seleção da melhor, que permite a
continuidade do projeto (estratégia 3).

42
 Uma questão muito comum em projetos de desenvolvimento de produtos é a incerteza sobre
a aceitação dele no mercado. Para essa questão, duas estratégias podem ser escolhidas. A estratégia
4 é a implantação-piloto, usada desde os anos 1950. A implantação-piloto é usada quando se
pretende avaliar as dificuldades de execução e os ganhos obtidos após a implantação, por isso ela é
feita em um âmbito restrito, com fronteiras definidas e controladas. Escolha uma pequena parcela
do mercado, com demografia similar ao do mercado e lance o produto do modo planejado. No fim
de certo período, os resultados do piloto são avaliados e se decide por continuar a implantação (roll
out) ou não. A estratégia 5 é mais simples: trata de antecipar entregas para criar “fatos consumados”
que demonstram a todos que o projeto avança.

Questão Estratégias de execução

1) Subdividir o projeto em fases, cada qual concluindo com um

Elevado risco e
entregável para aumentar a governabilidade da execução. As
incerteza no projeto
fases podem ser superpostas, e os entregáveis tornam-se
como um todo
pontos de controle.

Tema do projeto
2) Limitar o escopo aprovado apenas à fase de concepção: no
controverso, muito
fim dela, decide-se sobre a continuidade da execução.
inovador ou duvidoso

Incerteza sobre a
3) Dividir o projeto em fases – o fim da primeira fase, destinada
tecnologia, metodologia
ao estudo da solução, entrega a definição requerida para
ou produtos usados no
executar as fases posteriores.
projeto

4) Destinar uma fase à implantação-piloto em condições

Incerteza sobre os controladas, no fim da qual será decidido generalizar a
benefícios e ganhos do execução em fase posterior.
projeto 5) Criar vitórias precoces (quick wins), comprovando os ganhos
desde cedo.

Enorme esforço é 6) Repartir em segmentos a fase trabalhosa, multiplicando-se

requerido para a as equipes de executores, que atuam em paralelo (ex.:
execução implantação em escala nacional).

Incerteza sobre a
7) Estabelecer uma fase de teste, simulação em plataforma ou
operação do produto do
operação experimental assistida pela equipe do projeto.
projeto

43
 Questão Estratégias de execução

8) Ampliar o escopo do projeto, acrescentando uma fase de

pós-implantação destinada a acompanhar e controlar a
operação nos primeiros meses.
Incerteza sobre a
9) Antecipar divulgação e treinamentos, de modo a mapear a
adesão do usuário ao
adesão obtida com os usuários treinados.
produto do projeto
10) Forçar a adesão de todos a partir de um Dia D (estratégia big
bang), quando sistemas e processos são definitivamente
alterados.

Dificuldade de
11) Dividir em fases o projeto, aprovando recursos fase a fase,
assegurar fontes de
depois de fazer um balanço da implantação em cada fase.
investimento

12) Antecipar a execução de modo a ampliar a chance de

controlar o pessoal adicionalmente requerido.

Imprevisibilidade do 13) Desenvolver terceiros para reduzir sobrecargas em certas

esforço requerido na atividades, em contratos que permitam a rápida mobilização
execução de pessoal.

14) Planejar para contingências: criar Planos B e C conforme

cenários otimista e pessimista.

15) Adotar estratégia em ondas sucessivas, definindo o prazo

Muitas ações precisam
ser iniciadas e há
incerteza sobre a
capacidade de gestão
entre elas para maior controle. A primeira onda tem menor
escala e serve ao aprendizado da equipe. Assim que se reduz
o esforço da equipe na primeira onda, é iniciada a segunda
onda com essa equipe, enquanto outros cuidam do restante
da implantação da onda anterior, e assim por diante.

Em projetos cuja implantação ocorre na geografia do Brasil ou em escala mundial, costuma-

se adotar a estratégia 6. Somente na fase de implantação ocorre o reforço e a segmentação da equipe
do projeto para a implantação simultânea em diferentes locais.
Em projetos de novas instalações, costuma ocorrer uma questão: o pessoal operará com eficácia e
eficiência? Para essa questão, é usual a estratégia 7: adicionar ao escopo uma fase de testes e uma fase de
operação experimental, em que o pessoal opera com assistência da equipe do projeto.

44
 Situação similar ocorre em projetos de desenvolvimento de sistemas: há dúvidas sobre a adesão
dos usuários ao produto do projeto. Há três estratégias para a sua escolha. A estratégia 8 envolve somar
uma fase de pós-implantação, pelo período de tempo necessário para a equipe do projeto apoiar
usuários, corrigir defeitos precoces e avaliar resultados. A estratégia 9 envolve antecipar treinamentos a
usuários para medir se está ocorrendo demasiada resistência a mudanças, ainda a tempo de se reforçarem
as ações de aceitação. A estratégia 10 é bastante assertiva, contudo funciona: envolve definir um Dia D
em que tudo o que existia é desmobilizado e todos são forçados a usar o produto do projeto – muitos
denominam essa estratégia cinicamente de big bang.
Uma situação frequente em megaprojetos é a dificuldade de financiar o projeto como um
todo. A estratégia 11 envolve repartir o projeto em fases e aprovar orçamento fase a fase.
Quando o projeto envolve enorme abrangência para a implantação, além da estratégia 6,
outras são usadas. A estratégia 12 envolve antecipar a execução para que as dificuldades se
evidenciem a tempo de rever os planos e o sistema de gestão adotados. A estratégia 13 envolve fazer
um contrato por “ordens de serviço”, de tal modo que pessoal adicional pode ser fornecido
temporariamente para cobrir lacunas. A estratégia 14 indica que há outro modo de pensar
estratégias: trate a questão como um risco do projeto e crie respostas de planos B e C, contingenciais,
caso problemas aconteçam.
Por fim, a estratégia 15 é de uso mais recente: a implantação em ondas sucessivas. A implantação
em ondas significa iniciar a implantação por uma parte (do escopo ou da abrangência) e, antes mesmo
de terminar essa implantação, a equipe responsável pela primeira onda se desloca à próxima e a implanta.
Sucessivamente, o escopo vai sendo implantado. Nesse caso, os benefícios são avaliados periodicamente
e confrontados com a amplitude do que foi até então implantado. É o caso de projetos de mudança
cultural: a primeira onda divulga o propósito de mudança, a segunda avalia prós e contras, a terceira
visa a engajar pessoal na experimentação, e assim por diante.
Existe tanta confusão entre as estratégias de ondas e piloto que justifica explicar as diferenças.
O piloto é temporário, e pode resultar na decisão de recolher o produto e interromper o projeto. A
primeira onda não será interrompida, a sua execução avançará pelo tempo exigido, mesmo que
outras ondas sejam superpostas.
Note as palavras que se repetem na primeira coluna do quadro: dúvida, risco, incerteza,
dificuldade, etc. Significa que o verdadeiro propósito de estabelecer estratégias de execução é
mitigar riscos e incerteza.
Essas 15 estratégias podem ser combinadas conforme o grau de incerteza do projeto. Quanto
mais incerto, mais estratégias merecem ser somadas ao escopo do projeto. Para que as estratégias
sejam evidenciadas, é conveniente adaptar a EAP para que as mostre, seja no primeiro, seja no
segundo nível da “árvore” ou da lista enumerada.

45
Primeiro a estratégia, depois a tática
Inúmeras estratégias de execução foram criadas e são usadas em projetos. A principal
característica dos projetos é a existência de riscos e incerteza. Não é de estranhar que as diferentes
estratégias usuais de execução derivem exatamente dessa característica.
Quem executa o projeto sem estratégia antes definida se sujeita ao vai e vem tático: ora segue
em uma direção, ora muda para outra direção. Definir estratégias é definir uma direção ótima que
mitiga riscos e amplia a chance de sucesso. Primeiro, defina as estratégias; depois, deduza as táticas!

Escopo em projetos
Você conhece o conceito de escopo?
Você sabe definir os escopos (scope) de um projeto? O Alcorão dos muçulmanos afirma: “para
quem não sabe onde quer chegar, qualquer caminho serve”. O escopo compreende a definição de
onde se quer chegar, ou seja, o produto do projeto, e o caminho para obtê-lo, ou seja, as atividades
por realizar. Se não sei o que quero, não sei o que fazer nem como fazer.

Necessário gerir escopos

Em uma abordagem mais técnica, o escopo é a primeira questão a gerir em um projeto. Uma
abordagem mais estratégica define primeiro o valor de negócio do projeto; os objetivos, resultados
e benefícios; os principais interessados; e a expectativa de prazos e investimento. Só depois de definir
isso é que se definem os escopos. Esses conteúdos foram feitos no pré-projeto e formalizados no
Termo de Abertura do Projeto, que delimita a iniciação do projeto.
Depois de iniciado o projeto, na fase de planejamento todos os conteúdos são detalhados e
eventualmente revistos. Planejar um projeto envolve realizar pelo menos nove planos. Por onde
começar? Cada plano afeta e é afetado pelos demais. O melhor é fixar um prazo, por exemplo, de
30 dias, e executar todos os planos simultaneamente: cada plano completado obriga a rever todos
os completados anteriormente. Assim, não importa por onde começar, importa, sim, que o
documento Plano de Gerenciamento do Projeto seja completo, coerente e consequente (incentiva
e facilita a execução do projeto).
Minha preferência pessoal é começar pelo planejamento de interessados, comunicação, riscos,
qualidade e aquisições, para só depois planejar os escopos, que por sua vez determinam o
planejamento dos recursos humanos, tempos e custos. Sem falar em outros planos especiais: plano
de gestão do conhecimento, plano ambiental, plano de ética, etc.

46
“Esculpindo” escopos
O propósito da Gestão de Escopos do Projeto é “assegurar que o projeto inclui todo o
trabalho necessário, e apenas o necessário, para terminar o projeto com sucesso”. O PMI alerta que
escopo compreende o trabalho e os resultados ou produtos desse trabalho, portanto, há dois tipos
de escopo a serem geridos:
Escopo do produto – “as características e funções que caracterizam um produto, serviço
ou resultado”.
Escopo do projeto – “o trabalho que deve ser realizado para entregar um produto, serviço
ou resultado com as características e funções especificadas”.

Por exemplo, em um projeto de desenvolvimento de um novo automóvel, o escopo do

produto indica: sedan, quatro portas, motor 1,6 CV, freios ABS, quatro airbags, som, ar-
condicionado, direção hidráulica, câmbio automático. Toda a especificação técnica faz patê do
“escopo do produto”. Já o “escopo do projeto” inclui o trabalho requerido para desenhar,
desenvolver maquinário, treinar mão de obra, preparar fornecedores, produzir e distribuir lote
inicial, conceber e realizar ações mercadológicas e, claro, gerenciar o projeto. Todas as estratégias
de execução, tipo subdividir em fases ou fazer piloto pertencem ao escopo do projeto.
Se o propósito da gestão de escopos é assegurar que o escopo foi
adequadamente gerido para obter sucesso no projeto – e sucesso significa atingir
objetivos, resultados e benefícios esperados e também atender às necessidades e
expectativas de interessados, buscando a sua satisfação –, podemos deduzir
como praticar a gestão de escopos. A figura a seguir revela os seis processos de
gestão associados.
Na norma PMBOK Guide, cada processo tem entradas (inputs),
ferramentas e técnicas (tools) e saídas (outputs) – típico da visão cibernética. As
entradas são fontes de informação, as ferramentas servem à gestão e as saídas
apresentam produtos, resultados do trabalho e entregáveis (deliverables).
Este é um conceito muito útil: a gestão envolve trabalho intelectual por
natureza intangível. Para avaliar a gestão, é preciso tangibilizar esse esforço em
entregas potenciais: qualquer resultado ou produto exclusivo que torna
tangíveis as ações realizadas e, portanto, verificáveis. Exemplos de entregável:
um documento, evento, sinal, protótipo ou produto intermediário do projeto.
Quanto mais entregáveis, mais tangível e controlável, portanto, mais fácil é a gestão.

47
 Planejar Gestão de Escopos é o processo de criar um plano que documenta como o escopo será
definido, validado e controlado. Se a organização tem políticas e procedimentos que definem quem,
quando e como fazer a gestão de escopos, no projeto esse processo de gestão é dispensável
(lembrando que não é obrigatório usar os 47 processos de gestão). Esse processo tem dois
entregáveis: Plano de Gestão de Escopos e Plano de Gestão de Requisitos, tamanha é a dificuldade
de coletar requisitos.
Coletar Requisitos “é o processo de definir e documentar as características e funções do produto
e do projeto que atendam às necessidades e expectativas de interessados”. Outro conceito essencial:
requisito (requirement) é “uma condição ou capacidade que deve ser atendida ou possuída por um
sistema, produto, serviço, resultado ou componente para satisfazer um contrato, uma norma, uma
especificação ou outros documentos formais. Os requisitos incluem necessidades, desejos e
expectativas quantificados e documentados do patrocinador, do cliente e de outros interessados”.
Definir escopos é o esforço de detalhamento e documentação do escopo do produto e do
projeto. O PMI sugere que é raro um projeto começar com o seu escopo perfeitamente definido: o
usual é iniciar o projeto com uma macrodefinição do escopo que é definida por completo quando
do planejamento. Significa que escopos mudam, eles não são “congelados”, como muitos gostariam.
Ao definir escopos, a norma recomenda também definir as exclusões, os itens fora de escopo.
Também as premissas e restrições e os critérios de aceitação do projeto. A norma menciona que há
uma redundância com o conteúdo do Termo de Abertura, mas como são feitos em épocas distintas
e por pessoas distintas, na maioria das vezes, vale a pena revisitá-los.
Criar EAP – Estrutura Analítica do Projeto (Work Breakdown Structure – WBS) é organizar
escopos de forma lógica para facilitar a compreensão em projetos complexos. A EAP subdivide o
projeto desde estratégias, macroatividades até chegar aos pacotes de trabalho, a mais detalhada
medida de trabalho que se deseja controlar. A EAP também subdivide o projeto por algum critério
em cada nível de detalhamento. Nas últimas décadas, é a ferramenta de gestão mais importante, na
visão da comunidade do PMI.
Há uma diferença importante envolvendo os últimos processos de gestão de escopos. Validar
Escopos significa validar a aceitação de entregáveis. Controlar Escopos abrange monitorar os escopos e
decidir sobre mudanças no escopo do produto ou do projeto. Se não é possível congelar os escopos
durante a execução do projeto, controlar escopos é o meio de evitar que se entregue “gato por lebre” –
o gerenciador nunca perde o controle do escopo aprovado em um dado momento da execução.
Como se percebe, os requisitos se desdobram em escopos que são controlados para que
qualquer mudança assegure o pleno atendimento aos requisitos. Se não foram coletados os
requisitos juntos aos principais interessados, o escopo perde controlabilidade, as mudanças são
aceitas por critérios frágeis, o excesso de mudança causa imensos distúrbios na execução, ameaçando
o sucesso do projeto.

48
Sem definir não se controlam os escopos
Gerenciar escopos é fundamental no gerenciamento de projetos. Envolve competências duras,
na sua maioria: desenvolve uma abordagem técnica do projeto, conecta o conhecimento técnico
com o conhecimento em gestão, é o canal para incorporar inovação e desenvolver estratégias para o
projeto. Faça do “limão uma limonada”: enriqueça o escopo dos seus projetos, sejam eles pessoais
sejam eles profissionais. Obterá recompensas por esse esforço.

Gestão de interessados do projeto

Com quem contar?
Com quem você realmente conta nos seus projetos? Essa questão é perturbadora, porque
pressupõe que nem todos aceitam e apoiam um projeto, independentemente dos seus papéis e das
suas responsabilidades. Os interesses de cada um determinam os comportamentos que terão durante
a execução do projeto. Para piorar, como as expectativas deles mudam, os interesses e
comportamentos também mudam ao longo do ciclo de vida de um projeto.

Envolvidos e afetados
Ao redor de um projeto, são agregadas inúmeras pessoas ou organizações com interesses e
expectativas sobre ele. Além do mais, se os projetos são o principal meio para introduzir mudanças
nas organizações, isso significa que a execução de um projeto afeta diversas pessoas ou organizações.
Esses afetados podem reagir positiva ou negativamente. Por isso, é crucial conhecer precocemente
quem são esses interessados (stakeholders), de modo a propor estratégias para estimular o seu apoio
ao projeto e para mitigar impactos negativos.
A gestão de Interessados do projeto foi adicionada ao PMBOK Guide na quinta edição, de
2013, demonstrando a importância do tema. Alguns processos, antes pertencentes à gestão da
comunicação do projeto, ganharam relevância na norma em vigor.

Mais que cliente

Stakeholder é um neologismo, portanto, de difícil tradução. Compreender como foi criado e
usado amplia a nossa compreensão e desenvolve sagacidade. Muitos brasileiros desatentos escrevem
steakholder (significaria algo relacionado a bifes) que foneticamente é semelhante a stakeholder.
Na construção, stakeholders são as pequenas estacas de madeira usadas para fazer marcações
de obras. Não é esse termo técnico que interessa a gestores. O neologismo foi cunhado em uma
discussão em que a indústria norte-americana era comparada à japonesa. Dizia-se que nos EUA a
maior preocupação dos gestores era com o acionista – shareholder – enquanto no Japão havia o

49
entendimento de que a organização lida com diferentes atores. A corruptela de shareholder gerou
stakeholder. Nos EUA, at stake significa “em jogo”; portanto, stakeholder se associa aos jogadores,
apostadores, ou melhor, partes interessadas, como o PMI traduz.
O PMBOK Guide define:

Interessados do projeto (stakeholders) são pessoas ou organizações, tais como

clientes, patrocinadores, a organização empreendedora e o público ativamente
envolvido no projeto, ou cujos interesses podem ser positiva ou negativamente
afetados pela execução, término ou cancelamento do projeto.

Ampliando os exemplos fornecidos na norma, note a variedade e quantidade de interessados

em um projeto:
organização empreendedora (representada por dirigentes);
clientes, usuários e beneficiários do projeto (internos ou externos à organização);
acionistas, investidores e financiadores;
patrocinadores (apoiam e legitimam projetos);
conselho;
gestores de portfólio e gestores de programas correlatos;
Escritório de Gerenciamento de Projetos – EGP (funcionários do EGP, auditores e pessoal
de suporte);
gerenciador e equipe do projeto;
gestores funcionais (diretorias e gerências envolvidas, inclusive áreas de apoio);
parceiros e fornecedores;
governo, nos papéis regulatório, fiscalizador, tributário e desenvolvimentista;
comunidade afetada, grupos de interesse ou sociedade civil (em certos casos);
formadores de opinião internos e externos (veículos de comunicação) e
concorrentes.

Com tantos interessados, alguns positivos e outros negativos, ainda mais com interesses e
expectativas variando ao longo do tempo, realizar o projeto pode ser uma tarefa quixotesca, caso o
gerenciador não procure agregar e atender eticamente a tantos.

50
 A figura ao lado apresenta os quatro processos de Gestão de Interessados
do Projeto. Identificar Interessados envolve criar um Registro de Interessados,
contendo nome, cargo e posição no projeto, além dos meios de contato com
eles. Para isso, as fontes de consulta são: Termo de Abertura do Projeto,
contratos, legislação, organograma da organização e registros de experiências
similares. Isso não basta, é preciso avaliá-los de modo a discernir quem são os
relevantes entre as dezenas de interessados levantados.
Note que os interessados são pessoas, grupos ou organizações que podem
“afetar, serem afetados ou sentirem-se afetados por uma decisão, atividade ou
resultado de um projeto”. Dessas condições decorrem os seus interesses
positivos ou negativos.
O sucesso do projeto requer a identificação precoce dos principais interessados, para que se
possa engajá-los no momento oportuno. A ausência desse processo faz com que muitos se coloquem
de imediato em oposição ao projeto, e essa atmosfera pode crescer e tornar-se ainda mais perniciosa
durante a execução.
Planejar Gestão de Interessados envolve “desenvolver estratégias apropriadas de
gerenciamento para engajar as partes interessadas de maneira eficaz no decorrer de todo o ciclo de
vida do projeto, com base na análise das suas necessidades, interesses, e impacto potencial no sucesso
do projeto”. Possivelmente, é um dos planos mais importantes entre os reunidos no Plano de Gestão
do Projeto e merece uma discussão especial.
Gerenciar o engajamento de interessados requer usar da comunicação para estabelecer o melhor
relacionamento com os interessados relevantes, incentivando o maior engajamento deles no projeto.
Na prática, significa “colocar todos no mesmo barco”. Para o PMI, gerenciar o engajamento envolve
ações tais como:
Engajar interessados para obter ou confirmar o seu compromisso contínuo com o êxito
do projeto.
Gerenciar as suas expectativas por meio de negociação e comunicação para assegurar o
alcance das metas.
Abordar proativamente preocupações potenciais que ainda não se tornaram problemas e
antecipar problemas futuros que podem ser colocados por interessados.
Esclarecer e solucionar questões identificadas.

Note que a influência dos interessados é maior no início do projeto e declina à medida que
entregáveis são liberados, daí a proatividade exigida. Contudo, as questões se avolumam com o
passar do tempo, e a influência negativa pode ser mais danosa. Esse processo requer competências
brandas citadas pela norma: confiança, escuta ativa, gestão de conflitos, gestão da mudança,
influência, buscar consensos, negociar e compreender a organização para alterar comportamentos
(e cultura).

51
 Controlar o engajamento de interessados é monitorar o engajamento dos interessados, ajustando
estratégias e planos como medida de controle. Em casos extremos, o controle do engajamento pode
recomendar a neutralização de interessados negativos, seja pela substituição, isolamento ou
exclusão. Para evitar as situações extremas, o monitoramento deve ser cuidadoso, e a análise desses
interessados deve incluir opiniões de dirigentes, especialistas e consultores.

Boa política
Se tivesse de renomear a gestão de interessados, eu a chamaria de gestão política, porque é
disso que se trata. Se a política é a arte de mediar antagonismos, cabe bem à situação de projetos
que têm dezenas de interessados, muitos positivos (adeptos, apoiadores, cooperativos), muitos
neutros (indiferentes, inertes, menosprezam o projeto) e muitos negativos (discordam, rejeitam,
sentem-se negativamente afetados pelo projeto).
Costumamos rejeitar a política, sobretudo, os gerenciadores de perfil técnico. Contudo, é
importante notar que as organizações são altamente politizadas: seja por disputas de poder, seja pelo
funil das oportunidades de carreira, seja pelo relacionamento externo com outras fontes de poder
político. Desprezar a política é ingenuidade; praticar a boa política a torna mais nobre e explicita o
seu valor: engajar a todos.

Estratégia de comunicação em projetos

Comunicação é tudo
Quem participa de projetos percebe muitos problemas: desentendimento sobre objetivos e
resultados do projeto; atraso nas decisões; falta de informação no momento de decidir; falta de
evidências e fatos para o controle; baixo engajamento dos envolvidos; tensões entre interessados;
desconfiança; maledicência; entropia na equipe do projeto. Todos eles são problemas de
comunicação. Entre as 10 áreas do conhecimento em projetos, considero a comunicação a mais
relevante para o sucesso.

Uma qualidade vasta e essencial

Comunicar é tornar comum, isto é, fornecer informação a todos os interessados. Informar
é diferente de comunicar: informar equivale a divulgar e propagandear – “mão única” que deixa
o receptor passivo; comunicar é “mão dupla” – promove relacionamentos. Ambos são essenciais
no projeto.
Sobre comunicar, o PMBOK Guide afirma: “a comunicação só se completa quando o receptor
indica que recebeu a mensagem e a compreendeu por inteiro”, o que é especialmente relevante na

52
comunicação por e-mail. Comunicar é codificar e decodificar mensagens, dado que segue o
modelo emissor-receptor da figura abaixo.

O PMI trata da comunicação abrangente: interna e externa; formal e informal; oficial e não;
verbal e não verbal; vertical (com a governança) e horizontal.
A qualidade das relações com interessados, da efetividade da governança e do trabalho em
equipe, da construção de identidade e reputação, do enfrentar resistência a mudanças – todos
dependem da qualidade da comunicação.

Eficiência depende de planejamento: efetividade de competência

O principal propósito da comunicação é criar um ambiente fecundo e sinérgico para a
execução do projeto, visando sempre ao sucesso e à efetividade dele. Comunicação gera
alinhamento, harmonia, transparência e confiança, promovendo relações éticas em que os
interessados podem oferecer o seu melhor.
O PMBOK Guide, mostra a figura, aborda três processos de gestão
envolvendo a comunicação, tratada em separado da gestão de interessados:
Planejar a Comunicação, Gerenciar a Comunicação e Controlar a Comunicação.
Vivenciando projetos, constato que só lidera o projeto quem lidera a
comunicação do projeto: se o gerenciador é reativo diante das necessidades e
expectativas dos interessados, como ele poderia liderar a execução? A comunicação
proativa é o principal meio para constituir a liderança de fato, e não de direito. Só
lidera o projeto, ressalto, quem planeja, executa e controla a comunicação, e é
contável por ela: na consistência da informação, na oportunidade e nos veículos utilizados.
Planejar a Gestão da Comunicação requer abordagem de comunicação baseada em
necessidades e expectativas dos interessados. Abrange:
Definir para cada interessado relevante – conteúdo, veículo e periodicidade da
comunicação.
Regrar e dar ritmo à tomada de decisão.
Balancear entre o comunicar (relacionamento) e o informar (divulgação).

53
 Gerenciar Comunicação envolve criar, coletar, distribuir, armazenar, recuperar e apagar
informação do projeto, isto é, envolve aplicar o plano de comunicação. A qualidade desse processo
depende das tecnologias e políticas de comunicação adotadas pela organização: não basta o esforço
da equipe do projeto. Controlar Comunicação é o processo dedicado a monitorar e controlar a
comunicação ao longo do ciclo de vida do projeto para assegurar a sua efetividade. Se a comunicação
perde eficiência/eficácia, o plano é revisto e aprimorado.
Ainda é raro encontrar organizações que exigem comunicação planejada dos gerenciadores de
projeto. Consequência disso é o excesso de reuniões demoradas e improdutivas, o excesso de
documentos de informação incongruentes entre si, e um esforço exagerado ou negligente da equipe
do projeto, sem obter efetividade da comunicação. Comunicação é o principal problema em
projetos, informa o benchmarking feito pelos capítulos brasileiros do PMI há anos. Diante disso, o
maior esforço deve ser dedicado ao planejamento da comunicação.
O PMBOK Guide recomenda que um Plano de Comunicação do Projeto deve conter:
requisitos de comunicação para cada interessado relevante;
informação – formato, conteúdo, nível de detalhe;
responsáveis pela comunicação;
público-alvo – pessoa ou grupo que receberá informação;
veículos – métodos ou tecnologias usadas para formatar a informação;
frequência – periodicidade e período de tempo do envio ou coleta de informação;
escalação – critérios para escalar decisões e nome dos responsáveis, caso a caso;
atualização – métodos para atualizar o plano de comunicação à medida que o projeto
progride e
glossário dos principais termos.

Note que, quando coletar requisitos e analisar interessados, é importante coletar requisitos de
comunicação: como o interessado deseja ou necessita comunicar-se. Se é um tema tão relevante,
note que cada comunicação precisa ter um responsável designado para ela. Dessa recomendação,
deduzimos como elaborar o plano, basta identificar: informação, responsáveis, público, veículos ou
mídias e frequência da comunicação. A esses itens, costumo acrescentar no plano a forma, que
explica local, duração, registro e infraestrutura requerida.
Porém, a norma adiciona três itens muito importantes: escalação, atualização e glossário. Os
critérios de escalação derivam da governança e indicam quando ocorre a comunicação para decisões
que excedem a alçada do gerenciador. Como todo plano merece controle, a norma sugere a revisão
dos planos, que prefiro fazer periodicamente. Como toda comunicação é sujeita a “ruídos” ou
interferências, diz o modelo emissor-receptor, um glossário garante o entendimento e alinhamento
de todos para a linguagem adotada.

54
 Informação sobre o quadro-síntese do projeto;
projeto informação geral do projeto;

equipe responsável, alterações da equipe, níveis de esforço do

pessoal (Hh)
Informação sobre a
equipe governança do projeto;

matriz de responsabilidades e as suas alterações;

Informação sobre situação atual: fotos, esquemas, tabelas;

status balanço da situação e consequências;

controle de escopo: atual versus oficial;

painel de controle: indicadores de desempenho e comentários;

evolução física, financeira, de pessoal, de contratações, de

fornecimentos, de produção;
Informação sobre
controle dos investimentos;
progresso
controle de desempenho: Gestão pelo Valor Agregado;

análise das ocorrências (imprevistos, contingências) e decisões

tomadas;

alterações no sistema gerencial: equipe, processos, normas;

mudanças solicitadas, impactos e sugestões de encaminhamento

para a decisão;

tendências: simulações, análise de impactos e alternativas para

Informação sobre apreciação e decisão;
tendências
revisão das metas: proposta para decisão;

decisões urgentes;

próximos passos: horizonte de curto prazo.

Para facilitar o planejamento da comunicação, o quadro acima explora a informação usual

em projetos. Quanto aos veículos de comunicação, são geralmente usados:
veículos de informação:
jornais, periódicos, murais, impressos, displays, TV corporativa, showrooms;
meios digitais, intranet, e-mail, portal de projetos e investimentos;
eventos comemorativos, reuniões abertas e assembleias;

55
 reuniões e eventos:
reunião de lançamento do projeto, kick-off meeting (apresenta quem está
comprometido), reuniões de apresentação e apresentações itinerantes (road-show);
reuniões periódicas de avaliação, reunião de balanço do projeto, apresentações a
comitês e a dirigentes, reunião de grupo focal com usuários ou clientes,
videoconferência;
eventos de reconhecimento, de comemoração e de networking com parceiros,
premiações;
treinamentos presenciais, a distância e para autodesenvolvimento;
veículos formais:
contratos, concursos, correspondências oficiais e declarações ao público;
encartes, press-releases, casos de sucesso, guia rápido, informativos;
relatórios de status, de progresso ou de tendências.
veículo específico para projetos e situações de crise:
sala de estratégia (war room) – local de acesso restrito usado para reuniões sem
pauta para deliberar assuntos de ação imediata e cotidiana e
brindes, selos, lembretes, encontros informais (happy hour).

Costumo usar o planejamento da comunicação para também planejar as ações educacionais,

na falta de outro plano que a considere. Afinal, treinamento é um veículo de comunicação por
excelência. O extrato de um plano exemplifica a comunicação de um projeto:

Público-
Veículo Frequência Conteúdo Forma Responsável
alvo

Diretor Situação atual Reunião de

uma hora na
Reunião patrocinador Mensal, a EVM e
sede, com ata Gerenciador
mensal de equipe do partir de indicadores
registrada na do projeto
avaliação projeto mar./16 decisões urgentes
base de
convidados próximos passos conhecimentos

Diretor Balanço da Evento de três

execução horas em Gerenciador
patrocinador
No fim da avaliação de hotel, com do projeto,
Evento de equipe do
Fase 4 satisfação registro em com apoio
comemoração projeto
(implantação) reconhecimentos vídeo e de RH e
convidados distribuição de comunicação
à equipe e aos
imprensa engajados relatório final

56
 O quadro anterior oculta as seguintes estratégias que uso ao planejar a comunicação:
1. Para explorar oportunidades de comunicação, acrescento mais públicos ao alvo
(“carona”).
2. Mesclo veículos formais com informais, divulgação com contatos, comunicação
planejada com a que ocorre naturalmente sob demanda.
3. Cautela – o excesso de comunicação é tão contraproducente quanto a falta de comunicação.
4. Quanto maior a resistência a mudanças, mais comunicação é requerida.

Todos os itens do plano de comunicação se somam ao escopo do projeto e figuram no

cronograma – afinal, se a comunicação é essencial e consome horas de esforço de todos, ela precisa
ser evidenciada e controlada. Como o restante do Plano do Projeto, o Plano de Comunicação deve
ser aprovado pelos interessados para que de fato atenda às suas necessidades e expectativas.

A verdadeira liderança comunica

A ênfase em comunicação denota a mentalidade democrática (“tornar comum”), agregadora
e voltada para o sucesso do projeto. Gestores com essa mentalidade dedicam parte significativa do
seu tempo para a comunicação, deixando as atividades técnicas para membros da equipe do projeto.
Mesmo em projetos controversos ou pesarosos, em situação de normalidade ou de crise, essa
qualidade da gestão forma as verdadeiras lideranças. Não se apoia em fatos consumados, não força
nem obriga, apenas conquista.

57
MÓDULO III – PLANEJAMENTO:
COMPLEMENTAÇÃO

O módulo 3 completa as técnicas de planejamento de projeto que desejamos que

experimente. Neste módulo, será apresentado também um caso de Plano de Gerenciamento de
Projeto, contendo todos os planos considerados na norma do Project Management Institute (PMI),
ou seja, além dos planos produzidos nesta disciplina.
Ao final do módulo, esperamos que você seja capaz de:
desenvolver a capacidade de analisar riscos e criar respostas para os mais severos;
entender como um cronograma é elaborado, usando sistemas de gestão de projetos e
compreender a metodologia de gerenciamento de projetos em uma visão sistêmica,
incluindo algumas considerações sobre as metodologias ágeis em voga atualmente.

Gestão de riscos: ameaças e oportunidades

Precisa de sorte?
É da natureza humana que os jovens sejam audaciosos, aventureiros e, por necessidade de
“adrenalina”, atraídos e expostos demasiadamente a riscos. Enquanto amadurecem, as pessoas
mudam a sua aceitação a riscos; às vezes, até vão para o extremo oposto e se tornam avessos a riscos,
mas existe um “caminho do meio”: aquele em que aceitamos muitos riscos sem nos tornarmos
“amantes do risco”, porque sabemos como lidar com eles.
Quanto maior a competência em gerir riscos, maior a nossa capacidade de empreender e lidar
com desafios extraordinários. Nesse ponto, deixamos de depender da sorte e de condições
favoráveis: o sucesso e a sorte não caem do céu, nós construímos.
Desafiando deuses
Nos tempos antigos, tudo era creditado ao acaso e à ação de deuses. O povo era supersticioso:
era a forma de lidar com coisas que não estavam sob o seu controle. No início da época moderna,
século 17, ocorre uma mudança cultural. Depois das grandes descobertas marítimas, na Itália, a
marinheirada gritava “cuidado com o risco”, porque se a embarcação passasse sobre arrecifes e
houvesse um risco no casco, fatalmente iria naufragar. Risco passou a ser um conceito; tanto é que
o verbo risicare no italiano tanto significa riscar, como arriscar. A ciência progredia aceleradamente,
e o conceito de risco demarca o momento em que decidimos assumir esses azares como a nossa
responsabilidade e fonte de controle – e assim desafiamos os deuses.
Riscos estão em toda parte. Derivam do desconhecimento e da ignorância. Derivam da
incerteza sobre o futuro, que traz acidentes, imprevistos, motivos de “força maior” e casos fortuitos
nos contratos, do conturbado e do incontrolável. Isso não significa que sempre queremos eliminar
ou mitigar riscos.
Qualquer risco tem uma dupla natureza: dependendo de como o encaramos pode ser positivo
ou negativo. Vou dar um exemplo: pense nas respostas que funcionários dão para o risco de serem
demitidos. Por um lado, eles podem: esforçar-se mais no trabalho; evitar conflitos ou
comportamentos não aceitos; fazer treinamentos para melhorar o seu desempenho; cancelar viagens
de férias; cortar despesas supérfluas; e adotar medidas legais de proteção ao emprego, tornando-se
membros da Comissão Interna de Prevenção de Acidenttes (Cipa), de sindicatos, ou até mesmo
engravidar, no caso de mulheres. Por outro lado, e tão usual quanto, podem: atualizar o seu
curriculum; divulgar na sua rede de relações (networking) que está em busca de novos desafios; fazer
cursos para ampliar a sua empregabilidade; buscar outra fonte de renda; buscar novo emprego;
tornar-se empreendedor. Esse risco é apavorante, ninguém gosta de ser demitido, mas a amplitude
de respostas é enorme. Alguns percebem no risco uma ameaça a ser mitigada ou eliminada;
enquanto outros percebem oportunidades a serem exploradas.
A atitude empreendedora se manifesta na gestão de riscos. Diferentemente do pessoal de
finanças e de seguros, para o gerenciador de projetos os riscos não são necessariamente nocivos.
“Quem não arrisca não petisca”, aforismo brasileiro, e “Nothing ventured, nothing gained”, aforismo
norte-americano, sugerem que riscos e oportunidades são duas faces de uma mesma “moeda”: não há
oportunidade sem risco, assim como não há risco que não carregue consigo alguma oportunidade.

Ameaças e oportunidades: como queremos responder?

O Guia PMBOK afirma que há dois objetivos para a gestão de riscos em projetos: aumentar
a probabilidade e os impactos de eventos positivos e mitigar probabilidade e impactos dos eventos
negativos. Note que enfatiza as oportunidades tanto quanto as ameaças. Então, o propósito da
gestão de riscos é ampliar o sucesso do projeto.

60
 A norma define risco individual como “um evento ou condição incerta que, se ocorrer,
provocará um efeito positivo ou negativo em um ou mais objetivos do projeto”. O risco geral do
projeto é efeito da incerteza, fonte de riscos e crises: “o risco tem origem na incerteza existente em
todos os projetos”. Existe risco no contexto ao redor do projeto, em condições da organização que
hospeda o projeto ou os riscos decorrentes da própria situação de execução do projeto.
“As organizações percebem os riscos quando eles estão relacionados a ameaças ao sucesso ou
a oportunidades para ampliar a chance de sucesso do projeto”, afirma a norma, e conclui: “a
organização deve estar comprometida com uma abordagem proativa e consistente de gerenciamento
de riscos durante todo o projeto”.
Há sete processos de gestão envolvendo riscos do projeto, mostra a figura.
Planejar o gerenciamento dos riscos é o processo de definição de como conduzir as
atividades de gerenciamento dos riscos de um projeto. Identificar os riscos é o
processo de determinar os riscos que podem afetar o projeto e documentar as
suas características. Realizar a análise qualitativa dos riscos é o processo de
priorização de riscos para análise ou ação posterior por meio da avaliação e
combinação da sua probabilidade de ocorrência e impacto. Realizar a análise
quantitativa dos riscos é o processo de analisar numericamente o efeito dos riscos
identificados sobre os objetivos do projeto. Planejar respostas aos riscos é o
processo de desenvolvimento de opções e ações para aumentar as oportunidades
e reduzir as ameaças aos objetivos do projeto. Implementar respostas a riscos
envolve realizar os planos acordados, se é que eles não foram adicionados ao
escopo do projeto. Controlar os riscos é o processo de implementar planos de
respostas aos riscos, acompanhar os riscos identificados, monitorar riscos
residuais, identificar novos riscos e avaliar a eficácia do processo de gestão dos
riscos durante todo o projeto.
Se a organização dispõe de políticas sobre riscos, o processo de planejar a gestão de riscos é
dispensável. Certas organizações determinam que o Escritório de Projetos auxilie a equipe do
projeto na identificação de riscos. Transnacionais e empresas de capital aberto determinam que os
riscos corporativos dos projetos sejam informados à matriz, tamanho pode ser o impacto deles sobre
a organização. Outras organizações determinam a realização periódica da identificação, análise e
respostas a riscos.
A identificação de riscos é o processo que merece mais cuidado, porém ninguém fica imune
a riscos, daí decorrendo que só percebemos os riscos que desejamos perceber. A audácia juvenil
é consequência de não perceber os riscos ou os seus impactos – e não é por falta de informação, é
que a perspectiva de se defrontar com a morte é tão avassaladora que preferem não tomar
consciência dos riscos – não de forma consciente. O mesmo ocorre com gestores maduros: os riscos
catastróficos convenientemente são deixados de lado.

61
 Chernobil, a maior catástrofe causada pelo humano na história estranhou ao governo
soviético: como poderia a elite dos técnicos soviéticos desprezar, como fizeram, o risco de uma fusão
descontrolada do reator, por erro de operação? Depois de acarear dezenas deles, a resposta mais
ouvida foi: “Isso nunca iria acontecer”. Também a melhor polícia do mundo, o FBI, desprezou os
cinco pedidos de investigação no ano que antecedeu o 11 de setembro; um dos pedidos citava a
escola de aviação e o nome de terroristas que depois morreram no ataque. Dez anos depois, o FBI
negligenciou informe do serviço secreto russo que chamava a atenção de um tal de Tamerlan,
naturalizado norte-americano, que havia passado meses em visita a terroristas chechenos – um mês
depois, esse sujeito explodiu bombas na maratona de Boston de 2013.
Diante disso, o Guia PMBOK sugere inúmeras técnicas para identificar riscos em projetos.
Gosto de iniciar por um toró de palpites (brainstorming), para enganar a razão e usar a sagacidade para
perceber o máximo de riscos, até os improváveis e impensáveis. Posso complementar com uma lista
de verificação (check-list). Depois, faço a análise da documentação: um olhar crítico faz perceber
dezenas de riscos. Então, analiso as premissas e restrições: como as premissas são fatores assumidos
como verdadeiros, por detrás de cada premissa há riscos; o mesmo ocorre com restrições. Ainda
completo a lista com a análise SWOT: as fraquezas e ameaças são obviamente riscos do projeto;
contudo, as oportunidades e forças são riscos! Completo a lista com análises de causas-efeitos: como
o risco é uma possibilidade, toda causa de risco é um risco, e todo efeito de risco é também um risco.
A consulta a Estruturas Analíticas de Risco (ver figura) é proveitosa. A norma ainda sugere a
entrevista com interessados (ou oficina de riscos), que permite não só identificar o que não
percebemos, baseado nas suas expertises, como também permite aferir a sua tolerância a diferentes
riscos, o que evitará crises. Resultado: de 150 a 300 riscos são identificados, mesclando riscos positivos
(oportunidades) e riscos negativos (ameaças). São exemplos de riscos em um projeto – adapto os
sugeridos por Wideman (1992):
Ameaças externas imprevisíveis:
desastres da natureza, condições climáticas, força maior, sabotagem e terrorismo;
riscos legais e regulatórios (mudança de legislação, normas e regulamentos);
eventos indiretos causados pelo projeto (desastres ambiental, técnico e social) e
interrupção do projeto por fatores externos.
Riscos externos previsíveis:
mercado (flutuações de demanda e oferta, competitividade, orientação do
consumidor);
ameaça de insolvência e inadimplência de parceiros, fornecedores e
subcontratados;
riscos operacionais (depois de concluído o projeto).

62
 Riscos internos, não técnicos:
organizacionais (cultura organizacional, modelo de gestão, competição entre
projetos e por recursos, financiamento, prioridades);
gestão (mudanças sem controle, alterações em metas, planejamento falho,
decisões, conflitos, alterações da equipe) e
execução (logística, acidentes, desastres, falhas na execução).
Riscos técnicos (geralmente controláveis):
mudanças tecnológicas, inovação;
concepção do projeto (erros em requisitos, engenharia, especificação);
qualidade insuficiente;
riscos específicos da tecnologia adotada e
problemas de desempenho técnico, confiabilidade.

A análise qualitativa de riscos visa a selecionar os riscos mais severos. A severidade deriva da
maior probabilidade e impacto (positivo ou negativo) de um risco. Por ser qualitativa, é preciso
reduzir a subjetividade.
Recomendo que um grupo de até 10 pessoas faça essa análise, expurgando avaliações anômalas.
Transformo o conceito de “alto”, “moderado” e “baixo” em números, e escolho a moda (número mais
frequente) das avaliações, tanto de probabilidades de ocorrência quanto de impactos.

63
 A técnica FMEA, muito usada por especialistas em qualidade, avalia um terceiro fator: a
dificuldade relativa de detecção. Multiplicando a avaliação de probabilidade, impacto e detecção,
temos uma medida da severidade. Para escolher os riscos mais severos de uma lista em ordem
decrescente de severidade, há três métodos:
1. Pareto ou regra 80/20 – escolha 20% dos riscos com maior severidade, que em geral eles
somam 80% do total.
2. Curva ABC – escolha os riscos que totalizam 70% do somatório das severidades, eles são a
curva A.
3. Regra de Sabbag – varra a lista de cima a baixo e pare quando julgar que os riscos mais
severos acabaram.

Inventei essa terceira regra por uma simples razão: se a análise qualitativa é subjetiva, não faz
sentido usar a matemática para a seleção de riscos. Mesmo quando ocorra muita subjetividade nas
avaliações de probabilidades e impactos, como a avaliação é relativa, a lista em ordem decrescente é
quase confiável – o nosso escrutínio seleciona os mais severos.
Na lista de riscos identificados, não sei discernir o que é risco mensurável e o que é incerteza.
Lembre que todo projeto é único, portanto, não temos histórico em que nos basear para fazer
análises estatísticas. Por isso, poucos riscos permitem fazer uma análise quantitativa: riscos de
prazos, de custos e de retorno do investimento são os principais. Veja em artigo específico como
proceder nesses casos, fazendo uma simulação de Monte Carlo.
O Guia PMBOK recomenda: riscos severos merecem respostas específicas para cada um
deles. As respostas podem ser de prévias (antes de o risco eclodir), o que chamamos de Planos A,
ou contingenciais (depois da eclosão do risco), que chamamos de Planos B. Essa é a “abordagem
proativa e consistente”: raramente eliminamos riscos, portanto, por mais que as minhas respostas o
enfrentem, eles ainda podem ocorrer. Por isso, precisamos de Planos B, C, etc. Se ainda podem
ocorrer, o projeto está “exposto” ao risco.
A norma faz a separação entre os tipos de respostas para ameaças e para oportunidades:
Respostas para AMEAÇAS:
Escalar – para decisões fora do alcance do escopo ou do gerenciador;
Prevenir – resposta que elimina a ameaça;
Transferir – resposta que transfere a responsabilidade a terceiros;
Mitigar – respostas que reduzem a probabilidade ou os impactos da ameaça e
Aceitar – nada fazer significa aceitação passiva; definir Planos Contingenciais
(Planos B) significa aceitação ativa.

64
 Respostas para OPORTUNIDADES:
Escalar – para decisões fora do alcance do escopo ou do gerenciador;
Explorar – dar prioridade e garantir que a oportunidade seja explorada;
Compartilhar – transferir a terceiros para que eles compartilhem benefícios;
Melhorar – respostas para aumentar a probabilidade ou os impactos e;
Aceitar – nada fazer significa aceitação passiva; definir Planos Contingenciais
(Planos B) significa aceitação ativa, criando reservas de contingência para
aproveitar a oportunidade.

O quadro abaixo apresenta um exemplo de avaliação de risco.

Plano B –
Ameaça Probab. Impacto Severid. Plano A – prevenção
contingencial

Contratar apoio
especializado em estimar B1. Rever
demanda. planos visando
a acelerar
Vendas Criar rigoroso controle vendas
mensal de vendas.
do B2.
produto Efetuar análise de valor Renegociar
visando a reduzir gastos com
do
3 7 21 remanescentes. interessados
projeto
abaixo Controlar com rigor fatores B3. Informar a
geradores de problemas quem de
do
com vendas a fim de oportuno
esperado remover obstáculos.
C1.
Ser mais rigoroso na Interromper
decisão sobre retorno do projeto
investimento.

Como se percebe no exemplo acima, se forem adotadas, as medidas de Plano A reduzem

muito a chance de ocorrer o problema e reduzem um pouco o impacto desse risco. O Plano B
explora alguma oportunidade, porque, ao rever planos, torna-se possível enriquecer a campanha de
vendas do produto do projeto. Não faço distinção entre risco negativo e positivo, nem mesmo nas
respostas (muitas delas mitigam impactos negativos enquanto outras maximizam impactos
positivos). Note que há um Plano C extremo, adotado se os planos B não surtirem efeito.
Os Planos A de riscos devem ser compatibilizados com os demais planos que compõem o
Plano de Gerenciamento do Projeto. Por exemplo, algum altera o Plano de Aquisições, outro altera
o Plano de RH e o modelo de gestão, outro altera o Plano de Comunicação, etc. Somente os Planos
A se somam ao escopo do projeto. Uma dica adicional não menos importante: evite divulgar as

65
medidas de Plano B, porque muitos podem aderir diretamente a elas, desprezando o Plano A, ou
então podem alarmar-se com a sua gravidade, sem motivo para tanto.
Depois de validado o plano de respostas a riscos e durante a execução do projeto, os Planos
A, B e C precisam ser implementados. Note-se que qualquer resposta implementada pode criar
outros riscos, denominados riscos secundários. Note que ganhamos compreensão à medida que o
projeto avança, portanto, novos riscos são percebidos.
Para completar, como fazer o controle de riscos? Durante a execução, o Plano de Respostas a
riscos é revisto: riscos ocorridos e respostas são avaliados, novos riscos são incluídos no plano,
inclusive riscos secundários.

Sagacidade é essencial
Se o que mais caracteriza um projeto é a incerteza e os riscos associados, gerir riscos é essencial.
Contudo, isso envolve um perfil de competências muito abrangente. Perspicácia e sensibilidade
para riscos (gut feelings) são indispensáveis para a identificação de riscos. Uma boa dose de
sagacidade e temperança é necessária para a identificação e seleção de riscos. Porém, para responder
a riscos, o gerenciador precisa da razão treinada e de criatividade para as respostas não
convencionais. Novamente, a sensibilidade é importante para avaliar quando certos riscos eclodem
e, sobretudo, quando se transformam em crises. A prontidão para responder a problemas
emergentes (workaround) requer uma atitude atenta, alerta e flexível, sobretudo proativa.

Fontes
CHAPMAN, C. B. Project risk management: processes, techniques, and insights. Chichester: John Wiley, 1997.

KLIEM, R. L. Reducing project risks. Aldershot: Gower House, 1997.

PMI – Project Management Institute. Guia PMBOK: um guia para o conjunto de conhecimentos em gerenciamento
de projetos. 6. ed. Newtown Square: PMI, 2017.

SABBAG, P. Y. Gerenciamento de projetos e empreendedorismo. 2. ed. São Paulo: Saraiva, 2013.

WIDEMAN, R. M. Project and program risk management: a guide to managing project risks and opportunities.
Newtown Square: PMI, 1992.

66
Gestão de Cronograma do Projeto
Pontualidade
Você é pontual na sua vida pessoal e profissional? Admiro quem é pontual sem fazer disso
uma obsessão, porque denota que você é organizado e contável (accountable): cumpre o que
promete. Quem não é pontual, mas deseja ser, tem duas opções: espaça mais os seus compromissos,
chegando muito antes do agendado; ou planeja e gerencia o seu tempo. A primeira opção sacrifica
a eficiência; portanto, admito que o tempo precisa ser gerenciado como qualquer outro recurso.
Nesse caso, ser pontual significa ser mais eficiente porque usa melhor o seu tempo, e ser mais eficaz,
porque cumpre o que planejou.
Outra questão: você usa técnicas sofisticadas para planejar tempos ou usa o computador
apenas para desenhar “barrinhas” de um cronograma? Quero mostrar a arte de gerir cronogramas.
Em outro artigo, verá a técnica de usar softwares para gerir cronogramas.

Sempre falta tempo

Se a ideia do projeto foi bem estudada, levando à decisão de iniciar o projeto, essa
oportunidade traz um efeito: quanto antes o projeto terminar, melhor. Por isso, há tanta ansiedade
para realizar projetos.
Ocorre também outro fenômeno, e este é cínico. Como os atrasos em projetos são usuais,
caso se indague a qualquer interessado qual é a sua expectativa de prazo ou duração do projeto, ele
tende a pedir menos tempo que precisa e reclamar urgência, já assumindo que ocorrerão atrasos.
Porém, ditando esses prazos apertados ao gerenciador do projeto, este tende a aceitar docilmente
uma duração que depois se mostrará inviável.
Nada é grátis: se os prazos são apertados, a qualidade sofre, e os custos excedem. Por essa
razão, costumo discutir o quanto puder antes de coletar expectativas de prazos, e estudo
cuidadosamente qual seria o prazo mais adequado.

Sistema dinâmico para assegurar pontualidade

O Guia PMBOK informa o propósito de gerir cronograma: ele “inclui os processos
necessários para gerenciar o término pontual do projeto”. Note que a definição de qual é o
momento oportuno para realizar o projeto ocorreu antes, quando do estudo de viabilidade da ideia.
Significa que esta área do conhecimento visa a otimizar prazos – eficiência e eficácia.

67
 Otimizar cronogramas implica os sete processos de gestão da figura ao
lado. Em minha opinião, eles poderiam ser apenas três processos: planejar a gestão
de cronograma, desenvolver cronograma e controlar cronograma – os demais
processos são apenas etapas do processo de desenvolver cronograma. Contudo, a
norma alerta que optou por separá-los porque utilizam técnicas distintas – é um
preciosismo; se o objetivo é o término pontual, não há porque separá-los.
Planejar gestão de cronograma é definir critérios para elaborar
cronograma: métodos e ferramentas; nível de exatidão; critérios de atualização
e limites de controle. A questão-chave desse processo é a definição de
ferramenta: qual sistema de gerenciamento de projetos será utilizado, caso não
exista uma política para o tema.
Definir atividades equivale a detalhar a EAP no nível mais baixo dos
pacotes de trabalho. Se esse detalhamento já foi feito quando do planejamento
de escopos, este processo é dispensável. Todos os entregáveis são definidos.
Também os marcos (milestones) obrigatórios ou contratuais são produtos desse processo.
Sequenciar atividades, informando qual atividade precede ou sucede outra. São estudadas as
ligações entre atividades e entregáveis, em todos os níveis da EAP. O método para isso é o diagrama
de precedência.
Estimar durações para cada atividade significa estabelecer com a maior exatidão possível as
durações de cada atividade, em condições normais de trabalho. Quando a duração de uma atividade
é elástica, muda caso a caso, recomenda-se fazer uma “estimativa de três pontos”, calculando a
média ponderada das durações otimista, esperada e pessimista. Se a sequência e as durações foram
determinadas, conhecemos a duração global do projeto, embora nenhuma otimização ou verificação
tenha sido efetuada. A maioria dos gestores não profissionais para aí e se contenta com esse desenho
de cronograma. É um grave erro.
Desenvolver cronograma é o processo mais importante porque ele visa a otimizar e tonar mais
viável o cronograma desenhado. Requer: verificar se cada duração não é otimista ou pessimista;
inserir datas-marco (milestones) não só para os entregáveis como para controle; administrar folgas,
reduzindo sobrecargas pontuais e nivelando os esforços de cada recurso planejado; verificar se o
prazo global é aceitável. Como se vê, se o gerenciador não considerar este processo, o cronograma
produzido tem baixa qualidade – não servirá de guia para os executores; sofrerá revisões constantes;
será difícil de controlar.
Para desenvolver o cronograma é usual utilizar o método do caminho crítico. O nivelamento
de recursos, com análises “e se...” também é útil. Adoto uma regra heurística: não aceito executar um
projeto com mais de 40% de atividades críticas, 50% no extremo. Se estou otimizando um
cronograma, e o grau de criticidade é superior a 50%, adiciono “pulmões” dilatando o prazo de alguns
entregáveis: a duração global cresce, mas a chance de terminar no prazo também aumenta.

68
 Otimizado o cronograma, temos a melhor definição de prazo global para o projeto.
Todavia, é comum que esse prazo global vá além do esperado por interessados e definido como
expectativa no Termo de Abertura do Projeto. O que fazer então? Ainda como ação de
desenvolvimento do cronograma, é preciso efetuar a “compressão” do prazo. Há duas formas de
fazer a compressão do cronograma:
Compressão, que prefiro chamar Esmagamento (crashing), que encurta durações pela
adição de recursos ou ampliação da jornada de trabalho. Permite reduzir à metade a
duração global do projeto, contudo, amplia demasiadamente riscos e custos;
Paralelismo, que prefiro chamar de Execução Acelerada (fast tracking), quando fases e
atividades críticas se superpõem, causando redução da duração global. Como heurística,
não aceito superposição global superior a 50% em fases e atividades. Permite reduzir até
30% da duração global, contudo, amplia os problemas de coordenação e gestão.

Note a arte de produção do cronograma: usa-se a melhor cognição para definir escopos do
projeto; usa-se a melhor técnica para sequenciar atividades, estimar recursos e durações para cada
atividade; se for necessário, efetua-se o esmagamento do cronograma.
Se for possível definir a duração global do projeto sem compressão, essas duas técnicas ficam
reservadas para uso na mitigação de atrasos eventuais durante a execução. Nesse caso, tentamos
primeiro a via rápida o quanto possível, reservando o esmagamento como Plano B para situações
excepcionais. Contudo, se no momento do planejamento do projeto já se define um prazo forçando
uma compressão do cronograma, “queimam-se” todas as possibilidades de recuperar atrasos – e
explodem os riscos.
Sem otimizar o cronograma, não é possível confirmar o planejamento da equipe do projeto.
Somente quando avaliamos o esforço de cada recurso para uma dada sequência de execução e
durações é possível comprovar que a execução naquelas condições é viável. Aqui há uma estreita
relação com o planejamento da equipe do projeto: um depende do outro. Como se vê, planejar
tempos, custos e recursos são processos intrincados, que devem ser feitos ao mesmo tempo, nos
momentos finais do período de planejamento.
Aprovado o planejamento, esse cronograma otimizado passa por aprovação do patrocinador,
cliente e dirigentes, tornando-se um baseline, que prefiro chamar de referência para controle. Cada
vez que a realidade indicar que a execução ocorre em tempos distintos, torna-se necessário controlar
o cronograma.
Controlar o cronograma envolve coletar e tratar informação para atualizar o cronograma no
sistema, informando datas reais de início, término das atividades e os percentuais executados.
Como tudo flui, as coisas não acontecem conforme o planejado. Um general francês afirmou:
“Quando a guerra começa, a primeira vítima são os planos”. Diante dele, Napoleão Bonaparte
afirmou: “Planos não são nada, planejamento é tudo”: ter um plano não é nada porque planos ficam
obsoletos; ter planejamento é tudo porque permite rever os planos. Na mesma linha, Mané

69
Garrincha fustigou o técnico da seleção brasileira de futebol na véspera do jogo contra a União
Soviética, na final da Copa do Mundo de 1962: “Gostei dos planos, seu Feola, mas fiquei com uma
dúvida: o senhor já combinou com os russos?”. Genial, o jogador percebeu que em ambiente de
incerteza e risco os planos são apenas guias, e eles precisam ser revistos durante a execução.
Torna-se necessário rever o cronograma, mas como ele não foi aprovado? Vamos esclarecer:
o que é fixo são os marcos aprovados. Este é o compromisso estabelecido pelo gerenciador do
projeto. A sequência de execução e a alocação dos recursos é assunto de responsabilidade do
gerenciador, e ele só pode recuperar atrasos se atualizar o cronograma e estudar novas otimizações.
Em minha prática de gestão de projetos, gasto duas horas no início de cada semana para
atualizar dinamicamente o cronograma, estudando o que fazer para recuperar atrasos. É
suficiente e efetivo!

Cronograma é um guia, não um dever

Na mentalidade burocrática, não se admite revisar cronogramas, como se não existisse
incerteza. Na mentalidade do “faz de conta” ou “me engana que eu gosto”, são fixados prazos tão
curtos quanto inviáveis, como forma de pressionar o gerenciador e os executores a fornecer sua
maior eficiência.
Se desejamos o profissionalismo em projetos, a definição de cronogramas é um esforço
interativo e de simulação, até que se chegue a um ponto considerado ótimo ou subótimo. Para isso,
precisamos de sistemas sofisticados e de concentração dedicada ao processo. Experimente e verá.
O benefício disso é reduzir os atrasos de execução e conquistar a competência da pontualidade.

Fontes
PMI – Project Management Institute. Guia PMBOK: um guia para o conjunto de conhecimentos em gerenciamento
de projetos. 6. ed. Newtown Square: PMI, 2017.

SABBAG, P. Y. Gerenciamento de projetos e empreendedorismo. 2. ed. São Paulo: Saraiva, 2013.

Caso plano de gerenciamento do projeto

Iniciando o projeto
Imagine que o projeto foi oficializado. Alguém produziu o documento Termo de Abertura do
Projeto que foi aprovado pelos principais interessados (stakeholders), no caso, os acionistas do negócio a
ser criado pelo Projeto Sarau. Esse documento resume as “condições de contorno” ou fronteiras do
projeto e serve de guia para quem irá planejá-lo. Se durante o planejamento, algo mudar, será preciso
aprovar esse planejamento com os mesmos que aprovaram o Termo de Abertura.

70
Planejar é otimizar e antever problemas
O Plano de Gestão do Projeto é um documento detalhado, que usualmente consome um mês de
esforço de uma equipe com cerca de seis membros. Usando como base a norma do PMI, esse
documento contém pelo menos nove planos: interessados, comunicação, riscos, qualidade, aquisições,
recursos humanos, escopos, tempos e custos. Cada plano afeta os demais, portanto, não há uma ordem fixa
a ser seguida pelos planejadores. Além dos nove planos, costumo inserir no início desse documento um
Sumário Executivo no mesmo padrão do Termo de Abertura, para que a comparação entre eles revele
se há incongruências que motivariam solicitar nova aprovação do Plano.

Plano de Gestão do Projeto SARAU

Sumário Executivo

Descrição: a oportunidade de criar um serviço digital levou um grupo de

investidores a criar o Projeto Sarau. Trata-se de oferecer ao mercado brasileiro
a possibilidade de participar de comunidades voltadas à arte. Pesquisas
revelam reduzido uso de equipamentos culturais, à exceção da TV e do cinema.
Por que Também revelam reduzido nível de leitura. A formação de comunidades e a
comodidade oferecida pela web podem alterar essa situação.

Antecedente: os acionistas lançaram em 2012 serviço digital, experiência que

servirá de base para o Projeto Sarau.

Acionistas: Paulo Leme, Mario Silva, Ernesto Lima

Patrocinador do projeto: Paulo Leme

Quem
Gerenciador do Projeto: Rui Flecha (subcontratado: empresa Projectil)

Equipe do projeto: serão recrutados dois analistas sênior

Início: mar. 2018

Quando Lançamento do site: jan. 2019

Término do projeto: maio 2019

Abrangência nacional para produtos digitais

Onde Abrange as cidades de São Paulo, Rio de Janeiro, Brasília e Curitiba para eventos
presenciais.

71
 Objetivos:

Desenvolver modelo de negócio e o site até 30.07.2018.

Cadastrar produtos artísticos até 30.09.2018.

Lançar o serviço até 16.11.2018.

Resultados:

Conquistar 1.500 clientes três meses após o lançamento; 7.000 no

O que primeiro semestre; 12.000 no segundo semestre.

Atingir ponto de equilíbrio financeiro até 30.02.2020.

Retorno do investimento no horizonte de cinco anos: 35% ao ano.

Benefícios:

imagem – um artigo positivo sobre o serviço no primeiro ano de operação;

sustentabilidade a partir do segundo ano de operação;

geração de valor para acionista;

Premissas:
Há mercado – classes A e B do Brasil, em particular das cidades de São
Paulo, Rio de Janeiro, Brasília e Curitiba.
Recuperação da economia brasileira ocorre durante 2018.
Produtos culturais aceitam divulgação e condições especiais.
Assume-se como modelo de gestão do projeto o PMI.
Assume-se a confecção de site responsivo – acessado por notebook, tablet
ou celular.
Como O negócio requer organização enxuta, evitando a verticalização da
operação.
A equipe do projeto é formada pelo pessoal que depois ocupará posições
do organograma da empresa, visando a reduzir a curva de aprendizado.

Restrições:
legislação brasileira;
Código de Ética e Conduta do PMI, enquanto não for definido o da nova
empresa.

72
 Escopo do produto:

modelo de negócio – assinatura mensal; uma quinzena de degustação

para cadastrados;
conteúdo do site – home; agenda; blog; entrar;
produtos culturais – artes plásticas, foto, cinema, teatro, shows,
exposições, museus, livros, periódicos e músicas, quase todos em meio
digital ou presencial nas cidades consideradas;

Escopo do projeto:
Como gestão – planejamento e controle, comunicação, aquisições, finanças,
recursos humanos, apoio jurídico;
desenvolvimento da marca;
registro da empresa e contratação de contador;
desenvolvimento do modelo de negócio;
coleta de requisitos para desenvolvimento do site;
desenvolvimento e testes do site;
definição de parcerias culturais;
coleta de produtos a disponibilizar no site;
planejamento de marketing digital;
campanha de lançamento do serviço;

R$ 750.000,00 (estimativa paramétrica – foi somada margem de

Quanto
contingências de 15%)

Esse sumário foi comparado ao Termo de Abertura aprovado pelos acionistas, determinando
nova aprovação deste plano devido a diferenças substanciais.

73
Plano de gestão de interessados
Este plano apresenta as estratégias para engajamento dos principais interessados (stakeholders)
do projeto. Essas estratégias dirigem a elaboração do Plano de Comunicação. No anexo, costumo
adicionar um quadro registrando o Registro de Interessados que contém: nome, posição, função
no projeto e meios de contato.

Interessado Estratégia

1. Convidar para Reunião de Lançamento do Projeto e para evento de

Lançamento do serviço.
Acionistas
2. Sugerir ao patrocinador que defina como atender às suas necessidades e
expectativas.

1. Mantê-lo informado sobre conquistas e incidentes que podem envolvê-lo.

2. Convidar para a fala de abertura da Reunião de Lançamento do Projeto e
Patrocinador Lançamento do Serviço.
3. Definir papéis e responsabilidades com ele e atender aos seus requisitos
de comunicação.

1. Patrocinador oferece apoio em momentos críticos e para legitimar a sua

atuação.
Equipe do 2. Gerenciador do Projeto adota melhores práticas para team building,
Projeto oferecendo oportunidades de reconhecimento e visibilidade.
3. Estudar com patrocinador o oferecimento de bônus por desempenho no
fim do projeto.

1. Exigir e aprovar Plano de Gestão do Projeto, usando o cronograma para

controle.
2. Definir pontos de controle no cronograma associados a eventos de
Sistemista
pagamento.
3. Inserir no contrato cláusulas de prêmio e multa e de confidencialidade.
4. Assegurar obrigações de manutenção e garantia após testes do sistema.

1. Criar Proposição de Valor para obter neles a percepção de relação custo-

benefício favorável.
Assinantes
2. Estimular contato, sempre responder, sobretudo, a mensagens negativas.
3. Criar plano de retenção a ser oferecido após o lançamento do serviço.

Esse plano poderá ser revisado caso se perceba a existência de tensões e conflitos entre
interessados, bem como se forem notadas defasagens no engajamento de interessados.

74
 Plano de gestão da comunicação
Este plano contém todos os veículos planejados para informar e para comunicar interessados
durante a execução do projeto. Inclui também as rotinas para a tomada de decisão no projeto e as
iniciativas educacionais. Usualmente, na forma de quadro, para permitir a visão sistêmica da
comunicação.
Este plano deriva do Plano de Interessados e dos objetivos de comunicação definidos:
Comunicação atende a necessidades e expectativas dos interessados, portanto, é aprovada
por eles.
Comunicação visa a: alinhar informação sobre a execução; criar atmosfera favorável para
a execução harmônica; ampliar a eficiência e eficácia da execução do projeto.
Comunicação deve ser distribuída ao longo do ciclo de vida do projeto e deve ser reforçada
caso existam conflitos, crises e resistência a mudanças por parte dos afetados.

Mídia Público-alvo Periodicidade Conteúdo Forma Responsável

1. quem somos duração: 40’

reunião de Paulo, Mario,
dia 6 2. TAP local: sede Paulo
lançamento Ernesto, Rui
3. esclarecimentos café e ata

1. equipe do
projeto
Paulo, Mario, duração: 70’
reunião 2. plano do projeto
Ernesto, Rui dia 36 local: sede Rui
kickoff 3. matriz de
e convidados café e ata
responsabilidade
4. dúvidas

1. situação atual
bimestral a Rui, com
reunião com 2. decisões duração: 30’
Paulo e Rui partir de apoio da
patrocinador urgentes local: sede
mar.18 equipe
3. próximos passos

Equipe do mensal a 1. situação atual duração: 90’ analista1,

reunião de
Projeto e partir de 2. ações corretivas local: sede com apoio
controle
convidados mar.18 3. pendências ata digital de Rui

75
 Mídia Público-alvo Periodicidade Conteúdo Forma Responsável

duração: 8h
1. a empresa
local: sede contratado,
treinamento 2. valor para o
com apoio
de Funcionários out.18 cliente café de equipe do
funcionários 3. operações
material projeto
4. casos e soluções
didático

1. a empresa duração: 10d

road-show Rui e analista2,
out. 18, a 2. valor para o
com interessados local: TBD com apoio
definir cliente
interessados a definir de Rui
3. degustação logística

1. providências Duração: 20d

Equipe do 15 a
war room imediatas Rui
projeto 30.10.2018 Local: sede
2. próximos passos

Duração: 60’
Paulo, Mario, 1. o serviço Rui, com
evento de
Ernesto, Rui e 30.11.2018 2. fale conosco Local: TBD apoio de
lançamento
convidados 3. degustação Paulo
café e brindes

1. termo de
abertura
2. planos digital,
dossiê do 3. contratos registrado na
Paulo e Rui 31.03.2019 analista1
projeto 4. documentos base de
5. relatórios conhecimentos
6. lições
aprendidas

Esse plano será revisto na metade do prazo do projeto, a menos que solicitado pelo
patrocinador ou ocorrendo conflitos com interessados. Na ocorrência de crise, esse plano será
desdobrado em um plano emergencial, sem perder a validade deste plano.

76
Plano de gestão de riscos
Para o PMBOK Guide, os riscos incluem ameaças e oportunidades. Ambos podem ter
impactos positivos ou negativos para o projeto. Foi efetuada a identificação de riscos, com o uso
das técnicas: toró de palpites, análise da documentação, causa-efeitos, entrevistas com interessados
e Análise SWOT. Foram identificados 86 riscos, classificados pela severidade, isto é, pelo produto
da probabilidade de ocorrência pelo impacto, que usualmente é mostrado no anexo. Foram
selecionados os 18 riscos cuja severidade acumulada representa 70% do total de severidade, conceito
extraído da “Curva ABC”. Para cada risco severo foram criados planos A de prevenção e planos B
de contingência. Extrato do Plano de Respostas a Riscos:

Risco severo Planos A – prevenção Planos B e C – contingência

B1. Suspender a execução

1. Estudar três cenários para até que o assunto seja
atestar viabilidade. discutido com o
Premissas do
2. Considerar taxa de juros de patrocinador.
estudo de
18% ao ano. B2. Rever planos e projetar
viabilidade não se
3. Monitorar cuidadosamente tendências.
confirmam.
custos e prazos para evitar C. Suspender projeto e
estouros. informar aos principais
interessados.

1. Criar sistema de controle de

Alteração de escopo mudanças de escopo. B1. Rever estudo de
ameaça a 2. Ampliar margem de viabilidade na nova
viabilidade do contingências do orçamento. configuração.
projeto. 3. Definir com patrocinador um
teto para os gastos.

1. Investir o máximo possível em

ações mercadológicas. B1. Divulgar a interessados,
Sucesso maior que reconhecendo esforços da
2. Monitorar cuidadosamente a
o esperado no equipe do projeto.
operação inicial, por seis meses.
primeiro semestre
3. Corrigir prontamente B2. Estudar antecipação de
de operação.
reclamações de clientes, ação de expansão.
visando à sua retenção.

Os Planos A de riscos severos são somados ao escopo do projeto e repercutem em custos,

prazos, qualidade, aquisições e recursos humanos. Os Planos B e C são tratados à parte, já que serão
adotados só no caso da ocorrência do risco. Mensalmente, esse plano será refeito, tendo por meta
adicionar 10% dos riscos existentes no Registro de Riscos (em anexo) para rever a classificação de
riscos mais severos e emitir nova versão do Plano de Gestão de Riscos.

77
Plano de gestão da qualidade
Planejar a qualidade do projeto envolve criar métricas para os fatores que envolvem a
aprovação do projeto e que, portanto, determinam a satisfação dos interessados. O PMBOK Guide
menciona métricas de qualidade do produto e qualidade do projeto. Diante da relevância da
satisfação de interessados – que, para mim, é a principal medida de sucesso do projeto –, costumo
adicionar a qualidade percebida, como mostra o quadro a seguir:

Dimensão Requisito Indicador Métrica

80% de “ótimo” e
pesquisa de satisfação do “bom” na média das
usuário (anexo), medida avaliações
1. satisfação do cliente
180 dias após lançamento
2. satisfação do mínimo de 80
qualidade
acionista avaliação a 90, 180 e no pontos em escala
percebida
3. satisfação da lançamento de 0 a 100
equipe do projeto
avaliação a 90, 180 e no mínimo de 80
lançamento pontos em escala
de 0 a 100

índice de falha em
decisões
inferior a 20%
4. eficácia do índice de cumprimento
qualidade superior a 80%
planejamento dos planos
do projeto inferior a 200h
5. valor agregado índice de horas extras não
planejadas IDP e IDC > 1

IDP e IDC mensais

mínimo de 70%
evolução da carteira de
6. adesão do mercado
clientes após lançamento mínimo 93%
qualidade 7. desempenho
do financeiro evolução do faturamento resultado líquido
produto 8. retorno do mensal após lançamento superior a
investimento
evolução mensal do DRE R$ 300.000 a partir
do 6º mês

Oportunamente, serão definidas métricas para a organização a ser criada, permitindo operar
sobre todos os contratados definindo Acordos de Nível de Serviço (ANS) para assegurar a qualidade
do produto, no que tange à contribuição de cada contratado.

78
 Plano de gestão de aquisições
Uma premissa agora adotada é a de que o negócio requer organização enxuta, evitando a
verticalização da operação. O quadro abaixo evidencia os quatro principais contratos.

Parcela do Tipo de Tipo de Tipo de Tipo de Valor

Prazos
escopo contratado seleção contrato julgamento estimado

Formalizar: 2
escritório de preço melhor meses.
legal convite R$ 20.000
advocacia global preço Executar: 3
meses.

preço Formalizar: 2
desenvolved global meses.
tomada técnica e
tecnologia or de com R$ 80.000
de preços preço Executar: 5
sistema prêmio e
multa meses.

Formalizar: 2
preços meses.
agência melhor
marca convite unitários R$ 60.000
publicidade preço Executar 4
com teto
meses.

Formalizar: 3
agência de meses.
preços melhor
marketing marketing convite R$ 200.000
unitários preço Executar: 4
digital
anos.

O escopo detalhado de cada pacote de contratação será deduzido a partir do Plano de Gestão
do Escopo. Os requisitos para a contratação de cada pacote serão definidos oportunamente pela
equipe do projeto. Será feita avaliação de mercado visando a operacionalizar a seleção dos
convidados e cadastrados. Serão definidas minutas de contrato, a serem disponibilizadas aos
licitantes para que preparem as suas propostas. Além dos investimentos em contratações, não se
podem desprezar os investimentos em infraestrutura, publicidade e serviços de contabilidade.

79
Plano de gestão de recursos humanos
Outra premissa adicionada é a de que a equipe do projeto será formada pelo pessoal que
futuramente ocupará posições do organograma da empresa, visando a reduzir a curva de
aprendizagem. No primeiro ano, o CEO terá quatro funcionários: eles serão recrutados em 60 dias,
para compor a equipe do projeto. Depois de recrutados, terão dedicação exclusiva ao projeto. A
data-marco da sua mobilização também pode ser observada no cronograma. O quadro a seguir
indica papéis e responsabilidades deles.

Envolvido no
Papéis e responsabilidades
projeto

Contribuir para a Iniciação do Projeto, conferindo legitimidade aos

designados para gerenciar a sua execução; ser consultado em
patrocinador do decisões atípicas e em situações de crise, eventualmente decidindo
projeto sobre mudanças em objetivos do projeto; contribuir para a
transferência harmônica do produto do projeto, visando ao seu
encerramento.

Liderar os envolvidos, zelando para atender às suas necessidades e

expectativas; dedicar esforço para atingir os objetivos do projeto;
gerenciador do concentrar e comunicar informação sobre a execução do projeto,
projeto inclusive de mudanças nos planos; incentivar a formação e
desenvolvimento da equipe do projeto; promover cooperação e
sinergia na organização e em sua relação com o projeto.

No geral, assegurar dedicação ao projeto no nível planejado e aceito

membro da equipe na sua área de origem; contribuir de forma cooperativa para a
do projeto equipe do projeto; ser contável pelas atividades e entregáveis sob a
sua responsabilidade; atuar e promover ética.

Detalhar planejamento de marketing e políticas comerciais;

analista sênior
contribuir para a elaboração do site; cadastrar produtores culturais;
marketing
estabelecer parcerias culturais.

analista sênior Detalhar políticas financeiras; estudar preços; responde pelo

finanças controle de custos do projeto e por avaliações econômicas.

Definir políticas de comunicação, de privacidade, de relacionamento

analista pleno
institucional; definir plano de comunicação institucional da empresa;
comunicação
alimentar o site com conteúdos.

Definir plano diretor de tecnologia de informação; definir política de

analista pleno segurança; definir requisitos de hardware e software; zelar pela
tecnologia experiência do usuário dos sistemas; gerenciar melhoria contínua
dos sistemas legados.

80
 Oportunamente, será produzida a Matriz de Responsabilidades, baseada no cronograma
detalhado do projeto, repartindo de modo específico as responsabilidades em cada atividade do
escopo. Durante a execução, o Gerenciador do Projeto responde pela gestão da equipe e aplicação
das melhores práticas de gestão de pessoas.

Plano de gestão de escopos

Foram coletados os Requisitos do Projeto com os principais interessados como mostra o quadro
a seguir. Os requisitos abaixo foram classificados em E = Essencial; I = Importante; A = Acessório.

NEGÓCIO

Será contratado especialista para a definição de marca e o seu

marca posicionamento. O contrato incluirá no escopo a definição de EE
nomes, logo e papelaria.

Os clientes de cidades onde ocorrem eventos presenciais têm

cliente acesso a diferentes partes do site. Há estímulo para contato e II
compartilhamento de informação.

Promoções são ativadas quando chega ao final o período de

cliente AA
assinatura, visando à retenção de clientes.

SISTEMA

Site responsivo, podendo ser acessado por notebook, tablet ou

arquitetura EE
celular.

Contém:
1. eventos e objetos culturais;
2. comando de busca;
3. publicidade;
site EE
4. testemunhos;
5. agenda de eventos;
6. assinatura e
7. fale conosco.

1. cadastro e gestão de assinantes (bloqueio, edição, exclusão,

cupons de desconto);
Admin –
2. cadastro e gestão de conteúdos;
administrador EE
3. cadastro e gestão de clientes;
do site
4. editor de textos da home e
5. upload de textos, banners (publicidade) e posts (blog).

81
 NEGÓCIO

base MySQL – Linux

desenvolvimento E
linguagem Php 5

Criar Manual ou roadmap de operação no Admin; incluir

desenvolvimento treinamento da equipe Sarau; inclui fornecimento de códigos-fonte E
– fazer contrato de manutenção periódica.

O escopo detalhado do projeto é apresentado na primeira coluna do cronograma. Não

pertence ao escopo do projeto:
obter financiamento e gerir a definição/alteração de acionistas;
gerir investimentos durante o projeto e depois do lançamento do serviço e
a atração e contratação de pessoal.

Para organizar o escopo do projeto, foi produzida a seguinte Estrutura Analítica do Projeto (EAP):

Para favorecer a gestão do projeto, os principais entregáveis são:

contrato social registrado;
manual da marca;
site responsivo homologado;
base de dados de produtos culturais;
contratos e
plano de gestão do projeto.

82
 Todas as solicitações de mudança de escopo serão encaminhadas ao gerenciador do
projeto, que decidirá se pode ser aprovada imediatamente e por quem, ou se necessitará de
estudos antes da aprovação. Um registro de solicitações para monitoramento está disponível
com o Gerenciador do Projeto.

Plano de gestão de custos

A estimativa de custos adotou a técnica paramétrica resultando em:
Gestão: equipe quatro pessoas: 6.000h * R$ 50 = R$ 300.000
Desenvolvimento da marca: R$ 25.000
Registro da empresa e contratação de contador: R$ 5.000
Desenvolvimento do modelo de negócio – consultoria: R$ 10.000
Coleta de requisitos para desenvolvimento do site: R$ 3.000
Desenvolvimento e testes do site: 57.000
Definição de parcerias culturais: R$ 20.000
Coleta de produtos a disponibilizar no site: R$ 30.000
Planejamento de marketing digital: R$ 20.000
Campanha de lançamento do serviço: R$ 167.000
TOTAL: 637.000 + margem 15% = R$ 750.000

Plano de gestão de cronograma

As principais datas-marco do projeto são:
Início: mar. 2018
Lançamento do site: jan. 2019
Término do projeto: maio 2019

Para readequar-se à realidade, o cronograma será revisado a cada 15 dias. Contudo, caso
datas-marco oficiais venham a ser alteradas na revisão do cronograma, isso exigirá que o plano de
projeto seja revisado e novamente aprovado.

83
 Como elas alteram o que foi aprovado no Termo de Abertura, torna-se necessária nova
aprovação deste plano. O cronograma resumido do projeto é apresentado na figura abaixo:

Plano de promoção de ética

Como será criada uma empresa para fornecer o produto do projeto, julgou-se oportuno
delinear regras éticas, que serão o embrião do código de ética da organização. Inclui:
1. Respeito – atendemos a todos sem preconceito, e os tratamos como pessoas dignas de
respeito, em todas as circunstâncias.
2. Transparência – permitimos ao cliente acompanhar o serviço oferecido. Em caso de
problemas com as recomendações oferecidas no site, essas serão imediatamente removidas
até que se estude o problema.
3. Responsabilidade – não assumimos mais clientes que a capacidade momentânea da
empresa. Não pactuamos prazos inviáveis.
4. Justiça – asseguramos a todos o direito de reclamar, oferecendo resposta em prazo oportuno.
5. Garantia – daremos resposta formal a toda e qualquer reclamação dirigida à empresa.
6. Competência – não recomendamos ou publicamos nada em condições em que não seja
possível obter resultado de qualidade.
7. Honestidade – não fazemos propaganda enganosa. Sempre agimos de boa-fé.

84
 8. Conflito de interesses – não subcontratamos serviços, nem divulgamos ou protegemos
quaisquer produtos culturais cujos responsáveis tenham ou pareçam ter qualquer vínculo
com a empresa e os seus funcionários.
9. Relacionamento comercial – não prestamos serviços a clientes ou divulgamos produtos
de origem duvidosa.
10. Sustentabilidade – adotamos todas as políticas necessárias à proteção do meio ambiente,
da saúde e da segurança do pessoal e da clientela.

Anexos
Registro de interessados
Lista de riscos – avaliação qualitativa
Questionários de satisfação

Referência para controle

Não basta ter um Termo de Abertura do Projeto aprovado, indicando as fronteiras do projeto.
Para o sucesso da execução, é preciso planejar a execução. Este caso explora o Plano de Gestão do
Projeto, incluindo um plano não mencionado na norma do PMI: o Plano de Promoção de Ética.
Comparando o Sumário Executivo deste plano com o conteúdo do Termo de Abertura do
Projeto, nota-se que há mudanças. Desse modo, este plano também precisa ser aprovado pelos
mesmos interessados que aprovaram o Termo de Abertura do Projeto, para que eles indiquem
aceitação dessas mudanças. Depois disso, ele se torna referência para controle (baseline) e pode ser
divulgado a todos os envolvidos na execução do projeto.

85
MÓDULO IV – MONITORAMENTO,
CONTROLE E ENCERRAMENTO

Neste módulo há dois temas principais. O primeiro é o monitoramento, controle e aceite de

projetos, em que os indicadores de desempenho, que serão produzidos, ampliam a chance de
corrigir desvios do executado em relação ao planejado. O segundo tema é o código de ética e
conduta do Project Management Institute (PMI), que nos ajuda a perceber como a vida se torna
mais fácil e as relações mais duradouras quando se cultiva a ética.
Ao final, esperamos que você seja capaz de:
desenvolver a capacidade de criar indicadores de controle de execução de projetos;
compreender que o encerramento de projetos não é um momento, é uma fase de
transferência de responsabilidades;
compreender a diferença entre moral e ética, relacionando a ética com valores pessoais,
refletindo sobre a diferença entre normas éticas e de conduta.

Controle e aceite do projeto

Planejar mais controlar
Quem gosta de planejar, costuma negligenciar o controle. Eu adoto um lema: planejamento
sem controle é alucinação; controle sem planejamento é sobrecarga de trabalho. Um sempre
acompanha o outro; por isso, há décadas, usamos o termo “planejamento & controle”. O ápice do
controle se dá no momento de avaliar o projeto para fins de aceitar e encerrar o projeto.
Monitorar não é controlar
O PMBOK Guide faz uma interessante distinção entre monitorar e controlar. Monitorar é
coletar e processar informação para produzir relatórios; controlar é tomar decisões corretivas,
visando a adequar a realidade da execução. Apenas monitorar deixa a todos passivos; controlar
envolve proatividade.
Muitas organizações se esmeram em sistemas de informação que visam, a princípio, a
monitorar informação, deixando de lado o propósito básico desses sistemas por quem os solicitou:
controlar algo. Os meios foram colocados à frente dos fins.
Curiosamente, também ocorre o oposto: há organizações que falham em monitorar, mas são
forçadas a tomar decisões de controle. Controlar sem monitorar é tomar decisões erráticas: variam
a cada momento segundo o “humor” ou atenção despendida pelo decisor. Você já viu isso: cada
problema detectado na execução do projeto é escalado para o patrocinador ou a algum diretor que
milagrosamente decide o que fazer. Controlar sem monitorar é negar proatividade ao
gerenciamento do projeto.
Diante disso, o PMI prega o controle baseado em monitoramento. Deixe de lado a
especulação, monitore fatos e evidências, processe essas informações de boa qualidade e use-as para
recomendar a tomada de decisão, sobretudo quando ela ultrapassa a sua alçada como gerenciador
do projeto.

Monitorar e controlar para aceitar o projeto

Ao processar a informação coletada durante a execução do projeto, para que ela sirva para o
controle, é preciso que ela seja sintetizada. Fazemos isso criando o que os norte-americanos chamam
de Key Performance Indicators (KPI), ou seja, os indicadores-chave para o controle do desempenho
da execução do projeto.
É pouco usual para os brasileiros usarem indicadores de desempenho para controle. Por isso,
tomo o cuidado de criar indicadores de eficiência, eficácia e efetividade – em pequeno número,
apenas o suficiente para compreender os desvios de planejamento e tomar decisões corretivas.
Eficiência envolve questões de economia e produtividade: é fazer mais por menos; menos
tempo, menos esforços e custos, menos retrabalhos devido à qualidade. Eficácia significa cumprir
objetivos: atender aos requisitos, cumprir datas-marco, atingir desempenho e resultados esperados –
tem a ver com os objetivos do projeto. Efetividade envolve o propósito do projeto, nem sempre
discernível entre os objetivos – tem a ver com os benefícios trazidos pelo projeto.
Em 1954, Peter Drucker indicava que os gerentes convencionais de hierarquias buscavam
eficiência e agiam by the book para não errarem, enquanto os “gerentes do futuro” enfatizariam a
eficácia – popularizou a frase: ao invés de fazer certo as coisas (eficiência), precisava fazer a coisa
certa (eficácia). Antes de morrer, esse guru revisou essas ideias, dando relevo não à eficiência nem à
eficácia, mas à efetividade, voltada a cumprir os propósitos e finalidades. Não podemos desprezar

88
nenhum dos fatores, por isso um dirigente de banco alardeava: “Para conquistar o certo, é preciso
fazer o certo, do jeito certo”.
Controlar é decidir para assegurar governabilidade. Decidir sobre cada área do
conhecimento envolvida na gestão. Controlar escopos significa decidir sobre mudanças. Controlar a
qualidade é decidir sobre aceitar os entregáveis e exigir retrabalho sempre que o nível de qualidade
planejada não é atingido. Controlar custos e tempos é verificar, a cada momento, se a execução do
projeto agrega valor – gestão pelo valor agregado (earned value) fazendo mais por menos, isto é,
realizando o projeto melhor que o planejado. Gerir a comunicação é tomar ações corretivas para
preservar o bom relacionamento e alinhamento de todos. A ela se soma o controle dos interessados,
que visa a decidir como sustentar o engajamento de todos. Controlar riscos é acionar os Planos B
(contingenciais) e praticar o workaround: prontas respostas para problemas emergentes visando a
ampliar a chance de sucesso do projeto. Controlar aquisições e o trabalho visa a, sobretudo, assegurar
eficiência e competência dos envolvidos na execução. Para concluir, controlar a integração nada mais
é que rever o Plano do Projeto e a sua liderança sempre que necessário.
O ápice do controle ocorre no momento de avaliar e aceitar os entregáveis, produtos e
resultados do Projeto. Muitas vezes isso envolve realizar testes, homologar e avaliar resultados. Esses
processos fazem parte do grupo de processos de encerramento do projeto.
Encerrar o projeto envolve obter a aceitação provisória e depois a aceitação definitiva. Isso
está definido no Código Civil Brasileiro, quando trata da entrega futura de qualquer bem ou serviço.
A aceitação provisória significa apontar não conformidades no produto ou entregável. Supõe-se que
é necessário um tempo para que essas conformidades sejam eliminadas, por isso vem depois a
aceitação definitiva.
Obtida a aceitação provisória, é uma decisão do cliente do projeto se ele aceita que as
responsabilidades sejam transferidas a ele ou se aguardará a aceitação definitiva – é questão de
conveniência, o direito está assegurado desde que apontadas as não conformidades. Contudo, venho
observando um problema nas corporações brasileiras: definida a aceitação provisória de um novo
software, decide-se colocá-lo em “produção” ou operação; mas para isso é exigida a homologação,
por questões de auditoria. Parece insanidade, mas o que se pratica é fornecer uma “homologação
provisória”, seja lá o que isso significa.
Encerrar o projeto também inclui avaliar resultados do projeto, completar o dossiê com a
documentação do projeto, coletar as lições aprendidas e desmobilizar a equipe do projeto (handover)
assim que as responsabilidades foram totalmente transferidas a alguém. No caso de haver um cliente
externo, resta uma responsabilidade à organização que hospedou o projeto: efetuar serviços em
garantia – dita a legislação de defesa do consumidor, mas isso não impede de desmobilizar a equipe
do projeto.

89
 Quando há negligência durante a aceitação, a transferência de responsabilidades é dificultada,
a aceitação definitiva não ocorre, e os membros da antiga equipe do projeto continuam a serem
acionados ao mínimo problema, por serem os que mais conhecem os produtos do projeto. Por isso
é tão importante sistematizar e regrar como se dará a aceitação do projeto.
Sobre a avaliação de resultados, há mais uma coisa a transferir: alguns indicadores de
desempenho usados durante o projeto podem continuar a serem usados depois. Como os
gerenciadores costumam ser os que mais entendem de criar indicadores, a equipe do projeto pode
inclusive criar um painel de controle contendo indicadores pós-projeto. Isso permite avaliar
benefícios, por isso é explicitado na norma do PMI para a gestão de programas.
Sobre as lições aprendidas, há que diferenciá-las das “melhores práticas”: as primeiras incluem
aprender com os erros, enquanto as últimas pretendem perenizar os melhores acertos. Prefiro coletar
as lições aprendidas: para mentes preparadas, os erros ensinam mais que os acertos. Para a
efetividade disso, é preciso planejar o que mais ensina, para criar o sistema de coleta, processamento
e registro dessas lições. Considero todos os incidentes ocorridos, os fatores causadores de desvios e
as contingências ocorridas como as melhores fontes.

Revalorizando o controle
Nas hierarquias, ninguém gosta de ser controlado. Controle, nesse caso, significa que o chefe
cuida para que o trabalho seja adequado, quase sempre desempoderando e removendo a liberdade
de funcionários responsáveis atuarem.
Em projetos, controlar é uma função nobre, significa corrigir desvios, colocar o “trem de volta
nos trilhos” do planejamento. Sem controle, qualquer resultado é justificável. Sem controle, não
há gestão. Essa concepção está distante do senso comum sobre o conceito de controle nas
hierarquias. Precisa ser revalorizado.

Caso monitoramento e controle do projeto

Executando o projeto
Durante a execução do projeto, o gerenciador do projeto busca manter a equipe coesa para
executar conforme o planejamento. Aprovado o Plano do Projeto, foram criadas referências para
controle (baseline). Cada sugestão de mudança é confrontada com o baseline. Como existe muita
incerteza e riscos, é natural que ocorram incidentes que podem causar impactos sobre o
planejamento aprovado.

90
Controle baseado em monitoramento
Para o PMI, há uma grande diferença entre monitorar e controlar. Monitorar requer coletar
informação para divulgar aos interessados; equivale a acompanhar a execução; portanto, é de certo modo
passivo. Controlar envolve tomar decisões para corrigir o rumo da execução frente ao planejado.
Há muitas organizações que monitoram a execução, mas não usam essa informação para
controle; em outras, há excelente controle – decisões ágeis e firmes –, porém, na ausência de
monitoramento metódico. Nenhuma dessas opções é adequada: monitorar sem controlar é assistir
passivamente os riscos ocorridos; controlar sem monitorar envolve decisões arbitrárias que podem
levar o projeto a condições muito diferentes das aprovadas no Termo de Abertura. Por essa razão,
o PMI preconiza um controle baseado em monitoramento metódico.
Para evidenciar o monitoramento e controle da execução, o entregável usual é o relatório. São
usados três tipos de relatório, cada qual endereçado a diferentes interessados: status, progresso e
tendências. Status revela apenas a situação presente; Progresso compara a evolução da execução até o
momento atual; Tendências compara a situação presente com a tendência futura.
Este caso demonstra um Relatório de Status endereçado ao comitê executivo; um Relatório
de Progresso endereçado ao setor de controle de investimentos; e um Relatório de Tendências,
endereçado ao patrocinador do projeto. Cada qual em um momento diferente.

Relatório de Status – 30 de junho de 2018

O Projeto SARAU trata da criação de negócio digital dedicado a

informação comunidades com interesse em artes: artes plásticas, foto, cinema, teatro,
geral shows, exposições, museus, livros, periódicos e músicas. Foi iniciado em
março de 2018 e tem o seu término planejado para maio de 2019.

tempo: decorridos 19% do prazo (três meses)

investimento total: R$ 750.000
situação atual escopo: sem mudanças solicitadas
qualidade: satisfação do acionista: 80 pontos (escala de 0 a 100); índice de
cumprimento de planos: 92%; horas-extras não planejadas: 48h

VP – Valor Planejado: R$ 115.000 (sem margem)

CR – Custo Real: R$ 110.000 de R$ 750.000 = 15%
controle de
VA – Valor Agregado (realização física em valores orçados): R$ 70.000
desempenho
IDC = VA/CR = 0,63
IDP = VA/VP = 0,61

1. Follow-up do desenvolvimento do site, causador do atraso.

decisões
2. Antecipar atividades do caminho crítico para recuperar atrasos.
urgentes
3. Rever gastos futuros visando a aprimorar o índice de valor agregado.

91
Relatório de progresso – 30 de setembro de 2018

O Projeto SARAU trata da criação de negócio digital dedicado a

informação comunidades com interesse em artes: artes plásticas, foto, cinema, teatro,
geral shows, exposições, museus, livros, periódicos e músicas. Foi iniciado em
março de 2018 e tem o seu término planejado para maio de 2019.

tempo: decorridos 47% do prazo (sete meses)

investimento total: R$ 750.000

escopo: solicitada mudança no modelo de negócio – em análise

qualidade: satisfação do acionista: 80 pontos (escala de 0 a 100); índice de

cumprimento de planos: 92%; horas-extras não planejadas: 48h

indicadores:
situação
VP – Valor Planejado: R$ 293.000 (sem margem)
atual
CR – Custo Real: R$ 201.000 de R$ 750.000 = 27%

VA – Valor Agregado (realização física em valores orçados): R$ 230.000

IDC = VA/CR = 1,14

IDP = VA/VP = 0,69

Atrasos não foram recuperados, mas a gestão agregou valor em custos à

execução, em relação ao planejado.

controle de aprovados os conteúdos do site

escopo em análise, alteração do modelo de negócio para assinatura semestral

92
 A curva “S” atual é:

controle de
investimento

análise das 1. Falha no desenvolvimento do site: o modelo Wordpress adquirido

ocorrências apresentou dificuldades e foi substituído, causando atraso de 25 dias.

controle da
Não houve alterações na equipe do projeto; todos foram mobilizados conforme
equipe do
os prazos planejados.
projeto

próximos
1. Agilizar definição de parcerias e coleta de produtos culturais – pode haver
passos –
atrasos em relação ao planejado.
curto prazo

93
Relatório de tendências – 30 de dezembro de 2018

O Projeto SARAU trata da criação de negócio digital dedicado a

comunidades com interesse em artes: artes plásticas, foto, cinema,
balanço da teatro, shows, exposições, museus, livros, periódicos e músicas.
situação atual e
consequências Decorridos 10 meses, a equipe do projeto se prepara para o lançamento
do site, previsto para janeiro de 2019. Houve atraso na execução,
forçando a revisão da data final.

mudanças Solicitada a revisão do plano de marketing, redefinindo as personas e a

solicitadas campanha de lançamento. Gerenciador estuda a solicitação.

qualidade: satisfação do acionista: 60 pontos (escala de 0 a 100);

índice de cumprimento de planos: 78%; horas-extras não planejadas: 196h

índice de valor agregado:

VP – Valor Planejado: R$ 370.000 (sem margem)

indicadores
CR – Custo Real: R$ 330.000 de R$ 750.000 = 44%

VA – Valor Agregado (realização física em valores orçados): R$ 318.000

IDC = VA/CR = 0,96

IDP = VA/VP = 0,86

Como o IDP < 1 e não é possível lançar o site em janeiro próximo, o

patrocinador solicitou ao gerenciador do projeto um plano para
recuperar atrasos.
tendências A coleta de produtos ficou abaixo do esperado; o gerenciador sugere
reduzir o número de categorias para focar nos produtos com maior
representatividade. O patrocinador estuda a mudança junto aos
acionistas.
1. Data-marco lançamento do site: de jan./19 para mar./19, postergando
revisão de as datas-marco seguintes.
objetivos 2. Substituição de membro da equipe do projeto visando à maior
afinidade com produtos culturais.

Todo o esforço no curto prazo visa a testar e homologar o site,

adicionando conteúdos e visando à sua nova data de lançamento.

próximos A incerteza da economia brasileira recomenda reestudo do prazo de

passos retorno dos investimentos. Outro risco relevante é representado pelo
lançamento de serviço concorrente no mercado. O gerenciador
monitorará o seu desempenho e possivelmente emitirá revisão do Plano
do Projeto para nova aprovação.

94
Foco é o controle, não a divulgação
Os exemplos acima mostram as diferenças entre relatórios de status, progresso e tendências.
Os conteúdos e a profundidade dos relatórios podem variar. Há relatórios adicionais pré-
formatados no software de gerenciamento de projetos, muito úteis para controlar progresso. A
organização pode usar sistemas de business intelligence para criar painéis de controle digitais
(dashboards), automatizando parte da produção dos relatórios.
Ressalte-se que os relatórios visam ao controle do projeto, isto é, às decisões corretivas e à
eventual solicitação de revisão dos planos existentes. A informação é insumo para a gestão, visando
a ampliar a chance de sucesso do projeto.

Gestão pelo valor agregado (earned value)

Em retrospecto gastamos, e daí?
O controle de custos mais comum no Brasil é retrospectivo: os gastos acumulados até o
momento são apurados, comparando-se com o orçamento definido para o projeto. Usar um
controle retrospectivo de gastos seria metaforicamente equivalente a dirigir um veículo olhando
apenas pelo retrovisor. Sobre o que ocorreu há pouco a fazer, por isso precisamos de um controle
prospectivo, que nos aponte tendências para o futuro.

Não um indicador para análise, mas, sim, uma filosofia de gestão

Nos anos 1960, no setor público, uma questão relevante era saber se os gastos efetuados em
investimentos governamentais eram compatíveis com o avanço da execução dos projetos e programas.
Em 1967, o Departamento de Defesa dos EUA criou um sistema chamado “controle de
custo/cronograma”: qualquer avanço nos custos deveria ser compatível com avanços no cronograma.
Por duas décadas, houve resistência em adotar esse controle. Em 1991, o Secretário de Defesa cancelou
a execução de um projeto do avião A-12 baseado em cálculos de custo e cronograma; anos depois, foi
criada norma técnica, e a análise de valor agregado (earned value analysis) passou a ser obrigatória para
investimentos do governo em defesa, aeronáutica, energia e construção.
O PMI adotou o conceito em 1984, quando criou o PMBOK Guide. Em edições posteriores,
o conceito foi enriquecido: de uma “análise” passou a ser uma filosofia de trabalho, a “Gestão pelo
Valor Agregado – GVA”. A partir do ano 2000, todos os investimentos governamentais dos EUA
passaram a ser controlados pelo GVA, ganhando incentivo com a Lei Sarbanes-Oxley, de 2002.

95
Valor agregado e índices de desempenho
A relação entre tempos e custos acumulados foi popularizada como “Curva S”, utilizada desde
meados do século 20. O formato do gráfico (ver Figura 1) corresponde à letra “S” sugere que, no
início, os gastos demoram a “engrenar”; depois, gasta-se em ritmo acelerado; e, perto do fim,
novamente os gastos desaceleram.

O problema da curva S é que ela não apoia as decisões de controle de gastos, porque não se sabe
se gastos acumulados menores que o previsto se devem a atrasos na execução ou por economia. Falta
uma informação importante: o que foi realmente executado, comparado ao planejado.
Vamos aos conceitos:
Valor Planejado (VP) – em um dado momento, é a parcela do orçamento do projeto
correspondente ao trabalho planejado para ser executado até o momento.
Custo Real (CR) – é o somatório dos custos realizados no projeto até o momento.
Valor Agregado (VA) – é a medida do trabalho realmente realizado, expressa em valores
extraídos do orçamento. O valor máximo de VA corresponde ao Orçamento do Projeto,
ocasião em que todo o escopo foi concluído. Para que seja consistente, é usual considerar
apenas trabalhos concluídos, dada a falta de precisão de percentuais executados.

96
O gráfico abaixo mostra a curva S que a cada momento determina o VP – Valor Planejado. Mostra
também, até o momento (“data dos dados” ou data date, no inglês) a curva do Custo Real (CR) e
a curva S do Valor Agregado (VA). A curva do VP termina com o custo acumulado equivalente ao
Orçamento No Término (ONT). Note que a curva CR projeta para o futuro gastos maiores que
os orçados – Estimativa No Término (ENT) – se nenhuma medida de controle for adotada.
Contudo, a posição da curva do VA ilumina o problema: se ela está abaixo da curva VP, significa
que o avanço da execução é inferior ao planejado, porque VA representa o trabalho realizado, mas
a preços do orçamento, não a custos reais. Como calcular os valores de CR, VP e VA?

CR é o somatório dos gastos realizados. Considera o valor contabilizado.

Costumamos definir o VP por uma simplificação. Se o projeto tem duração de 12 meses,
decorridos três meses, ou seja, 25% do prazo global, assume-se que o VP é de 25% do Orçamento –
é como se a curva S se tornasse curva/retificada. A simplificação é a favor da segurança porque até a
metade da execução nós superestimamos VP e no final dela o subestimamos.
A grande questão é como calcular VA. É preciso criar um critério de medição da execução
física. No passado, a regra era muito apertada: só se consideravam atividades do escopo efetivamente
concluídas, ou seja, era um critério 0-100: ou não foi concluída ou foi concluída. Há variações: eu
prefiro usar o critério 0-50-100: até chegar à metade da execução consideramos 0%, passando da
metade, mas sem concluir a atividade consideramos 50% e somente as efetivamente concluídas
recebem o 100%. Há organizações que definiram um critério ainda mais brando: 0-30-70-100.
Varrendo a lista de itens do orçamento e atribuindo esses percentuais, a soma de tudo define o VA
naquele momento.

97
 Calculados os três valores, vamos à análise para tomar decisões de controle. O Cronograma
exemplificado ao lado mostra a duração de cinco meses – suponha que estamos a 30% dessa
duração. Suponha que o orçamento é $ 1.000 e já foram consumidos $ 500. O que se pode
concluir? Nada: pode ser que gastamos mais que o planejado, o que é ruim, mas pode ser também
que a execução está acelerada, o que seria bom.
Nesse exemplo, VP corresponde a 30% do orçamento, portanto, é $ 300. CR é $ 500, como
foi apurado na contabilidade do projeto. Para calcular VA, vamos usar o critério 0-50-100. A
atividade A foi concluída, representa 100% do custo orçado dela; a atividade B não chegou à
metade, portanto, consideramos 0% do valor orçado; a atividade C está atrasada, consideramos 0%
do orçado; a atividade D não deveria ter iniciado, mas realmente passou da metade da execução,
portanto, consideramos 50% do seu valor orçado. Somando os valores de cada atividade
multiplicados pelos percentuais correspondentes, chegamos ao VA de $ 400.
Para analisar a situação, podemos medir variações de prazo e de custo, ou então medir índices
de prazo ou de custo. Prefiro a segunda opção, cujas fórmulas são:
IDP – Índice de Desempenho de Prazos: IDP = VA/VP
IDC – Índice de Desempenho de Custos: IDC = VA/CR

No exemplo IDP = 400/300 = 1,33. Toda vez que o índice de prazos é superior a 1, significa
que o ritmo de execução é maior que o planejado. Se for inferior a 1, o IDP indica ritmo mais lento
que o planejado. Por sua vez, o IDC = 400/500 = 0,8. Toda vez que IDC é maior que 1 significa
que se gasta proporcionalmente menos que o orçado; se for inferior a 1 significa que se gasta
proporcionalmente mais que o orçado para aquilo que foi efetivamente realizado. Conclusão: o
projeto está acelerado, o que é bom, contudo, gasta-se demais. As decisões de controle poderiam
ser: manter o ritmo acelerado, porém aumentando a eficiência de custos, fazendo esforço para
reduzir os gastos futuros.

98
 No caso de projetos de construção, há gastos com materiais e gastos com pessoal. Os materiais
podem ter sido comprados antecipadamente e estão armazenados prontos para uso. Separando
materiais e mão de obra, poderemos aplicar os critérios para percentuais concluídos.
Sintetizando, a Gestão pelo Valor Agregado (GVA) permite controlar ao mesmo tempo o
ritmo de execução e de gastos. Uma terceira variável pode ser igualmente controlada: o esforço de
recursos. O critério usado para medir a conclusão de atividades cria uma nova mentalidade: concluir
atividades, sem deixar “rabichos” para trás.

Agregando valor
Ao comparamos a evolução do IDP e IDC ao longo do ciclo de vida do projeto, evidencia-se o
esforço do gerenciador do projeto em “agregar valor” ao projeto. A muitos escapa a razão de nomear o
trabalho executado em valores orçados como “valor agregado” – vamos refletir sobre isso.
Suponha que o projeto, em um dado momento, realizou exatamente aquilo que havia sido
planejado, tanto em prazos quanto em custos. Como ficariam os índices de desempenho? Claro,
IDP = 1 e IDC = 1. Não está ruim nem bom, está neutro. Significa que o gerenciador e a equipe se
esmeram por cumprir os planos, mas não estão agregando valor na execução do projeto.
Então, o que é “gerir pelo valor agregado”? É simplesmente fazer mais por menos, mais
rápido com menor custo; isto é, fazer melhor que o planejado. Durante o planejamento, a equipe
do projeto se esforça para otimizar recursos e mitigar ameaças; durante a execução, a equipe se
esforça para economizar tempos e recursos.
A Gestão pelo Valor Agregado cria uma mentalidade de melhorar sempre, não aceitando
gastar todo o tempo e dinheiro alocados para o projeto. É típico do perfil empreendedor.
Experimente praticar a gestão pelo valor agregado. Certamente, recuperará a governabilidade
dos seus projetos.

Gestão do Conhecimento em Projetos

Como aprender a gerenciar projetos?
No ensino superior, ainda hoje, há poucos cursos que incluem o gerenciamento de projetos
como disciplina obrigatória. Onde existe, foram iniciados há poucos anos. Diante disso, poucos
entre os que lideram projetos nas organizações brasileiras passaram por formação nesse tema.
Sem formação, os gerenciadores de projetos aprenderam pela experiência, e muitos
desenvolveram verdadeira competência assim. Apesar disso, aprender pela experiência é usar
tentativa e erro, é aprender colecionando erros e insucessos, mas o que preocupa é que aprenderam
pela própria experiência. Você gostaria de aprender pela experiência de outros? Isso implica gestão
do conhecimento.

99
Gerir conhecimentos
Se os projetos são desafios únicos, temporários e empreendidos por equipes temporárias, é de
se supor que só aprendem aqueles que tiveram o privilégio de participar da execução de um projeto
bem-sucedido. Não aprendem aqueles que tiveram uma participação periférica e de reduzida
dedicação ao projeto. Não aprendem aqueles mobilizados durante a execução e desmobilizados
antes do fim do projeto, porque não vivenciaram o ciclo de vida completo do projeto, nem quem
participou de projeto malogrado ou desprendeu o que sabia ou aprendeu como “defender-se” diante
de malogros.
Aprendem aqueles que transformaram experiências únicas em vivências criticamente
refletidas; aqueles que aprendem por comparação com outros projetos e com situações similares;
aqueles que tiveram mentores e coaches, ou que encontraram momentos durante a execução do
projeto para mensurar, avaliar e criticar o próprio desempenho. Como os projetos são únicos,
aprendem aqueles que criam técnicas, codificam, praticam e compartilham o seu uso com colegas
e, por fim, apreendem, isto é, assimilam os erros e acertos, para criar melhorias na sua própria
prática. É o que denomino “espiral do conhecimento”.
Aqueles que pouco aprendem pela experiência tendem a repetir práticas em outros projetos,
sem perceber que se eles são únicos. Toda repetição tem chance diferente de apresentar sucesso.
Aqueles que aprendem atingem o “estado de arte”: a sua prática torna-se autêntica, a sua perícia
torna-se evidente, e o sucesso tem maior chance de ocorrer, quaisquer que sejam as variações em
futuros projetos.
Seria fantástico se esses “artistas”, e não meramente técnicos, pudessem educar os seus colegas
na organização. Contudo, participar de um projeto é algo tão envolvente que pouca dedicação
restaria para isso. Pior: sem um sistema de gestão do conhecimento no projeto ou na organização,
isso seria impossível.

Gerir projetos requer gerir conhecimentos

Com esse título, escrevi um artigo em 2009 para a revista Mundo PM, o mais conhecido
periódico brasileiro em gestão de projetos. Nesse artigo, defendi a noção de que seria preciso
adicionar a Gestão do Conhecimento como mais uma “área de conhecimento” no Guia PMBOK,
então na terceira edição. Bem, a sexta edição dessa norma adicionou um processo de gestão dedicado
ao assunto na área de conhecimento da integração – e é a principal novidade dessa edição.

100
 As edições anteriores do Guia PMBOK mencionavam apenas a coleta de lições aprendidas,
como prática isolada de gestão de conhecimentos. Também a norma ISO-10.006, editada em 1997
e reproduzida como norma brasileira em 2000, tratava da qualidade em projetos. A cláusula 6,
“aprendendo com o projeto”, sugeria:

esta cláusula fornece diretrizes sobre como convém à organização

empreendedora aprender com o Projeto, como parte de um programa para
melhoria contínua em outros Projetos, atuais e futuros. Convém que a
organização empreendedora estabeleça um sistema para aquisição,
armazenamento, atualização e recuperação de informações sobre Projetos,
além de garantir que estas informações sejam utilizadas.

Note que a norma de qualidade enfatizava o uso de informação, e não de conhecimentos

adquiridos. A distinção entre informação e conhecimento preocupa filósofos há 25 séculos –
epistemologia – e o pessoal de tecnologia da informação desde os anos 1960.
A informação deriva do processamento de dados e serve para formar conhecimento. Dados
representam valores ou quantidades; a informação é o significado contextualizado de dados. Já o
conhecimento é a informação mentalmente processada, que habilita à ação. Platão disse no Teeteto:
“O conhecimento é algo que não podemos possuir passivamente”, porque o conhecimento reduz a
ignorância, transforma as ideias e modifica os comportamentos.
Informação é concreta, objetiva e unidimensional; conhecimento é abstrato, subjetivo e
multidimensional, portanto, sensível ao contexto. Informação é codificada com a linguagem;
conhecimento é codificado em sensações, emoções, imagens e ideias. Informação pode ser
registrada e recuperada facilmente para o uso; conhecimento é retido pela memória e pelo
aprendizado. Informação pode ser analisada, deduzida e implica inferências e síntese para criar
nova informação; conhecimento pode ser compreendido conscientemente, mas implica
criatividade para gerar novos conhecimentos.
Informação envolve conhecimentos “explicitáveis”, podendo ser armazenada em indivíduos,
organizações e bases de dados; conhecimento envolve, sobretudo, conhecimentos “tácitos”
(silenciosos), que residem apenas em indivíduos e incorporados em processos.
O filósofo Michael Polanyi em 1959 criou o conceito de conhecimento tácito, agora adotado
pelo Guia PMBOK. Para ele, é o conhecimento genuíno e não apenas memorizado; é o
conhecimento dos que têm reduzida escolaridade, é um saber de cunho prático; é o conhecimento
de que não nos damos conta; não sabemos que temos ou como o formamos, mas é o que distingue
os talentosos, os peritos e todos aqueles que têm conhecimento incorporado – in corpore – portanto,
não intelectualizado.
O Guia PMBOK menciona que os insumos para a gestão do conhecimento são: o plano de
gerenciamento do projeto, os documentos, os entregáveis, além dos fatores ambientais (cultura,

101
distribuição geográfica de instalações e recursos) e ativos de processos organizacionais (políticas,
gestão de RH, requisitos de comunicação e procedimentos para lidar com informação e
conhecimento). Como ferramentas, cita a opinião especializada, a gestão de conhecimentos, a
gestão de informação e as habilidades interpessoais e de equipe (competências brandas). Os
produtos desse processo de gestão são: registro de lições aprendidas, atualização de planos e de ativos
de processos organizacionais. Note: os ativos de processo são as políticas, os processos e
procedimentos – é a materialização de conhecimentos tácitos, portanto, é essencial atualizá-lo.
Gerir informação envolve coleta, registro e repositório de informação, além da gestão da
qualidade da informação, da sua disseminação e do seu uso. Isso é importante em projetos? Claro
que sim, mas não basta gerir os conhecimentos explicitáveis, aqueles que se transformam em
informação. Possivelmente, é mais relevante em um ambiente único, desafiador, onde são mais
eficazes as competências brandas (soft skills), a gestão dos conhecimentos tácitos.
Contudo, conhecimentos tácitos residem na mente dos seus possuidores, que muitas vezes
nem sabem que têm, ou se sabem não conseguem explicar de forma objetiva. Como gerenciar
conhecimentos tácitos? Afirma o Guia PMBOK:

o gerenciamento do conhecimento envolve garantir que as habilidades,

experiências e expertise da equipe do projeto e de outras partes interessadas
sejam utilizados antes, durante e depois do projeto. Como o conhecimento
reside nas mentes das pessoas e as pessoas não podem ser forçadas a
compartilhar o que sabem (nem a dar atenção ao conhecimento de outros),
a parte mais importante do gerenciamento do conhecimento é criar uma
atmosfera de confiança para que as pessoas sejam motivadas a compartilhar
seus conhecimentos.

Entre as técnicas para gestão do conhecimento, o Guia PMBOK exemplifica: redes sociais;
comunidades de praticantes; reuniões, fóruns, eventos e oficinas; feiras e treinamento participativo.
Gostaria de acrescentar: desenvolvimento de competências; coaching e mentoria; políticas para
incentivar o compartilhamento de conhecimentos; políticas e práticas para aprender com os erros.
Entre as técnicas para gestão da informação, a norma cita: métodos de codificação;
bibliotecas; lições aprendidas; coleta de informação e pesquisa; Sistema de Informação de
Gerenciamento de Projetos (SIGP). Gostaria de acrescentar: sistemas para trabalho colaborativo;
“páginas amarelas”; repositório de conhecimentos (vai além do SIGP porque armazena memórias
técnicas, artigos, propostas, planos e todos os produtos da criatividade humana).
Gerir conhecimentos na organização envolve promover criação, codificação, compartilhamento
e apropriação de conhecimentos. Para estimular a criação, as políticas e a mentalidade de inovação
são indispensáveis. Para a codificação, todo esquema, mapa mental, imagem, metáfora, conceitos e
definições são usados. Para o compartilhamento, é necessário promovê-lo. Como é um ativo

102
profissional importante, muitos podem protegê-lo. É preciso criar um ambiente em que todos os que
compartilham têm visibilidade e são reconhecidos por isso, mas não devemos desprezar o trabalho em
equipe, arranjo organizacional em que há cooperação mais profunda e intensa. Para a apropriação de
conhecimentos, recomendo avaliação de capital intelectual.

Confiança, contato e reconhecimento

Não importa em quais projetos estão ou foram alocados, a gestão do conhecimento
potencializa esse conhecimento em gestação e em revisão. Peritos educam novatos. Quem vivenciou
projetos semelhantes educa colegas tendo em vista a melhoria contínua. O trabalho se confunde
com ações educacionais, tornando concreto o conceito de blended learning e de 70/20/10. As
comunidades, os fóruns de discussão de projetos, a produção de artigos científicos e as fartas
bibliotecas digitais ou não amplificam o resultado.
Nessas organizações, todos aprendem continuamente como gerenciar projetos e se orgulham
desse conhecimento distintivo. Vão além do que prega o Guia PMBOK e formam o estado da arte
da profissão.

Fontes
ABNT/CB-25 – Comitê Brasileiro da Qualidade. NBR ISO 10.006: gestão da qualidade – diretrizes para a qualidade
no gerenciamento de projetos. Rio de Janeiro: ABNT, 2000.

BRESNEN, M.; GOUSSEVSKAIA, A.; SWAN, J. Organizational routines, situated learning and processes of
change in project-based organizations. PM Journal, p. 27-41, September 2005.

NONAKA, I.; TAKEUCHI, H. The knowledge-creating company: how Japanese companies create the dynamics of
innovation. New York: Oxford University Press, 1995.

PMI – Project Management Institute. Guia PMBOK: um guia para o conjunto de conhecimentos em gerenciamento
de projetos. 6. ed. Newtown Square: PMI, 2017.

POLANYI, M. Personal knowledge: towards a post-critical philosophy. Chicago: The University of Chicago Press,
1958.

SABBAG, P. Y. Gerir projetos requer gerir conhecimentos. Mundo Project Management, p. 9-15, junho/julho 2009.

______. Espirais do conhecimento: ativando indivíduos, grupos e organizações. São Paulo: Saraiva, 2007.

103
Código de ética e conduta profissional: pmi
Ética existe?
Você julga que as organizações são éticas? Sobre governos e política já temos opinião formada.
Mesmo as organizações que têm código de conduta e um canal para reportar desvios éticos são
éticas? Se temos frustrações nesse campo, possivelmente ocorre porque há incongruências entre os
nossos valores e os valores efetivamente praticados nas organizações.

Moral não é o mesmo que ética

Há uma diferença crucial entre moral e ética. A moral é reativa (cumprir leis e normas sociais),
enquanto a ética é proativa (dever de consciência). Códigos de conduta enfatizam os
comportamentos obrigatórios, passíveis de sanções – contudo, são insuficientes para desenvolver a
ética na organização. A dificuldade de incentivar a ética deve-se ao fato de que, como resulta de
uma questão de princípios e do dever de consciência, não é fácil redigir um código de ética.

Código promove valores e condutas

O PMI tornou efetivo em 2007 o Código de Ética e Conduta Profissional válido para
membros do PMI, para voluntários em atividades patrocinadas pela entidade (membros ou não) e
para profissionais certificados pela entidade. Pela qualidade do código, eu o recomendo a todos.
A visão e o propósito do código são: “como praticantes do Gerenciamento de Projetos, nós
somos comprometidos em praticar o que é certo e honrado. Nós estabelecemos normas elevadas
para nós mesmos e aspiramos cumprir essas normas em todos os aspectos de nossa vida: em casa,
no trabalho e a serviço de nossa profissão”.
O código usa o “nós” para indicar o pertencimento a uma comunidade de praticantes.
Privilegia o que é certo (moral) do que é honrado (ético, longe da busca por reputação). Indica uma
obviedade: se somos éticos, o somos em todas as dimensões da nossa vida. Não é possível ser ético
em casa e não o ser no trabalho. O aspecto mais relevante dessa visão é quando indica que
“estabelecemos normas elevadas” e “aspiramos cumprir”: a premissa é de que ninguém é totalmente
ético, daí buscar a ascese, isto é, ser mais ético no futuro. Não é uma visão ideológica, mas, sim,
pragmática. Considera que há dilemas éticos de solução difícil, daí aspirar cumprir ao invés de
desistir e de reafirmar que ser ético é uma utopia.
Esse código inclui normas ambicionadas (aspirational standards) e normas obrigatórias
(mandatory standards). As normas ambicionadas indicam as expectativas acerca dos praticantes da
“comunidade global de gerenciamento de projetos” um comportamento ético; as obrigatórias
sujeitam o gerenciador a sanções do PMI.

104
 Em geral, códigos de conduta são prescritivos e taxativos, portanto, são condutas obrigatórias.
Referem-se a questões morais mais do que éticas. A virtude desse código é que não se restringe à
moralidade das normas obrigatórias, mas também ressalta a ética das normas ambicionadas.
A ética, por ser um dever de consciência, é mais fecunda quando baseada em valores. O
Código do PMI estabelece normas baseadas em quatro valores fundamentais abaixo. Curiosamente,
são quase idênticos aos defendidos por Aristóteles há 2.500 anos, o que sugere serem esses valores
universais da humanidade: responsabilidade, respeito, justiça e honestidade.
O ambiente organizacional apresenta inúmeros desvios da ética:
falta de responsabilidade com interessados e afetados (stakeholders);
comportamentos contrários a normas e opostos a respeito, confiança e consideração;
conflitos de interesses entre sociedade, comunidade, organizações e indivíduos;
plágios, usurpação de propriedade intelectual;
uso indevido de informação institucional (quebra de confidencialidade);
mau uso de bens materiais da organização;
descuidos em relação à segurança, ao meio ambiente e ao clima organizacional;
manipulação dos preços e do mercado;
fraudes fiscais e evasão de impostos;
ocultação de provas e de informação, abuso de autoridade;
adulteração de documentos oficiais;
apropriação indébita;
subornos, corrupção, tráfico de influências e
nepotismo, favorecimento, assédio sexual, intimidação.

Quando esses desvios são divulgados, geram irreversíveis prejuízos à reputação da

organização. Vivemos em um mundo mais alerta e exigente em questões éticas. Note que o código
do PMI, com tamanha simplicidade, cobre praticamente todos os desvios acima arrolados.

Normas elevadas que aspiramos cumprir

Como viver em uma sociedade complacente com questões éticas? Se nada fizermos, não
podemos reclamar de políticos e da corrupção no governo. Por outro lado, muitos abrem mão de
participar da política. Significa aceitar passivamente a falta de ética?
Prefiro outra opção, parafraseando Shakespeare: a ética “é uma porta que se abre por dentro”.
Se cada um fizer a sua parte, a soma de todos os esforços fará a diferença. E, quer saber, vivendo
eticamente a vida fica muito mais fácil: as relações tornam-se mais verdadeiras e duradouras;
adotando a verdade como princípio o trabalho e a solução de problemas são favorecidos; seremos
mais justos e respeitosos em tudo.
Porém, quanto mais éticos nos tornarmos maior a incongruência com o trabalho pouco ético.
Desse dilema surgirá a opção de permanecer ou não em contextos pouco éticos. É a decisão
existencial mais valiosa.

105
MÓDULO V – EXECUÇÃO

O tema do módulo final desta disciplina é a execução de projetos. Enquanto o planejamento

e controle respondem por 50% da chance de sucesso de um projeto, acreditamos que o trabalho
em equipe responde por 40% da chance de sucesso. Dependendo do tipo de organização, os
projetos podem resultar em taxas maiores ou menores de sucesso. A escolha do gerenciador de
projetos e a governança definida também afetam a taxa de sucesso. Isso remete à relação entre
liderança e maturidade da equipe do projeto. O módulo adiciona uma discussão sobre o Escritório
de Gerenciamento de Projetos (EGP).
Ao final, esperamos que você seja capaz de:
entender como definir a governança de projetos e a definir equipes temporárias de projetos;
compreender o funcionamento de organizações hierárquicas, matriciais e por projeto;
entender as estruturas de apoio a projetos, denominadas Escritório de Gerenciamento de
Projetos (EGP) e
entender as competências requeridas do gerenciador para o sucesso em projetos.

Governança em projetos
Delegar
Gestores irônicos fazem uma distinção sagaz: “Há diretores que delegam e há aqueles que ‘de-
largam’”. Os primeiros oferecem liberdade e apoio, mas fazem a supervisão e intervêm sempre que
necessário. Os últimos oferecem liberdade e se isentam de quaisquer riscos, não apoiam nem
supervisionam e, tempos depois, quando precisam controlar o progresso, criticam tudo o que foi feito.
É uma questão de governança. Imagine que há mais chances de “de-largar” um projeto que
qualquer outra tarefa. Esse é o pano de fundo.
Governança define a gestão
Management, o trabalho de diretores, gerentes e gerenciadores, é um termo que deriva do
Latim maneggiare. O uso mais antigo do termo contava as proezas de um general que era tão hábil
no comando das suas tropas como era manejando o seu cavalo: o cavalo é mais forte, mas o cavaleiro
está tão vinculado ao cavalo que facilmente o dirige ou governa na trilha desejada. É uma boa
metáfora para a governança.

Mais que estrutura

Governança e governabilidade são dois conceitos muito usados no governo, na administração
pública e nas corporações. Vamos fazer a distinção. No setor público, a governança inclui
instituições, leis e costumes. Governança é o conjunto de estrutura, políticas, processos e modelos
de atuação que servem da base, no nosso caso, para a execução do projeto. Governabilidade é a
capacidade de realizar o projeto e as condições para exercer a liderança do projeto.
Muitos gerenciadores de projeto reclamam não ter autonomia suficiente para lavar o projeto
ao sucesso: é questão de governança. Muitos dirigentes reclamam que faltam habilidades e
competências para gerenciadores atingirem o sucesso: é questão de governabilidade. Há uma relação
entre os conceitos: uma governança precária ameaça a governabilidade; por outro lado, líderes
impetuosos e excessivamente independentes podem até atingir o sucesso, mas ameaçam a
governança e o “sistema de gestão” a ela atrelado.
Para desenvolver governabilidade, é preciso que o gestor se torne contável (responsivo,
responsável e comprometido), respeite as políticas internas e as leis (compliance) e respeite a
distribuição de papéis e responsabilidades definidas pela governança.
Para desenvolver governança, é preciso compreender o “sistema de gestão”. Na teoria dos
sistemas, as partes são interdependentes, todas têm igual finalidade e buscam o equilíbrio dinâmico.
O projeto não é autônomo, ele se insere em uma organização que tem o seu próprio modo de
funcionar – não fosse assim, o projeto seria externo à organização e independente, deixado à própria
sorte. Nesse caso, o gerenciador do projeto é como um empreendedor: ele guarda relações com os
investidores, executores e órgãos públicos, mas a responsabilidade maior é quase que totalmente a
sua. Duvido que gerenciadores de projetos internos às organizações desejem esse grau de
independência.
Estrutura é a questão-chave da governança. Mais importante que definir a equipe do projeto
é definir como a equipe interatua com os demais setores da organização que hospeda o projeto e
com os interessados (stakeholders) externos.
Por razões culturais, até o PMBOK Guide aponta o organograma como a ferramenta que
organiza as pessoas do projeto. Organograma é uma excelente ferramenta para mostrar as relações
hierárquicas de autoridade e poder, mas há relações funcionais, nem sempre hierárquicas. Há
posições temporárias como a de patrocinadores, que não fazem parte do organograma da

108
organização que hospeda o projeto. Além do mais, como desenhar um organograma de equipe de
projeto que funcione em estrutura matricial, em rede ou grupo-tarefa?
Diante disso, quando planejo um projeto, prefiro fazer um desenho que evidencie a
governança. Ele contém quatro aspectos:
1. Em que ponto há tangência entre a organização e o projeto – esse é o vínculo criado por
patrocinadores do projeto.
2. Como é formada a equipe do projeto, gerenciador e membros, indicando as suas relações
funcionais com os setores da organização que hospeda o projeto – esse é o vínculo dos
representantes de área e pontos focais; ou então é o que define a organização matricial.
3. Como se relacionam os membros da equipe e gerenciador – esse revela o vínculo entre
pessoas, se é hierárquico ou em equipe.
4. O sistema de gestão se completa evidenciando parceiros e organizações externas que
também “governam” o projeto: decidem e comandam – esse é o vínculo contratual, que
apresenta relações institucionais e relações funcionais.

O sistema de gestão pode ser complexo, por questões estruturais. Se é complexo, exigirá maior
esforço em horas de trabalho, maiores competências brandas e maior disciplina de método. Quanto
mais intrincado, mais depende de uma boa Matriz de Responsabilidades. A geografia também
dificulta as relações, tornando essencial que o Plano de Comunicações a considere e regre também
os processos decisórios.
Quando se trata de políticas e processos, a governança compreende: decisão, comando,
comunicação, alinhamento, abordagem e controles.
Vamos discutir as decisões. Se não é definido um patrocinador, assume-se que alguém na
estrutura da organização assume esse papel: pode ser um gerente, um diretor, vice-presidente ou
dirigente. Pode haver uma política que endereça a comitês existentes ou ad hoc (caso a caso). Se a
organização dispõe de um Escritório de Projetos (EGP ou PMO, na sigla em inglês), é preciso
definir o seu papel nas decisões, pois ele varia. Se a organização adota o modelo de programas e de
portfólios, é preciso definir como os respectivos gestores atuam nas decisões. Em certos campos de
aplicação, a obrigação de prestar contas é também uma política de decisões, e foi mencionada no
PMBOK Guide.
Sobre o comando, em geral, ele não é cercado de formalidade, mas nas relações entre
instituições isso é necessário: em consórcios, alianças, joint-ventures e relações contratuais, mas o
comando deve respeitar sempre os costumes e a cultura da organização para que seja efetivo. O
mesmo vale para a comunicação: usa canais e modelos costumeiros; também inclui como
encaminhar questões e pendências.
A governança promove o alinhamento: entre o projeto e as estratégias da organização, caso
em que a gestão de portfólio contribui decisivamente; entre os interessados e os requisitos aprovados
para o projeto; entre critérios de sucesso para o projeto.

109
 Inclui a abordagem: na definição e revisão de datas-marcos (milestones); na abordagem do
ciclo de vida do projeto (timing); na aprovação de mudanças, que pode incluir um Controle
Integrado de Mudanças como parte da governança.
Por fim, a governança também estabelece controles: ferramentas e sistemas de coleta e
processamento de informação (Management Information System); relatórios formais; auditorias.

Governabilidade requer a boa governança

A competência em gestão depende de atributos pessoais, é certo, mas o peso das organizações é
tão grande que essa competência se torna igualmente dependente da boa governança. Não estou aqui
tratando da governança corporativa, mas, sim, da governança dos projetos.
Organizações pouco maduras no gerenciamento de projetos costumam negligenciar a
governança de projetos, e aí reside o perigo. É a governança que tece teias envolvendo o projeto e o
conectando a setores da organização e a interessados externos.
Se a sua organização não tem uma governança adequada para projetos, você, enquanto líder
e gestor, deve criá-la cuidadosamente e passo a passo. Defina patrocinadores e fóruns para as
decisões. Crie “políticas” na forma de premissas que conta usar no seu projeto, e compartilhe com
todos o seu modo disciplinado de governar o seu projeto.

Gestão de Recursos do Projeto

Todo tipo de recursos
Nos primórdios da “Administração Científica”, os humanos eram mais um entre os recursos
alocados aos sistemas de produção fabril. Talvez fosse natural para um engenheiro como Frederick
Taylor pensar de forma tão racional, mas isso desumanizou a indústria por um século.
Da quinta para a sexta edição do Guia PMBOK, a área de conhecimento “Recursos
Humanos” passou a ser denominada apenas “Recursos”, porque reúne equipe, instalações,
equipamentos, materiais e suprimentos requeridos para o projeto. Seria um retorno ao taylorismo?

Trabalho em equipe não é luxo, é necessidade

A Gestão de Recursos do Projeto envolve os processos para “identificar, adquirir e gerenciar
os recursos necessários para a conclusão bem-sucedida do projeto”. Visa a garantir que os recursos
certos estejam disponíveis na hora e no lugar certos.
A norma do PMI admite que as competências para gerir recursos físicos são diferentes das
competências essenciais para gerir pessoas. Alerta que o grau de dedicação dos membros da equipe
do projeto pode variar, pois estes são mobilizados e desmobilizados conforme a execução do projeto
e, no caso de equipes multidisciplinares, provêm de diferentes setores da organização. Para piorar,

110
é raro que membros da equipe se reportem hierarquicamente ao gerenciador do projeto. Se ele não
“chefia” a equipe, como orientar e gerenciar a equipe?

Recursos físicos e humanos

A figura abaixo explora os seis processos de Gestão de Recursos do Projeto. Planejar gestão
de recursos inclui definir como estimar, adquirir, gerenciar e utilizar recursos físicos e de equipe.
Estimar recursos das atividades envolve tanto a concepção da equipe do projeto como o tipo e as
quantidades de materiais, equipamentos e suprimentos necessários. Adquirir Recursos envolve por
um lado arregimentar pessoas para compor a equipe concebida quanto obter recursos físicos
estimados. Desenvolver equipe do projeto envolve ampliar competências, interação entre membros
e ambiente para aprimorar o desempenho. Gerenciar equipe do projeto é avaliar
desempenho, fornecer feedback, resolver questões e gerenciar mudanças na
equipe – típico da Gestão de Pessoas. Por fim, Controlar os recursos envolve
garantir que os recursos estejam disponíveis conforme o planejado, executando
ações corretivas se necessário.
O Guia PMBOK apresenta tendências relevantes nessa área do
conhecimento: métodos para gerenciamento de recursos se popularizaram (lean
management, just-in-time, Kaizen); exigência de inteligência emocional pelo
gerenciador do projeto; adoção de equipes auto-organizadas; e equipe virtuais
ou distribuídas.
No primeiro processo, a questão é: como planejar a equipe do projeto?
Primeiro: quanto mais estratégico o projeto, mais elevada deve ser a posição do
seu patrocinador, diante da qualidade das decisões requeridas. A ele se vincula
o gerenciador do projeto, que lidera a equipe temporária. Os membros dessa
equipe raramente têm dedicação integral e exclusiva ao projeto — o usual é a dedicação parcial,
porque permanecem as suas obrigações na área a que pertencem.
Segundo: todo o escopo do projeto deve ser executado pela equipe do projeto? Essa é uma das
possibilidades, que chamo de estrutura vertical. Há também a estrutura horizontal, em que a equipe
do projeto é mínima (faz apenas gestão) e quase todo o escopo é realizado por pessoal da estrutura
permanente da organização, cada qual atuando em seu setor. É comum a estrutura híbrida, em que a
equipe do projeto, mais encorpada, assume partes críticas do escopo (além da gestão), enquanto o
restante do escopo é desempenhado por pessoal da organização permanente ou por terceiros. Por
existirem essas três opções é que o Guia PMBOK diferencia a equipe do projeto da equipe de
gerenciamento do projeto: a primeira contém a última, nas estruturas vertical, híbrida ou horizontal.
Em projetos de criação de negócios, a estrutura vertical é mais usada. O mesmo ocorre quando
o projeto é tão substantivo ou grandioso que requer a criação de uma estrutura vertical
hierarquizada, “agrupada” (trabalha no mesmo espaço físico): megaprojetos como a construção de

111
navios e obras de construção pesada adotam esse modelo. É esse também o caso de projetos do
terceiro setor ou de organizações sociais.
Se a organização responde bem ao planejado, assumindo compromissos, ou se as atividades
são pouco dependentes das demais, recomendo a estrutura horizontal. Ou então, quando o pessoal
é contável (accountable): cumpre o que promete. Um exemplo disso são os projetos corporativos de
organizações empreendedoras.
A estrutura híbrida significa reservar à equipe do projeto as atividades mais críticas e a gestão,
enquanto o restante do escopo é descentralizado. Também permite o engajamento de clientes,
usuários e parceiros compartilhando o escopo do projeto. Permite definir “pontos focais” em cada
área ou trazer para a equipe de gestão os “representantes” de cada área. Essa parece ser a forma mais
usada atualmente, nos três setores, governo, particular e social.
Cada escolha tem consequências. Escolher execução vertical significa formar equipes
numerosas, com hierarquia e especialização, com parte do pessoal com dedicação grande (>70%)
ou exclusiva ao projeto. Escolhendo execução horizontal, o perigo é o gerenciador cuidar de
demasiados projetos simultâneos, sem apoio de pessoal; a vantagem é formar uma equipe com
representantes de cada setor (grupo-tarefa) ou definir “pontos focais” como único canal para o
relacionamento com cada área. Escolhendo execução híbrida, forma-se uma estrutura mista: a
equipe de gestão (core team, no inglês) dedica-se mais que os demais membros (soft team).
A partir daí, pode ser definido o tipo de organização. Estrutura vertical com equipe numerosa
requer hierarquia: equivale à organização por projeto. Estruturas híbridas e horizontais fazem uso de
estrutura matricial, em que o núcleo do projeto coordena (na linha da matriz) o pessoal de diferentes
setores (colunas da matriz) alocados ao projeto. Como também faz uso de estruturas em rede, que
correspondem à negação da hierarquia, tornando mais fácil e provável obter o trabalho em equipe.
Resolvida a “arquitetura” organizacional para o projeto, é necessário dimensionar essa
organização – estimar os recursos. Adoto o seguinte processo:
Define-se previamente o modelo de equipe, com primeira estimativa da quantidade
de pessoas.
Essa organização é confrontada com o Escopo do Projeto, visando a repartir o trabalho —
a técnica usada é a Matriz de Responsabilidades, que reúne organizações externas, setores
da organização que hospedam o projeto e a Equipe do Projeto, esta última detalhada
membro a membro. No cruzamento entre atividades do escopo e cada pessoa, são
definidos os papéis e as responsabilidades daquela pessoa ou daquele grupo.
Conforme o somatório de papéis e responsabilidades de cada membro da Equipe do
Projeto, decide-se o montante de dedicação (integral ou parcial) de cada membro.
No cronograma, o pessoal é alocado a cada atividade do Escopo do Projeto, visando a
estimar o esforço e a dedicação — forma-se o Quadro de Alocação de Pessoal. Como estamos
tratando de recursos em geral, também podem ser alocados no cronograma os
equipamentos custeados por hora trabalhada.
A partir daí, são deduzidos os recursos necessários.

112
 O Plano de Recursos do Projeto apresenta o organograma acompanhado de esclarecimentos,
apresenta a matriz de responsabilidades e o quadro de alocação de pessoal (idem para
equipamentos). Pode incluir também as demandas de treinamento da equipe do projeto e o
fluxograma do sistema de tomada de decisões.
Há um aspecto adicional que o Guia PMBOK menciona com pouca ênfase. As questões de
ética e conduta muitas vezes precisam ser planejadas, sobretudo se a equipe do projeto é híbrida e
reúne pessoal de diferentes organizações. Nesse caso, é conveniente arrolar os valores esposados no
projeto, e, como decorrência deles, as normas de ética e de conduta são definidas e divulgadas.
Geralmente, as organizações designam o gerenciador do projeto e alguns membros da equipe,
supondo que são suficientes para o desafio de execução. Não se sabe, e é bom duvidar, se essas
pessoas têm comprometimento e dedicação assegurada ao projeto; não se sabe se têm habilidades
complementares; não se sabe o que os chefes e gestores de cada uma delas sabem a respeito do
projeto. É a rota para o fracasso. Diante disso, o Guia PMBOK preconiza a aquisição dos membros,
melhor dizendo, arregimentação: o seu papel é conceber a organização que deseja para o seu projeto,
negociando com os chefes e gestores a liberação do pessoal que deseja; e depois estabelecendo
compromisso com todos.
Para adquirir os recursos, note que eles podem ser internos ou externos à organização. Pessoas
podem ter contratos temporários ou permanentes, assim como equipamentos e instalações podem ser
alugados, mas o problema não e de planejar e adquirir, é preciso transformar esse grupo de pessoas
em uma verdadeira equipe, coesa e contável. É preciso compartilhar o desafio assumido pelo
gerenciador do projeto com essa equipe. Alerte-se para as dificuldades envolvidas nas equipes virtuais.

Equipe coesa, mesmo que virtual

Os projetos costumam ser o melhor ambiente para adquirir pessoal temporário, incluindo
consultores, parceiros, etc. Costumam ser o ambiente preferido para o funcionamento distribuído –
as equipes virtuais – com todas as dificuldades que se apresentam, mas a dificuldade primordial é: o
gerenciador de projetos profissional precisa ter a competência de transformar grupos em equipes, e
precisa ser um competente gestor de pessoas, lidando com o lado humano do projeto.

Fontes
KEELING, R. Gestão de projetos: uma abordagem global. São Paulo: Saraiva, 2002.

PINTO, J. K.; TRAILER, J. W. Leadership skills for project managers. Newtown Square: PMI, 1998.

PMI – Project Management Institute. Guia PMBOK: um guia para o conjunto de conhecimentos em gerenciamento
de projetos. 6. ed. Newtown Square: PMI, 2017.

113
Organização: tipos
A sua organização é de qual tipo?
A estrutura ou forma de organização, como não poderia deixar de ser, afeta o desempenho e
a qualidade das relações e do trabalho. É difícil definir a organização onde atuamos, até porque não
é raro encontrar diferentes formas de organização dentro de uma empresa ou fundação. As
hierarquias são tão compartimentadas que, se o setor de Recursos Humanos for complacente,
muitos diretores criarão a sua própria forma de organização para o seu setor. Você já viu isso?

Somos arquitetos de organizações

O problema estrutural surge nas situações em que há desdobramentos da organização: nos
projetos temporários e na criação de outras organizações, como fundações e institutos ligados à
organização original.
Uma equipe de projeto pode organizar-se de um modo distinto da organização que o
hospeda? Uma recomendação das normas de gerenciamento de projetos é o trabalho em equipes –
seria possível acomodar equipes reais em hierarquias renitentes? O mesmo se dá quando a
organização decide criar um instituto para o investimento social, quase sempre organizado por
projetos – cria um conflito cultural e estrutural.
A cultura organizacional precisa ser suficientemente elástica para acomodar diferentes padrões
organizacionais, até que se consagre um novo e abrangente padrão para cada organização. Nas
próximas décadas, é possível que o padrão hegemônico seja a organização por projetos, influenciando
a forma como as corporações se organizarão. Para isso, cada gestor precisa tornar-se um “arquiteto de
organizações”, para tirar o melhor partido da forma de organização em que opera.

Projetos, matrizes e redes como alternativa à hierarquia

Nada indica que a hierarquia deixe de ser a mais comum forma de organização. Não só no
ambiente religioso ou militar, mas no mundo corporativo, a transformação está ocorrendo. Há um
paradoxo que gera uma tensão estrutural: enquanto na hierarquia tudo flui na direção vertical, os
processos operacionais fluem na horizontal, isto é, somam contribuições de diferentes setores
especializados da organização. Exemplo de cadeia horizontal: para desenvolver e lançar um novo
produto, o setor de Desenvolvimento elabora os desenhos e protótipos apoiado pelo setor de
Marketing, que mantém contato direto com o mercado, mas o produto não sairá do papel sem a
Engenharia conceber processos industriais, de modo que o setor de Operações possa produzir, o
setor de Logística distribuir e a força de Vendas o colocar junto aos clientes.

114
 O paradoxo é que a lógica horizontal é tangível, enquanto que a lógica vertical é apenas uma
condição estrutural da hierarquia. Resultado habitual: cada setor atua independentemente dos outros,
mas com comando e controles internos perfeitos – enquanto prospera a falta de sincronia na cadeia.
Para solucionar esse paradoxo, algumas alternativas de organização são usadas desde o século
XX. A primeira alternativa requer verticalizar o processo horizontal: um único setor da organização
cuida de toda a cadeia ou processo. Essa solução resultou em estruturas denominadas: organização
por produto, unidade de negócio e organização por projeto. Um único diretor comanda todo o
setor especializado por tipo de produto e o seu mercado, ou seja, comanda uma hierarquia
focalizada. Não é diferente de uma construtora que cria uma organização temporária para cada um
dos seus empreendimentos imobiliários. Essas estruturas focadas são complementadas por pequenos
setores corporativos de apoio. Tanto Toffler, Mintzberg e Waterman denominam a organização
por projetos como adhocracias,2 do latim ad hoc: configuração em que deliberadamente se forma
uma organização temporária enquanto se busca alcançar certos objetivos. Reputam como a melhor
estrutura para a inovação porque formam constelações de projetos na organização. Mintzberg
afirma: “A adhocracia é a única configuração para aqueles que acreditam em uma democracia com
menos burocracia”.
Outra resposta ao paradoxo é eliminar compartimentos horizontais, gerando a estrutura por
grupo-tarefa. Forma-se um grupo contendo representantes de diferentes organizações ou
instituições. O grupo não admite chefe; no máximo, acolhe uma secretaria executiva. Há um
princípio: as decisões são tomadas por consenso. Depois de decidido, cada representante comanda
as suas organizações para a execução.
Uma alternativa ao paradoxo admite a dualidade horizontal-vertical: é a chamada estrutura
matricial. Na vertical, há uma hierarquia com diretores, gerentes e profissionais, dividida por
especialidades. Na horizontal, há coordenadores de projetos ou de processos. O comando é vertical,
enquanto a coordenação é horizontal: harmoniza a cadência de execução, converte a ação isolada
em sistema, concentra demandas de relacionamento com o cliente externo.
A negação completa da hierarquia é representada pela organização em rede. “A intenção
essencial de todas as redes é a redistribuição do poder”, afirma Marylin Ferguson3 e completa:

ampliada pelas comunicações eletrônicas, liberada das velhas restrições da

família e da cultura, a rede é o antídoto para a alienação. Gera poder
suficiente para reformular a sociedade; oferece ao indivíduo apoios
emocional, intelectual, espiritual e econômico. É um lar invisível, um meio
poderoso de alterar o curso das instituições, particularmente do governo.

2
O termo Adhocracia foi usado por TOFFLER, A. O choque do futuro. São Paulo: Record, 1994.

3
FERGUSON, Marylin. A conspiração aquariana: transformações pessoais e sociais nos anos 80. 6. ed. Rio de Janeiro:
Record, 1988.

115
 Gandhi se valeu desse conceito, adotando a estratégia de coalizões de pequenos grupos para
levar a Índia à independência. Eram então chamadas agrupamentos de unidades. A partir daí,
diferentes agrupamentos políticos passaram a adotar a organização em rede. É a forma de
organização das células de guerrilha, dos movimentos sociais e ambientais.
Pela novidade e importância, vale a pena deter-se na discussão da organização em rede. Ela
apresenta as seguintes características:
É plana, despreza níveis hierárquicos ou de autoridade. Não pode ser chefiada ou
comandada. Em uma burocracia, o título do cargo determina o poder do seu ocupante;
na rede, o que faz e a quem se vincula é que determinam o seu poder.
Despreza cargos ou funções, privilegiando “nós” (pessoas ou grupos) e as suas conexões.
Busca vínculos entre todos, fazendo com que em cada movimento um membro se torne
o centro da rede.
A liderança e a coordenação são circunstanciais: podem ser compartilhadas ou migrar de
pessoa a pessoa, dependendo das necessidades do momento. A coordenação deixa de ser
exercida de cima para baixo, substituída pelo mútuo compartilhamento dessa função.
É um sistema aberto que busca sempre o equilíbrio. As suas fronteiras são mais psicológicas
que estruturais. Está em constante fluxo, pronta para ser reorganizada, capaz de uma
transformação contínua. É amoldável, flexível ou mutante.
É uma estrutura polimorfa e dinâmica, ao contrário da hierarquia, que se pretende estática.
É autogerativa e auto-organizativa (e, às vezes, autodestrutiva). Agrega e dispersa membros
todo o tempo. Representa um processo, e não uma estrutura cristalizada. Para tanto, precisa
ser constantemente estimulada, seja por meio de ação seja de comunicação.
É cooperativa, e não competitiva, como a hierarquia. Os seus membros buscam confiança,
empatia, contribuição espontânea, complementaridade e reciprocidade. Visam ao apoio e
ao enriquecimento mútuo. Conquista muitas vezes a sinergia, energia suplementar que
deriva da cooperação harmônica.
“A rede é, ao mesmo tempo, íntima e ampla”, afirma Ferguson (1988); serve à exploração
pessoal tanto quanto à ação coletiva. Muitas vezes, é invisível, o que para muitos denuncia
um caráter conspiratório ou de conluio. Na realidade, a rede ressalta a coesão dos vínculos.
Em síntese: as redes representam o ideal democrático em todos os sentidos.

Enquanto organização ideal, as redes pressupõem o contato face a face e a comunicação

síncrona, em que o ciclo de comunicação se completa instantaneamente. O trabalho em equipes
virtuais e as comunidades de praticantes representam extensões do conceito de rede. Na visão de
Katzenbach e Smith, a maioria dos modelos de “organizações do futuro” de que ouvimos falar –
networked, clustered, nonhierarchical, horizontal, etc. – parte do pressuposto de que as equipes
compõem a unidade básica de desempenho. A novidade é a possibilidade de as equipes atuarem
sem fronteiras, na forma de redes.

116
 Note a cronologia: enquanto a hierarquia é adotada há milênios, a estrutura por produto data
do início do século XX. O grupo-tarefa, popularizado em inglês como task-force, data da II Guerra
Mundial. Parece ter sido a NASA que popularizou em 1960, nos EUA, a estrutura matricial. Nos
anos 1970, adeptos da “era de Aquário” confrontavam toda forma de autoridade, postulando redes.
Organizações por produto desdobraram-se nas organizações por projeto, a partir dos anos 1960.
Grupos-tarefa desmembraram-se nas equipes, enquanto as redes se tornaram a organização do mundo
digital e geraram o conceito de organização virtual, a partir dos anos 1980.
Hoje em dia, as hierarquias públicas e privadas dividem espaço com as organizações por projeto
adotadas no terceiro setor. Há tanto hierarquias nas grandes organizações quanto há estruturas
matriciais, equipes e verdadeiras redes, para não mencionar inúmeras configurações híbridas.
Cada estrutura condiciona uma mentalidade específica. Imagine o que ocorre em uma grande
organização hierárquica, onde o setor de tecnologia e o de desenvolvimento de produtos se
organizam por projetos, e o setor de recursos humanos se organiza de forma matricial (consultoria
interna e business partner). É o “samba do crioulo doido” das mentalidades.

Estrutura a serviço das pessoas

Quem cria uma organização, seja uma nova empresa, fundação ou organização social, começa
definindo a estrutura. Quero propor uma inversão: a estrutura organizacional deve ser a última
questão a definir. Primeiro, defina o Propósito ou a Visão, a Missão e os Valores da sua organização.
Dessa definição resulta o Mapa de Estratégias. Depois, defina as competências centrais e distintivas,
das quais derivam as funções especializadas (ou não). Só então o gestor dessa organização pode
pensar na estrutura, ou seja, na organização do trabalho. Daí deriva o tipo de organização que se
deseja para obter o melhor desempenho.
Definir primeiro a estrutura, depois os cargos e, por fim, as pessoas é um raciocínio
mecanicista: os humanos são “recursos” dessa organização. Nessa mentalidade, a estrutura restringe
as pessoas, ao invés de libertá-las para que ofereçam o seu melhor desempenho.

117
Escritório de gerenciamento de projetos (egp ou pmo)
Demasiados projetos
Não é estranho que o setor dedicado a apoiar projetos na sua organização seja chamado de
“escritório”? Talvez por isso muitas organizações prefiram usar o nome em inglês: Project
Management Office (PMO). É um assunto controverso, contudo visa a oferecer solução para um
problema sério: a quantidade excessiva de projetos nas organizações.

Escritório ou pessoa?
Quanto maior a reflexão estratégica de uma organização, mais projetos são criados. Quanto
maior o apetite e a competência em criatividade e inovação, mais projetos são criados. Quanto
maior a capacidade empreendedora e ambição da organização, mais e mais projetos são criados.
Quanto mais a mentalidade de atuar por projetos se instala na organização, mais projetos são
criados. Resultado: centenas e milhares de projetos disputam os recursos escassos da organização.
Diante dessa triste realidade, muitas organizações passam a isolar os projetos estratégicos, para
os quais toda a competência e prioridade são atribuídas, abandonando os demais projetos à própria
sorte. Eu não creio que essa seja uma solução viável, porque ela resulta em enorme proporção de
projetos terminados com sucesso parcial ou com insucesso.
A meu ver, há três soluções adequadas para o problema: a gestão de múltiplos projetos por
meio de Escritórios de Projetos; o agrupamento de projetos em programas, adicionando mais gestão
para essa coordenação; e o agrupamento em portfólio, visando a adicionar gestão capaz de priorizar
componentes do portfólio. Aqui, tratamos da primeira solução.
Gerenciar múltiplos projetos é considerar a diversidade e a diferença entre contribuições
empreendedoras. Essa solução (no inglês, multiple project management) requer unificar os processos
de gestão. Se cada projeto fosse gerenciado usando idêntica metodologia, técnicas e sistemas
informatizados, seria possível somá-los, verificando: sobrecarga de recursos (humanos, financeiros e
equipamentos), simultaneidade de eventos, interdependências entre atividades e benefícios obtidos.
Uma competente estrutura de apoio poderia fazer essa verificação e controle, de modo a evitar
conflitos entre projetos, perda de ritmo, incongruências, etc. Essa estrutura de apoio é formalizada como
Escritório de Gerenciamento de Projetos – EPG (no inglês, Project Management Office – PMO). Por
que escritório? Porque privilegia funções de gabinete ou assessoria. Há também uma razão histórica: esse
nome homenageia o pioneiro Special Project Office da Marinha norte-americana, criado para o Projeto
Polaris em 1957 (informa Johnson e colegas).

118
Diferentes escritórios, cada qual com a sua finalidade
O PMI define o Escritório de Gerenciamento de Projetos como

uma estrutura gerencial que padroniza processos relacionados à governança

de projetos e facilita o compartilhamento de recursos, metodologias,
ferramentas e técnicas. As responsabilidades de um EGP variam desde
prover funções de apoio ao gerenciamento de projetos até ser responsável
pela direção de um ou mais projetos.

Note que EGP é um setor da organização, portanto, presume-se que tenha gestores e equipe
de trabalho. Não é raro encontrar no Brasil organizações que chama de PMO as pessoas que coletam
informação sobre a execução do projeto e preenchem relatórios (o que o norte-americano chama de
Project Controller Officer – PCO). Não é um erro crasso, mas presume que cada projeto precisa de
um controlador, isso, sim, um erro porque fragiliza o gerenciador desses projetos.
Há diferentes tipos de EGP em funcionamento nas organizações para atender a finalidades
distintas. O Quadro explora sete tipos de EGP, atribuindo a eles apelidos jocosos com o intuito de
diferenciá-los. À direita estão os três tipos definidos no PMBOK Guide:
Apoiador – PMO apoiador fornece consultoria aos projetos fornecendo templates,
melhores práticas, treinamento, acesso a informação e lições aprendidas de outros projetos.
Esse tipo de PMO serve como repositório. Grau de controle desse PMO é baixo.
Controlador – PMO controlador fornece apoio e requer cumprimento de vários planos.
Cumprimento pode envolver modelos e metodologias, uso de templates específicos,
formulários e sistemas, ou conformidade com governança. Grau de controle desse PMO
é moderado.
Diretivo – PMO diretivo assume o controle de projetos passando a gerenciá-los. O grau
de controle desse PMO é elevado.

Nessa norma, o PMI reitera as diferentes finalidades do EGP (ou PMO):

o PMO integra dados e informação de projetos estratégicos e avalia como

objetivos estratégicos estão sendo alcançados. O PMO é a ligação natural
entre o portfólio, programas e projetos da organização, e dos sistemas
corporativos de avaliação (ex.: mapa estratégico). A forma, função e
estrutura do PMO dependem das necessidades da organização.

119
 Os riscos de a organização não discriminar adequadamente o tipo e a finalidade específica do
EGP são:
ambiguidade na definição de papel e responsabilidade;
mentalidade burocrática e tecnocrática, voltada para processos;
possibilidade de tornar-se um “multiplicador de erros” ao padronizar técnicas de
efetividade duvidosa;
resistência a controles pelos envolvidos gera ressentimentos;
dificuldade de avaliar o valor agregado do EGP frente aos custos fixos envolvidos e
perda da capacidade empreendedora, quando o EGP limita a expansão do número
de projetos.

Mais de um EGP
Muitas organizações tentaram mais de uma vez implantar um EGP antes de obter sucesso.
Há também as que têm mais de um EGP, provando a necessidade de distintos papéis, cada qual
desempenhado por um EGP. Quaisquer que sejam os tipos, os escritórios necessitam de sistemas
informatizados de apoio. É questão crucial para a gestão de múltiplos projetos.
Uma novidade promissora: muitas organizações recentemente optam por elevar o nível do
EGP. Ao invés de um EGP controlador, redefinem o EGP para a função de gestão de portfólio,
para priorizar e autorizar execução ao invés de elaborar relatórios de controle.
Qualquer que seja o tipo de EGP, é necessário homogeneizar a qualidade do gerenciamento
dos projetos, mas como fazer isso, se há tipos tão diferentes de projetos? O ideal é difundir na
organização uma metodologia suficientemente ampla e flexível, porém única, exigindo que cada
gerenciador de projetos selecione quais processos de gestão e instrumentos pretende usar no seu
projeto, sem abalar a necessidade de controle global dos investimentos.
Nos últimos anos, é notável a difusão de EGP nas organizações. Em muitos casos, parece até
um modismo, mas persiste a dúvida: criar estruturas permanentes, com elevados custos fixos, é
justificável? Ampliar controles, e não competências de gerenciadores, poderia ser de fato efetiva?

Competências em gestão de projetos

O que é especial merece tratamento especial
Antes de fazer esta disciplina, você havia sido educado no gerenciamento de projetos? A maioria
dos gestores que conheço assumiu responsabilidade por projetos antes de ser treinado no tema. Significa
que a maioria aprendeu “na raça” – contudo, esse é um aprendizado defensivo: aprenderam a se defender
de projetos, mas não a levá-los ao sucesso. Também aprenderam por tentativa e erro, e tiveram mais
erros que acertos, o que ainda é comum, e pouco sabem sobre como ser eficiente, eficaz e efetivo em
projetos. Vamos fazer uma avaliação das competências necessárias para o sucesso liderando projetos?

120
Um perfil especial de competências
Projetos são diferentes de processos. Projetos são desafios temporários, únicos e arriscados,
associados à inovação e mudança. Processos em geral são permanentes e contínuos; portanto,
remetem à melhoria incremental. Enquanto a gestão de processos é enfatizada na educação superior,
a gestão de projetos foi desenvolvida há 50 anos; portanto, ainda é pouco ensinada.
Por ser temporário, o projeto é gerido por uma equipe temporária, quase sempre
multidisciplinar, incluindo até pessoal externo. Os membros dessa equipe temporária raramente se
reportam ao gerenciador designado para o projeto. Isso cria uma situação em que esse gestor tem
perfil oposto ao de gestores com mentalidade hierárquica e burocrática.
Projetos têm incerteza e riscos elevados, o que remete a atitudes, capacidades e
conhecimentos especiais. Projetos em geral visam à mudança significativa, o que novamente
requer habilidades especiais.
Para tornar ainda mais difícil desenvolver competência em projetos, há um pressuposto de
que cada habilidade ou estilo pode demandar muito ou pouco tempo para o seu desenvolvimento.
O desenvolvimento exitoso requer disciplina.

Competências brandas e duras

De nada adianta dispor de metodologia, ferramentas e tecnologias de informação se a equipe
do projeto – e, em particular, o gerenciador que a lidera – não demonstrar as competências humanas
associadas ao objeto da sua atuação.
Competência é um termo controverso porque deriva do verbo competir. Os dicionários
explicam competência como: “faculdade concedida a; qualidade de quem é capaz de fazer algo;
habilidade; aptidão”, mas competência não é sinônimo de habilidade ou aptidão, é um termo mais
abrangente, porque é o que distingue o profissional dos seus pares e resulta em melhor desempenho.
Defino competência como o conjunto de qualificações em ação que promovem um desempenho distintivo
e superior visando a agregar valor ao realizado.
Postulo um conjunto de competências diretamente associado às características de projetos –
não poderia ser diferente. O quadro abaixo lista, à esquerda, as características de projetos e, à direita,
as competências associadas a cada atributo. Resulta em 50 competências. Com igual propósito, o
PMI,4 em norma específica sobre o tema, lista 129 competências (o que não significa uma lista mais
abrangente, mas apenas mais minuciosa) e o International Project Management Association (IPMA)5
europeu lista 28 macrocompetências.

4
PMI – Project Management Institute. Project manager competency development (PMCD) framework. Newtown: PMI, 2007.

5
IPMA – International Project Management Association. ICB – Individual Competence Baseline, version 4.0. Nijkerk: IPMA,
2015. Disponível em: <www.ipma.ch>.

121
 Atributos de
Competências do gerenciador associadas
projetos

1. proatividade (prontidão para agir mesmo em situações difíceis);

2. tenacidade: persistência e vitalidade;
3. autoeficácia: necessidade de conquista; crença no controle
esforços
sobre a sua vida;
desafiadores
4. excelência: ênfase em exceder ou superar resultados;
5. sensibilidade para qualidade;
6. capacidade empreendedora;

7. ênfase em resultados, e não no processo: “fazer acontecer”;

8. competência em estabelecer, mensurar e controlar objetivos;
temporários: com 9. habilidade em formar e desenvolver equipes temporárias;
ciclo de vida 10. habilidade em conceber organizações;
11. competência social: relacionamento, inteligência emocional;
12. liderança;

13. preferência pelo novo e pela inovação;

14. atitude de experimentação;
únicos ou
15. criatividade e flexibilidade mental;
extraordinários
16. resiliência elevada e baixa resistência a mudanças;
17. competência na formulação de estratégias;

18. temperança: capacidade de regular emoções;

19. sensibilidade para riscos;
riscos e incerteza 20. habilidade de identificar e quantificar riscos;
21. solução de problemas: habilidade em responder a riscos;
22. competência em elaborar planos contingenciais;

23. planejamento e controle;

24. ser organizado;
25. capacidade de coletar e processar informação esparsa como
recursos escassos
apoio a decisões;
26. capacidade analítica: estimar custos, recursos humanos e
financeiros;

122
 Atributos de
Competências do gerenciador associadas
projetos

27. auto e heteropercepção (defasagem entre como se vê e como

outros o veem);
28. capacidade de expressar e desenvolver comprometimento e
confiança;
29. empatia: capacidade de colocar-se no lugar do outro e sentir
como ele;
30. capacidade de mapear e gerir interessados;

múltiplos 31. competência em comunicação;

interessados 32. competência em influência, mais que em uso de autoridade e de
(stakeholders) poder coercitivo;
33. competência de negociação; habilidade política;
34. competência em gerir conflitos;
35. resiliência elevada: competência em gerir crises e mudanças;
36. otimismo aprendido: capacidade de contrapor emoções e
pensamentos negativos;
37. habilidade em lidar com diferenças culturais;
38. cultivar rede, articular apoio;

39. competência em formular normas e regulamentos

40. capacidade de desenvolver fornecedores
41. habilidade na preparação de editais, especificações e relatórios
relações formais
42. capacidade de julgamento e seleção
43. competência no controle de contratos
44. integridade e confiabilidade (compliance)

45. competência em tecnologias de informação e comunicação;

46. maestria em gestão;
competências 47. habilidade em coaching, mentoria ou aconselhamento;
técnicas 48. competência em ensinar e desenvolver pessoas e
49. domínio da tecnologia específica do campo de aplicação do
projeto.

Note que há poucas competências técnicas generalistas. Essa lista precisa ser complementada
caso a caso com competências técnicas especialistas, ou seja, específicas para o tema do projeto. Há
uma discussão interminável sobre a questão: o gerenciador de projetos deve ser um generalista ou um
especialista? Algum conhecimento técnico sobre o tema do projeto julgo relevante que ele disponha,
para que possa gerenciar melhor o projeto, mas a ênfase é nas competências generalistas – afinal, ele é
um gestor, acima de tudo.

123
 São tantas as competências que julgo necessário agrupá-las por outros critérios, visando a criar
estratégias para o seu desenvolvimento. A categorização que proponho classifica por dois critérios
que estabelecem quatro diferentes categorias de um gráfico. O eixo horizontal reparte as
competências entre aquelas padronizáveis porque resultam de processos definidos e aquelas em que
predomina o estilo autêntico e as atitudes. O eixo vertical reparte as competências fáceis e rápidas
de obter daquelas que requerem longo período de maturação.
Formam-se quatro quadrantes. O quadrante abaixo e à direita reúne as competências
padronizáveis de fácil desenvolvimento – competências PRÁTICAS. O acima e à direita reúne as
competências padronizáveis, porém de longa maturação – competências VIVENCIAIS. O abaixo
e à esquerda reúne as competências autênticas e pessoais de rápida apreensão – SAGACIDADE; o
acima e à esquerda contém as competências autênticas de longa maturação – SABEDORIA.
Distribuindo as 50 competências (exceto a última, que não cabe classificar) nos quatro
quadrantes, resulta a classificação apresentada na figura abaixo. Alerta: essa classificação não é
perfeita, depende do entendimento sobre cada competência listada. Por exemplo, na comunicação:
as técnicas de comunicação e apresentação julgo competências práticas; contudo, a arte da
comunicação, a oratória, eu classificaria como vivência.

124
 Note que os nove componentes da resiliência pertencem à sagacidade e sabedoria. A resiliência
capacita na gestão de crises, que se fosse listada estaria na mesma região. O mesmo se dá com
capacidade empreendedora, liderança e presença executiva. Há competências relacionadas à
sagacidade em que predominam atitudes, e isso é notável. Não são ensinadas na escola e requerem
tempo para evoluir.
As competências mais relevantes para lidar com projetos na sua maioria foram classificadas
nos quadrantes: sabedoria, vivência e sagacidade. Significa que a gestão de projetos requer longa
experiência e maturidade. Note que os exames de certificação e os treinamentos convencionais
enfocam apenas as competências práticas: um profissional de projetos aplica adequadamente as
técnicas, mas não obtém maior sucesso por falta dessas outras competências.
Vale ressaltar: a maioria do classificado como sabedoria e sagacidade são competências brandas,
aquilo que os norte-americanos denominam soft skills. Nas competências duras (hard skills),
prevalecem conhecimentos técnicos e habilidades complexas, predominantemente intelectuais. Nas
competências brandas, prevalecem atitudes (estilos) e comportamentos sociais.

Dicas para aprimorar competências

Todas as competências são desenvolvidas pela educação. As competências práticas e de
sagacidade envolvem cursos de curta duração, seja na educação formal (diplomas) seja na educação
não formal (certificados profissionais). As competências vivenciais e de sabedoria servem-se mais da
educação informal: autodesenvolvimento, estudo e coaching; subsidiariamente, elas podem servir de
educação não formal, porém em cursos não acadêmicos.
Note as diferenças: habilidades práticas são desenvolvidas em cursos de curta duração, com
conteúdos planejados e modelos educacionais (“pedagogias”) convencionais. Sagacidade pode ser
desenvolvida com cursos de sensibilização: reduzida duração, roteiro aberto e modelos participativos
(casos, jogos, vídeos). Habilidades vivenciais requerem cursos de longa duração e carga horária,
visando a sedimentar as vivências; portanto, com roteiro aberto e modelos participativos. Sabedoria
não se desenvolve em cursos, porque não existem; é necessário tempo de convivência, reflexão e
maturação – apenas o autodesenvolvimento, o estudo e mentores são eficazes.
Se a sua ênfase é na sagacidade e sabedoria, assuma esse compromisso na forma de um projeto,
e trilhe passo a passo o caminho da educação informal. Se a ênfase está nas vivenciais, crie projetos
de médio prazo e busque mais competências brandas que duras. No início de carreira, eduque-se
com as competências práticas – elas formam a base para a atuação profissional.

125
Dura uniformiza, branda diferencia
Não há oposição entre competências duras e brandas: quem deseja ser profissional do
gerenciamento de projetos precisa de ambas. As competências duras geram a disciplina de planejar,
documentar, decidir e comandar tão relevantes na gestão. As competências brandas geram o estilo
sagaz e sábio de lidar com a incerteza, riscos e relações humanas, sociais e políticas.
Contudo, as competências duras uniformizam; portanto, criam um padrão de gestão
profissional que iguala a todos os gestores. As competências brandas geram valor agregado e,
sobretudo, diferenciam gestores. Quanto mais competitivo o “mercado” de gestores de projetos em
uma organização, mais eles serão valorizados pelo domínio de competências brandas. Invista nas
suas competências!
Se ainda não se entusiasmou para desenvolver as suas competências como gestor de projetos,
deixe-me adicionar uma informação. Desde o início do século 21, as organizações perceberam que
a gestão de projetos é o repositório para a seleção e a educação de futuros diretores. Isso se deve ao
fato de que a mentalidade de projetos é mais próxima da de um diretor que a mentalidade de
gerentes. Se quiser chegar a diretor, invista na gestão de projetos.

126
BIBLIOGRAFIA
ABNT/CB-25 – Comitê Brasileiro da Qualidade. NBR ISO 10.006: gestão da qualidade – diretrizes
para a qualidade no gerenciamento de projetos. Rio de Janeiro: ABNT, 2000.

ARRUDA, M. C. C.; WHITAKER, M. C.; RAMOS, J. M. R. Fundamentos de ética empresarial e

econômica. São Paulo: Atlas, 2001.

BRESNEN, M.; GOUSSEVSKAIA, A.; SWAN, J. Organizational routines, situated learning and
processes of change in project-based organizations. PM Journal, p. 27-41, September 2005.

CARVALHO, M. M.; RABECHINI, R. Fundamentos em gestão de projetos: construindo

competências para gerenciar projetos. São Paulo: Atlas, 2011.

CASAROTTO, N. Projeto de negócio: estratégias e estudos de viabilidade – redes de empresas,

engenharia simultânea, plano de negócio. São Paulo: Atlas, 2002.

CHAPMAN, C. B. Project risk management: processes, techniques, and insights. London: John
Wiley, 1997.

COOKE-DAVIES, T. J. The real success factors on projects. International Journal of Project

Management, vol. 20, n. 3, p. 85-190, abr. 2002.

CRAWFORD, J. KENT. The strategic project office: a guide to improving organizational

performance. New York: Marcel Dekker, 2002.

FINOCCHIO JR., J. Project Model CANVAS: gerenciamento de projetos sem burocracia. Rio de
Janeiro: Elsevier-Campus, 2013.

FLEMING, Q. W.; KOPPELMAN, J. M. Earned value project management. Newtown Square:

PMI, 2000.

FRAME, J. D. The new project management: tools for an age of rapid change, corporate
reengineering, and other business realities. San Francisco: Jossey-Bass, 1994.

_______. Project management competence: building key skills for individuals, teams and
organizations. San Francisco: Jossey-Bass, 1999.

127
FREEMAN, R. Edward. Strategic management: a stakeholder approach. Boston: Pitman, 1984.

HIGHSMITH, J. A. Agile project management: creating innovative products. 2nd. ed. Boston:
Pearson Education, 2010.

JOHNSON, R. A.; KAST, F. E.; ROSENZWEIG, J. E. The theory and management of systems.
New York: McGraw-Hill, 1963.

KATZENBACH, J.; SMITH, D. The wisdom of teams: creating the high-performance

organization. EUA: Harper Business, 1994.

KEELING, R. Gestão de projetos: uma abordagem global. São Paulo: Saraiva, 2002.

KERZNER, Harold. Gestão de projetos: as melhores práticas. Porto Alegre: Bookman, 2002.

______; SALADIS, F. P. Gerenciamento de projetos orientado por valor. Porto Alegre: Bookman, 2010.

KLIEM, R. L. Reducing project risks. Aldershot: Gower House, 1997.

MAXIMIANO, A. C. A. Administração de projetos: como transformar ideias em resultados. São

Paulo: Atlas, 2002.

MENEZES, L. C. M. Gestão de projetos. São Paulo: Atlas, 2001.

MEREDITH, Jack R.; MANTEL, S. J. Project management: a managerial approach. New York:
John Wiley, 1985.

MINTZBERG, H. Criando organizações eficazes: estruturas em cinco configurações. São Paulo:

Atlas, 1995.

NONAKA, I.; TAKEUCHI, H. The knowledge-creating company: how Japanese companies create
the dynamics of innovation. New York: Oxford University Press, 1995.

OSTERWALDER, A.; PIGNEUR, Y. Business model generation: inovação em modelos de negócios.

Rio de Janeiro: Alta Books, 2011.

PMI – Project Management Institute. Practice standard for Work Breakdown Structures. 2nd ed.
Newtown Square: PMI, 2006.

128
______. Code of ethics & professional conduct. Newtown Square: PMI, 2007.

______. PMBOK Guide: um guia para o conjunto de conhecimentos em gerenciamento de

projetos. 5. ed. Newtown Square: PMI, 2013.

______. Guia PMBOK: um guia para o conjunto de conhecimentos em gerenciamento de projetos.

6. ed. Newtown Square: PMI, 2017.

PIDERIT, S. K. Rethinking resistance and recognizing ambivalence: a multidimensional view of

attitudes toward an organizational change. The Academy of Management Review, Mississippi State,
Oct. 2000.

PINCHOT III, G. Intrapreneuring: por que você não precisa deixar a empresa para tornar-se um
empreendedor. São Paulo: Harbra, 1990.

PINTO, J. K. Successful project managers: leading your team to success. New York: Van
Nostrand, 1995.

______. Power and politics in project management. Newtown Square: Project Management Institute,
1996.

PINTO, J. K.; TRAILER, J. W. Leadership skills for project managers. Newtown Square: PMI, 1998.

POLANYI, M. Personal knowledge: towards a post-critical philosophy. Chicago: The University of

Chicago Press, 1958.

SABBAG, P. Y. Espirais do conhecimento: ativando indivíduos, grupos e organizações. São Paulo:

Saraiva, 2007.

______. Gerenciamento de projetos e empreendedorismo. 2. ed. São Paulo: Saraiva, 2013.

______. Gerir projetos requer gerir conhecimentos. Mundo Project Management, p. 9-15,
junho/julho 2009.

SHUTERLAND, J. Scrum: a arte de fazer o dobro do trabalho na metade do tempo. 2. ed. São
Paulo: Leya, 2016.

129
SOLER, A. M. Gerenciamento de projetos: estudo de caso Rosalina e o Piano. 2. ed. São Paulo:
Brasport, 2015.

VALERIANO, D. L. Gerenciamento estratégico e administração por projetos. São Paulo: Makron, 2001.

WATERMAN JR., R. H. Adhocracia: o poder para mudar. São Paulo, Pioneira, 1992.

WIDEMAN, R. M. Project and program risk management: a guide to managing project risks and
opportunities. Newtown Square: PMI, 1992.

130
PROFESSOR-AUTOR
Paulo Yazigi Sabbag é doutor em Administração de Empresas pela EAESP/FGV (2002),
especialista em Grupos pela Sociedade Brasileira de Dinâmica dos Grupos (SBDG) (2012), mestre
em Engenharia Urbana e de Construção Civil (1986) e graduado em Engenharia Civil (1979) pela
Universidade de São Paulo. Atuou como vice-coordenador e responsável por cursos in company no
Programa de Educação Continuada (GVpec), da EAESP/FGV, de 1995 a 1999. Foi fundador e
dirigente do PMI em São Paulo, onde atuou desde 1996 e é certificado como Profissional de
Gerenciamento de Projetos (PMP), pelo PMI, desde 1998. Atualmente, é professor da FGV desde
1988, co-coordena o curso de Gerenciamento de Projetos desde 1989 e dirige a Sabbag Consultoria
desde 1993 e a Zagaz Aprendizagem Digital desde 2016. Autor dos livros: Resiliência, competência
para enfrentar situações extraordinárias na vida profissional, pela editora Campus Elsevier (hoje
Altabooks), em 2012 (recebeu o Prêmio Jabuti 2013); Gerenciamento de Projetos e
Empreendedorismo, pela editora Saraiva, em 2013 (com mais de 25.000 exemplares vendidos em
duas edições) e Espirais de Conhecimentos, pela editora Saraiva, em 2007 (entre os finalistas para o
Prêmio Jabuti 2008).

131