Curso GP

Gerenciamento de Projetos
na opinio de um Gerente de Projetos
J. R. B. Mendes
Pgina 1 de 190
Sobre o Autor
Joo Ricardo Barroca Mendes Bacharel em Informtica pela Universidade Federal
Fluminense e possui MBA Executive (Managers & Directors) pela Fundao Getlio
Vargas. Possui mais de dez anos de experincia em projetos de desenvolvimento de
sistemas. Tem artigos publicados sobre temas ligados a projetos na rea de informtica.
membro do Project Management Institute e consultor TOC especialista em Critical Chain.
E-mail: jrbmendes@ig.com.br
Pgina 2 de 190
1 Apresentao
1.1
Abordagem do Curso- Teoria e Pratica do Gerenciamento de Projetos
Gerenciar projetos no uma tarefa fcil. Vamos repetir isto algumas vezes ao longo deste
texto. Mas ela pode ser imensamente facilitada pela abordagem correta dos problemas
inerentes.
freqente que um profissional seja catapultado posio de liderana de um projeto sem ter
qualquer treinamento a respeito, simplesmente porque tem conhecimento do assunto que o
projeto envolve. Voc conhece bem Informtica, certo ? Estamos implantando um ERP e
precisamos de algum que coordene o trabalho dos consultores. Todo mundo est ocupado e
estou passando esta atribuio para voc. Por isto, gerncia de projetos conhecida como a
profisso acidental. Poucas pessoas saem da universidade prevendo um futuro como Gerente
de Projetos. Elas acabam sendo envolvidas no que parece ser uma oportunidade
interessante. Mas boa vontade e capacidade tcnica raramente so suficientes e o fracasso
comum.
Diante disto, seria de se esperar que o treinamento formal nas tcnicas de gerenciamento de
projetos melhorasse tremendamente o resultado dos projetos. Mas isto nem sempre
verdade. Muitos tericos, diante das dificuldades de um tema to rico, tentaram simplesmente
contorn-las, no querendo admitir uma realidade to complexa e querendo obter apenas
resultados certos e positivos. Eles s tomaram em considerao os dados calculveis,
rejeitando tudo que no pudessem quantificar e se dedicaram a criar uma grande quantidade
de receitas simples, detalhadas e precisas, mesmo quando completamente afastadas da
realidade.
O resultado que muitas falhas ocorrem pela inadequao destes conselhos tericos a uma
realidade prtica especfica. Muitos cursos e livros sobre gerenciamento de projetos parecem
carecer de qualquer contato com a realidade do mercado e da diversidade das culturas
organizacionais. As solues prontas, as balas de prata contra problemas considerados
clssicos, acabam diminuindo a eficincia da equipe em vez de aument-la.
Quando trabalhamos em projetos estamos sob o domnio do acaso. A incerteza faz com que o
Gerente de Projetos sempre se depare com uma realidade diferente daquela que esperava.
certo que isto deveria se refletir nos planos e mais ainda nas idias que neles se integram.
A ortodoxia no suficiente. A prtica no suficiente. preciso conhecer os princpios que
modelam as tcnicas. Conhecendo os princpios, o Gerente de Projetos poder desenvolver
suas prprias solues. Ele deve saber que a incerteza no afeta igualmente todas as
atividades no projeto. Existem determinados fatores razoavelmente confiveis. Em outros
pontos, porm, ele deve recorrer a seu talento e intuio.
A abordagem deste curso tenta abranger tanto a dimenso prtica quanto a dimenso terica
do gerenciamento de projetos, sempre questionando os princpios bsicos dos pressupostos
empregados. Tentaremos mostrar a arte e a cincia do gerenciamento de projetos,
procurando capacitar o estudante a desenvolver seu prprio estilo gerencial, ao mesmo tempo
em que aplica as prticas consagradas de Gerenciamento de Projetos. No iremos mostrar
menos teoria. Na verdade procuraremos mostrar mais. A suposta lacuna entre a teoria e a
prtica devido pretenso da primeira em governar a segunda nos seus detalhes. Quando
ela forma o esprito do profissional, facilitando sua compreenso dos fatos e diminuindo a
durao de seu aprendizado, ela cumpre um papel insubstituvel.
Pgina 3 de 190
Este curso se apoiar, ainda que de maneira crtica, no PMBOK Guide (A Guide to the
Project Management Body of Knowledge). Este guia, do qual falaremos em detalhes mais
tarde, lista as prticas consagradas pela comunidade e pelo tempo. Ele a referncia mxima
da ortodoxia. No entanto, vez por outra, o texto passar uma abordagem mais pessoal, fruto
de nossas experincias e opinies. Quando ocorrer divergncia entre as prticas clssicas e a
abordagem do curso, o texto deixar isto claro. Esta abordagem mista da ortodoxia, analisada
e questionada, com uma experincia singular, tem a pretenso de cobrir a indesculpvel
lacuna entre a bibliografia terica e a dura realidade das trincheiras.
1.2
Nota sobre o Uso de Termos em Ingls
Neste texto abundam expresses em ingls e como a utilizao de termos estrangeiros tem
merecido crticas exaltadas, creio ser prudente a colocao dos motivos:
! Quase a totalidade da bibliografia disponvel est em ingls. Qualquer um que no
esteja familiarizado com os termos, certamente, ter dificuldades em utiliz-la;
! No existe uma posio oficial quanto traduo e muitos termos podem ser
traduzidos de maneiras diferentes por diferentes autores. Isto no contribui em nada
para a divulgao do conhecimento;
! Peo perdo aos defensores da lngua ptria, mas existem palavras impossveis de
serem traduzidas. Stakeholder um exemplo. Algumas tentativas foram: partes
envolvidas, interessados, acionistas, entre outras. Nenhuma delas consegue captar
a idia de quem segura um pedao do projeto, sendo, bem ... um Stakeholder;
! O conhecimento sobre gerenciamento de projetos foi e permanece sendo quase que
totalmente gerado fora do Brasil. O argumento contrrio importao de termos
parece perder a fora diante da importao de toda uma cultura;
! Este livro fala muito da experincia pessoal do autor em gerenciamento de projetos. Eu
aprendi os termos em ingls e todos com que eu convivo utilizam os termos nesta
lngua. Eu me utilizo deles em meu dia a dia e me sinto mais confortvel com eles.
Acredito ser mais honesto utiliz-los tambm aqui.
No entanto, os termos estrangeiros sempre aparecero ressaltados por aspas, juntamente
com uma traduo e/ou um termo equivalente em portugus. Espero ser relevado por aqueles
que no se convenceram com meus argumentos.
1.3
Breve Histria da Gerncia de Projetos
O que um projeto? Um projeto academicamente definido como: um empreendimento

temporrio, de elaborao progressiva, com o objetivo de criar um produto ou servio nico.
Esta definio bem abrangente. Quase tudo que os seres humanos fazem pode ser, de uma
forma ou de outra, coberto por ela. O livro do Gnese nos mostra um impressionante gerente
de projeto criando o Universo e seguindo fases bem definidas. Na verdade, temos um projeto
terminado antes de um prazo impossvel de sete dias e que possibilitou um dia de descanso
para a equipe. Com um pouco de flexibilidade, a maternidade tambm pode ser classificada
como um projeto de 9 meses, que cria um produto nico, um ser humano. A verdade que
projetos existem desde que a humanidade surgiu... talvez antes.
Gerenciar os projetos talvez seja uma inveno mais recente. No livro de So Lucas, temos a
seguinte citao:
Quem de vs, com efeito, querendo construir uma torre, primeiro no se senta para calcular
as despesas e ponderar se tem com que terminar?
No acontea que, tendo colocado o alicerce e no sendo capaz de acabar, todos os que
virem comecem a caoar dele.
Evangelho de Lucas 14:28-29
Pgina 4 de 190
Se esta passagem d algumas recomendaes bsicas sobre gerenciamento de projetos, ela
tambm sugere que, com freqncia, os empreendedores passam por cima de tais
recomendaes e acabam por merecer o deboche de seus pares.
Procurando na histria, uma das primeiras evidncias de grandes projetos se encontra s
margens do Nilo. Infelizmente, no conhecemos muito sobre as tcnicas de projeto dos
antigos egpcios. Talvez aprendssemos que multas de vinte chibatadas so um meio
eficiente de garantir a entrega de suprimento no prazo estipulado. Nunca saberemos com
certeza.
As catedrais medievais eram feitas seguindo um certo nvel de planejamento. No possvel
realizar obras de certo tamanho totalmente pela intuio. Porm este planejamento raramente
era adequado ou suficiente e os projetos de construo de catedrais sofriam, alguma vezes,
de atrasos medidos em dcadas ou mesmo sculos. Felizmente os gerentes de projetos
eventualmente morriam juntamente com os patrocinadores originais, de modo que ningum
ficava com a sempre desagradvel tarefa de explicar um atraso deste tamanho.
Normalmente se reconhece que o moderno gerenciamento de projetos comeou com o
Projeto Manhattan, que desenvolveu a bomba atmica e com os projetos militares durante a
guerra fria, como o do submarino Polaris. Afinal, matar gente coisa sria e guerras no
esperam negociaes de prazos de entrega. De fato, se a concluso do projeto da bomba
atmica tivesse sido adiada por alguns meses talvez os japoneses tivessem se rendido e ela
no tivesse sido utilizada.
Se, nestes tempos iniciais, as tcnicas de gerenciamento de projeto desenvolvidas pelos
militares eram usadas apenas para estes enormes projetos de pesquisa e desenvolvimento,
pouco a pouco as empresas privadas de construo foram descobrindo os benefcios de
utiliz-las em projetos relativamente menores, como construir um prdio ou uma ponte.
Atualmente, gerenciamento de projetos est na moda e no sem razo. Cada vez mais as
empresas esto enfrentando presses competitivas. Neste cenrio, basta que uma empresa
competidora consiga otimizar os projetos em que participa para que a gerncia geral perceba
que no pode continuar a controlar os seus prprios de maneira amadora.
bem conhecida a figura do responsvel por projetos que afirma no ter tempo a perder com
planejamento e controle. Eles agitam toda a equipe, movem cus e terras para comear as
atividades o mais rapidamente possvel e conseguem at alguns resultados. Mas logo se
percebe o custo disso e, neste tipo de coordenao, projetos acabam custando o triplo do
preo, levando o dobro do prazo e entregando um produto com metade das necessidades dos
usurios.
Boa gerncia de projetos possvel mesmo com prazos apertados. Na realidade quando ela
mais necessria. A experincia demonstra isso. Uma certa criatividade e adaptao das
tcnicas, porm, sempre recomendvel.
1.4
Caractersticas de um Projeto
Pense no trabalho desenvolvido em uma organizao. Existem aquelas tarefas rotineiras,

servios continuados que compem a espinha dorsal da maioria das empresas produtivas.
Todo o resto projeto.
Vamos rever nossa definio:
Um projeto um empreendimento temporrio, de elaborao progressiva, com o objetivo de
criar um produto ou servio nico.
Pgina 5 de 190
1.4.1 Temporrio
Tudo na vida temporrio, claro, porque tudo termina, mais cedo ou mais tarde. Fbricas
so inauguradas e, aps algum tempo, fechadas. Empresas eventualmente vo a falncia. At
mesmo pases, como vemos freqentemente na Europa, nascem e morrem.
As operaes continuadas, ou seja, tudo que no projeto, normalmente traam objetivos que
se renovam. Uma empresa tem como objetivo dar lucro todo ano. Ningum fecha as portas de
uma empresa lucrativa por um esprito de misso cumprida. As organizaes tm o propsito
da continuidade. Seu fim um mero acidente.
Por outro lado, projetos tm um incio e um fim muito bem definidos. Comea-se um projeto
para alcanar um conjunto de objetivos e ele chega ao fim, se tudo correr bem, quando estes
objetivos forem alcanados. Anormalmente, ele pode ser encerrado porque se acredita que o
projeto no ser capaz de atingir seus objetivos ou porque os prprios objetivos da
organizao mudaram. O que certo que a organizao tem a inteno de que o projeto
eventualmente se encerre, de uma maneira ou de outra.
Ser temporrio no significa gerar efeitos temporrios. Os efeitos ou produtos do projeto
podem ter a caracterstica de serem continuados. O projeto de instalao de uma fbrica
temporrio. A fbrica em si uma organizao no temporria.
Ser temporrio tambm no significa ser de curta durao. No existe um limite mnimo ou
mximo para a durao de um projeto. Um pequeno projeto pode durar uma semana
enquanto que o projeto de levar o homem a Lua durou anos. Alguns projetos podem durar
dcadas, ainda assim eles so temporrios. Podemos antecipar o momento em que os
objetivos sero alcanados e eles sero encerrados.
1.4.2 Produto ou Servio nico

Alem de temporrio, um projeto nico. No existem dois iguais. Mesmo que seja possvel
utilizar os mesmos planos e os mesmos fornecedores para desenvolver um produto
semelhante, como, por exemplo, construir dois prdios com as mesmas plantas, cada projeto
um evento singular. Os dois prdios podem ser semelhastes, mas ainda sero distintos. Um
pode ser entregue dento do prazo e do oramento e o outro ficar inacabado porque a
construtora faliu.
Cada projeto nico e produz algo nico. A existncia de fatores semelhantes no muda a
caracterstica intrnseca de unicidade do projeto.
1.4.3 De Elaborao Progressiva

Cada projeto , pelo menos em parte, um ato de criao.
Idealmente, o escopo do projeto, ou seja, a definio do trabalho a ser realizado, deve
permanecer constante. Isto garantiria certa estabilidade ao projeto. No entanto, mesmo que
isto ocorra, nosso conhecimento sobre este escopo no constante.
No incio do projeto, as descries de caractersticas do produto e de como iremos produzi-lo,
por mais detalhadas que sejam, so apenas um primeiro esboo. Como o produto de cada
projeto nico, as caractersticas que o distinguem devem ser progressivamente elaboradas.
Conforme o projeto se adianta, nosso conhecimento aumenta e tomamos decises que
aperfeioaro este esboo.
Elaborar significa trabalhar com cuidado e detalhe at que o trabalho esteja completo. Nos
projetos, esta elaborao progressiva, no sentido de que procede por etapas, por
incrementos definidos.
Pgina 6 de 190
1.5
O que Gerenciamento de Projetos
Se um projeto caracterizado por seus objetivos, gerenciamento de projetos a arte de

atingir ou exceder as expectativas e necessidades vinculadas ao projeto. Para esta meta,
devem-se aplicar os conhecimentos, habilidades e tcnicas disponveis. Tudo que pode
aumentar as chances de sucesso do projeto pode ser classificado como Gerncia de Projetos.
Os limites so nebulosos e existe intercesso da Gerncia de Projetos com uma enorme
quantidade de reas de conhecimento. Estes conhecimentos podem ser organizados em
muitas formas e, como em toda rea da administrao, h teorias conflitantes. Ao conhecer a
ortodoxia e tomar contato com as opinies de outros gerentes de projetos, o Gerente de
Projetos pode adapt-los e, to importante quanto, contribuir para sua evoluo.
O gerenciamento de projetos no um corpo de conhecimento exclusivo para os Gerentes de
Projetos. De fato, quanto mais a equipe, ou o cliente do projeto, souber sobre o assunto,
maiores so as chances de sucesso. Se os profissionais souberem para que serve a
informao que eles devem reportar, maior a possibilidade deles reportarem corretamente.
Se eles entenderem os problemas, podero ter idias e contribuir para as solues.
A interao do gerente de projeto com a equipe particularmente importante porque,em
nossa opinio, na maioria dos projetos, a caracterstica bsica na aplicao do conhecimento
disponvel no est na criao de um planejamento perfeito e na sua execuo exata, mas na
elaborao progressiva de uma tarefa conjunta.
1.6
Tipos de Projetos
Projetos podem ser classificados arbitrariamente de diversas formas. Duas formas de

classificao so interessantes para nossa anlise. Uma diz respeito ao escopo do projeto,
que pode ser descrito como abstrato ou como concreto.
Projetos com escopo concreto incluem coisas como a troca de um componente de uma planta
industrial ou a construo de uma ponte. Nestes casos, o escopo pode ser definido, a priori,
em detalhes. Podem surgir alguns imprevistos mas, a principio, as tarefas necessrias podem
ser previstas com grande preciso.
O extremo oposto so os projetos com escopo abstrato. Escrever um livro um exemplo.
Projetar mudanas que melhorem a eficincia de uma linha de fabricao outro. Nestes
casos, temos um objetivo claro, seja a criao do livro ou a melhoria de um indicador. Mas
deste objetivo no pode ser diretamente derivado o procedimento detalhado para que ele seja
atingido. Nestes casos, a medida em que o projeto avana, tomamos decises que tornam o
escopo cada vez mais concreto, at que, por fim, obtemos o resultado.
necessrio compreender que estas diferenas so inatas ao tipo de escopo e no
dependem de qualquer escolha que o gerente de projetos faa. De certa maneira um escopo
concreto reduz a possibilidade de escolhas enquanto que um escopo abstrato permite
solues completamente diferentes sejam igualmente satisfatrias.
Uma outra classificao que devemos ter em mente diz respeito ao tipo de atividades que so
executadas durante o projeto. Cada tarefa pode ser do tipo criativa ou do tipo procedimental.
As tarefas procedimentais so aquelas que podem ser executadas seguindo uma seqncia
de passos bem determinada. Erguer uma parede de tijolos ou coletar dados sobre um
processo de fabricao so exemplos de tarefas procedimentais.
Tarefas criativas envolvem a necessidade do engenho humano. Escrever o captulo de um
livro ou decidir as linhas arquitetnicas de uma estrutura so tarefas criativas.
De um modo geral, projetos de escopo abstrato tendem a ter uma nfase maior em tarefas
criativas enquanto projetos de escopo concreto possuem tarefas altamente procedimentais e
bem conhecidas.
Pgina 7 de 190
Obviamente, estas classificaes so apenas exemplos de um contnuo de possibilidades.
Muitos projetos ocupam posies intermedirias com relao ao tipo de escopo e aos tipos de
tarefas executadas. O importante que se reconhea as caractersticas especficas de cada
projeto, e que o planejamento e execuo estejam de acordo com as necessidades para cada
caso.
1.7
Estilos de Gerenciamento de Projetos
Existem dois extremos de estilos de gerenciamento de projetos. Chamaremos estes dois

extremos de Ad-Hoc e Comando e Controle.
A maioria dos projetos dentro das empresas acabam sendo gerenciados da maneira Ad-Hoc.
Nestes casos, o gerente de projetos utiliza pouca ou nenhuma das tcnicas ortodoxas de
gerenciamento. O projeto evolui por meio de impulsos peridicos para uma direo geral.
Normalmente, a rotina se segue na convocao de reunies, distribuio de tarefas, novas
reunies para avaliao do status, redistribuio de tarefas e assim por diante. Cronogramas
so raros e o formalismo nenhum.
Usando uma figura simples, podemos ilustrar as formas Ad-Hoc de gerenciamento de
projetos imaginando um capito portugus no sculo XVI. Uma vez tendo recebido do Rei a
misso de chegar ao Brasil e tendo uma idia geral de que o Brasil ficava a sudoeste, nosso
capito AD-Hoc se jogaria ao mar imediatamente. Evidentemente, a menos que contassem
com muita sorte e com tripulaes excelentes, poucos destes capites chegariam ao destino.
Apesar disto, alguns destes gerentes de projeto conseguem chegar at o final de seus
projetos e o sucesso acaba perpetuando o mtodo, mesmo que o sucesso seja totalmente
acidental. No entanto, temos que reconhecer que pequenos projetos de escopo abstrato e
tarefas criativas podem ser gerenciados desta forma de maneira bastante eficiente e com
certa economia de esforos.
No outro extremo, temos a mentalidade de Comando e Controle que fomenta a separao
entre pensamento e ao. Primeiro voc pensa e planeja e depois voc executa o que foi
planejado. Esta seria uma estratgia perfeita em um mundo absolutamente racional, ou
racionalizvel, mas feliz ou infelizmente a realidade no colabora.
Um capito Comando e Controle pediria ao Rei detalhes sobre a costa brasileira e em que
lugar ele deveria aportar, quanto tempo ele deveria ficar naquela terra e o que deveria fazer
enquanto estivesse l. Depois ele se recolheria com um grupo de especialistas na Escola de
Sagres, estimaria as coordenadas da costa brasileira e criaria um curso em linha reta para o
Brasil. Aps anos de preparao cuidadosa, ele partiria com duas caravelas extras para
mantimentos de contingncia. Este capito ignoraria as correntes martimas que encontrasse
pelo caminho, quando elas no constassem do seu planejamento. Talvez ele acabasse
destroado por uma tempestade que poderia ter sido contornada, se a alternativa de alterar o
curso original no fosse impensvel.
Este tipo de gerente de projetos pode ter mais sucesso que o primeiro, mas com uma
sobrecarga brutal de custo e esforo. Sabemos que a capacidade de abandonar ou refazer
planos pode ser to crucial quanto a responsabilidade em produzi-los. O estilo Comando e
Controle parece ser aplicvel de forma eficiente em projetos com escopo concreto e tarefas
procedimentais. O grau de previsibilidade destes projetos parece favorecer a separao entre
planejamento e execuo.
Estes estilos so casos extremos, mas talvez por contraste com o uso do estilo Ad-Hoc,
muitos autores ortodoxos parecem recomendar o estilo Comando e Controle. No entanto,
para a maioria dos projetos, o sucesso no gerenciamento de projetos parece vir mais da
capacidade de ajustar constantemente seu planejamento realidade do projeto, sempre
marcando sua posio na rota planejada, mas estando disposto a aproveitar as correntes e
desviar de tempestades, do que de uma habilidade fantstica de planejamento e disciplina de
execuo.
Pgina 8 de 190
O estilo exato de quanto esforo de planejamento e quanta flexibilidade o gerente deve
promover dependem do tipo de projeto, mas, muito raramente, uma nfase total na execuo
do estilo Ad-Hoc ou no planejamento detalhado em minutos do estilo Comando e Controle
sero as respostas.
Uma histria curiosa parece ilustrar a situao que muitos gerentes de projetos acabam se
encontrando. Consta que uma unidade militar hngara saiu em patrulha nos Alpes e no
voltou por dois dias. No terceiro dia, porm, eles apareceram e se apresentaram para seu
comandante.
Eles reportaram que foram pegos por uma tempestade de neve e, devido baixa visibilidade,
se perderam. Em certo ponto, eles se deram por acabados e se prepararam para morrer. Mas
um deles, subitamente, lembrou de que possua um mapa em seu bolso. Isso os acalmou e
eles montaram acampamento at a tempestade passar. Como no sabiam onde estavam, o
dono do mapa teve alguma dificuldade inicial, mas acabaram por encontrar um marco
conhecido e seguiram o caminho para casa. Impressionado com a histria, o comandante
pediu para ver o miraculoso mapa e, para seu espanto, descobriu que se tratava de um mapa
dos Pirineus e no dos Alpes.
Este caso um tanto forado, reconheamos, mas a unidade de propsitos e a coordenao
de esforos podem obter resultados mesmo quando o planejamento original se mostra falho.
O mesmo no se pode dizer da situao contrria. Por outro lado, sem um mapa, ou seja, sem
algum tipo de planejamento, a unidade de propsitos dificilmente conseguida.
Pgina 9 de 190
2 Introduo ao PMBOK
2.1
O que o PMBOK ?
O Project Management Institute a maior organizao mundial especializada em

gerenciamento de projetos e faz um trabalho de classificao e divulgao do conhecimento
existente sobre o assunto. O PMI chama este conhecimento de Project Management Body of
Knowledge ou, de forma mais curta, o PMBOK.
Este PMBOK abstrato, que est na mente coletiva da comunidade do PMI, foi encarnado em
uma publicao. A ultima verso foi lanada no ano 2000 e chamada de PMBOK Guide.
O PMBOK Guide foi construdo para ser uma referncia dos processos e prticas que so
geralmente aceitos pela comunidade, ou seja, aqueles que so considerados aplicveis
maior parte dos projetos, na maioria das vezes e em que h um razovel consenso de seu
valor e utilidade.
O PMBOK Guide representa a ortodoxia do Gerenciamento de Projetos, no entanto, este
termo no deve ser entendido com uma conotao negativa. A ortodoxia necessria como
uma referncia para o progresso. Tcnicas consideradas hoje como radicais, se passarem no
teste do tempo, acabaro se tornando parte da ortodoxia. O PMI continua evoluindo o
PMBOK Guide.
2.2
Processos de Gerenciamento de Projetos
Um processo uma srie de aes que geram um resultado. Um projeto naturalmente

decomposto em processos. Afinal, um projeto inteiro composto por uma srie de aes que
(se tudo correr bem) geram como resultado um produto ou servio. H dois tipos bem
diferentes de processos em um projeto, mas existe alguma confuso entre eles,
principalmente no que diz respeito definio de responsabilidades. freqente que pessoas
treinadas para um tipo de processo acabem por ficar a cargo do outro, nem sempre com bons
resultados. Os dois tipos so:
! Processos orientados ao produto Estes processos so a razo de ser do projeto.
Compem as atividades que especificam, criam e validam o produto ou servio que o
projeto deve produzir. Estes processos devem ser executados por especialistas no
produto ou servio. Conhecimento tcnico o requisito para os profissionais
responsveis;
! Processos de gerenciamento do projeto Este processos tornam possveis os
processos acima. Eles focam a organizao, a descrio e o controle do trabalho no
projeto. Os profissionais responsveis por este tipo de processo devem ter
caractersticas como: organizao, liderana, capacidade de negociao etc. Estas
caractersticas so muito diferentes do perfil tcnico dos processos de produto;
Embora seja possvel, no freqente que um excelente tcnico tenha tambm um excelente
perfil gerencial. Mesmo que ele seja bom em ambos, ao tentar compartilhar seu tempo entre a
resoluo dos problemas tcnicos e coisas como gesto de conflitos ou administrao de
recursos, algo sempre deixado de lado. A exceo a este caso normalmente feita para
projetos pequenos.
As tcnicas de gerenciamento de projetos so essencialmente as mesmas no importando se
o projeto trata da elaborao de uma nova verso de um software ou da construo de uma
ponte. Em tese, um gerente de projeto experiente poderia liderar ambos os projetos. Na
prtica, o total desconhecimento tcnico torna-se uma barreira de comunicao com a equipe
e freqentemente leva a decises equivocadas por parte do gerente de projeto. Assim, um
Pgina 10 de 190
gerente de projeto com formao em engenharia, que tenha experincia construindo pontes,
poderia liderar o projeto de construo de um prdio, mas teria que ser muito bem
assessorado para ter sucesso liderando um projeto de pesquisa de novos medicamentos.
A lista de processos recomendados pelo PMI para um gerenciamento de projetos bem
sucedido encontrada no PMBOK Guide. Existem vrias maneiras de organizar este
conhecimento. O PMBOK Guide utiliza duas formas simultneas de organizao: Grupos de
Processos e reas de Conhecimento. Veremos as duas organizaes, mas antes vamos olhar
um processo isolado.
Pgina 11 de 190
2.3
Exemplo de um Processo de Gerenciamento
Dentro do PMBOK , cada um dos processos merece uma ateno especial e analisado em
detalhes O contedo da caixa abaixo foi extrado da verso 1996 e d uma amostra de como
um processo descrito.
5.4 Verificao do Escopo

A verificao do escopo o processo de formalizao do aceite do escopo do projeto pelos
Stakeholders (sponsor, cliente etc.) . Isto exige a reviso dos produtos, deliverables e
resultados do trabalho de modo a garantir que tudo fra produzido de forma correta e
satisfatria. Se o projeto terminar antes do previsto, o processo de verificao do escopo deve
estabelecer e documentar o nvel e a extenso do que for realmente produzido. A verificao
do escopo difere do controle da qualidade (descrito na Seo 8.3) no sentido de que
primariamente preocupada com a aceitao do resultado do trabalho enquanto o controle da
qualidade primariamente preocupado com a conformidade e correo dos resultados do
trabalho.
Entradas
Entradas
..
11RResul
tt
ados
ho
esul
adosdo
doTr
Trabal
abal
ho
Ferramentas
Ferramentas ee Tcnicas
Tcnicas
..
11 II
nspeo
nspeo
Sadas
Sadas
..
11Acei
tt
ao
Acei
aoFor
Formm al
al
..
22DDocum
ao
oo
ocument
ent
aodo
doPr
Produt
odut
5.4.1 Entradas para a Verificao do Escopo

.1 Resultados do Trabalho. Os resultados do trabalho quais deliverables foram total ou
parcialmente completados, que custos tm sido incorridos ou comprometidos, etc so
sadas da execuo do plano do projeto (discutido na Seo 4.2)
.2 Documentao do produto. Os documentos produzidos para descrever os produtos do
projeto devem estar disponveis para reviso. Os termos usados para descrever esta
documentao (planos, especificaes, documentao tcnica, desenhos etc) variam de
acordo com a rea de aplicao.
5.4.2 Ferramentas e Tcnicas para a Verificao do Escopo
.1 Inspeo. A inspeo inclui atividades tais como medio, exames e testes executados
para determinar se os resultados esto de acordo com os requerimentos. As inspees
podem ser chamadas de revises, revises de produto, auditoria ou walkthroughs,
dependendo da rea de aplicao. Em algumas reas de aplicao esses diferentes termos
tm significados diferentes e especficos.
5.4.3 Sadas da Verificao do Escopo
.1 Aceitao Formal. A documentao de que o cliente ou sponsor aceitou o produto do
projeto ou da fase deve ser preparada e distribuda. Tal aceitao pode ser condicional,
especialmente no fim de uma fase.
Pgina 12 de 190
2.4
Grupos de Processos
Projetos tm uma seqncia temporal. Eles tm incio, meio e fim. Uma das maneiras que
podemos organizar os processos de gerenciamento em grupos executados mais ou menos
simultaneamente, ou em conjunto, durante o projeto. Existem cinco grupos, cada um com um
ou mais processos. So eles:
! Processos de Iniciao - neste grupo est o processo que reconhece que um projeto
ou fase deve comear e gerar o comprometimento necessrio para execuo;
! Processos de Planejamento - neste grupo esto os processos que planejam e
mantm um esquema de trabalho vivel para se atingir os objetivos do projeto;
! Processos de Execuo - este grupo de processos que coordenam pessoas e outros
recursos para realizar o plano estabelecido. No devem ser confundidos com os
processos orientados ao produto. So processos de gerenciamento de execuo;
! Processos de Controle - neste grupo esto os processos que asseguram que os
objetivos do projeto esto sendo atingidos. Eles monitoram e avaliam o progresso e
tomam aes corretivas;
! Processos de Encerramento - este grupo formaliza a aceitao do projeto ou da fase
do projeto, alm de promover outras atividades de encerramento;
Os grupos de processos so uma abstrao til, assim como os processos em si. H uma
srie de interaes entre eles. No raro, por exemplo, que em um mesmo momento seja
feito o controle de uma atividade, a deteco de um problema e o replanejamento do projeto,
fruto de uma ao corretiva.
Sobre isto o PMBOK Guide tem a dizer:
Os grupos de processos se ligam pelos resultados que produzem o resultado ou sada de
um grupo torna-se entrada para outro. Entre grupos de processos centrais, as ligaes so
iterativas - o planejamento alimenta a execuo, no incio, com um plano do projeto
documentado, fornecendo, a seguir, atualizaes ao plano, na medida em que o projeto
progride.
Relacionamentos entre Grupos de Processos
Processos de
Iniciao
Processos de
Controle
As setas representam
fluxos de documentos e
itens documentveis
Processos de
Planejamento
Processos de
Execuo
Processos de
Encerramento
Assim, os grupos de processos no devem ser vistos de maneira separada ou descontnua.

No se trata de atividades executadas uma nica vez e depois encerradas. Na verdade, elas
se estendem por todo o projeto e se sobrepem. O que varia a intensidade. No incio do
projeto, temos uma nfase nos processos de Iniciao e, logo a seguir, nos de Planejamento.
Pgina 13 de 190
No entanto, podemos ter atividades de iniciao, por exemplo, quando o projeto muda de fase,
em um momento em que j estamos em plena execuo.
O grfico abaixo procura demonstrar esta sobreposio e mudana de nfase que ocorre em
cada fase e, em um nvel maior, no projeto como um todo. Mas, tambm ele, mostra uma
viso um tanto idealizada do projeto. Como em um fractal, este padro se repete ao nvel do
projeto, das fases e at das tarefas detalhadas.
Sobreposio dos Grupos de Processos

Processos de
Execuo
Processos de
Planejamento
Nvel de
Atividade
Processos de
Iniciao
Processos de
Encerramento
Processos de Controle
Incio
da
Fase
Fim
da
Fase
Uma outra forma de visualizar como os grupos de processo interagem reconhecer que uma
fase fornece uma entrada para o incio da prxima. Por exemplo, a finalizao de uma fase de
design requer uma aceitao, pelo cliente, do documento de projeto. Isto, por sua vez, permite
que a fase de Implementao se inicie.
Interao entre as Fases
Fase de Design
Iniciao
Fases
Anteriores
...
Planejamento
Fase de Implementao
Iniciao
Controle
Planejamento
...
Execuo
Fases
Subseqentes
Controle
Execuo
Encerramento
Encerramento
A repetio dos processos de iniciao, no incio de cada fase, auxilia a manuteno do

projeto focado nas necessidades de negcio que justificaram a sua criao. Tambm permite
que o projeto seja interrompido ou radicalmente modificado, caso os objetivos do negcio
tenham mudado, ou se o projeto tornou-se incapaz de satisfaz-los.
Pgina 14 de 190
2.5
reas de Conhecimento
Os mesmos processos de gerenciamento podem ser classificados por reas de conhecimento.

Estas renem os processos pela afinidade de suas atividades. So nove, a saber:
! Gerncia da Integrao do Projeto - descreve os processos necessrios para
assegurar que os diversos elementos do projeto sejam adequadamente coordenados.
Ele composto pelo desenvolvimento do plano do projeto, execuo do plano do
projeto e controle geral de mudanas.
! Gerncia do Escopo do Projeto - descreve os processos necessrios para assegurar
que o projeto contemple todo o trabalho requerido, e nada mais que o trabalho
requerido, para completar o projeto com sucesso. Ele composto pela iniciao,
planejamento do escopo, detalhamento do escopo, verificao do escopo e controle de
mudanas do escopo.
! Gerncia de Tempo do Projeto - descreve os processos necessrios para assegurar
que o projeto termine dentro do prazo previsto. Ele composto pela definio das
atividades, seqenciamento das atividades, estimativa da durao das atividades,
desenvolvimento do cronograma e controle do cronograma.
! Gerncia do Custo do Projeto - descreve os processos necessrios para assegurar
que o projeto seja completado dentro do oramento previsto. Ele composto pelo
planejamento dos recursos, estimativa dos custos, oramento dos custos e controle
dos custos.
! Gerncia da Qualidade do Projeto - descreve os processos necessrios para
assegurar que as necessidades que originaram o desenvolvimento do projeto sero
satisfeitas. Ele composto pelo planejamento da qualidade, garantia da qualidade e
controle da qualidade.
! Gerncia dos Recursos Humanos do Projeto - descreve os processos necessrios
para proporcionar a melhor utilizao das pessoas envolvidas no projeto. Ele
composto pelo planejamento organizacional, montagem da equipe e desenvolvimento
da equipe.
! Gerncia das Comunicaes do Projeto - descreve os processos necessrios para
assegurar que a gerao, captura, distribuio, armazenamento e a pronta
apresentao das informaes do projeto sejam feitas de forma adequada e no tempo
certo. Ele composto pelo planejamento das comunicaes, distribuio das
informaes, relato de desempenho e encerramento administrativo.
! Gerncia dos Riscos do Projeto - descreve os processos que dizem respeito
identificao, anlise e resposta a riscos do projeto. Ele composto pela identificao
dos riscos, quantificao dos riscos, desenvolvimento das respostas aos riscos e
controle das respostas aos riscos.
! Gerncia das Aquisies do Projeto - descreve os processos necessrios para a
aquisio de mercadorias e servios fora da organizao que desenvolve o projeto. Ele
composto pelo planejamento das aquisies, preparao das aquisies, obteno
de propostas, seleo de fornecedores, administrao dos contratos e encerramento
do contrato.
Pgina 15 de 190
2.6
Mapeamento Grupos X reas de Conhecimento

Grupo de
Processos
rea de
Conhecimento
Iniciao
4.1 Desenvolvimento do
Plano do Projeto
4. Integrao
5.1 Iniciao
5. Escopo
6. Tempo
7. Custo
8. Qualidade
9.Recursos Humanos
10.Comunicaes
Planejamento
Execuo
4.2 Execuo do Plano

do Projeto
5.4 Verificao de Escopo

5.5 Controle de Mudanas
de Escopo
6.1 Definio de Atividades

6.2 Sequenciamento de
Atividades
6.3 Estimativa de Durao
6.4 Desenvolvimento de
Cronograma
6.5 Controle de
Cronograma
7.1 Planejamento de
Recursos
7.2 Estimativa de Custos
7.3 Oramento de Custos
7.4 Controle de Custos
8.1 Planejamento de
Qualidade
8.2 Garantia de
Qualidade
9.1 Planejamento
Organizacional
9.2 Aquisio de Staff
9.3 Desenvolvimento da
Equipe
10.1 Planejamento de
Comunicao
10.2 Distribuio de
Informao
12. Aquisio
Aquisio
Solicitao
Encerramento
4.3 Controle Integrado de

Mudanas
5.2 Planejamento de Escopo

5.3 Definio de Escopo
Gerenciamento de Riscos
11.2 Identificao de Riscos
11.3 Anlise Quantitativa de
Riscos
11.4 Anlise Qualitativa de
Riscos
Resposta a Riscos
11. Risco
Controle
8.3 Controle de Qualidade
10.3 Reporte de
Performance
10.4 Encerramento
Administrativo
11.6 Monitorao e
Controle de Riscos
12.3 Solicitao
12.4 Seleo de
Fornecedores
12.4 Administrao de
Contratos
12.6 Encerramento
de Contrato
As numeraes das reas de conhecimento e dos processos seguem os nmeros dos

captulos e itens do PMBOK Guide.
2.7
Utilizao do PMBOK Guide
Uma primeira abordagem ao PMBOK Guide pode dar uma impresso errada. Como ele
composto de processos em que as sadas de um se tornam entradas de outro, pode-se ter a
impresso que se trata da descrio de um workflow a ser implementado como definido.
No entanto, uma leitura mais atenta mostra que esta simetria apenas uma forma de
organizar o conhecimento. Os processos so organizados de forma idealizada sem ter a
pretenso de mapear completamente a realidade.
Atravs do processo de certificao, o PMI exige que os profissionais provem que conhecem
este fluxo terico e, assim, espera-se que sejam capazes de adapt-lo a suas realidades
especficas. Projetos vm em todos os tamanhos e formas e nenhuma metodologia genrica
pode valer para todos.
Pgina 16 de 190
3 Interao Projeto X Organizao

A gerncia de projetos se insere num ambiente bem mais amplo do que o projeto
propriamente dito. A equipe de coordenao do projeto deve compreender este contexto mais
amplo. O simples gerenciamento das atividades da equipe do projeto necessrio, mas no
suficiente para o sucesso. Este captulo descreve os principais aspectos do contexto do
gerenciamento de projetos na Organizao.
3.1
Stakeholders
Stakeholders so indivduos ou organizaes que esto ativamente envolvidos no projeto ou

cujos interesses possam ser positiva ou negativamente afetados pela execuo do projeto ou
pelos produtos do projeto. Tentativas de traduo so: partes envolvidas, interessados,
acionistas, entre outras.
Alguns tipos so mais ou menos bvios, tais como: clientes, fornecedores, membros da
equipe, etc. No entanto, em um sentido mais amplo, qualquer um que tem alguma participao
no projeto, ou afetado por ele ou por seu resultado um stakeholder.
Muitos gerentes de projetos tiveram srios problemas ao falharem em reconhecer um
stakeholder importante. Construtores de usinas de energia, que falharam em reconhecer a
sociedade como um stakeholder, tiveram problemas de embargos de obras por
ambientalistas que poderiam ter sido aplacados caso tivessem sido envolvidos no projeto.
O gerente de projeto deve estar atento para o aparecimento, substituio e eventual
desaparecimento de stakeholders. medida que o projeto se adianta, o maior conhecimento
de seus detalhes pode determinar a alterao do quadro de stakeholders.
Identificar os principais stakeholders uma nas primeiras e mais vitais tarefas de um bom
gerente de projetos. Isto vital porque todas as decises importantes durante as etapas de
iniciao e planejamento so tomadas por estes stakeholders. So estas as pessoas que
devero, sob a orientao do gerente de projeto, estabelecer o acordo sobre os objetivos e
restries do projeto.
Os principais stakeholders so aqueles a quem o gerente de projeto ir se esforar ao
mximo para atender. So as expectativas deles que balizaro a avaliao da atuao
gerente do projeto. Mas eles tambm so aqueles que provero as mais valiosas
contribuies.
A estes principais stakeholders so atribudos, de forma clssica, papis que eles
representaro durante o projeto. Analisaremos em seguida estes papeis mais comuns, mas
antes duas pequenas advertncias. Papis so rtulos que colocamos em pessoas reais. Um
papel pode ser representado por uma pessoa ou um grupo e a mesma pessoa pode atuar em
vrios papis. Alm disso, no processo de identificao de stakeholders, mais importante
perguntar Quem tem uma contribuio a dar para o sucesso do projeto? do que
simplesmente Quem o cliente? ou Quem o Sponsor?.
3.1.1 Papel: Gerente de Projetos

Muitos gerentes de projetos esquecem de se incluir na lista de stakeholders. Isto um erro.
Ao comear um projeto essencial que ele descubra quais so as suas prprias expectativas
com relao ao projeto. A perda do equilbrio emocional pode levar a perda do foco inicial.
Gerentes de projetos internados, devido ao excesso de stress, no so teis para ningum.
Pgina 17 de 190
3.1.2 Papel: Sponsor
O Sponsor ou Patrono ou ainda Campeo do Projeto a pessoa com autoridade formal que,
em ltima instncia, responsvel pelo projeto. A posio de autoridade do Sponsor
independente de qualquer projeto individual. Isto possibilita ao Sponsor agir como um elo
entre o projeto e a organizao executora.
Algumas tarefas cabem normalmente ao Sponsor:
! Anunciar a existncia do projeto e definir o Gerente do Projeto;
! Assistir definio da diviso de responsabilidades;
! Revisar e aprovar o plano do projeto;
! Orientar o Gerente do Projeto e discutir, em bases regulares, o status do projeto;
! Monitorar e controlar a prioridade relativa do projeto durante seu desenvolvimento;
! Resolver conflitos e auxiliar o Gerente do Projeto na superao de obstculos dentro
da organizao;
til que o Sponsor tenha uma alta posio dentro da empresa, mas fundamental que ele
tenha grande interesse pelo projeto. De nada vale divulgar que o presidente da empresa o
Sponsor de um projeto se, quando voc mais estiver precisando dele, ele tiver coisas mais
importantes a fazer. Logo ficar claro para todos que o projeto carece do apoio que se
supunha a princpio.
3.1.3 Papel: Gerente Funcional da Organizao Executora

Gerente Funcional o termo geral que utilizamos para designar qualquer um com poder e
responsabilidade dentro da organizao ou organizaes em que o projeto se desenrola.
Podem ser coordenadores, gerentes, supervisores, diretores, presidentes ou mesmo aquele
assessor do presidente que ningum sabe exatamente o que faz, mas que consegue tudo que
quer.
Eles so aqueles que tem o controle de longo prazo dos recursos e pessoas que voc dever
pedir emprestado para o projeto. So eles que controlam e alteram as polticas da
organizao e podem autorizar excees. So eles enfim, que possuem o poder que o
Gerente de Projeto carece.
Um bom relacionamento com os Gerentes Funcionais pode facilitar a liberao daquele
especialista absolutamente necessrio para evitar que o projeto atrase. Pode acelerar a
obteno de informaes. Pode permitir que autorizaes e aprovaes sejam emitidas de
maneira gil e dentro dos prazos. Os Gerentes Funcionais podem ser uma fonte preciosa de
aconselhamento e informao. Um mau relacionamento pode sabotar totalmente o projeto.
3.1.4 Papel: Time de Projeto

Todos aqueles que contribuem para o projeto fazem parte do time de projeto. Muitos tero um
registro formal de participao no plano do projeto, outros no. Alguns clientes podem ser
considerados como parte do time de projeto. importante identificar os principais membros do
time o quanto antes possvel. Em alguns casos, estimativas s podem ser feitas com preciso
se soubermos quem executar a tarefa. Um excelente especialista pode ser 5 vezes mais
produtivo do que um profissional mediano.
Motivar a equipe, seja ela dedicada exclusivamente ao projeto ou no, uma tarefa
fundamental para o sucesso do projeto.
Pgina 18 de 190
3.1.5 Papel: Cliente
Normalmente quem paga tem a ltima palavra. Mas nem sempre obvia a identificao do
cliente. Se estivermos criando um produto para venda, o potencial cliente pagador pode ainda
nem ter cincia da existncia do projeto. Por outro lado, quem libera o oramento pode no ter
uma participao ativa no projeto. Certas entidades podem financiar o projeto em benefcio de
um grupo.
De uma maneira geral, precisamos distinguir alguns grupos de clientes:
1. Aqueles que esto pagando a conta;
2. Aqueles que tm autoridade para tomar uma deciso final sobre os requisitos do
projeto ou produto;
3. Aqueles que podem fornecer informaes valiosas sobre os requisitos do projeto ou
produto ou que representam o grupo total de clientes potenciais;
4. Aqueles que usaro o produto, sem necessariamente ter grande envolvimento no
projeto at suas fases finais;
5. Aqueles que querem participar e dar opinio, sem pagar a conta ou assumir
responsabilidades;
Saber distinguir estes grupos fundamental. Voc pode, por exemplo, criar um produto que
atende a 100% dos requisitos ditados por um consultor especialista (grupo 3), mas que na
hora de ser usado pelos clientes finais (grupo 4) se revelou altamente desapontador,
motivando que o comit de avaliao do projeto (grupo 2) recomendasse entidade
financiadora (grupo 1) o no pagamento da ultima fatura at voc concertar os problemas.
Obviamente procura-se manter a participao do grupo 5 em um mnimo, no entanto, podemse evitar muitos problemas disponibilizando algum tempo para ouvir estas pessoas e, talvez,
encaminh-las para algum do grupo 1. possvel que elas sintam que foram ouvidas e
pararem de tentar interferir. Algumas delas se sentiro satisfeitas se voc as incluir na lista de
pessoas que so informadas sobre alteraes de escopo.
Em qualquer caso, esta classificao um tanto arbitrria e um cliente pode pertencer a mais
de um grupo ou mesmo mudar de grupo vrias vezes durante o projeto. O Gerente do Projeto
deve tentar formalizar as caracterizaes e mudanas mais importantes, quando possvel.
3.2
Problemas Comuns no Relacionamento com a Organizao
Projetos no existem em um vcuo. Normalmente esto inseridos em uma organizao que j

existia quando comearam e continuar existindo aps seu encerramento. A caracterstica
finita do projeto freqentemente se choca com a caracterstica contnua da organizao.
Entender o porqu muito importante para evitar ou contornar problemas.
Um fato importante a ser reconhecido que os gerentes de projeto tm autoridade provisria.
Ela s dura enquanto o projeto durar. Talvez o gerente de projeto tenha alguma outra fonte de
autoridade se ocupar um cargo funcional concomitante ao projeto. Mas enquanto gerente de
projeto, sua autoridade dependente da existncia do projeto. Ele dever usar esta
autoridade para resolver os problemas do projeto mas, ao mesmo tempo , ter que lidar com
pessoas que tm interesses fora do projeto e que tm poder independente de sua existncia.
Ele tambm ter que lidar com seus prprios interesses futuros.
Outra fonte de problema que os projetos obedecem a um cronograma prprio que
independe dos marcos de tempo da organizao. Um projeto pode durar 1 ano e 5 meses e
atravessar 3 anos fiscais. Isto pode gerar problemas oramentrios, principalmente quando
um projeto ultrapassa estes perodos fiscais. O Oramento prometido em um perodo pode
sofrer alteraes no perodo seguinte.
Pgina 19 de 190
Lembre-se de que a organizao continuar existindo e tendo seus prprios problemas
enquanto o projeto continua. Os funcionrios que esto formalmente transferidos para o
projeto, na prtica, muitas vezes daro uma fugida para ajudar a seus companheiros de
departamento ou mesmo seu chefe. Eles esto na desconfortvel situao de servir a dois
senhores, e o gerente funcional tem o controle da sua carreira a longo prazo.
Finalmente, lembre-se de que a poltica da organizao ir afetar o projeto e o apoio dos
poderosos sempre incerto.
3.3
Organizao Funcional ou Hierrquica
Projetos podem ocorrer dentro da realidade de uma organizao puramente funcional.

Organizaes funcionais so organizadas em volta das funes primrias executadas na
empresa, tais como: Marketing, Engenharia, Vendas, Operaes, Tecnologia da Informao,
Recursos Humanos etc. Cada funcionrio tem um nico superior imediato que define suas
tarefas, controla seu trabalho e avalia seu desempenho. Por isso, estas organizaes tambm
so chamadas de hierrquicas. O Exrcito e a Igreja Catlica so os exemplos clssicos de
organizaes hierrquicas, mas a maioria das empresas tem a mesma caracterstica.
Projetos dentro de uma unidade funcional no apresentam maiores complicaes. No entanto,
quando um projeto afeta vrias unidades funcionais, a tarefa de gerenci-lo se torna
complexa. Isto porque o gerente de projeto no tem autoridade funcional sobre todos os
envolvidos e precisa contar com os gerentes funcionais para obter as necessidades do
projeto.
Vantagens da Organizao Funcional:
! Cada pessoa se reporta apenas a seu superior hierrquico. O respeito cadeia de
comando importante para que as ordens centrais sejam facilmente difundidas e evita
que os subordinados tenham dvidas na orientao a seguir;
! Os especialistas so mais facilmente gerenciados. Estando todos em uma unidade
funcional, podem ser coordenados por algum que compreenda suas necessidades. O
compartilhamento otimizado uma vez que eles podem atender a toda a organizao;
Problemas da Organizao Funcional:
! No h plano de carreira para Gerentes de Projetos. Ao termino do projeto ele deve se
preocupar com seu futuro na organizao. Isto pode retirar o foco do projeto em
momentos crticos;
! A unidade funcional tem seu prprio trabalho a fazer e, sendo pressionado, o gerente
funcional provavelmente atender as demandas imediatas e no s necessidades do
projeto. Atrasos e conflitos se tornam inevitveis;
! A unidade funcional tender a focar nos aspectos do projeto que mais lhe interessem.
A mentalidade de eu fiz minha parte facilmente se instala. No h interesse em
aumentar um pouco o trabalho de uma unidade funcional, mesmo quando isto
diminuir, significativamente, o esforo no projeto como um todo;
Pgina 20 de 190
3.4
Organizao por Projetos
Organizao por projetos so comuns dentro da realidade de empresas totalmente focadas

em projetos. Empreiteiras ou empresas de consultoria tm esta caracterstica.
Vantagens da Organizao por Projetos:
! O projeto se organiza de forma fcil e eficiente. Os recursos so providos
centralmente. As negociaes ainda so necessrias entre projetos, mas o processo
se torna muito mais fcil;
! Lealdade da equipe ao projeto. Como o nico interesse dos funcionrios o sucesso
dos projetos que participam, facilmente tomam as decises que atendem aos
interesses do projeto como um todo e no a otimizaes locais;
Problemas da Organizao por Projetos:
! A equipe de projeto tem preocupaes de alocao ao trmino do projeto. Se no
houver um novo projeto eles podem ser dispensados. A fuga de recursos nas fases
finais de um projeto pode ocorrer se as pessoas comearem a procurar outros
empregos de maneira preventiva;
! Muitas funes e recursos so duplicados. O compartilhamento se torna menos
eficiente porque no h um interesse funcional;
! A troca de informaes entre especialistas se torna mais difcil. Conhecimento gerado
em um projeto no migra facilmente para o resto da organizao;
3.5
Organizao Matricial
A idia da organizao matricial ser um hbrido entre a funcional e a por projetos. Na

estrutura matricial cada pessoa da organizao tem pelo menos dois superiores: o gerente
funcional de sua especialidade e os gerentes dos projetos a que ela pertence. A autoridade
dividida entre os gerentes funcionais e os gerentes de projetos e tenta-se manter um certo
equilbrio.
Vrios graus de organizao matricial podem ser adotados, dependendo principalmente do
balano de autoridade entre os gerentes funcionais e os gerentes de projetos.
Vantagens da Organizao Matricial:
! Melhora o controle dos recursos para o gerente de projeto, em comparao a estrutura
hierrquica;
! Garante mais suporte/apoio dos gerentes funcionais;
! Maximiza a utilizao de recursos escassos em relao organizao por projetos;
! Melhora a divulgao de informaes tanto, vertical (na hierarquia funcional) quanto
horizontal (no projeto);
Problemas da Organizao Matricial:
! Mais de um superior para cada pessoa. Os livros religiosos no so as nicas
referncias sobre os perigos de servir a dois senhores;
! Organizao complexa de controlar e monitorar;
! Problemas na alocao de recursos exigem negociao, uma vez que no
necessariamente claro quem tem autoridade final;
! Necessita de regras bem definidas;
! Alto potencial de conflito;
Pgina 21 de 190
3.6
Project Office
O escritrio de projetos ou Project Office uma entidade organizacional, ou equipe de

profissionais, cujo objetivo bsico dar a orientao e suporte que permitam organizao
desenvolver seus projetos da forma mais eficiente e eficaz possvel.
Existem muitos tipos de Project Office cada um com poderes, objetivos e mecanismos
diferentes. Ele pode gerenciar projetos especficos, possuindo total responsabilidade sobre o
sucesso dos mesmos, ou apenas prover suporte a diversos projetos simultneos.
Em suas vrias encarnaes, as funes mais comuns do Project Office so:
! Pesquisa e aprimoramento da Gerncia de Projetos na organizao Buscando e
trazendo as melhores prticas e as mais modernas ferramentas na rea de Gerncia
de Projetos;
! Definio de Mtodos, Procedimentos e Padres Toda a burocracia necessria (e s
vezes desnecessria) envolvendo a execuo e a documentao de projetos, pode ser
definida pelo PO;
! Suporte Tirando dvidas na utilizao dos softwares de gerenciamento de projetos;
dos procedimentos definidos, ou dos conceitos ligados ao gerenciamento de projetos;
! Consultoria e Mentoring Acompanhando o planejamento dos projetos, fornecendo
treinamentos formais e orientando sobre as melhores prticas do mercado;
! Centro de Fornecimento de Gerentes de Projetos Se responsabilizando pela
contratao de profissionais de projetos e sendo a unidade funcional a que eles se
reportam, estando alocados ou no a projetos especficos.
3.7
O Homem de Ligao
Em projetos terceirizados ou mesmo em projetos em que uma rea da empresa, por exemplo
a Tecnologia da Informao, presta servios de projetos para outra rea da empresa, temos a
possibilidade de utilizar um recurso organizacional extremamente til para o sucesso do
projeto. Trata-se da indicao de um homem de ligao entre o cliente e o projeto.
A funo desta pessoa ter um papel duplo. Formalmente, ele pertence estrutura
organizacional do cliente. a pessoa que o gerente de projeto dever procurar em primeiro
lugar quando precisar saber a opinio do cliente. Ele conhece a rea cliente e sabe quem
responsvel pelo que. Pode identificar quem pode fornecer uma informao necessria ou
quem deve ser envolvido em uma tomada de deciso especfica. Como conhece bem as
pessoas e os procedimentos do cliente, ele encarna, para o gerente do projeto, o cliente que
se envolve no projeto.
Se for necessrio negociar prazos ou custos, por exemplo, a primeira negociao deve ser
feita entre o gerente de projeto e o homem de ligao. Depois de aparadas as principais
arestas, eles podem, em conjunto, discutir as propostas com pessoas da estrutura do cliente
que possuam uma autoridade mais formal de aprovao.
Por outro lado, esta mesma pessoa deve ser um gerente de projeto e ter todo o treinamento
adequado para esta funo. Do ponto de vista do cliente, ele o gerente do projeto. Todos
perguntaro a ele o status do projeto. Ele receber o nus do fracasso e o bnus do sucesso.
Ele dever mobilizar a organizao cliente em direo aos interesses do projeto e, ao mesmo
tempo, garantir que o fornecedor esteja cumprindo a parte dele.
Normalmente no necessrio que ele fique dedicado a um nico projeto. Como os detalhes
de execuo ficam a cargo do gerente de projeto do fornecedor, ele pode agir como elemento
de ligao em vrios projetos simultneos.
Pgina 22 de 190
No existe um nome nico para este tipo de profissional. Na rea de Tecnologia da
Informao comum cham-los de Analistas de Negcios. Eles so alocados como
funcionrios dos departamentos clientes, como Vendas ou Controladoria, mas so eles que
promovem os projetos de informtica para estas reas e fazem a ligao com o departamento
de TI ou com fornecedores.
Um ponto importante que eles se reportem para a rea cliente, mesmo que suas
responsabilidades os prendam a padres e procedimentos da rea fornecedora. Provocadas
pelo receio da perda de controle dos projetos, ou por problemas de alocao de custos,
algumas tentativas foram feitas na colocao destas pessoas de ligao na rea fornecedora.
Por exemplo, o departamento de TI estabelece um elemento de ligao que far todo o
relacionamento de projetos para a rea de Vendas, outro para a Controladoria etc e cria uma
rea para reuni-los dentro do organograma da TI. Na prtica, os resultados deste tipo de
estrutura no tm se mostrados eficientes. Estas pessoas no tm legitimidade para falar em
nome dos clientes. Eles so, em ltima anlise, funcionrios do fornecedor e so avaliados
pelos objetivos do fornecedor.
Nos casos em que um cliente tenha sempre vrios projetos do mesmo tipo acontecendo, o
uso deste elemento de ligao extremamente poderoso para aumentar as chances de
sucesso dos projetos. Para projetos ocasionais, no entanto, o custo de manter uma pessoa
especfica para esta funo no deve prover retorno suficiente.
No entanto, sempre recomendado que exista, entre os clientes, um ponto focal que conhea
as tcnicas de gerenciamento de projetos. Esta pessoa poder fazer o papel de elemento de
ligao enquanto continua a desempenhar as suas tarefas normais fora de projetos.
Pgina 23 de 190
4 Mtodos de Seleo de Projetos

Como j dissemos, projetos existem no contexto de uma organizao maior. Esta organizao
tem seus objetivos e se utiliza de projetos para atingi-los. Como os recursos da organizao
so limitados, necessrio algum tipo de critrio de seleo para saber quais projetos devem
ser criados.
Cada um dos possveis projetos tem diferentes perfis de custo, benefcio e risco. Infelizmente
muito raro, seno impossvel, ter certeza dos valores destas grandezas. Mesmo que isto
fosse possvel, a seleo de um projeto j seria uma tarefa complexa. Caso a organizao
esteja escolhendo um portiflio de projetos, ou seja, um grupo de projetos com objetivos
coordenados, a tarefa ainda mais complexa.
Nosso amigo gerente de projetos freqentemente s chamado sala dos tomadores de
deciso quando o projeto j foi escolhido. A falta de conhecimento sobre projetos, por parte
destes tomadores de deciso, uma das fontes de dor de cabea futura. Em outros casos,
porm, o futuro gerente de projetos foi a pessoa que trabalhou em um anteprojeto e vendeu a
idia aos grandes lderes. Nestes casos, espera-se que ele saiba o que estava fazendo
enquanto demonstrava as maravilhas que o projeto poderia fazer pela empresa.
Em qualquer caso, extremamente til para o processo de seleo de projetos o uso, ou pelo
menos o conhecimento, dos modelos de mtodos de seleo. Estes modelos, de maneira
semelhante aos modelos cientficos, simplificam a realidade de forma a torn-la mais clara e
manusevel limitada capacidade humana. claro que a prpria escolha do modelo j
demonstra uma certa parcialidade na seleo dos aspectos relevantes (aqueles que sero
explicitados no modelo) e daqueles que so considerados irrelevantes. Um modelo
estritamente financeiro, por exemplo, deixar de fora o fato do projeto gerar um potencial
impacto ambiental.
Apesar de suas limitaes, modelos de seleo de projetos so teis e devem ser usados.
Eles so de diversos tipos, utilizando analogias, diagramas, aritmtica ou at mesmo simples
palavras. Veremos alguns deles a seguir mas antes, uma palavra de advertncia:
Modelos no tomam decises, pessoas tomam !

So lamentavelmente comuns casos em empresas nas quais bons projetos foram colocados
de lado devido dificuldade de comprovar seus benefcios dentro da formula padro de
anlise. Uma planilha eletrnica pode calcular o retorno de investimento provvel de um
projeto. necessrio um crebro humano plenamente desenvolvido para decidir quando
ignorar um baixo retorno de investimento na busca de atingir determinada posio estratgica.
Mas lembre-se de que conhecer o retorno previsto do projeto, quando ele calculvel, e tomar
uma deciso contrria recomendada uma coisa bem diferente de agir com base em meras
opinies e preferncias pessoais.
Mesmo quando o tomador de deciso segue um modelo, a responsabilidade final dele. A
delegao desta responsabilidade para o modelo pode ajud-lo a manter seu emprego aps
um projeto desastroso, mas no pode eximi-lo da responsabilidade.
Pgina 24 de 190
4.1
Mtodos no Numricos
Mtodos no numricos so mais simples e antigos e normalmente so bem conhecidos.
4.1.1 Projetos Vaca Sagrada

Um poderoso senhor, do alto da hierarquia da empresa, tem uma idia brilhante e a repassa
para algum gerente de nvel intermedirio com grandes ambies e espinha flexvel. Est a
origem de um grande nmero de projetos. Este critrio, tambm conhecido como manda
quem pode, obedece quem tem juzo, no deve ser subestimado.
Projetos Vaca Sagrada tm uma vantagem clara sobre outros projetos. Eles tm um suporte
claro de um Sponsor poderoso. Somente isto pode j ser suficiente para levar o projeto ao
sucesso.
4.1.2 Necessidade Imperativa

Algumas vezes, surgem projetos cuja necessidade praticamente unanimemente aceita. o
caso de um projeto de recuperao de um prdio com problemas estruturais. Se um projeto
necessrio para que o sistema da organizao continue operando, resta apenas uma
pergunta: O sistema em questo vale a pena ser salvo pelo custo estimado do projeto?
4.1.3 Necessidade Estratgica

Existem fatores mais ou menos intangveis como: competitividade futura, anseios de clientes,
imagem da organizao etc. Estes fatores so difceis de serem mensurados, mas a alta
gerncia normalmente custear projetos que estejam aparentemente de acordo com as
necessidades estratgicas. Este apoio ser mais ou menos independente da demonstrao de
benefcios tangveis. Assim, um projeto de integrao empresa X comunidade, por exemplo,
custeado sem que o retorno esteja claro, apenas porque isto est de acordo com os valores
da empresa. E talvez em troca de um pouco de marketing.
4.1.4 Anlise de Alternativas

Em muitas situaes, a organizao no tem nenhum mtodo formal de seleo de projetos,
no entanto, o grupo de tomadores de deciso acredita ter uma boa idia de que alguns
projetos traro mais benefcios do que outros, mesmo quando eles no tm nenhuma forma
precisa de medir ou mesmo definir estes benefcios.
O problema que muitas decises so tomadas de maneira desconexa. Um diretor pode
aprovar um projeto pela manh e recusar um projeto melhor tarde. As duas decises foram
tomadas em contextos separados e no houve uma comparao real entre os dois projetos.
Na escolha de um portiflio de projetos, o exerccio de anlise de alternativas bastante til.
Pode ser usado por um tomador de deciso solitrio ou com o auxlio de um comit. O
processo bsico muito simples e descrito a seguir:
1. Cada participante, aps ter analisado individualmente cada projeto, comea com uma lista de
todos eles, com o nome, a descrio de cada um e talvez alguns outros dados como: custo
estimado e o nome de quem sugeriu o projeto.
2. Cada participante divide a lista em duas: a lista de alta prioridade e a lista de baixa prioridade.
3. Cada participante busca nas duas listas existentes aqueles que podem ser mais bem
classificados como de mdia prioridade.
4. Cada participante seleciona, na pilha de alta prioridade, aqueles que podem ser movidos para
uma lista de prioridade mxima. Ele faz a mesma coisa com a de baixa prioridade em busca
daqueles que podem ser listados sob o rtulo de baixssima prioridade.
5. No fim, cada um rev suas listas em busca de projetos que paream fora do lugar, at que fique
satisfeito com a classificao.
Pgina 25 de 190
Se um comit for utilizado, os participantes podem fazer suas selees particulares de
maneira annima e depois as listas podem ser consolidadas pelo comit, buscando um
consenso.
Os detalhes gerais no so importantes. O importante que os tomadores de deciso se
obriguem a comparar o leque de alternativas, mesmo utilizando seus prprios critrios
subjetivos e que, de preferncia, tenham que argumentar suas escolhas perante seus pares.
4.2
Mtodos Numricos Financeiros
Uma grande quantidade de organizaes modernas tem algum tipo de mtodo financeiro de
avaliao e seleo de projetos. Estes mtodos tm a grande vantagem de vincular o projeto
grande meta da maioria das organizaes: ganhar dinheiro.
Mas uma empresa algo muito mais complexo do que uma aplicao financeira. Embora a
anlise financeira seja um critrio importante, outras consideraes podem levar um bom
dirigente a colocar dinheiro em um projeto cujo prejuzo financeiro certo.
4.2.1 Payback
O tempo de Paypack um mtodo antigo e ainda muito utilizado. Ele tem a vantagem de ser
simples de ser entendido, mas possui srias desvantagens.
O Payback calculado dividindo-se o investimento inicial no projeto pelo valor mdio de
fluxo de caixa previsto gerado pelo projeto. Por exemplo se um projeto, com a durao de um
ano, exige um investimento de $100.000,00 e existe a previso de que ele gere $25.000,00
por ano, ele se pagar em 5 anos. Dizemos que ele tem um payback de 5 anos.
Note que este mtodo ignora qualquer fluxo de caixa aps o perodo de payback. Projetos
que geraro produtos lucrativos por dcadas so igualados a produtos efmeros. Se nosso
projeto continuar a gerar dinheiro aps 5 anos ou no completamente irrelevante para o
clculo do payback. Alem disso, ele mascara completamente o volume de capital envolvido.
bem diferente ter um retorno de 5 anos para um investimento de $10.000,00 do que para um
de $1.000.000,00, mas o payback iguala os dois.
4.2.2 Taxa Interna de Retorno

Se o projeto puder ser representado como uma srie de entradas e sadas de caixa no tempo,
pode-se definir a taxa interna de retorno como sendo a taxa que iguala os fluxos.
n
E
i= 1
(1 + tir) = Si (1 + tir) i
i
i= 1
Ei so os fluxos de caixa de entrada e Si so os fluxos de caixa de sada.

Tomemos como exemplo nosso projeto com investimento de $100.000,00 e gerao de
$25.000,00 por ano. Se ele parar de gerar dinheiro aps 5 anos, ou seja, exatamente no
payback, a tir ser 0 (zero). Por outro lado, se ele continuar a gerar os $25.000,00 por mais
dois anos, a tir ser se 13%, ou seja, o projeto equivalente a um investimento com uma
taxa de 13% ao ano.
O valor de tir que iguala as duas equaes s pode ser calculado por tentativa e erro, ou
seja, por mtodos numricos. Na verdade, existem vrios valores possveis para tir e o
mtodo numrico encontrar apenas um deles. O esforo computacional desta operao ir
aumentar conforme o nmero de perodos. Estas caractersticas desestimulam o seu uso em
avaliaes de projetos.
Pgina 26 de 190
4.2.3 Fluxo de Caixa Descontado
O mtodo do Fluxo de Caixa Descontado tambm chamado de Valor Presente porque
determina o valor presente lquido (VPL) de todos os fluxos de caixa associados ao projeto,
descontando-os por uma taxa de referncia.
n
VPL(projeto) = Fi (1 + taxa) i
i= 1
Fi o fluxo de caixa no perodo i (normalmente os fluxos iniciais so negativos)

taxa: a taxa de referncia desejada para que o investimento valha a pena, em
comparao com um investimento alternativo de risco mais baixo (aplicar no banco, por
exemplo).
O VPL muito superior ao Payback, no entanto ainda tem imperfeies. Dependo da taxa
escolhida, dificilmente um projeto cujos fluxos de retorno demorem alguns anos ser bem
avaliado, mesmo que a previso seja de que este fluxo continue por muito tempo.
Digamos, por exemplo, que temos que escolher entre dois projetos em um pas com inflao
zero:
! Um projeto que exigir um investimento mensal de $15.000 durante um ano e tenha
previso de retornar um fluxo de $50.000 por ms durante um ano aps isto.
! Um projeto que exigir um investimento mensal de $15.000 durante cinco anos, mas
tenha previso de retornar um fluxo mensal de $50.000 durante 24(vinte e quatro) anos
aps isto.
Se a taxa pretendida de 2% ao ms, o primeiro projeto tem um VPL de $ 258.299,10,
enquanto o do segundo de $ 238.000,92. Em valores absolutos, o primeiro projeto gera um
caixa de $420.000,00 e o segundo de $ 13.500.000,00, ainda assim o VPL apontaria para a
escolha do primeiro projeto.
No h nada de errado com relao a esta concluso mas ela, sem dvida, privilegia decises
de curto prazo. Para determinados tipos de negcios, cinco anos um prazo muito pequeno e
a utilizao do VPL traz dificuldades. Se, por exemplo, tivermos que tomar uma deciso que
elimine 4 anos de vida til do segundo projeto, o VPL resultante ser de $ 233.967,48, o que
representa uma diferena mnima se notarmos que esta deciso significou a perda de
$2.400.000,00 em receitas futuras. Lembre-se de que, sem inflao, estamos falando de
valores reais, embora futuros.
4.2.4 Mtodo de Pacfico

O mtodo de Pacfico um exemplo de variao de mtodo financeiro que introduz a anlise
de risco dentro do modelo de avaliao. Este mtodo em especial se aplica a projetos de
pesquisa e desenvolvimento de produtos, mas a idia geral pode ser adaptada para outros
tipos de projetos. Vejamos sua frmula:
P(projeto) = rdpc SP L C
r = avaliao da probabilidade de sucesso da pesquisa
d = avaliao da probabilidade de sucesso do desenvolvimento do produto (dado que a
pesquisa tenha sucesso)
p = avaliao da probabilidade de sucesso do processo de fabricao (dado que o
desenvolvimento do produto tenha sucesso)
Pgina 27 de 190
c = avaliao da probabilidade de sucesso comercial do produto (dado que o produto
seja fabricado)
S = estimativa do volume anual de unidades vendidas do produto
P = estimativa do lucro por unidade vendida do produto
L = estimativa do tempo de vida no mercado esperado para o produto. Embora o lucro
no seja propriamente descontado no tempo, a raiz quadrada diminui sua importncia
absoluta
C = estimativa do custo do projeto
Com tal quantidade de estimativas de probabilidades, mtodos como este so altamente
arbitrrios. No entanto, no processo de definir as variveis necessrias, aumenta-se as
chances de que todos os aspectos para o sucesso do projeto sejam devidamente avaliados.
Pgina 28 de 190
4.3
Mtodos Numricos no Financeiros
Mtodos numricos no financeiros procuram explicitar as opinies e insights dos tomadores

de deciso.
4.3.1 Ponderao de Fatores,

Na ponderao de fatores, os avaliadores criam uma lista de objetivos e/ou caractersticas que
um projeto deve alcanar. O portiflio de projetos avaliado por sua influencia nestes fatores.
Cada projeto recebe uma nota, normalmente de 1 a 5, para cada fator, dependendo do projeto
ser mais ou menos relevante para o fator. Os fatores, por sua vez, recebem notas com sua
importncia relativa para a empresa.
A nota final do projeto uma mdia ponderada dos fatores.
n
N(projeto) = ni wi
i= 1
Onde: ni = a nota do projeto no i-simo fator

wi = o peso relativo do i-simo fator
4.3.2
Modelo de Dean e Nishry
O modelo de Dean e Nishry uma sofisticao do modelo anterior. O processo comea com o
clculo da nota de cada projeto individual:
N p = ni wi
i= 1
Tambm precisamos definir o custo de cada projeto (cp) e a quantidade total de recursos
disponveis (R). Uma vez que tenhamos estas duas variveis, o modelo aplicado a um
algoritmo de otimizao (ex. Simplex). A idia encontrar o conjunto de projetos que
maximiza os benefcios enquanto mantm o portiflio dentro do oramento. Matematicamente,
devemos encontrar o conjunto de valores de xp (onde x = 0 ou 1) que maximiza:
max N = x p N p
p=1
Tendo como restrio que:
x c
p=1
p p
Embora parea sofisticado, este mtodo pode, atualmente, ser facilmente implementado
empregando-se uma planilha eletrnica, por exemplo, utilizando-se o Sorver do MS-Excel.
Pgina 29 de 190
4.4
rvores de Deciso
rvores de deciso so ferramentas que podem ser utilizadas tanto para mtodos financeiros
quanto para mtodos no financeiros. A idia bsica desta ferramenta comparar
alternativas, levando em conta tanto o perfil de risco quanto os benefcios esperados para
cada deciso possvel, de modo a mostrar uma viso ampla da situao.
Imagine a seguinte situao: voc responsvel por um projeto cujo objetivo promover um
evento. Voc localizou trs opes de locais para o evento, cada uma com diferentes
capacidades. Mas voc est inseguro quanto ao nmero de inscries Voc est preocupado
se a demanda de inscries para o evento ser alta ou baixa, mas precisa tomar a deciso de
qual opo de projeto, ou seja, qual localizao ser escolhida.
Neste exemplo vemos dois tipos de variveis:
! Alternativas So opes controlveis pelo tomador de deciso. Em nosso caso so
os diferentes locais analisados e suas capacidades.
! Estados da Natureza So possveis eventos que no so controlveis pelo tomador
de deciso. Em nosso caso, a demanda pelo evento.
Inicialmente, poderamos criar uma tabela em que colocssemos os resultados de todas as
possveis combinaes entre alternativas e estados da natureza.
Demanda
Capacidade
Menor Dimensionamento
Baixa
Alta
$ 8 milhes
$ 8 milhes
Dimensionamento Mdio
$ 5 milhes
$ 15 milhes
Maior Dimensionamento
($ 11 milhes)
$ 22 milhes
A tabela nos diria que conforme aumentamos o dimensionamento, podemos ganhar mais
dinheiro se o evento for um sucesso, mas ganharemos menos, ou at perderemos, se a
demanda for baixa. Mas isto parece bastante bvio e no ajuda muito em nossa deciso. Falta
uma informao importante que a probabilidade ligada aos estados da natureza, ou seja a
possibilidade de que a demanda seja alta ou baixa. Digamos que ns avaliamos, baseado em
anlises de eventos semelhantes, que a possibilidade de uma alta demanda de 70%.
O que fazemos com essa informao ? Parece que ela nos induz a arriscarmos mais, porque
existe uma boa possibilidade de que a demanda seja alta. Mas ainda parece que precisamos
de algo para que possamos tomar a deciso. A rvore de deciso introduz o conceito de valor
esperado para resolver este problema.
O valor esperado de uma alternativa a mdia dos valores possveis, ponderada pela
probabilidade do valor. Fixada uma alternativa, por exemplo, o local de mais alta capacidade,
temos 30% de chance de termos um prejuzo de $11 milhes e 70% de chance de termos um
lucro de $22 milhes. O valor esperado 30% de -$11 milhes que -$3.3 milhes somado a
70% de $22 milhes que 15.4 milhes, totalizando $12.1 milhes. A tabela abaixo mostra
todas as trs opes de valor esperado, uma para cada alternativa de deciso.
Demanda
Alta
( 70% )
$ 8 milhes
Valor Esperado
Menor Dimensionamento
Baixa
( 30% )
$ 8 milhes
$ 5 milhes
$ 12 milhes
$ 12 milhes
Maior Dimensionamento
($ 11 milhes)
$ 22 milhes
$ 12,1 milhes
Capacidade
Pgina 30 de 190
$ 8 milhes
Se analisarmos a tabela de nossa situao exemplo, o melhor valor esperado justamente da
opo que pode gerar a maior perda, ou seja, o maior dimensionamento com baixa demanda.
A rvore de deciso ilustra as conseqncias de cada opo. Vejamos como ela seria
construda em nosso caso:
nsi
im e
D
or
m
ona
en t
(.3)
a Baixa
Demand
Demanda Alta
(.7)
$8 milhes
n
Me
Me
nor
(.3)
Demanda Baixa
Dema
nda A
lta (.7
$12 milhes
)
Dim
e
$8 milhes
$8 milhes
$5 milhes
$15 milhes
nsi
on
am
en t
Demanda Baixa (.3)

Dema
nda A
lta (.7
$12,1 milhes
)
($11 milhes)
$22 milhes
Observem como todas as informaes de nosso raciocnio esto sintetizadas de maneira

clara. Na verdade, a rvore em si no serve para tomada de deciso, ela simplesmente uma
ferramenta de comunicao para o raciocnio envolvido na tomada de deciso usando o valor
esperado. No entanto, ela uma boa ferramenta de comunicao e fica bonita em
apresentaes.
O exemplo que apresentamos muito simples e a rvore seria razoavelmente substituda pela
tabela. Mas rvores de deciso mais complexas, com mais tipos de alternativas e outros
estados da natureza, podem ser construdas para decises mais complexas. Nestes casos, o
poder de expressividade da rvore muito maior.
Mas voltemos a nosso exemplo. O melhor valor esperado o da alternativa de
dimensionamento alto. O modelo aponta para esta alternativa, mas ser que esta seria a
nossa deciso ? A resposta no. A estratgia de dimensionamento mdio provavelmente
seria a escolhida. Os valores so muito prximos e o prejuzo potencial grande demais.
Como sempre, no seria prudente deixar o modelo tomar a deciso por ns.
Existem modelos que esclarecem um pouco mais o processo decisrio neste tipo de situao.
Vamos discutir um deles quando falarmos sobre a Teoria da Utilidade, no captulo sobre
riscos. Mas j sabemos que o valor esperado, mesmo fornecendo informaes interessantes
para a tomada de deciso, no deve ser usado de maneira absoluta.
Pgina 31 de 190
5 O Gerente de Projetos
5.1
Misso e Paradoxos do Gerente de Projetos
Ser o gerente de um projeto raramente uma tarefa fcil. Ele tem a misso bsica de entregar
o escopo do projeto com a qualidade adequada, dentro dos prazos e custos definidos e com
alto ndice de satisfao dos Stakeholders.
Esta misso, como veremos, freqentemente o coloca frente de objetivos conflitantes. Este
o primeiro paradoxo de sua atuao. Ele deve gerar satisfao em todos os Stakeholdes
mesmo que, em muitos casos, atender a um signifique prejudicar outro. No suficiente que
ningum fique totalmente insatisfeito. O projeto deve atender as expectativas de todos para
que ele seja considerado um sucesso total.
O gerente de projetos, na maioria das ocasies no tem autoridade para ordenar. Ele deve se
restringir a pedir. No controla decises, somente as influencia. No atua como um supervisor,
mas como um facilitador. Ao mesmo tempo, deve manter o projeto sob controle. Culpar a falta
de autoridade pelo fracasso no aceitvel. Espera-se que ele tenha sucesso, mesmo que
no tenha todos os recursos. Este o segundo paradoxo.
O gerente de projetos deve agir dentro de um ambiente com alto grau de incerteza. Nenhum
planejamento detalhado o suficiente de modo a evitar qualquer variao. Ao mesmo tempo
ele deve ser capaz de cumprir o planejamento. Mesmo no sendo capaz de prever o futuro,
nunca pode permitir que os clientes ou a gerncia snior sejam surpreendidos. Este um
terceiro paradoxo.
Estes paradoxos so apenas aparentes, e na maioria dos projetos, eles so solveis. As
tcnicas listadas neste trabalho podem capacitar o gerente de projetos, tornando-o mais
eficiente e eficaz. No entanto, o talento necessrio para resolver os paradoxos deve pertencer
ao gerente de projeto, pelas suas habilidades inatas e pela sua experincia.
5.2
O Perfil do Gerente de Projetos
De todas as caractersticas pessoais de um bom gerente de projeto, a mais importante a

determinao em completar sua tarefa. Se ele no possuir a motivao, a energia e a
iniciativa para atingir o objetivo, tudo o mais falhar. O gerente de projeto o corao do
projeto.
Outras caractersticas so fortemente recomendadas:
! Credibilidade Administrativa - um profundo conhecimento de todas as tcnicas de
gerenciamento de projeto. Mas isto no suficiente. Ele precisa transmitir maturidade
como gerente. As pessoas precisam reconhec-lo como um gerente capaz.
! Credibilidade Tcnica - um entendimento razovel da tecnologia envolvida no projeto.
A maioria dos autores afirmam que, embora as tcnicas de gerenciamento de projeto
sejam independentes do tipo de projeto, os gerentes de projeto no so. De fato, ele
certamente ter necessidade de interpretar as requisies tcnicas dos clientes e
analisar o impacto no projeto. verdade que mais provvel que ele se envolva em
decises tcnicas quando se trata de pequenos projetos mas, mesmo em grandes
projetos, ele certamente precisar discutir alternativas com a equipe. Vrias atividades
ficam mais complicadas quando o gerente no tem conhecimento tcnico adequado.
! Sensitividade capacidade de lidar com todas as implicaes polticas que um projeto
gera dentro da organizao. Saber navegar entre as gerncias funcionais e sentir
preocupaes e ambies fundamental.
Pgina 32 de 190
O gerente de projetos tambm precisa descobrir conflitos entre membros da sua
prpria equipe e desta com pessoas fora da equipe de projeto. Evitar conflitos
normalmente torna a situao pior. Sentir um conflito em seus estgios iniciais e
confront-lo antes que um estado de guerra se imponha essencial. Esta tarefa
complicada pelo fato de as pessoas normalmente evitarem informar ao gerente de
projeto a existncia de conflitos.
Ele tambm precisa sentir quando est recebendo informaes erradas. Mesmo
pessoas razoavelmente honestas e competentes freqentemente tentam ocultar suas
falhas.
! Liderana influenciar pessoas a tomar decises e aes em benefcio do projeto.
Para isto ele precisa saber como motivar as pessoas de modo que estas se
comprometam com o projeto. O senso de tica importante para que se mantenha
esta influncia. Ele certamente ser colocado em situaes moralmente ambguas e
ter que tomar decises sem perder a credibilidade e por conseqncia a capacidade
de liderana. Como o gerente de projetos freqentemente carece de poder real, sua
capacidade pessoal de inspirar liderana , sem dvida, um trunfo fundamental.
! Habilidade de Lidar com o Stress Ele certamente ter que lidar com muitas presses
durante o projeto. A vida de um gerente de projeto, tentando se equilibrar entre prazo,
escopo e recursos limitados, enquanto atende uma multido de diferentes
stakeholders, no fcil. Uma pessoa que, ao mesmo tempo seja absolutamente
calma e totalmente orientada para ao, que o requisito bsico para a gerencia de
projetos, um indivduo bastante raro. mais razovel exigir que ele seja capaz de se
manter racional mesmo sob presso extrema. Ele certamente ficar estressado como
qualquer ser humano normal, mas deve ser capaz de sair do estado de stress
rapidamente. Gostar do que faz e ter uma vida prazerosa fora do trabalho ajuda
bastante a obter este equilbrio.
5.3
Introduo ao Processo de Negociao
Negociao um processo em que duas ou mais partes, com interesses comuns e

antagnicos, se renem para confrontar e discutir propostas explcitas com o objetivo de
alcanarem um acordo.
Negociar parte do dia a dia do gerente de projetos e ele deve se esforar em obter
conhecimento e treinamento nesta rea. Este captulo oferece uma introduo a esta arte,
mas fortemente recomendado ao Gerente de Projeto que se aprofunde em tudo que diga
respeito ao assunto.
5.3.1 Estratgias Principais de Negociao

Cada uma das partes pode optar por vrias posturas diferentes em relao negociao.
Mesmo acreditando que a estratgia de opo do gerente de projeto deva ser a Negociao
Ganha-Ganha, listaremos as estratgias mais comuns e quando elas so normalmente
utilizadas.
! Fuga Quando a parte acredita que no tem nada a ganhar negociando. A fuga pode
acontecer devida a uma percepo de poder muito superior, gerando a crena de que
no precisa de nada da outra parte. Pode acontecer tambm o exato oposto: a parte
sente que se houver um processo explcito de negociao ela ter tudo a perder. De
qualquer forma ela evita a negociao propriamente dita de maneira mais ou menos
explcita.
Os gerentes de projeto freqentemente se vem lidando com gerentes funcionais que
ignoram compromissos assumidos e no respondem a ligaes. Descobrir que tipo de
percepo causa a fuga, se de superioridade ou de inferioridade, fundamental. A
Pgina 33 de 190
resposta pode ser uma aproximao pessoal de modo a chamar o fujo para o
processo do projeto. Em casos raros, um aumento da aparncia de poder do gerente
de projeto possvel e necessrio. O Sponsor pode prover este poder adicional. No
entanto, esta opo invariavelmente causa ressentimentos.
Os prprios gerentes de projeto utilizam a fuga para ganhar tempo. Embora alguns
conflitos possam ser adiados desta maneira, trata-se de uma situao
necessariamente temporria. O abuso da fuga pode levar ao descrdito total do
Gerente de Projeto.
! Uso do Poder (Pegar ou Largar) Quando a parte acredita que tem muito mais poder
que a outra. Quando isto acontece, a outra parte freqentemente adota uma estratgia
de fuga. Mesmo quando isto no ocorre e os objetivos da parte forte so atingidos,
certamente um ressentimento ser criado na parte mais fraca, o que afetar qualquer
negociao futura.
Entre os Stakeholders, os Clientes so os mais propensos a utilizar relaes de fora,
afinal eles esto financiando o projeto. Freqentemente acreditam que a melhor
maneira de ter o mximo do projeto forar posies. Muitos clientes tentam, por
exemplo, forar aumentos de escopo sem alterao de prazos e custo. A chave aqui
no adotar uma posio radical. Uma fuga temporria pode evitar que o gerente de
projeto ceda sob presso. Ele pode planejar, explicar os problemas gerados e oferecer
concesses.
Um gerente de projeto raramente pode se dar ao luxo de utilizar uma postura de poder.
Gerenciar projetos uma atividade que exige relacionamentos de longo prazo. Mesmo
que o projeto atual permita uma relao de poder, projetos futuros podem ser
prejudicados. Quando necessrio o uso da fora, a imposio de uma posio pode
ser feita de modo a permitir que a outra parte salve as aparncias e no se sinta
humilhada.
! Barganha Quando o poder equilibrado o dilogo inevitvel. Nesta situao
freqentemente se opta por uma estratgia de barganha. H uma troca de
concesses, de valores tangveis que ajudam cada parte a se ajustar, por meio de
recuos e avanos, at que um acordo aceitvel estabelecido. Ambas as partes
perdem algo. Embora isto no seja uma verdade absoluta, a barganha freqentemente
gera ressentimentos e problemas que dificultam um relacionamento duradouro.
Tanto os Stakeholders quanto o Gerente de Projetos provocaro situaes de
barganha. Se ela puder ser resolvida rapidamente e de modo que a perda de ambas as
partes seja aceitvel, ela pode e deve ser utilizada. Mas se o custo for alto e houver
previso de negociaes difceis e demoradas, a opo de negociao Ganha-Ganha
deve ser acionada.
! Negociao Ganha-Ganha - Quando o poder equilibrado e h necessidade de
relacionamento duradouro a negociao Ganha-Ganha praticamente a nica opo.
A idia resolver os problemas de modo que ningum saia perdendo. Parte-se do
princpio que um acordo bom aquele que melhora o relacionamento entre as partes.
Bons acordos satisfazem os interesses das partes e so justos e durveis. Este um
mtodo demorado e exige pacincia, mas o sucesso de cada negociao facilita as
negociaes futuras.
Raramente, qualquer Stakeholder prope o estabelecimento de uma negociao
Ganha-Ganha. Se isto acontecer o gerente de projeto deve se sentar mesa de
negociao, mesmo que ele sinta que tenha poder suficiente para impor uma posio.
A possibilidade do gerente de projeto propor uma abordagem Ganha-Ganha
depender de sua credibilidade perante os Stakeholders. claro que simplesmente
Pgina 34 de 190
no h tempo suficiente para uma abordagem negociada de cada problema, mas nos
pontos importantes ele deve procurar induzi-la.
5.3.2 Negociao Ganha-Ganha

A estratgia de negociao Ganha-Ganha atingiu popularidade aps o livro Getting to Yes de
Willian Ury e Roger Fisher. Neste texto clssico, Fisher e Ury descrevem seus princpios para
uma negociao eficaz. Tambm descrevem obstculos comuns negociao e discutem
maneiras de super-los. Alguns de seus princpios so:
! Separar pessoas e problemas - As pessoas tendem a tornar-se pessoalmente
envolvidas com as questes e posies do seu lado e assim tendem a interpretar
questionamentos a estas posies como ataques pessoais. Separar emocionalmente
as pessoas dos problemas permite que as partes se dirijam s questes em pauta sem
prejudicar seu relacionamento.
Para isto, os problemas devem ser atribudos a trs fatores bsicos: diferenas de
percepo, emoes e falhas de comunicao. Para diminuir o problema de diferenas
na percepo dos fatos essencial que cada parte tente compreender o ponto de vista
da outra sem supor que uma maldade inerente ou motivos ocultos dominam as aes
do outro lado.
As emoes so a segunda fonte de problemas. O processo de negociao pode ser
bastante frustrante e medo e raiva so bastante comuns. O modo de tratar este
problema , antes de qualquer coisa, reconhec-lo e tentar compreender sua fonte.
Declarar as emoes do outro como irracionais apenas o tornar mais irracional.
Tambm no se deve reagir emocionalmente s exploses emocionais da outra parte.
Gestos simblicos de desculpas e simpatia so bastante efetivos no controle de
emoes fortes.
Comunicao a terceira fonte de problemas. As partes freqentemente no esto
ouvindo uma a outra, mas planejando seu prximo argumento. O ouvinte deve prestar
ateno ao que est sendo dito, sumarizando ocasionalmente os pontos do outro, de
modo a confirmar sua compreenso.
! Focar em interesses em vez de posies Sua posio algo pela qual voc se
decidiu. Seus interesses so os motivos destas decises. Quando um problema
redefinido em termos dos interesses subjacentes das partes, freqentemente
possvel encontrar uma soluo que satisfaa aos interesses de ambas as partes
Uma vez que as partes identificaram seus interesses, devem discuti-los e ouvir
sugestes mtuas. As partes devem manter um foco claro em seus interesses, no
abrindo mo deles, mas permanecendo abertos a propostas e a posies diferentes
que podem permitir atingi-los.
! Gerar opes antes de estabelecer-se em um acordo final As partes devem iniciar a
negociao preferencialmente em uma atmosfera informal e realizar um brainstorm
para todas as solues possveis ao problema. Propostas incomuns e criativas so
incentivadas. Somente depois que uma variedade de propostas foi feita, o grupo se
volta tarefa de avaliar as idias. A avaliao deve comear com as propostas mais
promissoras. Nesta fase, as partes podem tambm refinar as propostas.
Pgina 35 de 190
Uma tcnica interessante de negociao ganha-ganha foi criada por Elyahu Goldratt e
chamada de Diagrama de Disperso de Nuvens. Ela simplifica tremendamente o processo de
negociao para os casos em que o problema pode ser adequadamente colocado no formato
do diagrama.
A
Necessidade da outra
Parte.
X
Proposta ou ponto de
vista da outra parte
B
Sua Necessidade.
No X
Sua Proposta ou
seu ponto de vista
O
Objetivo. Que interesse
as partes tem em comum?
Porque se incomodam
em negociar ?
Em primeiro lugar voc coloca a necessidade que acredita que a outra parte possui e a
proposta que ela afirma ser necessria para atend-la (caixas A e X). Depois voc declara sua
necessidade e sua proposta (caixas B e No X). Finalmente voc coloca explicitamente o que
vocs tm em comum. Deve haver um objetivo comum ou as partes no se preocupariam em
dialogar. Se nada melhor surgir, podem ser usados objetivos vagos como o bem da
empresa, mas ser muito melhor se um objetivo claro e especfico puder ser definido.
Na montagem do diagrama, se houver qualquer impreciso dos enunciados, ou a outra parte
no gostar de como um ponto foi colocado, corrija-o de modo que todos fiquem satisfeitos com
a maneira que o problema esta sendo proposto.
Uma vez montado o diagrama, ele deve ser lido. A maneira de fazer isto usando a lgica de
necessidade. Algo como: Concordamos que temos que fazer obter O. Para que O seja
atingido a necessidade A deve ser satisfeita e para isto precisamos de X. Por outro lado, O
tambm depende de B ser satisfeito e para isto necessrio No-X. Mas, opa, X
incompatvel com No-X, ou no h recursos suficientes para fazer ambos, X e no X. No
admira estarmos discutindo, temos um problema.
Reparem que, o tempo todo, ns tentamos colocar que uma questo das duas partes agirem
contra o problema e no de uma parte contra a outra.
Depois que o problema estiver colocado, as duas partes, em conjunto, devem avaliar cada
seta do diagrama em busca de pressupostos. Porque acreditamos que devemos satisfazer a
necessidade A para atingir O ? Por que, para obter B, temos que ter No-X ? Por que
acreditamos que X e No-X so incompatveis ? A cada ponto devemos tornar estas
suposies claras. Na esmagadora maioria dos casos, poderemos encontrar pelo menos uma
suposio falsa, tanto nossas quanto da outra parte. Se isto acontecer, o problema
simplesmente se dissolve, a nuvem negra se dispersa. No h necessidade de barganhas,
pois ns invalidamos o problema.
Pgina 36 de 190
Em outros casos podemos encontrar pequenas solues que no destroem o problema, mas
o enfraquecem o suficiente para que possamos chegar a um acordo. Vamos dar um exemplo
retirado de um caso real. Imagine que voc um Diretor de Projetos e tem um problema com
um jovem Gerente de Projetos. O cliente est solicitando mudanas no escopo do projeto e
est disposto a pagar por elas, mas est pressionando por entregas rpidas para as
alteraes. Nosso Gerente de Projetos fortemente voltado para atender o cliente, e uma vez
que o mesmo est disposto a cobrir os custos, ele aceita os prazos impostos. Mas a equipe
est insatisfeita com esta presso e a consideram desnecessria. Alguns citam casos em que
alteraes consideradas urgentes s foram efetivamente verificadas pelo cliente dias depois
de prontas.
O primeiro passo reconhecer o problema. Uma conversa com nosso gerente de projeto
necessria. Voc comea o dilogo mostrando entender que, para que o projeto seja um
sucesso, ns temos que atender aos clientes e compreender que a presso sobre os
funcionrios fruto deste desejo. Por outro lado, voc coloca que o sucesso do projeto
tambm depende de termos uma equipe motivada e que isto no possvel se eles se
sentirem desnecessariamente pressionados.
Os prazos so negociados levando
em considerao tanto a urgncia
do problema quanto nossa
capacidade de resoluo
A
Temos que atender as
necessidades
dos clientes
O
Os objetivos do projeto
so
totalmente atendidos
X
Temos que pressionar
os funcionrios para
entregas rpidas a
pedidos dos clientes
O profissional se envolve
no problema
(informao e maturidade)
B
Temos que fazer os
funcionrios se sentirem
motivados e contentes
No X
Os funcionrios
no podem se sentir
desnecessariamente
pressionados
A seta entre O e B parece razovel. Os funcionrios so Stakeholders e desejamos

permanecer com eles aps o projeto se encerrar. No-X parece ser um requisito razovel
para B, ningum se sente motivado quando trabalha em excesso sem necessidade.
Clientes insatisfeitos se recusam a liberar pagamentos, no tornam a contratar a mesma
empresa e criam uma mancha no bom nome da organizao. Estes so fortes pressupostos
que justificam a ligao ente O e A.
No entanto, a ligao entre X e A no parece to slida. Na verdade ela parece ser
incmoda logo que colocada explicitamente. Um pressuposto errado, aqui, que as
demandas de prazos dos clientes espelham sempre suas necessidades. Pelo depoimento da
equipe, a ateno dos clientes para os produtos do projeto no ocorre logo que eles ficam
prontos. Existe, claro, um sentimento de urgncia e ele se materializa em solicitaes de
prazos apertados. Mas certamente h espao para negociao. O desejo de atender aos
Pgina 37 de 190
pedidos e no s necessidades dos clientes deve estar nublando a capacidade de negociao
do gerente do projeto. freqente que um cliente faa presso de modo a obter o melhor
acordo possvel, mas apesar da inflexibilidade aparente, ele responder a argumentos
razoveis.
Um outro pressuposto que, mesmo que haja uma urgncia real, a necessidade do cliente
deve ser atendida a qualquer custo. Embora o cliente seja o principal Stakeholder ele no
o nico e o Gerente de Projeto deve balancear suas necessidades com a dos outros
Stakeholders.
Nosso Gerente de Projeto pode melhorar sua forma de negociao com o cliente de modo a
levar em conta tanto a urgncia do problema quanto a capacidade de resoluo da equipe. Ele
deve tomar cuidado para no deixar de atender s necessidades reais dos clientes e nem
gerar insatisfao com o projeto. Esta negociao aliviar bastante a presso embora ela no
termine de todo. A nuvem ainda existe mas est enfraquecida.
H outra conexo a analisar: aquela que liga X a No-X. Por que acontece que, quando
pressionamos os funcionrios eles se sentem desnecessariamente pressionados? Certamente
existe urgncia por parte do cliente e, mesmo que haja negociao, os prazos ainda sero
curtos. O pressuposto incorreto que qualquer urgncia obrigatoriamente vista como
desnecessria pela equipe.
O problema aqui de percepo. A equipe acredita que o Gerente est negociando mal os
prazos, o que verdade, e que no h urgncia real, o que no verdade. Mas se a equipe
acredita que no existe urgncia, a pressa, para eles, desnecessria. Para resolver o
problema de percepo podemos aconselhar o Gerente de Projeto a envolver a equipe no
problema. Pode-se, por exemplo, levar um dos membros da equipe para as reunies de
negociao, de modo que ele tambm sinta a presso e participe da elaborao do prazo.
A negociao com o cliente e o envolvimento da equipe no processo tem o efeito conjunto de
satisfazer o cliente, a equipe e o prprio gerente do projeto, sem que ningum tenha que abrir
mo de suas necessidades, apenas de suas posies.
5.3.3 Tticas
Em muitas situaes de negociao, o gerente de projetos tem que lidar com pessoas difceis.
Estas pessoas tm como meta vencer a negociao e so resistentes a solues ganhaganha ou at mesmo a barganhas razoveis para os dois lados.
Estas pessoas utilizam, na maioria das vezes consciente e deliberadamente, de pequenas
tticas para obter vantagem na negociao. Se no compreender o que est acontecendo, o
gerente de projeto pode ter uma reao emocional que impedir qualquer soluo razovel.
Ele deve compreender estas tticas pelo que realmente so: movimentos no tabuleiro da
negociao para obter um acordo mais favorvel. Ao reconhecer estas tticas, ele pode
analisar friamente uma resposta adequada.
Existe uma infinidade de tticas, mas elas so normalmente agrupadas em 3 (trs) categorias:
! Obstruo O oponente recusa-se a ceder. A idia por traz da obstruo que, se
voc se convencer que impossvel faz-lo ceder, voc pensar que no tem
alternativa a no ser aceitar a posio dele. Ele pode recorrer a uma suposta poltica
da empresa. Pode declarar que sua posio se deve a um fato consumado e, portanto,
irreversvel. Pode argumentar que ele est preso a um compromisso anterior. s
vezes, a obstruo mais sutil. O oponente pode tentar prorrogar a negociao,
arrastando o caso at que seu tempo disponvel, ou sua pacincia, se esgote. Outras
vezes, a obstruo pode assumir a forma de um rude pegar ou largar. Sabendo que a
obstruo uma ttica e que, no fundo, o oponente pode ceder ou buscar alternativas,
voc pode encontrar um meio de contorn-la.
Pgina 38 de 190
! Ataques O oponente tenta pression-lo ou intimid-lo. Aqui a idia desequilibr-lo
de modo que voc faa alguma coisa estpida. Freqentemente um ataque questiona
sua credibilidade ou capacidade. Pode tambm ter a forma de uma ameaa pessoal,
como por exemplo, uma possvel reclamao ao seu superior. Com freqncia as
ameaas so nebulosas e indefinidas, como se tivesse um trunfo na manga que pode
usar para prejudic-lo. A ameaa ou a ofensa tambm pode ser dirigida organizao
a que voc pertence. O oponente tambm pode trat-lo com desprezo, superioridade
ou grosseria. Ele lanar mo de qualquer expediente para desequilibr-lo
emocionalmente. Certas pessoas utilizam a fama de serem rudes e intransigentes para
manter seus oponentes permanentemente na defensiva. Manter o sangue frio mais
fcil quando se sabe que o oponente quer que voc perca a calma. apenas uma
ttica.
! Truques O oponente tenta engan-lo. Os truques utilizam os mesmos aspectos da
personalidade humana que so explorados por estelionatrios. Um truque comum
utilizar dados falsos, confusos ou fora de contexto. Se voc partir de premissas
incorretas, chegar a uma concluso invlida. Outro truque, muito comum, fazer com
que voc acredite que ele tem autoridade para negociar. Quando voc ceder tudo que
pode, ele lhe informa que um superior tem a palavra final. Este superior, ou o prprio
oponente, supostamente em nome deste,
far exigncias extras. Um truque
particularmente irritante o da exigncia de ltima hora. Quando voc acredita que j
chegou a um acordo e comea a relaxar, ele lembra de algo que essencial para
fechar o acordo. Quando voc est ciente do truque, no h motivos para ser
enganado por ele.
Willian Ury, em seu livro, Supere o No oferece, em detalhes, instrumentos para lidar com as
tticas e negociar com pessoas difceis.
5.3.4 Dialtica Erstica

A Dialtica Erstica a arte de discutir com o objetivo de vencer. No se busca a verdade.
Quem tem razo irrelevante nesta arte. Por curioso que possa parecer a Erstica chamou a
ateno de um dos maiores filsofos de todos os tempos, Arthur Schopenhauer. Seu trabalho
sobre o tema fornece muitos exemplos de estratagemas que so utilizados em nosso dia a dia
por pessoas bem mais comuns.
Conhecer estes estratagemas um trunfo para o negociador. No para que ele os utilize,
embora o prprio filsofo acreditasse que justo opor fogo contra fogo, pelo menos em
algumas circunstancias. Mas para que ele no seja vtima deles. Ns listaremos exemplos de
alguns estratagemas e recomendamos ao leitor a busca da obra original (uma edio em
portugus com comentrios geniais de Olavo de Carvalho est disponvel ao leitor brasileiro).
! Incompetncia Irnica - Quando no consegue encontrar uma forma de responder ao
argumento o oponente pode alegar ignorncia sobre o tema argumentado: O que voc
est dizendo ultrapassa minha capacidade de leigo, soa completamente sem sentido
para mim. Com isto, alem de fazer graa, desmoralizando seu adversrio, ele impede
que voc continue argumentado na linha que o derrotaria.
! Negao da Teoria na Prtica - A negao da validade de uma teoria em face da
prtica pode negar completamente uma argumentao bem instruda. Afirmar que
circunstncias especficas, por motivos no muito claros, impedem a aplicao de um
conceito, alm de bloquear a argumentao, d ao oponente vantagem adicional de o
colocar na posio superior de quem entende a realidade prtica, mesmo que seja
completamente ignorante da teoria.
! Argumento s refutvel por especialista Nos casos em que o oponente um
especialista em um assunto e voc no , ele pode alegar algo que no verdade. Por
Pgina 39 de 190
exemplo: afirmar que voc est pedindo uma coisa impossvel, quando na verdade ele
tem motivos para no atend-lo. Como voc no tem credenciais no assunto, no ter
como contra-argumentar, mesmo que voc saiba, ou suspeite, que ele no est
dizendo a verdade.
! Alternativa Forada O adversrio apresenta duas escolhas, como se fossem as
nicas disponveis e uma delas claramente ruim. A outra aquela que ele quer que
voc aceite. Por exemplo, ele pode perguntar: Os clientes devem ter seus pedidos
atendidos ou o que o cliente quer no tem importncia ?. claro que os clientes tm
importncia. A forma como foi argumentado induz que a concluso, atender a tudo que
o cliente pede, vlida.
! Falhas Lgicas Diversos tipos de falhas na conexo lgica do argumento podem ser
utilizadas. Muitas destas argumentaes tero a aparncia legtima, mas no tm
fundamento. Mudar o significado de um termo no meio do argumento um truque
comum. Passar de um caso especfico para uma concluso geral tambm muito
usado. Outro truque freqente ocorre quando um fato tem como conseqncia possvel
a contribuio para um efeito. A presena deste efeito pode levar o adversrio a culpar
o fato sem demonstrar que a conexo se aplica no caso concreto.
5.4
Cdigo de tica
O PMI recomenda que os profissionais de gerenciamento de projetos se comprometam com

um cdigo de tica. Mesmo que voc no se interesse por esta instituio interessante
conhecer este cdigo e o que a sociedade exige da tica do gerente de projetos. Na verdade,
as exigncias do cdigo so pequenas e os desafios ticos da atuao do gerente de projetos
freqentemente superam estas recomendaes simples.
Artigo I: Os profissionais de gerncia de projeto mantero padres elevados de conduta
pessoal e profissional e:
a) aceitaro a responsabilidade por suas aes.
b) empreendero projetos e aceitaro responsabilidades somente se qualificados por
treinamento ou experincia, ou aps a plena divulgao a seus empregadores ou
clientes das qualificaes pertinentes.
c) mantero suas habilidades profissionais no estado da arte e reconhecero a
importncia da educao e desenvolvimento pessoal contnuos.
d) avanaro a integridade e o prestigio da profisso, praticando-a de uma maneira
honrada.
e) suportaro este cdigo e incentivaro colegas de trabalho e colaboradores a agir de
acordo com ele.
f) suportaro a comunidade profissional ativamente, participando e incentivando
colaboradores e colegas de trabalho a participar.
g) obedecero as leis do pas em que o trabalho est sendo executado.
Artigo II: Os profissionais de gerncia de projeto devem, em seu trabalho:
a) Fornecer a liderana necessria ao projeto de modo a promover produtividade
mxima enquanto esforam-se para minimizar o custo.
b) Aplicar o estado da arte em ferramentas e tcnicas de gerncia de projeto para
assegurar que os objetivos de qualidade, custo e prazo, como determinados no plano
do projeto, sero obtidos.
Pgina 40 de 190
c) Tratar com justia todos os membros da equipe de projeto, colaboradores e colegas
de trabalho, no importando a raa, religio, sexo, idade ou nacionalidade.
d) Proteger membros da equipe de projeto de danos fsicos e mentais.
e) Fornecer oportunidades e condies de trabalho adequadas para os membros da
equipe de projeto.
f) Buscar, aceitar e oferecer crticas honestas ao trabalho, dando crdito para a
contribuio de outros.
g) Ajudar aos membros da equipe de projeto, colaboradores e colegas de trabalho no
seu desenvolvimento profissional.
Artigo III: Os profissionais da gerncia de projeto, em suas relaes com seus empregadores
e clientes, devem:
a) Agir como agentes fiis e confiveis para seus empregadores e clientes nos
assuntos profissionais ou de negcio.
b) Guardar confidncia sobre assuntos de negcio ou processos tcnicos de um
empregador ou cliente, enquanto empregado, e mesmo mais tarde, at que tal
informao seja corretamente liberada.
c) Informar a seus empregadores, clientes, sociedades profissionais ou agncias
pblicas de que so membros ou para os quais possam fazer quaisquer
representaes, de qualquer circunstncia que poderia conduzir a um conflito de
interesses.
d) No dar ou aceitar, direta ou indiretamente, presentes, pagamentos ou servios de
valor maior que o nominal, para ou de pessoas ou entidades que tenham
relacionamentos de negcio com seus empregadores ou clientes.
e) Ser honesto e realista ao reportar a qualidade, o custo e o prazo do projeto.
Artigo IV: Os profissionais da gerncia de projeto, ao cumprir suas responsabilidades
comunidade, devem:
a) Proteger a segurana, a sade e o bem-estar da populao e manifestar-se contra
abusos em reas que afetem o interesse pblico.
b) Buscar estender o conhecimento e a apreciao pblicos da profisso de gerncia
de projetos e de suas realizaes.
Pgina 41 de 190
6 Introduo aos Processos de Planejamento

6.1
Escopo do Produto X Escopo do Projeto
Um projeto definido pelo seu escopo. O seu detalhamento a principal entrada para o
planejamento do projeto. Dentro do contexto de gerenciamento de projetos a palavra escopo
pode ter dois significados:
! Escopo do Produto refere-se as caractersticas e funes que caracterizam o produto
ou servio que o projeto deve produzir. Compe o objetivo do projeto.
! Escopo do Projeto refere-se ao trabalho que precisa ser feito para a produo e
entrega do produto, dentro das especificaes do escopo do produto.
O escopo do produto fruto, principalmente, das necessidades do cliente, enquanto o escopo
do projeto fruto de um acordo entre os stakeholders. O status do escopo do projeto
medido contra o plano do projeto, enquanto que o status do escopo do produto medido em
relao aos requisitos da especificao.
claro que ambos esto bastante interligados e o escopo do produto deve definir o escopo do
projeto. No entanto, esta ligao no total. possvel que existam alteraes no escopo do
produto que no gerem necessidade de alterao no escopo do projeto e vice-versa.
Por exemplo, se o projeto define a colocao de azulejos em uma parede, o cliente pode
alterar a cor do azulejo sem que isto altere o trabalho do projeto. Por outro lado, a tcnica de
colocao, definida no escopo do projeto, pode variar sem que o resultado final mude para o
cliente.
6.2
Work Breakdown Structure
6.2.1 Caractersticas de um WBS

Como j dissemos, o escopo define o projeto. Todas as atividades no projeto se referem ao
escopo de uma forma ou outra. Um dos primeiros passos de um planejamento, que algo
voltado para aes, levantar o escopo que causar estas aes.
Muitos caem na armadilha de gerar, a partir de uma idia geral das necessidades do cliente,
uma lista de atividades, em diferentes nveis de detalhe, que devero ser executadas. H dois
problemas neste procedimento. Primeiro: pode ser que nem mesmo o cliente tenha
compreendido direito as suas prprias necessidades, ou seja, o escopo est altamente
indefinido. Segundo: a lista de atividades gerada desta maneira ser, quase certamente,
incompleta e confusa, pois misturar diferentes nveis de detalhe e depender da memria,
conhecimento e viso do elaborador da lista.
Existe um instrumento bastante simples e prtico para resolver estes problemas, chamado de
Work Breakdow Structure (WBS). Algumas tradues se referem a ele como Estrutura
Analtica do Projeto (EAP). No PMBOK encontramos a definio:
Um Work Breakdow Structure (WBS) um agrupamento deliverable-oriented dos elementos do
projeto que organiza e define o escopo total do projeto. O trabalho que no est no WBS est fora do
escopo do projeto. Com relao declarao do escopo, o WBS freqentemente usado para elaborar
ou confirmar um entendimento comum do escopo do projeto. Cada nvel descendente representa um
incremento no detalhamento da descrio dos elementos do projeto.
Pgina 42 de 190
A idia bsica quebrar o escopo em uma estrutura hierrquica que, nos nveis mais altos,
represente o escopo geral como visto pelo cliente e, nos nveis mais baixos estejam os
elementos mais prximos daquilo que voc coloca em um cronograma como uma atividade.
Vejamos um exemplo:
Projeto XPTO
WBS
Gerenciamento do Projeto
Criao do Ambiente de
Hardware e Rede
Desenvolvimento do
Aplicativo
Estabelecimento
do Projeto
Levantamento
Anlise
Planos
de Gerenciamento
Dimensionamento
Projeto
Acompanhamento
e Controle
Segurana
Construo
Implantao
Homologao
Acompanhamento
de Produo
Implantao
Um Deliverable qualquer produto, servio, resultado ou item, que seja tangvel e verificvel
e que tenha que ser produzido para que o projeto seja concludo. Um deliverable externo
exige aprovao pelo sponsor ou pelo cliente.
Um WBS deliverable-oriented porque construdo com foco neste tipo de produto ou
subproduto. Afinal, ele montado como uma decomposio do escopo a ser entregue.
Entretanto, estes deliverables no precisam ser necessariamente externos. Para melhor
detalhamento do trabalho, deliverables internos e intermedirios podem ser estabelecidos.
Descries de deliverables so, freqentemente, colocadas em um dicionrio WBS. Um
dicionrio WBS inclui, tipicamente, descries de elementos do WBS, mas pode conter outras
informaes de planejamento, tais como datas de cronogramas, custo de oramentos e
designaes de funcionrios responsveis.
A apresentao em rvore, como a da figura, facilita a visualizao, porm, o WBS no pode
ser confundido com o mtodo de apresentao. O mero desenho de uma lista no estruturada
de atividades, em um formato de diagrama hierrquico, no faz disto um WBS. Nem esta
forma obrigatria. De fato, em WBS maiores so comuns o uso de listas indexadas.
Cada item no WBS , geralmente, designado por um identificador nico. Estes identificadores
so, freqentemente conhecidos como code of accounts. Os itens nos nveis mais baixos do
WBS so freqentemente referenciados como pacotes de trabalho (work packages).
Um W
Work Package um deliverable no nvel mais baixo da hierarquia do WBS. Em teoria,
seria possvel destacar cada work package, transformando-o em um subprojeto com seu
prprio gerente de projeto. Estes pacotes de trabalho podem ser mais decompostos em
atividades. Em projetos pequenos, porm, muitos work packages correspondem a uma nica
atividade.
Pgina 43 de 190
6.2.2 Como construir um WBS
O WBS evolui atravs de uma srie de consideraes sobre o escopo do projeto e sua
viabilizao tcnica. No h regras fixas sobre seu tamanho. A profundidade do WBS
depender da complexidade do projeto e do nvel de detalhe necessrio para planej-lo e
control-lo. No entanto, muitas reas de aplicao so cobertas por um WBS de 3 nveis.
O tamanho do WBS tambm no precisa ser fixo dentro de um projeto. Um WBS de alto nvel
pode ser criado nas primeiras fases de definio conceitual do projeto. Mais tarde, a
decomposio dos elementos de nvel mais alto gerar WBSs sucessivamente mais
detalhados.
No h necessidade de cada ramo do WBS ter a mesma quantidade de nveis. Por exemplo:
projetos complexos podem dividir o escopo em fases e definir o trabalho de cada fase logo
antes de seu incio, baseado nos resultados da fase anterior. A lista de testes que sero feitos
em um novo medicamento, por exemplo, podem depender das propriedades descobertas na
fase de pesquisa.
Em adio aos deliverables ligados ao produto do projeto, o WBS tambm pode refletir dois
outros tipos de elementos:
! Atividades de gerenciamento do projeto;
! Marcaes do ciclo de vida do projeto, ou seja as fases do projeto;
No entanto, estes outros elementos devem ser usados apenas no nvel de detalhe necessrio
para organizar as tarefas. Os work packages (elementos de mais baixo nvel) tem como
objetivo identificar tarefas com deliberables especficos e tangveis.
H vrias formas de se organizar um WBS. Por exemplo:
! Por partes do produto Neste caso, divide-se o produto final do projeto em suas
partes constituintes (Ex: Modulo 1, Modulo 2 etc.) e depois se subdivide cada parte
no ciclo de vida de produo. Esta forma muito usada na diviso de um grande
projeto em sub-projetos;
! Por fases de projeto Neste caso, primeiro se divide o projeto de acordo com seu
ciclo de vida (Ex: Projeto, Construo, etc.) e s depois se detalha os sub-produtos;
! Por mesclas destes dois tipos;
O importante que ele represente tudo de significativo que ser feito pela equipe do projeto.
Algumas questes podem ajud-lo a decidir se o WBS precisa ser mais detalhado:
! H necessidade de se aprimorar o nvel de acurcia das estimativas de custo e
durao dos work packages ? A decomposio pode facilitar a estimativa.
! Mais de um indivduo responsvel pelo mesmo elemento do WBS ? Descubra
uma forma de dividir os work packages de modo que cada um fique totalmente
responsvel por sua parte do trabalho.
! Algum work package inclui mais de um tipo de trabalho ou mais de um tipo de
deliverable ? Procure manter o work package especifico para um deliverable
ou tipo de deliverable.
! Algum work package complexo demais para permitir que se acompanhe o
progresso de sua construo ? Decomponha-o de modo a poder melhor gerencilo.
! possvel que o critrio de aceitao do work package possa ser aplicvel sem
que o mesmo esteja completo ? A decomposio poder mostrar deliverables
intermedirios.
Pgina 44 de 190
6.2.3 Utilizao do WBS
Ao construir o WBS temos que manter em mente seus dois objetivos principais:
! Apresentar o escopo de uma forma clara e completa, levantando com o cliente e
com os outros stakeholders quais so os deliverables do projeto e como eles
esto organizados.
! Suportar o planejamento e a diviso de responsabilidades das atividades do
projeto.
Na sua forma original, o WBS uma ferramenta de registro e comunicao de escopo. Ele
deve garantir que o projeto inclua todo trabalho necessrio e que no inclua trabalhos
desnecessrios. Estes dois efeitos indesejveis so comuns em projetos sem uma definio
formal de escopo.
Todo o planejamento do projeto se ergue a partir do WBS, que a principal entrada para
diversos processos de gerenciamento do projeto: Definio de Atividades, Planejamento de
Recursos, Estimativa de Custos, Oramento, Planejamento de Gerncia de Riscos.
O cronograma do projeto deve ser diretamente rastrevel ao WBS, sendo um detalhamento
deste, traduzido em atividades. Cada elemento do WBS deve ser relacionvel com o
organograma da organizao, normalmente atravs de uma Matriz de Responsabilidade.
6.3
Resumo dos Processos de Planejamento
Na introduo ao PMBOK Guide, citamos a existncia de um grupo de processos chamado

Planejamento. Este grupo de processos possui os chamados processos essenciais e os
processos facilitadores.
Os processos essenciais so aqueles que so obviamente necessrios para qualquer projeto,
tais como a estimativa de custos ou a elaborao do cronograma. Ainda assim, muitos
projetos carecem at mesmo destes.
Os processos essenciais so altamente integrados. Em projetos menores, ou at de mdio
porte, pode no haver uma clara separao entre eles. Estes processos, comumente, so
executados juntos, dentro de uma nica atividade de planejamento e de maneira altamente
iterativa. No entanto, existe uma seqncia lgica de como o planejamento deve ser criado.
Mesmo quando no h separao clara da atividade de planejamento em seus processos
bsicos, esta ordem deve estar na mente do planejador.
Os processos facilitadores, como gerenciamento de risco ou qualidade, so ativados de forma
intermitente durante o planejamento. No h uma ordem especfica entre eles. Voc pode
analisar os riscos do projeto, por exemplo, antes ou depois de definir a poltica de qualidade.
Embora os processos facilitadores estejam ausentes de boa parte dos projetos reais, eles no
devem ser considerados como acessrios ou dispensveis. O fato de seu uso no ser to
difundido quanto os processos essenciais, no quer dizer que eles no so importantes na
garantia de sucesso do projeto.
Os diversos captulos deste trabalho trazem informaes especficas dos diversos processos,
tanto facilitadores quanto essenciais. No entanto, antes de entrarmos neste nvel de detalhe,
interessante darmos uma viso geral dos processos essenciais.
O diagrama abaixo mostra a ordem idealizada para os processos essenciais de planejamento.
Estamos, aqui, prximos do formalismo idealizado do PMBOK. Mais tarde teremos a
oportunidade de subverter um pouco esta ordem idlica.
Pgina 45 de 190
Tempo
Tempo
Escopo
Escopo
Planejamento
de Escopo
Definio
de Escopo
Definio
de
Atividades
Custo
Sequenciamento
de
Atividades
Tempo
Tempo
Desenvolvimento
de
Cronograma
Estimativa
de Durao
de Atividades
Planejamento
de Recursos
Custo
Oramento
de
Custos
Custo
Estimativa
de
Custos
Integrao
Desenvolvimento
do
Plano de Projeto
Planejamento de Escopo - Define o escopo geral do projeto

Definio de Escopo - Detalha o escopo em componentes melhores
Definio de Atividades - Detalha as atividades necessrias para entrega dos produtos
Planejamento de Recursos - Determina os recursos necessrios para cada atividade
Sequenciamento de Atividades - Identifica dependncias entre atividades
Estimativa de Durao de Atividades - Identifica a durao estimada de cada atividade
Estimativa de Custos - Estima os custos dos recursos usados nas atividades
Desenvolvimento de Cronograma - Cria o cronograma do Projeto
Oramento de Custos - Aloca os custos no projeto ao longo do tempo
Desenvolvimento do Plano do Projeto Consolida o Planejamento
Analisando o diagrama vemos que ele comea com o Planejamento de Escopo. O escopo do
projeto ser mais bem definido quando for maior a clareza do escopo do produto. Primeiro,
devemos saber o que produzir para ento definir como produzir.
Um documento chamado de Declarao de Escopo (Scope Statement) formaliza algumas
informaes sobre o escopo do projeto tais como:
! Justificativa e Objetivos do Projeto
! Definio dos Produtos e Deliverables do Projeto
Em projetos terceirizados, esta parte do processo pode ser to simples quanto copiar as
informaes de contrato. O prprio contrato (se bem redigido) pode ser considerado como
Declarao de Escopo.
Este processo tambm gera um documento formal chamado de Plano de Gerenciamento de
Escopo . Este plano a primeira seo do Plano de Projeto. Define como o escopo deve ser
gerenciado, de que maneira as mudanas no escopo sero integradas (ou no) ao projeto e
como as necessidades de mudanas de escopo sero identificadas, classificadas e sujeitas
aprovao.
A seguir temos o processo de Definio de Escopo. Este processo se preocupa em dividir as
definies da Declarao de Escopo (Scope Statement), que esto prximas linguagem do
Cliente, em pedaos menores, mais gerenciveis e prximos linguagem do Gerente do
Projeto.
O principal produto deste processo o WBS (Work Breakdown Structure) acompanhado por
um dicionrio com a descrio de cada elemento.
Uma vez que o WBS est pronto, o gerente de projeto parte para o processo Definio de
Atividades. Neste ponto cruza-se definitivamente a linha entre o escopo do produto e o
escopo do projeto. A lista de atividades uma extenso do WBS. Em projetos simples, a lista
Pgina 46 de 190
de atividades poder ser virtualmente idntica ao WBS, mas aqui a nfase est nas atividades
(aes) e no nos produtos e servios visveis para o cliente.
No existe uma definio infalvel sobre o nvel de detalhe adequado para planejamento de
escopo, WBS e lista de atividades mas, normalmente, as responsabilidades so alocadas no
nvel do WBS. Mais tarde, sero definidos recursos necessrios para cada atividade na lista.
Tenha isso em mente na hora de cri-las.
Neste processo, normalmente comeamos a utilizao de softwares de controle de projetos,
como o MS-Project ou o Primavera.
A seguir temos o Planejamento de Recursos que define as caractersticas e as quantidades
de recursos fsicos necessrios para cada atividade.
Recursos so:
! Pessoas;
! Equipamentos;
! Materiais;
Avalie apenas o que possa impactar o projeto. Na maioria dos projetos no h necessidade de
saber, por exemplo, quanto material de escritrio uma atividade gastar.
Em alguns casos, pode ser definido que apenas uma quantidade de recursos pr-estabelecida
estar disponvel. Em outros, a equipe de projeto pode ter que calcular quantos recursos
devem ser alocados para a atividade. Este clculo inicial no gravado em pedra. A
quantidade de recursos pode variar durante outras fases do planejamento, particularmente no
processo de Estimativa de Durao de Atividades.
Uma vez que as atividades foram definidas e suas necessidades detalhadas, passamos para
o Sequenciamento de Atividades. Atividades devem ser sequenciadas por dependncias
inerentes natureza do trabalho. O tipo de dependncia mais comum a Final para Incio,
uma seqncia temporal simples, ou seja, a segunda atividade s poder ser iniciada aps o
termino da primeira
Muitos tipos de diagramas podem ajud-lo a documentar precedncias (Ex: Rede, Flecha,
GERT). O mais comum o grfico de Grantt usado no MS-Project. Nesta ferramenta, uma
dependncia declarada por um link entre as atividades.
Neste momento passamos para a Estimativa de Durao de Atividades. A durao de uma
atividade depende, principalmente, da complexidade da tarefa e da quantidade e qualidade
dos recursos alocados. Nesta etapa, algumas estimativas da quantidade de recursos estimada
podem ser revisadas.
Avalie tanto as economias quanto as deseconomias de escala. Estas ltimas parecem ser as
mais significativas. Em determinadas circunstncias, aumentar a equipe aumenta o tempo da
tarefa em vez de diminu-la. Isto porque equipes maiores representam problemas especficos
em sua administrao.
Sabendo dos recursos e da durao podemos passar para a Estimativa de Custos. Este
processo calcula o custo total do projeto e documenta algumas alternativas de custo
analisadas. Por exemplo, uma atividade terceirizada ter um perfil de custos diferente de uma
feita por equipe prpria.
Custo previsto para as atividades e drivers de custos individuais (Ex. valor hora de um
engenheiro) devem ser registrados.
Nesta etapa criado o Plano de Gerenciamento de Custos, outra seo do Plano de
Projeto , que descreve como as variaes de custo previsto versus real devem ser
gerenciadas. Pode tambm definir um plano de contas para o projeto.
Pgina 47 de 190
A prxima etapa o Desenvolvimento de Cronograma. Aqui se define a data de incio e a
durao de cada atividade. Neste processo est a grande arte do planejamento. Diversas
tcnicas podem ser utilizadas:
! CPM Critical Path Method
! PERT Program Evaluation and Review Technique.
! GERT Graphical Evaluation and Review Technique
! Critical Chain - Na verdade, mais do que uma tcnica de criao de cronograma,
trata-se de uma filosofia de gerenciamento de projetos.
O Cronograma gerado difere do planejamento gerado pelo processo Sequenciamento de
Atividades, principalmente, porque nesta fase se leva em conta a conteno de recursos
entre atividades, ou seja, duas atividades que poderiam ser executadas paralelamente no
podero s-lo porque utilizam os mesmos recursos. O processo que trata estes conflitos
conhecido como Resource Leveling.
Ferramentas de automao de projetos, como o MS-Project, possuem funes que ajudam
nesta tarefa, modificando automaticamente as datas das atividades em conflito. Aqui,
novamente, as estimativas de quantidade de recursos e tempo da atividade podem ser
revistas na tentativa de obter um balano entre o custo do projeto e o prazo de entrega.
Com o cronograma pronto, podemos definir o Oramento de Custos. O Oramento define os
custos do projeto ao longo do tempo, ou seja, o fluxo de dinheiro que dever sair do caixa do
projeto por unidade de tempo. No se deve confundir este custo com o preo do projeto. O
custo uma estimativa tcnica. O preo baseado, evidentemente, na estimativa de custos,
mas tambm nas relaes de mercado entre o cliente que patrocina o projeto e a organizao
que o executa.
Neste processo, as estimativas devem ser obtidas pelo cronograma do projeto.
Estes fluxos de consumo de recursos orados so conhecidos como baselines ou linhas de
base do projeto. Existem vrios tipos de baselines , por exemplo:
! Gastos Contbeis;
! Fluxo de Caixa;
Baselines so usualmente expressas com S-curves que mostram o desenvolvimento dos
valores acumulados pela durao do projeto. Mais tarde, curvas semelhantes com os valores
reais podero ser plotadas para comparao.
Fluxo de
Caixa
Esperado
Valores
Acumulados
Baseline
de Custos
Tempo
Pgina 48 de 190
6.4
O Plano do Projeto Definindo as Regras do Jogo
A maioria esmagadora dos problemas que ocorrem durante o projeto decorrem da falta de
coordenao. Mesmo quando todos concordam que esto no mesmo barco, freqentemente
cada um rema em uma direo diferente. A melhor ferramenta para evitar isto estabelecer
as regras do jogo.
Os clientes precisam saber qual o escopo e como podem modific-lo. O gerente do projeto
precisa saber quem pode aprovar uma mudana de custo ou prazo e como dever justific-la.
Os membros do projeto precisam saber suas responsabilidades. Todas estas regras do jogo
do projeto, e vrias outras, podem ser consolidadas em um documento chamado Plano de
Projeto.
O processo Desenvolvimento do Plano do Projeto utiliza as sadas dos outros processos de
planejamento para criar um documento consistente e coerente, que possa ser usado para
guiar tanto a execuo quanto o controle do projeto.
Este processo quase sempre se repete vrias vezes. Algumas partes do Plano de Projeto,
como por exemplo, os planos de gerenciamento, devem permanecer mais ou menos estveis
ao longo do projeto, enquanto outras sero atualizadas at durante o encerramento.
O Plano do Projeto usado como guia bsico para todos os envolvidos e como documentador
de premissas.
Alguns dos itens encontrados em um plano de projeto so:
! Project Charter Definindo o gerente do projeto e as necessidades de negcio;
! Scope Statement incluindo os objetivos e os subprodutos do projeto;
! Work Breakdown Structure (WBS);
! Estimativas de custos, datas programadas para incio das atividades e atribuies de
responsabilidade no nvel adequado do WBS;
! Baselines de medida de desempenho para prazo e custo;
! Principais marcos e suas datas previstas;
! Mo de obra chave ou necessria;
! Principais riscos, incluindo restries e suposies, e as respostas planejadas para
cada um deles;
! Organograma do Projeto;
! Planos de gerenciamento auxiliares, incluindo:
Plano de gerenciamento de Escopo;
Plano de gerenciamento de Cronograma;
Plano de gerenciamento de Custos;
Plano de gerenciamento de Qualidade;
Plano de gerenciamento de Pessoal;
Plano de gerenciamento de Comunicao;
Plano de gerenciamento de Risco;
Plano de gerenciamento de Aquisio;
! Questes por resolver e decises pendentes;
! Premissas adotadas e decises tomadas;
Pgina 49 de 190
Muitas partes do Plano de Projeto podem e devem ser reaproveitadas de projetos
semelhantes ou criadas a partir de templates. O reaproveitamento dos planos de
gerenciamento, por exemplo, ajudam a criar uma cultura consistente na empresa. Quando isto
acontece, boa parte destes planos pode ser separada da documentao do projeto e ser
armazenada em uma base corporativa de documentos. Em empresas com ISO-9000, por
exemplo, as regras do jogo podem ser armazenadas como procedimentos ou padres.
Aqui, cabe uma advertncia. Projetos so nicos ! Embora possamos e devamos reaproveitar
as regras do jogo, se criarmos procedimentos detalhados e rgidos e os tornarmos obrigatrios
para todos os projetos, estaremos criando uma grande ameaa para o sucesso de qualquer
projeto. De qualquer forma, regras simples so aquelas que tm maior probabilidade de serem
seguidas.
Nos captulos seguintes, detalharemos o que deve estar contido nos planos auxiliares.
aconselhvel que o Plano de Projeto contenha as informaes e regras correspondentes a
cada um deles, mas no necessrio seguir uma estrutura rgida. Os planos de Pessoal e
Comunicao, por exemplo, podem ser facilmente mesclados em uma nica seo do plano
de projeto. O mais importante que haja clareza e simplicidade.
As regras do Plano de Projeto podem ser colocadas em contratos formais quando os projetos
so terceirizados. Isto beneficiar tanto os bons clientes quanto os bons fornecedores. Em
outros casos, uma apresentao do tipo PowerPoint para os Stakeholders pode ser mais
eficiente do que o mero envio de documentos formais que correm o risco de no serem lidos.
6.5
Balanceamento do Projeto
Em qualquer atividade, ns nos deparamos com o problema de limitao de recursos. Sempre

h um prazo limite, um custo mximo ou uma quantidade disponvel de pessoas e
equipamentos. Isto um fato da vida, mas especialmente claro em gerenciamento de
projetos.
Tanto durante o planejamento quanto durante a execuo do projeto, o gerente de projeto
ter que fazer escolhas e estas escolhas tero repercusses positivas e negativas. Elas
tambm no sero tomadas de maneira totalmente livre. Ele deve ter conscincia das
limitaes internas ou externas que so impostas a qualquer projeto. Costuma-se mostrar
estas restries na forma de um triangulo sagrado para o gerente de projeto.
Escopo/Qualidade
Custo /
Recursos
Tempo
! O tempo talvez a maior de todas as restries. O compromisso mais visvel do

gerente de projetos entregar o projeto no prazo. Para resolver problemas de atraso
ele pode tentar obter mais recursos ou autorizar horas extras a um custo mais alto.
Alternativamente, pode tentar diminuir o escopo do projeto. Se ele escolher no fazer
escolha alguma, a equipe tomar por ele, reduzindo a qualidade do trabalho produzido
de modo a gastar menos tempo.
Pgina 50 de 190
! O escopo do projeto sua razo de existncia. Clientes freqentemente mudam de
idia e solicitam coisas no previstas. Para atend-los ele pode ter que negociar mais
recursos ou mais tempo.
! O custo do projeto talvez a dimenso mais flexvel. Enquanto os benefcios do
projeto superarem os gastos, um nvel hierrquico superior pode liberar mais recursos.
No entanto, h um limite para esta flexibilidade. Quando este limite atingido, a
flexibilidade se torna zero. Neste caso, a diminuio de recursos pode gerar atrasos e,
mais freqentemente, concesses no escopo devem ser feitas.
claro que um bom gerente de projetos deve ter o desejo de entregar mais por menos, mas
aderir ao plano, ou seja, obter um balano das dimenses do projeto a melhor forma de
chegar a isto.
Algumas dicas que permitiro alterar uma ou mais destas dimenses so:
! Re-estimar o Projeto medida que o projeto avana, as incertezas diminuem e
certas tarefas podem ter seu prazo diminudo sem prejuzo para o projeto.
! Mover recursos entre tarefas Algumas atividades tm alguma folga e podem ter
algum atraso sem que o projeto inteiro atrase. Outras so crticas para o projeto.
Quando for possvel remanejar pessoal do primeiro tipo de tarefa para o ltimo, podese deduzir o tempo total do projeto sem aumentar os custos.
! Adicionar pessoas ao projeto Quando recursos realmente qualificados esto
disponveis, o aumento do esforo pode diminuir a durao das tarefas. Normalmente,
h um custo adicional envolvido. Em atividades que possuem tarefas que podem ser
executadas em paralelo, com um mnimo de interao entre elas, esta pode ser uma
boa opo.
! Utilizar consultores para aumentar a produtividade Equipes inexperientes tem baixa
produtividade, no importa quanto treinamento receberam. Se for possvel alocar
especialistas que os ajudem a resolver problemas prticos e proporcionem orientao
em tempo real, a produtividade pode aumentar tremendamente.
! Horas extras Horas extras custam mais e so menos produtivas, pois utilizam
recursos j cansados pela jornada normal. Apesar disso, podem ser uma opo em
emergncias e em resposta a problemas.
Equipes raramente reclamam de trabalhar horas extras quando sabem que elas so
decorrentes de falhas de produtividade ou problemas imprevisveis. Quando a data
final do projeto externamente definida (Ex.: os projetos do Bug do milnio tinham
que ser terminados antes de 31/12/1999), a equipe poder ser motivada a aceitar
prazos apertados que inevitavelmente levaro a horas extras. Bons profissionais
compreendem a necessidade desses desafios.
Por outro lado, a utilizao de horas extras j no planejamento do projeto, como uma
forma corriqueira de comprimir os prazos, extremamente negativa. A equipe ver isto
como explorao e/ou demonstrao de falta de competncia na negociao dos
prazos. quase certo que a qualidade do produto sofrer, o projeto ser entregue
atrasado, os custos sero maiores do que o ideal e a equipe ficar insatisfeita.
Um fato interessante constatado na maioria dos projetos que a nfase muda ao longo da
evoluo do projeto. No incio do projeto, a maioria dos stakeholders est preocupada com o
escopo do projeto. Eles querem o melhor produto possvel e podem estar dispostos a negociar
prazo e custo. No entanto, nas fases finais do projeto o cronograma se torna o mestre
absoluto. As pessoas esto comprometidas com a data final e as expectativas dos clientes e
da alta gerncia so facilmente frustradas por alteraes em datas que esto prximas.
aconselhvel que gerente de projeto ajuste suas decises de acordo com esta mudana de
nfase.
Pgina 51 de 190
7 Introduo aos Modelos e Estimativas utilizados em Projetos

Este captulo, necessariamente terico, ser possivelmente um incomodo para os espritos
prticos dos gerentes de projetos. No entanto, muitas teorias so utilizadas de maneira
implcita nas prticas comuns de gerenciamento de projetos. Conhec-las, compreender seus
limites e us-las conscientemente , sem dvida, uma vantagem competitiva. A alternativa
seria continuar seguindo, cegamente, a opinio de outras pessoas.
7.1
Modelos X Realidade
Cada projeto nico por definio. Ter perfis diferentes de custos, benefcios e riscos. Na
pratica, impossvel saber, com absoluta certeza, quais sero os valores reais de cada uma
destas dimenses antes do encerramento do projeto. Em alguns casos, nem mesmo ento.
Isto acontece porque a realidade complexa demais. Muitos fatores contribuem para gerar o
caos e a incerteza. Nossa cultura nos faz sonhar com uma formula bem definida que, uma vez
utilizada, gere previses de resultados com uma preciso conhecida. Para a maioria dos
projetos isto jamais ocorrer !
Para encarar uma realidade catica ns precisamos simplific-la. Precisamos idealiz-la,
descartando a maior parte de suas caractersticas, nos restringindo quelas que temos iluso
de poder controlar.
Esta mutilao da realidade feita atravs da criao de um modelo. Os modelos que usamos
so semelhantes aos cabos inelsticos, corpos pontuais, movimento sem atrito e outras tantas
simplificaes que utilizamos em fsica clssica. Mas existem duas diferenas importantes.
A primeira que no podemos ter certeza da margem de erro de nossos clculos. Podemos
dizer que o comprimento de um corpo de 30cm com um erro de mais ou menos 1 mm. Neste
caso, sabemos com certeza que corpo no mede 31cm mas, quando estimamos a durao de
um projeto em 6 meses, ele poder durar 6 anos ou mesmo nunca acabar. Quando lidamos
com projetos, tratamos com modelos probabilsticos. Acreditamos que o projeto tenha alta
probabilidade de acabar em 6 meses, mas existe uma probabilidade, diferente de zero, de que
ele acabe em 6 anos.
A segunda que muitos modelos usados em projetos so aproximaes muito mais
grosseiras da realidade do que os da fsica. A Curva de Aprendizado ou a Curva de
Preciso X Custo da Estimativa so simplificaes quase risveis. Ainda assim so tudo que
possumos e podem ajudar a treinar e guiar a intuio.
Acreditar na preciso de suas prprias estimativas um erro. No acreditar nas estimativas
um pecado mortal. como se estivssemos em um cassino, em que os dados podem cair
contra ns. Mas existe uma diferena: permitido interferir na sorte. Temos que fazer o que
pudermos (e um pouco mais) para trapacear a banca e transformar nossas profecias em
realidade.
Ao compreender os modelos utilizados em teoria de projetos, o gerente de projetos pode
prever o impacto de suas aes sobre o comportamento do projeto. Neste captulo,
mostraremos algumas tcnicas para melhorar suas chances de fazer uma aposta vencedora.
Mas antes de comear, sopre os dados !
Pgina 52 de 190
7.2
Mtodos de Gerao de Estimativas
Os mtodos de gerao de estimativas so amplamente usados para definir um parmetro

especfico de um projeto. As mesmas tcnicas bsicas podem ser utilizadas para definir custo,
prazo ou quantidade de recursos.
Cada mtodo tem, associado a ele, uma quantidade de trabalho e um nvel de detalhamento
de informaes. No geral, quanto mais preciso o mtodo, mais trabalho e mais informao
ele requer.
7.2.1 Estimativa no Elevador

Muitas atividades, ou mesmo projetos inteiros tm seu tamanho ou custo definidos por uma
pergunta feita dentro do elevador ou ao lado da maquina do caf. Normalmente, este tipo de
estimativa tem um erro em torno de 90%, dependendo da capacidade e conhecimento do
estimador. O nico uso recomendado para este tipo de estimativa est na fase de seleo de
projetos. O tomador de deciso pode ter uma idia brilhante para um projeto e perguntar a
um tcnico quanto ele acha que custaria. Se o numero de zeros for compatvel com o
oramento, o projeto pode ser analisado.
7.2.2 Estimativa por Analogia

A estimativa por Analogia ou por Ordem de Magnitude melhor que a anterior mas ainda
tem uma margem de erro alta. Ela baseada em extrapolaes sobre outros projetos
semelhantes. O estimador gasta algum tempo comparando o novo projeto com uma base de
informaes sobre projetos j encerrados. No final ele pode decidir se o projeto ou tarefa tem
a metade do tamanho de um outro ou 25% maior do que um terceiro.
7.2.3 Estimativa Detalhada (Bottom-Up)

A estimativa detalhada chamada tambm de estimativa Bottom-Up. A idia postergar a
estimativa at ser possvel ter um entendimento maior do projeto, principalmente do WBS.
Cada Work Package ou cada atividade pode ser avaliada por um especialista que define o
custo, o prazo e a quantidade de recursos necessrios para a execuo. Os especialistas
podem utilizar estimativas por analogia ou por modelos matemticos para determinar o
parmetro desejado. Pode-se tambm lanar mo de experimentos e prottipos para este
propsito.
Uma vez que cada atividade tenha sido estimada, elas so sucessivamente sumarizadas nos
nveis superiores do WBS at que se tenha a estimativa de todo o projeto.
A principal desvantagem deste mtodo o nvel de detalhe e trabalho exigido em relao aos
anteriores. Durante as fases iniciais do projeto, pouco provvel que as informaes
necessrias estejam disponveis. Mesmo depois, o gerente de projeto pode ter dificuldade de
gastar o tempo e o custo necessrios para esse tipo de estimativa.
7.2.4 Estimativas por Modelos Matemticos

Nas estimativas por modelos matemticos o estimador conhece alguns parmetros a respeito
do produto do projeto e possui um modelo (normalmente emprico) que estima a dimenso
requerida (Ex.:custo ou prazo) de maneira automtica.
Na construo civil, por exemplo, existem modelos em que o estimador s precisa inserir a
quantidade de metros quadrados de uma casa para receber a estimativa do custo de
construo. Outros modelos so mais complexos. Alguns modelos de desenvolvimento de
software exigem a determinao ou estimativa de dezenas de parmetros de entrada. Alm
disso, nem sempre os parmetros so to objetivos quanto metros quadrados. comum que
Pgina 53 de 190
o estimador tenha que definir algo to intangvel quanto o grau de comprometimento do cliente
em uma escala de 1 a 5.
A estimativa por modelos tem duas importantes vantagens. A primeira que certos
parmetros podem estar disponveis ou serem estimveis muito cedo, no ciclo de vida do
projeto. o caso, por exemplo, do tamanho em metros quadrados de uma casa. Basta saber
o tamanho do terreno e uma aproximao do percentual que ser usado como rea
construda. Um dos fatores que torna estes parmetros facilmente estimveis o fato deles se
referirem ao produto do projeto, ou seja, ao escopo, e no s atividades do projeto. Como o
escopo definido antes das atividades que vo produzi-lo, aquele est disponvel bem mais
cedo que estas.
A segunda vantagem que ela pode ser utilizada para recalcular o projeto caso o cliente
mude de idia e aumente os parmetros combinados. Se ele resolver construir um anexo a
casa, por exemplo, podemos mostrar o mesmo programa que usamos na proposta original e
recalcular o custo baseado no aumento de escopo, medido em metros quadrados construdos.
Isso pode evitar muita discusso.
Um fato que se deve ter em mente quando lidamos com estimativas por modelos que,
apesar de sua praticidade, elas so sempre menos precisas do que as estimativas BottomUp. Por elas utilizarem frmulas matemticas, muitas pessoas tm a iluso de que so
extremamente precisas, mas isso est longe da realidade. A experincia de um especialista
no dimensionamento de tarefas leva em conta fatores sutis que so completamente ignorados
pelos modelos. Os modelos so sempre simplificaes grosseiras da realidade. Se no
fossem, seriam to complexos que se tornariam inteis para uso prtico.
Muito cuidado deve ser tomado na escolha do modelo. Alguns deles variam exponencialmente
em relao a pequenos erros nos dados de entrada. Modelos bem conhecidos e de uso
relativamente comum respondem a pequenas variaes nos parmetros de configurao, com
aumentos de mais de 50% no tamanho calculado do projeto. Quando esses parmetros so,
por sua vez, estimativas imprecisas, o modelo se torna no s intil, mas prejudicial.
Outro problema que muitos modelos no so escalveis. Isso quer dizer que um modelo
utilizado para construir um pequeno prdio ser praticamente intil na estimativa de custos de
um arranha-cu e vice-versa. Eles funcionam apenas dentro do tipo de projeto para os quais
foram criados e no so facilmente adaptados.
Recomenda-se a calibrao constante dos modelos, utilizando informaes histricas de
projetos semelhantes. A maioria dos modelos tem determinadas quantidades (Ex.
produtividade, custos individuais, etc.) que no so considerados parmetros de entrada, uma
vez que podem permanecer constantes entre projetos, mas que podem ser ajustadas pelo
confronto com experincias reais. So parmetros de configurao ou calibrao.
Veremos mais tarde os limites do que podemos obter com a calibrao de modelos. Por
enquanto, basta dizer que nenhuma calibrao ir melhorar a performance do modelo alm da
sua preciso intrnseca, que costuma no ser muito boa.
Uma forma intermediria de usar os modelos matemticos tom-los como uma primeira
estimativa. Depois, os especialistas podem ajustar os parmetros de configurao a fim de
trazer o modelo mais para perto da realidade especfica do projeto. Por exemplo, alguns
modelos utilizam como parmetro de configurao a produtividade da equipe.
A informao histrica utilizada para o clculo de valores mdios pode conter dados sobre
projetos potencialmente muito diferentes. Desta maneira, a mdia histrica pode no ser um
valor adequado para calibrar o modelo para o projeto atual. Em vez disso, podemos pedir a
um ou mais especialistas que conheam as caractersticas especficas do projeto e da equipe
que ajustem o valor da produtividade. A partir deste momento a produtividade fixada e
qualquer negociao com o cliente utilizar esse valor. Portanto, temos as vantagens de
negociao providas pelo uso de modelos matemticos, ao mesmo tempo em que
Pgina 54 de 190
confrontamos dois resultados de estimativas: a do modelo e a da experincia dos
especialistas, de modo a obter um resultado mais preciso.
7.2.5 Estimativa por Fase

Estimativa por fase a tcnica favorita de 9 entre 10 gerentes de projetos porque gera
compromisso com a acurcia da estimativa em uma fase de cada vez. Esta tcnica reconhece
que no prtico estimar todo um projeto, justamente no momento em que a incerteza est
no seu mximo, ou seja, no seu incio. Qualquer projeto dividido em fases que determinam
milestones ou pontos de controle. A estimativa por fase se aproveita desses pontos de
controle. Ela se desenvolve da seguinte maneira:
1. Quando a primeira fase est para comear, fazemos uma estimativa da ordem de
magnitude do projeto inteiro (por exemplo, via analogia ou via modelo matemtico
parametrizado). Fazemos tambm uma estimativa detalhada da primeira fase do
projeto via Bottom-Up.
2. No final da fase, recalculamos a ordem de magnitude do resto do projeto e fazemos a
estimativa detalhada para a fase seguinte. A estimativa do projeto ser mais acurada
que a anterior, porque agora aumentamos nosso conhecimento sobre o projeto.
3. Com os novos custos, tomamos decises sobre a continuidade do projeto ou a
abrangncia do escopo. Pode se tomar a deciso de suspender o projeto antes de
gastos maiores sejam feitos ou pode-se ajustar o escopo para reduzir o custo total.
Neste momento, o Gerente de Projeto deve renegociar o equilbrio do projeto.
4. Repetem-se todos os passos a cada fase, at o final do projeto.
A razo pela qual os gerentes de projetos gostam da estimativa por fase deve ser bvia. Eles
s precisam se comprometer com a estimativa da fase atual e com uma ordem de grandeza
do projeto. Para os financiadores do projeto este benefcio pode parecer duvidoso.
Na verdade, a estimativa por fase uma tcnica de controle e reduo de risco. Se a
realidade provou que uma estimativa foi muito otimista melhor para todos reconhecer isso o
mais rapidamente possvel. Em projetos desenvolvidos com custo varivel, comum que o
Sponsor s descubra que o projeto gastou mais do que o limite de retorno de investimento
quando tarde demais. A estimativa por fase reduz esse risco. Mesmo em projetos
terceirizados a custo fixo, um erro grande demais na estimativa do projeto pode levar o
prestador de servio a abandonar o projeto (mesmo pagando multa) ou pior ainda: reduzir a
qualidade em lugares no facilmente visveis para o cliente, de modo a reduzir os custos. No
final todos perdem.
7.3
Pressupostos e Estimativas Parametrizadas
Na verdade, mesmo as melhores estimativas no passam de um palpite educado. Voc faz

suposies, implcitas ou explcitas, sobre o que vai acontecer e executa alguns clculos em
cima disso. Fazer suposies inevitvel, mas existem problemas especficos com relao s
suposies implcitas.
Digamos que voc tenha que justificar sua estimativa. Ou que tenha que recalcul-la a partir
de uma mudana no projeto. A verdade que, pouco tempo depois da estimativa original,
voc no se lembrar do que levou ou no levou em conta na estimativa.
Resolver este problema relativamente simples. Voc s precisa transformar os pressupostos
implcitos em explcitos. Documente as restries e pressupostos que voc utilizou na
estimativa. Voc pode, por exemplo, documentar suas suposies a respeito de produtividade
mdia, volume de trabalho, porcentagem de retrabalho, tamanho do problema etc.
Em alguns casos, voc registrar pressupostos e restries qualitativas como por exemplo:
Somente os funcionrios atuais sero utilizados no projeto, sem contrataes ou
Pgina 55 de 190
terceirizaes ou Ser utilizada uma tecnologia no dominada pela equipe. Outras vezes,
porm, voc ser capaz de supor um numero, um parmetro, para sua estimativa. Voc
poder assumir, por exemplo, que a produtividade mdia da equipe ser de 2 unidades por dia
e a equipe ter 10 pessoas.
Neste caso, voc poder documentar tambm o modelo matemtico que voc usou para
transformar estes parmetros em uma estimativa. Para recalcular uma estimativa, basta que
voc altere os valores dos parmetros e reaplique a formula. Tambm ser mais fcil para que
voc justifique sua estimativa ou consiga outra opinio a respeito.
A documentao das estimativas tambm poder ajud-lo a no cometer erros em futuros
projetos. Se uma atividade durou muito mais do que o previsto, por exemplo, a produtividade
mdia que voc utilizou como parmetro pode estar superestimada.
Este mesmo raciocnio pode ajud-lo a identificar a causa de problemas no projeto atual. Se
voc utilizou um pressuposto que no se realizou na prtica, isso se materializar como uma
divergncia entre o planejado e o realizado. Analisar os pressupostos evitar que voc exera
esforo de correo sobre a causa errada.
Pgina 56 de 190
7.4
Estimativas e Medidas
7.4.1 Estimativas como funes de probabilidade

Como j notamos, uma estimativa no um valor e nem mesmo uma faixa de valores. Ela
mais bem representada por uma funo de probabilidade. relativamente fcil analisar uma
funo de probabilidade se dispomos de seu grfico. Basta que examinemos a rea embaixo
da curva. Ela representa a probabilidade acumulada de que o valor real seja menor ou igual a
um valor especfico.
Uma das funes de probabilidade mais comuns a chamada curva normal.
0,3
Probabilidade
0,25
0,2
0,15
0,1
0,05
9,
00
10
,0
0
11
,0
0
12
,0
0
13
,0
0
14
,0
0
15
,0
0
16
,0
0
8,
00
7,
00
6,
00
5,
00
4,
00
3,
00
2,
00
1,
00
0,
00
Tempo
Neste caso, temos uma simetria semelhante de uma faixa de valores. Um erro raramente se
estende muito, nem para menos nem para mais, do valor mdio. Se utilizarmos em nosso
planejamento o valor de pico da curva, teremos 50% de chance de estarmos certos. Se
dobrarmos este valor, teremos mais de 99% de chance.
Infelizmente, muitas estimativas so mais bem modeladas por uma distribuio Gama, como a
mostrada abaixo:
0,16
Probabilidade
0,14
0,12
0,1
0,08
0,06
0,04
0,02
9,
00
10
,0
0
11
,0
0
12
,0
0
13
,0
0
14
,0
0
15
,0
0
16
,0
0
8,
00
7,
00
6,
00
5,
00
4,
00
3,
00
2,
00
1,
00
0,
00
Tempo
Neste caso a distribuio de probabilidade no simtrica. Usando os valores do grfico

acima estimaramos que tarefa ir durar 5 dias. A probabilidade absoluta que ela termine
durante o 12o dia (com 7 dias de atraso) o dobro da que ela termine durante o primeiro dia
(4,5 dias adiantado).
Se analisarmos a probabilidade acumulada, o grande problema ser que o acrscimo de
tempo disponvel para a tarefa cada vez menos efetivo, do ponto de vista do aumento da
probabilidade de acertarmos nossa estimativa.
Pgina 57 de 190
Observemos novamente nosso exemplo. existe 60% de chance da tarefa ser entregue em 4
dias. Sabemos disso porque a rea embaixo da curva de 0 at 4 representa 60% da rea total
sobre a curva. Se dobrarmos a estimativa para 8 dias, cobriremos 90% da rea. Isso parece
valer a pena, afinal aumentamos nossa chance em 30%. Mas, se dobrarmos novamente a
estimativa para 16 dias, a probabilidade ficar em torno de 99%. O custo-benefcio de
acrescentar mais dias ao projeto cada vez pior.
Em projetos reais os nmeros variam bastante, mas a idia a mesma. Assim, se um projeto
tem 90% de chance de ser entregue em seis meses, pedir um prazo de um ano no
aumentar a probabilidade de ele ser entregue no prazo, tanto quanto seria de se esperar a
primeira vista. Veremos mais tarde que, em alguns casos, a probabilidade diminui.
Concluso: faa estimativas realistas e gerencie seu plano de acordo com elas. Adicionar uma
margem de segurana de tempo e dinheiro para contingncia de riscos identificados um
hbito prudente. Exagerar no custo e no prazo, na esperana de entregar o projeto mais cedo
ou garantir sua entrega sem esforo no produtivo, nem honesto.
7.4.2 Nvel de Detalhamento das Estimativas

Uma grande quantidade de autores prescreve um remdio para diminuio da incerteza:
projetos mais detalhados. Este um bom conselho, at certo ponto. Essa abordagem, porm,
tem limitaes pouco discutidas.
Vejamos primeiro o lado positivo. Analisaremos um modelo que sustenta a prtica de detalhar
o planejamento at que obtenhamos tarefas bem pequenas. A idia bsica que uma tarefa
muito grande difcil de ser estimada com preciso. Dividi-la em sub-tarefas aumenta a
acurcia total da estimativa, desde que a acurcia de cada estimativa das sub-tarefas
permanea a mesma da grande tarefa.
Digamos, por exemplo, que em uma tarefa de 100 dias se espere um erro de 10%, ou seja 10
dias para mais ou para menos. Se quebrarmos esta tarefa em 5 tarefas de 20 dias, com os
mesmos 10% de erro, cada tarefa ter, individualmente, um erro provvel de 2 dias. No
entanto o erro das 5 tarefas em conjunto ser de apenas cerca de 2,5 dias. O erro total, neste
caso, a raiz quadrada da soma dos quadrados dos erros individuais. possvel demonstrar
isto, matematicamente, mas simples compreender este fato de maneira intuitiva: como a
margem de erro varia nos dois sentidos, espera-se que algumas tarefas terminem mais cedo
do que o prazo e algumas mais tarde. Umas compensando outras.
O que percebemos que estimar o tamanho de tarefas muito grandes pode levar a erros
muito grandes. Este um dos motivos (mas no o nico) pelo qual uma estimativa dada em
no elevador ou ao lado de uma maquina do caf muito ruim: o projeto como um todo
estimado. Quando criamos um WBS e fazemos uma estimativa de cada Work Package, a
preciso melhora enormemente. Se detalharmos o WBS em atividades, poderemos aprimorar
ainda mais a preciso da estimativa. Contudo, neste ponto, comeam os problemas. Esse
raciocnio, perfeitamente razovel, d origem aos conselhos: quebrar qualquer tarefa que
tenha um tamanho mximo pr-determinado, ou aumentar o nvel de detalhamento do plano
de atividades at que isto no seja mais possvel.
Cronogramas com centenas ou milhares de tarefas, para projetos relativamente pequenos,
resultam deste tipo de conselho e acabam sendo ingerenciveis. Erros comeam a acontecer
escondidos na multido de tarefas. Em alguns casos, ningum, muito menos o gerente do
projeto, consegue entender o cronograma Godzilla. Na maioria dos projetos, os problemas de
um cronograma excessivamente detalhado superam os possveis benefcios na melhora das
estimativas. No entanto, h um motivo mais bsico contrrio ao detalhamento excessivo. O
problema est escondido no prprio modelo.
Teoricamente, quando fazemos a estimativa sobre uma tarefa individual, a preciso da
estimativa varia com o esforo desprendido. Nessa viso, sempre poderamos melhorar uma
Pgina 58 de 190
estimativa dedicando mais esforo. De fato, parece que quanto mais trabalharmos a
estimativa, melhor a preciso. Se fizermos testes ou ensaios, se contratamos especialistas
ou aplicamos modelos matemticos, a incerteza tender a diminuir.
A curva abaixo demonstra o comportamento geral deste modelo. Inicialmente, um pequeno
esforo adicional gera um aumento significativo na preciso da estimativa. Isto faz sentido. Se
usarmos 2 segundos para dar um palpite ou meia hora para analisar o problema antes de dar
a estimativa, isto certamente far diferena. Depois, porm, entramos em uma fase em que
pensar mais sobre a estimativa nos render uma dor de cabea, mas no uma maior preciso.
Incerteza na Estimativa
250
200
150
100
50
0
0,00
0,02
0,06
0,10
0,14
0,18
0,22
0,26
0,30
Esforo Gasto no Processo de Estimativa
Seguindo este modelo, imagine que voc dispe de um certo esforo, digamos 25 horas, para
gastar com a estimativa do projeto. Se voc dividir esta tarefa em tarefas menores, mantendo
o custo total da estimativa constante, o esforo disponvel para cada tarefa diminui. Assim, se
o projeto tiver 5 tarefas, poderemos gastar 5 horas com cada tarefa (25 horas divididas por 5
tarefas). Mas fazendo isso, a preciso da estimativa de cada tarefa no permanece constante
e, sim, diminuir devido ao menor esforo dependido. Se a preciso da estimativa de cada
tarefa diminui, como se comporta a estimativa do projeto? Podem acontecer trs casos:
! A estimativa original estava do lado direito do grfico acima Nesse caso, ao dividir a
tarefa em tarefas menores, a incerteza individual no diminuir significativamente e o
efeito da variao individual de cada tarefa nos daria uma preciso total maior.
! A estimativa original estava no centro do grfico acima Nesse caso, a perda de
preciso das estimativas individuais compensaria o efeito da subdiviso das tarefas e a
preciso total permaneceria mais ou menos a mesma.
! A estimativa original estava do lado esquerdo do grfico acima Nesse caso, ao dividir
a tarefa em tarefas menores, a incerteza individual diminuir significativamente e o
efeito da variao individual de cada tarefa no seria suficiente para compensar este
efeito de aumento da incerteza. A preciso do plano detalhado seria menor.
Em resumo: divida o projeto em atividades at um nvel de detalhe em que a preciso da
estimativa das atividades seja razovel, mas no alm. Tarefas de 5 minutos costumam ser
to absurdas quanto tarefas de 1 ano, a menos que o projeto todo dure 2 horas.
Pgina 59 de 190
7.5
Curvas de Aprendizagem
A presena de seres humanos uma forma maravilhosa de adicionar caos a um projeto

porque ela sempre introduz variao. Mas nem sempre esta variao est contra o gerente de
projetos.
Alguns projetos, particularmente aqueles que so caracterizados por criao intelectual, ou
mesmo por tarefas sensveis aprendizagem, passam a ter uma caracterstica interessante
quando a mesma tarefa, ou tarefas muito semelhantes, so recorrentes durante o projeto.
Vemos esta caracterstica, por exemplo, quando temos um grupo de trabalhadores que devem
montar dezenas de prottipos complexos que sero utilizados nos testes de um novo produto
ou quando um sistema de informao composto por centenas de programas em um novo
ambiente de desenvolvimento.
O que acontece que a performance de um ser humano aumenta significativamente com a
repetio da tarefa. Estudos j demonstraram que, em geral, a performance melhora por uma
percentagem fixa cada vez que se dobra a quantidade de vezes que a tarefa executada.
Esta percentagem chamada taxa de aprendizagem. Ela uma constante, mas como o
modelo exige que a quantidade produzida dobre para que ela seja aplicada, a performance
tende a se estabilizar com o tempo.
Digamos, por exemplo, que um indivduo produz o primeiro prottipo em 10 minutos e o
segundo em 8 minutos. Devemos esperar que a taxa de aprendizagem seja de 80% e
permanea assim at a estabilizao da produtividade. A quarta pea poderia ser produzida
em 6,4 minutos e a oitava em 5,12. Existe uma frmula que, uma vez fixada a taxa de
aprendizagem, permite estimar o tempo inicial a partir do tempo de produo da n-sima pea
ou vice versa.
Tn = T1 n ( log r log 2 )
T1 a tempo de execuo da primeira tarefa, Tn o tempo de execuo da n-sima tarefa, n
o nmero de repeties e r a taxa de aprendizagem. A curva de aprendizado, em nosso
exemplo, teria a forma abaixo:
120
100
80
60
40
20
25
23
21
19
17
15
13
11
Para tornarmos o modelo um pouco mais prximo da realidade, estabeleceremos que, aps
um certo nmero de repeties, a curva de aprendizado deixa de ter efeito e a produtividade
permanece constante. Na prtica, mais ou menos isto que acontece, embora esse modelo
no leve em considerao as flutuaes estatsticas de produtividade, ou seja, o que acontece
com a produtividade de um funcionrio treinado quando ele dormiu mal na noite anterior, ou
brigou com a esposa de manh cedo.
Pgina 60 de 190
Assim, vamos imaginar que a curva mais prxima da realidade seja esta abaixo:
120
100
80
60
40
20
25
23
21
19
17
15
13
11
Se definirmos um certo s (menor que n) como sendo o nmero de repeties necessrias

para estabilizao, ento o tempo total de uma tarefa seria dado pela frmula:
Tempo Total = Ts (n s ) + T1 p ( log r log 2 )

p=1
A grande pergunta agora : como isto afeta o gerente de projeto ? claro que poucos
gerentes de projeto tm tempo ou necessidade para calcular curvas de aprendizado, mas
usaremos este modelo para criar uma intuio fundamental que diz respeito ao planejamento
de durao de uma atividade.
Digamos que o nosso amigo gerente de projeto saiba que um profissional experiente possa
criar uma pea em 45 minutos e ele tem 25 peas para produzir. Nada mais natural do que
alocar um total de 18:45 minutos para a tarefa. O conhecimento necessrio para isto se limita
a regra de 3. Mas, sabendo que a equipe inexperiente, como ele deve corrigir esta
estimativa ? A resposta para isto : depende !!! A tabela abaixo nos ajudar a entender o por
qu.
Caso 1
Caso 2
Caso 3
Caso 4
Caso 5
Caso 6
Peas
Produtividade
dos Experts
25
10
25
10
25
10
45
45
45
45
45
45
Tempo
Experts
18:45
7:30
18:45
7:30
18:45
7:30
Taxa
80%
80%
84%
84%
75%
75%
Produtividade
Media dos
Novatos
52,3
63,2
57,1
69,5
49,6
57,2
Tempo
Novatos
21:46
10:31
23:47
11:35
20:40
9:31
Diferena
na
Estimativa
16%
40%
27%
54%
10%
27%
Analisemos a tabela comparando os casos 1 e 2. Temos a mesma taxa de aprendizado para

os dois casos mas, no primeiro, nossa tarefa produzir 25 peas e no segundo, 10 peas.
Ora, o que ocorre que, com apenas 10 peas, duas coisas acontecem:
! A primeira que no h tempo para que o treinamento chegue a seu mximo. A
produtividade mxima atingida de 48 minutos por pea.
! A segunda que a quantidade de peas produzidas no gera tempo suficiente para
que as tentativas iniciais, extremamente lentas, tenham sua influncia atenuada na
mdia de produtividade.
Pgina 61 de 190
Esses dois efeitos reunidos fazem com que a diferena de produtividade entre um expert e um
novato seja relativamente baixa no primeiro caso (16%) e extremamente danosa no segundo
(40%).
Agora comparemos o caso 3 com o caso 5. Ambos produzem 25 peas e nos dois casos
ocorre tempo suficiente para que os novatos atinjam o nvel de produtividade dos experts. Mas
h uma diferena importante entre eles, a taxa de aprendizado.
No caso 3, a taxa de aprendizado de 84%. O trabalho com a pea mais difcil de se
aprender do que prevamos no caso 1. Os novatos mover-se-o mais lentamente em direo
produtividade mxima, s atingindo-a na ltima pea fabricada.
O caso 5 o oposto. Nossos novatos no mais espertos. Eles aprendem a uma taxa de 75%.
Conseqentemente, eles atingem a produtividade mxima na stima pea. A partir da, so
experts. O erro da estimativa, no caso 5 de apenas 10%, mesmo usando apenas novatos,
enquanto que o erro no caso 3 de 27%.
120
100
80
75%
60
84%
Expert
40
20
25
23
21
19
17
15
13
11
Que lies ns obtemos nesta matemtica toda? Algumas lies muito simples, extremamente
bvias, mas que so freqentemente relegadas durante a tomada de deciso:
! Se o projeto curto, provavelmente o custo adicional de contratar especialistas pode
ser compensatrio se comparado a perda de produtividade de uma equipe de novatos.
! Se o projeto longo, os novatos tero tempo para aprender e provavelmente sero um
grande investimento para futuros projetos. Em termos de produtividade, eles j sero
experts mas o custo dificilmente ter sido corrigido a ponto de atingir o dos experts
originais. Alm disso, medida que o nmero de experts disponveis aumenta, seu
custo mdio diminui.
! Tecnologias complexas levam mais tempo para serem absorvidas do que as mais
simples. S porque voc teve sucesso em alocar uma turma de estagirios para um
projeto anterior no significa que voc possa fazer isto sempre. Curvas de aprendizado
podem ser radicalmente diferentes e isto pode fazer toda diferena do mundo.
! Mesmo que a tecnologia seja a mesma, diferenas individuais na capacidade de
aprendizado podem ser imensas. Um grupo de novatos, inexperientes, mas
inteligentes e com uma boa formao, podem ter curvas de aprendizado muito
melhores do que outros de menor capacidade. Normalmente, estas diferenas
individuais podem ser notadas nas primeiras tentativas do novato e esta
precisamente a melhor hora para substituio dos casos extremos.
Pgina 62 de 190
7.6
Introduo ao Estudo de Variaes
Um sistema definido como uma rede de componentes independentes que trabalham juntos
para alcanar a meta do sistema. Um projeto sempre ocorre dentro de um sistema. Cada um
dos Stakeholders um componente independente. As instalaes, recursos disponveis,
mtodos, etc. tambm so partes do sistema.
Um processo um conjunto de atividades executadas pelo sistema de modo a produzir algo.
Entregar o escopo do projeto, dentro do prazo e do oramento , sem duvida, um processo.
Na verdade, vrios processos diferentes podem ser executados pelo mesmo sistema para
produzir resultados equivalentes, no entanto a eficincia desses diferentes processos pode ser
muito diferente. Um mesmo projeto, por exemplo, pode ser planejado e executado de diversas
maneiras.
Uma atividade do projeto igualmente um processo, ou sub-processo, executado pelo
sistema ou por parte dele.
Se pudermos executar um mesmo processo de modo a produzir repetidamente o mesmo
produto e medirmos a performance do sistema ao longo do tempo, veremos que ela varia.
Esta, na verdade, uma das causas por que um projeto nico. Dois projetos com o mesmo
escopo e executados pelo mesmo sistema tero performances diferentes, ainda que
ligeiramente. A variao causada por muitos motivos. H variao nas pessoas, nos
materiais, nos mtodos, no equipamento e no ambiente. Em todo o processo, haver muitas
pequenas causas de variao que se combinam para produzir a variao total.
Se quisermos lidar com a variao devemos entender como ela funciona. Edward Deming
conhecido como o homem que ensinou qualidade aos Japoneses. Deming afirmava que uma
falha quase universal na interpretao de fenmenos nas organizaes a de supor que todo
efeito indesejvel, um defeito ou um acidente por exemplo, culpa de uma pessoa
(normalmente a mais prxima) ou causada por um evento especial. Ele demonstrou que a
maioria dos problemas so conseqncias do prprio sistema, ou seja , da nossa maneira de
trabalhar e apenas um nmero menor poderia ser atribudo a eventos transitrios ou externos
ao sistema. Assim, ele classificou dois tipos de causas de variao:
! Causas Comuns de Variao Aquelas que so inerentes ao sistema. Se o sistema
estiver sob controle, as causas comuns de variao provocaro variaes de
performance dentro de limites de controle, estatisticamente calculveis. O sistema
mostrar resultados que se espalham aleatoriamente em torno de um ponto central.
! Causas Especiais de Variao So eventos ou fatos especiais que no fazem parte
do sistema de causas comuns. Elas so detectadas por resultados fora do normal, ou
seja, que fogem ao padro aleatrio. O sistema nem sempre afetado por elas,
embora sua ocorrncia no precise ser um fato absolutamente raro. Shewhart as
chamava de causas designveis para indicar que elas poderiam ser isoladas e lidadas
individualmente.
Imagine que a figura a seguir represente os resultados de seis lanamentos feitos por um
excelente jogador de dardos. Por melhor que ele seja, necessariamente sujeito a causas
comuns de variao e no consegue acertar sempre exatamente no centro do alvo. Mas seus
resultados esto consistentemente dispersos ao redor de uma pequena rea prxima ao
centro. Isso o que faz dele um bom jogador.
No entanto, um dos dardos est nitidamente fora do padro. Ele quase jogou o dardo para
fora do alvo. Este resultado atpico uma indicao de que uma causa especial de variao
agiu. Nos casos reais, seria necessrio um grande numero de resultados, (bem mais do que
apenas seis) todos na pequena rea em torno do alvo, para que estabelecssemos o padro
das causas normais.
Pgina 63 de 190
O lanamento deste
dardo deve ter tido
uma causa especial
Desempenho geral
com baixa disperso em torno do centro
Um resultado fora do padro indica que uma Causa Especial agiu. O que ele no pode fazer
esclarecer qual Causa Especial especfica agiu neste lanamento. A primeira coisa que nos
vem cabea que o jogador simplesmente errou. Ou seja, o culpamos pessoalmente. O que
Deming nos incentiva a lembrar que no podemos fazer este julgamento priori. Algum
pode, por exemplo, ter esbarrado no brao do jogador.
Causas Especiais de Variao devem ser tratadas caso a caso e com muito cuidado. Porm
existem algumas estratgias genricas para lidar com elas. Ns as veremos a seguir, mas
antes vamos voltar nossa ateno para as Causas Comuns de variao.
Observe a figura com dois alvos. Imagine que representam os resultados de dois amigos
testando suas habilidades no jogo de dardos. O alvo da esquerda mostra os resultados do
primeiro jogador. Eles esto aleatoriamente espalhados em relao ao centro, assim seus
resultados parecem ser afetados apenas por causas comuns. O problema deste jogador que
a disperso grande demais. Seu modo de jogar no confivel. No h nada
especificamente errado no seu jogo que possa ser apontado como seu grande problema. Para
que seus resultados melhorem, ele tem, simplesmente, que praticar mais e aprimorar sua
tcnica.
Desempenho geral
com problemas
de variao
Vis solucionvel por

calibrao
O caso do segundo jogador diferente. Como sempre, inevitvel que ele seja afetado por
Causas Comuns e seus dardos tambm esto aleatoriamente espalhados em uma regio do
alvo. Mas a disperso dos dardos menor do que a do primeiro, o que indicaria uma tcnica
superior. O problema desse jogador de outro tipo. Seu jogo tem um vis para o lado direito
do alvo. Se ele corrigir isto, talvez calibrando sua mira um pouco mais para a esquerda ou
descobrindo o que, no seu lanamento, gera o vis, ele ter resultados muito superiores ao
primeiro. No se trata de uma causa especial, uma vez que ele, consistentemente, desvia
para a direita. A causa do desvio interna ao sistema do jogador. De maneira semelhante s
Pgina 64 de 190
Causas Especiais, um vis de resultado normalmente causado por um pequeno nmero de
causas e assim mais fcil identific-las e aprimorar o sistema.
Entender bem estes diferentes tipos de variao importante por diversos motivos. Um deles,
Deming acreditava, que uma grande quantidade de problemas de gerenciamento so
decorrentes de dois erros bsicos:
! Erro Tipo 1 - Atribuir uma variao a uma causa especial quando, na verdade, ela
estava dentro dos limites de variao comum do sistema. Ou seja, tomar uma variao
de Causa Comum como sendo de Causa Especial;
! Erro Tipo 2 - Atribuir uma variao ou erro ao sistema quando, na verdade, ela ocorreu
devido a um evento externo. Ou seja tomar uma variao de Causa Especial como
sendo de Causa Comum;
Ambos so extremamente comuns e tm como conseqncia a piora do desempenho do
sistema. Deming idealizou uma experincia para ajudar a demonstrar estes erros e seu
impacto. Para montar o experimento (e voc pode tentar isto em casa) precisamos de um alvo
estendido no cho, um funil colocado a uma altura fixa, mas que possa se movimentar
paralelamente ao alvo e uma bolinha que possa passar pelo bico do funil. O objetivo do
sistema fazer a bolinha acertar o centro exato do alvo.
Perceba que o sistema no requer habilidade. Basta jogar a bolinha no funil. Todos os nossos
jogadores de dardos, por exemplo, seriam equivalentes. De certo modo, este sistema muito
semelhante aos modelos matemticos de gerao de estimativas. Voc joga informao pelo
funil do modelo e ele gera uma estimativa de custo ou prazo, que est a certa distncia do
centro, ou seja, do valor real medido aps o projeto.
Se, colocarmos o funil exatamente sobre o centro do alvo e jogarmos a bolinha um certo
numero de vezes, teremos uma distribuio aleatria semelhante da figura a seguir. A
variao entre os resultados devido a Causas Comuns de variao apenas.
10
0
-10
-5
0
-5
-10
Pgina 65 de 190
10
Se esta comparao lhe parece inadequada, ns concordamos. Seria preciso que o funil
estivesse a uns 10 metros de altura para que a distribuio do ponto de queda da bolinha se
aproximasse da impreciso dos modelos que usamos em projetos. Mas digamos que um alto
gerente esteja insatisfeito com os resultados e exija que o modelo seja aprimorado. Ele sugere
(ou ordena) que o caminho lgico usar os dados reais de sada para calibrar o modelo.
Assim, um procedimento passa a especificar que o funil seja movido mesma distncia a
partir da origem, mas na direo contrria do ultimo ponto. Se o ultimo ponto ficar a dois
centmetros direita do centro, colocamos o funil dois centmetros esquerda. Se ele estiver
um centmetro para cima, a posio do funil passar a estar um centmetro abaixo.
Se tentarmos o experimento com o modelo calibrado, teremos uma distribuio similar
mostrada a seguir.
10
0
-10
-5
10
-5
-10
Podemos ver que a disperso piorou. Esse o resultado de se atribuir uma variao comum a
uma causa especial. Um erro do tipo 1. Para que a disperso diminusse seria necessrio
melhorar o sistema e no simplesmente calibr-lo.
Isso no quer dizer que a calibrao no funciona de maneira geral. Calibrao um
instrumento de correo de vis, como vimos no exemplo dos dardos. Mas calibrao um
recurso que raramente melhora a disperso. Ela apenas centraliza o modelo.
Erros de tipo 1 so to comuns quanto danosos. Tendo compreendido o resultado de uma
tentativa de calibrao em um sistema apenas com causas comuns, voc pode avaliar o
impacto de pessoas sendo punidas ou premiadas pela performance que elas tm em um
sistema como este, onde as variveis que realmente importam esto fora do seu controle.
Disso decorrem as tentativas mais absurdas de calibrar o sistema ou forar resultados. Isto
o que fazemos todos os dias na maioria das empresas.
Vejamos um pequeno exemplo. Imagine que uma determinada atividade do projeto envolva
alguns caminhes indo e voltando em um trajeto determinado. A quantidade de sinais
fechados no caminho causa uma variao no tempo de viagem. Esta seria uma causa comum
inerente ao caminho escolhido. Por outro lado, um pneu pode furar ou um veculo parado pode
gerar um engarrafamento. Estas so causas especiais.
Deming argumenta que punir um componente do sistema por produzir fora dos limites de
qualidade no funciona. Ele acredita que, nestes casos, o processo, ou seja, o modo de
executar as tarefas, que est doente e ele que deve ser aprimorado. Por definio, metade
das performances ficar acima da mdia e metade abaixo da media. Isto no significa
necessariamente mrito para os que ficaram acima nem falha dos que ficaram abaixo.
verdade que as pessoas so parte do sistema e que alguma variao realmente devido
performance individual. Mas, em muitos sistemas, a influncia da performance individual
pequena em relao a influncia de outros fatores. Isso contrasta de forma absurda com o fato
de que culpar pessoas a ao de correo predileta em nossas organizaes.
Pgina 66 de 190
Se a performance de um sistema est dentro dos limites esperados de qualidade,
provavelmente a melhor coisa a fazer deix-lo como est. Caso contrrio, devemos atuar
sobre as partes do processo que podem diminuir as causas comuns de variao. Seres
humanos so apenas uma destas partes.
Em nosso exemplo, ao final do dia, um determinado motorista dever ter a pior mdia de
tempo de viagem. Isso inevitvel. Algum tem que ser o pior. Se a performance geral estiver
dentro das necessidades do projeto, no devemos tomar atitude nenhuma.
Se acreditarmos que o tempo de viagem est atrapalhando a produtividade e tomarmos a
atitude de dispensar aquele o motorista, no dia seguinte outro tomar seu lugar com o pior
tempo. Na verdade, um motorista diferente provavelmente seria o pior mesmo que ele
permanecesse. No culpa dele se o nmero de sinais vermelhos foi maior. Se escolhermos
outra rota, com menos sinais, poderemos melhorar o tempo mdio. Isto seria melhorar o
sistema. Demitir o motorista seria um erro do tipo 1.
Quando lidamos com Causas Especiais de Variao temos que ter uma abordagem diferente.
Se as variaes normais de um processo tm origem em uma infinidade de causas comuns,
as variaes especiais so normalmente causadas por uma nica ou poucas causas. um
trabalho relativamente mais simples isolar causas especiais.
Decidir qual a nossa reao a elas mais complexo. De maneira simplificada, temos duas
maneiras genricas de reagir contra estas causas:
! Atuar no sistema Podemos atuar dentro do sistema no sentido de evitar que a causa
ocorra ou preparar uma reao caso ela ocorra.
! Ignor-la Se a probabilidade de uma nova ocorrncia da mesma causa for baixa, na
maioria dos casos lev-la em conta s ir piorar o desempenho do sistema.
Digamos que um motorista sistematicamente demore bem mais do que os outros. Temos um
indcio de que uma causa especial de variao em relao ao sistema est ocorrendo, pois ela
s afeta esse motorista. Por outro lado, como o atraso sistemtico, se trata de uma causa
comum em relao a esse motorista. Podemos conversar com ele e tentar descobrir a origem
do problema. A resposta pode ser que esse motorista especfico responsvel pelo transporte
de material explosivo. Neste caso devemos ignorar esta variao ou arcar com o risco de um
desastre.
Por outro lado, podemos descobrir que o motorista sempre dirige o mesmo caminho e que
este est como problemas. Podemos gerar aes corretivas que melhoraro a manuteno do
caminho e eliminar a causa especial de variao.
Podemos tambm descobrir que ele um mau motorista e que costuma parar para uma
cerveja e um papo durante o expediente, apesar de toda tentativa dos supervisores em tentar
mudar seu comportamento. Neste caso, poderemos demiti-lo. Mas faremos isso com o
conhecimento de que melhorar o sistema.
Ainda falta analisar o segundo tipo de erro. O erro do tipo 2 impede o administrador de ver e
remover uma causa especial de variao, ignorando oportunidades de grandes melhorias na
variao do processo. Em projetos, este tipo de erro se manifesta, por exemplo, como um
tratamento pouco efetivo dos riscos envolvidos. Riscos so, por definio, causas especiais de
variao e devem ser tratados como tais. Se um risco ou efeito externo se torna muito comum,
as pessoas tendem a incorporar seu impacto nas estimativas do projeto, tratando-o como uma
condio inerente ao sistema. comum que uma tarefa que leve apenas alguns dias para ser
feita, passe a ter uma estimativa medida em semanas, porque as pessoas contam, por
exemplo, com atrasos do fornecedor. Isso um erro do tipo 2.
Pgina 67 de 190
7.7
O Mtico Homem-Ms
Quando dimensionamos uma tarefa, freqentemente usamos uma medida para descrev-la: o
Homem-ms. Em termos simples, o equivalente de trabalho que um homem produz em um
ms. H variaes equivalentes como: Homem-dia ou Homem-ano. Trata-se de uma
abstrao bastante til para compreender o tamanho de um empreendimento. Se dissermos
que uma tarefa tem 5 Homens-dia, sabemos que ela pequena, mas se necessita de 50
Homens-ano percebemos imediatamente que ela possui um tamanho considervel.
Esta mtrica muito utilizada, durante o planejamento, no dimensionamento de tarefas. Ela
mascara completamente se foram usados 25 homens trabalhando por dois anos ou 100
homens trabalhando por seis meses. Isso facilita seu uso.
Se dimensionarmos uma tarefa como tendo 20 Homens-dia podemos, durante o planejamento
do cronograma, ou at mesmo durante sua execuo, decidir se usaremos 1 profissional
durante vinte dias ou colocaremos 2 profissionais para que terminem em dez dias.
Como muitas das prticas utilizadas por vrios gerentes de projeto, esse raciocnio simples,
direto, matemtico, lgico e tambm falacioso e perigoso.
Em 1975 Frederick Brooks escreveu um livro sobre sua experincia como gerente do projeto
OS/360 da IBM, um mega empreendimento pelos parmetros da rea de informtica, que
consumiu 5.000 Homens-Ano de trabalho. No captulo que deu nome ao livro, Brooks nos leva
a uma concluso impressionante:
Adicionar mais recursos humanos a um projeto de software atrasado garante

que ele se atrase ainda mais.
Embora suas concluses tenham sido originalmente criadas para projetos de engenharia de
software, cada vez mais se demonstra sua aplicabilidade a muitos outros projetos. De uma
maneira geral, grandes projetos sofrem problemas diferentes de projetos pequenos. Isto
acontece principalmente devido diviso de trabalho.
Para comear, podemos fazer alguns clculos simples. Em um projeto com 3 pessoas, o
nmero de canais de comunicao individuais entre os participantes apenas 3.
Se analisarmos um projeto com 6 pessoas, o numero de canais de comunicao possveis

chega a 15.
Pgina 68 de 190
No geral, sendo n o nmero de pessoas no projeto, o nmero de canais de comunicao
ser de n(n-1)/2. Para qualquer um que j brincou de telefone sem fio fica absolutamente
obvio os problemas de comunicao que apenas esse aspecto do problema pode gerar.
Alm disso, em um projeto com um pequeno nmero de pessoas, uma nica pessoa executa
vrias tarefas interligadas. Se aumentarmos o nmero de pessoas para que iguale a
quantidade de tarefas, qualquer deciso em uma tarefa que afete uma outra tem que ser
comunicada pessoa responsvel pela segunda. No grupo original, a pessoa responsvel
pelo grupo de tarefas podia avaliar o impacto em seu prprio trabalho, tanto no que ainda iria
fazer, quanto no que j estava teoricamente pronto. Com o aumento do nmero de pessoas, a
anlise do impacto de decises nas sub-tarefas se torna muito complexa e exige uma
formalizao muito maior.
Conforme a quantidade de pessoas aumenta, a logstica envolvida em coorden-la se torna
cada vez mais complexa. Em um determinado ponto, as tarefas do gerente de projetos tm
que comear a serem divididas com outras pessoas. Imagine o que isto gera? Mais
complexidade na comunicao.
Junte a isso tudo o fato simples de que determinadas tarefas so indivisveis. O exemplo mais
famoso um velho ditado popular: Uma mulher pode gerar um filho em 9 meses, mas 9
mulheres no conseguem gerar uma criana em um ms. O mesmo acontece com muitas
tarefas do dia a dia. Nestes casos, dividir o trabalho atrapalha e no gera nenhuma vantagem.
Um efeito pior acontece quando a troca de prazo por esforo ocorre no meio da execuo da
tarefa. Digamos que uma tarefa, estimada em 12 homens-ms tenha uma equipe inicial de 3
membros. O cronograma mostrar a tarefa completa em 4 meses. Agora imagine que, aps o
trmino do segundo ms, apenas um quarto do trabalho est pronto. Parece que a tarefa ir
atrasar. Mas sejamos otimistas e digamos que os problemas ficaram para trs. Ento temos 9
Homens-ms de tarefas (3/4 do original) para serem feitas em 2 meses. Como, em teoria,
precisamos de 4 homens e meio para realizar a tarefa, resolvemos alocar mais 2 pessoas na
equipe. Os 5 membros deveriam ser capazes de entregar a tarefa em menos de 2 meses. Mas
as duas pessoas adicionais no esto treinadas e gastaro tempo de pelo menos um membro
da equipe original para que recebam as informaes e habilidades necessrias. Imagine que
isso leve um ms. Durante este ms, somente duas pessoas estaro trabalhando e, se tudo
correr bem, tero produzido 2 homens-ms, restando ainda 7 homens-ms e apenas um ms
de prazo. A tarefa terminar ainda mais atrasada do que se a equipe original tivesse sido
mantida.
claro que estes nmeros foram preparados para dramatizar o efeito. A realidade no to
simples e ajustar o nmero de recursos de uma tarefa, para obter o melhor equilbrio de custo
e prazo, um recurso importante para o gerente de projetos. Abusar deste recurso sem
conhecer seus limites, porm, flertar com o fracasso.
Pgina 69 de 190
7.8
Estudo sobre as causas de atrasos em projetos
Quando examinamos o tempo de durao de uma tarefa, vimos que ele definido como
funes de probabilidade Gama. Se nossa estimativa coincide com a mdia da curva, temos
50% de chance de estarmos corretos. Uma questo interessante : Quando pedimos uma
estimativa para algum, em que percentual acumulado esta estimativa provavelmente estar ?
Se pensarmos um pouco, veremos que o elaborador da estimativa dificilmente usar a moda
(valor mais freqente) ou a mdia. Ele no quer estar errado em metade das vezes e isto o
que a mdia tem a oferecer, 50% de chance. A moda oferece ainda menos. Ele sabe que no
existe como ter certeza absoluta da estimativa, mas ele deseja estar certo em pelo menos
90% dos casos. Ora, dependendo do formato da curva, 90% de estimativa pode ser um tempo
3 ou 4 vezes maior do que a mdia.
Vejamos o exemplo abaixo:
Mdia = Estimativa Otimista

Estimativa Razovel
Estimativa Pessimista
30m
15m
90%
75%
45m
60m
50%
75m
90m
105m
120m
Segurana
Segurana
Trata-se de uma tarefa impossvel de ser executada em menos de quinze minutos. Existe
50% de chance dela ser executada em 40 minutos e 75% de chance dela ser executada em 1
hora. Mas se pedirmos uma estimativa, quase certo que receberemos 2 horas como
resposta. E esta uma boa resposta. No h nenhuma tentativa de criar uma folga artificial. A
pessoa apenas sabe que, em alguns casos, o trabalho se complica um pouco e pede um
prazo que cubra estas eventualidades.
Em teoria, se nenhum problema acontecer, a tarefa acima poderia acabar sendo executada
em 45 minutos, ou seja, em menos da metade do tempo planejado. Na verdade, este tipo de
coisa deveria acontecer a pelo menos um tero das tarefas. O problema que, na prtica, isso
nunca ocorre. Caso ocorresse, os atrasos em outras tarefas seriam parcialmente
compensados pelas tarefas que terminassem mais cedo e os projetos teriam muito mais
chance de sucesso.
Para entender o que realmente ocorre devemos analisar a psicologia por trs da equipe e do
gerente do projeto. O primeiro ponto se refere ao no aproveitamento das tarefas que
terminam adiantadas.
Pgina 70 de 190
Existem dois motivos para isto
! Quando uma tarefa termina antecipadamente o gerente de projeto no est preparado
para responder a isto. Como conseqncia, os recursos para a tarefa seguinte podem
no estar disponveis. Normalmente, o gerente acredita que no vale a pena
renegociar a alocao dos recursos e acaba mantendo a data original.
! Quando tarefas so terminadas antes do prazo, as pessoas tendem a no reportar o
fato, pelo menos no imediatamente. Muitos tm medo de que, na prxima estimativa,
o prazo seja diminudo com base em um resultado de sorte. Eles tm muito a perder e
pouco a ganhar informando que a tarefa est adiantada.
No entanto, nem sempre isso que ocorre. Freqentemente, as tarefas realmente terminam
atrasadas ou no fim do prazo, por mais que exista um tempo de segurana embutido no prazo.
Isso no quer dizer que as estimativas foram pessimistas, muito pelo contrrio.
Lembre-se dos tempos do colgio. O que acontecia quando um professor lhe dava um tempo
razovel para estudar para a prova, digamos 3 semanas ? Alguns alunos, verdade,
comeavam a estudar imediatamente. De modo que, muito antes da data do teste, j estavam
preparados. Mas a maioria tinha um comportamento diferente. Ns espervamos at os
ltimos dias para comear a estudar. Se acabssemos descobrindo que a matria era mais
complexa do que parecia, ou que precisvamos consultar um livro na biblioteca, no tnhamos
mais tempo para reagir. Os resultados freqentemente apareciam nas notas.
Nos projetos, tambm acontece a chamada Sndrome do Estudante. Se uma tarefa parece
ter folga suficiente, o esforo ser pequeno no incio do prazo. medida que o tempo passa, e
a folga irremediavelmente perdida, a equipe volta sua ateno para a tarefa e descobre
coisas inesperadas. Mas a, tarde demais e a tarefa acaba atrasando.
7.9
Inflao de estimativas
O comportamento descrito na seo anterior (estimar com 90% de certeza) no deve ser
confundido com o expediente de artificialmente inflar estimativas. Pessoas que inflam
estimativas tm como objetivo ser capazes de, com tranqilidade, entregar os produtos sob
sua responsabilidade antes do prazo, e assim ganhar a fama de milagreiros. um hbito
ilegtimo e contra-produtivo para o projeto. Como vimos, se uma tarefa termina antes do prazo,
o projeto pode no estar preparado para iniciar a prxima.
Um aspecto que torna esta prtica ainda mais danosa o fato de que a Sndrome do
Estudante tambm se aplica aqui. Sabendo que o prazo est superestimado, a equipe pode
esbanj-lo e acabar se atrasando.
Provises de contingncia de tempo e recursos devem ser explicitadas no planejamento do
projeto. Previses j so imprecisas o bastante sem que se acrescente desonestidade na
equao.
Pgina 71 de 190
8 Custos
8.1
Plano de Gerenciamento de Custos
O Plano de Gerenciamento de Custos uma das partes do Plano do Projeto.

O gerenciamento de custos tem a tarefa bsica de controlar os custos dos recursos
necessrios para as atividades do projeto de forma que o oramento do projeto seja cumprido.
No entanto, tambm deve ser considerado o efeito das decises no custo de utilizar o produto
do projeto. Certos tipos de economias feitas durante o projeto levam a enormes custos de
manuteno e propriedade.
O plano deve estabelecer como as variaes entre o orado e o realizado devem ser
respondidas. Por exemplo, variaes pequenas podem ser ignoradas enquanto variaes
maiores podem gerar respostas especficas. Isto estabelece os limites de liberdade de ao
do gerente do projeto.
Devem ser definidos tambm os procedimentos pelos quais uma mudana no oramento
aprovado pode ser feita. Isso pode incluir a burocracia requerida e os nveis de aprovao.
8.2
Dialtica de Custos
No capitulo passado, ns analisamos o processo de estimativas. Agora veremos uma

aplicao muito especial dos mtodos de estimativas: a estimativas de custos.
O custo real de um projeto depende das quantidades e valores dos recursos utilizados que,
por suas vez, dependem da produtividade, do escopo do projeto e dos mtodos que utilizamos
para produzi-lo. Mas estas variveis s so totalmente conhecidas a posteriore. No momento
do incio do projeto o escopo ainda est sujeito a mudanas. Nosso planejamento ainda
incerto e no se tem conhecimento preciso da produtividade. Enfim, tudo incerto !
O oramento destinado ao projeto, porm, definido neste momento e espera-se que o
gerente de projeto cumpra este oramento a despeito de se tratar, no fundo, de uma obra de
fico.
Essa situao leva a um conflito inevitvel: de um lado, o gerente do projeto e a equipe
tentaro obter um oramento que lhes permita entregar o projeto com alguma folga, mesmo a
despeito de toda incerteza no futuro. De outro, o cliente que coloca a mo no bolso, tenta
fazer com que os custos sejam os menores possveis. O fato que, se qualquer um destes
lados tiver uma deciso unilateral sobre o oramento, os interesses da organizao
certamente sero prejudicados.
atravs da dialtica entre estas duas vises que um oramento slido porm enxuto pode
ser concebido. De uma maneira geral, os clientes usaro duas tcnicas de estimativas:
! Estimativa no Elevador O cliente sabe o quanto est disposto a gastar com o
projeto e, dessa maneira, estima o oramento do projeto.
! Estimativa por Analogia Tendo alguma experincia em projetos passados, o cliente
pode fazer um tipo precrio de estimativa por analogia e obter uma aproximao do
oramento do projeto.
O gerente de projetos, por outro lado, dar preferncia a tcnicas mais precisas de
estimativas. Um dos problemas que ele enfrenta o fato de que estas tcnicas necessitam de
mais dados e mais tempo na sua elaborao. Assim, muitas vezes, nos momentos iniciais do
projeto, o cliente j tem um nmero para apresentar, mas o gerente de projeto, no. Isto,
freqentemente, faz com que o oramento seja simplesmente empurrado para o projeto.
Pgina 72 de 190
As tcnicas prediletas dos gerentes de projetos so:
! Estimativa Detalhada (Bottom-Up) Esta tcnica s pode ser utilizada quando o
cronograma, ou pelo menos o WBS est pronto e os recursos necessrios para cada
atividade j esto definidos. Ento s uma questo de som-los para obter o
oramento do projeto inteiro.
! Estimativa por Modelos Dados alguns parmetros do produto, em vez do projeto,
pode-se tambm estimar o esforo e, conseqentemente, o custo. Se o escopo ainda
no estiver detalhado, este mtodo sofre o mesmo problema do anterior, ou seja,
precisa que o trabalho do projeto j esteja um tanto adiantado antes de ser utilizado.
Esses mtodos de estimativas, na verdade, podem ter diferentes nveis de preciso. O
gerente de projetos pode usar um WBS provisrio ou arbitrar parmetros para o modelo.
Desta maneira, ele ter uma estimativa um pouco melhor que a do cliente. Se ele puder no
se comprometer com estimativas to vagas, melhor, mas se ele no tiver um nmero para
negociar, o cliente certamente ter o dele.
8.3
Oramento Top-Down com Rateios,
Idealmente, primeiro deve ser definida uma estimativa confivel e depois o oramento dever
ser definido. Mas, como dissemos, freqentemente esta ordem natural aparece invertida. O
gerente de projeto pode, ento, lanar mo de um tipo top-down de oramento.
A idia bsica , uma vez definido o oramento total, rate-lo pelas atividades que compem o
projeto. Evidentemente, os custos definidos de maneira bottom-up tero um valor diferente
do oramento alocado de maneira top-down. Restam as opes de usar recursos mais
baratos, menos recursos ou us-los por menos tempo.
Os responsveis pelas atividades certamente argumentaro que isto prejudicial ao projeto e
que o oramento dado insuficiente. Algumas vezes, eles tero razo, mas freqentemente
este raciocnio est errado.
O que no se observa que as estimativas para cada atividade so apenas isto: estimativas.
Se lembrarmos do padro de distribuio Gama de probabilidade, quando estimativas so
feitas buscando 90% de sucesso, existe uma boa chance de que um esforo muito menor seja
suficiente. Se o gerente de projetos ratear o oramento proporcionalmente s estimativas do
modelo bottom-up, ele estar reduzindo a chance de sucesso de cada atividade de 90%
para, digamos 75%, mas estar longe de zerar esta chance. Estamos simplesmente
aumentando o perfil de risco do projeto. Algo que, do ponto de vista do negcio, pode ser
aceitvel.
claro que, nestas condies, estaremos trabalhando com uma incerteza maior e,
certamente, algumas das atividades no conseguiro cumprir o oramento. Para se proteger
contra essa eventualidade, o gerente de projeto no deve ratear todo o oramento recebido.
Ele deve reservar um montante que permita o socorro daquelas atividade que realmente
deveriam ter recebido um oramento maior.
Dentro dos limites do razovel, a utilizao de oramentos mais apertados e da tcnica TopDown pode levar a projetos de melhor custo/benefcio para a organizao. No entanto, esta
tcnica razovel, se mal utilizada, pode levar ao desastre. Ao tentar ensinar o burro a parar
de comer, acabamos com um burro morto.
Pgina 73 de 190
8.4
Oramentos por Fase
Oramentos por fase utilizam o mecanismo de estimativa por fase. A idia quebrar a grande
negociao de oramento do incio em negociaes menores ao longo do projeto.
No incio do projeto, a negociao sobre o oramento total feita normalmente e com as
imprecises de praxe. Adicionalmente, define-se que parte deste oramento deve ser alocada
para a fase inicial do projeto. Essa estimativa tem trs vantagens sobre a estimativa total.
! Como o horizonte de tempo menor, as estimativas tm menos incerteza. Quanto
mais no futuro est uma atividade, menor a confiana que podemos ter no que
realmente ocorrer.
! O planejamento detalhado da fase inicial pode ser feito rapidamente e assim teremos
um modelo Bottom-Up com que podemos nos comprometer j no incio do projeto.
! Normalmente as fases iniciais tm o custo menor proporcional ao projeto, assim, erros
no oramento desta fase tem menor possibilidade de influenciar negativamente o
projeto.
Espera-se que, ao final de cada fase, uma viso mais ntida do projeto se forme e a
quantidade de incerteza diminua. No modelo de oramento por fase, necessrio que o
cliente se comprometa com essa evoluo. Ao final de cada fase, feita uma nova estimativa
de ordem de magnitude para o projeto como um todo, alm de uma estimativa detalhada para
a prxima fase.
A estimativa do projeto total deve ser ajustada por essa compreenso maior sobre o projeto.
Para isso, o cliente deve estar disposto a renegociar sua viso inicial. No necessrio que
ele ceda ao oramento bottom-up feito de forma tcnica, mas apenas que ele reconhea que
o projeto mudou e reajuste suas prprias expectativas. O gerente de projetos, por sua vez,
deve adaptar seus custos projetados ao oramento disponvel.
Para facilitar essa negociao, um modelo matemtico de estimativa uma ferramenta
bastante til. Os modelos matemticos definem o tamanho do projeto com base em
parmetros medidos no escopo. No incio do projeto, pode ser calculado um tamanho
estimado com as informaes disponveis. Se o cliente concordar em usar o modelo como
uma forma de medir o esforo do projeto, a cada fase, o gerente do projeto pode apresentar o
novo clculo e us-lo como base da negociao. Assim, se o modelo matemtico acusa que o
novo tamanho do projeto 25% maior do que o original, o gerente do projeto pode pleitear
que o oramento total aumente em 25%. claro que pedir no ganhar, mas a negociao
ter um ponto de partida tangvel e razovel.
8.5
Contabilizao dos Custos
O gerente de projetos deve compreender como os custos do projeto so mapeados na

contabilidade da organizao. Em alguns casos, contas e centros de custo especficos so
criados para grandes projetos. Mas, na maioria das vezes, as despesas devem ser reportadas
dentro da estrutura contbil existente.
O gerente de projeto pode pedir ajuda rea de contabilidade da empresa, no sentido de
analisar as despesas do projeto e mape-las no plano de contas da organizao.
Em alguns casos, alm deste mapeamento, outros Stakeholders podem exigir que as
informaes de custo sejam organizadas segundo critrios diferentes. Por exemplo, se o
projeto pertence a uma organizao e o cliente pagador a outra, este ltimo pode solicitar que
as despesas sejam apresentadas contra o trmino das atividades, enquanto a organizao
hospedeira registra as despesas no momento em que ocorrerem.
Pgina 74 de 190
8.6
Nvel de Esforo
O que chamamos de Nvel de Esforo ou Level of Effort (LOE) o trabalho ou custo

adicional que ocorre, em maior ou menor intensidade, durante todo o projeto, mas que no
est associado a nenhuma tarefa especfica. O salrio do gerente do projeto e pessoal de
apoio, seguros, despesas legais, custos de viagem e estada, custos de manuteno da infraestrutura do projeto, aluguel de um escritrio especialmente montado para o projeto com
gastos de telefone e luz, todos so exemplos de Nvel de Esforo.
Todos os projetos tm alguma quantidade de Nvel de Esforo. Em alguns casos, ele pode
representar at 20% do custo total. Mais comumente encontramos nveis de esforo na ordem
de 10%.
O que torna este tipo de custo especial que ele depende, essencialmente, da durao do
projeto. Se uma pendncia adia a entrega de uma pequena parte do projeto por um ms, isto
pode significar um esforo direto muito baixo. No entanto, isto tambm pode significar pagar
mais um ms de aluguel do escritrio.
Desta maneira, quando contabilizamos o efeito de atrasos no projeto temos que nos certificar
de levarmos em conta tambm estas despesas indiretas.
Este efeito no atua somente em atrasos no final do projeto. Quando um projeto pra, por
qualquer motivo, por exemplo devido a um embargo legal, estas despesas continuam atuando
mesmo que nenhum trabalho esteja oficialmente sendo produzido.
Pgina 75 de 190
9 Cronograma
9.1
Plano de Gerenciamento de Cronograma
O Plano de Gerenciamento de Cronograma define como o cronograma ser criado e

gerenciado. A escolha da filosofia de gerenciamento (Ex: PERT/CPM ou Critical Chain)
uma deciso importante e deve ser tomada no incio do projeto.
9.2
Ciclos de Vida
Embora projetos sejam nicos, aqueles que pertencem a mesma rea de atuao (ex.
desenvolvimento de sistemas, construo de prdios etc) costumam apresentar uma estrutura
geral comum. Essas estruturas normalmente esto divididas em fases mais ou menos bem
definidas. Essas fases permitem que o controle do projeto seja facilitado e que qualquer
stakeholder entenda como o projeto est adiantado pela mera referncia fase em que est.
Em conjunto, as fases so chamadas de Ciclo de Vida do Projeto. Projetos com ciclos de vida
semelhantes devem ter WBSs semelhantes.
Cada fase marcada pela entrega de um ou mais deliverables. Normalmente, o
encerramento de uma fase um momento de avaliao em que se questiona se o projeto tem
condies de passar para a prxima fase. o momento, tambm, de verificar e corrigir erros
que seriam mais custosos de sanar em pontos mais avanados do Ciclo de Vida.
costume destacar as datas em que se espera que uma fase termine por marcos ou
milestones em nosso planejamento e cronograma. Estas datas sero aquelas que alguns
Stakeholdes lembraro da existncia do projeto e questionaro seu status.
9.3
Criao de um Cronograma
No captulo 6, vimos alguns processos de planejamento cujo propsito bsico era a gerao
de um Cronograma. Estes processos seguem uma seqncia idealizada de criao do
cronograma. Essa seqncia sugere, por exemplo, a determinao dos recursos necessrios
para cada atividade antes da gerao da estimativa de durao. Na prtica, o ajuste da
quantidade de recursos pode depender da durao calculada da atividade. Uma atividade
considerada longa demais pode receber mais recursos enquanto outra, considerada muito
dispendiosa, pode ter recursos cortados, tornando-a mais demorada. Estes trade-offs so
feitos diversas vezes, ajustando-se o cronograma em diversas iteraes, at que o projeto,
como um todo seja otimizado.
Em linhas gerais, o processo :
1 detalhar, a partir do WBS, as atividades necessrias para entrega dos produtos;
2 determinar os recursos necessrios para cada atividade. A primeira aproximao
feita de maneira idealizada;
3 identificar dependncias entre atividades;
4 estimar a durao de cada atividade usando recursos definidos e calcular o
tamanho inferido;
5 estimar os custos dos recursos utilizados nas atividades;
6 executar o Resourse Leveling do cronograma;
7 interagir com os passos de 2 a 6, otimizando o custo, o tempo e a utilizao de
recursos totais do projeto;
Pgina 76 de 190
9.3.1 Definindo as Atividades
O WBS deve ser a ferramenta bsica de planejamento de atividades. Cada atividade deve
contribuir de alguma forma para a elaborao do escopo. Assim, cada atividade deve estar
relacionada com uma parte da hierarquia de escopo no WBS.
A definio de atividades normalmente feita com o uso de algum software de gerenciamento
de projetos como o MS Project ou o Primavera. A facilidade que estas ferramentas
proporcionam ao moderno gerente de projetos pode ser uma beno duvidosa. Um gerente de
projetos inexperiente pode se sentir tentado a abrir a ferramenta e comear a listar as
atividades que, ele pensa, sero necessrias ao projeto. fcil inserir novas tarefas no
software, medida que vamos lembrando delas. O resultado ser uma enorme lista de tarefas
com diferentes nveis de detalhe e sem nenhuma garantia de que todos os aspectos do
projeto foram cobertos.
Se, por outro lado, o gerente de projetos utilizar o WBS como guia, ele ter maior
probabilidade de abordar o problema de forma organizada e completa. Os nveis superiores do
WBS se tornam tarefas de sumrio do MS Project. Nveis intermedirios tambm so
registrados como tarefas de sumrio, mas que so sub-tarefas das anteriores. Finalmente, as
atividades bsicas do projeto so registradas como sub-tarefas destas ltimas. Nesse
processo, o gerente de projeto pode ajustar o nvel de detalhe do planejamento de forma a
obter um plano bem balanceado.
Nem tudo que feito no projeto precisa estar explicitamente registrado no cronograma.
Pequenas tarefas que tenham o mesmo responsvel podem ser agrupadas e podemos criar
checklists para tarefa resultante de forma a garantir que nada seja esquecido. Por exemplo:
se temos 5 atividades que envolvem 5 diferentes tipos de teste, podemos criar uma nica
atividade chamada Teste, e associar a ela um checklist que garanta que cada um dos 5
testes seja executado antes que a tarefa seja dada como completa.
Uma vez que uma atividade seja registrada, precisamos definir sua durao. claro que a
durao dependente da quantidade de recursos alocada mas, neste momento, devemos j
ter uma primeira definio dos recursos envolvidos e uma estimativa da durao da tarefa. Por
exemplo: digamos que planejamos executar a tarefa de testes com um nico recurso e
dimensionamos dois dias para cada teste. Nessas condies a tarefa dever durar 10 dias. Se
mais tarde pudermos disponibilizar mais recursos, teremos que replanejar a durao. Aqui,
valem os cuidados de sempre. Cinco testadores podem fazer os cinco testes em paralelo e
realiz-los em dois dias, mas 10 testadores no iro realizar a tarefa em 1 dia. O prximo
passo registrar, no software, os recursos que utilizamos para a estimativa de durao.
Quando planejamos a durao da atividade, importante recordar que existem dois tipos
principais de tarefas: aquelas que so dependentes de esforo e aquelas que so
dependentes de tempo. claro que qualquer atividade dependente de ambos, mas a nfase
pode ser bem diferente. Atividades dependentes de esforo so as atividades que temos
usado como exemplo. A durao da tarefa totalmente preenchida pelo esforo. Nessas
tarefas tendemos a alocar recursos em mltiplos de 100%. Um profissional de um tipo
representado por 100%, dois profissionais do mesmo tipo por 200% e assim por diante.
Com atividades dependentes de tempo, normalmente temos episdios intercalados de ao e
espera. Se, por exemplo, precisamos fazer um levantamento que envolva conversas com
diversas pessoas, precisaremos marcar vrias reunies que ocorrero em diferentes ocasies
dentro de um espao de tempo. Podemos ser obrigados a alocar duas semanas para este
levantamento, embora estas duas semanas acabem rendendo apenas 40 horas de
entrevistas. O trabalho real gastaria apenas metade do tempo total.Normalmente, alocaramos
50% de um recurso para esta tarefa. No entanto, o carter imprevisvel do padro de trabalho
e espera pode nos forar a desperdiar alocao. Ningum sabe realmente quando e quantas
horas o recurso estar disponvel e, em muitos casos, mais simples alocar o recurso 100%
para este tipo de tarefa, principalmente quando no temos um uso paralelo para ele.
Pgina 77 de 190
9.3.2 Dependncias entre Atividades
A seqncia em que as atividades do projeto so executadas dependem dos relacionamentos
entre estas atividades. As restries que geram estas seqncias so governadas pelo
relacionamento lgico entre as atividades. Por exemplo: antes de erguermos as paredes de
uma casa devemos primeiro construir as fundaes. Nesse caso, mudar a ordem destas
tarefas no faz sentido nos levar ao fracasso do projeto.
Na literatura clssica, as dependncias so definidas como:
! Dependncias Mandatrias So aquelas em que a inverso impossvel. Ex.
construir o telhado antes de colocar a fundao.
! Dependncias Discricionrias Desejveis (Soft Logic)
experincia da equipe, normalmente para evitar riscos.
So
decididas
pela
! Dependncias Discricionrias Preferenciais (Preferencial Logic) So sugeridas por

um Stakeholder e expressam uma seqncia preferencial sem exista uma
necessidade real para a dependncia.
Nos casos das Dependncias Discricionrias Desejveis a dependncia nem sempre obvia.
A inverso pode no impedir o sucesso do projeto, mas ela gerar aumento do risco e/ou do
esforo total. Este o caso de pintar as paredes antes da colocao dos carpetes. A inverso
certamente possvel, mas os pintores devero ter muito mais cuidado, o que aumentar o
tempo da pintura e, ainda assim, existe o risco de danos ao carpete.
Algumas vezes, ocorre uma dependncia entre uma atividade do projeto e uma atividade
externa ao projeto. Se o planejamento no levar esse fato em conta, o projeto poder ficar
bloqueado aguardando uma definio externa.
Deixar de notar uma dependncia pode gerar problemas para o projeto, mas o erro mais
comum a criao de dependncias que no existem. Se duas tarefas, teoricamente
simultneas, so executadas pelo mesmo recurso, o planejador pode querer criar uma
dependncia artificial entre elas, de modo que as duas tarefas sejam executadas em
seqncia e assim o conflito de superalocao de recursos seja removido. Isto no
recomendvel. As dependncias devem espelhar apenas os relacionamentos intrnsecos entre
as atividades. Os conflitos de recursos so tratados por tcnicas especficas (Resource
Leveling). As dependncias artificialmente criadas podem, medida que o projeto se
desenrola, gerar problemas para o gerente de projeto. Ele pode falhar em ver, por exemplo,
que pode acelerar o projeto colocando recursos adicionais para o trabalho em paralelo.
As dependncias entre as atividades podem ser representadas por meio de tabelas de
precedncia como a descrita baixo. Este tipo de tabela to simples e eficiente que usada
pelos softwares de gerenciamento de projetos para armazenamento interno das informaes.
ID
1
Atividade
Analise de Requerimentos
Predecessor Durao
30 dias
Modelagem Dados
15 dias
Prottipo de Telas
5 dias
Detalhamento de Funes
20 dias
Programao
2;3;4
40 dias
Testes
5 dias
Pgina 78 de 190
Uma outra ferramenta para mostrar dependncias o diagrama de rede. Esses diagramas
representam graficamente no s as atividades, mas tambm os eventos, ou seja o ato de
completar uma ou mais atividades.
Existem dois tipos. O primeiro o AOA - Activity On Arrow, ou seja, atividade na flecha. Os
eventos so representados pelos ns. A tabela acima poderia ser representada pelo diagrama
AOA abaixo.
2
INICIO
FIM
4
O segundo tipo o diagrama AON Activity On Node, ou seja, atividade no n. As flechas
passam a representar eventos.
4
Ambos tem vantagens e desvantagens e ambos foram largamente utilizados. Mas eles
acabaram por serem substitudos pelo grfico de Gantt. O grfico de Gantt foi desenvolvido
por volta de 1917 por um pioneiro da administrao cientfica chamado Henriy L. Gantt. Tm a
vantagem de permitir a visualizao, no s da precedncia, mas tambm do tamanho relativo
entre as atividades e as diferenas de prazo entre elas. O diagrama de Gantt , na realidade,
uma espcie de diagrama AOA construdo em uma escala de tempo.
No diagrama de Gantt, podemos ver claramente que a atividade de nmero 3 pode atrasar
vrios dias sem que o projeto como um todo se atrase. Este fenmeno chamado de Slack
ou Float (folga) entre atividades. Neste exemplo, descrevemos atividades com precedncia
temporal simples. Esse o tipo mais comum de sequenciamento, mas existem outros. Entre
eles esto:
! Final para Incio - Seqncia temporal simples, ou seja a autorizao para o incio da
segunda atividade depende do evento de finalizao da primeira.
! Incio para Incio A autorizao para o incio da segunda atividade est relacionada
ao evento de iniciao da primeira. Normalmente, quando elas devem comear juntas.
! Final para Final O encerramento da segunda atividade est relacionada ao evento de
encerramento da primeira. Por exemplo: a etapa de planejamento de uma construo
Pgina 79 de 190
pode comear antes da aprovao do projeto, mas ela no pode terminar at que o
projeto esteja completo.
Alm disso, o retardo na conexo no precisa ser zero, ou seja, pode haver Leads
(dianteiras) e Lags (esperas) entre duas tarefas. Normalmente, usamos esperas (Lags)
entre tarefas do tipo Final para Incio quando necessrio um tempo mnimo entre elas. Por
exemplo: aps a colocao de cimento, necessrio esperar alguns dias para o
endurecimento. Durante este tempo, nenhuma atividade pode ser executada.
Dianteiras (Leads) so normalmente utilizadas em ligaes do tipo Inicio para Incio. Muitas
destas ligaes surgem de ligaes que seriam do tipo Final para Inicio, mas nas quais no
necessrio terminar toda a primeira atividade antes que a segunda comece. Por exemplo,
devemos esperar que a pintura acabe antes que o carpete seja colocado, mas no
precisamos esperar que todos os quartos sejam pintados. A equipe do carpete pode comear
a trabalhar assim que a primeira sala esteja pintada e os pintores passarem para a prxima.
Podemos calcular o tempo de pintura de uma sala e dar esse tempo de dianteira para os
pintores.
9.3.3 Clculo do Cronograma

Atualmente, os softwares de gerenciamento de projeto, como o MS-Project ou o Primavera, j
calculam o cronograma automaticamente. No entanto, interessante para o gerente de
projeto entender o processo.
O Cronograma calculado baseado no tempo previsto de durao da tarefa e da rede de
dependncias. Calcular o cronograma significa definir quando uma tarefa deve comear e
terminar para que o prazo do projeto seja o menor possvel.
Como as tarefas podem ter Float, na verdade devemos calcular 4 datas para cada tarefa:
! Early Start (ES) A data mais cedo que uma tarefa pode comear dadas as tarefas
que a precedem;
! Early Finish (EF) A data mais cedo que uma tarefa pode terminar dadas as tarefas
que a precedem e sua durao prevista;
! Late Start (LS) A data mais tardia que uma tarefa pode comear sem que o projeto
seja atrasado;
Pgina 80 de 190
! Late Finish (LF) A data mais tardia que uma tarefa pode terminar sem que o projeto
seja atrasado;
Para o clculo, ns determinamos essas datas como uma certa quantidade de perodos (ex.
dias) a ser somada data inicial. Assim, se a data inicial dia 5/julho, a data 3 seria 8/julho,
ou seja, 3 dias aps 5/julho.
Imagine, como exemplo, que temos a seguinte estrutura de precedncia:
Tarefa
Durao
Predecessora
T1
T2
T3
T1, T2
T4
T2
T5
T3, T4
O clculo do cronograma feito em duas fases, na primeira, chamada de Foward Pass, ns

calculamos as datas mais cedo de cada tarefa (ES e EF). Para isso passeamos pelas
tarefas do incio ao fim. Para tornar mais claro, colocaremos as tarefas em um diagrama de
rede em que as informaes seguem a seguinte legenda:
Durao
Float
ES
EF
LS
LF
De incio, sabemos apenas a durao de cada atividade. Todas as outras informaes ficam
em branco. Ento, analisamos todas as tarefas que no tm pr-requisitos. O ES dessas
tarefas 0. Para o clculo do EF basta somar a durao data de incio. Assim, T1 e T2 tem
datas de fim 3 e 5, respectivamente. A tarefa T4, que depende de T2, s pode comear
quando esta terminar, logo a sua data de incio a data de fim de T2.
No caso de T3, existe um pequeno detalhe: T3 depende tanto de T1 quanto de T2. Nesses
casos, a data de incio passa a ser a maior data de fim entre as anteriores. fcil ver o
porqu. T3 s pode terminar quando as duas antecessoras terminarem e isso s vai acontecer
no dia 5, quando T2 terminar.
O processo segue at a ltima tarefa, T5, que s poder comear no dia 9 e acabar no dia
12, data de fim do projeto.
T1
T3
0
-
3
-
5
-
9
-
9
-
12
-
INICIO
T4
T2
5
0
-
5
-
5
-
7
-
Pgina 81 de 190
T5
FIM
O passo seguinte conhecido como Backward Pass, isto porque examinamos a rede do fim
para o incio. Comeamos pela tarefa T5. Como ela define a data final do projeto, suas LS e
LF so exatamente iguais a ES e EF, respectivamente.
As tarefas T3 e T4 so antecessoras de T5, logo, suas datas de fim no podem ser maiores
que a data de incio de T5. Suas datas de incio so calculadas diminuindo-se a durao da
data de trmino. Notem que, em T4, as datas mais cedo e mais tarde no coincidem.
Em T2, encontramos o caso em que uma tarefa tem mais de uma sucessora. Ao contrrio do
Foward Pass quando pegamos a maior data, aqui ns escolhemos a menor data entre as
datas de incio (LS) das sucessoras. No caso, entre T3 e T4, a menor data de incio o 5 de
T3 e no o 7 de T4.
Quando todas as datas esto calculadas, calculamos o Float pela diferena entre LF e EF,
ou ente ES e LS. Notem que T1 pode comear entre o dia 0 e o dia 2 sem que o projeto
atrase. Seu Float calculado 2.
T1
T3
0
2
3
5
5
5
9
9
9
9
12
12
T4
T2
INICIO
0
0
5
5
5
7
7
9
T5
FIM
Cabe ao Gerente de Projeto decidir quando ele deseja efetivamente comear as tarefas com
Float. H duas estratgias mais comuns:
! Utilizar a Early Start A vantagem, neste caso, que, se a tarefa tiver um pequeno
atraso, o Float ser consumido, mas o projeto como um todo no atrasar. Isto reduz
o risco do projeto. Esta a opo mais recomendada pela literatura.
! Utilizar a Late Start Neste caso, remove-se todo o Float. Atrasos na tarefa
implicam em atrasos no projeto, no entanto, esta tcnica evita que recursos fiquem
sem alocao no meio do projeto. Alm disso, o custo associado tarefa ser adiado,
o que pode ser bom para o fluxo de caixa. Na prtica, esta a opo mais usada
pelos gerentes de projeto.
9.3.4 Calendrios
Um detalhe freqentemente esquecido na criao de cronogramas o ajuste adequado dos
calendrios. Um calendrio representa as datas e horrios em que a equipe estar disponvel
para o trabalho. Freqentemente, um calendrio nico com os feriados e o horrio
administrativo da Organizao suficiente.
No entanto, principalmente em projetos que envolvam mltiplas organizaes, ou
geograficamente dispersos, calendrios diferentes podem ser necessrios para diferentes
equipes de trabalho. Um feriado municipal, por exemplo, ou a disponibilidade de trabalho aos
sbados, pode afetar apenas uma parte da equipe do projeto.
Pgina 82 de 190
9.3.5 Caminho Crtico
O Caminho Crtico definido como sendo o maior caminho atravs da rede, ou seja, a menor
quantidade de tempo em que se espera que o projeto possa terminar. Normalmente a folga
entre as atividades dependentes no Caminho Crtico zero. Isto porque, se houver folga,
podemos reduzi-la para diminuir o prazo do projeto. No entanto, alguns projetos tm seus
prazos finais pr-estabelecidos, o que pode gerar caminhos crticos com folgas. Na verdade
isto no comum. Muitos autores e vrios softwares de controle de projeto definem o
Caminho Crtico como o caminho de folga zero.
Em nosso projeto exemplo, a seqncia de atividades T2, T3 e T5 compem o caminho
crtico. Se a atividade T4 durar o dobro do tempo que est planejado, isso no dever afetar
o prazo final porque ela possui folga. Atraso em qualquer atividade de Caminho Crtico gera
atraso no projeto.
9.3.6
Fast Tracking
Fast Tracking envolve a sobreposio de tarefas que tradicionalmente seriam executadas

em seqncia. Em alguns casos, o uso de Fast Tracking pode diminuir significativamente o
tamanho do cronograma. Existem registros de at 40% de reduo do tempo total. Por outro
lado, Fast Tracking aumenta significativamente o risco do projeto.
A quantidade de tarefas, simultaneamente gerenciadas, aumenta, bem como a quantidade de
recursos. O risco de retrabalho aumenta consideravelmente.
O exemplo mais comum o incio da execuo quando a fase de projeto no est totalmente
terminada. Nestes casos, a quantidade de tempo poupada e tambm o risco gerado,
dependero principalmente da quantidade de dianteira dada (Lead).
Podemos imaginar que plantas em um projeto de engenharia que esto 95% prontas, mesmo
que sem a aprovao final, j fornecem uma boa base para a execuo. Alguns detalhes
podem mudar mas, na altura em que a execuo tiver que lidar com eles, a fase de projeto j
estar 100% encerrada. Mesmo que no esteja, o nvel de retrabalho esperado pequeno.
Por outro lado, podemos trabalhar com a hiptese de que 30% do projeto j define informao
suficiente para o incio do trabalho de execuo. Os ganhos no cronograma, neste caso, so
enormes. Entretanto, a possibilidade de grandes alteraes no projeto tambm so enormes.
praticamente certo que, na altura em que o projeto final seja definido, uma boa parte do
trabalho tenha que ser refeito.
Definir a dianteira necessria uma arte que o gerente de projeto deve compartilhar com os
principais Stakeholders do projeto. Se o cliente compartilha o risco do Fast Tracking ele
estar menos disposto a solicitar alteraes cosmticas no projeto que resultarem em
retrabalho na execuo.
9.3.7 Resource Leveling

O cronograma inicial calculado no necessariamente o cronograma real do projeto. Isto
porque ns no levamos em conta uma restrio muito importante no planejamento do projeto:
a quantidade de recursos disponveis.
Lembre-se de que as dependncias devem espelhar apenas os relacionamentos mandatrios
ou discricionrios entre as atividades. O cronograma calculado no verifica se o mesmo
recurso est previsto para duas atividades ao mesmo tempo. Logicamente, se for este o caso,
as duas atividades sero executadas em srie e no em paralelo. Um passo adicional
chamado de Nivelamento de Recursos ou Resource Leveling necessrio para corrigir o
cronograma.
Pgina 83 de 190
O objetivo do Resource Leveling otimizar o uso de pessoas e equipamentos alocados ao
projeto. No apenas uma questo de impedir a superalocao de recursos. A tcnica se
baseia no pressuposto que, quando possvel, deve ser evitado que o mesmo recurso entre e
saia do projeto repetidas vezes. Normalmente, a melhor soluo aquela que prev o uso
consistente e contnuo do menor nmero de recursos possvel.
A tcnica tem duas entradas principais: o cronograma inicial calculado e a previso de uso de
recurso por tarefa. Uma heurstica aplicada sobre estas entradas e o resultado um
cronograma que no s obedece s dependncias intrnsecas, mas tambm evita tanto a
superalocao quanto a sub-alocao dos recursos. O Resource Leveling lida apenas com
pessoas e equipamentos, os materiais necessrios para o projeto so pr-definidos pela
especificao da tarefa.
Os softwares de gerenciamento de projetos tm algoritmos embutidos que calculam o
Resource Leveling. No entanto, as vrias opes de softwares produziro diferentes
cronogramas. Normalmente, se avalia a qualidade do algoritmo pela durao total do projeto
gerado. Quanto mais longo, pior o algoritmo. Em uma pesquisa dos anos 70 foram
comparados diversos programas comerciais. Um experimento interessante, chamado de
Problema 13, obteve resultados radicalmente diferentes de cada software. O Primavera,
ento em sua verso 4.0, conseguia gerar um cronograma com 23 dias de durao. Na poca,
as primeiras verses do MS-Project geravam, para o mesmo projeto, um cronograma de 27
dias. Embora a verso 95 do MS-Project ainda tivesse resultados abaixo do ideal, trinta anos
depois do experimento original o algoritmo padro da verso 2000 do MS-Project j consegue
gerar um cronograma de 21 dias. Apenas 1 a mais do que o timo terico de 20 dias.
Se os resultados do Resource Leveling forem inaceitveis, o gerente de projeto pode tentar
manipular as estimativas de recursos de cada tarefa. Por exemplo: ao invs de usar uma
grande quantidade de recursos durante um pequeno perodo de tempo, aloca-se uma
quantidade menor em um perodo um pouco maior. Este tipo de mudana alterar o
cronograma inicial que dever ser recalculado. O Resource Leveling resultante deste novo
cronograma poder ser mais satisfatrio.
Alternativamente, o gerente de projeto poder negociar cargas extras de trabalho em
momentos de pico. Mas isto extremamente perigoso. Se o planejamento j prev horas
extras desde o primeiro dia, quando algum problema acontecer, e eles sempre acontecem,
no haver nenhuma margem para correo de curso e o projeto certamente atrasar. Desta
forma, esta deve ser uma ferramenta de ltimo recurso. Bons gerentes de projeto no a
utilizam de nimo leve.
Uma coisa muito importante que o gerente de projeto deve ter em mente que o cronograma
produzido pelo Resource Leveling aquele que ele dever usar para todo o planejamento,
incluindo o compromisso de data de entrega para o cliente. O cronograma inicial apenas um
passo intermedirio. Na prtica, no possvel segui-lo.
9.4
Cronograma por Fases
Quando analisamos as tcnicas de oramentao, sugerimos uma alternativa chamada

Oramentos por Fase. Voc deve recordar que a idia bsica era a de quebrar o grande
esforo de planejamento do incio do projeto em esforos menores que ocorreriam ao longo do
projeto. O mesmo princpio pode ser aplicado a outros tipos de estimativas e planejamentos,
inclusive elaborao de Cronogramas. Na medida do possvel, devemos controlar o impacto
de estimativas feitas justamente no momento em que a incerteza est no seu mximo, ou
seja, no incio do projeto.
A elaborao do cronograma por fases segue um processo semelhante ao processo evolutivo
que descrevemos com relao ao WBS. Nos vimos que um WBS de alto nvel pode ser criado
nas primeiras fases de definio conceitual do projeto e, mais tarde, ter seus elementos
decompostos em WBSs sucessivamente mais detalhados. Se partirmos do princpio de que o
Pgina 84 de 190
cronograma deve seguir o WBS, no teremos escolha, a no ser detalharmos o Cronograma
toda vez que detalhamos o WBS.
No incio do projeto, podemos criar um Cronograma que defina as informaes nas fases do
ciclo de vida do projeto. Como exige poucas informaes, este cronograma pode ser criado
bem no princpio do projeto. Talvez ainda na fase de concepo. Mais tarde, quando
estivermos prontos para comear uma fase, poderemos detalhar as atividades daquela fase,
seguindo o detalhamento do WBS.
As vantagens deste tipo de procedimento so semelhantes quelas do oramento por fase.
! O planejamento inicial pode ser feito rapidamente e os pontos crticos analisados
bastante cedo no projeto;
! No planejamento detalhado de cada fase, como o horizonte de tempo menor, as
estimativas para cada fase tm menos incerteza;
! Em muitos casos, as atividades exatas que devem ser feitas, dependem dos
resultados das fases anteriores. Com o cronograma por fases, poderemos planejar as
atividades detalhadas para cada fase quando j sabemos o resultado das fases
anteriores;
Vejamos um exemplo simples: digamos que ainda estamos em uma fase de estudo de
viabilidade de um projeto de desenvolvimento de software. O projeto abaixo mostra um
cronograma bastante agregado, elaborado durante essa fase. Na criao deste cronograma
est associada uma srie de pressupostos a respeito dos recursos, custo e esforo
necessrios para cada fase. Vejamos:
Id
1
2
3
4
5
6
Nome da tarefa
Projeto
Analise
Projeto
Implementao
Homologao
Implantao
Durao S-1
51 dias
7 dias
10 dias
25 dias
6 dias
3 dias
S1
S2
S3
S4
S5
S6
S7
S8
S9
S10
A linha de base associada a esse cronograma poderia ser a que mostrada na tabela abaixo.
Projeto
Analise
Prazo
51 dias
7 dias
Esforo (HH)
1.346 hrs
70 hrs
Custo
R$ 87.700,00
R$ 3.500,00
Projeto
10 dias
120 hrs
R$ 6.000,00
Implementao
25 dias
850 hrs
R$ 57.500,00
Homologao
6 dias
204 hrs
R$ 13.800,00
Implantao
3 dias
102 hrs
R$ 6.900,00
Recursos
Analista Senior;
Outros Recursos[25%]
Analista Senior;
Analista Snior
Outros Recursos[25%];
Terceiros Externos[300%]
Analista Snior
Analista Snior
Esse cronograma, apesar de seu nvel de agregao, gera, juntamente com a definio do
escopo, informao suficiente para obter um compromisso entre o cliente e o gerente do
projeto. Decises com relao a prazos, desembolsos e disponibilizao de recursos podem
ser tomadas.
Mais tarde, quando estivermos prontos para comear a fase de Anlise, este cronograma ser
insuficiente para fins de planejamento. Ser necessrio detalhamento das principais atividades
da fase. Os recursos exatos j devem ser definidos e os custos calculados com preciso. O
novo cronograma e a nova linha de base so descritos a seguir.
Pgina 85 de 190
S11
Id
1
2
3
4
5
6
7
8
9
Nome da tarefa
Projeto
Analise
Preparao de Ambiente
Especificaes de Requisito
Criao do Plano de Testes
Projeto
Implementao
Homologao
Implantao
Projeto
Analise
Preparao de Ambiente
Especificaes de Requisitos
Criao do Plano de Testes
Projeto
DuraoS-1 S1
51 dias
7 dias
1 dia
5 dias
1 dia
10 dias
25 dias
6 dias
3 dias
S2
Prazo
51 dias
7 dias
1 dia
5 dias
1 dia
10 dias
Esforo (HH)
1.348 hrs
72 hrs
16 hrs
40 hrs
16 hrs
120 hrs
25 dias
850 hrs
6 dias
204 hrs
3 dias
102 hrs
Implementao
Homologao
Implantao
S3
S4
S5
Custo
R$ 87.760,00
R$ 3.560,00
R$ 800,00
R$ 2.000,00
R$ 760,00
R$ 6.000,00
S6
S7
S8
S9
S10 S11
Recursos
Danubia;Lianna
Danubia
Danubia;Joao
Danubia;
Danubia;
R$ 57.500,00 Terceiros Externos[300%];
Danubia;
Danubia;
Os valores exatos podero variar com relao ao planejamento original. Em nosso exemplo
isto afetou o custo total do projeto. Nessa primeira fase esta variao deve ser mnima. Mais
tarde, o replanejamento pode ter a tendncia a variaes maiores. Isso normal ! No entanto,
novamente aqui a capacidade de negociao e a criatividade de adaptao do gerente de
projetos devero fazer com que uma soluo adequada aparea.
As informaes sobre ao resto do projeto, que j conheamos com certeza, podem ser
incorporadas ao plano a partir daqui. Nesse exemplo, o recurso definido como Analista Snior
j foi identificado como sendo a Danubia. Sabemos o custo exato da hora dessa profissional e
assim podemos atualizar o planejamento das fases seguintes com estas informaes. Por
outro lado, os terceiros ainda no esto definidos e permanecem como recursos genricos.
Pgina 86 de 190
9.5
Gerenciando a incerteza
Bem cedo, os gerentes de projeto aprenderam que a incerteza inerente a sua atividade.
Com o tempo, vrias tcnicas surgiram para tentar lidar com este fato. Analisaremos trs
dessas tcnicas:
9.5.1 CPM
CPM a abreviao de Critical Path Method. O CPM foi desenvolvido no fim da dcada de
50 pela DuPont Inc. e foi especialmente utilizado em projetos de construo civil.
O CPM tem a premissa subjacente de que as estimativas das atividades so razoavelmente
precisas e determinsticas. Se pensarmos desta maneira, o tempo de execuo de uma tarefa
passa a ser modelado pela variao do esforo. Se aumentarmos o esforo, terminaremos
antes, mas se diminuirmos o esforo terminaremos depois. Esta uma premissa razovel em
projetos de construo civil.
Em CPM, esforo interpretado como custo. Se quisermos que uma tarefa leve menos tempo
que o planejado devemos adicionar mais recursos ou autorizar horas extras. Em qualquer
caso o tempo deve ser inversamente proporcional ao custo. O ato de aumentar o custo de
uma tarefa para aceler-la chamado de Crash.
Como o Gerente de Projetos sabe em que tarefas ele deve utilizar o Crash ? Simples ! So
aquelas que possuem pouca ou nenhuma folga para atraso, ou seja, as atividade do Caminho
Crtico. Como, em muitos projetos, as tarefas que compem o Caminho Crtico representam
10% do total, o aumento de custos destas tarefas representam relativamente pouco para o
total do projeto. Provavelmente, muito menos do que os custos de atraso do projeto.
As tcnicas sugeridas por CPM podem ser utilizadas at um limite. Na verdade, CPM se
baseia em duas premissas que j sabemos serem falhas. A primeira que as estimativas de
durao das tarefas so precisas e determinsticas, quando sabemos que elas so,
comumente, imprecisas e probabilsticas. A segunda que sempre podemos acelerar uma
tarefa aumentando a quantidade de recursos. J vimos (O Mtico Homem-Ms) que em
alguns casos isso pode at atrasar a tarefa.
9.5.2 PERT
PERT a abreviao de Program Evaluation and Review Technique. O PERT foi
desenvolvido em 1958 em um esforo de cooperao da Marinha Americana, da Booz-Allen e
da Lockheed Corporation. O PERT foi primariamente destinado para projetos de pesquisa e
desenvolvimento.
O CPM foca a ateno na dimenso Custo, PERT, por outro lado, tenta evitar atrasos pela
manipulao direta dos prprios prazos das atividades. O PERT reconhece que a durao das
atividades definida segundo um modelo probabilstico e tenta calibrar o prazo total do projeto
de modo a aumentar a probabilidade de ele terminar segundo o planejado.
Se o CPM uma tcnica de execuo do projeto, PERT uma tcnica do planejamento. A
idia engenhosa. Parece certo que a probabilidade de durao de uma tarefa modelada
por uma funo prxima a Gama. Devido ao processo de negociao com os Stakeholders,
as estimativas CPM esto, na prtica, em diferentes partes desta curva, ou seja, tm
diferentes probabilidades de sucesso mas, na teoria, elas so estimativas pessimistas com
99% de chance de sucesso. Desta maneira, CPM nos oferece um ponto na curva de
probabilidade. Se tivermos mais alguns pontos podemos esboar a curva. O PERT requer
que, para cada tarefa, sejam feitas no uma mas trs estimativas de durao, definidas de
maneira bastante precisa:
Pgina 87 de 190
! A estimativa otimista (o) definida como o menor prazo possvel em que a atividade
pode ser executada se tudo correr da melhor maneira possvel. Algo que deve ocorrer
em 1% dos casos.
! A estimativa pessimista (p) definida como o maior prazo razovel em que a atividade
pode ser executada, se tudo que for previsto para dar errado, se concretize. Um prazo
como este deve cobrir 99% dos casos.
! A estimativa mais provvel (m) definida como a moda da distribuio.
Digamos que, na tarefa representada pela figura abaixo, temos as estimativas o=2, m=5,75
e p=16.
Nesse ponto, o PERT faz uma suposio no sustentada por nenhuma teoria. O modelo
afirma que a distribuiao de probabilidade do tipo Beta (semelhante a Gama) e que entre a
estimativa pessimista e a otimista temos 6 desvios padro.
s = (o + p) / 6
Com base nisto, ele tenta calcular uma estimativa da mdia da distribuio com a frmula:
Xbar = (o + 4m + p) / 6
Em nosso exemplo, a estimativa recomendada por PERT seria, aproximadamente, de 6,8
dias.
Xbar = (2 + 4 * 5,75 + 16) / 6 = 6,8
Lembremos que a mdia de uma distribuio oferece 50% de chance de sucesso. Se
utilizarmos o dimensionamento sugerido por PERT para todas as tarefas, teramos 50% de
chance de terminar o projeto no prazo. Tal planejamento seria inadmissvel. Podemos corrigir
isso criando uma reserva no final do projeto. Para dimensionar esta reserva precisamos
primeiro identificar as tarefas do caminho crtico e calcular o desvio padro de cada uma
delas. Se o caminho crtico tiver um nmero razovel de tarefas (recomenda-se pelo menos
30), a Estatstica garante que podemos calcular o desvio padro do projeto inteiro como sendo
a raiz quadrada da soma dos quadrados dos desvios padro de cada tarefa no caminho
crtico. Recomenda-se que a reserva seja de 3 vezes o valor do desvio padro. Vejamos um
exemplo simplificado (com menos de 30 atividades):
Pgina 88 de 190
2
Tarefa
Xbar
12,5
7,42
1,75
3,06
12,5
7,58
1,58
2,51
15
9,33
1,67
2,78
10
25
15,33
3,00
9,00
15
9,17
1,83
3,36
10
25
15,17
3,17
10,03
15
9,00
2,00
4,00
O tamanho total do projeto usando CPM, se a equipe tivesse a liberdade de definir o prazo,
seria de 120 dias, que o somatrio das estimativas pessimistas. PERT utilizaria o somatrio
de Xbar, o que seria 73 dias. Com este prazo a probabilidade de sucesso de 50% e
precisaramos de uma reserva. Para calcular a reserva, primeiro calculamos o somatrio de s2,
que de 34,7 e tiramos sua raiz quadrada para obter cerca de 5,9 dias. Este o desvio
padro esperado do projeto. Multiplicando este valor por 3, teramos uma reserva de
aproximadamente 18 dias. O tamanho total do projeto PERT seria 91 dias, ou seja, 29 dias a
menos do que o CPM terico.
PERT , sem dvida uma evoluo se comparado ao CPM terico puro. Um lado positivo de
PERT nos forar ao questionamento das estimativas. Para que trs estimativas sejam
oferecidas e justificadas, uma ateno considervel tem que ser dada ao assunto. Alm disso,
o reconhecimento da caracterstica probabilstica da durao real um passo importante na
compreenso de como os projetos funcionam.
Infelizmente, essa compreenso no foi muito longe. Muitos autores, demonstrando uma
ignorncia completa do fenmeno, descrevem a frmula PERT como uma forma de tornar a
estimativa mais precisa. Sabemos que o que ela realmente faz gerar uma estimativa com
aproximadamente 50% de chance de sucesso. Isso est longe de ser mais preciso do que a
estimativa CPM. Pelo menos no sentido que estes autores do. A maioria deles omite
completamente que a reserva de prazo e custo uma necessidade em PERT e no uma mera
precauo.
Graas a este desconhecimento, projetos PERT acabam sendo administrados da mesma
maneira que projetos CPM. O gerente de projetos espera que todas as tarefas sejam
terminadas nas datas programadas e certamente haver uma avaliao negativa para aqueles
que no conseguirem. Mas com estimativas em 50% metade das tarefas certamente
terminaro fora do prazo e isto no pode ser evitado pela equipe. As pessoas no gostam de
ser punidas por aquilo que no controlam. Assim, inevitavelmente, no prximo projeto as trs
estimativas sero super-infladas de modo que o resultado da frmula PERT acabar tendo o
mesmo valor que a estimativa pessimista CPM.
Outro problema do mtodo a sua suposio de que entre a estimativa pessimista e a
otimista temos exatamente 6 desvios padro. As funes Beta e Gama tm uma infinidade de
formatos e o ponto a 1% pode estar a uma distncia indefinida do ponto 99%. Parece-nos que
este o tipo de simplificao que as pessoas recorriam na dcada de 50, quando
computadores pessoais no existiam e engenheiros ainda utilizavam rguas de clculo.
Por outro lado, os estimadores no podem ter certeza de que suas estimativas so realmente
os pontos 1%, moda e 99%. Este o tipo de auto-iluso que os especialistas adoram, mas
que no faz sentido na prtica. mais provvel que as estimativas pessimistas estejam em
torno de 90% pois, como j vimos, o formato da curva de probabilidade faz com que
estimativas a 99% sejam exageradamente grandes e dificilmente aceitas pelos Stakeholders.
As outras estimativas sofrero distores menores, mas que tambm podem ser significativas.
Pgina 89 de 190
PERT tambm erra o alvo ao focar a avaliao de riscos no caminho crtico. Adiaremos a
explicao deste erro para a prxima sesso, pois ela necessita de algumas anlises que no
foram feitas quando PERT foi criado.
Acreditamos que todas estas falhas, principalmente a ignorncia sobre as bases tericas do
mtodo, levaram ao descrdito de PERT a ponto de ele ter sido totalmente absorvido pelo
CPM. Pouco, ou nada, das boas idias que criaram PERT pode ser percebido quando o
chamado mtodo PERT/CPM referenciado.
9.5.3 Introduo a Critical Chain

Critical Chain (Corrente Crtica) foi criada por Eliahu Goldratt em 1997 como uma aplicao
de sua Teoria das Restries gerncia de projetos.
Se observarmos como o Caminho Crtico definido, veremos que ele leva em conta apenas
as dependncias explcitas entre as tarefas, isto , ele utiliza as datas previstas antes do
Resource Leveling para definir a data final do projeto. Basta que o mesmo recurso seja
utilizado por atividades dentro e fora do Caminho Crtico para que o prazo final do projeto
mude radicalmente.
Analise o projeto abaixo. O Caminho Crtico definido pelas 4 primeiras tarefas. As tarefas
NC1 e NC2 so consideradas no crticas.
Id
1
Nome da tarefa
CP 1
CP 2
CP 3
CP 4
NC 1
NC 2
D1
D2
D3
D4
A
D5
D6
D7
D8
D9
D10
D11
B
C
C
A
C
No entanto, depois de levarmos em conta a disponibilidade de recursos, um cenrio bem

diferente se apresenta. Primeiro, vemos que no possvel terminar o projeto no prazo dado
pelo Caminho Crtico. Alm disso, vemos claramente que as tarefas NC1 e NC2 no podem
atrasar sem que todo o projeto atrase. Por outro lado, as tarefas CP2 e CP3, que pertencem
ao Caminho Crtico, podem ter algum atraso sem que o projeto seja prejudicado.
Id
1
Nome da tarefa
CP 1
CP 2
CP 3
CP 4
NC 1
NC 2
D1
D2
D3
D4
A
D5
D6
D7
D8
D9
D10
D11
B
C
C
A
C
Qualquer bom gerente de projeto pode ver esses efeitos no cronograma e gerenciar o projeto
de acordo. Mas, no corpo de conhecimento tradicional, no havia um nome especfico para a
seqncia CP1,NC1,NC2,CP4. No podemos cham-la de Caminho Crtico e, no entanto, elas
so as verdadeiras atividades crticas. Goldratt deu um nome para este tipo de seqncia de
atividades: a Corrente Crtica.
A Corrente Crtica definida como a mais longa cadeia de atividades que considera as
dependncias explcitas entre tarefas e as dependncias implcitas de recursos.
Goldratt props mais do que um nome para o fenmeno. Identificar a Corrente Crtica do
Projeto apenas o primeiro passo de sua abordagem. O prximo passo proteger a Corrente
Critica de atrasos. J vimos os motivos por que a segurana adicionada a cada tarefa
sistematicamente desperdiada. A Sndrome do Estudante e o no aproveitamento dos
adiantamentos so duas dessas causas. O conflito aqui : como adicionar segurana ao
projeto sem que ela seja desperdiada ?
Pgina 90 de 190
J sabemos a resposta. Ela foi sugerida pelo modelo PERT na metade do sculo passado.
Basta remover a segurana das tarefas individuais e coloc-la no final do projeto. Analise a
figura abaixo. A data com que nos comprometeremos com o cliente ser a soma das reas
claras, que representam os prazos razoveis para as atividades, com as reas escuras que
representam a segurana adicionada ao projeto. Na parte de cima vemos um cronograma
CPM e, na parte inferior, vemos um cronograma utilizando estimativas com 50% de chance.
O Comprimento total do projeto rigorosamente o mesmo nas duas opes. No entanto, os

prazos internos ao projeto da segunda opo sero radicalmente reduzidos. A Sndrome do
Estudante ter um efeito mnimo se os prazos dados para a equipe forem apertados desde o
incio. A probabilidade de uma tarefa terminar mais cedo do que foi planejado pequena e,
portanto, no haver o desperdcio associado.
Apesar de utilizarmos rigorosamente a mesma quantidade de tempo de segurana, a
probabilidade da segunda opo efetivamente terminar no prazo fatal muito maior. De fato,
como j vimos em PERT, se planejarmos a segurana desta forma, a matemtica de
probabilidade garante a possibilidade de oferecermos um prazo total menor que o original e,
ainda assim, ter maior chance de entregar o projeto no prazo. Para aqueles que no confiam
muito em modelos matemticos, devemos dizer que, alm desse argumento terico, nossa
prpria experincia prtica com o mtodo confirma esta hiptese.
Em Critical Chain a segurana alocada ao projeto, em substituio a segurana alocada as
tarefas, conhecida como pulmo ou Buffer do projeto. Ele protege o projeto como um todo
de atrasos. O mtodo de criao do Buffer de Projeto corrige um dos problemas da reserva
PERT porque leva em conta a Corrente Crtica real do projeto e no o Caminho Crtico terico.
Critical Chain no faz qualquer pressuposto quanto quantidade de desvios padro entre
estimativas. Pede-se a equipe para fornecer duas estimativas: uma com 50% de chance de
sucesso, equivalente a Xbar calculada na frmula PERT e outra com 90% de chance de
sucesso, equivalente s estimativas pessimistas de CPM. Estas estimativas, claro, sofrem
das mesmas imprecises de sempre. Mas Critical Chain remove a iluso de que elas so
mais do que isso. A estimativa pessimista, por exemplo, carrega explicitamente a informao
de que, em 10% dos casos, o pessimismo insuficiente e a tarefa atrasa. No se exige
preciso de 99% porque ela no ocorre na prtica.
Pgina 91 de 190
Existem vrias maneiras de definir o tamanho do Buffer de projeto. Aqui utilizaremos a
sugerida por Lawrence Leach e que semelhante a que mostramos para PERT. Para facilitar
a compreenso, inicialmente admitamos que a Corrente Crtica coincida com o Caminho
Crtico.
As estimativas 90% seriam provavelmente idnticas s estimativas pessimistas de nosso
exemplo PERT. As estimativas 50%, como so tomadas diretamente, no seriam idnticas s
estimativas Xbar de PERT, mas seriam muito prximas.
Para calcular o tamanho do Buffer, Leach sugere que utilizemos a diferena entre as duas
estimativas e apliquemos o mesmo mtodo de calcular a raiz quadrada da soma dos
quadrados.
Tarefa
1
2
3
4
5
6
7
50%
90%
7
8
9
12
9
15
9
12,5
12,5
15
25
15
25
15
5,50
4,50
6,00
13,00
6,00
10,00
6,00
30,25
20,25
36,00
169,00
36,00
100,00
36,00
Nesse exemplo o tamanho total do projeto seria de 90 dias. Esse total a soma dos 69 dias
calculados pela soma das estimativas 50% com os 21 dias de Buffer calculados como a
raiz quadrada da soma dos R2. Esses resultados seriam muito prximos queles que
calculamos com PERT.
Nos casos prticos porm, a Corrente Crtica seria diferente do Caminho Crtico e nosso
projeto exemplo mudaria, por exemplo, para a forma abaixo:
Tarefa
1
2
5
6
7
NC1
NC2
NC3
NC4
50%
7
8
9
12
9
9
6
5
10
12,5
12,5
15
25
15
18
12
12
20
5,50
4,50
6,00
13,00
6,00
9,00
6,00
7,00
10,00
30,25
20,25
36,00
169,00
36,00
81,00
36,00
49,00
100,00
Se estivssemos usando CPM, o tamanho do projeto do projeto pularia de 120 dias para 142
dias aps o nivelamento de recursos. Com PERT estaramos usando uma reserva calculada
para um conjunto diferente de tarefas. Com Critical Chain basta seguir o mesmo
procedimento do exemplo anterior.
O somatrio das estimativas 50% da Corrente Crtica seria 75 dias. Com este prazo teramos
apenas 50% de chance de terminar o projeto dentro de esperado. Para calcular o Buffer do
projeto, calculamos o somatrio de R2, que de 557,5 e tiramos sua raiz quadrada para obter
cerca de 24 dias. O tamanho total do projeto seria 99 dias, ou seja, 43 dias a menos do que se
utilizssemos CPM com nivelamento de recursos.
Este um resultado impressionante! Teramos um projeto 1/3 menor, ainda assim, com mais
probabilidade de terminar no prazo do que se utilizssemos o planejamento tradicional. Isso
que diferencial competitivo!
Pgina 92 de 190
No entanto, nossa ltima afirmao no seria totalmente verdadeira. A proteo oferecida pelo
Buffer de Projeto no suficiente para garantir que o projeto termine no prazo. Este outro
problema ignorado por PERT. Existe uma srie de tarefas fora da Corrente Crtica que tiveram
sua segurana igualmente suprimida. Desta maneira, a probabilidade de que um destes
caminhos convergentes atrase muito alta. Se isto acontecer, a tarefa da Corrente Crtica que
for subseqente ao caminho convergente ir ser atrasada e, por conseqncia, o projeto todo
tambm.
A soluo deste problema aplicar o mesmo princpio do Buffer de Projeto para esses
caminhos convergentes. Esses Buffers ou Pulmes de Convergncia protegem a Corrente
Crtica de atrasos fora dela, da mesma forma que o Buffer de Projeto protege a prpria
Corrente Crtica. Eles podem ser calculados da mesma maneira que j mostramos, uma vez
que so aplicaes do mesmo conceito. este cronograma com Buffers de convergncia
que ofereceria todo diferencial completivo que prometemos acima.
Os softwares de gerenciamento de projetos tradicionais ainda no suportam adequadamente
os conceitos de Corrente Crtica. No entanto, podemos criar pseudo-atividades que
representem a existncia destes buffers. A figura abaixo representa um exemplo de como
nosso projeto poderia parecer depois de a segurana ser retirada de suas atividades e aps a
criao dos buffers adequados.
Id
1
Nome da tarefa
CP 1
NC 1
NC 2
CP 4
Buffer Projeto
CP 2
CP 3
Buffer Convergencia
D1
D2
D3
D4
D5
D6
D7
D8
D9
D10
D11
A
A
C
C
B
C
Estas adaptaes so ligeiramente desconfortveis, pois exigem que os buffers sejam

controlados manualmente. Para aqueles que adotarem seriamente a filosofia Critical Chain e
desejarem suporte de uma ferramenta adequada, existem alternativas de produtos no
mercado, fora dos grandes fornecedores. O primeiro e o mais conhecido destes softwares o
ProChain Project Scheduling da ProChain. Ele , na verdade, uma extenso do MS Project,
o que gera a desvantagem de exigir a compra do software da Microsoft. Por outro lado, esse
aspecto facilita o aprendizado para aqueles que j conhecem o MS Project e permite que os
recursos disponveis para ele sejam utilizveis com o ProChain.
Um ponto que se deve ressaltar na utilizao de Critical Chain a ateno formao e
psicologia dos Stakeholdes. A equipe deve se sentir segura de que no sero punidos por
falhar em cumprir duraes com 50% de chance. Se a gerncia proceder a qualquer tipo de
punio, alm de demonstrar que no compreendeu o modelo, ter que enfrentar inflao de
estimativas por parte da equipe nos futuros projetos. Por outro lado, o Sponsor ou o Cliente
pode se sentir tentado a remover o diminuir radicalmente o Buffer de projeto. Se isto
acontecer o mtodo falhar e os projetos fracassaro. Eles devem compreender que a
alternativa, ou seja, o uso dos mtodos tradicionais, trabalha com prazos muito maiores e alta
probabilidade de fracasso.
Critical Chain tem muitas sutilezas e exige uma grande mudana na mentalidade da
organizao. A descrio adequada de todo o conhecimento e de todas as tcnicas
necessrias para implementao e uso da filosofia de Corrente Crtica extrapola o escopo
deste trabalho. O leitor fortemente aconselhado a buscar uma bibliografia especfica e/ou
uma consultoria especializada antes de tentar utiliz-la. No entanto, a experincia demonstra
que os resultados dessa tcnica podem ser to expressivos que esse investimento e a
mudana cultural necessria so totalmente recompensados.
Pgina 93 de 190
9.6
Multitarefa e Mltiplos Projetos
O mundo seria muito simples se tivssemos que nos preocupar com um problema de cada
vez. Mas o mundo est longe de ser simples e temos sempre uma pilha de trabalho em cima
da mesa. A maneira mais freqente de lidar com esta pilha de trabalho tentar execut-los
simultaneamente. Na verdade, dividimos nosso tempo entre as mltiplas atividades,
alternando entre elas, por exemplo, trabalhando em um projeto pela manh e em outro
tarde. Este modo de operao chamado de Multitarefa. Aparentemente, esta uma maneira
eficiente de trabalhar porque, alm de nos manter ocupados por todo o tempo, permite que
todas as pendncias sejam resolvidas simultaneamente, mesmo que pouco a pouco. Esta
imagem de eficincia enganosa.
Observe a figura abaixo. Imagine que uma das tarefas de um projeto que voc gerencie seja
executada por um recurso compartilhado por vrios projetos. Se este recurso no tiver outras
tarefas para fazer, ele gastar uma determinada quantidade de horas corridas na tarefa e
nosso projeto poder continuar. Este seria o caso da figura a. Porm, se ele receber duas
outras tarefas, mais ou menos do mesmo tamanho que a nossa e engajar no modo
Multitarefa, o tempo de entrega ir aumentar drasticamente. Isso ilustrado pela figura b.
a)
b)
Nosso Projeto
Nosso
Projeto
Projeto
B
Projeto
C
Nosso
Projeto
A figura b no mostra todo potencial do problema. As pessoas no conseguem chavear,

instantaneamente, de uma atividade para outra sem perdas. Entre uma tarefa e outra existe
um tempo improdutivo que o recurso leva para se preparar para a nova tarefa. Se for uma
tarefa fsica, ele ter que localizar e preparar suas ferramentas e o material trabalhado. Em
uma tarefa intelectual ele ter, por exemplo, que localizar documentos relevantes.
Alm disso, a produtividade nunca a mesma de quando a tarefa foi interrompida. Atividades
intelectuais freqentemente interrompidas podem durar para sempre, pois necessrio um
tempo para a mente se acomodar tarefa. Alm disso, comum o profissional ter que voltar
um pouco atrs no trabalho, refazendo ou revisando o que j est pronto.
Esses efeitos, em conjunto so ilustrados pela figura c.
c)
Nosso
Projeto
Projeto
B
Projeto
C
Nosso
Projeto
Isso no conta toda a histria. At agora pressupomos que o recurso daria igual prioridade a
todas as tarefas e que elas teriam aproximadamente o mesmo tamanho da nossa. Esses
pressupostos no espelham a realidade. Em primeiro lugar, as pessoas tm a tendncia a
priorizar as tarefas que elas consideram mais agradveis. Em segundo lugar, as tarefas
podem aparecer em diversos tamanhos e complexidades. Tarefas maiores tendero a
consumir pedaos maiores de tempo. Em terceiro lugar, o recurso pode entender que uma
determinada tarefa prioritria. A prioridade, neste caso, no necessariamente a
importncia da tarefa para a organizao. Uma tarefa pode receber prioridade porque o cliente
mais chato, rude ou poderoso em relao ao recurso. Esses efeitos so ilustrados na figura
d.
d)
Nosso
Projeto
Projeto
B
Projeto
C
Pgina 94 de 190
Nosso
Projeto
Isso ainda no tudo. Ns ilustramos esses fenmenos dentro do que seria o limite do
razovel: apenas trs tarefas simultneas, mais ou menos com a mesma prioridade e
tamanho. Se uma tarefa realmente grande, agradvel e prioritria aparecer, a nossa tarefa
levar muito mais tempo para ser concluda. E isso ainda no o pior. Se o nmero de tarefas
aumentar, todos estes efeitos so ampliados a ponto de nossa tarefa poder ser totalmente
esquecida pelo recurso. No estamos falando de tarefas demorando o dobro ou o triplo do
tempo planejado, estamos falando de tarefas demorando at dezenas de vezes o tempo
planejado. um efeito devastador !
Nem todo uso de Multitarefa, porm, negativo. Vimos que existem atividades dependentes
de esforo e atividades dependentes de tempo. Quando lidamos com atividades dependentes
de esforo, o uso de Multitarefa sempre leva aos fenmenos que acabamos de analisar. No
entanto, atividades dependentes de tempo param por si mesmas. Que o recurso gaste tempo
em esperas inerente a esse tipo de atividade. Podemos usar esse tempo em espera para
outras atividades produtivas sem que isto afete o tempo total da tarefa original. No entanto,
mesmo este tipo de Multitarefa no isento de riscos. O recurso pode no estar disponvel
quando o tempo de espera acabar, o que causar atrasos.
Quando lidamos com um nico projeto, o uso de tcnicas de nivelamento de recursos pode
nos ajudar a nos livrar dos efeitos negativos da Multitarefa com relativa facilidade. No entanto,
quando lidamos com mltiplos projetos o problema se complica.
Vamos analisar o possvel impacto da Multitarefa em mltiplos projetos atravs de um
exemplo: imagine que um determinado tipo de projeto seja executado pela organizao
atravs de uma seqncia de tarefas sobre a responsabilidade de departamentos diferentes.
Este no um caso raro. Determinadas encomendas, por exemplo, geram projetos que
passam pela Engenharia, que dever especificar o produto, depois vo para a fabricao, sob
responsabilidade da Manufatura, passam para a logstica de entrega do produto e finalmente
chegam montagem final no cliente. Na maioria das empresas, cada departamento se
importa apenas com sua parte do processo, sem se preocupar com o projeto como um todo.
Imagine que vrios projetos cheguem simultaneamente em uma empresa desse tipo. Os
responsveis por cada projeto devem negociar, individualmente, com cada departamento.
Estes procuraro atender, da melhor maneira possvel, s demandas conflitantes. Digamos, a
ttulo de simplificao, que existem apenas dois projetos e capacidade atual de cada
departamento suficiente para atender somente um de cada vez. O resultado das
negociaes poder ser algo como cronograma abaixo. Os departamentos tentam atender
simultaneamente os dois projetos atravs de Multitarefa.
Id
1
Nome da tarefa
Projeto 1
Durao S1
50 dias
Tarefa 1
10 dias
Tarefa 2
10 dias
Tarefa 3
10 dias
Tarefa 4
10 dias
Tarefa 5
10 dias
Projeto 2
S2
S3
S4
S5
S6
S7
S8
S9
S10
S11
A[50%]
B[50%]
C[50%]
D[50%]
E[50%]
50 dias
Tarefa 1
10 dias
Tarefa 2
10 dias
10
Tarefa 3
10 dias
11
Tarefa 4
10 dias
12
Tarefa 5
10 dias
A[50%]
B[50%]
C[50%]
D[50%]
E[50%]
Pgina 95 de 190
Os dois projetos so atendidos de maneira simultnea. De manh, o departamento trabalha
para um projeto e, tarde, para outro. Observem que este cronograma no leva em
considerao os efeitos de perda de produtividade que j analisamos. Imaginamos um
Multitarefa perfeito. Apesar disso, cada projeto levaria o dobro do tempo que poderia, se
tivesse dedicao total da empresa. Isso parece inevitvel, certo ? A organizao s tem
capacidade para atender a um projeto de cada vez e aceitou duas encomendas.
Vejamos o problema por outro ngulo: digamos que algum tenha a idia de unir os dois
projetos e fazer um nivelamento de recursos. O que aconteceria se o interesse da empresa,
como um todo, dirigisse o planejamento, em vez dos interesses individuais de cada projeto ? A
resposta mostrada abaixo. Fazemos com que um dos projetos comece um pouco depois e,
em conseqncia, eliminamos a Multitarefa. O resultado que ambos terminam muito antes
dos prazos do planejamento anterior.
O primeiro projeto termina na metade do tempo e o segundo termina apenas um pouco
depois. Isso sem contar com os efeitos negativos da Multitarefa sobre a performance. Como
em uma das histrias de Malba Tahan: aquele que cedeu acabou sendo grandemente
beneficiado.
Id
1
Nome da tarefa
Projeto 1
Durao S1
25 dias
Tarefa 1
5 dias
Tarefa 2
5 dias
Tarefa 3
5 dias
Tarefa 4
5 dias
Tarefa 5
5 dias
Projeto 2
S2
S3
S4
S5
S6
S7
S8
S9
S10
S11
A
B
C
D
E
25 dias
Tarefa 1
5 dias
Tarefa 2
5 dias
10
Tarefa 3
5 dias
11
Tarefa 4
5 dias
12
Tarefa 5
5 dias
A
B
C
D
E
O que torna o ambiente de mltiplos projetos peculiar em suas dificuldades essa falta da
viso do todo. A competio pelos recursos e o prejuzo geral se tornam difceis de se evitar.
Para o trabalhador individual, o ambiente de mltiplos projetos significa responder a diferentes
gerentes de projeto e ter que lidar com os desejos de cada um de modo a mant-los
satisfeitos. Para os gerentes de projeto um ambiente competitivo e catico, onde outros
projetos tentam roubar parcelas maiores de recursos chaves. Para os gerentes de
departamentos significa ter que negociar com mltiplos interesses enquanto usa o que sobra
de seus recursos para tocar o dia a dia da empresa.
Apenas os acionistas vem o ambiente de mltiplos projetos como aquilo que ele deveria ser:
uma maneira de utilizar os recursos da empresa de modo a atender seus maiores interesses.
O problema que eles tm essa viso, mas no sabem como fazer para que o resto da
empresa siga na direo correta.
Algumas abordagens genricas tm sido sugeridas para o ambientes de mltiplos projetos.
Vamos analisar trs delas, propostas por Newbold.
! Planejar todos os projetos em conjunto Nesta tcnica todos os projetos so
planejados juntos, como se fossem um nico projeto. Foi isso que fizemos na segunda
parte de nosso exemplo. Essa tcnica permite um nivelamento de recursos geral para
a empresa e a manuteno do foco nos interesses da organizao. Porm, em
ambientes complexos, com projetos comeando e terminando em datas diferentes e
por iniciativa de grupos diferentes, os problemas prticos desta tcnica rapidamente se
tornam insuperveis.
Pgina 96 de 190
! Projetos Sucessivos Nesta tcnica, cada projeto planejado individualmente e,
posteriormente, inserido dentro de um cronograma composto pelos projetos j
existentes. O novo projeto procurar se acomodar da melhor maneira possvel e
problemas de superalocao so resolvidos caso a caso. Esse mtodo suporta melhor
ambientes complexos, porm necessita que todas as informaes sobre planejamento
e andamento de projetos estejam atualizadas em um ponto central. Alm disso, os
projetos novos tendem a receber uma prioridade menor que os mais antigos, no por
seus mritos mas simplesmente por uma questo de inrcia. Mudanas requeridas
pelos novos projetos podem ter um efeito em cascata e alterar o planejamento de toda
organizao.
! Recurso Estratgico Esta tcnica semelhante a anterior e funciona da mesma
forma, mas ela restringe o controle central apenas aos recursos escassos. Os recursos
que tem excesso de capacidade no so inseridos no planejamento centralizado. A
organizao deve identificar os recursos estratgicos e planejar sua utilizao pelos
projetos. Os outros recursos so alocados por negociao caso a caso. Este mtodo
muito mais simples que os outros dois e resolve boa parte dos problemas. Ainda
existiro conflitos de alocao para recursos no estratgicos, mas estes, por
definio, toleram um certo desperdcio. No entanto, sua simplicidade apenas
relativa, se comparada com os outros dois. Esta tcnica ainda exige um considervel
planejamento central.
Existe uma necessidade clara de tcnicas de priorizao de projetos de modo a que a
alocao de recursos atenda aos interesses da organizao. Todos os trs mtodos
apresentados podem ter aplicao em realidades especficas. Todos trs tm o mrito de
manter o foco no todo e no em otimizaes locais. No entanto, nenhum deles nos parece ser
capaz de ter aplicabilidade geral nas complexas e geis organizaes de nossos tempos.
Adiaremos nossa sugesto de soluo para o captulo de Recursos Humanos, porque no se
trata de uma tcnica de confeco de cronogramas, mas apenas de uma poltica de
gerenciamento de recursos.
Por enquanto, basta observar que tudo que puder ser feito para minimizar os efeitos negativos
da Multitarefa e evitar otimizaes de interesses locais um passo no caminho certo.
Pgina 97 de 190
10 Recursos Humanos
O gerenciamento de recursos humanos inclui os processos que tem como misso tornar mais
efetiva a utilizao das pessoas envolvidas no projeto. Muitos projetos fracassam por falhas
na escolha da equipe ou por baixo envolvimento dos Stakeholders. Seres humanos podem
ser o elo mais fraco ou o mais forte do projeto, mas certo que o fator humano ter uma
influencia decisiva para o sucesso ou o fracasso.
10.1 Plano de Gerenciamento de Pessoal

As regras e procedimentos que controlam os recursos humanos do projeto devem ser
includos como parte do plano do projeto.
Esta parte do plano define, entre outras coisas:
! Como a responsabilidade pelo projeto compartilhada;
! Como os recursos humanos sero alocados e desalocados do projeto;
! Que atividades devem ser executadas para que as pessoas tenham o melhor
rendimento no melhor ambiente possvel;
As regras do jogo que influenciam as pessoas esto neste plano. Um conselho. normalmente
til. estar explicitamente registrado que os responsveis pelas atividades so coresponsveis com o gerente de projetos na garantia de que as pessoas necessrias estejam
disponveis a tempo. Tambm devem ser descritos os mecanismos de apoio a este processo.
10.2 Planejamento Organizacional

O planejamento organizacional envolve as atividades de identificar e documentar as
responsabilidades e papis de pessoas e grupos no projeto. O benefcio mximo para o
projeto pode ser obtido quando o Planejamento Organizacional feito nas fases iniciais. De
pouco adianta informar a um gerente de departamento que sua rea tem um papel
fundamental na fase do projeto que comea amanh. As pessoas devem ser envolvidas o
mais cedo possvel. tarefa do gerente de projetos mant-las envolvidas.
O Planejamento Organizacional deve ser parte integrante do Plano de Projeto e deve estar
extremamente relacionado com o Planejamento de Comunicao. Ele deve responder a trs
perguntas simples: Quem faz o qu ? Quando as pessoas devem se envolver ? Quem se
reporta a quem no projeto ?
10.2.1 Definio de Responsabilidades e Papeis

A pergunta Quem faz o que ? a mais importante no Planejamento Organizacional. Aqui
existem duas premissas para o sucesso:
! Os recursos necessrios para cada atividade no projeto devem estar disponveis
quando necessrio. No antes ou depois. A quantidade deve ser a absolutamente
necessria. No mais e nem menos.
! Cada atividade dever ter uma pessoa como responsvel. Esta nica pessoa deve:
o
tomar providncias para garantir que a atividade tenha sucesso;
tomar decises que afetem a probabilidade de sucesso da atividade;
responder pelo fracasso ou problemas da atividade;
Pgina 98 de 190
A primeira premissa a base do planejamento de recursos. Nas fazes iniciais do
planejamento no necessrio que o gerente de projeto tenha detalhes de todos os recursos
do projeto, incluindo nomes especficos. No entanto, ele deve:
! Garantir que os tipos de recursos planejados (mesmo que no identificados
individualmente) podero ser requeridos por ele quando se tornarem necessrios. Por
exemplo: pode ser suficiente a garantia formal de um chefe de departamento de que
liberar algum para uma determinada fase do projeto mesmo se ele no fornecer um
nome especfico.
! Garantir que os recursos especficos para as prximas atividades estaro disponveis e
cientes de suas tarefas, ou seja, saberem que papis iro desempenhar no projeto.
Se a primeira premissa define os papis (Quem executa o que ?), a segunda premissa
define as responsabilidades (Quem decide e responde pelo qu ?) e condio necessria
para o sucesso da primeira.
A restrio de que uma nica pessoa seja responsvel importante. Este um conselho a ser
seguido sempre que possvel.
A maneira mais efetiva de afundar uma atividade deixar um comit responsvel por ela. De
fato, se voc no quiser que um determinado projeto tenha sucesso, mas no quer arcar com
a responsabilidade de ir frontalmente contra ele, determine que um comit seja responsvel
pela sua execuo. Quando o projeto fracassa, por pura paralisia, sempre se pode dizer que
uma tentativa foi feita e, como um comit era o responsvel, ningum individualmente
prejudicado. Comits servem para analisar problemas por diversos ngulos e tomar decises
pontuais. Nisso so excelentes. Como rgo executivo, simplesmente no funcionam.
Uma possvel exceo regra de responsabilidade pessoal a de terceirizao de parte do
projeto. Neste caso, a responsabilidade tomada contratualmente por toda a organizao do
fornecedor.
O planejamento de recursos, que define e controla os trabalhadores e equipamentos
necessrios, parte integrante do planejamento de atividades. De fato, os softwares de
controle de projeto permitem que os recursos sejam armazenados como parte do registro da
atividade. Eles fornecem inclusive histogramas de utilizao de recursos. Falaremos deles no
item seguinte.
A definio de responsabilidades, porm, deve ser parte do Plano do Projeto. A ferramenta
mais utilizada para esta definio chamada de Matriz de Responsabilidade. A Matriz de
Responsabilidade liga o WBS a pessoas (preferencialmente) ou grupos. A ligao pode ser
feita em qualquer nvel do WBS. Se uma pessoa designada como responsvel por um nvel
superior, ela se torna automaticamente responsvel por todo o ramo da rvore que est
abaixo deste nvel. Em nveis inferiores, a responsabilidade pode ser delegada mas, como em
qualquer delegao, o responsvel superior pode se livrar dos detalhes sobre a atividade, mas
no pode se livrar da responsabilidade sobre ela.
Alm da responsabilidade direta, outros tipos de relacionamento com as atividades podem ser
registrados, tais como o de aprovador ou simples colaborador. O importante que as pessoas
saibam o que se espera delas.
comum colocar o cargo ao lado do nome da pessoa. Isso serve para guiar o Gerente de
Projeto caso haja mudanas na estrutura da empresa durante o projeto (o que pode incluir a
substituio do prprio gerente do projeto).
Pgina 99 de 190
O exemplo abaixo mostra uma matriz possvel montada a partir do WBS.
Projeto XPTO
WBS
Gerenciamento do Projeto
Criao do Ambiente de
Hardware e Rede
Desenvolvimento do
Aplicativo
Estabelecimento
do Projeto
Levantamento
Anlise
Planos
de Gerenciamento
Dimensionamento
Projeto
Acompanhamento
e Controle
Segurana
Construo
Implantao
Homologao
Acompanhamento
de Produo
Implantao
Atividade Gerenciamento Acompanhamento

do Projeto
e Controle
Pessoa
R
R
Joo Gerente do Projeto
Maria Gerente dos Usurios
Criao do
Ambiente
Pedro Coord. de Segurana
Tiago Ger. de Sistemas
A Aprova
Desenvolvimento
do Aplicativo
Jos Ger. de Produo
R Responsvel
Segurana
P - Participa
10.2.2 Alocao e Liberao de Pessoal

No item anterior, verificamos como as responsabilidades so registradas na Matriz de
Responsabilidades. Vimos que os papis de execuo so registrados no prprio software de
projetos. Mencionamos tambm que no prtico tentarmos individualizar os papis muito
cedo no projeto.
Nesta seo, veremos como o Gerente de Projeto e os responsveis pelas atividades
controlam como os recursos humanos sero alistados e liberados do projeto. Existem alguns
mecanismos para auxiliar o gerente de projetos nesta tarefa: um mecanismo prev a utilizao
de histogramas de utilizao de recursos. Os softwares de projetos podem ler as informaes
registradas por atividade e fornecer uma viso por recurso. Esta viso toma forma de
histogramas que fornecem a informao de quando um recurso ser necessrio. A prxima
figura contm histogramas-exemplos tirados de nosso projeto simplificado. Analis-la pode
demonstrar alguns casos interessantes.
O primeiro recurso, o Analista de Suporte, comea junto com o projeto. Isso significa que ele
j deve ter sido designado antes do projeto comear. Se ele no for alocado a tempo, o
projeto j comear atrasado. Uma das caractersticas do mau gerenciamento de projetos a
de permitir que ocorram buracos na alocao de recursos dentro do caminho crtico do
projeto.
Analisando um pouco mais este recurso, vemos que ele fica sem tarefas durante a terceira
semana do projeto. Este um tempo proporcionalmente curto em comparao com o tamanho
do projeto. Nestes casos, o gerente de projeto pode analisar a alternativa de no liberar o
recurso durante a semana ociosa. Com isto ele evita que haja atrasos no retorno do recurso a
atividade na semana seguinte. claro que esta alternativa ir depender de negociao com o
responsvel pelo recurso e do custo que esta semana adicional pode causar ao projeto, mas
estes problemas devem ser pesados contra os riscos da liberao temporria do recurso.
Pgina 100 de 190
O segundo recurso comea aps o projeto j ter se iniciado. O risco de falhas na ativao
neste tipo de recurso maior. Isso porque, na alocao da equipe inicial, o problema tinha
toda a ateno do gerente de projetos mas, nas alocaes que ocorrem no meio do projeto, o
gerente de projeto est com sua ateno dispersa entre os diversos aspectos da
administrao do projeto. Os histogramas so um meio de alertar o gerente de projetos para
estas mudanas no status de alocao.
Novamente aqui, a alocao do recurso irregular durante o projeto. Aps a terceira semana
ele no tem qualquer atividade. Porm, ele deve retornar ao projeto na ltima semana. Neste
caso no h muita opo. No se pode exigir que um recurso fique a maior parte do tempo do
projeto parado, enquanto aguarda que seja necessrio novamente. O gerente de projeto deve
liber-lo e fazer acordos para garantir que ele esteja novamente disponvel quando
necessrio.
Na verdade, este caso apenas um exemplo de uma situao bastante comum.

Freqentemente o gerente de projetos no tem funcionrios diretos. Todos os recursos para o
projeto devem ser obtidos com outras reas ou com terceiros. No basta o gerente de projeto
enviar, no incio do projeto, uma requisio de recursos para o responsvel e esperar que eles
apaream nos prazos determinados. quase certo que, ao longo do tempo, os compromissos
com o projeto sejam esquecidos. Para evitar isto, o gerente de projetos pode enviar
notificaes sobre a previso de uso dos recursos. Podem ser usadas notificaes com uma
antecedncia prefixada (ex: uma semana antes do recurso ser necessrio), com antecedncia
ajustada pela dificuldade de obteno do recurso (ex. especialistas ocupados podem receber
avisos com mais antecedncia), ou mesmo um sistema com mltiplas notificaes (ex. trs
alertas com antecedncia de: 1 ms, uma semana e dois dias).
Estas notificaes podem ser formais (como um sistema de autorizao de trabalho) ou to
informais quanto um telefonema. No entanto o gerente de projeto deve manter registros de
controle sobre estas atividades.
Tanto quanto a alocao, a adequada liberao dos recursos deve ter a ateno do gerente
de projetos. Recursos cobrados por hora podem ser uma despesa cara se no forem
liberados.
Um aspecto constantemente esquecido pelo gerente de projetos que, em muitos casos, o
emprego dos membros da equipe vinculado existncia de projetos. Isso especialmente
verdadeiro em Organizaes de Projetos. Se um membro da equipe v a data de fim de sua
alocao se aproximar sem que ningum converse com ele sobre o futuro, certamente
Pgina 101 de 190
pensar o pior. Ele sabe que, se no houver um novo projeto, ele pode ser dispensado. A fuga
de recursos nas fases finais de um projeto pode ocorrer se as pessoas comearem a procurar
outros empregos de maneira preventiva.
A nica maneira de evitar este problema a comunicao. A menos que voc esteja
realmente planejando a demisso de toda a equipe, esclarecer seus planos e perspectivas de
forma honesta vai ajudar a mant-los.
10.2.3 Aquisio de Pessoal

Nos itens anteriores, ns vimos como um gerente de projetos deve definir os papeis
necessrios para o projeto e como ele deve controlar a alocao e liberao destes recursos.
Neste item ns esclareceremos o processo que vai da identificao de um papel at a
individualizao do recurso que o executar.
O primeiro passo detalhar as necessidades do projeto. No cronograma. pode estar
especificado que ser necessrio um determinado perfil genrico, por exemplo, um
programador. Mas isto insuficiente. preciso definir o conhecimento requerido para o
programador e tambm seu nvel de experincia. Essa definio pode dar origem ou no a um
documento formal de perfil de pessoal, mas ela deve estar clara na mente do gerente do
projeto.
Uma vez definidos os perfis, o gerente do projeto pode lanar mo de trs vias para aquisio
de pessoal:
! Pr-Alocaes Em alguns casos uma equipe pode ter sido pr-alocada para o
projeto. Este o caso quando o projeto fruto de uma concorrncia e a especificao
do time de projeto era parte da proposta. Tambm acontece que alguns gerentes de
projeto so tambm gerentes funcionais e tm a sua disposio um time de
profissionais alocveis ao projeto.
! Negociaes O gerente de projeto pode ter que negociar com gerentes funcionais ou
outros gerentes de projetos, os recursos necessrios para o projeto. Habilidades de
negociao, um bom patrono e um projeto com boa visibilidade valem ouro nestes
casos.
! Terceirizao O processo de terceirizao pode ser utilizado para obter os recursos
desejados. Isso necessrio quando a organizao no dispe de uma equipe com os
perfis necessrios ao projeto. Mesmo quando estes recursos existem, eles podem j
estar comprometidos com outros projetos. altamente recomendvel para um gerente
de projetos, que tenha que terceirizar sua equipe, formalizar em detalhes o perfil de
cada recurso necessrio.
10.2.4 Organograma do Projeto

O Organograma do Projeto um grfico que mostra os relacionamentos de reporte no projeto.
Em projetos maiores, em que o trabalho de gerenciamento do projeto dividido, ele pode ser
altamente complexo. Em projetos menores, a estrutura hierrquica pode ser to simples e
conhecida que dispense a criao do diagrama.
Um uso interessante do organograma incluir alm da linha de reporte abaixo do gerente de
projetos, os relacionamentos entre os diversos Stakehorders. Por exemplo: ele pode definir,
entre os clientes, qual tem a deciso final em relao ao escopo, ou incluir um registro de
quem o sponsor do projeto logo acima do gerente de projeto.
Pgina 102 de 190
10.3 Alocao de Recursos no MS Project
A maioria dos conceitos sobre planejamento e criao de cronogramas so facilmente
traduzidos durante a utilizao de ferramentas de software como o MS Project. Cada
atividade uma linha no grfico de Gantt. Uma hierarquia de atividades semelhante ao WBS
pode ser criada pelo uso de tarefas de sumrio. As dependncias entre tarefas so
registradas por links entre elas. Aps o planejamento, a ferramenta tem uma opo de menu
que permite o salvamento da linha de base do projeto.
No entanto, no caso da alocao de recursos, o usurio deve conhecer um pouco do
funcionamento interno da ferramenta de modo a utiliz-la corretamente. Os algoritmos
embutidos fazem suposies com base em determinadas configuraes e ajustam parmetros
de prazo, esforo e unidades de recurso, automaticamente. freqente que o gerente de
projeto tente fazer uma alterao no planejamento e receba uma mudana no cronograma que
no espera ou compreenda. De modo a prover informao para resolver este problema,
vamos sair um pouco da linha deste trabalho e mergulhar no maravilhoso mundo do MS
Project.
Quando uma tarefa inserida no MS Project e tem sua durao especificada, a ferramenta
no aloca automaticamente nenhum recurso. Se inserirmos uma tarefa de 80 horas, isso
refletir-se- em uma durao de 10 dias. Se olharmos o registro de Trabalho, ele estar
zerado. Se no h recursos, no h trabalho.
No momento em que inserirmos a primeira lista de recursos na tarefa, o MS Project calcular
o Trabalho. Se, por exemplo, informamos que dois recursos esto alocados para nossa tarefa
e que ambos tero uma dedicao de 50%, ento a ferramenta alocar um total de 80Hh
(homens-hora) de Trabalho. At este ponto no importa que configurao esteja definida para
a tarefa, o MS Project agir sempre da mesma maneira.
No entanto, o gerenciamento de projetos uma atividade dinmica. muito comum que
precisemos modificar o planejamento inicial de uma atividade. Poderemos descobrir que a
atividade precisa de 100Hh de esforo e no de 80Hh. Ou poderemos querer aumentar a
quantidade de recursos pretendendo diminuir o prazo. Vrias alteraes so possveis. No
entanto, a maneira da ferramenta reagir s alteraes pode variar radicalmente. Cada tarefa
pode ser individualmente configurada para diferentes reaes.
A reao do MS Project governada por uma equao bastante simples:
Durao Total = Trabalho Total
Unidades
de Recursos
Em nosso exemplo, a Durao Total de 80hs, o Trabalho Total de 80Hh sendo executado
pelo total de 1 homem (50% do recurso A mais 50% do recurso B). A conta confere
perfeitamente e o MS Project vai garantir que ela continue batendo, no importando o que o
usurio faa.
A primeira configurao importante um pequeno campo chamado de Controlada pelo
Empenho. Quando este campo est desabilitado, qualquer recurso adicional que a tarefa
receba gera um aumento do trabalho total. O MS Project vai entender que o gerente de
projeto inicialmente subdimensionou o esforo e est adicionando recursos para corrigir isto.
O prazo da tarefa permanece inalterado.
Quando o campo Controlada pelo Empenho est ligado, porm, o MS Project entende o
exato oposto. Este o modo conhecido como trabalho por mutiro, em que os recursos
adicionais diminuem o esforo individual. O esforo em homens-hora no campo Trabalho
permanecer inalterado e a ferramenta entende que outras dimenses na tarefa devem ser
alteradas. Qual delas depende de uma outra configurao que veremos a seguir.
Pgina 103 de 190
Se analisarmos a equao, veremos que tem 3 variveis e o gerente de projetos pode mudar
apenas uma de cada vez. A ferramenta tem que decidir o que fazer com as outras duas para
que a equao permanea equilibrada. O que ela faz definir que uma delas deve
permanecer fixa e modificar a que sobra. Essa a segunda configurao importante, definida
no campo Tipo de Tarefa.
O campo Tipo de Tarefa pode ter 3 valores possveis: Unidades Fixas, Durao Fixa e
Trabalho Fixo.
O que acontece se mudamos de idia com relao a nossa tarefa-exemplo e resolvemos que
os recursos ficaro alocados integralmente tarefa ? Estamos modificando o somatrio de
unidade de recursos passando de 1 homem (50% de A e 50% de B) para 2 homens (100% de
A e 100% de B). O MS Project tem que reagir para equilibra a equao. Se definirmos que a
tarefa do tipo Trabalho Fixo, ento a ferramenta modificar a nica dimenso que sobra, a
Durao. Seguindo a equao teremos:
Durao Total = 80Hh / 2H = 40h
Por outro lado, se tivermos definido que a tarefa do tipo Durao Fixa, a ferramenta
modificar o Trabalho Total.
Trabalho Total = 80 h * 2H = 160Hh
Se a configurao estiver em Unidades Fixas, o MS Project tambm alterar o Trabalho.
Vejamos uma outra possibilidade: digamos que no fizemos o exerccio anterior. Em vez disso
voltamos ao planejamento original e a dimenso que desejamos alterar a durao da
atividade. A durao passa a ser 40hs.
Se definirmos que a tarefa do tipo Trabalho Fixo, a ferramenta ter que modificar a
dimenso restante, Unidade. Seguindo a equao teremos:
(Unidades de Recursos) = 80Hh / 40h = 2H

O MS Project perceber que ele tem que dobrar as unidades de cada recurso passando a
alocao de cada um deles de 50% para 100%.
Se estamos lidando com Unidades Fixas, a ferramenta ajustar o trabalho total da atividade.
Trabalho Total = 40 h * 1H = 40Hh
Se a tarefa estiver com Durao Fixa, ela seguir, neste caso, o mesmo comportamento de
Unidades Fixas.
Falta analisar como as duas configuraes trabalham juntas. No caso de Trabalho Fixo a
mudana do parmetro Controlada pelo Empenho desabilitada. Isso parece lgico porque
se j decidimos que o trabalho total fixo em qualquer alterao de recursos, ele tambm
ser fixo na adio de novos recursos. Mas ainda podemos ter combinaes de tarefas
Controladas pelo Empenho, tanto com Unidades Fixas quanto com Durao Fixa.
No caso de Unidades Fixas, se aos recursos originais adicionarmos um recurso C com 100%
de alocao, a durao da tarefa ser alterada.
Durao Total = 80Hh / (50% A + 50% B + 100% C) = 80Hh / 2H = 40h
Nenhuma novidade at aqui. Mas guardamos a situao mais interessante para o final. Se a
tarefa for do tipo Durao Fixa e j fixamos o Trabalho Total, ento a nica coisa que o MS
Project pode fazer alterar a prpria unidade de alocao. Se o trabalho permanece fixo em
80Hh e a durao permanece fixa em 80hs a equao nos informa que:
(Unidades dos Recursos) = 80Hh / 80h = 1H

Pgina 104 de 190
Ns inserimos um recurso adicional e agora o MS Project tem 3 recursos reais para dividir
uma unidade de recursos. O que a ferramenta pode fazer ? A resposta que passamos a ter
33% de alocao de A, 33% de alocao de B e 33% de alocao de C. Obviamente o
gerente de projetos, que acabou de informar que queria que o recurso C ficasse 100%
alocado tarefa, ficaria extremamente confuso com o resultado. Provavelmente, ele ficaria
olhando para a tela amaldioando o software. No entanto, a raiva intil. Uma vez que
entenda como o MS Project funciona, voc pode convenc-lo a fazer exatamente o que
quer, bastando apenas configurar essas duas opes.
Uma informao til aqui que o comportamento padro do MS Project o de tarefas com
Unidades Fixas e Controladas pelo Empenho e esta configurao justamente a mais
adequada e comportada para a maioria das situaes. Alm disso, importante saber que a
alterao das configuraes deve ser feita antes do replanejamento. Uma vez que o MS
Project fizer algo estranho porque a tarefa estava configurada para Durao Fixa, de nada
adiantar mud-la para Unidades Fixas, porque ele no recalcular absolutamente nada.
Nestas horas, que damos valor quela cpia de segurana, em disquete, que fizemos do
planejamento original. Se que no nos esquecemos de faz-la.
10.4 Recursos Compartilhados

Voltaremos agora ao problema da utilizao de recursos compartilhados em um ambiente de
mltiplos projetos. Vamos recordar algumas de nossas concluses relacionadas ao assunto:
! O uso de Multitarefa em atividades dependentes de esforo sempre leva a
desperdcios de tempo. A maneira mais eficiente de lidar com uma pilha de trabalhos
deste tipo dedicar sua ateno total a cada trabalho e s iniciar o prximo quando o
anterior estiver encerrado.
! Mesmo sem os efeitos negativos da Multitarefa, quando um recurso compartilhado
entre mltiplos projetos a durao real das atividades no ser igual ao esforo
estimado convertido para horas ou dias corridos. Isso porque, se duas ou mais tarefas
forem simultaneamente enviadas para o recurso, somente uma delas poder ser
iniciada imediatamente.
! Se os recursos compartilhados forem administrados por negociao individual com
cada projeto, o resultado provvel o uso de Multitarefa e a priorizao inadequada
das atividades, gerando problemas graves de atrasos.
! As tcnicas de administrao de recursos compartilhados atravs de planejamento
centralizado so trabalhosas, altamente dependentes da qualidade do registro de
informaes e inadequadas para a maioria dos ambientes complexos.
Precisamos de um processo que priorize os projetos mais importantes, mantenha foco nos
interesses globais da organizao e diminua os prazos de entrega dos projetos, sem que um
controle central excessivo seja utilizado. Parece uma misso impossvel !
Primeiramente, precisamos compreender melhor o fenmeno com que estamos lidando.
Existem diversos nveis e tipos de compartilhamentos de recursos e devemos estabelecer
exatamente qual o problema que nos preocupa.
A rigor, qualquer recurso, que no esteja 100% comprometido ao projeto, pode ser definido
como compartilhado. Mas esta definio abrangente demais. Digamos que determinadas
tarefas espordicas ao longo do projeto exigem um recurso que no pertence equipe
dedicada. J vimos que, utilizando as tcnicas de alocao e liberao de pessoal descritas
neste captulo, podemos gerenciar a participao destes recursos com um mnimo de
dificuldades. Desta maneira, eles se dedicam 100% s suas tarefas, embora no tenham
dedicao exclusiva ao projeto como um todo.
Pgina 105 de 190
Em outros casos, haver recursos que no podero ter dedicao integral, mesmo na tarefa.
Digamos, por exemplo, que precisamos de um funcionrio do cliente para atividades de
validao de deliverables e produtos intermedirios. Se essas tarefas exigirem um tempo
considervel, o cliente talvez no possa autorizar a dedicao exclusiva do funcionrio.
comum que o funcionrio seja liberado para trabalhar no projeto, por exemplo, pela manh e,
tarde, em suas atividades normais. Como conseqncia, o tempo das tarefas aumentar e
sofreremos alguns dos efeitos nocivos da Multitarefa. No entanto, esse nvel de
compartilhamento pode ser planejado com antecedncia e seus efeitos sobre o cronograma,
previstos. De qualquer forma, o cliente se recusar a ceder o recurso em tempo integral e s
nos resta nos resignarmos com esta soluo conciliatria.
Este tipo de compartilhamento, porm, exige um cuidado adicional. Temos que garantir que o
recurso efetivamente dedicar ao projeto o tempo combinado. Preferencialmente, devemos
tentar remover o recurso de seu local normal de trabalho e/ou enviar um membro da equipe do
projeto para acompanhar a execuo da tarefa nos horrios combinados. claro que
prudente ter bastante flexibilidade no controle da dedicao de um recurso do cliente.
Devemos apenas tentar que, na mdia, ele oferea ao projeto a dedicao combinada. O que
definitivamente no funciona enviar o trabalho do projeto ao recurso e voltar para cobrar os
resultados na data marcada. O projeto entrar como mais uma das tarefas em cima da mesa
e, sem nenhuma cobrana constante, acabar tendo prioridade cada vez menor.
Esses recursos no dedicam 100% do tempo ao projeto ou s suas tarefas. Mas. as tcnicas
de negociao caso a caso, juntamente com um bom acompanhamento da execuo das
tarefas parecem ser suficientes para resolver ou, pelo menos, controlar o impacto do
problema. Ainda no localizamos nosso problema.
Precisamos nos perguntar: que tipo de recurso compartilhado gera todos os efeitos
desastrosos que analisamos, gerando atrasos de dezenas de vezes o tempo planejado e
ameaando projetos e organizaes inteiras? A resposta pode depender do tipo de
organizao e at variar de projeto para projeto. Veremos, mais tarde, que identificar estes
recursos no difcil. Bata procurar por seus efeitos. A ttulo de exemplo, podemos identificar
o caso mais comum. Trata-se de departamentos que fornecem servios para a organizao.
Essas reas oferecem, por definio, servios compartilhados. Elas recebem solicitaes de
toda a empresa, tm sempre uma pilha de pendncias e negociam caso a caso diretamente
com os solicitadores. So o ambiente perfeito para o aparecimento de Multitarefa, prioridades
equivocadas e tempos de atendimentos absurdamente grandes.
Para esses casos que precisamos de ferramentas especiais, alm das tcnicas de
negociao e do planejamento central. A soluo muito mais simples do que se pode
imaginar pela extenso do problema. Trata-se da mera aplicao de bom senso e algum
conhecimento sobre certos fenmenos probabilsticos. No entanto a implementao da
soluo exige mudanas de mentalidade gerencial que no so, de modos algum, triviais.
Para ilustrar a soluo usaremos um problema retirado de um caso real, em um de nossos
clientes. A rea de Tecnologia da Informao deste cliente era composta por profissionais
selecionados por critrios rgidos e que recebiam treinamentos freqentes. Consultoria,
software e hardware eram disponveis de maneira abundante, bem acima da mdia do
mercado. A quantidade de profissionais, tanto efetivos quanto terceiros era igualmente acima
do que seria o normal no mercado. Ressaltamos esses pontos para deixar claro que os
problemas que descreveremos no eram decorrentes de incompetncia tcnica ou de falta de
recursos.
A despeito de todo o enorme investimento que a organizao provia para a Tecnologia da
Informao, os projetos sistematicamente atrasavam. De fato, eles eram planejados, com
freqncia, com o dobro do prazo que seria comum em outras empresas e, apesar disso,
atrasos que dobravam ou triplicavam a durao planejada dos projetos eram bastante
comuns. A insatisfao das reas clientes era notria e como, por poltica da empresa, eles
Pgina 106 de 190
poderiam contratar servios diretamente de terceiros, muitos projetos saiam completamente
do controle da Tecnologia da Informao. claro que no se chega a uma situao como esta
em decorrncia de um nico problema. Vrias premissas incorretas estavam embutidas no
estilo e na cultura administrativa da empresa, mas as falhas na utilizao de recursos
compartilhados, como veremos, contribua enormemente para a situao. Por isto mesmo
gerariam o maior impacto positivo se solucionadas.
10.4.1 Identifique a Restrio do Sistema

Nosso mtodo uma aplicao dos princpios da Teoria das Restries de Goltratt e comea
com a identificao do problema. Em nosso caso, precisamos descobrir o que est causando
os atrasos. Para isto no necessrio nenhum ferramental matemtico ou tcnica complexa
de anlise. Basta que faamos algumas perguntas aos gerentes de projetos:
! Em que tipo de tarefas os projetos comeam a atrasar ?
! Que tipo de atividade demora desproporcionalmente em relao ao esforo estimado
para sua execuo ?
! Existe algum ou algum setor que voc tem que ficar cobrando e pressionando para
que o trabalho seja feito ?
Se existir um problema de gargalo no processo, estas perguntas, ou outras semelhantes
apontaro direto para departamentos que prestam servios compartilhados. Na maioria dos
casos, apenas um, ou no mximo dois gargalos sero identificados. As pessoas reclamaro
de uma infinidade de problemas, mas o gargalo verdadeiro dever estar presente na maioria
das respostas. No caso do tipo de projetos que tivemos contato em nosso exemplo, a resposta
seria praticamente unnime: o problema est na Infra-estrutura.
A Infra-estrutura, no caso, era um pequeno departamento, com 4 profissionais liderados por
um coordenador sem qualquer capacidade gerencial ou conhecimento administrativo. Todos
os gerentes de projetos tinham que negociar com ele. E sua postura era, admitidamente, criar
dificuldades para qualquer projeto que aparecesse.
A rea era fundamental para qualquer projeto da organizao, mas ela era basicamente
avaliada pela capacidade de manter o ambiente estvel. Evidentemente qualquer projeto gera
mudanas no ambiente e esta perturbao tem alta probabilidade de diminuir a estabilidade
do sistema. Isso inevitvel e foge do controle da rea mas, como dissemos, ela era avaliada
pela sua capacidade de manter a estabilidade. Deste modo, qualquer dificuldade artificial que
diminusse o ritmo dos projetos era internamente vista como benfica.
Alm disso, os 4 profissionais deveriam servir no s aos projetos, mas tambm s
solicitaes decorrentes das atividades de rotina da empresa. Como resultado, o nvel de
utilizao destes recursos era altssimo, praticamente sem horas ociosas. Isso era bem
avaliado pela gerncia como sendo um uso eficiente do oramento da rea.
A conseqncia desse estado de coisas era que, toda vez que os projetos precisavam de
servios da Infra-estrutura eles simplesmente paravam. Problemas que poderiam ser
resolvidos em uma hora se arrastavam por semanas. Como a participao deste
departamento ocorria vrias vezes ao longo dos projetos, isto tinha o efeito de gerar
adiamentos absurdos nos prazos finais.
10.4.2 Explore a Restrio do Sistema

A identificao do gargalo apenas o primeiro passo de nossa soluo. Se fosse possvel
criar um cronograma centralizado das atividades da Infra-estrutura, o problema estaria
resolvido. Porm, o tipo de servio deste departamento no se presta ao planejamento
detalhado. As atividades variam muito em esforo e durao, dependendo dos problemas
encontrados no caminho. Situaes inesperadas podem fazer, e normalmente fazem, com que
Pgina 107 de 190
os projetos necessitem de servios que no estavam planejados. Para qualquer um que
conhea esse tipo de trabalho parecer claro que um planejamento central das atividades em
todos os projetos completamente invivel.
Sabendo que a Infra-estrutura o gargalo que impede que os projetos tenham melhor
performance e que a organizao atenda de maneira adequada aos seus clientes, parece
lgico que o prximo passo seja evitar que existam desperdcios no uso do gargalo.
Devemos remover qualquer obstculo para o melhor aproveitamento do gargalo. Em nosso
caso, os obstculos principais esto ligados poltica de administrao da rea. A gerncia
deve entender a participao da rea no sucesso ou fracasso dos projetos e mudar o modo
como ela avaliada. Deve ser buscado um ponto de equilbrio entre estabilidade e mudana
de modo atender aos interesses amplos da empresa. Nenhuma dificuldade artificial deve ser
criada para os projetos.
A mentalidade do coordenador de minimizar os riscos era outro obstculo. Qualquer
solicitao que pudesse gerar um mnimo de risco estabilidade da estrutura era negada por
princpio, sem avaliar os benefcios para a empresa em correr esses riscos. Qualquer situao
que violasse as regras estritas colocadas para o atendimento era rejeitada sem qualquer
anlise ou exceo. Somente depois de vrias negociaes, o gerente de projeto conseguia o
apoio necessrio, porm a atividade j estava atrasada.
A mentalidade de otimizao local, risco mnimo e cumprimento estrito de regras genricas
tem que ser substituda pelo atendimento dos interesses do todo. Tal mudana de
mentalidade, infelizmente, com freqncia passa pela substituio da pessoa na liderana do
departamento. O coordenador em questo era o exemplo do resultado de anos de
condicionamento, em uma realidade em que o mau comportamento era premiado e o bom
punido. Isso, aliado as suas limitaes de capacidade gerencial, conhecimento e postura
pessoal tornariam a mudana de cultura quase impossvel e, sem dvida, extremamente
demorada. A organizao deve, em cada caso, fazer uma avaliao profunda da viabilidade
da mudana. Um requisito absolutamente necessrio, embora no suficiente: a pessoa deve
compreender e concordar com a nova poltica.
o lder do departamento gargalo que deve orientar a equipe na postura de atendimento aos
projetos. Ele deve organizar os trabalhos de modo a evitar o uso incorreto de Multitarefa.
ele quem deve liderar a implementao dos prximos passos da soluo. No se consegue
nada disto se a pessoa obrigada a tomar um caminho o qual no gosta nem acredita.
10.4.3 Subordine tudo explorao da restrio

Identificamos o gargalo e removemos as causas de desperdcio, removendo atrasos
desnecessrios. Mas isso no suficiente! Fica claro em nossa descrio do problema que a
rea tem excesso de trabalho. Precisamos de uma maneira de utiliz-la de forma eficiente
para a organizao.
Este um problema de otimizao de uso de recurso com capacidade limitada. No podemos
atender rapidamente a todas as solicitaes.Somos obrigados a prioriz-las.
fcil perceber que cada projeto deve receber uma classificao de prioridade. Mas quem
define a prioridade ? Essa uma questo chave. Certamente, no podem ser os funcionrios
ou o coordenador do departamento gargalo. Isso o que ocorre normalmente quando no
existe uma prioridade clara. Como cada projeto possivelmente atende a um cliente diferente, o
cliente tambm no parece ser a melhor opo para definir prioridades. Cada um definir o
seu prprio projeto como o mais importante. O mesmo problema ocorre com os gerentes de
projeto.
No existe uma resposta correta. Os interesses dos acionistas deveriam definir a prioridade
dos projetos. Os nveis gerenciais prximos ao topo da pirmide so mais sensveis a esses
interesses, mas eles podem no avaliar corretamente os projetos. Em alguns casos, se os
Pgina 108 de 190
projetos forem pequenos, talvez nem mesmo tenham interesse em faz-lo. Nveis gerenciais
mais baixos compreendem melhor os projetos e do mais ateno a eles, mas podem ser
influenciados por critrios da poltica interna da empresa, alheios aos interesses dos
acionistas. Por estes fatos, o processo especfico deve ser adaptado para cada organizao.
Aqui, sugerimos um processo genrico.
Os projetos devem nascer classificados como de prioridade Normal. Isso deve garantir a eles
que suas tarefas sejam executadas na frente das tarefas cotidianas de prioridade mais baixa.
Em nosso exemplo, a Infra-estrutura deve atender s solicitaes dos projetos com status
Normal na ordem exata em que chegarem. Atividades que no pertencerem a projetos, mas
que sejam mais urgentes, podem ser executadas antes das atividades de projetos normais,
caso contrrio, as pendncias referentes a projetos devem ser atendidas primeiro.
Se algum projeto, por um motivo de negcio, ou porque est atrasado, ou mesmo porque foi
planejado com prazos muito apertados, necessitar de um atendimento prioritrio, isso deve ser
reconhecido primeiro pelo gerente de projeto. Este deve ento negociar a mudana de status
do projeto para prioridade Alta.
Se alguma atividade de um projeto com prioridade Alta for encaminhada para o gargalo, ela
deve se tornar a primeira da fila de execuo. Se j existirem outras tarefas de projetos de alta
prioridade, as mais antigas so executadas em primeiro lugar.
No necessrio, nem desejvel, que se criem muitos nveis de prioridade. Desde que a
prioridade Alta s seja usada quando necessrio, ela ser suficiente para gerenciar o
gargalo. Mltiplos nveis de prioridade podem gerar discusses inteis sobre quem mais
importante. Se a organizao preferir criar um nvel adicional de prioridade Muito Alta, para
as emergncias, isto provavelmente no far mal. No entanto, ns ainda preferimos a
elegante simplicidade dos dois nveis.
Organizada de modo a atender a esta poltica, a Infra-estrutura poderia diminuir radicalmente
os tempos de atendimento para os projetos prioritrios. Os projetos normais tambm se
beneficiariam por um fluxo mais estvel e confivel de atendimento. Nenhuma atividade
passaria a frente por critrios que no fossem os interesses do negcio.
10.4.4 Eleve a Capacidade da Restrio

Nos passos anteriores ns garantimos o uso da capacidade atual do gargalo da melhor
maneira possvel. Em muitos casos, isso pode ser suficiente para gerar um nvel de servio
adequado para a empresa.
Em outros, evitar desperdcios e utilizar o gargalo de maneira a privilegiar os projetos mais
importantes pode no ser suficiente. Esses passos so absolutamente necessrios mas,
mesmo depois deles, o gargalo pode continuar a afetar a performance de toda a organizao.
Nesse ponto devemos nos perguntar: interesse da organizao que este gargalo exista ?
Talvez isto no faa sentido do ponto de vista do negcio. Neste caso, ser o momento de
buscar aumentar a capacidade do recurso compartilhado em atender aos projetos.
Em nosso exemplo, houve pelo menos uma vez em que o oposto foi feito. Uma das 4 pessoas
da equipe era um tcnico excepcionalmente bom e com uma postura de atendimento
igualmente boa. No entanto, seu custo estava acima da mdia do mercado. De modo a reduzir
o custo ele foi substitudo por um profissional mais barato. Neste tipo de servio, a velocidade
e qualidade do atendimento variam ordens de grandeza entre um timo profissional e um
profissional mediano. Se fosse medido em produtividade, a empresa certamente teria uma
perda enorme com a troca.
Este tipo de departamento deve garantir que seu quadro contenha os melhores profissionais
disponveis. Performances medocres no so admissveis quando os interesses de toda a
organizao esto em jogo. Um movimento correto seria pesquisar a existncia de
Pgina 109 de 190
profissionais fracos na equipe e substitu-los, mesmo que gerando um pequeno aumento de
custo.
Em alguns casos podemos aumentar a produtividade sem aumentar os custos. Veremos, no
captulo de qualidade, tcnicas de como fazer isso. Basicamente, trata-se de identificar as
causas mais freqentes de problemas e gerar aes que melhorem o processo de
atendimento. Se, por exemplo, identificarmos que um determinado tipo de atendimento gasta
muito tempo da equipe, podemos analisar maneiras de prestar o mesmo servio de modo
mais rpido, talvez pela racionalizao do procedimento ou pelo uso de ferramentas melhores.
Uma outra maneira de aumentar a capacidade disponvel transferir parte do servio para
outras reas da empresa. Sempre existe alguma redundncia dentro das organizaes e em
outros departamentos podem existir recursos ociosos que poderiam absorver parte das
responsabilidades da rea gargalo.
Finalmente, chegamos ao ponto mais sensvel: aumentar a capacidade da rea atravs de
investimentos em recursos extras. Nessa deciso, teremos novamente que combater o erro
conceitual universal nas organizaes: a otimizao local.
Para compreender o problema podemos lanar mo da Teoria das Filas. A fila, neste contexto,
o acmulo de solicitaes de trabalho aguardando para serem atendidas pelos recursos da
rea gargalo. Uma fila caracterizada por algumas grandezas. Duas das mais importantes
so: o ritmo de chegada das solicitaes () e a taxa de atendimento mdio de cada recurso
(). possvel demonstrar que a taxa de utilizao mdia () dos recursos dada pela
frmula:
Onde M a quantidade de atendentes.

Por exemplo, se temos 4 recursos, cada um com a capacidade de atender, em mdia, a 5
chamados por dia e a rea recebe 15 chamados por dia, teremos 75% de taxa de utilizao.
Nesse caso, cada recurso do departamento ficaria, em mdia, um quarto do tempo ocioso por
falta de servio.
Segundo a Teoria das Filas, o comportamento da quantidade mdia de elementos na fila ir
ser previsvel, uma vez que se conhea a taxa de utilizao dos recursos. O grfico abaixo
mostra o modelo de uma fila terica conhecida como M/M/1. Nossa fila real teria valores
diferentes, mas o comportamento geral seria o mesmo.
45
40
35
30
25
20
15
10
5
0
50%
55%
60%
65%
70%
75%
80%
Pgina 110 de 190
85%
90%
95%
100%
Se o ritmo de chegada das solicitaes for maior do que a taxa de atendimento total do
sistema, ou seja, se for maior do que 1, nossa fila terica ir aumentar infinitamente. No
mundo real, ir ser criada uma demanda que ser ou reprimida ou atendida por um outro
meio. Em nosso exemplo, os clientes poderiam desistir de seus projetos ou tentar a
terceirizao sem a participao da Tecnologia da Informao. Porm no necessrio que
as solicitaes superem o atendimento para que os problemas comecem a acontecer.
Na figura, podemos ver claramente que, conforme o ndice de utilizao aumenta, a
quantidade de itens na fila aumenta exponencialmente. Quando temos taxas de utilizao
prximas a 50% a fila muito pequena e assim o tempo total entre uma solicitao e seu
atendimento baixo. Praticamente igual ao tempo real de execuo da tarefa sem contar o
tempo na fila. Por outro lado, conforme as taxas de ocupao sobem acima de 80%
rapidamente grandes filas so geradas. Em certo ponto, o tempo de espera na fila comea a
ser muito maior do que o tempo de atendimento. Podemos ver este fenmeno em nosso
cotidiano, quando temos que fazer um pagamento em um banco muito cheio. Para diminuir
este problema, em sistemas industriais comum a substituio de certos equipamentos
quando a taxa mdia de utilizao atinge 90%.
Sabemos que a taxa de utilizao dos recursos da Infra-estrutura era altssima. Talvez, at
maior do que o 100% terico, uma vez que horas extras eram comumente utilizadas. Como
vimos, isso era bem visto pela gerncia. Essa a mentalidade de otimizao local. A suposta
economia gerada pela manuteno dos recursos com uma alta taxa de utilizao gerava filas
enormes de trabalho pendente que, por sua vez, geravam atrasos e custos extras em toda a
organizao. Se olharmos para os gastos da empresa como um todo, e no para os gastos
locais de um departamento, veremos que a remoo do gargalo, pelo aumento de capacidade
da rea, muito mais econmica.
Quanto precisaramos adicionar em capacidade? A mesma Teoria das Filas nos fornece a
direo da resposta. Observem que, no importando qual o tamanho atual da fila, se
dobrarmos a quantidade de recursos (M), e no existir nenhuma demanda reprimida, a taxa de
ocupao cair abaixo de 50% e teremos nveis de servio espetaculares. Isso,
provavelmente, seria um desperdcio, mas nos fornece um teto para o investimento.
Em nosso caso, como existe demanda reprimida, poderamos adicionar recursos um a um,
monitorando o tamanho das filas e a taxa de utilizao, at que esta se estabilize abaixo de
80%.
Uma vez que todos estes passos fossem seguidos, os projetos teriam um aumento
significativo de performance. No entanto, rapidamente o nvel de exigncia dos clientes se
adaptaria ao novo nvel de servio e novas restries de capacidade poderiam surgir em
outros pontos da empresa. Assim, o passo final do nosso mtodo : no deixe a inrcia se
transformar em uma restrio. Busque um processo de melhoria contnua, em que o sistema
permanentemente questionado em busca de oportunidades de melhoria.
Pgina 111 de 190
10.5 Desenvolvimento da Equipe
Desenvolvimento da Equipe um processo com dois objetivos:
! Melhorar a habilidade e o conhecimento individual dos stakeholders em sua
contribuio ao projeto,
! Melhorar a habilidade e o conhecimento da equipe no trabalho em conjunto;
O primeiro objetivo reconhece que uma equipe bem qualificada essencial para o projeto. De
fato, uma boa equipe freqentemente a diferena entre o fracasso e o sucesso. Este
desenvolvimento individual pode ter uma dimenso gerencial, principalmente para os
membros mais seniores, ou tcnica, para a maioria.
Por outro lado, a experincia comprova que o trabalho em equipe fundamental. De nada
vale um tcnico excelente que cause distrbios e no apie seus colegas. O segundo objetivo
reconhece que o desenvolvimento como equipe crtico para o projeto. Algumas tcnicas
recomendadas so listadas a seguir.
10.5.1 Treinamento Tcnico

O treinamento tcnico a atividade mais comum de desenvolvimento de equipe. tambm a
mais incua. Embora o treinamento formal seja necessrio, particularmente para os membros
menos experientes, em muitos casos, ele no gera os aumentos esperados de produtividade.
Membros mais experientes podem se beneficiar da participao em congressos e seminrios,
trazendo para o projeto as novidades em termos de tecnologia, bem como experincias de
outras organizaes.
10.5.2 Mentoring
Mentoring, ou treinamento durante a execuo da tarefa, parece ser um bom meio de
aprimorar a capacidade tcnica da equipe. O Mentoring parece mais efetivo quando as
questes mais simples j foram endereadas por meio do estudo individual ou por um
treinamento bsico. O especialista pode ento acompanhar a equipe na execuo de tarefas
reais, ajudando a resoluo de problemas prticos e adaptando o conhecimento terico a
realidade do projeto.
10.5.3 Atividades de Construo de Equipe

A melhor maneira de construir o esprito de equipe envolver os membros no processo de
planejamento e nas decises tomadas durante o projeto.
Algumas vezes um processo mais dirigido necessrio. Tcnicas de Coaching podem
resolver o problema de recursos tecnicamente valiosos, mas que tm dificuldades de
relacionamento.
Algumas empresas fornecem cursos de melhoria de relacionamento pessoal. Os resultados
desse tipo de ao so duvidosos.
10.5.4 Habilidades de Gerenciamento

Cursos de liderana, motivao, etc podem fornecer informaes interessantes a serem
incorporadas ao repertrio da equipe.
Particularmente, cursos de tcnicas de negociao podem fornecer ferramentas poderosas
para os membros mais expostos a conflitos com outros stakeholders.
Pgina 112 de 190
10.5.5 Sistemas de Recompensa e Reconhecimento
Sistemas de Recompensa e Reconhecimento so aes gerenciais que reforam
comportamentos por meio de algum tipo de recompensa. Esta recompensa pode ter vrias
formas: financeira, material, uma promoo, uma viagem, reconhecimento pblico etc. A
bibliografia recomenda, normalmente, que os sistemas faam uma ligao clara, explcita e
alcanvel entre performance e recompensa.
As tcnicas de avaliao formal e individual de performance parecem estar entranhadas na
cultura de nossas organizaes e so utilizadas quase universalmente. Na prtica, os
sistemas de recompensa acabam reforando apenas o comportamento de obter a
recompensa. muito freqente que os sistemas de medio sejam enganados por um
funcionrio esperto. Alm disso, mesmo sem manipulaes, os prprios indicadores podem
levar a otimizao local em prejuzo dos objetivos globais. W. Edwards Deming estudou e
combateu os sistemas de recompensa individuais. Para ele, esses sistemas retiravam a
motivao intrnseca que as pessoas sentem ao realizar suas tarefas. Outros pesquisadores,
como Coens e Jenkins, demonstraram as conseqncias danosas e as falhas nos
pressupostos dos sistemas de avaliao.
Bons sistemas de recompensa so aqueles oferecidos a toda a equipe, amarrados aos
resultados globais do projeto. Esse tipo de sistema refora o esprito de equipe.
Recompensas individuais (como promoes de carreira) podem ser dadas aps uma anlise
profunda da contribuio individual para o sucesso do projeto e da organizao, mas no
devem ser automticas e calculadas sobre indicadores simplistas.
10.5.6 Colocao Fsica

A colocao de todos ou quase todos os membros do projeto na mesma localidade fsica
melhora a habilidade de trabalhar como uma equipe. Isso algo que a tecnologia de
telepresena ainda no conseguiu substituir.
10.6 Motivao Teorias X,Y e alm

Muito se tem pesquisado, escrito e discutido sobre como motivar pessoas. H muito tempo se
sabe que as velhas tcnicas comportamentalistas de motivao baseada em recompensas se
comprovaram ineficientes. Vamos analisar as principais alternativas que foram propostas ao
longo dos anos e propor uma soluo que parece ser a mais adequada para projetos.
As idias de Frederick Hezberg esto entre as mais conhecidas e fornecem uma base para a
interpretao de outras teorias. Ele acreditava que as atitudes das empresas com relao a
seus empregados podiam ser classificadas em dois conjuntos de fatores:
! Fatores Higinicos Incluam o salrio, o status e a segurana oferecidos pelo
emprego. Esses fatores no geram motivao embora sua ausncia possa gerar
desmotivao.
! Fatores Motivacionais O reconhecimento, a responsabilidade, o grau de interesse da
tarefa e a possibilidade de atingir objetivos mais elevados poderiam gerar motivao.
No incio da dcada de 60, Douglas McGregor publicava o seu The Human Side of
Enterprise. Esta obra teve uma influencia profunda na maneira de analisar o comportamento
de pessoas nas organizaes. McGregor afirmava que todas as tentativas de motivar pessoas
poderiam ser classificadas de acordo com os pressupostos subjacentes em que elas se
baseavam. Ele identificou dois grupos de pressupostos opostos, ou Teorias, que suportavam
essas tentativas e as chamou de Teoria X e Teoria Y.
Pgina 113 de 190
! A Teoria X assume que as pessoas no gostam do trabalho e precisam ser coagidas,
controladas e dirigidas para os objetivos da Organizao. Alm disso, a maioria das
pessoas prefere ser tratada desta maneira uma vez que assim elas podem evitar
responsabilidade sobre suas aes;
! A Teoria Y enfatiza o interesse intrnseco que um profissional normal tem pelo seu
trabalho, seu desejo de ser autodirigido e buscar responsabilidades e sua capacidade
de ser criativo na resoluo dos problemas do negcio;
McGregor foi influenciado pela hierarquia de necessidades do psiclogo Abraham Maslow.
Maslow acreditava que existem 5 conjuntos de objetivos que podem ser chamados de
necessidades bsicas do ser humano. Quando um nvel de necessidades est satisfeito, o ser
humano busca satisfao do prximo nvel.
! Necessidades fisiolgicas como comer e dormir;
! Segurana proteo contra perigos e privao;
! Amor dar e receber afeto ou ter um certo sentimento de pertencer;
! Estima o desejo de se destacar, de ter uma reputao e reconhecimento de seus
pares;
! Auto-Realizao o desejo de se auto-aprimorar e exercer criatividade;
Uma vez que a maioria dos empregos ajudava ou satisfazia as trs primeiras necessidades,
Maslow sugeria que as empresas deveriam dirigir seu foco para as duas ltimas. Assim,
McGregor definia a Teoria Y, mais compatvel com as idias de Maslow, como sendo a mais
desejvel e aconselhava os gerentes a segui-la. Isso, claro, pressupunha que uma escolha
era inevitvel. Como a Teoria X j havia se mostrado falha, restava aos gerentes seguir a
Teoria Y.
Uma viso, chamada de Teoria da Contingncia, questionou a necessidade e a possibilidade
de uma soluo nica, aplicvel a todos os casos. Esta , em nossa opinio, a teoria que mais
parece funcionar no ambiente de gerenciamento de projetos. A idia bsica que no existe
uma nica maneira correta de motivar pessoas em geral. O que devemos buscar a tcnica
mais adequada para ambos, o grupo de pessoas e a tarefa em questo.
Um estudo de Morse e Lorsch, publicado na Harvard Business Review de maio de 1970,
analisou a eficincia das Teorias X e Y em diferentes grupos de pessoas e empresas. Eles
analisaram dois laboratrios de pesquisa e duas empresas de manufatura. Os pares de
empresas analisadas eram muito semelhantes em vrios aspectos, menos no estilo de
administrao de pessoas.
Morse e Lorsch descobriram que um dos laboratrios de pesquisa tinha uma estrutura
altamente informal, com poucos controles, ciclos de tempo de avaliao bem amplos e baixa
evidncia de hierarquia. Essas caractersticas levavam ao uso natural da Teoria X e,
efetivamente, tanto o nvel de motivao dos cientistas, quanto a eficincia dos projetos de
pesquisa pareciam ser muito superiores em comparao com o laboratrio onde os controles
eram relativamente maiores. Ponto para a Teoria X !
Os resultados do estudo para as empresas de Manufatura, porm, mostrou um quadro
diferente. Uma das empresas de manufatura possua nveis hierrquicos bem definidos, alto
nvel de formalismo e de padronizao de procedimentos, avaliaes e controles freqentes e
baixa autonomia de ao individual. A Teoria X prev que esse tipo de ambiente sempre
resulta em empregados desmotivados e baixa eficincia generalizada, mas isso no
espelhava a realidade. Os empregados pareciam muito mais satisfeitos com seu trabalho e a
empresa demonstrava resultados melhores do que sua gmea mais informal.
Os pesquisadores acreditavam que o resultado de sua pesquisa s poderia ser explicado por
uma maior adequao do estilo gerencial com a natureza especfica das tarefas e dos
Pgina 114 de 190
empregados das empresas. Os pesquisadores dos laboratrios precisavam de liberdade para
preservar sua capacidade criativa. Os operrios, por outro lado, se sentiam mais seguros
conhecendo os procedimentos que levariam automaticamente aos melhores resultados. Do
ponto de vista da eficincia, os procedimentos formais se adaptavam ao tipo de indstria do
estudo, porque ela possua um processo simples e altamente estvel. Por outro lado, ningum
pode criar um procedimento formal que substitua a criatividade de um bom cientista.
A experincia comprova que um indivduo tem uma forte necessidade de se sentir adaptado
ao meio em que est, e este fator parece ser o mais forte motivador a disposio das
empresas. Pessoas que tem seus fatores higinicos atendidos e que se sentem competentes
e adaptadas cultura do grupo se tornam satisfeitas e contentes. No importa o quanto voc
elogie um funcionrio ou lhe oferea prmios, se ele no se sentir competente e adaptado
naquilo que faz, ele nunca ficar completamente motivado.
Para gerar esta motivao nossa sugesto que as organizaes coloquem seus esforos em
duas frentes:
! Melhoria de Processos O modo de trabalho deve ser adequado ao tipo de
atividade, de modo que as pessoas sintam que fazem parte de um sistema e
no que lutam contra um. Conhecimento sobre Teoria dos Sistemas, Variao,
Teoria das Restries etc. deve ser utilizado para aperfeioar a organizao e
sua administrao.
! Poltica de Recursos Humanos A empresa deve buscar pessoas que, no s
possuam capacidade tcnica, mas que tenham, por sua personalidade e
caractersticas pessoas, maior possibilidade de contribuir para o sucesso da
organizao. Na maioria dos casos, isso significa pessoas compatveis com os
valores e cultura da empresa. No s o processo de recrutamento deve ter
esse foco, mas a administrao deve continuamente buscar e substituir aqueles
que, claramente, no conseguem se adaptar.
Pgina 115 de 190
11 Comunicao
Informao uma arma extremamente importante para o gerente de projetos. Na verdade,
todo processo de planejamento e controle do projeto envolve comunicao de informaes.
Ele deve ser a aranha no centro da teia de informao do projeto. Afinal ele o responsvel
pelo projeto e se no tiver acesso a todas as informaes necessrias de forma atualizada,
certamente tomar decises erradas ou, o que talvez seja at pior, no conseguir tomar
decises.
Existem dois tipos principais de comunicao com as quais o gerente de projeto deve se
preocupar:
! Interna ocorre entre o gerente de projeto e as equipes ou entre as equipes.
! Externa comunicao da equipe do projeto com os outros Stakeholders.
Principalmente os clientes e a alta gerncia.
11.1 Plano de Gerenciamento de Comunicao

O Plano de Gerenciamento de Comunicao cobre a definio de regras sobre:
! Como os vrios tipos de informaes sero coletadas e atualizadas no decorrer do
projeto;
! Os fluxos formais de informao, documentando quem deve gerar que informaes
para quem;
! A estrutura das informaes que sero distribudas. Padres de documentao (Ex.
formato de atas de reunio), se aplicveis, devem ser documentados.
! O procedimento de quando cada tipo de informao deve ser produzido e divulgado.
Podem-se definir tanto periodicidades quanto eventos geradores;
! Os mtodos de acesso informao;
11.2 Comunicao Interna

De uma forma geral, toda equipe de projeto tem algumas necessidades bsicas de
informao:
! Responsabilidade Cada equipe deve saber que parte do projeto est sob sua
responsabilidade;
! Coordenao Cada equipe deve ter conhecimento do trabalho no resto do projeto de
modo a que o trabalho se desenvolva de forma conjunta e coordenada;
! Decises As decises tomadas devem ser informadas a todas as equipes afetadas,
principalmente decises que alterem o escopo ou que definam especificaes
tcnicas;
! Questes, Pendncias e Riscos Tudo que pode afetar o projeto deve ser divulgado;
Por outro lado as equipes devem manter o gerente de projeto atualizado em relao a:
! Status O progresso do trabalho de cada equipe deve ser comunicado de forma que o
acompanhamento do o projeto seja possvel;
! Questes, Pendncias e Riscos O gerente de projetos s pode tomar aes
corretivas sobre aquilo que ele foi informado;
Pgina 116 de 190
11.3 Matriz de Comunicao
O modo como a informao formal ser distribuda para os Stakeholders deve ser
claramente definido. Talvez a maneira mais simples de garantir isso seja atravs da criao de
uma Matriz de Comunicao
A Matriz descreve, para cada informao significativa, quem ser o gerador e o receptor da
informao, com que freqncia ela deve ser gerada e qual formato e meio deve possuir.
O exemplo abaixo se refere a um pequeno projeto com um nvel mdio de formalizao.
Informao
Responsvel
Alvo
Freqncia
Formato
Relatrio de
Acompanhamento
Gerente do Projeto
Sponsor
Semanal
Relatrio Word c/
template
RELPROJ.DOT
anexo a email
Produtos Acabados em
verso final
Gerente do Projeto
Sponsor
Nas milestones
Reunio para
apresentao
Mudanas no Status de
Riscos
Gerente do Projeto
Sponsor
Na mudana de
Status
Telefone ou email
ou Pessoalmente
Histrico do Projeto
Gerente do Projeto
Sponsor
Informaes de
Acompanhamento
Responsvel pelo
Work Package
Gerente do Projeto
Ao termino de Work
Package ou, no
mnimo, Semanal
Telefone ou email
ou Pessoalmente
Mudanas Importantes
no Status do Projeto,
incluindo Riscos
Equipe do Projeto
Gerente do Projeto
Na mudana de
Status
Telefone ou email
ou Pessoalmente
Informaes de
Acompanhamento
Equipe do Projeto
Responsvel pelo
Work Package
Ao termino de Work
Package ou, no
mnimo, Semanal
Telefone ou email
ou Pessoalmente
Sempre que alterado Web Site de Projeto
11.4 A Sala de Guerra

Freqentemente os projetos envolvem equipes trabalhando em locais diversos. O projeto,
nestes casos, carece de um local fsico que o caracterize. Para solucionar este problema,
podem ser criadas Salas de Guerra onde os membros do projeto tenham livre acesso e em
que possam compartilhar informaes.
Na Sala de Guerra, podem estar, em permanente exibio, documentos e informaes
atualizados sobre:
! Planejamento e status do projeto;
! Decises importantes;
! Questes, Pendncias e Riscos;
Ao visitar a Sala de Guerra, o membro da equipe pode no somente tirar suas dvidas, mas
tambm entrar em contato com o que est acontecendo no resto do projeto e prever ou
resolver questes e problemas.
Atualmente, Salas de Guerra virtuais na forma de um website para o projeto vm sendo
bastante utilizadas. Embora elas no possam substituir a sensao de envolvimento provida
por uma sala real, elas so uma soluo excelente quando o time ou os Stakeholders esto
geograficamente dispersos.
Pgina 117 de 190
11.5 Reunies de kick off
O momento exato de incio de um projeto nem sempre possvel de ser identificado. Assim,
aconselhvel que o gerente de projeto providencie uma espcie de cerimnia para celebrar o
nascimento de um novo projeto e proclamar a todos a sua existncia.
Essas cerimnias so comumente chamadas de reunies de kick-off, ou pontap inicial.
Sua importncia no deve ser subestimada. Elas fornecem a energia inicial ao projeto e
ajudam no envolvimento dos stakeholders. Normalmente se reconhece que existem dois
tipos de reunies de kick-off:
! Kick-off Interno Este um tipo de reunio em famlia entre o gerente do projeto e os
principais membros da equipe. No h uma regra fixa de quem deve ser chamado para
essa reunio. Podem ser includos, por exemplo, os gerentes funcionais que
fornecero a equipe. O objetivo principal a equalizao do conhecimento a respeito
do projeto e o estabelecimento de um entrosamento inicial.
! Kick-off Externo Essa reunio envolve os clientes e/ou a alta gerncia e tem um
carter mais formal. As linhas gerais do plano de projeto devem ser discutidas. O
objetivo aqui aumentar a definio do escopo do projeto e de como ele ser
desenvolvido.
No necessrio que todos os envolvidos compaream a reunio. Ns j vimos outras
tcnicas que permitem uma ao mais abrangente de comunicao. No entanto, o gerente de
projeto deve fazer um esforo especial para que aqueles que contribuem para as atividades
mais criticas compaream. Outras pessoas, que tenham uma participao relativamente
menor podem receber cpias das atas de reunio ou um pequeno texto informando o que se
espera de sua participao.
Pgina 118 de 190
12 Riscos
A incerteza uma certeza na vida de um gerente de projetos. Vimos, na definio de projeto,
que cada um nico. Cada um reserva suas surpresas apenas para seu gerente de projeto.
Gerenciamento de Riscos uma das maneiras pelas quais a incerteza sistematicamente
gerenciada para que a probabilidade de sucesso do projeto aumente. Praticamente tudo que o
gerente de projetos faz pode ser classificado nesta definio, mas Gerenciamento de Riscos
um conjunto de atividades em que o gerente de projetos conscientemente busca identificar e
lidar com riscos.
O tipo de incerteza que lidamos no gerenciamento de riscos a que Deming chama de causa
especial de variao, ou seja, algo que pode afetar o desempenho do sistema de modo a que
ele fuja da variao normal de um sistema sob controle. Por definio um risco algo que se
espera que no acontea. Ele no faz parte do desempenho normal do sistema.
Quando lidamos com o outro tipo de variao, a variao de causa comum, estamos lidando
com variaes dentro de limites de controle. Quando projetos sistematicamente terminam
atrasados no devemos buscar causas especiais, ou seja, no devemos culpar o azar e os
riscos. As alternativas so melhorar o processo de desenvolvimento do projeto ou aumentar
as nossas estimativas de prazo.
O oposto ocorre quando lidamos com causas especiais de variao. Se aumentarmos nossas
estimativas de prazos ou mudarmos nosso processo em resposta a um acontecimento nico,
teremos estimativas e processos piores. A maneira correta de lidar com uma causa especial
de variao evitar que ela ocorra ou, se isso no for possvel, limitar seu impacto. Em
resumo, temos que gerenciar os riscos.
Um risco sempre envolve duas caractersticas:
! Incerteza O fato real que caracteriza o risco pode ou no acontecer. A incerteza
medida em termos de probabilidade, ou seja chances em termos de porcentagens
maiores do que 0% e menores que 100%. No existe risco com 100% de chance de
ocorrer. Isto no seria um risco mas uma condio do projeto.
! Impacto Se o risco se tornar realidade, conseqncias indesejadas ocorrero. Alguns
autores, inclusive o PMBOK, sugerem que eventos incertos que podem gerar
conseqncias positivas tambm sejam monitorados. A idia a de ativamente buscar
por oportunidades de ganho. No entanto, a gerencia clssica de riscos e a prtica da
maioria dos projetos lida somente com eventos prejudiciais.
Pgina 119 de 190
12.1 Plano de Gerenciamento de Riscos
O Plano de Gerenciamento de Riscos parte do Plano de Projeto e descreve como os riscos
so identificados, analisados, respondidos, monitorados e controlados. Ele no contm
detalhes sobre riscos especficos. Isso tarefa do Plano de Resposta a Riscos. Como os
outros planos de gerenciamento, o Plano de Gerenciamento de Riscos estabelece as regras
do jogo. Alguns itens que podem fazer parte do Plano de Gerenciamento de Riscos so:
! Metodologia Define quais so as tcnicas, ferramentas e fontes de dados que sero
usados no planejamento, incluindo o formato dos relatrios de acompanhamento.
! Papis e Responsabilidades Torna explcita a participao de cada Stakeholder no
controle de riscos. Responsabilidades especficas podem ser registradas na Matriz de
Responsabilidade do projeto. Tambm correto definir responsabilidades genricas,
por tipo de Stakeholder.
! Oramento Muitas tcnicas de resposta a riscos envolvem gastos. Os limites destes
gastos devem ser estabelecidos.
! Tempo A poca e a freqncia com que as atividades de gerenciamento de risco
sero executadas devem ser estabelecidas para garantir que mudanas no perfil de
risco sejam detectadas.
! Limites Critrios para o que se considera risco aceitvel ou risco alto devem ser
estabelecidos. A utilizao de Matrizes de Probabilidade/Impacto um exemplo
desses critrios.
12.2 Identificao de Riscos

O primeiro passo para a proteo contra riscos a identificao. Riscos desconhecidos no
podem ser gerenciados. Cada projeto, sendo nico, tem riscos especficos, mas projetos
semelhantes devem ter riscos semelhantes. As tcnicas de identificao de riscos devem
ajudar a identificar tanto os riscos especficos quanto queles comuns a vrios projetos.
O produto do processo de identificao de riscos simplesmente uma lista de riscos
identificados. aconselhvel que esta lista j esteja classificada por tipo de risco.
Aps a identificao dos riscos temos uma Lista de Riscos do Projeto que o documento de
entrada para os processos seguintes de gerenciamento de risco.
Existem trs tipos de riscos:
! Riscos Conhecidos So aqueles que so descobertos aps uma anlise cuidadosa
das circunstancias especficas do projeto, das caractersticas produto ou do plano do
projeto. So riscos especficos ao projeto, devido sua caracterstica nica.
! Riscos Previsveis So aqueles que podem ser extrapolados da experincia passada
com projetos semelhantes. So riscos genricos.
! Riscos Imprevisveis So o coringa do baralho. No importa o quo minuciosa seja a
anlise dos riscos envolvidos, sempre pode ocorrer um desastre que ningum poderia
imaginar.
Para identificar estes riscos existem algumas ferramentas. Citamos trs:
! Conversas com os Stakeholders Sesses de brainstorming, ou mesmo simples
entrevistas com todos os grupos envolvidos no projeto podem ser utilizadas para
detectar riscos. Simplesmente, pergunte o que pode dar errado e as pessoas tero
prazer em serem altamente criativas. Tcnicos especialistas so particularmente bons
em apontar monstros esperando no armrio. Deixe que falem e anote o que for
compreensvel. Essa ferramenta vai lhe oferecer os Riscos Conhecidos.
Pgina 120 de 190
! Uso de registros histricos Se houve projetos semelhantes deve haver considervel
quantidade de informao gerada pelos sobreviventes. O que deu errado antes pode
dar errado de novo. O que quase aconteceu da ltima vez pode acontecer realmente
dessa vez. Alguns tipos de projetos tm, inclusive, registros estatsticos publicados
sobre probabilidade de problemas. Existem tabelas que fornecem a probabilidade de
um incndio durante uma obra. Dados menos estruturados, como a confiabilidade de
um tipo de fornecedor, podem ser obtidos das histrias de terror sobre projetos
passados. Esta ferramenta vai lhe oferecer alguns Riscos Previsveis.
! Uso de Checklists ou Risk Profiles Um checklist de riscos uma lista de
perguntas, normalmente agrupadas por categorias, que endeream as reas de
incerteza tradicionais para o tipo de projeto. Esta ferramenta tambm vai lhe oferecer
alguns Riscos Previsveis.
12.2.1 Checklists de Riscos

Checklists de Riscos so desenvolvidos com base em informaes histricas e
conhecimento acumulado em projetos similares. Uma grande vantagem destas listas a
facilidade de utilizao. Elas, rapidamente, guiam o gerente de projeto para um
questionamento sobre o que pode dar errado em seu projeto.
Muitos checklists padronizados esto disponveis em publicaes ou na
Internet.
Checklists so ferramentas para descobrir Riscos Previsveis. Existem vrios nveis em que
os riscos so genricos. Existem vrios riscos inerentes natureza de todos os projetos. O
risco de alteraes do escopo, por exemplo, possvel em qualquer projeto, uma vez que todo
projeto tem um escopo. Listas com este nvel de generalizao tm uso limitado. Outros riscos
so inerentes atividade relacionada ao projeto. Projetos de desenvolvimento de sistemas de
informao tm riscos ligados tecnologia, por exemplo. Outros ainda, so inerentes
organizao que hospeda o projeto.
Quanto mais especfica for a lista, quanto mais adaptada e prxima da realidade do projeto,
mais til ela ser. Idealmente, o desenvolvimento dos checklists deve ser parte de um
processo contnuo. Ao final de um projeto, o que foi aprendido incorporado ao checklist.
As perguntas dos checklists so normalmente organizadas em categorias ou fontes de risco.
Podem existir perguntas referentes ao time do projeto, ao cliente, a tecnologia envolvida, ao
produto, ao gerente do projeto etc.
Abaixo est um pequeno exemplo de Checklist de Riscos.
Fontes de Risco:
Ambiente
Ambiente
Cliente
Cliente
Cliente
Cliente
Equipe
Equipe
Equipe
Equipe
Equipe
Perguntas sobre Riscos

Faltam ferramentas necessrias para a gerncia do projeto ?
Faltam ferramentas necessrias para o desenvolvimento do produto ?
Trata-se de um cliente desconhecido ?
O Cliente parece resistente a formalizao ?
O Cliente parece no engajado ao projeto ?
O Cliente parece no aceitar as regras acordadas para o projeto ?
Falta experincia coordenao ?
Falta experincia equipe ?
A equipe desconhecida ?
Existem membros trabalhando "part-time" no projeto ?
O turnover da equipe pode ser um problema ?
O gerente de projeto deve analisar cada pergunta e decidir se aquele risco especfico
existente e relevante no projeto. Em caso afirmativo, ele registra o risco para as prximas
etapas do Gerenciamento de Riscos.
Pgina 121 de 190
12.3 Anlise Qualitativa de Riscos
A Anlise Qualitativa de Riscos o processo de avaliar as duas caractersticas bsicas dos
riscos: Probabilidade e Impacto. O processo prioriza os riscos identificados de acordo com seu
efeito potencial nos objetivos do projeto. Para cada risco deve ser estimada a probabilidade de
que se torne realidade. Esta probabilidade normalmente expressa em percentagens, mas
elas podem ser descritas qualitativamente (Ex. muito alta, alta, moderada, baixa e muito
baixa). Pode ser estabelecida uma escala de converso. Por exemplo: uma probabilidade
muito alta pode equivaler a 75% de chance de ocorrncia.
O impacto tambm pode ser definido por uma escala ordinal (muito alto, alto, moderado, baixo
e muito baixo) ou numrica cardinal. Neste ltimo caso, no h necessidade de que a escala
seja linear. Pode-se usar uma escala no linear (ex. 0.05, 1, 2, 4, 8) de modo a realar os
riscos de alto impacto. Algumas vezes, utilizam-se valores financeiros para quantificar o
impacto. Nesses casos, os riscos seriam medidos em moeda corrente. No entanto, h
dificuldade de se definir valores em dinheiro para riscos de natureza intangvel, como a
insatisfao do cliente ou a perda de capital intelectual.
Devemos ressaltar que o impacto deve ser determinado em relao ao projeto como um todo.
Um atraso de 5 dias em uma tarefa do caminho crtico representa um impacto totalmente
diferente de um atraso de 10 dias em uma tarefa com folga de 15 dias.
A medida do risco chamada de exposio. Quanto maior a probabilidade associada ao risco,
maior a exposio. E quanto mais alto for o impacto, a exposio tambm aumenta.
freqente que o clculo da exposio seja simplesmente a multiplicao da probabilidade
pelo impacto. Se um evento tem 20% de chance de ocorrer e pode gerar um custo de
$50.000, ento a exposio seria de $10.000. Na verdade, esta uma boa tcnica quando o
impacto medido em termos financeiros. No entanto, recomendado o uso de tcnicas mais
sofisticadas para a derivao da exposio ao risco. Uma ferramenta de avaliao a matriz
de Probabilidade/Impacto. Ela contm valores de exposio associados a combinaes de
pares de probabilidade e impacto. Por exemplo:
Exposio
Impacto
Probabilidade
Muito
Baixo
Baixo
Mdio
Alto
Muito
Alto
75%
0,05
0,09
0,18
0,36
0,72
50%
0,04
0,07
0,14
0,28
0,56
30%
0,03
0,05
0,10
0,20
0,40
15%
0,02
0,03
0,06
0,12
0,24
05%
0,01
0,01
0,02
0,04
0,08
As reas mais escuras e com maior valor de impacto necessitariam de um tratamento de risco
mais forte do que as mais claras.
Uma ferramenta comum na analise qualitativa a Matriz de Riscos. Ela sumariza as
informaes quanto aos riscos Um exemplo colocado abaixo.
ID
1
Descrio
Se
Ento
Descrio do evento que geraria impacto

Conseqncias do evento
Probab. Impacto Exposio

30%
Alto
Alta
0,20
Uma vez que os riscos tenham sido analisados, eles so classificao por exposio. Da mais
alta exposio para a mais baixa. improvvel que a equipe de projeto possa dar conta de
uma lista muito grande de riscos. mais provvel que a lista inteira passe a ser ignorada.
Assim, prefervel uma lista menor, mas controlada de maneira ativa pela equipe. Para isto, o
gerente de projeto pode resolver ignorar os riscos de pequena exposio.
Pgina 122 de 190
12.3.1 Teoria da Utilidade
Cada pessoa reage de maneira diferente diante do risco. Aquilo que uma pessoa considera
aceitvel pode ser absurdamente arriscado para outra. A Teoria da Utilidade tenta criar um
modelo de como as pessoas reagem diante do risco. No mbito da gerncia de projeto, esta
teoria poderia ser usada para definir regras de modo a padronizar a analise de riscos de forma
independente da pessoa que executa a anlise.
Para entender como a Utilidade funciona, imagine que voc recebeu um bilhete, com um
prmio de $2000, em uma loteria da festa de fim de ano da empresa. Voc pode sair do jogo
agora e embolsar os $2000, mas para tornar a brincadeira mais divertida, o organizador da
festa prope um jogo adicional. Se voc concordar, o presidente da empresa ir jogar uma
moeda. Se o resultado for cara voc ganha $5000, mas se for coroa voc perde tudo.
Vamos calcular o valor esperado das duas opes. Se voc no continuar jogando, voc tem
100% de chance de ganhar $2.000, assim, o valor esperado desta alternativa $2.000. Mas
se continuar jogando voc tem 50% de chance de ganhar $5.000 e 50% de chance de no
ganhar nada. O valor esperado desta opo $2.500. Desta maneira nossa arvore de deciso
nos aconselha a continuar jogando. A grande maioria das pessoas ir parar.
A Teoria da Utilidade tenta explicar este fenmeno associando um valor, chamado de
Utilidade, a cada valor monetrio envolvido em escolhas. A utilidade sempre cresce quando os
valores crescem mas no cresce necessariamente na mesma proporo. Imagine que a curva
a seguir modela o nosso comportamento na festa.
1
0,75
$2.000
$5.000
Se calcularmos o valor esperado da Utilidade e no da quantia, temos uma utilidade de 0.75

para a opo de aceitar os $2.000 e uma utilidade de 0.5 (50% * 1 + 50% * 0) para a opo de
continuar jogando. Isto parece fazer sentido. O dinheiro certo que nos tira da misria parece
ter mais valor do que aquele duvidoso que pode nos tornar ricos.
Segundo a Teoria da Utilidade, existem trs posturas genricas com relao ao risco. Estas
posturas poderiam ser modeladas por uma das 3 curvas abaixo:
Curva de Averso ao Risco
Curva de Buscador de Risco

Utilidade
Utilidade
Quantia
Curva de Indiferena ao Risco

Utilidade
Quantia
Quantia
Seguir a curva de indiferena significa obedecer rvore de deciso. O buscador de risco o

viciado em adrenalina que gosta de apostar valores maiores. A maioria dos executivos, assim
como a maioria das pessoas, so do tipo com averso aos riscos. Se a organizao definir
uma curva de utilidade padro, isto poderia, em teoria, ser utilizado como balizador das
decises de risco.
Pgina 123 de 190
Parece que tudo se encaixa muito bem, mas muitos economistas criticam os prprios
pressupostos da Teoria da Utilidade. Na base da teoria est a crena de que as atitudes com
relao ao risco dependem apenas da diferena que isto pode fazer no seu nvel de riqueza.
O fato de as pessoas serem avessas a risco seria derivado apenas da concavidade da curva e
seu comportamento seria conseqncia desta concavidade e do grau de inclinao da curva
para um determinado nvel inicial de riqueza.
O exemplo que demos parece justificar esta afirmativa, mas ele foi escolhido por esse mesmo
motivo. Se analisarmos outras situaes a teoria no se mostra to perfeita.
Um dos problemas se refere aposta de pequenos valores. Quando estamos lidando com
pequenas quantias, em comparao com o nvel de riqueza da pessoa, a concavidade da
curva tem uma influncia desprezvel e as pessoas deveriam adotar uma atitude neutra em
relao ao risco. Mas a prtica mostra que as pessoas no so neutras em relao ao risco
nem para pequenas apostas.
Se este problema no parece suficiente para descartar uma teoria to elegante, saiba que o
modelo parece induzir recusa de verdadeiras barganhas.
Por exemplo, imagine que voc se recusa a apostar $10 contra uma chance de 50% de
ganhar $11 ou perder tudo. O valor esperado da aposta $10.5, o que a faz uma proposta
mais do que justa, se seguirmos uma tendncia neutra ao risco. Mesmo assim, recusar esta
aposta parece bastante razovel e a maioria das pessoas com uma atitude saudvel com
relao a risco a rejeitaria. At aqui no temos problemas com a teoria da utilidade.
O problema surge se a mesma pessoa que recusou esta aposta se vir diante de uma outra um
pouco maior, digamos, de $100. Se partirmos do princpio de que a teoria est correta, ela
rejeitaria, com certeza, um prmio de $110, o que seria proporcional primeira aposta. Mas
estamos em uma parte superior da curva onde ela est quase paralela ao eixo x e cada
quantia adicional que oferecemos vale menos e menos.
Se oferecermos um prmio de $1000 contra 50% de chance de perder $100 e a pessoa
recusasse j no pareceria prudncia, mas uma certa covardia. Porm, apenas baseado na
aposta original e na teoria da utilidade, seramos forados a prever que ela recusaria apostas
de $100 contra uma possibilidade de 50% de perder tudo ou ganhar no s $1000 mas
$10.000, $1.000.000.000 ou mesmo quantias maiores. Voc recusaria ?
O absurdo da situao evidente. Se crissemos um procedimento burocrtico baseado no
modelo da Teoria da Utilidade poderamos gerar uma barreira insustentvel para boas
decises com relao ao risco. O modelo, como sempre, poderia sugerir, mas no poderia
tomar a deciso.
Alguns economistas propuseram alternativas para essa teoria e prevem que, eventualmente,
uma delas ir substitu-la na criao de modelos de risco. Duas idias propostas por Rabin e
Thaler parecem promissoras, embora ainda no totalmente amadurecidas. O conceito de
Averso Perda define que as pessoas sentem mais intensamente a perda do que o ganho
de uma quantia de mesmo tamanho. No importando o nvel de riqueza de uma pessoa,
perder $10 significa mais do que ganhar $10. Esse conceito d conta da caracterstica de
averso ao risco sem cair em problemas com apostas pequenas. A Contabilidade Mental um
conceito complementar. Segundo ele, as pessoas julgam riscos financeiros de maneira
isolada, no levando realmente em conta seu nvel de riqueza ou outros riscos.
Seja qual for o modelo que suceder a Teoria da Utilidade, se isso realmente acontecer, ele
certamente ter suas prprias falhas e dificilmente ser um substituto para um Gerente de
Projetos com bom senso.
Pgina 124 de 190
12.4 Desenvolvimento de Resposta a Riscos
Aps a identificao e a anlise qualitativa dos riscos, deve-se proceder com o
desenvolvimento de um plano que estabelea como esses riscos sero tratados pelo projeto.
Existem algumas estratgias genricas para tratar riscos:
! Ignorar Riscos ignorados saem da lista de riscos e da mente da equipe. No h
nada de absurdamente errado em ignorar um risco. A realidade cheia de riscos
altamente improvveis. Se tentarmos planejar reaes a todos eles, chegaremos a
uma parania passvel de internao.
No entanto, devemos estar cientes que no caso de eventos associados a riscos
ignorados realmente ocorrerem, os danos provavelmente sero maximizados. S
tomaremos conscincia do problema quando ele j estiver bufando em nossos
pescoos. Teremos um tempo mnimo para pensarmos em como reagir e logo
passaremos ao. bastante provvel que essa ao consuma bastante tempo e
recursos.
! Aceitar Tambm chamada de aceitao passiva. Os riscos aceitos so monitorados.
A equipe pode detectar os primeiros indcios de que o risco ir se tornar um problema
real. Mas no h um plano prvio de resposta definida. Caso ocorram os indcios, a
equipe dever planejar a reao e execut-la. Aceitar o risco melhor que ignor-lo,
porque permite um planejamento mnimo e uma reao antes que o problema cresa.
! Monitorar Monitorar o risco , sutilmente, diferente de aceit-lo. Tanto que muitos
autores no separam essa estratgia da aceitao, chamando-a de aceitao ativa. A
diferena que o plano de resposta especfico elaborado antes dos primeiros
indcios. Dessa forma a equipe pode reagir imediatamente ao primeiro sinal do
problema. Os recursos necessrios podem estar previamente autorizados e
disponveis. Uma desvantagem o tempo e esforo que so gastos neste
planejamento prvio.
! Mitigar / Evitar Mitigar busca diminuir a probabilidade e/ou o impacto associados ao
risco. A idia transformar um risco de alta exposio em um risco de baixa
exposio. Tanto o planejamento quanto a ao real de resposta ao risco so
executados antes dos primeiros indcios. O princpio por trs da Mitigao que, no
caso de certos problemas, muito melhor tomar uma ao preventiva do que remediar
o problema depois que ocorra. Mitigar riscos freqentemente uma estratgica cara e
os custos da mitigao devem ser pesados com relao exposio do risco.
Mitigar um risco pode envolver alteraes no planejamento do projeto no sentido de
tomar um curso de ao que ir reduzir o problema. Um exemplo clssico o
desenvolvimento de um prottipo antes de aumentar a escala do projeto. Outras tticas
de mitigao envolvem o uso de sistemas redundantes, simplificao de processos,
testes preliminares e o uso de fornecedores de alta qualidade.
Algumas vezes, o processo de mitigao pode eliminar a possibilidade do risco. Por
exemplo: o cliente pode concordar em retirar um item problemtico do escopo do
projeto, ou o projeto pode ser transferido para uma rea fsica em que o risco no
ocorra (ex. no h risco de terremoto em larga escala no Brasil). Nesses casos a
estratgia chamada de Evitar o risco.
! Transferir Transferir o risco um tipo especial de mitigao. A idia permitir que o
problema ocorra se o risco se materializar, mas fazer com que este problema pertena
outra pessoa. O evento de risco ainda existe mas a exposio no. O uso de seguros
o exemplo clssico de transferncia de riscos. A terceirizao com preo fechado de
parte do projeto tambm um tipo de transferncia.
Pgina 125 de 190
O grfico a seguir ilustra as principais estratgias.
Primeiros
Indcios
Problema
Real
Ignorar
Aceitar
Monitorar
Mitigar
Conscincia
Planejamento
Ao
A matriz de riscos que vimos na anlise de riscos pode ser ampliada para conter informaes
de resposta aos riscos.
! Responsvel - Responsveis pelo risco so aqueles que devem ser envolvidos no
desenvolvimento da resposta ao risco, seja ela reativa ou proativa.
! Indicador Algumas vezes, possvel apontar os efeitos preliminares que indicam
que o risco est se tornando realidade. Por exemplo: o atraso em um pagamento um
indicador do risco de no pagamento. Alguns tipos de convocaes do sindicato so
indicadores do risco de greve. A idia no esperar at o ltimo minuto para reagir ao
risco.
! Estratgia Alm da estratgia genrica para o risco (Aceitar, Mitigar, etc.) esse
campo define como esta estratgia ser implementada para aquele risco em particular.
Se a estratgia for muito complexa, uma referncia para outro documento pode ser
registrada aqui.
ID
Responsvel
Descrio
Se
Probab. Impacto Exposio
Descrio do evento que geraria impacto
Nome do
Ento
Conseqncias do evento
responsvel por
Indicador
Descrio os primeiros indcios do problema
implantar a ao de
resposta ao risco Estratgia Descrio da estratgia genrica e dos detalhes
planejados.
30%
Alto
Alta
0,20
12.4.1 Planos de contingncia genricos.

No importa quo paranico um gerente de projeto seja, a maioria dos riscos so sempre
ignorados. A realidade catica demais para ser antecipada. Se o plano de riscos for bem
feito, a probabilidade individual dos riscos ignorados pequena. Mas, mesmo eventos muito
improvveis, s vezes, acontecem.
Para esses casos, podem ser desenvolvidos planos de contingncia genricos. O caso mais
comum simplesmente alocar uma folga de oramento para emergncias. No entanto, planos
mais elaborados podem ser definidos. Estes planos podem envolver o uso de opes
alternativas para a continuao das atividades. Por exemplo, um local alternativo, com
equipamentos alugados pode ser utilizado no caso de um desastre na sede do projeto.
Pgina 126 de 190
12.4.2 Riscos em Terceirizaes.
A terceirizao a custo fechado, de parte ou de todo o projeto , como j colocamos, uma
ttica eficaz de transferncia de riscos. No entanto, essa uma ttica freqentemente mal
utilizada.
Muitas empresas tomam a terceirizao a custo fechado como uma carta branca para permitir
alteraes de escopo e mau gerenciamento geral do projeto. Se houver clausulas contratuais
especificando corretamente o escopo, o fornecedor poder reivindicar aumento dos valores
envolvidos. Mesmo que estas clusulas no existam, o fornecedor pode chegar concluso
de que a perda de um cliente ou mesmo o risco de um processo tem um impacto menor do
que os custos de se manter no projeto.
Outro problema potencial, e muito freqente, o caso do fornecedor escolhido pelo menor
preo, sem levar em conta a sua capacidade real. As estimativas envolvidas na proposta
podem ter sido muito otimistas. Caso alguns riscos se materializem, o fornecedor pode vir a
no ter capacidade de custear o projeto e o cliente acabar tendo que arcar com as
conseqncias .
12.5 Controle e Monitorao de Riscos

Controle e Monitorao de Riscos o processo de acompanhar os status de cada risco
identificado, identificar novos riscos, garantir a execuo dos planos de ao e avaliar a sua
efetividade na reduo dos riscos.
Este um processo contnuo durante toda a vida do projeto. Durante o planejamento ns
temos uma viso dos riscos do projeto que pode, e provavelmente ir, mudar muito medida
que o tempo passa. recomendvel que ocorram avaliaes formais peridicas quanto ao
planejamento de risco, principalmente nas mudanas de fase de ciclo de vida. Mas controle de
risco algo que o gerente de projeto deve ter sempre em mente.
A matriz de riscos a melhor amiga do gerente de projetos nessa tarefa. Ele deve revis-la
com freqncia similar a que revisa o cronograma.
Todas as informaes que fluem para o gerente de projeto oferecem indcios sobre risco. Isso
particularmente verdadeiro com relao ao cronograma. Atrasos so fortes indicativos de
que os problemas antecipados se materializaram ou que riscos novos esto surgindo.
de fundamental importncia que o Gerente questione ativamente a equipe sobre possveis
problemas e riscos. Poucas pessoas gostam de ser mensageiros de ms notcias, mas
igualmente poucas escondero um problema se forem diretamente questionadas a respeito.
No caso de identificarmos que um risco est se tornando realidade, de fundamental
importncia que um responsvel especfico esteja designado para o plano de ao. Esse
responsvel pode, s vezes, ser o prprio gerente de projeto. Este , com freqncia, o
primeiro reflexo. Bons gerentes de projeto so orientados para ao. Se h algum problema,
eles se envolvem pessoalmente na resoluo. Mas bons gerentes tambm sabem quando
delegar. No h sentido em focar em um nico problema e deixar o resto do projeto sem
ateno.
Por vezes, os planos de ao originais acabam no sendo os melhores. medida que o
conhecimento sobre o projeto evolui, o gerente de projeto deve providenciar para que os
planos de ao sejam revisados. Planos que j estejam em andamento devem ser
monitorados para verificar se eles efetivamente esto administrando o risco de maneira
adequada.
Uma prtica bastante recomendada a de registrar os eventos, problemas e respostas
relacionados a risco. A criao de um banco de dados de riscos pode ajudar a organizao a
melhorar seus instrumentos de gerenciamento de riscos, incluindo os checklists.
Pgina 127 de 190
12.6 Anlise Quantitativa de Riscos
A idia bsica da anlise quantitativa de risco a de determinar as conseqncias de cada
risco para os objetivos do projeto, analisando numericamente as probabilidades de risco.
Tcnicas de anlise de deciso e simulao so recomendadas pelo PMBOK.
Como exemplo, destacam-se as rvores de Deciso e a anlise de Monte Carlo.
Uma rvore de Deciso, como j vimos, um diagrama em que cada alternativa
representada por uma bifurcao na rvore. Custos, recompensas e probabilidades podem ser
vinculadas a cada alternativa. Os valores mais provveis de cada caminho da rvore pode ser
calculado com base nas operaes bsicas de probabilidade. Deve-se, em princpio, escolher
o caminho com o melhor valor associado.
As anlises de simulao, como a de Monte Carlo, comeam pela associao de funes de
probabilidades a cada evento em estudo. Nmeros aleatrios so gerados tentando simular os
eventos reais. O resultado final de cada simulao armazenado para anlise. Se um nmero
suficiente de simulaes for gerado, informaes estatsticas como valor mdio e desvio
padro podem ser calculados. Essas estatsticas devem espelhar o comportamento, em
termos de distribuio de probabilidade do projeto como um todo.
Por exemplo: digamos que, antes do projeto se iniciar, queremos determinar como nosso
cronograma deve se comportar durante o projeto. Se utilizarmos PERT, temos os trs valores
de estimativa que nos permitem definir o formato da curva de distribuio de cada tarefa
individual. Usamos nmeros aleatrios para criar valores para cada tarefa de acordo com
estas curvas. O tempo total do projeto calculado somando os tempos individuais simulados.
Se repetirmos esse processo um grande nmero de vezes, poderemos traar a curva de
probabilidade da durao do projeto como um todo.
Usado desta forma, Monte Carlo uma sofisticao das estimativas de gerao de reserva
para PERT. A vantagem deste mtodo em comparao com aquele, muito mais simples, que
j vimos que a simulao de Monte Carlo levaria em conta os caminhos convergentes para o
caminho crtico. Essa utilizao estaria restrita para PERT porque CPM considera os prazos
como determinsticos e Critical Chain resolve o problema por seus prprios mecanismos.
Em sua forma bsica, Monte Carlo no uma ferramenta de anlise de risco. Ela levar em
conta apenas as formas de variao de causa comum do projeto. Riscos so causas especiais
de variao.
Alguns autores tm proposto expanses do modelo de modo a simular a introduo de riscos.
Cada risco identificado associado a uma funo de probabilidade e colocado de forma a
causar possveis impactos no cronograma ou nos custos. Esses modelos podem ser
extremamente complexos. De fato, para a maioria dos projetos, esse procedimento no s
complicado, ele completamente acadmico. As probabilidades das estimativas e riscos
individuais dificilmente podem ser definidas com preciso razovel. Desta maneira elas so
fruto de pouca evidncia e muita opinio. O resultado da anlise nos dir mais sobre os
preconceitos da equipe do que sobre o projeto em si.
Se essas ferramentas estiverem disponveis, elas podem contribuir para alguns insights do
Gerente de Projetos. Elas tambm podem ser utilizadas na anlise de risco financeiro junto a
potenciais investidores do projeto. Caso contrrio, certamente h maneiras mais efetivas de
investir recursos preciosos, como o tempo do Gerente do Projeto, principalmente se ele j tem
experincia suficiente para intuir o comportamento do tipo de projeto que tem pela frente.
Por outro lado, um dos usos mais interessantes da anlise de Monte Carlo no treinamento
de futuros gerentes de projetos. Podemos simular a resposta de projetos fictcios a decises
de planejamento dos estudantes. Esta uma maneira barata de aprender por tentativa e erro,
sem gastar os recursos das organizaes com projetos fracassados.
Pgina 128 de 190
12.7 Dimensionamento de Contingncia
Em face de toda incerteza que enfrenta, o gerente de projetos certamente procurar criar um
colcho de reserva que absorva problemas durante o projeto. Embora as duas estejam
relacionadas, o gerente deve dimensionar separadamente as reservas de prazo e de custo.
Para ambos os casos, a seguinte frmula genrica se aplica:
Contingencia Total = Variao Comum + Vis & Ris cos

J vimos os modos de dimensionamento da contingncia para variao de causa comum.
Eles dependem do tipo de filosofia de planejamento de cronograma:
! CPM No existe previso de contingncia, pois utiliza estimativas pessimistas;
! PERT Utiliza o desvio padro de cada tarefa no caminho crtico, calculado como 1/6
da diferena entre as estimativas pessimista e otimista. O desvio padro do projeto a
raiz quadrada da soma dos quadrados dos desvios padro das tarefas. A contingncia
normalmente dimensionada em duas ou trs vezes o desvio padro do projeto.
! Critical Chain Calcula a diferena entre as duas estimativas de cada tarefa na
Corrente Crtica. A contingncia alocada ao buffer de projeto a raiz quadrada da
soma dos quadrados das diferenas entre estimativas. Os buffers de convergncia
so calculados da mesma maneira.
Esses mtodos funcionam de maneira idntica tanto para o clculo de prazo quanto para o de
custos. Essa parte da contingncia deve ser suficiente para dar conta da variao natural da
execuo do projeto. No entanto, ela no leva em conta fatores que fujam do carter aleatrio
desta variao. Esses fatores so as causas de vis, que sempre influenciam negativamente o
projeto e os riscos, ou seja, as causas especiais de variao, externas ao sistema.
Exemplos destes fatores so:
! Omisses Mesmo os planos mais detalhados acabam omitindo tarefas necessrias
para o projeto. Isso particularmente verdadeiro nos projetos de escopo abstrato,
onde o aprendizado durante o projeto desempenha um papel importante. Em alguns
casos, o uso de checklists ou templates pode evitar que omisses importantes
ocorram. Omisses freqentemente so responsveis por aumentos de 5% a 15% no
custo do projeto. O impacto no prazo reduzido, principalmente se as omisses no
afetam a corrente crtica.
! Erros de Execuo Como veremos no captulo de Qualidade, o custo de erros pode
ser bastante alto. Quanto mais cedo o erro for percebido e corrigido, to menor ser o
impacto para o projeto. Erros podem gerar um impacto de 5% a 25% no prazo e de 5%
a 50% no custo. Se no houver um esforo de controle de qualidade no projeto, estas
faixas podem se mostrar conservadoras em seus limites mximos.
! Falhas de Dimensionamento J vimos que as estimativas de esforo sofrem causas
comuns de variao que so absorvidas pelo buffer de variao comum. No entanto,
algumas vezes os profissionais cometem erros de avaliao da complexidade da
tarefa. Nestes casos, as premissas que eles usaram estavam erradas, o que gera um
vis no tempo real de execuo. Essas falhas podem gerar impactos de 5% a 50%,
tanto no prazo quanto no custo. No h muito a fazer para evitar esse problema,
exceto proceder estimativas com o maior cuidado possvel.
! Nvel de Esforo O Nvel de Esforo, evidentemente, no causa atrasos no projeto.
No entanto atrasos que ocorram por outras causas prolongaro o Nvel de Esforo. O
impacto sobre o custo ser proporcional ao atraso e ao custo dirio de se manter o
projeto. Tudo que puder evitar atrasos ir prevenir esse custo adicional
Pgina 129 de 190
! Riscos Riscos so Causas Especiais de Variao. Eles podem gerar um impacto de
0% a 30% tanto no prazo quanto no custo. Todas as tcnicas de administrao de
risco que vimos neste captulo tentam minimizar esse impacto.
Analisando todas estas causas de atrasos ou aumento de custos, poderamos pensar que
uma reserva de contingncia de 50%, adicionada a contingncia de causa comum, seria uma
poltica at conservadora. No entanto, a maioria dos Clientes e Sponsors jamais aceitariam
uma contingncia deste tamanho.
O fato que, se a causa de variao comum est fora do controle do gerente de projetos, a
variao especial e o vis no esto. Os resultados reais sero tremendamente afetados pela
competncia do gerente de projetos e da equipe.
Em qualquer caso, recomenda-se que o tamanho total da contingncia de prazo no seja
menor do que 25% da durao da Corrente Crtica e que o tamanho total da contingncia de
custo no seja menor do que 10% a 25%, dependendo do perfil de risco do projeto, do
oramento do projeto utilizando as estimativas mdias.
Pgina 130 de 190
13 Aquisio e Terceirizao
13.1 Plano de Gerenciamento de Aquisio e Terceirizao
O Plano de Gerenciamento de Aquisio e Terceirizao se preocupa com o processo de
obter bens e servios de fornecedores fora da organizao patrocinadora, de modo a atingir
os objetivos do projeto. Freqentemente, se convenciona em chamar os bens e servios
simplesmente de produtos adquiridos.
O Plano determina:
! Que tipos de contratos sero utilizados;
! Como ser o processo de aquisio dos produtos;
! Como o projeto ir interagir com o departamento de compras da organizao;
! Como os fornecedores sero escolhidos e gerenciados;
Normalmente, a organizao j possui estas regras e cabe ao gerente de projeto apenas
conhec-las e segui-las. No entanto, na ausncia de regras prvias, o gerente de projeto
dever estabelecer seu prprio procedimento.
13.2 Processo de Aquisio e Terceirizao

13.2.1 Planejamento de Aquisio
O gerente do projeto precisa identificar as necessidades do projeto que sero mais bem
atendidas pelo uso de terceiros. Preferencialmente, esta tarefa deve ser feita durante o
processo de planejamento em paralelo com a definio do escopo do projeto.
Em primeiro lugar, pode ser feita uma anlise Make-Or-Buy, ou seja, para cada item do
escopo, e at para o projeto inteiro, a empresa deve analisar os custos e benefcios de realizar
a tarefa com recursos internos a organizao ou adquirir estes recursos externamente. Uma
infinidade de detalhes associados ao custo de risco, custo de oportunidade, decises
estratgicas, poltica da empresa, disponibilidade de recursos, conhecimento tcnico,
experincia, etc., devem entrar nesta anlise. Sempre que a deciso contrarie a prtica
corrente na organizao os motivos devem ficar bem documentados. Depois deve ser
selecionado o tipo de contrato a ser utilizado na aquisio. Alguns dos tipos mais comuns so:
! Contratos a Preo Fixo O preo fechado baseado no escopo acordado. O risco
corre por conta do fornecedor e ele normalmente deve embutir este risco no valor do
contrato.
Existem algumas variaes. Alguns contratos determinam o escopo de maneira muito
vaga e deixam o risco totalmente por conta do fornecedor. Mais freqentemente, o
preo fixo desde que o escopo, bem definido, se mantenha constante. Neste caso, o
contrato deve estabelecer como ser feita a correo dos valores envolvidos na
mudana do escopo.
Alguns contratos prevem um bnus e/ou um nus pr-determinados caso a
performance do fornecedor fique acima ou abaixo do previsto. Tambm pode ser
prevista uma clausula que proteja o fornecedor contra problemas ocorridos por fatores
fora do seu controle ou por culpa do comprador.
Pgina 131 de 190
! Contratos por Preo Unitrio O preo fechado em um valor fixo por unidade. Mais
comumente negocia-se um valor por hora trabalhada. Neste caso, o risco corre por
conta do comprador e, na verdade, o vendedor tem interesse em que problemas
ocorram e o projeto se prolongue. Apesar disso, este tipo de projeto pode ser usado
quando o comprador tiver total controle sobre o trabalho do fornecedor. Certos casos
de terceirizao de profissionais em que a equipe externa se integra equipe interna,
enquanto o controle do projeto permanece com a organizao compradora cai neste
tipo de caso.
Em outros casos existe uma determinada mtrica de tamanho do escopo e o valor
estabelecido por unidade desta mtrica. o caso de se estabelecer um valor por metro
quadrado de uma construo. Neste caso, desde que a unidade de medida seja
calculvel sem ambigidades, o risco compartilhado pelas duas partes. Aumentos de
escopo sero acusados pela mtrica e cobrados ao comprador. Problemas na
execuo ficaro por conta do fornecedor.
! Contratos de Custo Reembolsvel Este tipo de contrato raro no Brasil. O
fornecedor no tem praticamente nenhum risco. Os fornecedores recebem os custos
envolvidos na tarefa mais um adicional que represente seu lucro. Este adicional pode
ser fixo ou pode ser calculado de acordo com a performance de gerenciamento dos
custos. Desta forma, o fornecedor ter algum incentivo para reduzir os custos totais do
projeto.
Uma frmula clssica para o calculo do adicional :
Adicional = AdicionalAlvo ( (CustoReal CustoAlvo) * Constante))
A redao especfica do contrato deve ser alvo de bastante cuidado e o formato escolhido
deve ser aquele que mais se adequar aos objetivos do projeto. O uso de uma forma padro
para todos os casos normalmente gerar contratos inadequados.
13.2.2 Solicitao
A solicitao o processo de obter propostas ou oramentos de fornecedores potenciais para
as necessidades do projeto. um processo em duas etapas.
Na fase de planejamento, so construdos documentos que informam aos fornecedores sobre
as necessidades do projeto, as condies em que essas necessidades devero ser satisfeitas
e os requisitos mnimos para que o fornecedor se habilite a apresentar uma proposta.
Dependendo do tipo de empresa, esses documentos so chamados de RFPs (Request for
Proposal ou solicitao de propostas), Licitao, Pedido de Oramento etc. Usaremos o
nome RFP como termo genrico.
Um dos itens de um RFP a chamada especificao de trabalho/produto ou SOW (Statement
of Work) que descreve o item a ser adquirido em detalhe suficiente para permitir que o
candidato avalie sua capacidade em fornecer. Esse detalhe suficiente pode variar,
dependendo da natureza do item, necessidades especficas do comprador ou tipo de contrato.
Os RFPs devem ser cuidadosamente preparados de forma a propiciar uma resposta correta e
acurada por parte dos fornecedores. Eles devem incluir, alm da especificao do produto,
qualquer informao relevante para o fornecimento.
A emisso do RFP compe a solicitao propriamente dita. Os critrios de seleo do
fornecedor devem ser tornados explcitos para os candidatos como parte do RFP. Nos
contratos mais simples e em muitas licitaes para o governo, o nico critrio o menor
preo. Os fornecedores devem cumprir com determinadas exigncias mnimas mas, uma vez
habilitados, aquele que oferecer o preo mais atraente ser o vencedor. Este tipo de seleo
s deve ser utilizado nos casos em que o produto fornecido um commodity e no h muita
diferena de qualidade entre fornecedores.
Pgina 132 de 190
Para produtos e servios mais sofisticados recomendam-se critrios mais amplos. Alguns dos
critrios mais comuns so:
! Compreenso do Servio Os fornecedores devem demonstrar, por suas propostas,
que compreenderam o que foi solicitado a eles. Esse um critrio absolutamente
indispensvel.
! Custo do Fornecimento Tanto o custo do item fornecido como tambm custos
derivados, como taxas de entrega ou contratos de manuteno, devem ser levados em
conta.
! Capacidade Tcnica O fornecedor deve demonstrar que possui capacidade e
competncia tcnica para atender ao projeto ou que razovel se esperar que ele
obtenha esta capacitao antes do fornecimento. Certificaes pblicas e atestados de
capacidade tcnica, fornecidos por ex-clientes, so utilizados nesse critrio. comum
que esses documentos sejam forjados e o contratante deve estar preparado para
auditar as declaraes do fornecedor.
! Proposta O modo de fornecimento proposto pelo fornecedor deve ser factvel e
adequado s necessidades do contratante. Propostas pouco usuais no so
necessariamente ruins mas merecem uma anlise mais profunda.
! Capacidade Financeira O porte e a sade financeira do fornecedor devem ser
adequadas ao tamanho e complexidade do produto fornecido. Pequenos fornecedores
so levados beira da falncia por tentarem abocanhar mais do que podem. No h
aqui um conselho para se ater a grandes fornecedores. Isso nem sempre uma boa
poltica. Porm, procurem analisar se o porte do fornecedor compatvel com as
necessidades do projeto.
Recomenda-se, normalmente, que, sempre que possvel, defina-se critrios objetivos de
escolha, em vez de subjetivos. No entanto, critrios subjetivos podem ser utilizados de forma
complementar. Por exemplo, sondagens informais no mercado sobre a fama de um fornecedor
podem evitar que se feche um contrato com notrios incompetentes que tenham uma bela
apresentao.
comum que os critrios objetivos sejam transformados em uma graduao e consolidados
por uma frmula ponderada. Toda a bela proposta do fornecedor assim transformada em um
nico nmero e o avaliador precisa apenas de uma mquina de calcular para dar seu
veredicto. A maioria dos fornecedores se torna especialista em manipular suas propostas de
modo a obter maior pontuao. Um dos problemas destas frmulas que elas sempre omitem
critrios importantes. A criao dos critrios de graduao e dos fatores de multiplicao
sempre esconde decises mais ou menos arbitrrias, embora o modelo final seja um exemplo
aparente de racionalidade. oportuno lembrar aqui nosso aviso: modelos no devem tomar
decises no lugar de pessoas.
comum a prtica de marcar reunies com os candidatos de forma a esclarecer dvidas.
Essas reunies tambm so uma boa oportunidade para que o contratante conhea o
candidato a fornecedor. Elas devem ser feitas, preferencialmente, antes da apresentao das
propostas.
A emisso dos RFPs pode ser pblica para qualquer fornecedor que se habilite ou pode
depender de convite especfico. Quando h convites especficos na verdade j se realiza uma
pr-seleo dos fornecedores que podem participar do processo. Quando se utiliza apenas de
critrios objetivos, o que o caso de muitas licitaes governamentais, a pr-seleo protege
a organizao de fornecedores indesejveis. Quando a empresa tem liberdade de descartar
fornecedores por critrios discricionrios, mesmo que eles apresentem o que seria,
teoricamente, a melhor proposta objetiva, a necessidade de pr-seleo, nesse ponto de vista,
menor.
Pgina 133 de 190
13.2.3 Seleo de Fornecedores
Uma vez que as propostas foram apresentadas, descartam-se os candidatos que no
atingiram os requisitos mnimos e passa-se fase de seleo. Nos processos de licitao
pblica em que o vencedor e sua proposta so definidos pelos critrios acordados, o processo
se encerra por a.
No entanto, as organizaes privadas no esto obrigadas a aceitar as proposta como elas
so apresentadas. freqente que dois ou mais candidatos apresentem boas propostas, mas
que existam pontos positivos e negativos importantes para cada escolha. A proposta ideal
conteria, nesse caso, elementos de vrias propostas. Ou pode acontecer que o menor preo
oferecido simplesmente seja maior que o oramento para o produto.
Para estes casos, aberto o processo de negociao. Nessa situao, o contratante pode
expor informaes sobre o que est errado na proposta e quais as sugestes que, se
incorporadas, podem garantir a vitria ao fornecedor. considerado antitico abrir as
propostas dos adversrios uns para os outros, no entanto, itens especficos podem ser
colocados. A negociao no deveria incluir somente o preo do fornecimento, embora este
seja o item mais comumente discutido.
Aps as negociaes, novas propostas formais, com as alteraes combinadas, devem ser
emitidas. Aps a escolha final, um contrato deve ser assinado nos termos da proposta.
13.2.4 Administrao de Contrato

Embora a terceirizao transfira a execuo de uma atividade para o fornecedor, ela no
transmite inteiramente a responsabilidade pela execuo. O gerenciamento da atividade deve
ser integrado ao gerenciamento do projeto como um todo. Quase todas as tcnicas e
processos definidos no nvel de projeto valem para a parte terceirizada, incluindo
planejamento, execuo, comunicao e controle.
O gerente de projeto deve supervisionar o trabalho produzido pelo fornecedor de modo a
garantir que as praticas acordadas estejam sendo cumpridas. O fornecedor deve informar
sobre qualquer mudana que afete os termos do contrato e prover relatrios de andamento de
suas atividades.
Os pagamentos emitidos para o fornecedor devem estar vinculados ao cumprimento de suas
obrigaes e a assinatura do gerente de projeto deve estar na lista de aprovaes necessrias
para a efetivao do pagamento.
13.3 Falhas comuns no Processo de Terceirizao

A terceirizao de projetos tem um histrico muito irregular de sucessos e fracassos. Na
maioria dos casos, a culpa do fracasso pode ser rastreada at aes do contratante.
No processo de seleo, a ateno desproporcional ao preo uma fonte de problemas.
Freqentemente o menor preo significa menor qualidade, mas isto apenas parte do
problema. Nem sempre a proposta mais barata corresponder ao menor custo total. bem
conhecida a prtica de empresas que colocam preos baixos durante o processo de seleo e
aumentam os custos depois. No momento da seleo existe forte concorrncia e o poder est
com o contratante. No entanto, no decorrer do projeto, os custos para a troca de fornecedor
passam a se tornar astronmicos. Nessa circunstncia, os fornecedores passam a ter mais
poder de negociao. Quando as inevitveis mudanas de escopo ocorrem ou falhas na
definio de servio no contrato so descobertas, o fornecedor pode pedir preos premium
por seus servios. Pensando ser o explorador que jogou um fornecedor contra o outro at
atingir um preo mnimo, o contratante se v na situao de explorado.
Pgina 134 de 190
Muitos contratantes raciocinam que esse processo inevitvel e que o preo final
proporcional ao inicial. Quanto mais desconto eles conseguem na proposta tanto menor ser o
custo final. Na maioria dos casos, isso no verdade.
Existem maneiras de definir contratos nos quais o fornecedor tenha interesses compatveis
com os do contratante. Propostas nesses termos tm, quase sempre, um preo inicial maior
do que as normais, no entanto o preo final invariavelmente menor.
Pode-se, por exemplo, definir o contrato por uma mtrica objetiva do tamanho do escopo e
oferecer prmios e penalidades para o no cumprimento do contrato.
Muitas vezes, as penalidades constam em contrato, mas no so usadas pelo contratante.
Isso um grande erro. A hbito de no aplicar as multas nulifica o seu efeito inibidor. Se um
fornecedor sub-dimensiona uma proposta e acaba tendo prejuzo por causa disso, ele tem
menos probabilidade de repetir a m prtica em futuras proposta. Dadas garantias legtimas,
bons fornecedores tero interesse de se comprometer com clusulas de punio porque isso
acabar por aumentar o nvel geral de preos das propostas. Ao mesmo tempo, o contratante
ter mais garantias de que o custo final estar dentro do oramento designado.
13.4 Desenvolvimento de Fornecedores

Algumas vezes, compramos produtos e servios que so nicos e temos baixa probabilidade
de contrat-los novamente. No entanto, na maioria dos casos, temos que comprar os mesmos
tipos de produtos e servios repetidas vezes. Se encararmos cada compra como sendo nica,
estaremos perdendo uma oportunidade valiosa de melhorarmos nossos processos.
O desenvolvimento de fornecedores se preocupa em estabelecer uma parceria com um
nmero limitado de empresas que passam a oferecer servios personalizados a nossas
necessidades. De uma forma geral, existem dois benficos bsicos no estabelecimento
dessas parcerias:
! Passamos a lidar com fornecedores que conhecemos. Sabemos os limites de sua
capacidade e confiabilidade. Temos mais confiana que eles no arriscaro um
relacionamento de longo prazo violando segredos da empresa ou fornecendo um
produto com problemas.
! O fornecedor passa a nos conhecer melhor. Ele pode reagir a sutilezas em nossas
necessidades. Ele conhece nossos padres e procedimentos e no tem dificuldades
para segui-los.
O relacionamento benfico para ambos. Com um volume maior de negcios o fornecedor
pode ter economias de escala e repass-las para o comprador. Por outro lado, ele no
precisar entrar em guerras de preos com outros fornecedores de qualidade desconhecida.
A parceria no se limita ao mero fornecimento e pode incluir a troca de conhecimento e
esforos conjuntos de aprimoramento. Turmas de treinamento com membros de ambas
empresas so um meio interessante de integrao. Alm disso, sugestes de cada parte
podem levar a evoluo dos processos da outra.
Normalmente, se recomenda que o nmero de fornecedores para cada tipo de produto ou
servio seja reduzido, mas no nico. Se tivermos dois fornecedores sempre teremos duas
propostas para comparar. A experincia demonstra que a qualidade de servio em
fornecedores monopolistas cai com o tempo. comum que o preo acabe aumentando
tambm. Isolado do mercado, o cliente pode nem perceber o que est acontecendo.
Pgina 135 de 190
14 Qualidade
14.1 Histrico
Antes da Revoluo Industrial, cada arteso era responsvel por seu produto. Os produtos
manufaturados eram, de forma geral, caros e os clientes analisavam suas encomendadas e
discutiam os problemas antes do pagamento. A reputao do arteso e, conseqentemente,
sua clientela futura, dependiam de atender s necessidades dos clientes. notvel como esse
sistema produziu manufaturados que eram verdadeiras obras de arte.
Com o progresso e a produo em massa, os produtos se tornaram acessveis a um nmero
muito maior de pessoas. Nesta poca, as pessoas estavam to maravilhadas com a
possibilidade de finalmente possuir os bens, que no se incomodavam muito em julgar a
qualidade do que compravam. Esta era durou pouco.
Durante a Segunda Guerra, j havia a preocupao de que os produtos funcionassem como
prometido. Imagine que voc est em um campo de batalha e percebe que suas granadas no
explodem. Ou que voc o responsvel por um paiol e percebe que algumas granadas tm a
tendncia de explodir quando no deveriam. As inspees de qualidade no final da linha de
produo j eram regra nessa poca, mas isso no parecia ser suficiente.
Algumas estatsticas demonstram que, se voc inspecionar 100% de sua produo, sero
encontrados apenas 80% dos defeitos. O custo deste tipo de inspeo alto, assim como o
custo de corrigir os problemas encontrados. Ainda assim, uma parte significativa dos seus
produtos ainda chegar ao mercado com problemas.
Na dcada de 50, um Japo arrasado produzia produtos especialmente baratos e de baixa
qualidade. O socorro veio das mos de um americano. W. Edwards Deming realizou uma
srie de visitas aos japoneses, realizando seminrios para divulgao de suas idias e
causando uma impresso profunda.
Suas idias eram de uma simplicidade Zen: em vez de tentar melhorar as inspees de
qualidade, o que era custoso e ineficiente, porque no entender o porqu dos defeitos
aparecerem. Compreendendo e aprimorando o sistema podemos criar bons produtos, com
menos desperdcio e logo na primeira tentativa. O resto, como dizem, histria !
Em 1980, a NBC transmitiu um documentrio chamado If Japan Can, Why Cant We ?. O
ponto alto deste programa foi uma entrevista com o Dr. Deming. Aps dcadas orientando os
japoneses, ele foi, pela primeira vez, realmente ouvido no Ocidente.
Aps isso reinou o caos. Uma infinita srie de metodologias ou filosofias a respeito da
Qualidade gerou a felicidade das empresas de consultoria por todo o mundo. Mas os
resultados foram muito variveis. Existiram casos at tragicmicos. O mais famoso prmio
baseado na filosofia de qualidade total, como os americanos a entendem, o Malcolm
Baldridge, do qual o nosso PNQ uma cpia. O processo de premiao extremamente
rigoroso e a empresa agraciada no ano colocada como um exemplo a ser seguido. Porm
os resultados prticos no se apresentaram. Um ano aps o recebimento do prmio, uma
empresa chamada Wallace Company Inc entrou em concordata. Isso arranhou um bocado a
validade da filosofia do Baldridge. No entanto, sempre existe a prxima moda para garantir o
mercado para consultores.
Qualidade importante! O sucesso absoluto dos japoneses nas dcadas de 1970 e 1980
prova isso. Mas preciso entender os princpios que podem levar a sucessos semelhantes.
Pgina 136 de 190
14.2 Definies
Qualidade genericamente definido como a totalidade dos aspectos e caractersticas de um
produto ou servio em relao a sua habilidade de satisfazer necessidades declaradas ou
implcitas. De uma maneira mais simples, ter qualidade agradar ao cliente.
Normalmente, reconhecido que a qualidade tem mltiplos aspectos. Discutiremos trs
destes aspectos: a qualidade do projeto, a qualidade de conformidade e a qualidade como
valor agregado.
A qualidade de projeto o que faz um Pentium ser superior a um 286 ou que faz um produto
Luxo ser superior a um Popular. Diferenas em relao ao tamanho, ao desempenho,
quantidade de recursos, aparncia etc, so devido a projetos diferentes. crena geral que
melhorias na qualidade do projeto geram custos maiores. No entanto, nem sempre isso
verdade, pelo menos no a longo prazo. Qualquer computador de mesa melhor e mais
barato do que um velho ENIAC vlvula.
A qualidade de conformidade o quanto um produto especfico atende s especificaes de
um projeto. Imagine se voc comprasse uma Ferrari e a maaneta da porta sasse na sua
mo. No importa o quanto um projeto seja bom. Se os produtos efetivamente produzidos no
seguirem de perto suas especificaes, a qualidade ser afetada.
Todo fabricante tem a inteno de fabricar seus produtos conforme prometido, mas isso no
to simples quanto parece. Nossa conhecida variao no atinge apenas os Gerentes de
Projetos. Ela se apresenta em inmeras formas que vo desde as caractersticas da matriaprima at diferenas nos processos de fabricao. Duas canetas ou duas Ferraris jamais
sero exatamente iguais. O truque fazer com que elas sejam equivalentes, pelo menos,
naquilo que importante para o consumidor. A variao no pode ser evitada mas,
freqentemente, ela pode ser conhecida e controlada.
Ao contrrio da Qualidade do Projeto, aumentos na Qualidade de Conformidade tendem a
diminurem os custos. Menos desperdcio, processos mais eficientes e menos retrabalho so
resultados possveis e a reduo dos custos pode ser muito significativa.
A qualidade como valor um conceito vindo de Marketing. Imagine que voc pudesse
transformar todas as caractersticas positivas do produto em um nmero. O cheiro do carro
novo, seu desempenho, a quantidade de paqueras que voc receberia dentro dele, tudo isto
convertido em um numero B. Imagine que voc fizesse a mesma coisa com as
caractersticas negativas. O preo do carro, o custo em combustvel, o prazo de entrega, o
medo de ser seqestrado, tudo transformado em um nmero C. O valor do produto seria
dado pela razo B/C. Se os benefcios superarem os custos a venda feita, caso contrrio o
consumidor procurar outra coisa para comprar.
Quando tornamos um produto mais barato ou reduzimos o prazo de entrega, provavelmente
estaremos trabalhando para melhorar este aspecto da qualidade.
O valor , talvez, o objetivo final de qualquer iniciativa de Qualidade. Podemos fazer um
produto simples, ou seja, de baixa qualidade de projeto, se ele for muito mais barato do que a
concorrncia. Lembre-se de que houve uma poca em que mesmo a qualidade de
conformidade era de importncia secundria para o consumidor. Hoje, vemos produtos de
origem chinesa que so extremamente baratos e vendem bastante, apesar de ter baixa
conformidade.
De uma maneira geral, no entanto, os mercados amadurecidos esperam um produto de alto
valor e que tenha boa qualidade de conformidade. A qualidade de projeto exigida depender
do nicho alvo do produto.
Pgina 137 de 190
14.3 Deming & Juran
Nas palavras de Kauoru Ishikawa, o Dr. W. Edwards Deming foi quem apresentou o controle
de qualidade ao Japo. Ele tambm um bom amigo do Japo, que conhece o Japo. Esta
amizade comeou com um seminrio em 1950. Naqueles dias, Ishikawa nos conta que os
diretores ordenavam a seus subordinados para fazer o melhor que pudessem ou que
trabalhassem mais (...) apelando para o chamado esprito japons.
A mensagem de Deming era simples mas poderosa: Todos fazerem o seu melhor no a
resposta. necessrio que as pessoas saibam o que fazer. Mudanas drsticas so
requeridas. A responsabilidade pela mudana est com a gerncia. O primeiro passo
aprender como mudar.
Para Deming, os gerentes deveriam colocar de lado suas preocupaes com o hoje para que
pudessem ter a certeza de que haveria um amanh. Eles deveriam se comprometer com a
melhoria contnua de produtos e servios de modo a atender s necessidades dos clientes.
Ele advogava que as linhas verticais entre departamentos e as horizontais entre supervisores
e trabalhadores deveriam ser quebradas. A viso de sistema deveria substituir a viso de
postos de trabalho especializado, com responsabilidades limitadas e bem definidas.
A ferramenta chave que ele sugeria para entender o sistema, separando as causas comuns e
especiais de variao, era o Controle Estatstico de Processos. As regras da probabilidade
poderiam determinar quando uma variao tinha um comportamento aleatrio, significando
que tinha causas inerentes ao sistema, ou se existia variaes devido a causas especiais.
Para isto, algumas variveis, chamadas de caractersticos da qualidade, deveriam ser
coletadas pelos prprios operadores e plotadas em um grfico especial. Estes caractersticos
de qualidade eram representaes mensurveis dos requisitos dos clientes. A cada perodo
de tempo, ou nmero de peas produzidas, o trabalhador deveria coletar uma amostragem do
seu prprio trabalho, medir o caracterstico e plotar um grfico de controle como o abaixo:
210
208
206
204
202
200
198
196
1
9 10 11 12 13 14 15 16 17 18 19 20
No grfico estavam previamente plotadas trs linhas: a linha mdia, a linha de limite superior
de controle e a linha de limite inferior de controle. A linha mdia continha, simplesmente, a
mdia histrica daquela operao. Os limites de controle eram calculados somando-se ou
diminuindo-se o equivalente a 3 desvios padres ao valor da media. Estes valores eram
calculados por especialistas, mas o trabalhador deveria ser capaz de entender o grfico.
Sempre que uma medio ficasse entre os limites de controle e no houvesse nenhuma
indicao de tendncia, por exemplo, seis pontos consecutivos do mesmo lado da linha de
mdia, significava que o processo estava sob controle. As variaes eram normais e ele
estava fazendo um bom trabalho. Mas se um dos pontos escapasse ao limite de controle,
como no caso do ponto 10 de nosso grfico, ele poderia parar imediatamente a operao,
Pgina 138 de 190
descobrir a causa da variao e corrigir o problema ou pedir ajuda. Essa reao imediata faz
com que o problema seja encontrado mais facilmente, porque o operador pode se perguntar: o
que esta diferente do normal. O que fiz de diferente ? O que aconteceu quando estava
operando aquela pea ? Lembro de ter trocado o lote de matria prima ? Ouvi um barulho
estranho ?
Ele se torna um orgulhoso responsvel pela qualidade de seu trabalho. Ningum vai avali-lo
por uma meta fixa de valor. Ningum vai apontar ameaadoramente para ele quando surgir o
primeiro problema. A culpa sempre do sistema at que se prove o contrrio.
Entretanto, esta remoo de causas especiais, sob responsabilidade do trabalhador, no
suficiente para a qualidade. O sistema permanecer estvel, mas ele pode no ser um bom
sistema.
Digamos que as especificaes do cliente indiquem que as peas tenham 205mm de dimetro
com uma tolerncia de mais ou menos 1mm, ou seja de 204mm at 206mm. Podemos ver
que a mdia do grfico est em torno de 204,2mm. Espera-se que ele produza peas variando
de 200,3mm at 208mm. Claramente, contamos com a sorte para atingir as especificaes do
cliente. Ns falhamos em consegui-lo em 7 das 20 amostragens do grfico.
Nosso sistema precisa de aprimoramento. Deming afirmava que, para mover a mdia para
cima ou para baixo e assim mover os limites de controle na mesma direo e distncia, era
necessrio que a gerncia promovesse um esforo integrado de vrias reas da empresa.
No adianta simplesmente apontar o dedo para o operador. Ele, provavelmente, j fez o que
podia.
Se, alm disso, a empresa desejar atuar sobre a faixa de variao, tornando-a mais estreita e
assim, tornando o processo mais confivel, o esforo ainda maior. Os benefcios potenciais
tambm sero maiores. O grfico abaixo mostra um sistema em que a mdia de 205mm, a
mesma desejada pelo cliente. A variao mxima est entre 203,4mm e 206,6mm. Nas vinte
amostragens, todas as peas seriam aprovadas pelo cliente.
207
206
205
204
203
202
201
1
9 10 11 12 13 14 15 16 17 18 19 20
Deming no foi o nico americano a contribuir para o milagre japons. A influencia de

Joseph Juran foi quase to grande. Sua participao foi importante por duas noes que criou
e que foram fundamentais para os japoneses.
A primeira a do custo da qualidade. Juran percebeu que os altos gerentes jamais dariam
ateno a coisas como taxas de defeitos ou limites de controle. Ele decidiu traduzir a
qualidade para a linguagem que eles conseguiam entender: dinheiro. Ele ensinava que os
custos da qualidade podiam ser classificados em quatro tipos:
! Custos de Falhas Internas so decorrentes de defeitos descobertos antes que o
produto fosse enviado para o cliente. O retrabalho e o expurgo de peas so
exemplos.
Pgina 139 de 190
! Custos de Falhas Externas so decorrentes de defeitos descobertos aps o
embarque para o cliente. O reenvio de mercadorias e a perda de mercado so
exemplos desse tipo de custo.
! Custos de Avaliao so associados ao teste e ao controle de matrias-primas e
produtos. Os gastos com laboratrios de qualidade, por exemplo, poderiam evitar que
falhas internas se transformassem em falhas externas.
! Custos de Preveno so associados com a preveno de falhas. A compra de
matrias primas de fornecedores mais confiveis ou os gastos com consultores
formados pelo Juran Institute esto nesse tipo.
Colocar dinheiro em preveno e avaliao no era, de maneira alguma, jogar dinheiro fora.
Eram investimentos que seriam compensados por redues nos custos de falhas.
Juran argumentava que deveria existir um objetivo claro para a qualidade. Investimentos em
Avaliao e Preveno seriam financeiramente benficos enquanto a taxa de defeitos fosse
relativamente grande. Os custos da qualidade (CDQ) atingiriam um mnimo quando os
investimentos em qualidade igualassem os custos com falhas. A empresa deveria lutar para
atingir este Eldorado chamado custo mnimo de qualidade e ento s precisaria se manter
nesta posio.
Custo por
Unidade
Vendida
Custos de Falhas
Internas e Externas
Custos
Totais de
Qualidade
Mnimo CDQ
Custos de Avaliao
e Preveno
zero defeitos
100 % de defeitos
Esse tipo de raciocnio soou como msica para os investidores e o Japo colheu os frutos
deste entusiasmo. Juran, porm, estava baseado em premissas no muito slidas. O
equilbrio muito mais instvel do que seus grficos demonstram e boa parte das variveis
envolvidas intangvel e de difcil quantificao, como por exemplo, a imagem da empresa
para o consumidor.
O custo da qualidade uma ferramenta muito til para a venda de programas de qualidade,
mas no deve ser encarado como um modelo absolutamente correto. Pelo menos no sentido
de que os custos de qualidade so quantificveis precisamente e plotveis em um grfico
O outro conceito importante divulgado por Juran foi o Princpio de Pareto. Ele recomendava
que, pelo menos nos estgios iniciais de um programa de qualidade, a empresa se
concentrasse em projetos que ele chamava de the vital few, ou seja aqueles que poderiam
gerar mais impacto na qualidade usando o menor esforo possvel.
Vilfredo Pareto foi um economista italiano que percebeu que 80% de toda riqueza da Itlia
estava concentrada em 20% da populao. Juran percebeu esta imagem como uma analogia
ao problema da qualidade. Ele argumentava que 80% dos defeitos pareciam ser causados por
Pgina 140 de 190
apenas 20% dos elementos envolvidos no sistema. Tratava-se assim de encontrar aquelas
poucas vitais entre todas as aes potencialmente teis.
O sucesso do Principio de Pareto foi to grande que Juran se arrependeu de no t-lo
chamado Principio de Juran. De fato, qualquer ao administrativa, e no somente os
programas de qualidade, pode ser aprimorada se os responsveis puderem focar nas
restries do sistema, ou seja, naquilo que realmente impede a performance de melhorar, em
vez de tentar mover o sistema inteiro de uma s vez.
Juran e Deming, principalmente este ltimo, estabeleceram a direo geral que os esforos de
qualidade deveriam seguir. Isso no significa que todos seguiram nesta direo. Uma enorme
quantidade de iniciativas ignoraram ou foram frontalmente contrrios aos princpios destes
mestres.
14.4 ISO-9000
Para compreender as idias que suportam a ISO-9000 temos que retornar ao sculo XIX e
compreender a Teoria da Burocracia de Max Weber. Weber estava impregnado com o
racionalismo positivista da poca. Esperava-se utilizar os mtodos cientficos para obter a
soluo perfeita e a previsibilidade absoluta dos fenmenos.
O processo de racionalizao a aplicao prtica de conhecimento de modo a atingir um
determinado fim. O planejador deve levar em conta todos os fatores e utilizar seu
conhecimento superior para projetar a maneira tima de execuo. O planejador e o executor
no so necessariamente a mesma pessoa e, para Weber, eles no deveriam s-lo. Mesmo
que se trate de um mesmo indivduo ou grupo, os dois processos so separados. Enquanto se
planeja no se executa e s se executa aps o planejamento.
Weber descreveu o sistema em que a racionalizao poderia ocorrer e chamou-o de
Burocracia. Suas idias sobre a Burocracia incluam:
! Regras Escritas de Conduta A Burocracia previa regras exaustivas capazes de cobrir
todas as reas da organizao, prever todas as ocorrncias e enquadr-las dentro de
um esquema racional pr-definido. As regras criadas tm um poder legal porque so
mandatrias e freqentemente prevem mecanismos de coao para os rebeldes.
! Carter Formal da Comunicao Visando evitar erros nas comunicaes, elas
deveriam ser escritas e padronizadas pelo tipo de informao. As comunicaes
deveriam ser armazenadas de modo a proporcionar comprovao, ou evidncia, de
que o processo formal foi seguido.
! Diviso especializada de trabalho Em toda burocracia os trabalhadores deveriam ter
funes bem definidas. Cada membro da organizao passaria a ter funes
especficas em sua esfera de competncia restrita. Tudo bem definido pelos
procedimentos racionais.
! Promoo baseada na eficincia Os critrios de promoo de um funcionrio
deveriam ser objetivos e ligados s tarefas especficas de seu cargo. Uma vez que o
sistema se encarregava de garantir que os objetivos da organizao fossem atingidos,
bastaria mensurar e controlar o quo bem cada membro executa as funes sob sua
responsabilidade.
A variabilidade introduzida pelo elemento humano sempre vista pela Burocracia como
danosa. A Burocracia deveria promover um nvel de previsibilidade equivalente aos aparelhos
mecnicos. Como conseqncia, ela deveria ser um modelo perfeito de eficincia, porque a
execuo era feita rigorosamente dentro dos princpios racionais superiores que moldaram as
normas e procedimentos.
O sucesso que os princpios burocrticos atingiram foi impressionante, principalmente dentro
da administrao estatal. No entanto, logo as falhas das premissas racionalistas se tornaram
Pgina 141 de 190
evidentes. Vrios autores, j no meio do sculo XX, identificaram disfunes que ocorriam
com freqncia alarmante nas organizaes burocrticas. Algumas destas disfunes so:
! Internalizao das regras e apego exagerado aos regulamentos Os objetivos que
levaram a criao das normas comearam a ser esquecidos no dia a dia, at que o
cumprimento das normas deixou de ser apenas um meio para se tornar o prprio
objetivo dos funcionrios. O funcionrio deixa de ser um especialista nas tarefas e
passa a ser um especialista nas normas e regulamentos. Isso j foi chamado de
incapacidade treinada.
! Excesso de Formalismo Os registros escritos se tornaram cada vez mais numerosos
e detalhados. Como os processos devem resolver qualquer eventualidade, mesmo as
informaes com pouca possibilidade de serem necessrias tinham que ser
registradas e confirmadas por um documento. Nenhum funcionrio ousa executar uma
tarefa se o pedido adequado no foi propriamente enviado por meio do canal definido,
no importando o tamanho ou urgncia da tarefa.
! Resistncia a Mudanas O funcionrio eventualmente se acostuma com a completa
estabilidade e repetio de suas tarefas. Qualquer possibilidade de mudana no
procedimento tende a ser interpretada como um elemento desconhecido que ameaa a
segurana e a tranqilidade. Na medida do possvel, o funcionrio passa a resistir
mudana de maneira mais ou menos ativa.
! Categorizao como base de Deciso Como existe um nmero limitado de
processos formalizados e um nmero ilimitado de situaes, o burocrata tende a
classific-las de maneira estereotipada de forma a ser capaz de lidar com elas,
encaixando-as em um dos tipos previstos pela documentao. Quanto mais freqente
se torna esta categorizao, menor ser a procura de alternativas para soluo de
problemas. Isto lembra um velho ditado: quando a vida s lhe deu um martelo, todos
os seus problemas passam a se parecer com pregos.
! Dificuldade de atender a Clientes e conflitos com o Pblico A mais famosa das
disfunes da burocracia , na verdade, derivada de todas as outras. A burocracia visa
estabilidade e no adaptabilidade. Uma vez que os funcionrios esto voltados
para suas normas, e so avaliados pelo seu cumprimento, todos os clientes so
atendidos de forma padronizada, segundo categorias fixas. Se algum cliente tem um
problema que exige uma soluo personalizada, o burocrata entra em pnico. O
argumento mais comum o de que, se ele tivesse que lidar com toda exceo que
aparece ele no poderia realizar seu trabalho.
Acrescentamos uma disfuno, que uma das mais prejudiciais, e que s pode ser entendia a
luz da teoria dos sistemas. As burocracias geram uma mentalidade de otimizao local. Cada
funcionrio passa a se ver como um operrio de uma linha de montagem, com
responsabilidades limitadas. A otimizao das performances individuais de cada
departamento, que est embutida na prpria estrutura da Burocracia, praticamente garante
que o sistema como um todo ser subotimizado. Isso particularmente verdadeiro para
projetos, em que o trabalho em equipe fundamental para resoluo de problemas.
Todas estas disfunes da Burocracia se tornaram famosas a ponto de ela, de maneira no
totalmente justa, virar sinnimo de ineficincia. irnico que este estigma tenha se imposto a
um nome que deveria representar a prpria eficincia racionalista na administrao. O nome
Burocracia jamais poder ser usado novamente de maneira positiva, mas sempre existe uma
maneira de requentar velhas idias com novos rtulos. E assim chegamos finalmente ao
assunto original, o modelo de gesto ISO-9000.
Os governos sempre foram entusiastas dos princpios burocratas. Na ausncia das foras
competitivas do mercado, o estado tem sempre a preocupao de agir de maneira racional, de
modo a maximizar a utilizao de seus recursos. Durante os anos 70, as atividades do British
Pgina 142 de 190
Standards Institute (BSI) espelhavam a preocupao do governo britnico em garantir a
confiabilidade de seus fornecedores. Em 1979 o BSI publicou um padro chamado de BS
5750 e conseguiu que diversas empresas da Inglaterra o adotassem.
As idias bsicas do BS 5770 eram retiradas do iderio burocrata. A nfase era em produzir
de forma previsvel, e com pouca variao, os produtos que eram fornecidos para o governo.
No havia nenhuma referncia melhoria de performance, mas esta norma j tinha a maioria
das caractersticas importantes da ISO-9000, inclusive as auditorias internas.
O poder de fogo da BS 5770 era pequeno e o governo Ingls buscou a respeitabilidade que a
ISO podia oferecer. Em 1987, as idias da BS 5770 foram transferidas para a comunidade
internacional na forma da ISO-9000, apesar da sintomtica falta de suporte dos Japoneses.
Os padres ISO-9000 so burocrticos por natureza. Como mesmo uma rosa com outro nome
continua sendo uma rosa, eles sofrem de todas as disfunes associadas. No entanto, a ISO9000 uma forma um tanto evoluda de burocracia. Em relao burocracia original de
Weber, podemos destacar alguns pontos interessantes:
! Os padres e normas no deveriam ser impostos de cima para baixo, mas construdos
pelas prprias pessoas que os utilizariam. Isso evitaria que normas boas no papel, mas
inexeqveis na prtica, fossem impostas de cima para baixo.
! Durante a elaborao dos processos, o cliente deveria ser sempre o foco. Em tese, o
objetivo da eficincia da burocracia ISO-9000 deixa de ser a utilizao dos recursos do
produtor e passa a ser o atendimento confivel ao cliente. Embora este foco
freqentemente seja perdido, as necessidades do cliente no so totalmente
esquecidas como na Burocracia original.
! implcito nas normas que elas devem evoluir com o tempo. Pelo menos teoricamente
as normas deveriam ser alvo de um ciclo evolutivo nos moldes do PDCA. Isto deveria
diminuir a tendncia cristalizao dos procedimentos em leis eternas.
No entanto, estes novos aspectos no so capazes de impedir que as disfunes apaream.
Durante a elaborao das normas, as pessoas tm a tendncia de levantar velhos problemas
e ressentimentos e criam regras que acabam agindo para dificultar seu prprio trabalho. A
mentalidade determinista e racionalista est muito arraigada em nossa sociedade e nos
sentimos culpados quando nossos procedimentos no so capazes de cobrir a diversidade do
mundo real. Como conseqncia, processos idealizados acabam por serem auto-impostos.
O foco no cliente logo esquecido pelo prprio processo de certificao. Qualquer um que j
tenha participado de um processo desses j presenciou casos em que solicitaes dos
clientes foram simplesmente negadas porque a auditoria estava prxima. Preparar-se para ela
tem sempre a prioridade absoluta.
Uma vez elaboradas, as normas tm vida prpria. Os prprios criadores tero receio em
modific-las. Lembraro das discusses interminveis que precederam a aprovao de um
frgil consenso. O hbito de seguir o padro e a inrcia em efetivar mudanas far com que
somente aquelas normas que se tornarem insuportveis sero modificadas.
As disfunes inerentes a qualquer Burocracia inevitavelmente ocorrero, mas no devemos
nos juntar ao clamor das massas na condenao de qualquer tipo de Burocracia.
Em primeiro lugar, devemos entender que determinadas organizaes, ou pelo menos,
determinadas partes de organizaes podem se beneficiar muito do racionalismo burocrata.
Existem muitas atividades que so simples, no sentido de darem margem a poucas
alternativas, e so pouco influenciadas por mudanas no ambiente externo. Plantas em
indstrias de commodities so um bom exemplo disto. No se espera um grande dinamismo
gerencial na produo de enxofre, mas os clientes esperaro uma absoluta confiabilidade e
previsibilidade de seus fornecedores. A implantao da ISO-9000 pode oferecer esta
estabilidade.
Pgina 143 de 190
Por outro lado, atividades que exigem alto nvel de dinamismo e adaptabilidade, em que as
mudanas e variaes so inevitveis e nem sempre malficas, como o caso da
esmagadora maioria dos projetos, sero quase certamente prejudicadas pela existncia de
uma burocracia forte.
Em segundo lugar, ao contrrio do que muitos auditores ISO podem dar a entender, existe
todo um contnuo de padronizao burocrtica. No preciso escolher entre o completo caos
informal e o escreva exatamente como voc faz, faa rigorosamente como descreveu e
mantenha registros para prov-lo. A utilizao focada de procedimentos para atividades
repetitivas de baixa tolerncia a variao certamente uma grande arma administrativa.
Programas de qualidade, a exemplo do modelo 6 sigma, fazem uso deste tipo de
burocratizao focada.
Alm disso, atividades podem ter guias que induzam boas prticas sem que se tornem
procedimentos fixos. O prprio PMBOK um exemplo disso. O PMI promove uma certificao
para garantir que os gerentes de projeto conheam as prticas recomendadas. No entanto,
deixada para o gerente de projeto a deciso da aplicabilidade de cada tcnica a um projeto
individual. Este um bom sistema que poderia ser mais comum nas organizaes.
A ISO-9000 um modelo de gesto. Nisto ela difere de todas as outras normas e
procedimentos da ISO, que visam principalmente o mbito operacional. Ela um modelo
burocrtico de gesto e cabe a cada administrador decidir se este modelo adequado para
sua organizao. No entanto, esta deciso foi retirada dos administradores. Os governos
passaram a exigir a certificao ISO-9000 como pr-requisito para a seleo de fornecedores.
Estes, por sua vez, passaram a exigir que seus prprios fornecedores a adotassem. A coero
responsvel pela esmagadora maioria das iniciativas de adoo da norma e isso algo
deplorvel.
Alm disso, a maioria das empresas, que no foram diretamente coagidas certificao,
adotou a norma imaginando que se tratava de um programa de melhoria contnua. Mas isso
no verdadeiro. A mera adio de recomendaes sobre ciclos PDCA a uma filosofia que
mira a estabilidade e no a mudana, no a transforma em um programa de melhoria de
qualidade.
Muitos argumentaro que se um processo no est sob controle ele no pode ser aprimorado.
Isto verdade, mas este argumento teria como pressuposto que sistemas no burocratizados
esto sempre fora de controle. Esse pressuposto simplesmente invlido. Todo trabalho de
Deming focou em sistemas sob controle sem que a estrita formalizao de procedimentos
fosse utilizada.
A experincia demonstra que sistemas levemente normatizados so muito mais frteis para
projetos do que o informalismo total ou a burocracia total.
14.5 Lies de Guerra

Carl von Clausewitz foi o maior de todos os pensadores da arte da guerra. Ele foi
contemporneo e opositor de Napoleo, mas seus ensinamentos so, at hoje, venerados e
considerados vlidos na execuo do mais arriscado dos projetos: o combate. A leitura de sua
obra, Da Guerra um exerccio fascinante e questionador, cheio de lies aplicveis a vrios
aspectos da vida dentro das empresas modernas. Talvez parea estranho abord-lo em um
captulo sobre qualidade, no entanto, suas anlises sobre princpios, regulamentos e mtodos
lanam uma luz interessante sobre a formalizao de aes em ambientes de alta incerteza.
Clausewitz enfrentou o problema que caracterstico da guerra, mas que tambm ocorre em
nossos projetos: o acaso. Ele observa que "a grande incerteza acerca de todos os dados
constituem uma dificuldade na guerra (...) A falta de visibilidade que esta fraca iluminao traz
consigo tem de ser compensada pelo talento da adivinhao, ou tem que se deixar abandonar
sorte. Na ausncia de uma sabedoria objetiva, necessrio aqui, ainda, confiar no talento e
Pgina 144 de 190
at mesmo na benevolncia do acaso. Em um ambiente como este uma doutrina positiva
impossvel. Nenhuma teoria poderia criar regras, aplicveis universalmente, que pudessem
governar o comportamento dos generais diante dos acasos da guerra.
Para ele, existiam duas alternativas que poderiam nos fazer sair dessa dificuldade:
Em primeiro lugar, o que dissemos a respeito da natureza da atividade guerreira em geral no
se aplica do mesmo modo a todos os escales da atividade. Nos graus inferiores, (...) os
fenmenos aparecem muito mais circunscritos, os fins e os meios so menos numerosos, os
dados mais precisos e freqentemente representados por objetos reais. Mas, medida que se
sobe na hierarquia, as dificuldades aumentam.... Se no poderamos criar modelos precisos
para o comportamento de Generais, a mesma dificuldade no se encontrava para os soldados
rasos.
A segunda alternativa que justifica uma teoria a idia segundo a qual nada a obriga ser uma
doutrina positiva, isto , um mtodo de ao (...) Toda atividade que, a maior parte das vezes,
se aplica sempre as mesmas coisas e utiliza sempre os mesmos meios para os mesmos fins,
deve poder ser objeto de um exame racional (...) Quando a teoria estuda os objetivos que
constituem a guerra e dissocia de um modo mais claro aquilo que primeira vista parece
confundir-se, quando determina de um modo mais completo as caractersticas dos meios da
guerra ao mesmo tempo que os seus provveis efeitos, ento que se cumpre o objetivo
principal de sua tarefa. ento que essa teoria pode servir de guia a quem queira familiarizarse com a guerra atravs de leituras; ela ilumina o seu caminho, facilita as suas diligncias e
impede o interessado de se desviar do caminho.
A funo de uma teoria era criar ordem e esclarecimento, de modo a que as pessoas no
precisassem traar sempre seus prprios caminhos analisando pequenos detalhes. Ela
deveria ser destinada ao futuro lder, para orientar sua auto-educao, assim como um
pedagogo prudente orienta e facilita o desenvolvimento espiritual do jovem sem que, no
entanto, o traga amarrado a si toda a vida. Essa teoria se basearia no ensinamento de
princpios, algumas vezes conflitantes, e deixaria ao general o julgamento de quando apliclos e quando ignor-los e seguir sua prpria intuio. Ela no deveria ser uma teoria
prescritiva, mas um conjunto de princpios que facilitassem a compreenso da realidade,
sempre preservando a liberdade criativa do lder.
Tal teoria serve para formar e no para dirigir. Serve para acelerar o aprendizado e evitar que
o inexperiente cometa erros tolos. A filosofia geral deste curso, e em especial o captulo 7, que
fala de modelos aplicados em projetos, segue essas linhas definidas por Clausewitz. Quando
falamos de curvas de aprendizado no esperamos que algum esforo seja gasto na medio e
criao das curvas de casos reais. Isso deixado para os acadmicos. Basta que o gerente
de projetos compreenda o efeito que o fenmeno do aprendizado pode ter no ambiente de
projetos. Ele pode, inclusive, optar por ignorar o modelo, se o risco lhe parecer aceitvel ou
inevitvel.
Regulamentos e Instrues estariam na outra extremidade do espectro. Um soldado, fora da
atividade de combate propriamente dita, executa tarefas simples e procedimentais em que a
criatividade no necessria e nem bem vinda. Os Regulamentos de Clausewitz so a verso
militar dos procedimentos ISO-9000. Tarefas repetitivas e procedurais devem ter
procedimentos detalhados de forma a diminuir o atrito com que lder tem que lidar na
execuo dos seus planos. No importa se estamos erguendo uma parede em um projeto de
construo civil ou uma paliada contra a cavalaria inimiga, tarefas procedurais que so
freqentes em nossas atividades devem ser padronizadas em detalhes.
Clausewitz foi mais longe e enfrentou o problema mais delicado: o caso dos oficiais
intermedirios. Ele ponderou que como o nmero de oficiais aumenta medida que se desce
para os graus inferiores, cada vez menos podemos confiar na exatido da perspiccia e na
correo do julgamento das esferas inferiores (...) preciso recorrer rotina do metodismo.
Pgina 145 de 190
Este servir de suporte ao julgamento e de barreira a essas idias extravagantes e totalmente
erradas de que preciso desconfiar acima de tudo.
O mtodo, a maneira de proceder, um comportamento constante escolhido entre vrios
outros igualmente possveis; e o metodismo aplica-se a ao, que em lugar de ser
determinada por princpios gerais ou por regulamentos individuais, obedece a mtodos... O
metodismo no est fundamentado em premissas definidas e particulares, mas na
probabilidade mdia de casos anlogos.
O metodismo se utiliza de duas ferramentas principais: regras e princpios. Regras, neste
sentido, so meios de identificar uma situao graas a um sinal especfico. No existe regra
sem exceo, mas quando utilizamos a regra temos mais probabilidade de julgar corretamente
a situao. Regras so estruturadas na forma Se...Ento. Princpios so conselhos
aplicveis na maior parte dos casos.
Regras e princpios definem o elenco de opes possveis para o oficial. Os oficiais devem ser
condicionados a utilizar as regras e princpios, mas no h obrigatoriedade no cumprimento de
nenhuma regra ou princpio especfico. Ele tem a liberdade de escolher, dentre o elenco de
princpios disponveis, quais os adequados a sua situao particular.
Para obter o equilbrio entre a liberdade de julgamento e o mtodo, os oficiais intermedirios
devem ser treinados nas regras e princpios e enfaticamente orientados a utiliz-los. Eles
devem saber que seguro seguir o mtodo e, quando se afastam dele esto assumindo
riscos. A maioria seguir o caminho seguro. Aqueles que tiverem capacidade de avaliar as
situaes de maneira mais profunda e assumirem riscos sero, desde que demonstrem a
sabedoria de suas escolhas, aqueles que acabaro sendo alados a posio de generais, ou
gerentes de projeto.
14.6 Plano de Gerenciamento de Qualidade

Depois desta longa introduo estamos de volta ao mundo dos processos de gerenciamento
de projetos. De uma forma genrica, o Gerenciamento de Qualidade em projetos inclui todos
os processos necessrios para garantir que o projeto satisfaa as necessidades que
motivaram sua criao. Cabe ao gerente de projeto definir com a Organizao qual filosofia de
qualidade aplicvel.
Como sempre, existe uma parte do Plano de Projeto que cuida da qualidade. O Plano de
Gerenciamento da Qualidade descreve tanto a poltica de qualidade quanto a maneira como
ela ser implementada no projeto.
Ele pode descrever aspectos como responsabilidades, procedimentos, processos e recursos
necessrios ao gerenciamento da qualidade. O plano pode ter diferentes nveis de detalhe ou
formalidade, dependendo das necessidades do projeto.
O importante garantir que os clientes sero atendidos de maneira adequada. E, para isso, as
prticas de qualidade podem ser ferramentas poderosas, quando bem aplicadas.
Pgina 146 de 190
14.7 Critrios de Qualidade de Produtos
O planejamento da qualidade deve identificar os padres de qualidade que se aplicam aos
produtos do projeto e determinar como satisfaz-los.
Na determinao dos padres de qualidade de produtos, existem duas possibilidades.
possvel que padres ou regulaes pr-existentes afetem alguma atividade ou produto do
projeto. Neste caso a documentao do projeto deve referenciar os padres competentes.
No entanto, a caracterstica nica dos projetos praticamente garante que nem todas as
necessidades de qualidade sero cobertas pelos padres existentes. O gerente do projeto
deve estabelecer, junto aos Stakeholders, os padres de qualidade para cada item do
escopo do projeto. De fato, o estabelecimento dos padres de qualidade se confunde com a
prpria definio do escopo, pois o cliente pode se recusar a aceitar um produto com base no
fato dele no atender a um determinado critrio. A melhor proteo do projeto contra este fato
definir os critrios antecipadamente e de maneira clara.
Alguns critrios de qualidade podem ser definidos para um subconjunto dos produtos gerados,
outros podem ser amarrados a itens especficos do WBS. De qualquer forma, os critrios de
qualidade podem ser colocados como parte da declarao de escopo do projeto. Isto refora o
fato de que no basta entregar um produto qualquer. necessrio que este produto atenda
aos requisitos dos Stakeholders.
Uma ferramenta til para a definio de critrios de qualidade so os Checklists, ou seja,
uma lista de perguntas para garantir que um determinado critrio de qualidade foi preenchido.
14.8 Controle de Qualidade em Projetos

O controle de qualidade de produtos envolve a monitorao de resultados especficos do
projeto para determinar se os padres de qualidade definidos esto sendo cumpridos. O
controle de qualidade deve ser executado durante o projeto e no somente em seu final.
A inspeo de qualidade a atividade que inclui as tarefas de medir, examinar e testar os
produtos e deliverables do projeto para determinar sua conformidade com os requisitos.
Vrios tipos de inspeo de qualidade podem ser feitos. Uma boa prtica a de que o
responsvel pelo produto seja o primeiro responsvel por inspecion-lo. Isto o torna ciente dos
padres aplicveis e evita que ele cometa os mesmos erros em outros produtos.
importante que os produtos intermedirios sejam aferidos antes que uma nova fase do
projeto comece. A deteco dos erros evita que eles se propaguem para os produtos
seguintes e diminui os custos de correo.
A inspeo pode ser feita em todos os produtos ou, quando isso no prtico ou possvel, em
uma parte dos produtos. Nesses casos, uma amostra deve ser tomada dentro dos critrios
estatsticos. Ela deve, por exemplo, ser representativa em relao ao universo total de
produtos.
Os principais produtos de uma inspeo de qualidade so:
! Decises de aceite Se um produto estiver dentro do padro ele poder ser aceito
pelos Stakeholders, caso contrrio o projeto poder ter retrabalho.
! Ajustes necessrios A inspeo apontar quais caractersticas do produto devem ser
aprimoradas.
! Informaes sobre os problemas A quantidade e qualidade dos problemas pode ser
registrada para acompanhamento. Sucessivas inspees podem mostrar um padro
til para tomada de decises.
Pgina 147 de 190
14.9 Garantia da Qualidade em Projetos
O Controle de Qualidade atua sobre os produtos do projeto, tanto finais quanto intermedirios,
de modo a detectar problemas de qualidade. A Garantia de Qualidade (Quality Assurance)
atua sobre o processo do projeto, de modo a evitar que os problemas de qualidade surjam.
Existem duas principais filosofias de Garantia de Qualidade:
! Controle formal do processo Esta a filosofia preconizada pela norma ISO-9000.
Tem como requisito que um processo formal tenha sido estabelecido antes do
incio do projeto. Seguindo o processo criado racionalmente, espera-se que os
produtos do projeto sejam automaticamente conformes s especificaes.
! Conhecimento do processo Esta a filosofia de Deming. Pressupe o
conhecimento da Teoria de Sistemas e da Variao. A medio de caractersticos
da qualidade e o controle e ajuste do processo pelos prprios trabalhadores,
orientados por uma liderana forte, devem gerar um impulso de melhoria contnua.
A maioria dos projetos no se presta a implantao total da filosofia ISO-9000. Isto no quer
dizer que nenhuma formalizao ou racionalizao de procedimentos aplicvel. J vimos
que existem atividades procedimentais que se beneficiam com a formalizao. Alm disso,
processos mais genricos e flexveis, que permitam opes e liberdade de ao podem, e
devem, ser utilizados. O respeito a esse tipo de processo torna-se mais forte para a equipe do
projeto, uma vez que a necessidade de contorn-lo, extraoficialmente, devido a excees,
minimizada.
No ambiente ISO-9000, um instrumento comum de Garantia de Qualidade a Auditoria de
Qualidade. Essa auditoria um procedimento estruturado de reviso se os procedimentos de
qualidade esto sendo seguidos. As auditorias podem ser previamente marcadas ou terem um
carter surpresa. Em qualquer caso, o componente policial de uma auditoria tem o efeito
colateral de retirar a responsabilidade da verificao de qualidade do gerador do produto.
ele quem deve conhecer os procedimentos adequados e avaliar sua prpria produo. A
mentalidade de Comando e Controle das auditorias de procedimentos est ligada aos
princpios burocrticos e extremamente desmotivadora. Em muitos casos, a monitorao
informal e contnua do trabalho das equipes e a orientao pessoal daqueles que no esto
seguindo os procedimentos mais adequada para o ambiente dos projetos.
O caminho de Deming mais difcil e complexo, mas tambm mais frutfero. O gerente e a
equipe do projeto devem monitorar o que importante para os Stakeholders, particularmente
os clientes. No lugar do cumprimento cego dos procedimentos, a execuo consciente das
tarefas a chave para o sucesso.
Se entendermos um projeto como um servio prestado ao cliente, teremos algumas
dimenses de qualidade de servio que devem ser monitoradas:
! Dimenso Concreta e Evidente para o Cliente Esta , basicamente, a qualidade do
produto do projeto, tal como vista no momento da aceitao.
! Dimenso Intangvel e No Evidente para o Cliente Esta compe aspectos do
produto como: facilidade de manuteno, custo de propriedade, expectativa de vida
til, capacidade de evoluo etc. Esses aspectos devem estar de acordo com as
necessidades do cliente. Se o cliente deseja um produto barato e relativamente
descartvel, a equipe do projeto no deve gastar recursos para aumentar a
expectativa de vida til do produto.
! Dimenso Psicolgica Qualidades como cortesia, simpatia e comprometimento so
importantes para gerar uma avaliao positiva dos Stakeholders sobre o projeto.
Elas se relacionam ao modo como a equipe executa suas tarefas quando em contato
com os clientes e outros Stakeholders.
Pgina 148 de 190
! Dimenso Tempo O tempo citado freqentemente como a dimenso cardinal em
qualidade de servios. Isso especialmente verdadeiro em projetos.
De todas estas dimenses de qualidade, a Dimenso Tempo a que mais facilmente se
presta monitorao. tambm a que tem mais probabilidade de retorno com relao a
esforos de melhoria. Existem algumas subdivises desta dimenso que devem ser
conhecidas:
! Tempo de Acesso Este o tempo decorrido entre a organizao ou o cliente
identificar a necessidade de um projeto e o momento de incio do projeto. Baixo tempo
de acesso importante, particularmente, mas no somente, quando a organizao
executora do projeto no a mesma que a do cliente. Projetos, freqentemente,
devem ser executados dentro de uma janela de oportunidade. No caso de demora
para o incio do projeto pode acontecer que seu final perca esta janela.
! Tempo de Execuo Pelos mesmos motivos relacionados no Tempo de Acesso, o
tempo necessrio para execuo do projeto deve ser o menor possvel. Aumentos de
produtividade, que permitam a entrega de projetos em prazos menores so sempre
bem vindos.
! Confiabilidade na Execuo - Cumprimento dos prazos estabelecidos , talvez, o
aspecto mais importante da Dimenso Tempo da qualidade.
Todos estes aspectos do tempo so facilmente mensurveis. Se uma organizao executa
vrios projetos do mesmo tipo, ela pode criar grficos de controle e medir como se comporta a
variao do seu processo de execuo de projetos. Tudo que dissemos sobre causas comuns
e especiais de variao pode ser aplicado aqui. O conhecimento gerado pode ser usado para,
seguindo o Princpio de Pareto, melhorar o sistema onde o impacto para os Stakeholders
ser maior.
Pgina 149 de 190
15 Execuo e Controle de Projetos

15.1 Sistema de Autorizao de Trabalho
O sistema de autorizao de trabalho (Work Authorization System) um procedimento
formal para liberar o trabalho de projeto de modo a assegurar que as atividades sejam
executadas no tempo e na seqncia apropriada. A autorizao de trabalho pode ser um
documento formal, um e-mail ou apenas verbal. Tudo depende do tamanho e tipo da equipe
envolvida.
importante que, ao receber a autorizao de trabalho, a equipe seja informada sobre:
! Informaes pertinentes ao planejamento do projeto. A nova equipe precisa se integrar
a um projeto em andamento;
! Deliverables e Produtos que so esperados para aquela atividade, bem como os
critrios de aceitao e qualquer padro aplicvel. preciso ter certeza de que o
trabalho foi bem entendido para que ele seja bem executado;
! Necessidades de reporte sobre o andamento do trabalho. Muitas pessoas no
reportam adequadamente ao gerente do projeto, simplesmente porque no foram
solicitadas;
15.2 Reunies de Status

O gerente de projeto deve planejar gastar algum tempo com todas as equipes do projeto, de
forma regular. Em projetos pequenos, estes encontros devem ser com cada indivduo alocado
ao projeto.
A funo do Gerente de Projeto garantir que o projeto ser entregue com sucesso. Para isso
ele deve garantir que cada equipe seja produtiva e contribua de forma efetiva. Ele no pode
fazer este trabalho se no compreender o que cada equipe est fazendo e quais so os
problemas que ela est enfrentando. A experincia demonstra que os problemas s sero
espontaneamente levados ao Gerente do Projeto quando for tarde demais.
Reunies de Status so reunies formais de reviso marcadas de forma planejada no
cronograma do projeto ou no plano do projeto. Assim, no importa o quanto o Gerente de
Projeto e a equipe estejam ocupados com o trabalho, os contatos sero feitos com um mnimo
de periodicidade.
As reunies podem ser feitas com periodicidades diferentes para nveis diferentes. Por
exemplo: as reunies com a equipe podem ser semanais enquanto que reunies que incluam
clientes ou a alta gerncia podem ser mensais.
15.3 Controle de Mudana

Mudana uma certeza em gerenciamento de projetos. No possvel, nem desejvel evitar
que elas ocorram. Mas se o gerente de projetos no conseguir ter algum controle sobre estas
mudanas, elas certamente passaro a ter o controle sobre ele.
O Controle de Mudana se preocupa com integrar e coordenar as mudanas ocorridas
durante todo o projeto. Como sempre, a complexidade e a formalidade desta tarefa deve ser
adequada ao tamanho do projeto e cultura da organizao. No entanto, altamente
desaconselhvel um processo totalmente informal de controle de mudana. Por mais que a
burocracia seja um mal a ser evitado, ela tem seu uso. Processos informais freqentemente
levam a m compreenso sobre o que significa a mudana solicitada e, conseqentemente, a
erros nas aes tomadas em resposta. No incomum que um gerente de projeto tenha que
Pgina 150 de 190
fazer e refazer planos e ordenar retrabalhos sucessivos enquanto o prazo final permanece o
mesmo, devido ao excesso de informalidade do processo de mudana.
Existem dois tipos de mudanas: aquelas que so geradas por uma solicitao e aquelas que
ocorrem devido ao desenvolvimento do projeto. Mudanas no requeridas se referem ao no
cumprimento do planejamento e dizem respeito, principalmente, a prazos e custos. J as
solicitaes de mudanas se referem principalmente a mudanas de escopo. O controle de
mudanas decorrentes de solicitaes um processo que segue as seguintes linhas gerais:
! Analisa todas as mudanas solicitadas para o projeto;
! Identifica as tarefas e produtos impactados pela mudana;
! Traduz os impactos em termos de custo, tempo e recursos necessrios;
! Avalia o custo/benefcio das mudanas solicitadas;
! Identifica e sugere mudanas alternativas que possam atingir fins semelhantes com um
custo menor;
! Aceita ou rejeita as solicitaes de mudana;
! Informa sobre as mudanas a todas as partes afetadas;
! Garante que as mudanas sejam apropriadamente implementadas;
! Registra as mudanas em um histrico;
Como sempre, recomenda-se a existncia de um Plano de Controle de Mudana (tambm
chamado de Sistema de Controle de Mudana) que define como as atividades acima sero
executadas no projeto especfico.
Nesse plano tambm deve ser especificado como as mudanas no requeridas sero
identificadas e respondidas. Ele define como a execuo real do projeto deve ser comparada
ao planejamento e como o gerente de projeto deve responder a variaes. Neste ultimo ponto,
deve se tomar cuidado de criar apenas procedimentos gerais, caso contrrio, corre-se o risco
de retirar toda capacidade de iniciativa do gerente de projeto.
A cada mudana, os documentos mais importantes do planejamento devem ser armazenados
de maneira consistente para futura consulta. Isso obtido com o uso de tcnicas de Gerncia
de Configurao.
15.4 Renegociao do Projeto

Sabendo que as mudanas so inevitveis e que devemos registrar mudanas, principalmente
no escopo, devemos nos questionar como nossos planos devem reagir a elas.
A sabedoria convencional nos diz que baseamos nossos planos na definio original de
escopo e, conseqentemente, variaes no escopo esto destinadas a ter impacto nos prazos
e custos acordados. Se, por exemplo, uma estimativa parametrizada foi utilizada na
elaborao do plano e a mtrica utilizada nos diga que o projeto aumentou em 20%, ento, em
tese, devemos ajustar o esforo em 20%. Seguir este raciocnio, porm, uma excelente
maneira de gerar clientes insatisfeitos.
Novamente, devemos lembrar que nossas estimativas so um espelho muito pobre da
realidade. O aumento em 20% em uma mtrica de tamanho no significa realmente que o
esforo deve aumentar em 20%. Gostaramos que nossas mtricas fossem precisas, mas elas
no so. Alm disso, ns nos utilizamos delas no incio do projeto, que quando nosso
conhecimento est menos desenvolvido. Naturalmente, costumamos embutir toda uma srie
de temores e margens de tolerncia nestas estimativas. Se alguns de nossos temores no se
materializaram, ento o esforo j alocado pode ser suficiente para absorver um certo nvel de
variao no escopo.
Pgina 151 de 190
Muitos clientes tm, ainda que intuitivamente, essa viso. Vero o aumento automtico dos
prazos e custos como uma falta de cooperao e preocupao por seus interesses. Em
muitos casos eles tero razo.
Os registros de mudana e as mtricas de tamanho do projeto so um argumento de fora
para um processo de negociao, mas eles so apenas o ponto de partida deste processo. Se
a mudana no for controlada, a probabilidade de renegociao basicamente zero. Se ela
for controlada, as chances de se obter um acordo melhor so relativamente grandes.
Em muitos casos, os clientes estaro dispostos a ceder se o gerente de projetos demonstrar
que tambm pode fazer concesses. Aqui, todas as tcnicas de negociao que citamos
anteriormente sero aplicadas em toda sua extenso.
15.5 Verificao de Escopo

Verificao de Escopo envolve o processo de obteno da aceitao formal dos produtos
finais e intermedirios do projeto pelos Stakeholders. A verificao de escopo difere do
controle de qualidade. Nele ns desejamos correo, conformidade com o planejado. Na
verificao de escopo, buscamos apenas aceitao. evidente que, nos principais produtos
do projeto, uma coisa depende da outra e os dois processo acabam por ser simultneos.
No entanto, nem sempre h padres de qualidade a serem seguidos, embora sempre se
requeira que os produtos sejam aceitos. A nica maneira de obter esta aceitao fazer com
que o cliente, ou outro stakeholder autorizado, inspecione o produto e conceda sua
aprovao.
Muitas tcnicas podem ser usadas nesta inspeo. A tcnica escolhida ir depender do tipo
de produto, das circunstncias do projeto, do perfil do aprovador, etc. Testes so um meio
comum de inspeo e os melhores testes so planejados em detalhes com antecedncia.
Apresentaes so outra ferramenta comum de inspeo.
Em certos casos, um documento formal assinado, afirmando que o produto atende as
necessidades do cliente absolutamente necessrio. Isso verdade principalmente quando
existem obrigaes legais envolvidas. Outras vezes, basta que o cliente de uma aprovao
verbal e pague uma fatura. O nvel de formalidade deve ser compatvel com as circunstncias.
Um problema comum quando o suposto aprovador foge de sua responsabilidade. Isso
acontece muito quando o produto a ser inspecionado uma especificao ou uma deciso de
projeto. Muitas pessoas tm resistncia em se comprometer com uma aprovao mesmo
quando isto foi colocado como uma obrigao delas. Forar algum a assinar algo que no
quer, raramente uma boa poltica. Se a aprovao formal no for legalmente requerida, o
gerente de projeto pode lanar mo de recursos alternativos.
Um recurso til nestes casos a chamada aprovao passiva. O gerente de projeto envia o
documento para o aprovador com um prazo razovel. Na mensagem do envio, ele documenta
que o aprovador tem at a data determinada para se manifestar com relao a algum
problema. Periodicamente o gerente de projeto lembra ao aprovador que o prazo final est
chegando. No dia marcado, o aprovador avisado que, no dia seguinte o documento ser
considerado aprovado caso ele no tenha nenhuma objeo. No dia seguinte, o documento
divulgado para todos os envolvidos, incluindo o aprovador, informando seu status de
aprovado. Se aps esta mensagem final o aprovador no se manifestar, ele ficar em uma
situao difcil se tentar contestar o documento mais tarde. Feita de forma transparente, com
educao e respeito, a aprovao passiva bem aceita, inclusive pelo aprovador.
Outro instrumento para lidar com esta situao convocar uma reunio sobre o produto. A
aprovao pode ser obtida verbalmente durante a reunio. Depois, o gerente de projeto pode
emitir uma ata que registra que o produto foi aprovado e distribu-la para os participantes. Uma
ata um documento relativamente formal, mas no absolutamente requerido que ela seja
Pgina 152 de 190
assinada. Caso ela no seja repudiada em um prazo razovel, a aprovao considerada
como dada.
15.6 Earned Value

A anlise de Earned Value (EV) ou Valor Agregado (VA) a ferramenta mais comum de
acompanhamento de performance de projetos, pelo menos nas publicaes. Ela integra dados
de escopo, custo, esforo e cronograma em uma forma numrica relativamente simples de se
compreender e analisar.
Para compreender EV devemos lembrar que, para cada atividade no cronograma, ns
associamos uma determinada quantidade de tempo de um certo nmero de recursos. Se, para
cada recurso ns calcularmos ou arbitrarmos um custo, podemos calcular o custo da tarefa
como um todo.
Este procedimento nos leva a um resultado surpreendente. medida que registramos os
dados de esforo real executado, podemos gerar medidas que permitam o acompanhamento
da evoluo do escopo, do custo e do prazo, de forma absolutamente integrada e
transformada na linguagem financeira. Nesses clculos, o escopo representado na forma da
tarefa em si e a dimenso tempo associada convertida em custo. Em EV, tempo
literalmente dinheiro.
Por exemplo: digamos que uma determinada tarefa tenha a durao estimada de 2 dias e
exija 1 filsofo e 1 poltico trabalhando 8 horas por dia. O filsofo trabalha a $100,00 por hora
(verdadeiros filsofos so raros e, por conseqncia, so caros), mas o poltico custa apenas
$10,00 por hora (um poltico extremamente fcil de se comprar e assim o valor de mercado
baixo).
O custo orado para a tarefa de $1.760,00. Isto fcil de calcular: so 16 horas do filosofo a
$100,00 por hora mais 16 horas do poltico a $10,00 por hora.
Podemos fazer mais do que calcular o custo da tarefa como um todo. Podemos calcular o
custo para cada dia que a tarefa dura. Neste caso, esperamos que a tarefa custe $880,00 no
primeiro dia e mais $880,00 no segundo.
EV envolve o clculo e acompanhamento deste tipo de valor em trs dimenses do projeto:
! O que estava planejado para acontecer no cronograma original - Os valores calculados
a partir do cronograma original. Estes so os valores que acabamos de calcular. A
medida que o projeto avana podemos calcular valores acumulados. Este valor
acumulado at a data de status do projeto chamado de BCWS (Budgeted Cost of
Work Scheduled) ou COTA (Custo Orado do Trabalho Agendado) ou ainda PV
(Planned Value) ou VP (Valor Planejado).
! O esforo que foi executado pelo projeto - Essas so as horas realmente trabalhadas,
convertidas em dinheiro da mesma forma que o anterior. chamado de ACWP
(Actual Cost of Work Performed) ou CRTR (Custo Real do Trabalho Realizado) at a
data de status do projeto. Tambm conhecido por AC (Actual Cost) ou CR (Custo
Real)
! O que foi efetivamente realizado pelo projeto - Estas so as horas produzidas, o que
no necessariamente igual as horas trabalhadas. indicado pelo valor chamado de
BCWP (Budgeted Cost of Work Performed) ou COTR (Custo Orado do Trabalho
Realizado) at a data de status do projeto ou ainda EV (Earned Value) ou VA (Valor
Acumulado)
Em termos simples, se uma tarefa est orada em 80 horas a $10,00 a hora, seu valor orado
(BCWS) de $800,00. Se o recurso j trabalhou 60 horas, mas s completou metade da
tarefa, o valor do esforo (ACWP) $600,00 mas o valor produzido (BCWP) apenas metade
do orado, ou seja, $400,00.
Pgina 153 de 190
Retornemos ao nosso exemplo original. Ao final de um dia de trabalho, o filsofo seguiu
risca o que estava combinado, mas nosso poltico no apareceu.
O nosso planejado para o primeiro dia era: BCWS = 8 * 100 + 8 * 10 = $880,00
Qual foi o esforo realizado ? Somente a parte do filsofo. Nosso ACWP igual a 8 * 100 =
$800,00.
Nesse esforo, quanto, efetivamente, se produziu ? Se seguirmos a maneira que o MS Project
faz a conta, esse ltimo clculo segue um procedimento ligeiramente diferente. Foram
produzidas 8 horas de esforo. Se o custo total da tarefa de $1.760,00 utilizando 32
Homens-hora, ento cada hora vale, em mdia, $55,00. Este o valor que utilizamos para
calcular o BCWP. Como produzimos 8 horas o esforo na forma do BCWP = 8 * 55 = $440,00
Ao final do dia seguinte, nosso poltico continuou sem aparecer, mas nosso filsofo descobriu
que conseguiria terminar o trabalho sem ele. O BCWS = $1760,00 o custo orado da tarefa
inteira. O esforo (ACWP) foi de $1600,00 correspondente aos 2 dias de trabalho do Filsofo.
E o que foi produzido (BCWP) igual ao que foi orado. Talvez seja um tanto estranho dizer
que foram produzidas 32 horas de trabalho em apenas 16 horas de esforo, mas com o tempo
esta idia fica mais natural.
Para que a anlise deste valores fique mais clara, usa-se alguns indicadores derivados. Os
mais comuns so:
! SV (Schedule Variance) ou VA (Variao na Agenda) do valor acumulado at a data
de status do projeto representa a diferena entre o trabalho realmente produzido e o
que estava orado at a data. o BCWP menos o BCWS.
! CV (Cost Variance) ou VC (Variao de Custo) do valor acumulado at a data de
status do projeto representa a diferena entre o trabalho produzido e o esforo
realizado. o BCWP menos o ACWP.
Em nosso exemplo, ao final do primeiro dia SV era negativo em $440,00 ($440,00 - $880,00) ,
com um CV, igualmente negativo, de $360,00 ($440,00 $800,00).
O SV negativo significa que o projeto est atrasado. O CV negativo indicaria um gasto maior
do que o orado. Em nosso caso, isto no verdadeiro mas apenas uma distoro temporria
devido ao fato de o filsofo ser muito mais caro que o poltico e utilizarmos custos mdios para
o clculo do realizado.
Se no fosse por este detalhe, o CV seria positivo e indicaria o que realmente ocorreu: o
projeto est atrasado porque houve menos esforo do que o previsto. O que decorrente da
falta do poltico.
Normalmente, quando o SV e o CV so ambos negativos, os indicadores querem dizer que,
apesar de termos nos esforado mais do que o previsto, o projeto est atrasado. Esta uma
situao muito desconfortvel, pois indica problemas na execuo da tarefa. Provavelmente
um risco se materializou.
Ao final da tarefa, o SV zero ($1760,00 - $1760,00) e o CV positivo em $360,00 ($1760,00
$1600,00).
O SV zerado indica que o projeto est rigorosamente em dia, nem atrasado nem adiantado.
Nestas circunstancias, o CV positivo nos diz que fomos econmicos, no precisamos de todo
o esforo orado para realizar a tarefa. Mesmo sem o poltico, o filosofo realizou a tarefa no
prazo.
Pgina 154 de 190
Na tabela a seguir, temos um resumo das possveis situaes destes indicadores.
SV >= 0
SV < 0
CV >= 0 Dentro do oramento e dentro do

prazo. O esforo necessrio foi
menor ou igual ao que o previsto.
Tudo est bem!
Dentro do oramento mas com o prazo

estourado. O esforo necessrio foi menor
do que o previsto mas isto no significa
produtividade. Trabalhou-se menos, logo,
produziu-se menos. Normalmente, isto
ocorre quando os recursos prometidos no
estavam disponveis na data planejada.
CV < 0
Com o prazo e oramento estourados.

Apesar de todos estarem trabalhando feito
loucos, o projeto est atrasado. Esta a
situao pesadelo. Se o problema que
gerou perda de produtividade j ficou para
traz, a situao est sob controle. Mas se as
tarefas com problemas continuam, tudo
deve ficar pior do que est.
Oramento estourado mas dentro

do prazo. O esforo necessrio foi
maior
do
que
o
previsto.
Provavelmente, o gerente de
projeto, notando a possibilidade de
atraso, alocou mais pessoas ou
autorizou horas extras.
Ao analisar os indicadores, devemos ficar alertas para o fato de que valores positivos ou
negativos em CV e SV so normais, se em pequena escala, e que no significam
necessariamente que o projeto est fugindo do planejado. Lembre-se que o planejamento
feito com estimativas, o trabalho realizado dificilmente seguir a estimativa a risca. De fato,
uma forma de ter segurana de que o cronograma est sendo manipulado e a equipe est lhe
escondendo algo o fato dos indicadores estarem sempre zerados. A variao normal
durante os projetos. A ausncia dela indica problemas. Por sua vez, se o gerente de projeto
hiper-reagir a uma variao natural, ele provavelmente estar criando problemas para o
projeto.
Outra anlise til que podemos fazer com os indicadores o da previso do futuro. a
chamada anlise de tendncia. Quando calculamos a soma dos valores orados de todas as
tarefas, temos o oramento total do projeto. Este o BAC (Budgeted cost At Completion) ou
OAT (Oramento ao Trmino), ou seja, o custo de linha de base do projeto.
Podemos comparar o BAC com o EAC (Estimated cost At Completion) ou EAT (Estimativa
ao trmino) do custo do projeto. Esta estimativa tenta prever o custo final do projeto com base
nas informaes de custo que j temos.
A VAC (Variance At Completion) ou Variao na Concluso, entre o custo da linha de base e
o custo estimado, compara este dois valores. Analisa-se este indicador de maneira
semelhante ao SV. Mas como calcular o EAC ? Existem vrias frmulas. Cada uma parte de
uma premissa diferente e s o Gerente do Projeto pode decidir qual a mais prxima de sua
realidade.
! EAC = ACWP + BCWSfuturo Esta a frmula mais comum. Ela soma o trabalho
realizado ao que sobra do trabalho planejado (BAC BCWS). Nessa estimativa,
presume-se que qualquer variao do passado no existir no futuro e, daqui para
frente, tudo ocorrer como previsto. Como dissemos, esta a mais usada, o que no
quer dizer que a mais correta.
! EAC = ACWP + ETC Esta frmula soma o trabalho realizado com uma estimativa do
esforo para terminar o projeto (ETC). Cabe ao gerente do projeto replanejar o futuro
com base no seu conhecimento atual. Esta estimativa provavelmente a mais precisa,
mas ela exige que o gerente de projeto realize uma grande quantidade de trabalho. S
faz sentido utilizar esta frmula quando houve uma mudana grande de cenrio. Ela
no serve para relatrios peridicos de rotina.
Pgina 155 de 190
! EAC = ACWP + BCWSfuturo / CPI CPI um ndice de performance calculado
dividindo-se o BCWP pelo ACWP e mede a produtividade do projeto. Esta frmula
tenta corrigir o trabalho futuro pela produtividade passada e assim toma o caminho
inverso da primeira frmula ao acreditar que tudo de bom e ruim no projeto vai
continuar influenciando o futuro. Esta no uma premissa inerentemente mais
razovel que a da primeira frmula. Apenas o gerente de projeto pode avaliar qual a
mais conveniente.
! EAC = BAC / CPI Esta uma estimativa grosseira e de pouca utilidade, a no ser
que no haja dados detalhados disponveis.
Podemos traar a evoluo dos indicadores bsicos ao longo do tempo e ter uma indicao
visual do que est ocorrendo. O grfico abaixo um exemplo do que podemos produzir.
EAC
VAC
BAC
Acumulado $
BCWS
-SV
ACWP
CV
BCWP(Earned Value)
Data
Incio
Data de
Status
Data
Fim
Tempo
15.7 Anlise Crtica a Earned Value

Apesar de ser altamente recomendada por, virtualmente, toda literatura ortodoxa a respeito de
projetos, a adoo de Earned Value para acompanhamento de projetos tem tido uma
recepo relativamente fria na prtica do mercado.
Os autores normalmente fazem crticas fumegantes ignorncia e ao preconceito do mercado
em relao a uma ferramenta que eles avaliam como fundamental. A realidade, como sempre,
mais complexa.
Os defensores da metodologia sugerem que seu maior poder a juno de vrias dimenses
do projeto em um nico grupo de indicadores. Eles argumentam que no suficiente saber
que os valores gastos foram menores do que os orados at o presente. necessrio ligar
esta informao a um escopo e a um prazo. Se, em um projeto de um ano, oramos gastar
$500.000 no primeiro semestre e recebemos uma conta de $400.000 podemos ter uma
percepo inicial de que o projeto est sendo econmico em seus gastos. Mas, se recebemos
a informao de que apenas metade do trabalho previsto est pronta, o cenrio bem
diferente. Os indicadores Earned Value mostrariam isto facilmente.
A objeo dos gerentes de projeto normalmente toma a forma de reclamaes com relao ao
acrscimo de trabalho no planejamento e registro de informaes de acompanhamento. No
basta que as equipes reportem, de maneira macro, o status da tarefa. Elas tm que reportar
com preciso o nmero de horas/dias trabalhados de cada um dos envolvidos. Os recursos e
Pgina 156 de 190
custos de cada atividade devem ser cuidadosamente planejados e registrados. Muitos
acreditam que o esforo adicional no vale a pena se eles podem ter uma intuio razovel
sobre o status do projeto, comparando as dimenses isoladas. Revendo nosso exemplo: se j
usamos 80% do oramento planejado para seis meses e o projeto est trs meses atrasado,
parece bvio que temos um problema mesmo sem que olhemos os indicadores. Dependendo
da complexidade do projeto e da flexibilidade dos controles oramentrios, o gerente de
projeto pode ou no avaliar que o trabalho adicional para o clculo dos indicadores vale a
pena.
Parece haver outras razes para a resistncia utilizao da metodologia. Estas razes esto
ligadas a sua prpria essncia. Como dissemos, seu ponto forte a juno de vrias
dimenses em um nico grupo de variveis. E se essas dimenses no variarem de forma
homogenia?
Digamos que uma parte do projeto seja terceirizada a custo fixo. Neste caso, o esforo real
no poder ser convertido automaticamente em custo. Podemos, claro, ratear o custo total
pelo nmero de horas previstas. Se as horas reais forem diferentes, os indicadores mostraro
uma variao de custo que no existe, pois o custo total contratado fixo. Existem prticas,
como a colocao de recursos a custo zero e alocao de pessoas como se fossem materiais,
que tentam contornar este problema mas, no fundo, so apenas remendos. Earned Value
transforma tempo em custo e vice-versa. Se estas variveis no forem conversveis sero
geradas distores.
Outro problema tambm relacionado terceirizao. O gerente de projeto normalmente no
tem controle sobre detalhes da execuo de tarefas feitas no ambiente do fornecedor. Em
muitos casos, os fornecedores no se disporo a enviar os acompanhamentos peridicos no
nvel de detalhe exigido pela metodologia. claro que eles podem ser contratualmente
obrigados, mas provvel que, nestes casos, eles reportem exatamente o que o cliente quer
ouvir, ou o que eles querem que o cliente saiba. Em qualquer caso, o acompanhamento pelo
indicador ser intil.
Um problema semelhante aparece nos casos em que a equipe avaliada pelo nmero de
horas que se reportam aos projetos. Se voc pede uma informao a uma pessoa e, ao
mesmo tempo, avalia esta pessoa atravs desta informao, absolutamente certo que
haver distores nos relatrios. Poucas pessoas sero desprendidas o suficiente para
oferecer informaes que possam prejudic-las.
Outro aspecto interessante o carter contbil da metodologia. Ela reconhece os custos por
competncia. Ou seja, quando o trabalho foi executado, no entanto, os executivos podem
estar mais interessados no regime de caixa. Eles querem saber quando devero novamente
desembolsar dinheiro para o projeto. Earned Value no oferece esta dimenso de avaliao
baseada em caixa e o gerente de projetos deve ter um cronograma de desembolso controlado
em separado dos relatrios contbeis da metodologia.
Ainda ligada contabilidade de custos, Earned Value demonstra outra fraqueza. Os custos
contbeis so equiparados a despesas reais. Digamos, por exemplo, que estamos analisando
um projeto de implantao de ERP. Haver funcionrios dedicados ao projeto e consultores
contratados especificamente. Existiro tambm funcionrios e terceiros que daro apoio ao
projeto enquanto continuam a se dedicar as suas atividades normais. Na maioria dos casos, o
aumento de despesa em mo de obra se deve exclusivamente aos consultores ERP
dedicados. Os funcionrios e os terceiros no dedicados ao projeto so simplesmente
reorganizados mudando suas prioridades e redistribuindo trabalho. No entanto, todos os
custos sero igualmente alocados ao projeto. Se o gerente de projeto tiver que tomar uma
deciso que substitua horas de um consultor pelo trabalho de dois funcionrios dedicados, os
indicadores provavelmente reportaro um impacto negativo nos custos. No entanto, a
quantidade de dinheiro que realmente sai da empresa diminui porque os consultores so
pagos por hora e os funcionrios so despesas fixas.
Pgina 157 de 190
Um ponto fundamental diz respeito utilizao da informao. Imaginemos que os indicadores
sero utilizados pelo prprio gerente de projeto. Nesses casos, vimos que muitos gerentes de
projetos avaliam que o trabalho adicional no vale a pena, uma vez que podem acompanhar
cada dimenso separadamente e, como esto envolvidos no projeto, tm acesso a uma
quantidade muito maior de informao, vinda de fontes no formais, do que um mero indicador
agregado pode oferecer. Eles precisam tomar decises e, freqentemente, a opinio de um
membro da equipe pode ser uma indicao mais confivel e rica do que qualquer mtrica.
Se o alvo dos indicadores um executivo ou um cliente temos uma questo maior. Estas
pessoas tm um conhecimento muito menor em relao ao que realmente ocorre no projeto
do que o gerente de projeto. No entanto, elas tambm precisam tomar decises. Aqui o uso de
indicadores agregados mostra todo seu brilho e todo seu abismo. Em tese, um executivo que
acompanhasse um projeto via indicadores poderia ter uma informao concentrada, sem ter
que se preocupar com os detalhes da realidade. como se uma luz vermelha piscasse em
sua mesa e ele s tivesse que procurar saber com quem deve gritar. Esse tipo de
comportamento est enraizado na mentalidade de comando e controle de muitas
organizaes. A verdadeira questo saber se os executivos realmente devem tomar
decises e atitudes baseadas em luzes vermelhas se acendendo.
Devemos lembrar todas as distores que podem acontecer no clculo dos indicadores.
Assim, a luz verde pode estar acesa em projetos condenados e a luz vermelha pode apontar
para um projeto sob controle.
Em qualquer caso, apesar de todos os pontos apresentados, Earned Value uma tcnica
interessante. Se usada corretamente em um ambiente adequado e sem uma preocupao
excessiva por preciso, ela pode ser bastante til. No , definitivamente, a panacia final ou
a nica maneira de controlar projetos de sucesso.
15.8 Relatrios de Acompanhamento

Uma atividade essencial de controle do projeto a de criar e enviar informaes de
acompanhamento. Os relatrios fornecem ao Stakeholders as informaes que eles
precisam saber sobre o projeto. Os relatrios podem ter vrias nfases e periodicidades. E
diferentes relatrios podem ser enviados a diferentes Stakeholders. No entanto, de modo a
evitar burocracia desnecessria. Se for possvel, deve-se optar pela a padronizao de um
nico relatrio peridico para todos.
Algumas informaes importantes que devem ser reportadas so:
! Status e Progresso Descreve o que o projeto j realizou e como est em relao aos
prazos e oramentos combinados. Earned Value um exemplo de como isso pode
ser reportado.
! Previses Descreve o comportamento do projeto em relao ao progresso e status
futuro. Pode-se utilizar a anlise de tendncias para isso.
! Cronograma O cronograma atualizado deve sempre acompanhar o relatrio
! Risco Modificaes na situao dos riscos identificados devem ser reportadas.
Novos riscos devem ter destaque no relatrio.
! Questes Assuntos pendentes de deciso devem ser informados. Adicionalmente, a
pessoa responsvel e uma data limite podem ser registradas.
! Decises Decises importantes podem ser sumarizadas no relatrio, principalmente
aquelas que afetem o escopo do projeto.
Uma ferramenta particularmente interessante para a publicao de relatrios de
acompanhamento a criao de um web site para o projeto. Os diversos Stakeholders
podem ter vises diferentes, customizadas para suas necessidades, sem que o gerente de
Pgina 158 de 190
projeto tenha que criar vrios relatrios. A tecnologia se encarrega de selecionar as
informaes necessrias e criar o relatrio on-line
15.9 Reporte de Status

Para atualizar os registros de status e progresso do projeto, o gerente de projeto deve receber
informaes dos responsveis pela execuo das tarefas. Existem algumas maneiras
genricas de executar este reporte de informaes. Cada uma com suas vantagens e
desvantagens.
A primeira o reporte da data de incio da atividade, do tempo efetivamente trabalhado desde
o ltimo relatrio e uma estimativa da quantidade de esforo pendente. Vejamos, como
exemplo, uma tarefa que estava prevista para durar uma semana, sendo executada por um
nico recurso: em um determinado relatrio este recurso pode reportar que comeou na data
prevista, j trabalhou um total de 32 horas e acredita que necessita de outras 32 horas para
terminar o trabalho. Com base nas informaes dadas, teramos um retrato bastante rico da
situao. Percebemos imediatamente que o profissional parece estar com problemas e talvez
necessite de algum apoio.
O problema com esta tcnica que ela exige reporte em um nvel excessivo de detalhe.
Normalmente, exigido que cada um dos recursos informe a quantidade diria de horas
gastas em cada tarefa em que ele participa. A maioria dos profissionais, especialmente
aqueles que no esto 100% dedicados ao projeto, ir fornecer informaes incorretas.
Alguns porque no guardam apontamentos das horas gastas. Outros, simplesmente, por
diversos motivos, mentem a respeito.
Quando temos recursos a custo fixo, a informao detalhada de horas trabalhadas no
relevante. Precisamos acompanhar apenas o status da tarefa. Por outro lado, se o profissional
pago por hora, h uma grande chance dele distorcer as informaes, o que pode levar a
perda de controle do projeto.
Alm disso, a quantidade de horas a trabalhar uma mera estimativa que pode, dependendo
dos recursos envolvidos ser altamente imprecisa. Esta tcnica exige que cada recurso se
responsabilize por esta estimativa e seja capaz de calcul-la. Se a tarefa envolver vrios
recursos, este trabalho pode no ser trivial.
A segunda tcnica usada requer apenas que a equipe reporte dentro de percentagens fixas de
execuo da tarefa. Existem algumas formulas clssicas como as regras 50/50, 20/80 e 0/100.
Na regra 50/50, por exemplo, as tarefas esto inicialmente 0% completas. Quando a equipe
reporta a data em que a tarefa foi iniciada, o gerente de projeto marca esta tarefa como 50%
completa. Os outros 50% s sero creditados quando a equipe reportar que a tarefa est
terminada.
Essa regra simplifica o reporte por parte da equipe, mas algumas informaes so perdidas no
caminho. O esforo real no registrado e no h maneira alternativa de saber, somente pelo
relatrio, se uma equipe est com problemas.
Este problema minimizado quando o tamanho das tarefas menor do que o perodo de
reporte. Se o reporte semanal e uma atividade de 4 dias foi reportada como iniciada,
necessariamente ela deve ser informada como completa na semana seguinte ou ela estar
atrasada. Se uma atividade permanecer como 50% completa por dois perodos consecutivos,
o gerente de projetos saber que algo est ocorrendo e poder buscar mais informaes.
A terceira tcnica, um meio termo entre as outras duas, exige que o responsvel pela tarefa
reporte a data de incio da tarefa e uma estimativa da data de fim. Esse clculo mais simples
do que o da primeira opo porque apenas o responsvel pela tarefa deve realizar a
estimativa e apenas da data de fim e no de esforos individuais. Como na segunda tcnica,
os detalhes de esforo real so perdidos. No entanto, ela mais rica em informaes do que o
Pgina 159 de 190
mtodo das percentagens. O gerente de projeto pode detectar problemas potenciais pela
simples variao da data prevista de fim.
medida que problemas ocorram e so resolvidos pela prpria equipe, o gerente de projeto
deve estar preparado para variaes significativas na data prevista de fim, tanto para mais
tarde quanto para mais cedo,. Isso absolutamente normal e, em boa parte dos casos,
nenhuma ao corretiva deve ser tomada.
A escolha do estilo de reporte do gerente de projeto. Ele pode usar um ou outro estilo
dependendo do projeto ou da equipe envolvida. Ele pode at mesmo utilizar tcnicas
diferentes para equipes diferentes dentro do mesmo projeto.
Uma ressalva ocorre na adoo de Critical Chain. Quando esta filosofia de gerenciamento
utilizada, as equipes no podero registrar informaes no estilo de percentagens fixas. Isso
porque necessria uma estimativa do trmino da tarefa de modo que os buffers possam
ser administrados. Critical Chain no usa datas definidas para o trmino de atividades. Do
ponto de vista de acompanhamento ele tambm no necessita saber o esforo exato que foi
despendido. Assim, a tcnica de reporte mais adequada a esta filosofia a terceira. Apenas a
data de incio e uma previso da data de fim oferecem a informao de acompanhamento
necessria.
Pgina 160 de 190
16 Encerramento
16.1 Quando puxar a tomada ?
No importa qual seja a situao, a deciso de terminar um projeto prematuramente sempre
difcil. Ningum gosta de admitir fracassos e ningum gosta de estar associado a eles. No
foram poucos os projetos que foram mantidos vivos artificialmente mesmo quando todo o bom
senso apontava para o contrrio.
Sabemos que as pessoas tendem a exibir comportamentos que so recompensados e evitar
aqueles que so punidos. Muitas vezes esquecido o fato de que no s os comportamentos,
mas nossas percepes so influenciadas por nossas expectativas. As pessoas envolvidas no
projeto falharo em enxergar o que pode parecer bvio para um observador sem conexes
emocionais.
O cenrio emocional em torno de uma deciso como esta sempre pesado. Apesar disto,
alguns projetos devem ser cancelados antes de atingirem seus objetivos.
Projetos existem no tempo. A deciso de inici-los , bem como a definio de seus objetivos
se encontram no passado. Normalmente, associamos o encerramento prematuro a uma falha
interna do projeto, mas isto no necessariamente verdadeiro. Imagine que voc esteja
gerenciando um projeto de desenvolvimento de um novo produto e sua empresa compra a
patente de um produto superior. Seu projeto esta dentro do prazo e do custo programados e
voc tem certeza de obter o produto especificado. Mas o prprio objetivo do projeto se tornou
obsoleto.
Uma situao similar ocorre quando h uma mudana administrativa que substitui o antigo
Sponsor do projeto. Um Diretor centralizador pode ser substitudo por um que simptico a
delegao. Por isso, o projeto mais precioso da antiga gesto vai para lata de lixo de manh
bem cedo. Mas claro que nem sempre este o caso e muitos projetos fracassam por suas
prprias falhas. Os objetivos ainda so desejveis, mas as premissas de custo e prazo j no
podem mais ser alcanadas.
Em algum ponto, o Gerente de Projeto deve decidir se a pergunta fatdica Devemos continuar
? pode ser feita. Esta uma deciso de sensibilidade. Se feita prematuramente, pode dar a
impresso de derrotismo e fazer at com que ele seja removido do projeto. Feita tarde demais
levar a perdas desnecessrias. Nenhum procedimento formal pode ajudar o gerente de
projeto nesta deciso. Mas se a pergunta for feita, ou ele decidir levant-la, existem algumas
orientaes que podem ajud-lo. Lembre-se de que, dificilmente, o gerente de projeto poder
tomar esta deciso. sua responsabilidade, porm, fornecer um parecer adequado queles
que tem autoridade para isto.
O princpio bsico deste tipo de questo a anlise de cenrio. Temos duas alternativas
bsicas: parar ou continuar. Cada uma tem suas vantagens e conseqncias.
Alguns exemplos de questes que devemos responder, para cada opo, de modo a montar
os cenrios so:
! Qual o nvel de suporte que os principais Stakeholders oferecem ao projeto ? Qual
seria sua reao se o projeto fosse interrompido ?
! Qual a probabilidade de sucesso do projeto ? Quais as possveis alternativas ao
abandon-lo ?
! O projeto ainda gera um benefcio positivo mesmo com o novo custo e prazo ? Qual a
perda acumulada de ele for abandonado ?
Pgina 161 de 190
! O projeto ainda compatvel com a capacidade financeira da organizao ? Quais as
conseqncias de curto e longo prazo em assumir os prejuzos e encerr-lo ?
! O escopo j produzido pode ser aproveitado com um investimento adicional menor e
reduo dos objetivos do projeto ? H alternativas melhores para este investimento ?
A anlise de cenrios deve envolver conseqncia positivas e negativas de cada alternativa.
Fornecer esta anlise pode evitar que a organizao cometa erros por reaes emocionais.
Ainda assim, mandar o currculo para os amigos pode ser uma contingncia prudente.
16.2 Encerramento Formal

O encerramento formal do projeto ou de uma fase faz parte da estratgia de comunicao.
Existem coisas que so possveis durante o projeto, mas que no devem continuar aps seu
encerramento. Por exemplo: os clientes podem solicitar pequenos ajustes no produto durante
suas fases finais. Muitos projetos prevem este fato. Mas uma vez que o projeto esteja
terminado, a manuteno do produto se regula por uma dinmica diferente. Os recursos,
antes disponveis para o cliente, podem j estar alocados a outro projeto ou terem retornado a
suas funes normais.
Encerrar formalmente o projeto significa informar a todos os Stakeholders de seu trmino.
Significa tambm obter a aprovao final dos produtos do projeto, confirmando que eles
atingiram os requisitos dos clientes. Por vezes, durante o projeto so feitas negociaes
prevendo atividades e compromissos aps seu encerramento. Esta a hora de informar aos
Stakeholders quem ficar responsvel por estes compromissos e como eles sero
atendidos. Lembre-se, se o cliente ainda deve uma ltima fatura e no concorda que o projeto
terminou, ele tem a ltima palavra.
Cabe ao gerente de projeto garantir que as informaes geradas pelo projeto sejam
devidamente organizadas, indexadas e armazenadas.
16.3 Anlise Post-Mortem

O encerramento , certamente, a mais negligenciada de todas as atividades ligadas ao
gerenciamento de projetos. Afinal, uma vez que o projeto est encerrado, com ou sem
sucesso, ele se torna passado e todos os envolvidos passam a olhar para o futuro.
No entanto, os projetos encerrados podem prover informaes valiosas para futuros projetos.
Em alguns casos, projetos semelhantes podem ser raros e portanto o esforo pode no ser
compensatrio. No entanto, quando a organizao atua de forma recorrente no mesmo tipo de
projeto, importante descobrir o que houve de certo e de errado no projeto de modo a
aperfeioar os procedimentos da organizao.
A anlise Post-Mortem no uma busca por culpados. Ela no se dirige a pessoas, mas a
polticas e procedimentos. Ela estuda o planejado em comparao com o realizado, de modo
a descobrir causas comuns e especiais de variao e agir de acordo com elas.
Pgina 162 de 190
Apndice A - PMI e PMBOK

Histrico
O PMI (Project Management Institute) nasceu em 1969 em Philadelphia, Pennsylvania, USA
com cinco voluntrios. Seus primeiros seminrios atraram menos de 100 pessoas. Na dcada
de 70, comeou a publicar Project Management Journal (PMJ), o que ajudou a atrair mais
membros e divulgar o PMI pelo mundo. J contava ento com 2.000 membros.
Na dcada de 80 as atividades, servios e quantidade de membros continuaram a crescer.
Um Cdigo de tica foi adotado para a profisso e o primeiro exame de certificao Project
Management Professional (PMP) foi administrado. Comeava a caracterizao do gerente
de projetos como uma profisso que necessitava de formao especfica. Os primeiros
padres foram publicados. Uma publicao mensal, o PM Network, foi iniciada e a rea
editorial cresceu, comeando a publicar livros.
Em torno de 1990, os membros totalizavam mais de 8.500 e, aps 1993, as taxas anuais de
crescimento superaram 20% ao ano. Tambm foi estabelecida a presena na World Wide
Web e a publicao do mais importante padro de gerenciamento de projetos, A Guide to the
Project Management Body of Knowledge (PMBOK Guide).
No incio do sculo 21, o PMI tinha mais de 50,000 membros, mais de 10.000 Project
Management Professionals certificados e mais de 270.000 cpias do PMBOK Guide em
circulao.
Atualmente, o PMI a maior associao no lucrativa de profissionais de gerenciamento de
projetos em todo o mundo, possuindo mais de 86.000 membros espalhados pelo planeta em
125 pases. As reas de atuao de seus membros incluem indstrias automotivas,
aeroespaciais, gerenciamento de negcios, construo civil, engenharia, servios financeiros,
tecnologia de informao, farmacutica, telecomunicaes dentre outras. O PMBOK Guide
passou a ser quase universalmente reconhecido como a referencia bsica de boas prticas
para projetos de sucesso.
No Brasil, desde o incio deste sculo, passou a ser cada vez mais comum a exigncia de
conhecimento do PMBOK ou at mesmo certificao PMP em licitaes e processos de
selees de profissionais.
Pgina 163 de 190
Processos de Iniciao
Processos de Iniciao
5.1
5.1
Iniciao
Iniciao
Processos de Planejamento
Processos Core
5.2
5.2
Planejamento
Planejamento
de
deEscopo
Escopo
5.3
5.3
Definio
Definio
de
deEscopo
Escopo
6.2
6.2
Sequenciamento
Sequenciamento
de
deAtividades
Atividades
6.1
6.1
Definio
Definiode
de
Atividades
Atividades
6.4
6.4
Desenvolvimento
Desenvolvimento
de
deCronograma
Cronograma
6.3
6.3
Estimativa
Estimativade
de
Durao
Duraode
de
Atividades
Atividades
7.1
7.1
Planejamento
Planejamento
de
deRecursos
Recursos
7.3
7.3
Oramento
Oramentode
de
Custos
Custos
7.2
7.2
Estimativa
Estimativade
de
Custos
Custos
4.1
4.1
Desenvolvimento
Desenvolvimento
do
doPlano
Planode
de
Projeto
Projeto
11.1
11.1
Planejamento
Planejamento
de
deGerenciamento
Gerenciamento
de
deRiscos
Riscos
Processos de Facilitao
8.1
8.1
Planejamento
Planejamento
de
deQualidade
Qualidade
10.1
10.1
Planejamento
Planejamentode
de
Comunicaes
Comunicaes
9.1
9.1
Planejamento
Planejamento
Organizacional
Organizacional
9.2
9.2
Aquisio
Aquisioda
da
Equipe
Equipe
11.2
11.2
Identificao
Identificao
de
deRiscos
Riscos
11.3
11.3
Anlise
Anlise
Qualitativa
Qualitativa
de
deRiscos
Riscos
Pgina 164 de 190
12.1
12.1
Planejamento
Planejamento
de
deAquisies
Aquisies
11.4
11.4
Anlise
Anlise
Quantitativa
Quantitativa
de
deRiscos
Riscos
12.2
12.2
Planejamento
Planejamento
de
de
Solicitaes
Solicitaes
11.5
11.5
Planejamento
Planejamento
de
deResposta
Respostaaa
Riscos
Riscos
Processos de Execuo
Processos de Execuo
4.2
4.2
Execuo
Execuodo
do
Plano
Planode
deProjeto
Projeto
9.3
9.3
Desenvolvimento
Desenvolvimento
da
daEquipe
Equipe
8.2
8.2
Garantia
Garantiade
de
Qualidade
Qualidade
10.2
10.2
Distribuio
Distribuio
de
deInformao
Informao
12.4
12.4
Seleo
Seleode
de
Fornecedores
Fornecedores
12.3
12.3
Solicitao
Solicitao
12.5
12.5
Administrao
Administrao
de
deContrato
Contrato
4.3
4.3
Controle
Controle
Integrado
Integrado
de
deMudana
Mudana
10.23
10.23
Reporte
Reportede
de
Performance
Performance
5.4
5.4
Verificao
Verificaode
de
Escopo
Escopo
5.5
5.5
Controle
Controlede
de
Mudana
Mudanade
de
Escopo
Escopo
6.5
6.5
Controle
Controlede
de
Cronograma
Cronograma
7.4
7.4
Controle
Controlede
de
Custos
Custos
8.3
8.3
Controle
Controlede
de
Qualidade
Qualidade
11.6
11.6
Monitorao
Monitoraoee
Controle
Controlede
de
Riscos
Riscos
Pgina 165 de 190
Processos de Encerramento
Processos de Encerramento
12.6
12.6
Encerramento
Encerramento
de
deContrato
Contrato
Pgina 166 de 190
10.4
10.4
Encerramento
Encerramento
Administrativo
Administrativo
Apndice B Probabilidade e Estatstica

Introduo
Incerteza foi, talvez, o principal assunto abordado neste trabalho. Este apndice foi idealizado
para ajudar o estudante na compreenso de alguns princpios da matemtica da incerteza.
Esta introduo Probabilidade e Estatstica , com certeza, insuficiente para um estudo
mais srio, mas fornecer a base necessria para o entendimento correto dos conceitos que
foram apresentados neste trabalho.
Probabilidade
De uma maneira simples, probabilidade uma medida da incerteza. Trata-se de um nmero
que pode variar apenas entre 0 e 1. A probabilidade zero (0) associada a eventos que no
podem ocorrer, que no tm chance alguma de acontecer. A probabilidade 1 ou 100%
associada a eventos absolutamente certos de ocorrerem.
A definio do nmero exato de probabilidade associado a um evento uma operao
freqentemente complexa. Em alguns casos, a estimativa baseada apenas nas crenas
subjetivas da pessoa que gerou a estimativa de probabilidade. No caso oposto, temos a
probabilidade que definida de maneira lgica pela prpria estrutura do fenmeno. Esse o
caso da chance associada face de um dado. Sabemos que o dado tem seis lados iguais e
que qualquer um deles tem a mesma chance de ser sorteado. Assim podemos calcular que a
probabilidade de que um lado especfico seja sorteado exatamente 1/6.
Entre esses dois extremos, a determinao totalmente subjetiva e a lgica/objetiva, fica a
Probabilidade Experimental. A Probabilidade Experimental uma extrapolao do futuro pela
anlise do passado e tambm considerada objetiva. Se realizarmos um experimento no
determinstico um certo nmero de vezes e observarmos uma determinada quantidade de
ocorrncias de um fenmeno, podemos estimar a probabilidade do fenmeno pela frmula:
Probabilidade = Nmero de Ocorrncias do Evento / Nmero de Execues do Experimento
Chamamos de espao amostral ao conjunto de todos os resultados possveis do experimento.
No caso de um dado, o espao amostral {1,2,3,4,5,6}. Um evento definido como um
subconjunto do espao amostral. Um exemplo de evento possvel no caso de um dado que
o nmero sorteado seja maior ou igual a 4. A probabilidade associada a um evento pode ser
encontrada. Neste caso ela seria 0,5. A probabilidade associada com o espao amostral 1.
Dois eventos so ditos como independentes se a ocorrncia de um no afeta a probabilidade
da ocorrncia do outro.
Regra da Multiplicao
Suponha dois procedimentos consecutivos. Imagine que o primeiro tenha n1 tipos diferentes
de resultados e que o segundo tenha n1 tipos diferentes de resultados. Se tomarmos os dois
em conjunto, teremos n1 x n1 tipos diferentes de resultados. A figura abaixo ilustra isso.
Pgina 167 de 190
Se temos associada uma probabilidade para cada opo, a probabilidade de que dois eventos
de cada procedimento ocorram juntos expressa por:
P(A e B) = P(A) x P(B|A)
Ou seja, a probabilidade de que os dois ocorram simplesmente a probabilidade que o
primeiro ocorra multiplicada pela probabilidade de que o segundo ocorra uma vez que o
primeiro ocorreu.
Quando tomamos dois eventos independentes e desejamos calcular a probabilidade de que
ambos ocorram, podemos utilizar a regra da multiplicao. Ela se baseia no fato de que, se os
eventos so independentes P(B|A) = P(B):
P(A e B) = P(A) x P(B)
Por exemplo, qual a probabilidade de que tenhamos um lanamento de um dado maior ou
igual a 4, seguido de um nmero 6. P(d>=4) igual a 0,5. P(d=6) igual a 0,17. A
probabilidade de que os dois ocorram juntos de 0,083.
Regra da Adio
Suponha que dois procedimentos so mutuamente exclusivos, ou seja, so alternativas que
no podem ser executadas em conjunto. Imagine que o primeiro tenha n1 tipos diferentes de
resultados e que o segundo tenha n1 tipos diferentes de resultados. Se tomarmos os dois em
conjunto, teremos n1 + n1 tipos diferentes de resultados. A figura abaixo ilustra isso.
Se temos associada uma probabilidade para cada opo, a probabilidade de que dois eventos
quaisquer de cada procedimento ocorram expressa por:
P(A ou B) = P(A) + P(B)
Imagine, porm, que os eventos no sejam mutuamente exclusivos e que haja uma faixa de
intercesso entre eles.
Nesse caso teremos o seguinte resultado:

P(A ou B) = P(A) + P(B) - P(A e B)
Qual a probabilidade de termos um lanamento de dado maior ou igual a 4 ou um lanamento
com um nmero par ?
P(A ou B) = 0,5 + 0,5 0,33 = 0,67
Pgina 168 de 190
Distribuies de Probabilidade
Se traarmos um grfico de barras em que no eixo x esto os eventos possveis no
lanamento de dois dados e no eixo y esto as probabilidades associadas a cada evento,
obteremos o grfico abaixo. Este tipo de grfico mostra o que chamamos de distribuio
discreta, ou seja, os eventos avanam por passos. Neste caso, nmeros inteiros.
18,0%
16,0%
14,0%
12,0%
10,0%
8,0%
6,0%
4,0%
2,0%
0,0%
2
10
11
12
No mundo real, freqentemente lidamos com as chamadas distribuies contnuas de

probabilidade. Nessas distribuies, os eventos so associados a nmeros Reais e no a
Inteiros. Nesses casos, no lugar de grficos de barras, utilizamos grficos de funes de
distribuio. Quando estamos lidando com nmeros Reais, a probabilidade associada a um
nmero exato zero. Nesse caso, s faz sentido falar de faixas de valores e a probabilidade
ser dada pela integral da curva de distribuio de probabilidade.
Pgina 169 de 190
Estatstica
Estatstica Descritiva X Estatstica Inferencial
A Estatstica Descritiva usa determinadas medidas, como mdias e desvios padres para
caracterizar o comportamento de toda uma populao. Quando dizemos que a mdia da nota
da turma foi 7,3 estamos descrevendo a turma como um todo. Nesses casos, as medidas
estatsticas so conhecidas como parmetros da populao. Se inspecionarmos cada item
produzido por uma fbrica, podemos estabelecer parmetros estatsticos, como o
comprimento mdio de uma pea da produo da fbrica.
A Estatstica Inferencial usa as mesmas medidas da Estatstica Descritiva, mas as calculam
usando apenas uma parte da populao. A idia inferir a mdia ou o desvio padro da
populao por meio da mdia e desvio padro de amostras da populao. Quando afirmamos
que a altura mdia dos habitantes de um Pas 1.71m , no medimos cada um dos habitantes
mas apenas uma pequena poro desse conjunto. Se a amostragem for bem planejada,
podemos inferir o comportamento da populao com muito menos esforo. Nesse caso,
chamamos as medidas de estatsticas sobre a populao e no de parmetros da populao.
Se inspecionarmos apenas uma parte de cada lote produzido por uma fbrica, poderemos ter
uma estatstica do comprimento mdio de uma pea.
Medidas de Tendncia Central

A tendncia central de uma distribuio uma estimativa do "centro" da distribuio de
valores. H trs tipos principais de estimativas da tendncia central:
Media
A mdio o mtodo o mais usado para descrever a tendncia central. Ela
simplesmente a soma de todos os valores dividida pelo nmero de valores.
x=
x
n
Por exemplo, considere a lista de valores a seguir como sendo comprimentos em

centmetros, medidos em 10 amostras:
202, 203, 204, 204, 204, 205, 206, 206, 206, 206
A soma desses 10 valores 2046. Assim a mdia 2046/10 = 204,6 cm.
Mediana
A Mediana o valor encontrado no meio do conjunto dos valores. Um mtodo para
encontrar a Mediana listar todos os valores em ordem numrica e selecionar o
nmero no centro da lista. Por exemplo, se houvessem 7 valores, o nmero que
aparecesse em 4o.lugar na lista ordenada seria a Mediana. Existiriam exatamente 3
valores antes da Mediana e 3 valores aps a Mediana. Nesse caso, temos um nmero
mpar de valores. Tomando nosso exemplo anterior com 10 valores temos:
202, 203, 204, 204, 204, 205, 206, 206, 206, 206
Os valores na 5o e na 6o posio esto no meio da lista. No caso de listas com um
nmero par de valores para calcular a Mediana, computamos a mdia desses dois
valores centrais. Em nosso exemplo, esse valor seria (204+205)/2 = 204,5 cm.
Pgina 170 de 190
Moda
A Moda o valor mais freqente que ocorre na lista. Para determinar a Moda, voc
pode contar quantas vezes o mesmo nmero aparece na lista. Em nosso exemplo, o
comprimento 206 cm ocorre quatro vezes e assim ele a nossa Moda. Em algumas
distribuies, h mais de um valor modal. Por exemplo: em uma distribuio bimodal
h dois valores que ocorrem mais freqentemente.
Medidas de Disperso
A medidas de disperso indicam o grau de espalhamento dos valores em torno da tendncia
central. H trs medidas mais comuns da disperso:
Amplitude
A Amplitude a medida de tendncia central mais facilmente calculada, mas a que
tem propriedades estatsticas mais fracas. A Amplitude simplesmente a diferena
entre o maior valor e o menor valor. Em nossa distribuio do exemplo, o maior valor
206 e o menor valor 202, assim a Amplitude 206 - 202 = 4 cm.
Varincia
Uma maneira de calcularmos a disperso seria medirmos a distncia mdia entre cada
valor e a Mdia da distribuio. No entanto, teramos algumas distncias em valores
positivos (as maiores que a mdia) e outras em valores negativos (as menores que a
mdia). A mdia das distncias seria sempre zero. Podemos contornar esse problema
se calcularmos a mdia do quadrado das distncias. No entanto, pode ser provado que
se dividirmos o somatrio por uma quantidade que uma unidade menor que o
nmero de valores (n-1), essa medida ter propriedades estatsticas mais
interessantes. Assim, a Varincia dada pela frmula:
(x x)
=
n 1
A Varincia em nosso exemplo de, aproximadamente, 2,04cm2.

Desvio Padro
O Desvio Padro normalmente considerado a melhor estimativa de disperso. O
Desvio Padro simplesmente a raiz quadrada da Varincia. O problema da Varincia
ser expressa no quadrado da unidade original. Como estamos medindo valores em
centmetros, a Varincia expressa em centmetros quadrados. O Desvio Padro
corrige isso.
Alm disso, o Desvio padro tem propriedades estatsticas interessantes. Algumas
delas podem ser vistas no apndice sobre Seis Sigma.
O Desvio Padro em nosso exemplo de, aproximadamente, 1,43 cm.
Pgina 171 de 190
Distribuio Normal
A funo Normal a mais conhecida e importante das funes de distribuio de
probabilidade e dada pela frmula:
1 x 2
f ( x) =
exp
2
2
Se X tiver uma distribuio Normal, teremos:

Mdia =
Varincia= 2
Na distribuio Normal, a Mdia , a Mediana e a Moda tm o mesmo valor. A distribuio

Normal que possui mdia 0 e desvio padro 1 chamada de Distribuio Normal Reduzida.
Ela tem propriedades to interessantes que seus valores foram tabelados. Essa tabela pode
ser encontrada em qualquer livro de estatstica. O seu uso mais importante vem do fato de
que possvel transformar qualquer distribuio Normal na distribuio Normal Reduzida
aplicando-se a frmula:
Z=
(X )
Por exemplo, digamos que temos uma distribuio com mdia igual a 2 e desvio padro igual
a 0,05 e queremos saber qual a probabilidade de termos um resultado entre 2 e 2,1. Temos:
Z = (2,1-2)/0,05 = 0,1/0,05 = 2
Se verificarmos na tabela da Distribuio Normal Reduzida, descobriremos que a
probabilidade de um valor ocorrer entre 0 e 2 de 0,4772. Como a distribuio acima
equivalente, a probabilidade nessa distribuio de um valor ocorrer entre 2 e 2,1 a mesma,
ou seja, 0,4772.
Distribuio Gama
A funo Gama uma generalizao da funo fatorial. Se r for um nmero inteiro, (r)= (r-1)!.
Mas Gama est definida para nmeros fracionrios. Assim, por exemplo: (1/2) = .
A funo de distribuio de probabilidade Gama dada pela frmula:
f ( x) =
(x ) r 1 e x
(r )
Se X tiver uma distribuio Gama, teremos:

Mdia = r/
Varincia= r/2
Distribuio Qui Quadrado

A Distribuio de Qui Quadrado um caso particular da distribuio Gama, quando = 1/2 e
r =n/2, onde n um inteiro positivo. Desta maneira obtemos a frmula geral:
n
1
1
f (z) = n 2
z 2 ez / 2
2 ( n 2)
Se Z tiver uma distribuio Qui Quadrado, teremos:

Mdia = n
Varincia= 2n
Pgina 172 de 190
Teorema do Limite Central
O Teorema do Limite Central descreve um fenmeno surpreendente e tremendamente
importante no estudo de problemas estatsticos. Ele afirma que, quando lidamos como somas
de variveis aleatrias, no importando que tipo de distribuio as variveis possuem, a soma
tender a apresentar uma distribuio Normal se o nmero de termos tender ao infinito.
Sejam X1,X2 ... Xn variveis aleatrias independentes com a mesma distribuio, e possuindo
mdia e uma varincia 2.
Se Sn = X1 + X2 + ... Xn , ento:
S n
lim P n
x = ( x )
x
n
onde (x) a probabilidade Normal Reduzida de que a soma seja menor que x.
A ilustrao para este teorema simples. Os resultados dos lanamentos de um nico dado
so uniformemente distribudos entre as faces. A probabilidade de um 6 idntica a
probabilidade de um 3. Mas se lanarmos dois dados e calcularmos a soma, veremos que a
probabilidade d a soma ser 2 ou 12 menor que a do valor mdio 7. Se utilizarmos um
nmero maior de dados e um grande nmero de lanamentos, veremos que o histograma da
soma do resultados tomar cada vez mais a forma de uma distribuio Normal.
Quando analisamos as propriedades de tendncia central e disperso da distribuio normal
criada em decorrncia do Teorema do Limite Central, temos dois resultados muito importantes
na prtica. A mdia da distribuio Normal da soma igual a soma das mdias de cada
distribuio. Assim a mdia resultante cresce com o nmero de termos. Mas o desvio padro
ser a raiz quadrada da soma dos quadrados dos desvios individuais. Desta maneira, ele ser
cada vez menor em relao mdia.
s = 1 + 2 + + n
s = 1 + 2 + + n
s = 1 + 2 + + n
Pgina 173 de 190
Apndice C Teoria das Filas

Todos conhecemos bem o que uma fila. O que no to conhecido o modelo matemtico
que permite prever o comportamento de uma fila. Para entender esse modelo, primeiro temos
que conhecer seus elementos.
O fenmeno que estamos estudando requer apenas que surjam clientes, de uma populao
especfica, que formem uma ou mais filas, enquanto aguardam por algum tipo de atendimento
ou servio.
O processo de chegada caracterizado pelo ritmo mdio de chegada () de novos clientes e o
processo de atendimento pelo ritmo mdio de atendimento (). Alternativamente, podemos
falar em intervalo mdio de chegadas (IC) e tempo mdio de atendimento (TA). trivial
demonstrar que:
IC =
TA =
Quando a populao suficientemente grande, o nmero de clientes na fila no afeta a taxa

de chegada de novos clientes. Nesse caso, em termos prticos, a populao considerada
infinita. Por outro lado, quando a populao pequena, a influncia pode ser considervel. Se,
por exemplo, a populao total de 10 clientes, cada cliente que entra na fila reduz a
probabilidade de que um novo cliente aparea. Se existem 9 clientes na fila e 1 sendo
atendido, a probabilidade de que um novo cliente aparea zero.
Servidor
Fila
Servidor
Servidor
Populao
Atendimento
Uma mtrica muito importante a taxa mdia de utilizao do atendimento (). Para qualquer
fila, ela pode ser calculada pela expresso abaixo, onde M o nmero de atendentes:
Para que uma fila seja estvel, isto , para que o nmero de clientes do sistema convirja para
valores em torno de um nmero mdio, necessrio que a taxa mdia de utilizao do
atendimento () seja menor do que 100%. Se for maior do que 1 a fila crescer para sempre,
ou at que sua capacidade de abrigar os clientes seja esgotada.
A anlise do sistema como um todo sempre pode ser dividida em duas partes. A primeira diz
respeito fila e a segunda ao atendimento. O tempo mdio do cliente no sistema (TS)
dividido em tempo mdio de espera na fila (TF) e tempo mdio de atendimento (TA). O
Pgina 174 de 190
nmero mdio de clientes no sistema (NS) dividido entre o nmero mdio de clientes na fila
(NF) e o nmero mdio de clientes em atendimento (NA). Assim:
TS = TF + TA
NS = NF + NA
J.D. Little demonstrou que, para um sistema estvel de filas, as frmulas abaixo so vlidas:
NF = TF
NS = TS
Todas essas frmulas so aplicveis para qualquer modelo de filas. Elas, no entanto, falam
apenas de valores mdios. Para fazermos previses sobre o comportamento de uma fila,
precisamos mais do que valores mdios. Precisamos saber as distribuies de probabilidade
associadas a esses valores. Se examinarmos dois sistemas com parmetros mdios de
chegada e atendimento idnticos, mas com funes de probabilidade diferentes, eles podem
ter tamanhos mdios de fila completamente diferentes.
Vejamos, por exemplo, dois sistemas, ambos com ritmos mdios de chegada de 20 clientes
por hora e taxa de atendimento de 25 clientes por hora. Admitamos que o primeiro tenha um
comportamento determinstico, ou seja, chega exatamente 1 cliente a cada 3 minutos e ele
atendido em exatamente 2 minutos e 24 segundos. Nunca ser formada uma fila. Os clientes
entraro, sero atendidos e iro embora. A taxa de ocupao deste sistema de 80% e os
20% de folga estaro espaados uniformemente no tempo.
No segundo sistema, por outro lado, os clientes chegam segundo um padro aleatrio. Assim,
possvel que, por exemplo, 10 clientes cheguem simultaneamente e faam uma fila.
Digamos que eles sejam atendidos em 24 minutos e o prximo cliente s aparea 6 minutos
depois do ltimo atendimento. Esse sistema continua tendo ritmo mdio de chegada de 20
clientes por hora, uma taxa de atendimento de 25 clientes por hora e uma taxa de ocupao
de 80%, mas tem um comportamento completamente diferente do primeiro. Nesse segundo
sistema, o tamanho mdio da fila considervel.
A distribuio de probabilidade mais usada na simulao do comportamento de filas reais
chamada distribuio Markovia ou distribuio de Poisson:
f ( x) =
x e
x!
A distribuio Markoviana um caso especial de outra distribuio, conhecida como Erlang de

grau m. Na verdade, a distribuio de Poisson uma distribuio de Erlang de grau 1.
Uma notao muito usada na descrio do comportamento de filas a de Kendall:
A/ B / c/ K / m / Z
A a funo de distribuio dos intervalos entre as chegadas de clientes;
B a funo de distribuio do tempo de atendimento;
c o nmero de atendentes;
K a capacidade mxima do sistema. Se um cliente chegar quando j existem K clientes no
sistema, ele ter que ir embora e tentar novamente em outra hora;
m o tamanho da populao que fornece clientes ao sistema;
Z a disciplina de atendimento da fila. As disciplinas mais comuns so FIFO (que indica que
os clientes so atendidos pela ordem de chegada), LIFO (os ltimos a chegar so atendidos
primeiro, como em uma pilha), por ordem de prioridade e aleatoriamente;
Pgina 175 de 190
Assim, por exemplo, uma fila designada E 2 / M / 3 / / / FIFO tem uma distribuio de
chegada Erlang de grau 2, distribuio de atendimento Markoviana, 3 atendentes, capacidade
e populao infinita e disciplina de atendimento por ordem de chegada. A notao reduzida
A / B / c muito utilizada para filas sem limite de capacidade, populao infinita e regime FIFO.
A famlia de filas M / M / 1 muito importante, porque seu comportamento pode ser
completamente descrito por um grupo de frmulas simples:
Varivel
Nmero mdio de clientes na fila
Nmero mdio de clientes no sistema

Tempo mdio de permanncia dos clientes na fila
Frmula
2
NF =
( )
NS =
TF =
( )
Tempo mdio de permanncia dos clientes no

1
TS =
sistema

Pgina 176 de 190
Apndice D Seis Sigma

Seis Sigma um programa de qualidade criado dentro da Motorola e que depois foi adotado
em muitas outras empresas, particularmente a GE, onde Jack Welch a transformou em uma
das suas obsesses. No s as idias do programa podem ser utilizadas na melhoria da
qualidade em atividades dos projetos, mas tambm o programa composto por sucessivos
projetos de qualidade, fatos que garantem a relevncia do assunto neste apndice.
Por que Seis Sigma Diferente ?

De maneira diferente de outros programas de qualidade ocidentais, Seis Sigma tem
conseguido demonstrar sua capacidade de gerar retornos de investimento considerveis para
os acionistas. Em nossa opinio o que torna a estratgia Seis Sigma diferente das demais
sua abordagem eficiente em 4 frentes:
! O estabelecimento de um forte comprometimento da alta gerncia tanto ao programa
como um todo quanto a projetos individuais de melhoria, garantindo que os recursos
necessrios sejam disponibilizados e que a inrcia seja vencida. Cada projeto tem um
Campeo escolhido entre os gerentes de alto nvel;
! A divulgao dos princpios gerais da metodologia por toda a organizao, criando
uma base para a cultura;
! A educao intensiva de profissionais chaves antes que os projetos comecem.
Estatstica e viso sistmica so ensinados, alm das tcnicas especficas do mtodo.
Estes profissionais so conhecidos como Green Belts ou Black Belts e so os
lderes de projetos e consultores internos;
! O uso de consultores especialistas, os Master Black Belt orientando o processo para
garantir sua aplicao correta;
A maioria dos programas de qualidade carecem de uma ou mais dessas dimenses. Alm
disso temos outras vantagens caractersticas do mtodo e que proporcionam resultados:
! O foco em processo em vez de operaes individuais ajuda a obter uma viso
sistmica. Por outro lado, programas como TQM, como os ocidentais o aplicam,
procuram aprimorar o funcionamento interno de cada departamento o que
normalmente piora o processo. Se cada componente de um sistema for otimizado, o
sistema como um todo estar subotimizado;
! O foco em um nmero limitado de processos de cada vez no lugar de tentar aprimorar
a empresa inteira induz que o principio de Pareto seja seguido, obtendo resultados
rapidamente;
! A utilizao de tcnicas estatsticas de controle de processo cria uma linguagem
comum na empresa e um alvo claro a ser perseguido;
A aplicao de Seis Sigma no carece de problemas e a sua filosofia no sem falhas, no
entanto, ele se mostra to superior a outras iniciativas de qualidade que suas imperfeies
podem ser consideradas menores.
Um dos pontos mais fracos, porm, na sua abordagem inicial aos problemas. A coleta e
classificao de dados so instrumentos fracos para localizao de problemas-raiz. Kepler
tomou toneladas de dados astronmicos e, ao longo de um lento processo, os correlacionou
em leis empricas. Seu mtodo de trabalho foi semelhante ao utilizado em Seis Sigma. J
Newton tomou uma via completamente diferente. Ele procurou entender o fenmeno e
postular alguns princpios. Este mtodo acabou por gerar leis muito mais precisas e
abrangentes que as de Kepler, com quantidades de dados absurdamente menores. O mtodo
Pgina 177 de 190
Thinking Process criado por Goldratt aplicao do mtodo cientfico aos negcios e tem
grande potencial na gerao de solues. No entanto, se a organizao estiver em falta de
Newtons, pode ter resultados bastante razoveis treinando Keplers.
Outro problema diz respeito s medies em si. O alvo do mtodo melhorar o processo, ou
pelo menos melhorar o desempenho de um ou mais indicadores caractersticos do processo.
Quanto mais preciso for um indicador com relao qualidade real, mais adequado ser o
mtodo. Se temos um parmetro absoluto de qualidade, como uma pea deve ter entre 104,5
cm e 105,5 cm , a tcnica quase perfeita. Se, por outro lado, estamos medindo o grau de
satisfao dos clientes com base em notas de 1 a 5 em questionrios, sabemos que o mtodo
ser bastante prejudicado, embora ainda seja utilizvel.
Assim, se pudermos, pelo menos inicialmente, selecionar projetos que lidem com critrios
objetivos, teremos mais chances de obter resultados mais expressivos.
Se isso no for possvel, podemos tentar com componentes objetivos do problema. Em vez de
perguntarmos a satisfao dos clientes, por exemplo, podemos busc-la indiretamente por
componentes que, acreditamos, afetam esta satisfao. Se soubermos que o tempo de espera
um componente importante, podemos medi-lo e estabelecer um tempo mximo para
considerarmos que o cliente foi bem atendido.
O Mtodo DMAIC
O principal mtodo em Seis Sigma o de melhoria de processos, conhecido como DMAIC. A
sigla usa a primeira letra dos nomes de cada fase do processo:
! Define Estabelece um novo projeto e monta a equipe. Identifica o Cliente do projeto,
suas necessidades e suas expectativas. Monta um mapa de alto nvel do processo que
ser aprimorado;
! Measure Cria um plano de coleta de dados que meam os interesses dos Clientes na
eficincia e na eficcia do processo. Executa a coleta de acordo com o plano;
! Analise Estuda os dados coletados se o alvo de melhoria for a eficcia. Desta
maneira podem ser identificados os principais problemas que afetam o cliente. Estuda
os processos se o alvo de melhoria for a eficincia, descobrindo operaes que geram
desperdcio de tempo e recursos. Busca dos problemas-raiz e validao das causas
supostas.
! Improve Escolha de solues para os problemas encontrados. Planejamento de
influencia de modo a lidar com resistncias as mudanas. Aplicaes de pilotos para
as solues;
! Control Define controles estatsticos e no estatsticos para garantia da continuidade
dos resultados obtidos. Documenta o projeto para futura referncia;
Alm desse mtodo, existe um outro,equivalente, quando o projeto deve criar um processo e
no melhorar um processo existente.
Seis Sigma e Capacidade de Processo

Caractersticos da qualidade so variveis ligadas ao produto ou servio que indicam se ele
adequado ao cliente. A avaliao de um caracterstico de qualidade pode ser feita por uma
classificao (ex. uma lmpada acende ou no acende) ou por uma medio (ex. uma
lmpada est consumindo 103 watts). Um caracterstico da qualidade chamado de varivel
se ele resulta em uma medio e de atributo se resulta de uma classificao.
Quando estamos lidando com processos, estamos lidando com variaes. Os caractersticos
de qualidade dos produtos de um processo exibiro variaes que, em boa parte dos casos
,estaro dentro dos limites aceitveis pelos clientes mas que, ocasionalmente, geraro
Pgina 178 de 190
produtos ou servios insatisfatrios. Normalmente, os clientes, o mercado ou o governo
especificam os limites aceitveis por meio de uma faixa de tolerncia (ex. Uma lmpada de
100 watts deve consumir de 98 watts a 102 watts para ser considerada aceitvel ).
Quando fazemos sucessivos testes com produtos de um processo, podemos calcular dados
estatsticos sobre a mdia ou o desvio padro dos valores dos caractersticos de qualidade.
Quando analisamos um processo estvel, ns interpretamos estas estatsticas como
pertencendo a uma distribuio Normal de probabilidade. A distribuio Normal tem algumas
caractersticas bem conhecidas. Quando estamos analisando uma faixa de valores, podemos
saber qual o percentual de probabilidade acumulada dessa faixa de valores. Em especial, na
curva Normal, esses valores foram tabelados em relao mdia. Se tomarmos uma faixa de
valores equivalente a um desvio padro acima e abaixo da mdia, teremos uma probabilidade
de 68,27% de acertarmos o valor real do fenmeno. Se aumentarmos esta faixa para 6
desvios padro de largura, 3 para cada lado, teremos 99,73% de chance de acertarmos o
resultado.
_
X
-3
-2
68,27%
+2
+3
95,45%
99,73%
Conhecendo o comportamento da curva normal, e sabendo que os limites de especificao
estabelecem uma faixa de valores, podemos descobrir qual o percentual de probabilidade
que temos de que o processo produza peas de qualidade aceitvel. De fato, esta relao
entre os limites de especificao e acurva Normal to ntima que se convencionou medir a
capacidade do processo em termos da distncia, em nmeros de desvios padro, do limite de
especificao at a mdia do processo. Como o desvio padro representado pela letra
grega sigma (), dizemos que o processo est a 1 sigma, 2.7 sigma ou 6 sigma, por exemplo.
Para calcular o sigma, depois de termos a mdia e o desvio padro obtidos
experimentalmente, devemos primeiro calcular a capacidade do processo em atender os
requisitos de qualidade. Essa capacidade definida pelo chamado ndice Cpk. Para calcul-lo,
tomamos o limite de especificao que est mais prximo da mdia e calculamos o mdulo da
seguinte frmula:
Cpk = (Limite de Especificao Mdia) / (3 * Desvio Padro)
Em nosso exemplo, suponha que medimos 50 amostras de lmpadas. Ns registramos que as
amostras tinham lmpadas que variavam de 99,4 watts a 101,9 watts, com uma mdia de
Pgina 179 de 190
100,45 watts e um desvio padro de 0,57 watts. Como os limites de controle so 98 watts e
102 watts, usaremos o limite superior para calcular o Cpk.
Cpk = (102 100,45) / (3 * 0,57) = 0,906
Esse nmero no nos diz muito. Mas os matemticos criaram tabelas que permitem
transform-lo em um nmero sigma ou uma porcentagem de probabilidade. Veja a tabela
resumida abaixo:
Cpk
Sigma
Probabilidade de
Acerto
Defeitos por
1.000.000
2,00
99,99966%
1,67
99,98%
233
1,33
99,4%
6.210
1,00
93,3%
66.807
0,97
2,9
91,9%
80.757
0,90
2,7
88,5%
115.070
0,83
2,5
84,1%
158.655
0,67
69,1%
308.538
0,33
30,9%
691.462
O processo de nosso exemplo estaria a aproximadamente 2,7 sigma ou 88,5% de rendimento.

Digamos que a empresa fabrique 10.000 lmpadas por dia. Podemos esperar que ela tenha
que jogar fora ou reprocessar cerca de 1150 lmpadas. Poucas empresas poderiam arcar com
um custo desse tamanho. Notem que a estatstica prev esse nvel de perda, mesmo que
nenhuma lmpada tenha sido realmente reprovada entre as testadas. Na prtica, temos que
planejar a amostragem e determinar seu tamanho, de modo que os dados sejam
estatisticamente representativos. Mas so as caractersticas estatsticas do processo, ou seja
a mdia e o desvio padro, que nos daro a capacidade do processo e no o percentual de
reprovao da amostra.
Ao contrrio do que se pensa, o objetivo da metodologia 6 Sigma no fazer com que todos
os projetos atinjam 6 sigma. Esta seria uma meta prxima da perfeio, mas bastante irreal. O
objetivo real do mtodo fazer com que os processo atinjam desempenhos sigmas que
estejam de acordo com as necessidades do negcio. possvel que um desempenho 4 sigma
seja considerado muito bom para um caso especfico. Por outro lado, em alguns casos, atingir
6 sigma pode no ser suficiente. Imagine que 3 cheques sejam descontados na conta errada,
pelo seu banco, a cada 1.000.000 de transaes. Voc avalia isso como um servio
satisfatrio considerando os volumes de transaes dirias, envolvendo cheques, em um
grande banco? Que tal trs acidentes a cada 1.000.000 de aterrizagens de avio ? Isso bom
o bastante ? Em certos casos procuraremos sempre ir alm de 6 sigma e buscar a perfeio.
Pgina 180 de 190
Bibliografia
1. PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of
Knowledge. USA: Project Management Institute, 2000.
2. LEACH, LAWRENCE. Critical Chain Project Management, 1 ed. USA: Artech House,
2000.
3. DEMING, W. EDWARDS. A Nova Economia, 1 ed. Rio de Janeiro: Qualitymark, 1997.
4. MEREDITH, JACK. Project Management: A Managerial Approach, 3 ed. USA: John
Wiley & Sons, 1995.
5. VERZUH, ERIC. The Fast Forward MBA in Project Management, 1 ed. USA: John
Wiley & Sons, 1999.
6. KERZNER, HAROLD. Project Management: A Systems Approach to Planning,
Scheduling and Controlling, 7 ed. USA: John Wiley & Sons, 2000.
7. PROJECT MANAGEMENT INSTITUTE. Practice Standard For Work Breakdown
Structures. USA: Project Management Institute, 2001.
8. FISHER, ROGER e URY, WILLIAN. Como Chegar ao SIm, 1 ed. Rio de Janeiro:
Imago, 1995.
9. URY, WILLIAN. Supere o No, 4 ed. So Paulo: Best Seller, 1990.
10. GOLDRATT, ELIAHU. Critical Chain, 1 ed. USA: North River Press, 1997.
11. GOLDRATT, ELIAHU. The Haystack Syndrome, 1 ed. USA: North River Press, 1990.
12. GOLDRATT, ELIAHU. A Meta, ed. ampliada. So Paulo: Educator, 1993.
13. GOLDRATT, ELIAHU. Its Not Luck, 1 ed. USA: North River Press, 1994.
14. LEACH, LARRY. Schedule and Cost Contingency Reserve (Buffer) Sizing, USA: API,
2002.
15. VIEIRA, SONIA. Estatstica para a Qualidade, 2 ed. Rio de Janeiro: Campus, 1999.
16. ECKES, GEORGE. A Revoluo Seis Sigma,1 ed. Rio de Janeiro: Campus, 2001.
17. MEYER, PAUL. Probabilidade: Aplicaes Estatstica, 2 ed. Rio de Janeiro: LTC,
1983.
18. ANBARI, FRANK. Quantitative Methods for Project Management, 1 ed. USA:
International Institute of Learning, 1997.
19. ISHIKAWA, KAORU. Controle de Qualidade Total, 3 ed. Rio de Janeiro: Campus,
1993.
20. JURAN, J.M.. Quality Control in Service Industries. USA: TPOK/Juran Institute, 1973.
21. CHIAVENATO, IDALBERTO. Introduo Teoria geral da Administrao, 3 ed. So
Paulo: McGraw-Hill,1983.
22. CANTOR, MURRAY. Object Oriented Project Management with UML, 1 ed. USA: John
Wiley & Sons, 1998.
23. FINNEY, ROBERT. Essential of Business Budgeting, 1 ed. USA: AMACOM, 1995.
24. MORSE, JONH e LORSCH, JAY. Beyond Theory Y. USA: Harvard Business Review,
May-Jun 1970.
Pgina 181 de 190
25. STAW, BARRY e ROSS, JERRY. Knowing When To Pull The Plug. USA: Harvard
Business Review, March-April 1987.
26. McGREGOR, DOUGLAS. The Human Side of Enterprise, 25th Anniversary Printing.
USA: McGraw-Hill, 1985.
27. SEDDON, JOHN. The Case Against ISO 9000. USA: Oak Tree, 2001.
28. ABNT. NBR ISO 9000 Sistemas de Gesto da Qualidade Fundamentos e
Vocabulrio. Rio de Janeiro: ABNT, Dez 2000.
29. ABNT. NBR ISO 9001 Sistemas de Gesto da Qualidade - Requisitos. Rio de Janeiro:
ABNT, Dez 2000.
30. ABNT. NBR ISO 9004-4 Gesto da Qualidade e Elementos do Sistema da Qualidade,
parte 4, Diretrizes para a Melhoria da Qualidade. Rio de Janeiro: ABNT, Nov 1993.
31. RABIN, MATTHEW. Risk Aversion and Expected-Utility Theory: A Calibration Theorem.
USA: University of California-Berkeley, 1999.
32. COENS, TOM e JENKINS, MARY. Abolishing Performance Appraisals, 1 ed. USA:
Berrett-Koehler Publishers, 2000.
33. SHIM, JAE e SIEGEL JOEL. Budget Basics and Beyond, 1 ed. USA: Prentice-Hall,
1994.
34. SCHEINKOPF, LISA. Thinking for A Change: Putting the Toc Thinking Process to Use,
1 ed. USA: St. Lucie Press, 1999.
35. CORBETT, THOMAS. Throughput Accounting, 1 ed. USA: North River Press, 1998.
36. MINTZBERG, HENRY. Safri de Estratgia, 1 ed. Porto Alegre: Bookman, 2000.
37. RAGSDALE, CLIFF. Spreadsheet Modeling and Decision Analysis, 3 ed. USA: SouthWestern College Publishing, 2000.
38. SCHOPENHAUER, ARTHUR. Como Vencer um Debate sem Precisar Ter Razo, 1
ed. Rio de Janeiro: Topbooks, 1997.
39. Von CLAUSEWITZ, CARL. Da Guerra, 2 ed. So Paulo: Martins Fontes, 1996.
40. GARRITY, PETER. MBA Compacto - Matemtica Aplicada aos Negcios, 1 ed. . Rio
de Janeiro: Campus, 2000.
41. PRADO, DARCI. Teoria das Filas e da Simulao, 1 ed. . Belo Horizonte: Editora DG,
1999.
42. DAMODARAN, ASWATH. Avaliao de Investimentos, 2 reimpresso. Rio de Janeiro:
Qualitymark, 1999.
43. LAX, DAVID e SEBENIUS, JAMES. The Manager As Negotiator: Bargaining for
Cooperation and Competitive Gain, 1 ed. USA: Free Press, 1986.
44. WALDROOP, JAMES e BUTLER, TIMOTHY. HBR OnPoint: The Executive as Coach.
USA: Harvard Business Review, 2000.
45. GOFFEE, ROBERT e JONES, GARETH. Why Should Anyone Be Led by You?. USA:
Harvard Business Review, Sep-Oct 2000.
46. GOLEMAN, DANIEL. Leadership That Gets Results. USA: Harvard Business Review,
Mar-Apr 2000.
47. MINTZBERG, HENRY. The Managers Job: Folklore and Fact. USA: Harvard Business
Review, Jul-Aug 1975.
Pgina 182 de 190
48. MINTZBERG, HENRY. Crafting Strategy. USA: Harvard Business Review, Jul-Aug
1987.
49. MINTZBERG, HENRY. Planning on the Left Side and Managing on the Right. USA:
Harvard Business Review, Jul-Aug 1976.
50. RABIN, MATTHEW e THALER, RICHARD. Anomalies: Risk Aversion. USA: Journal of
Economic Perspectives, vol. 15, issue 1, 2001.
51. McCRAY, GORDON ; PURVIS, RUSSELL e McCRAY COLEEN. Project Management
Under Uncertainty: The Impact of Heuristics and Biases. USA: Project Management
Journal, Mar 2002.
52. MORRIS PETER. Updating the Project Management Bodies of Knowledge. USA:
Project Management Journal, Sep 2001.
53. SOTIRIOU DEAN e WITTMER,DENNIS. Influence Method of Project Managers:
Perceptions of Team Members and Project Managers. USA: Project Management
Journal, Sep 2001.
54. AL-TABTABAI, HASHEM. Conflict resolution Using Cognitive Analysis Approach. USA:
Project Management Journal, Jun 2001.
55. SLATER, ROBERT. Jack Welch: O Executivo do Sculo, 3 ed. So Paulo: Negcio
Editora, 1999.
56. WELCH, JACK. Jack Definitivo, 1 ed. Rio de Janeiro: Editora Campus, 2001.
Pgina 183 de 190
Sobre o Autor .............................................................................................................................................. 2
Apresentao ..................................................................................................... 3
1.1
Abordagem do Curso- Teoria e Pratica do Gerenciamento de Projetos............... 3
1.2
Nota sobre o Uso de Termos em Ingls .................................................................. 4
1.3
Breve Histria da Gerncia de Projetos .................................................................. 4
1.4
Caractersticas de um Projeto ................................................................................. 5
1.4.1
Temporrio .............................................................................................................................. 6
1.4.2
Produto ou Servio nico........................................................................................................ 6
1.4.3
De Elaborao Progressiva..................................................................................................... 6
1.5
O que Gerenciamento de Projetos ....................................................................... 7
1.6
Tipos de Projetos...................................................................................................... 7
1.7
Estilos de Gerenciamento de Projetos.................................................................... 8
Introduo ao PMBOK ..................................................................................... 10

2.1
O que o PMBOK ? ................................................................................................ 10
2.2
Processos de Gerenciamento de Projetos ........................................................... 10
2.3
Exemplo de um Processo de Gerenciamento....................................................... 12
2.4
Grupos de Processos............................................................................................. 13
2.5
reas de Conhecimento......................................................................................... 15
2.6
Mapeamento Grupos X reas de Conhecimento ................................................. 16
2.7
Utilizao do PMBOK
Guide ............................................................................ 16
Interao Projeto X Organizao .................................................................... 17

3.1
Stakeholders ........................................................................................................... 17
3.1.1
Papel: Gerente de Projetos ................................................................................................... 17
3.1.2
Papel: Sponsor ...................................................................................................................... 18
3.1.3
Papel: Gerente Funcional da Organizao Executora.......................................................... 18
3.1.4
Papel: Time de Projeto.......................................................................................................... 18
3.1.5
Papel: Cliente ........................................................................................................................ 19
3.2
Problemas Comuns no Relacionamento com a Organizao ............................. 19
3.3
Organizao Funcional ou Hierrquica................................................................. 20
Pgina 184 de 190
3.4
Organizao por Projetos ...................................................................................... 21
3.5
Organizao Matricial............................................................................................. 21
3.6
Project Office....................................................................................................... 22
3.7
O Homem de Ligao ............................................................................................. 22
Mtodos de Seleo de Projetos .................................................................... 24

4.1
Mtodos no Numricos ........................................................................................ 25
4.1.1
Projetos Vaca Sagrada ....................................................................................................... 25
4.1.2
Necessidade Imperativa........................................................................................................ 25
4.1.3
Necessidade Estratgica....................................................................................................... 25
4.1.4
Anlise de Alternativas .......................................................................................................... 25
4.2
Mtodos Numricos Financeiros........................................................................... 26
4.2.1
Payback .............................................................................................................................. 26
4.2.2
Taxa Interna de Retorno ....................................................................................................... 26
4.2.3
Fluxo de Caixa Descontado .................................................................................................. 27
4.2.4
Mtodo de Pacfico................................................................................................................ 27
4.3
Mtodos Numricos no Financeiros ................................................................... 29
4.3.1
Ponderao de Fatores,........................................................................................................ 29
4.3.2
Modelo de Dean e Nishry...................................................................................................... 29
4.4
rvores de Deciso ................................................................................................ 30
O Gerente de Projetos ..................................................................................... 32

5.1
Misso e Paradoxos do Gerente de Projetos........................................................ 32
5.2
O Perfil do Gerente de Projetos ............................................................................. 32
5.3
Introduo ao Processo de Negociao ............................................................... 33
5.3.1
Estratgias Principais de Negociao................................................................................... 33
5.3.2
Negociao Ganha-Ganha.................................................................................................... 35
5.3.3
Tticas ................................................................................................................................... 38
5.3.4
Dialtica Erstica.................................................................................................................... 39
5.4
Cdigo de tica....................................................................................................... 40
Introduo aos Processos de Planejamento ................................................. 42

6.1
Escopo do Produto X Escopo do Projeto ............................................................. 42
6.2
Work Breakdown Structure.................................................................................... 42
6.2.1
Caractersticas de um WBS .................................................................................................. 42
Pgina 185 de 190
6.2.2
Como construir um WBS....................................................................................................... 44
6.2.3
Utilizao do WBS................................................................................................................. 45
6.3
Resumo dos Processos de Planejamento ............................................................ 45
6.4
O Plano do Projeto Definindo as Regras do Jogo............................................. 49
6.5
Balanceamento do Projeto..................................................................................... 50
Introduo aos Modelos e Estimativas utilizados em Projetos ................... 52

7.1
Modelos X Realidade .............................................................................................. 52
7.2
Mtodos de Gerao de Estimativas ..................................................................... 53
7.2.1
Estimativa no Elevador ....................................................................................................... 53
7.2.2
Estimativa por Analogia......................................................................................................... 53
7.2.3
Estimativa Detalhada (Bottom-Up) ..................................................................................... 53
7.2.4
Estimativas por Modelos Matemticos.................................................................................. 53
7.2.5
Estimativa por Fase............................................................................................................... 55
7.3
Pressupostos e Estimativas Parametrizadas ....................................................... 55
7.4
Estimativas e Medidas............................................................................................ 57
7.4.1
Estimativas como funes de probabilidade......................................................................... 57
7.4.2
Nvel de Detalhamento das Estimativas ............................................................................... 58
7.5
Curvas de Aprendizagem ....................................................................................... 60
7.6
Introduo ao Estudo de Variaes ...................................................................... 63
7.7
O Mtico Homem-Ms ............................................................................................. 68
7.8
Estudo sobre as causas de atrasos em projetos ................................................. 70
7.9
Inflao de estimativas........................................................................................... 71
Custos ............................................................................................................... 72
8.1
Plano de Gerenciamento de Custos...................................................................... 72
8.2
Dialtica de Custos................................................................................................. 72
8.3
Oramento Top-Down com Rateios, .................................................................. 73
8.4
Oramentos por Fase ............................................................................................. 74
8.5
Contabilizao dos Custos .................................................................................... 74
8.6
Nvel de Esforo...................................................................................................... 75
Pgina 186 de 190
9
Cronograma...................................................................................................... 76
9.1
Plano de Gerenciamento de Cronograma............................................................. 76
9.2
Ciclos de Vida ......................................................................................................... 76
9.3
Criao de um Cronograma ................................................................................... 76
9.3.1
Definindo as Atividades ......................................................................................................... 77
9.3.2
Dependncias entre Atividades............................................................................................. 78
9.3.3
Clculo do Cronograma ........................................................................................................ 80
9.3.4
Calendrios ........................................................................................................................... 82
9.3.5
Caminho Crtico..................................................................................................................... 83
9.3.6
Fast Tracking ...................................................................................................................... 83
9.3.7
Resource Leveling .............................................................................................................. 83
9.4
Cronograma por Fases........................................................................................... 84
9.5
Gerenciando a incerteza ........................................................................................ 87
9.5.1
CPM....................................................................................................................................... 87
9.5.2
PERT ..................................................................................................................................... 87
9.5.3
Introduo a Critical Chain.................................................................................................. 90
9.6
10
Multitarefa e Mltiplos Projetos ............................................................................. 94
Recursos Humanos ......................................................................................... 98
10.1
Plano de Gerenciamento de Pessoal ................................................................. 98
10.2
Planejamento Organizacional............................................................................. 98
10.2.1
Definio de Responsabilidades e Papeis ............................................................................ 98
10.2.2
Alocao e Liberao de Pessoal ....................................................................................... 100
10.2.3
Aquisio de Pessoal .......................................................................................................... 102
10.2.4
Organograma do Projeto..................................................................................................... 102
10.3
Alocao de Recursos no MS Project........................................................... 103
10.4
Recursos Compartilhados................................................................................ 105
10.4.1
Identifique a Restrio do Sistema ..................................................................................... 107
10.4.2
Explore a Restrio do Sistema .......................................................................................... 107
10.4.3
Subordine tudo explorao da restrio .......................................................................... 108
10.4.4
Eleve a Capacidade da Restrio ....................................................................................... 109
10.5
Desenvolvimento da Equipe............................................................................. 112
10.5.1
Treinamento Tcnico........................................................................................................... 112
10.5.2
Mentoring .......................................................................................................................... 112
10.5.3
Atividades de Construo de Equipe .................................................................................. 112
Pgina 187 de 190
10.5.4
Habilidades de Gerenciamento ........................................................................................... 112
10.5.5
Sistemas de Recompensa e Reconhecimento ................................................................... 113
10.5.6
Colocao Fsica ................................................................................................................. 113
10.6
Motivao Teorias X,Y e alm ....................................................................... 113
11
Comunicao.................................................................................................. 116
11.1
Plano de Gerenciamento de Comunicao ..................................................... 116
11.2
Comunicao Interna........................................................................................ 116
11.3
Matriz de Comunicao .................................................................................... 117
11.4
A Sala de Guerra ............................................................................................... 117
11.5
Reunies de kick off ...................................................................................... 118
12
Riscos ............................................................................................................. 119
12.1
Plano de Gerenciamento de Riscos................................................................. 120
12.2
Identificao de Riscos..................................................................................... 120
12.2.1
Checklists de Riscos ......................................................................................................... 121
12.3
Anlise Qualitativa de Riscos........................................................................... 122
12.3.1
Teoria da Utilidade .............................................................................................................. 123
12.4
Desenvolvimento de Resposta a Riscos ......................................................... 125
12.4.1
Planos de contingncia genricos....................................................................................... 126
12.4.2
Riscos em Terceirizaes. .................................................................................................. 127
12.5
Controle e Monitorao de Riscos................................................................... 127
12.6
Anlise Quantitativa de Riscos ........................................................................ 128
12.7
Dimensionamento de Contingncia................................................................. 129
13
Aquisio e Terceirizao ............................................................................. 131
13.1
Plano de Gerenciamento de Aquisio e Terceirizao ................................. 131
13.2
Processo de Aquisio e Terceirizao .......................................................... 131
13.2.1
Planejamento de Aquisio................................................................................................. 131
13.2.2
Solicitao ........................................................................................................................... 132
13.2.3
Seleo de Fornecedores ................................................................................................... 134
13.2.4
Administrao de Contrato.................................................................................................. 134
13.3
Falhas comuns no Processo de Terceirizao ............................................... 134
13.4
Desenvolvimento de Fornecedores ................................................................. 135

Pgina 188 de 190
14
Qualidade........................................................................................................ 136
14.1
Histrico ............................................................................................................ 136
14.2
Definies.......................................................................................................... 137
14.3
Deming & Juran................................................................................................. 138
14.4
ISO-9000............................................................................................................. 141
14.5
Lies de Guerra ............................................................................................... 144
14.6
Plano de Gerenciamento de Qualidade ........................................................... 146
14.7
Critrios de Qualidade de Produtos................................................................. 147
14.8
Controle de Qualidade em Projetos ................................................................. 147
14.9
Garantia da Qualidade em Projetos ................................................................. 148
15
Execuo e Controle de Projetos ................................................................. 150
15.1
Sistema de Autorizao de Trabalho ............................................................... 150
15.2
Reunies de Status ........................................................................................... 150
15.3
Controle de Mudana........................................................................................ 150
15.4
Renegociao do Projeto ................................................................................. 151
15.5
Verificao de Escopo ...................................................................................... 152
15.6
Earned Value.................................................................................................. 153
15.7
Anlise Crtica a Earned Value ..................................................................... 156
15.8
Relatrios de Acompanhamento...................................................................... 158
15.9
Reporte de Status.............................................................................................. 159
16
Encerramento ................................................................................................. 161
16.1
Quando puxar a tomada ? ................................................................................ 161
16.2
Encerramento Formal ....................................................................................... 162
16.3
Anlise Post-Mortem ..................................................................................... 162
Apndice A - PMI e PMBOK .................................................................................... 163

Histrico........................................................................................................................... 163
Processos de Iniciao................................................................................................... 164
Processos de Planejamento ........................................................................................... 164
Pgina 189 de 190
Processos de Execuo ................................................................................................. 164
Processos de Execuo ................................................................................................. 165
Processos de Controle ................................................................................................... 165
Processos de Encerramento .......................................................................................... 166
Apndice B Probabilidade e Estatstica.............................................................. 167

Introduo........................................................................................................................ 167
Probabilidade .................................................................................................................. 167
Regra da Multiplicao........................................................................................................................ 167
Regra da Adio.................................................................................................................................. 168
Distribuies de Probabilidade............................................................................................................ 169
Estatstica ........................................................................................................................ 170

Estatstica Descritiva X Estatstica Inferencial .................................................................................... 170
Medidas de Tendncia Central ........................................................................................................... 170
Medidas de Disperso......................................................................................................................... 171
Distribuio Normal ............................................................................................................................. 172
Distribuio Gama............................................................................................................................... 172
Distribuio Qui Quadrado .................................................................................................................. 172
Teorema do Limite Central.................................................................................................................. 173
Apndice C Teoria das Filas ................................................................................ 174

Apndice D Seis Sigma ........................................................................................ 177
Por que Seis Sigma Diferente ?................................................................................... 177
O Mtodo DMAIC ............................................................................................................. 178
Seis Sigma e Capacidade de Processo ......................................................................... 178
Bibliografia ............................................................................................................... 181
Pgina 190 de 190

Curso GP

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Curso GP

Enviado por

Direitos autorais:

Formatos disponíveis

Gerenciamento de Projetos

Abordagem do Curso- Teoria e Pratica do Gerenciamento de Projetos

Nota sobre o Uso de Termos em Ingls

Breve Histria da Gerncia de Projetos

O que um projeto? Um projeto academicamente definido como: um empreendimento

Pense no trabalho desenvolvido em uma organizao. Existem aquelas tarefas rotineiras,

1.4.2 Produto ou Servio nico

1.4.3 De Elaborao Progressiva

O que Gerenciamento de Projetos

Se um projeto caracterizado por seus objetivos, gerenciamento de projetos a arte de

Projetos podem ser classificados arbitrariamente de diversas formas. Duas formas de

Estilos de Gerenciamento de Projetos

Existem dois extremos de estilos de gerenciamento de projetos. Chamaremos estes dois

O Project Management Institute a maior organizao mundial especializada em

Processos de Gerenciamento de Projetos

Um processo uma srie de aes que geram um resultado. Um projeto naturalmente

Exemplo de um Processo de Gerenciamento

5.4 Verificao do Escopo

5.4.1 Entradas para a Verificao do Escopo

Assim, os grupos de processos no devem ser vistos de maneira separada ou descontnua.

Sobreposio dos Grupos de Processos

A repetio dos processos de iniciao, no incio de cada fase, auxilia a manuteno do

Os mesmos processos de gerenciamento podem ser classificados por reas de conhecimento.

Mapeamento Grupos X reas de Conhecimento

4.2 Execuo do Plano

5.4 Verificao de Escopo

6.1 Definio de Atividades

7.4 Controle de Custos

4.3 Controle Integrado de

5.2 Planejamento de Escopo

8.3 Controle de Qualidade

As numeraes das reas de conhecimento e dos processos seguem os nmeros dos

Utilizao do PMBOK Guide

3 Interao Projeto X Organizao

Stakeholders so indivduos ou organizaes que esto ativamente envolvidos no projeto ou

3.1.1 Papel: Gerente de Projetos

3.1.3 Papel: Gerente Funcional da Organizao Executora

3.1.4 Papel: Time de Projeto

Problemas Comuns no Relacionamento com a Organizao

Projetos no existem em um vcuo. Normalmente esto inseridos em uma organizao que j

Organizao Funcional ou Hierrquica

Projetos podem ocorrer dentro da realidade de uma organizao puramente funcional.

Organizao por Projetos

Organizao por projetos so comuns dentro da realidade de empresas totalmente focadas

A idia da organizao matricial ser um hbrido entre a funcional e a por projetos. Na

O escritrio de projetos ou Project Office uma entidade organizacional, ou equipe de

4 Mtodos de Seleo de Projetos

Modelos no tomam decises, pessoas tomam !

Mtodos no numricos so mais simples e antigos e normalmente so bem conhecidos.

4.1.1 Projetos Vaca Sagrada

4.1.2 Necessidade Imperativa

4.1.3 Necessidade Estratgica

4.1.4 Anlise de Alternativas

Mtodos Numricos Financeiros

4.2.2 Taxa Interna de Retorno

Ei so os fluxos de caixa de entrada e Si so os fluxos de caixa de sada.

Fi o fluxo de caixa no perodo i (normalmente os fluxos iniciais so negativos)

4.2.4 Mtodo de Pacfico

Mtodos Numricos no Financeiros

Mtodos numricos no financeiros procuram explicitar as opinies e insights dos tomadores

4.3.1 Ponderao de Fatores,

Onde: ni = a nota do projeto no i-simo fator

Modelo de Dean e Nishry

Tendo como restrio que: