Apostila Gerencia Projetos

Gerncia de Projetos
*** Verso 1.19r ***

Curso de Sistemas de Informao
FACE FUMEC Disciplina: Gerncia de Projetos
Pg. I-1
Pg. I-2

NDICE

1. Introduo Um Bom Exemplo de Projeto...................................................... 1
2. Conceitos-Chave................................................................................................. 3
2.1. Conceito de Projeto......................................................................................................... 3
2.2. Gerenciamento de Projetos.............................................................................................. 3
2.3. Operaes X Projetos.................................................................................................... 4
2.4. Exemplos de Projetos...................................................................................................... 4
2.5. Exemplos de No-Projetos .............................................................................................. 5
2.6. Sucesso e Fracasso em Projetos....................................................................................... 5
2.7. Fatores de Sucesso e Fracasso em Projetos...................................................................... 7
2.8. Trade-Offs do Gerenciamento de Projetos ....................................................................... 9
3. Fases de um Projeto e o Ciclo de Vida de Um Projeto................................... 11
3.1. Subdivindo os Projetos.................................................................................................. 11
3.2. Fases Genricas do Ciclo de Vida de um Projeto........................................................... 12
3.3. Comportamento Genrico de um Projeto ao Longo do Ciclo de Vida ............................ 13
3.4. Importncia Relativa dos Objetivos do Projeto quanto ao Ciclo de Vida........................ 16
4. O Gerente de Projetos...................................................................................... 19
5. A Proposta do PMI para o Gerenciamento de Projetos................................. 23
5.1. Os Grupos de Processos de um Projeto.......................................................................... 23
5.2. reas de Conhecimento do Gerenciamento de Projetos ................................................. 26
5.3. Relao entre Grupos de Processos e reas de Conhecimento....................................... 28
6. O Relatrio Executivo...................................................................................... 34
6.1. Misso .......................................................................................................................... 34
Pg. I-3
6.2. Diagnstico................................................................................................................... 36
6.3. Escopo .......................................................................................................................... 36
6.3.1. Objetivos (ou, O Qu o Projeto REALIZAR):...............................................................36
6.3.2. O Qu o Projeto NO REALIZAR................................................................................36
6.4. Restries ..................................................................................................................... 37
6.5. Premissas ...................................................................................................................... 38
6.6. Benefcios..................................................................................................................... 39
6.7. Riscos ........................................................................................................................... 39
6.8. Macro-Fases.................................................................................................................. 40
6.9. Justificativas para Contrataes e Aquisies ................................................................ 41
6.10. Perfil da Equipe de Projeto............................................................................................ 41
6.11. Oramento Preliminar ................................................................................................... 42
6.12. Fatores Crticos de Sucesso........................................................................................... 43
7. O Plano de Execuo........................................................................................ 45
7.1. Cronograma .................................................................................................................. 45
7.2. Matriz de Responsabilidades ......................................................................................... 49
7.3. Plano de Desembolso.................................................................................................... 51
7.4. Produtos e Sub-Produtos ............................................................................................... 52
7.5. Plano de Comunicao.................................................................................................. 54
8. Negociao e Alocao de Recursos ................................................................ 56
8.1. Negociando a Alocao de Profissionais ....................................................................... 56
8.2. Negociando a Alocao de Recursos Fsicos ................................................................. 57
9. Gerncia de Riscos ........................................................................................... 58
9.1. Definio de Risco........................................................................................................ 58
9.2. Caractersticas do Risco ................................................................................................ 58
9.3. Princpios de uma Gerncia de Riscos bem sucedida ..................................................... 58
Pg. I-4
9.4. Origens dos Riscos........................................................................................................ 59
9.5. Impactos dos Riscos...................................................................................................... 59
9.6. Gesto Proativa de Riscos ............................................................................................. 60
9.7. Estratgias para o Gerenciamento de Riscos.................................................................. 60
9.8. O Processo de Gerenciamento de Riscos ....................................................................... 61
9.8.1. Identificao dos Riscos..................................................................................................61
9.8.2. Anlise dos Riscos...........................................................................................................62
9.8.3. Elaborao de Planos de Tratamento dos Riscos...........................................................64
9.8.4. Acompanhamento dos Riscos..........................................................................................67
9.8.5. Controle dos Riscos.........................................................................................................67
9.9. O Documento de Avaliao de Riscos........................................................................... 67
10. Instrumentos para Conduo e Desenvolvimento de Projetos ...................... 68
10.1. Instrumentos de Apoio ao Controle de Projetos ............................................................. 68
10.1.1. TO-DO Lists....................................................................................................................68
10.1.2. Listas de Pendncias (Checklists) ...................................................................................69
10.1.3. Bases de Acompanhamento de Atividades ......................................................................70
10.1.4. Reunies de Acompanhamento .......................................................................................72
10.1.5. Roteiros para Entrevistas / Reunies (Scripts) ...............................................................73
10.1.6. Relatrios de Relacionamento com Fornecedores..........................................................73
10.1.7. Bases Executivas para Acompanhamento de Projetos....................................................74
10.2. Instrumentos de Apoio Gesto do Conhecimento Presente nos Projetos...................... 75
10.2.1. Prottipos........................................................................................................................75
10.2.2. Ambientes de Homologao............................................................................................76
10.2.3. Projetos-Piloto................................................................................................................77
10.2.4. Laboratrios....................................................................................................................77
10.2.5. Benchmarking de Solues .............................................................................................78
10.2.6. Fruns de Discusso/Conhecimento...............................................................................79
10.2.7. Relatrios de Eventos......................................................................................................79
10.2.8. Transferncia de Conhecimento por Tradio ...............................................................80
10.2.9. Reunies de Lies Aprendidas ......................................................................................80
10.2.10. Apresentaes Executivas ...............................................................................................81
11. Avaliao e Escolha de Fornecedores ............................................................. 82
11.1. Estabelecimento de Critrios de Avaliao.................................................................... 82
11.1.1. Definio de Pr-Requisitos ...........................................................................................82
11.1.2. reas de Avaliao .........................................................................................................83
11.1.3. Categorias, Quesitos de Pontuao, Nveis de Conformidade e Pesos ..........................84
11.2. Solicitao de Propostas................................................................................................ 86
11.2.1. Elaborao das Solicitaes de Propostas (RFP Request for Proposal) ....................86
11.2.2. O Recebimento das Propostas Tcnico-Financeiras ......................................................87
Pg. I-5
11.3. Realizao da Avaliao ............................................................................................... 88
11.3.1. Avaliao Tcnica...........................................................................................................88
11.3.2. Avaliao Financeira......................................................................................................89
11.3.3. Avaliao Comercial.......................................................................................................89
11.3.4. Avaliao Mercadolgica...............................................................................................89
11.4. O Relatrio de Recomendao ...................................................................................... 90
11.5. Contratao dos Parceiros Escolhidos ........................................................................... 91
12. Consideraes Finais (mas no menos importantes)...................................... 93
12.1. Envolvimento do Pessoal Interno da Organizao ......................................................... 93
12.2. Quando dizer NO....................................................................................................... 93
12.3. Voc um Lder de Projetos?........................................................................................ 94
13. Referncias Bibliogrficas ............................................................................... 96

Pg. 1
FACE -FUMEC
Curso de Graduao em Cincia da Computao
Curso Superior Sequencial de Formao Especfica de Gesto de Negcios em
Telecomunicaes
Disciplina : Gerncia de Projetos
Professor : Roberto Lus Capuruo Gattoni - e-Mail: rgattoni@inet.com.br

1. Introduo Um Bom Exemplo de Projeto

Considere a execuo dos eventos de Reveillon na praia de Copacabana Rio de Janeiro,
que rene, a cada ano, cerca de 2 milhes de pessoas zero hora de 31 de dezembro:

Gerncia do trfego urbano: como tratar os desvios de trfego, a inverso de mos, a
interrupo das vias de acesso e da avenida litornea, como divulgar e sinalizar as
alteraes de trfego com a antecedncia necessria, em todos as vias de acesso
regio...;
Gerncia da segurana / policiamento: como distribuir o efetivo policial ao longo das
redondezas, ao longo da praia, como garantir a coordenao de esforos entre os diversos
destacamentos militares disponibilizados, como realizar a efetiva conteno de eventuais
arrastes e tumultos diversos...;
Gerncia do atendimento mdico imediato / hospitalar: como instalar tendas para
atendimento em termos de primeiros socorros, realizar a contratao de mdicos e
enfermeiros adequados, realizar a remoo dos casos mais graves para os hospitais mais
prximos (principalmente em relao aos corredores de fuga, a serem negociados junto
gerencia do trfego urbano)...;
Gerncia do lixo: como distribuir recipientes para o depsito de lixo a longo do evento,
como realizar a retirada dos mesmos, como realizar, de forma rpida e eficiente, a
limpeza da regio horas depois ocorrncia do evento...;
Gerncia de informaes / divulgao / sinalizao: considerar a adequada disseminao
de informaes aos turistas, aos moradores e donos de restaurantes e hotis da regio,
como repassar informaes acerca de restries relacionadas ao trfego areo, martimo e
urbano...;
Gerncia dos shows musicais / fogos de artifcio: quem contratar, como contratar, como
distribuir os diversos palcos ao longo da praia, qual ser a melhor composio de artistas,
bem como a ordem em que os mesmos faro suas apresentaes, como realizar a instalar
todo o equipamento de luz e som...

Em cada uma das questes acima, como fazer para:
Definir, com clareza e objetividade, o escopo do que se pretende?
Gerenciar o envolvimento e o comprometimento das pessoas envolvidas?
Analisar previamente todos os riscos possveis, e prever o contingenciamento efetivo
para cada um deles?
Gerenciar as comunicaes entre todos os participantes e envolvidos direta e
indiretamente?
Cuidar da aquisio de produtos e contratao de servios de terceiros?
Pg. 2
Obter alta qualidade nos produtos adquiridos e nos servios contratados?
Garantir que o projeto seja realizado estritamente dentro do prazo e do oramento
previstos?
Integrar o projeto como um todo, em todos os seus aspectos e parmetros?

Numa viso integrada do projeto acima e de todas as questes levantadas, como fazer para:
Definir o escopo geral do projeto?
Planejar o andamento integrado das atividades / custos / recursos / prazos do projeto?
Executar o projeto conforme o planejado?
Controlar a execuo do projeto conforme o planejado?
Finalizar o projeto, garantindo o aceite do mesmo, bem como o devido encerramento de
todas as atividades abertas?

Gerenciar um projeto de realizao do evento significa cuidar de todos os detalhes citados
acima, bem como todos os detalhes que ainda no so conhecidos anteriormente ao projeto, agir de
forma pr-ativa para que todas as aes sejam executadas de forma integrada e coesa e, enfim...

REALIZAR O PROJETO!!!
Pg. 3
2. Conceitos-Chave

2.1. Conceito de Projeto

Para abordarmos o tema de gerncia de projetos devemos, em primeiro lugar, definir o
conceito de projeto:

Um projeto um esforo temporrio empreendido para criar um produto ou servio nico.
Temporrio significa que todo projeto tem um incio e um trmino bem definidos. nico
significa que o produto ou servio distingue-se substancialmente de todos os produtos e
servios existentes (PMI, 2000, p. 4).

Outras definies de projeto vm a seguir:

Projeto um empreendimento no repetitivo, caracterizado por uma sequncia clara e lgica
de eventos, com incio, meio e fim, que se destina a atingir um objetivo claro e definido, sendo
conduzido por pessoas dentro de parmetros pr-definidos de tempo, custo, recursos
envolvidos e qualidade.

Projeto uma combinao de recursos organizacionais colocados juntos para criarem ou
desenvolverem algo que no existia previamente, de modo a prover um aperfeioamento da
capacidade de performance no planejamento e na realizao de estratgias organizacionais

De forma mais simplificada, projetos so esforos temporrios levados a efeito para gerar
um produto ou servio nico.

Caractersticas principais dos projetos:
Temporariedade e individualidade do produto ou servio a ser desenvolvido pelo projeto.

Outras caractersticas relevantes:
Empreendimento no repetitivo;
Envolve uma sequncia clara e lgica de eventos em seu planejamento, mas seu
desenvolvimento pode se tornar catico, uma vez que as variveis envolvidas no so
totalmente conhecidas a priori;
Objetivos claros e bem definidos;
Conduzido por pessoas;
Utiliza recursos;
Possui parmetros bem definidos: como valores bem determinados para os custos, os
materiais, os equipamentos e os prazos para cada uma de suas atividades previstas e a
serem executadas;
Raridade;
Restries: limitadores vinculados aos fatores tempo, capital e/ou recursos;
Multidisciplinaridade: requer integrao e coordenao entre pessoas e reas diversas;
Complexidade: principalmente no que tange aos aspectos de divergncia de objetivos e
da mudana tecnolgica constante.

2.2. Gerenciamento de Projetos

Aplicao do conhecimento e habilidades utilizando ferramentas e tcnicas de planejamento
e controle de atividades conforme os requisitos de um projeto.
Pg. 4

2.3. Operaes X Projetos

As operaes so trabalhos contnuos e repetitivos.

Suas semelhanas com os projetos so as seguintes:
As operaes podem ser executadas por pessoas (os projetos tem que ser executados por
pessoas);
As operaes tambm necessitam ser planejadas, executadas e controladas;
As operaes tambm objetivam-se obteno de resultados bem definidos;
As operaes tambm possuem limitaes e restries em seus recursos alocados.

Suas diferenas em relao aos projetos so as seguintes:
As operaes so repetitivas, enquanto os projetos so nicos;
As operaes so de execuo previsvel ou bem definida, enquanto os projetos possuem
conduo com propenso ao caos, pois as variveis e complexidades envolvidas nos
mesmos no so necessariamente conhecidas por completo a priori;
As operaes podem no ser executadas por pessoas, podendo ser conduzidas por
computadores ou por mquinas, por exemplo; os projetos, como j foi dito, somente
podem ser executados por pessoas;
As operaes normalmente possuem um procedimento associado que documenta seu
funcionamento, condies de erro, situaes de contorno; cada projeto, por sua vez, possui
documentao que se prope a planejar sua execuo, contudo, a mesma estar sempre
sujeita a modificaes, acertos e adequaes, dada a natureza de complexidade e de
alguma imprevisibilidade que envolve um projeto;
As operaes envolvem pouco ou quase nenhum trabalho de criao, sujeio a riscos ou
gerncia de conflitos, pois referem-se a tarefas bem definidas e conhecidas. Em certos
casos, as eventuais excees ou conflitos que possam atingir as operaes costumam ser
bem conhecidas e bem documentadas, passando a constiturem-se parte de si prprias; j
os projetos so tpicos ambientes que envolvem conflitos e riscos, e continuamente exige-
se a adoo de mecanismos e solues desenvolvidas a partir de grande dose de
criatividade por parte de seus participantes.

2.4. Exemplos de Projetos

Implantao de uma nova soluo de software em uma organizao;
Construo de uma casa;
Estudo de um acidente areo com vtimas;
Elaborao de uma tese de doutorado;
Realizao de uma viagem a um local;
Desenvolvimento de um novo sistema de informaes;
Realizao de um concurso de videok;
Desenvolvimento e implantao de um novo curso de graduao.
Pg. 5

2.5. Exemplos de No-Projetos

Manuteno rotineira de equipamentos;
Preenchimento de um formulrio;
Atendimento a clientes via telemarketing;
Realizao de vendas de passagens de nibus em um terminal rodovirio;
Configurao de um vdeo-cassete para gravar um determinado programa.

2.6. Sucesso e Fracasso em Projetos

Poderamos comear a definir um projeto de sucesso como aquele que ocorre conforme o
planejado, em termos de custo, prazo e qualidade.

Naturalmente, nem todas as partes interessadas compartilham a mesma idia do que se
constitui o sucesso de um projeto. Alguns autores consideram, por exemplo, que existem 4
dimenses para que um projeto atinja o seu pleno xito:

1> A eficincia do projeto: consiste em realizar o projeto de forma a atender ao seu
oramento e ao seu cronograma proposto. Neste caso, cabem alguns questionamentos:
caso um projeto apresente seus resultados muito antes do previsto, ou mesmo com um
custo final bem abaixo do valor orado originalmente, ser que isso no poderia trazer
inconvenientes ou mesmo perdas ao seu cliente? (Ex. Perda de produtos gerados e
insumos estocados para consumo no projeto, ou perda de capital motivada pelo aporte de
investimentos no utilizados no projeto);

2> Impacto/satisfao do cliente do projeto: esta dimenso muito complexa, pois no
somente envolve a natural conformidade s especificaes tcnicas e operacionais dos
produtos gerados pelo projeto, mas tambm inclui fatores relacionados fidelidade e
disposio do uso (ou da reaquisio) dos produtos gerados pelo projeto: atendimento s
necessidades apontadas pelo cliente, efetivo uso da soluo por parte do cliente,
resoluo de um problema considerado principal pelo cliente e o constante desafio da
prpria satisfao do cliente em relao s solues oferecidas pelo projeto.
Naturalmente, pode existir grande parcela de subjetividade na prpria avaliao de
satisfao por parte do cliente, pois podem existir representantes da organizao cliente
que considerem positivos e satisfatrios os resultados de um projeto, assim como h a
possibilidade de que outros indivduos considerem que o projeto tenha sido um
empreendimento de resultados absolutamente insatisfatrios (some-se a isso que estas
avaliaes podem variar ao longo do tempo...);

3> Sucesso direto/sucesso no negcio do cliente: esta caracterstica pode ser medida,
primariamente, em termos do nvel de sucesso comercial ou da fatia de mercado (market
share) atendida a partir dos resultados desenvolvidos pelo projeto. No caso de projetos
internos, devem ser averiguadas melhorias nas quantidades de produo alavancadas a
partir do projeto, ou na reduo de tempo dos ciclos produtivos, ou na reduo ou
otimizao dos passos de processamento, ou na melhoria da qualidade, entre outros
fatores relacionados aos processos organizacionais do cliente do projeto;
Pg. 6

4> Futuro potencial: esta dimenso, mas difcil e nebulosa de se apurar, inclui fatores
relacionados, por exemplo, ao potencial de abertura de um novo mercado a partir dos
resultados de um projeto, ou s perspectivas de desenvolvimento de uma nova linha de
produtos ou servios em funo da implementao do projeto ou, em um projeto interno,
na possibilidade de desenvolvimento de novas tecnologias, habilidades e/ou
competncias a partir da execuo do projeto.

Em uma outra abordagem, mais analtica, poderamos caracterizar o sucesso de um projeto em
termos da natureza das variveis a serem consideradas em sua mensurao, tais como:

Sucesso Tcnico: quando ocorre aderncia do projeto a quesitos mensurveis. Como
exemplos, vejamos as seguintes situaes:
Um projeto que concluiu-se dentro ou antes do prazo previsto. Neste caso, estamos
considerando que a antecipao do prazo de entrega do projeto foi benfico para a
organizao contratante do mesmo
1
;
Envolver um oramento menor ou igual ao previsto. Neste caso, considera-se que a
economia gerada pela reduo do desembolso no projeto no venha a incorrer em perdas
de capital para o contratante do projeto
2
;
Demandar menos recursos do que o previsto originalmente;
Os produtos gerados possurem qualidade ou performance igual ou superior ao previsto
originalmente.

Sucesso Organizacional: quando ocorre aderncia do projeto a quesitos no mensurveis,
mas igualmente importantes do ponto de vista do contexto envolvido. Vejamos os seguintes
exemplos:
Um projeto que ocorre com um mnimo de alteraes de escopo;
Um projeto que aceito sem restries pelo contratante ou cliente;
Um projeto que desenvolvido e implantado sem que tenha ocorrido paralizao,
interrupo ou prejuzo das atividades normais da organizao contratante;
Um projeto que no tenha agredido a cultura da organizao contratante.

Finalmente, se agregarmos todas as questes levantadas acima no intuito de chegarmos a uma
definio nica de sucesso em um projeto, poderamos chegar aos seguintes termos:

1
O fator de antecipao dos resultados de um projeto pode se revelar, em alguns casos, um estorvo. Por exemplo,
suponha que um determinado fabricante de peas se proponha a entregar, em seis meses, um volume total de 10.000
itens para uma organizao contratante, esta ltima em processo de implantao de uma fbrica, cujo prazo de trmino
da construo de seus galpes de estocagem compatvel com as datas combinadas de entrega dos itens. A antecipao
na entrega dos itens na fbrica, ainda em construo, poderia causar transtornos severos em termos da estocagem dos
mesmos, uma vez que a fbrica ainda no teria condies de abrig-los adequadamente.
2
Este um outro exemplo em que a reduo do que foi planejado originalmente pode trazer resultados perversos para o
contratante de um projeto. Por exemplo, suponha que um projeto foi orado em R$10 milhes a serem executados em
um perodo de um ano. Desta forma, a contratante provisionou, em termos de seus oramentos anuais, esta quantia para
o investimento no empreendimento. Contudo, suponha que o desembolso total do projeto tenha somado R$8 milhes ao
longo dos mesmos 12 meses de execuo. Neste caso, a diferena de R$2 milhes no empregada no projeto e
provisionada pelo contratante poderia ter sido aplicada no mercado de capitais, ou mesmo utilizada em outras
iniciativas. Ser que, a economia teoricamente gerada pelo projeto no poderia ter trazido algum prejuzo ao
contratante ao invs de benefcios?
Pg. 7

Um projeto de sucesso aquele que concludo dentro do prazo e dos custos
estabelecidos conforme planejado, e em um nvel de qualidade de seus resultados e produtos
que leve plena satisfao de seus clientes.

2.7. Fatores de Sucesso e Fracasso em Projetos

Em uma pesquisa realizada pelo Standish Group
3
, em projetos de tecnologia da informao,
chegou-se aos seguintes nmeros em relao ao sucesso e fracasso dos mesmos:

16,2% dos projetos de software iniciados so completados no prazo definido, dentro do
oramento planejado e com todas as funcionalidades como originalmente definido;

52,7% dos projetos iniciados so completados e tornados operacionais, mas excedem o
oramento, e/ou o prazo estimado e/ou oferecem menos funcionalidades e
produtos em relao ao que foi originalmente especificado;

31,3% dos projetos so cancelados em algum ponto durante seu ciclo de desenvolvimento.

Esta pesquisa apresentou os principais fatores apontados pelos executivos entrevistados que
motivaram os projetos considerados de sucesso:

Fatores dos projetos de Sucesso % de Respostas
Envolvimento do usurio 15,9%
Apoio dos executivos sniores 13,9%
Definio clara de requisitos 13,0%
Planejamento adequado 9,6%
Expectativas realistas 8,2%
Proximidade dos marcos do projeto 7,7%
Competncia da equipe 7,2%
Propriedade 5,3%
Clareza da viso e dos objetivos 2,9%
Trabalho duro, com a equipe focada 2,4%
Outros fatores 13,9%

Os participantes da pesquisa foram tambm questionados a respeito das causas que levam
um projeto a ser concludo, porm com distores no oramento e/ou no prazo e/ou nas
funcionalidades esperadas:

3
Este relatrio do Standish Group apresenta os resultados de uma pesquisa realizada em 1995, questionando executivos
sniores de empresas de Tecnologia da Informao com o intuito de identificar o escopo das causas das falhas de
projetos de software. Esta pesquisa levantou os principais fatores que levam tais projetos a falhar e os ingredientes
chave que poderiam vir a reduzir as falhas em projetos desta natureza. Maiores detalhes podem ser encontrados no site
http://standishgroup.com/visitor/chaos.htm.
Pg. 8

Fatores dos projetos Concludos com Restries % de Respostas
Falta de informaes dos usurios 12,8%
Especificaes e requisies incompletes 12,3%
Alteraes nas especificaes e requerimentos 11,8%
Falta de apoio dos executivos 7,5%
Restries da tecnologia 7,0%
Falta de recursos 6,4%
Expectativas no realistas 5,9%
Falta de clareza nos objetivos 5,3%
Estimativas de prazos no realistas 4,3%
Tecnologia muito nova 3,7%
Outros fatores 23,0%

As opinies sobre quais motivos levaram projetos a serem cancelados podem ser
sumarizadas conforme a tabela abaixo:

Fatores dos projetos Cancelados % de Respostas
Requerimentos incompletos 13,1%
Falta de envolvimento do usurio 12,4%
Falta de recursos 10,6%
Expectativas no realistas 9,9%
Falta de apoios dos executivos 9,3%
Alteraes nas especificaes e requerimentos 8,7%
Falta de planejamento 8,1%
No teremos mais necessidade disso 7,5%
Falta de gerenciamento de TI 6,2%
Falta de conhecimento da tecnologia 4,3%
Outros fatores 9,9%

Segundo a Microsoft, no seu MSF (Microsoft Solutions Framework), os projetos falham
pelos seguintes motivos:

Falta de diferenciao entre objetivo e funcionalidade: a funcionalidade deve existir
para apoiar o atingimento de um objetivo particular ou para resolver um problema tcnico
especfico. Frequentemente, a funcionalidade criada sem a compreenso do objetivo a
que serve. Como um exemplo, um projeto tem por objetivo a criao de um novo modelo
de automvel que seja barato, bonito e econmico. Neste caso, supondo que os
engenheiros insistam em tentar produzir um motor altamente eficiente mas que se utilize
de uma tecnologia de difcil implementao em larga escala, poderia-se chegar a um caso
tpico de funcionalidade atendida e ainda assim o objetivo no ter sido alcanado;

Falta de sintonia entre negcio e tecnologia: quando os objetivos de negcio e os
objetivos de tecnologia da organizao no esto alinhados, os objetivos da tecnologia
podem no suportar as necessidades de negcio demandadas. Como um exemplo,
suponhamos que os objetivos de negcio de uma organizao seja o de explorar as
necessidades de cidades do interior do pas com cerca de 100.000 habitantes. Neste caso,
Pg. 9
considere que uma deciso estratgica seria dotar os vendedores de ferramentas que lhes
dem agilidade para prospectar e contactar rapidamente os clientes potenciais nas micro-
regies de foco, bem como dar eficincia aos processos de coleta e atendimento de
pedidos. Desta forma, um fator de sucesso seria o alinhamento dos objetivos de negcio
com os de tecnologia, esta ltima devendo esmerar-se em desenvolver canais eletrnicos
para a troca de informaes entre a central e os vendedores mveis (Internet, PDAs,
notebooks, celular, construo de aplicativos especficos, sistemas de logstica mais
eficientes, etc.) para que os resultados sejam alcanados de acordo com os interesses da
organizao;

Falta de uma linguagem e um processo comuns: neste caso, resulta-se em muita
confuso e expectativas no realistas. Como um exemplo de fator para o insucesso de um
projeto, teramos o seguinte caso: considere uma fbrica em que os setores de
relacionamento com fornecedores (compras) estivessem desenvolvendo novos sistemas
para a automao da logstica de recebimento de insumos. Neste caso, se o pessoal das
usinas, do controle de estoques de materiais, de tecnologia da informao, e outros
setores, no estiverem bem coordenados e envolvidos em relao a uma viso integrada
quanto ao processo como um todo, o fracasso ser praticamente certo (s vezes, as demais
reas somente tomam conhecimento do projeto s vsperas da sua implantao!!!). Alm
disso, a utilizao de termos distintos para significar as mesmas coisas pode dificultar
ainda mais a eficcia do novo projeto. Por exemplo, a data de entrada da mercadoria a
data de entrega do produto na fbrica, ou a data em que o mesmo entra nos estoques da
empresa, ou a data em que a mesma tornada disponvel para a linha de produo? Ou os
cdigos de fornecedores esto realmente integrados em todos os sistemas da empresa,
cada um deles significando um, e exatamente um nico fornecedor? Ou a causa da no
aceitao de um material est relacionada sua incompatibilidade no processo produtivo,
ou s eventuais divergncias quanto entrega da mercadoria na chegada da mesma
empresa? Todas estas discrepncias podem trazer srios problemas organizao, pois
desconectam o novo projeto em relao a todos os seus envolvidos e participantes
necessrios;

Falhas na comunicao entre as equipes de projeto, e falhas na atuao como um
nico time: estimular as pessoas a irem alm de seu esforo pessoal e torn-las capazes de
trabalhar efetivamente como uma equipe coesa e nica crtico para o sucesso de um
projeto;

Processos organizacionais internos inflexveis: ambientes resistentes s mudanas a
serem proporcionadas pelo projeto podem inviabiliz-lo por completo. Neste caso, deve-
se verificar com cuidado os redutos de poder nas organizaes, e implementar polticas
que facilitem e ampliem a flexibilidade dos diversos setores envolvidos na implantao
dos novos projetos.

2.8. Trade-Offs do Gerenciamento de Projetos

H uma tendncia ao considerar um projeto apenas em termos das especificaes de seus
resultados, ou seja, da qualidade de seus resultados. Contudo, devem ser considerados tambm os
custos necessrios para se atingir tais resultados, bem como o adequado dimensionamento de prazos
para seu desenvolvimento. Alguns autores tambm consideram as expectativas do cliente como uma
Pg. 10
quarta dimenso do gerenciamento dos projetos. No entanto, podemos considerar que este ltimo
fator uma parte inerente das combinaes das outras 3 dimenses de um projeto.

O grfico abaixo apresenta os objetivos principais do gerenciamento de projetos, com os
objetivos especificados do projeto nos eixos. A funo resultante varia de projeto para projeto, e a
principal tarefa do gerente de projetos lidar com estes trade-offs.

Relacionamento entre os objetivos de um projeto: custo, prazo e qualidade (ou performance, no original em ingls).
Fonte: MEREDITH e MANTEL (1995, p. 4)

A obrigao principal de um gerente de projetos de manter o melhor equilbrio entre este
trio de restries, alm de atender (ou, se possvel, exceder) as expectativas dos stakeholders
4
do
projeto.

4
Stakeholders so todos aqueles que sero afetados pelos resultados de um projeto, seja direta, seja indiretamente,
sejam eles internos como externos organizao.
Pg. 11
3. Fases de um Projeto e o Ciclo de Vida de Um Projeto

3.1. Subdivindo os Projetos

O ciclo de vida de um projeto pode compreender fases. Uma fase de um projeto pode ser
definida como uma etapa a ser executada. Cada uma delas caracterizada pela entrega ou
finalizao de produtos, trabalhos ou resultados, que devem ser tangveis e de fcil
identificao. A concluso de uma fase geralmente marcada pela reviso dos principais
subprodutos e pela avaliao do desempenho do projeto tendo em vista:
A> Determinar se o projeto deve continuar na sua prxima fase, e;
B> Detectar e corrigir eventuais erros a um custo aceitvel.

O ciclo de vida do projeto serve para definir o incio e o fim de um projeto. A definio do
ciclo de vida do projeto tambm determina os procedimentos de transio para o ambiente de
operao que sero includos ao final do projeto, distinguindo-os dos que no sero. Desta forma, o
ciclo de vida do projeto pode ser usado para ligar o projeto aos processos operacionais
contnuos da organizao executora.

Os subprodutos oriundos de uma fase normalmente so aprovados antes do incio da
prxima fase. Entretanto, quando os riscos so considerados aceitveis, a fase subsequente pode
iniciar antes da aprovao dos subprodutos da fase precedente.

As descries do ciclo de vida de projeto podem ser genricas ou detalhadas. Descries
muito detalhadas podem conter uma srie de formulrios, diagramas e checklists para prover
estrutura e consistncia. Estas abordagens detalhadas so freqentemente chamadas de
metodologias de gerncia de projeto.

Os programas so grupos de projetos administrados com as mesmas tcnicas, de modo
coordenado. Como exemplos, podemos citar o Programa Espacial Norte-Americano, ou o Programa
Fome Zero, cada um deles composto de diversos projetos, com gesto prpria, coordenados por
comits centrais

Subprojetos, dentro de projetos, podem ter ciclos de vida separados, cada um deles
constituindo-se como um projeto em si mesmo, com um gerente de projeto exclusivo, que se reporta
a um gerente de projeto com responsabilidade sobre diversas reas, que, por sua vez, se reporta a
um gerente responsvel pelo programa inteiro. Por exemplo, uma empresa de arquitetura contratada
para projetar um novo prdio de escritrios poder estar inicialmente envolvida com um subprojeto
relacionado s definies do contratante (ao qual chamaremos, neste exemplo, Subprojeto de
Anlise de Viabilidade). Quando esta empresa estiver fornecendo suporte construo, estar
tambm envolvida no Subprojeto de Construo. O Subprojeto de Anlise de Viabilidade poderia
ser dividido em diversas fases, entre elas, a fase de Elaborao do Design Arquitetnico. Esta
fase, por sua vez, poder possuir sua prpria configurao de sub-fases como, por exemplo, as sub-
fases Especificao Conceitual, Definio dos Planos de Trabalho, Desenho das Pranchas,
Construo de Maquetes, Apresentao ao cliente, Reviso Final e, enfim, Entrega e
Encerramento.

O diagrama a seguir ilustra o exemplo de subdiviso de um projeto em sub-projetos, fases e
sub-fases:
Pg. 12

3.2. Fases Genricas do Ciclo de Vida de um Projeto

Genericamente, podemos considerar as seguintes fases de um ciclo de vida de um projeto:

Concepo: os objetivos tcnicos do projeto devem ser especificados a um nvel que
permita o planejamento detalhado do estgio seguinte, de Planejamento; deve haver o
comprometimento dos recursos necessrios para o projeto tanto por parte do apoio dos
executivos sniores quanto por parte dos gerentes funcionais; a prioridade do projeto,
em relao s prioridades de outros projetos da organizao, devem ser estabelecidas e
comunicadas; a estrutura organizacional do projeto deve ser estabelecida de forma a
cruzar as responsabilidades com as macro-tarefas previstas, sendo uma premissa para a
conduo das fases seguintes;

Planejamento: esta a fase onde o projeto altera-se de um conceito geral para um
conjunto de planos altamente detalhados; deve haver o comprometimento dos
gerentes funcionais para a correta alocao dos recursos sob sua responsabilidade para a
execuo de tarefas previstas para o projeto;

Implementao: uma vez que os planos de projeto j foram desenvolvidos e aprovados
por todos os envolvidos, o trabalho efetivo toma parte nesta fase; o controle do projeto
um dos principais desafios do gerente do projeto nesta fase;

Encerramento: concluso dos trabalhos do pessoal envolvido, com a entrega dos
produtos e servios finais do projeto, a finalizao dos documentos abertos durante o
projeto, o encerramento dos contratos firmados junto aos parceiros e fornecedores e o
aceite final do cliente do projeto.

Projeto Nova Casa
Sub-Fase:
Especificao Conceitual
Sub-Fase:
Definio dos Planos de Trabalho
Sub-Fase:
Desenho das Pranchas
Sub-Fase:
Construo de Maquetes
Sub-Fase:
Apresentao ao Cliente
Sub-Fase:
Reviso Final
Fase: Elaborao do
Design Arquitetnico
Fase:
Estudo da Viabilidade Financeira
Outras Fases (...)
Subprojeto
Anlise de Viabilidade
Subprojeto
Construo
Outros
Subprojetos (...)
Pg. 13
No PMBOK encontram-se diversos exemplos de ciclos de vida de projetos, como projetos
de construo civil, desenvolvimento de software, da indstria farmacutica e do estabelecimento
de uma infra-estrutura de defesa militar.

3.3. Comportamento Genrico de um Projeto ao Longo do Ciclo de Vida

A maioria das descries do ciclo de vida de projeto apresentam algumas caractersticas em
comum:

O custo e a quantidade de pessoas integrantes da equipe so baixos no incio do
projeto, sofre incrementos no decorrer do mesmo e se reduzem drasticamente quando seu
trmino vislumbrado;

Como pode ser verificado no grfico acima, quando os recursos e custos so alocados a
um projeto bem como quando os mesmos so desalocados, um aspecto crtico a
qualidade da gerncia sobre os mesmos. Rapidamente um projeto ganha recursos ao
longo do tempo e tambm rapidamente o projeto os perde. Alm disso, quando os custos
e recursos encontram uma estabilidade em termos de alocao, o gerente de projetos deve
preparar-se para perd-los, no esperando utilizar-se dos mesmos por tempo
indeterminado.

A probabilidade de terminar um projeto com sucesso baixa no incio e o risco e a
incerteza so altos. Normalmente a probabilidade de sucesso vai aumentando medida
que o projeto caminha em direo ao seu trmino;
Eixo X
C
u
s
t
o

/

Q
t
d

d
e

P
e
s
s
o
a
s
E
n
v
o
l
v
i
d
a
s
Ciclo de Vida do Projeto
Preparar-se para a
desalocao de recursos
Aspecto crtico: uma boa seleo
/ gerenciamento de recursos
Pg. 14

Como o grfico acima demonstra, em determinado momento do projeto, a curva de
probabilidade de sucesso cresce muito rpido. Neste momento, os nveis de aprendizado
da equipe de projeto ampliam-se fortemente, capacitando-os para o cumprimento final do
mesmo. Alm disso, se observarmos o grau de aumento de probabilidade de sucesso no
mesmo perodo, fortalece-se a argumentao para que o comprometimento das reas e
executivos envolvidos sejam mantidos em alta.

A capacidade das partes envolvidas de influenciar as caractersticas finais do
produto do projeto e o seu custo final, alta no incio e vai se reduzindo com o
andamento do projeto. Isto acontece, principalmente, porque o custo de mudanas e
correo de erros geralmente aumenta medida que o projeto se desenvolve.

Tempo
P
r
o
b
a
b
i
l
i
d
a
d
e
d
e

S
u
c
e
s
s
o
Grande aprendizado
da equipe do projeto
Forte argumentao para venda do
projeto de forma a manter a continuidade do
apoio dos executivos e das reas envolvidas
Tempo
C
a
p
a
c
i
d
a
d
e

d
e

i
n
f
l
u
n
c
i
a

n
o
s
r
e
s
u
l
t
a
d
o
s

e

n
o

c
u
s
t
o

f
i
n
a
l
Intensificar o entendimento
das definies do usurio / cliente
(Ex. Prottipos, Simulaes)
Tempo
C
a
p
a
c
i
d
a
d
e

d
e

i
n
f
l
u
n
c
i
a

n
o
s
r
e
s
u
l
t
a
d
o
s

e

n
o

c
u
s
t
o

f
i
n
a
l
Intensificar o entendimento
das definies do usurio / cliente
(Ex. Prottipos, Simulaes)
Pg. 15

Uma vez que as alteraes no incio do projeto so menos complexas e, em consequncia,
menos dispendiosas, deve-se intensificar o entendimento das expectativas dos usurios ou
clientes do projeto. Ferramentas como prottipos ou simulaes podem ser empregados
para que o mesmo nvel de entendimento seja obtido entre todas as partes envolvidas.

A oportunidade e o risco envolvidos geralmente mantm-se relativamente altos no
incio do projeto, ao passo que as quantidades arriscadas so menores no incio e
aumentam medida que um projeto evolui. Isso significa que o perodo de maior
impacto do risco ocorre quando ambas estas variveis chegam ao seu ponto de encontro.

O grfico a seguir apresenta uma relao entre o estado de finalizao do projeto ao longo
do tempo. Note como no incio do projeto o progresso lento, no decorrer do projeto rapidamente
se atingem resultados e, ao aproximar-se do fim, o projeto mais lento para concluir-se:

Relao entre a parte concluda de um projeto ao longo do tempo Fonte: MEREDITH e MANTEL (1995, p. 14)
Tempo
R
i
s
c
o

X
Q
t
d
.

A
r
r
i
s
c
a
d
a
Risco ou
Oportunidade
Qtd. Arriscada
Perodo de
maior impacto
dos riscos
Pg. 16

O grfico a seguir apresenta a distribuio do esforo em projetos ao longo de seu ciclo de
vida:

Distribuio do esforo em um projeto ao longo do tempo Fonte: MEREDITH e MANTEL (1995, p. 14)

Observe como o esforo dispendido nas fases iniciais mnimo (quando o conceito do
projeto est sendo desenvolvido), bem como no trmino, quando h os processos de avaliao e
concluso do projeto. Ressaltamos que se for utilizado mais esforo nas fases iniciais do projeto
suas chances de sucesso crescem significativamente.

essencial para o gerente de projetos compreender as caractersticas da curva do ciclo de
vida do projeto sob sua responsabilidade. As distines entre os diversos ciclos de vida assumem
um papel crtico no desenvolvimento de oramentos e cronogramas para o projeto.

3.4. Importncia Relativa dos Objetivos do Projeto quanto ao Ciclo de Vida

A sabedoria convencional, de forma errnea, aponta os objetivos dos projetos em funo
de seus estgios da seguinte forma:
No incio do projeto, quando o mesmo est sendo planejado, a qualidade apontada
como o item mais importante, e os demais deveriam ser sacrificados em seu favor;
Em seguida fase de planejamento, ou seja, durante a sua execuo, o custo tomaria
precedncia em relao s demais variveis, devido ao fato que o projeto toma corpo,
cresce e opera em picos de atividade, demandando, para isso, dispndio financeiro;
Finalmente, quando o projeto aproxima-se do encerramento, o cronograma passa a ser
visto como o objetivo principal, enquanto os demais sofrem.

Como citado, a crena apontada acima no considerada verdadeira.

A tabela a seguir aponta a importncia relativa entre os objetivos de um projeto em cada
uma das fases do ciclo de vida genrico considerado:
Pg. 17

Como pode ser verificado, no estgio de Concepo no h uma diferena significativa
entre cada um dos trs objetivos do projeto. Isso ocorre devido premissa de que o projeto deve
ser concebido para atingir a todas as expectativas do cliente, ou seja, aos trs objetivos. Se
condies especficas devem ser assumidas, cada um dos trs objetivos deve ser considerado
vulnervel. Contudo, caso algum objetivo assuma uma importncia maior nesta fase, o candidato
natural o objetivo Qualidade, uma vez que o cliente pode desejar alcanar nveis de resultados
superiores ao vislumbrado previamente.

Na fase de Planejamento, o Prazo o objetivo dominante, sendo significativamente mais
importante que a Qualidade, que por sua vez mais importante que o Custo. A isso se explica
devido ao fato que os principais comprometimentos quanto a prazos se fazem justamente no
detalhamento dos planos de execuo, produzidos neste estgio. Em funo dos prazos assumidos,
estabelecem-se compromissos em relao apresentao de verses, ou mdulos, dos produtos a
serem gerados ao longo do projeto (Qualidade), de forma que novas verses vo sempre
acrescentando novas funcionalidades s j existentes. Isso se justifica de forma a quebrar as
expectativas dos clientes do projeto, oferecendo-lhes resultados intermedirios ao longo do tempo
de execuo do mesmo.

Na fase de Implementao, tanto o Prazo quanto a Qualidade so os objetivos mais
preocupantes, sendo ambos mais importantes que o Custo. Neste sentido, busca-se sempre atingir os
resultados (Qualidade) apresentados na fase de Planejamento dentro dos Prazos originalmente
previstos. Quanto ao Prazo, para que o mesmo seja obedecido, muitas vezes podem ser requeridos
recursos extras (o que pode aumentar os custos) ou que se faam restries s especificaes
tcnicas dos produtos finais (o que pode prejudicar a Qualidade). Cada uma destas decises pode
no se justificar em grande parte dos casos, devido restries de ordem contratual, tica ou de
poltica da companhia. Quanto Qualidade, medida que o projeto evolui passa a existir uma
grande quantidade de interfaces entre os componentes da soluo, aumentando enormemente a
complexidade dos resultados esperados. Neste caso, como h uma grande preocupao com a
devida integrao dos diversos componentes da soluo projetada, o objetivo Qualidade
considerado to significativo quanto o Prazo. O controle do projeto nesta fase exercido,
principalmente, sobre estes dois objetivos, o que no significa que o fator Custo no merea a
ateno devida.

Na fase de Encerramento, a Qualidade mais significativa que o Prazo, que por sua vez
mais significativa que o Custo. Durante esta fase, todos os envolvidos investem grande esforo
para executar o que for necessrio para concluir as especificaes dos produtos a serem gerados
Estgio do Ciclo de Vida Custo Prazo Qualidade
Concepo 1 1 1
Planejamento 3 1 2
Implementao 3 1 1
Encerramento 3 2 1
OBS. 1 = mais importante
Importncia relativa dos objetivos de um projeto durante os diferentes estgios de seu ciclo de vida genrico
Fonte: MEREDITH e MANTEL (1995, p. 101)
Pg. 18
pelo projeto (Qualidade), objetivando-se completar o projeto mesmo que com algum atraso
tolervel. Neste caso, excees podem ser verificadas em projetos com datas-limite muito rgidas.
At mesmo alguns desvios nos Custos, desde que no muito altos, so tolerados, desde que
favoream a concluso do projeto dentro da Qualidade aceitvel, e dentro de Prazos finais no
muito postergados. Problemas tcnicos so relativamente raros nesta fase, uma vez que a maioria
dos mesmos muito provavelmente j teriam sido resolvidos nas fases anteriores.

Pg. 19
4. O Gerente de Projetos

Responsvel por planejar, conduzir, controlar e finalizar um projeto, um gerente de projetos
deve possuir habilidades especficas para um bom gerenciamento de projetos. As seguintes
habilidades gerenciais-chave aplicam-se no somente para um gerente de projetos, mas para os
diversos indivduos participantes nos mesmos, quais sejam:

1> Comunicao: troca de informaes com eficincia e eficcia, e tanto nas funes de
emissor quanto de receptor, de forma clara, no ambgua e completa, e sob as diversas
dimenses comunicacionais disponveis (escrita e oral, interna/externa ao
projeto/organizao/inter-organizao, formal/informal, vertical/horizontal, entre outras).
De todas as habilidades necessrias a um gerente de projetos, esta sem dvida a mais
importante de todas, principalmente devido ao fato que um gerente de projetos investe
cerca de 90% de seu tempo em atividades de comunicao, atravs de reunies de status,
de equipe, e-Mail, comunicaes verbais e outras atividades. As comunicaes escrita e
oral so o alicerce de todo projeto bem sucedido;

2> Liderana: atravs do estabelecimento de direes voltadas para objetivos, metas ou
vises comuns, do alinhamento dos demais participantes em funo da viso comum
estabelecida, da motivao e inspirao a ser energizada nos membros das equipes de
projeto de forma a suplantar os eventuais obstculos de ordem poltica, burocrtica e de
recursos por vir;

3> Negociao: a capacidade de negociar com outros de forma a chegar a acordos benficos
aos objetivos dos projeto, e no que tange aos aspectos de escopo, custo, cronograma,
mudanas, termos e condies contratuais, atribuies e responsabilidades, alocao de
recursos, por exemplo. No caso de conflitos, tcnicas de negociao podem ser utilizadas
para san-los e, no caso de dvidas, tais conflitos devem ser sempre resolvidos
preferencialmente a favor do cliente;

4> Resoluo de problemas: refere-se a uma combinao de definio de problemas e
tomada de decises. No primeiro caso, a definio de um problema requer a distino
entre causas e sintomas, e os problemas podem ser de ordem interna ou externa,
tcnicos, gerenciais ou inter-pessoais, entre outros. A tomada de decises inclui a anlise
do problema para identificar as solues viveis, e posteriormente fazer uma escolha
dentre elas. Uma vez feita a escolha, as decises devem ser implementadas. H que se
observar, neste caso, que uma deciso certa pode no ser a melhor deciso tcnica, dadas
as restries de prazos, por exemplo;

5> Influncia na organizao: refere-se habilidade de efetivamente realizar coisas. Para
isso, necessrio o conhecimento das estruturas formais e informais da organizao
como as esferas culturais, de poder e da poltica interna da organizao. Tambm deve
levar em considerao as relaes entre clientes, parceiros, fornecedores e concorrentes,
como os fluxos de informao esto estruturados internamente, e suas interfaces com as
entidades externas organizao.

Outras habilidades pessoais e inter-pessoais: honestidade, integridade, lealdade, auto-
motivao, pr-atividade, auto-confiana, estabilidade emocional, maturidade, tolerncia,
Pg. 20
flexibilidade, entre outras no menos importantes.

Uma proposta de trabalho voltada para a gerncia de projetos deve considerar que, de uma
maneira geral, o lder de projetos conduza as seguintes atividades:

Junto ao cliente, contratante do projeto, estabelecer as principais iniciativas a serem
desenvolvidas em termos das solues a serem desenvolvidas, e dar incio ao seu
planejamento e execuo, considerando parmetros bem definidos de custos, prazos,
recursos e nveis de qualidade a serem atendidos;
Relacionamento do gerente de projetos com o cliente/contratante estgio de definio e priorizao do Projeto

Junto ao pessoal tcnico e administrativo, ttico e operacional da instituio, bem como
junto aos parceiros e clientes, envolver os principais atores institucionais ligados s
solues demandadas, obtendo deles participao e comprometimento para o
desenvolvimento das mesmas;
Relacionamento do gerente de projetos com o pessoal interno da organizao
Cliente do
Pro]eto
Gerente de
Pro]etos
Define e
Prioriza
Pro]etos
Cliente do
Pro]eto
Gerente de
Pro]etos
Gerente de
Pro]etos
Define e
Prioriza
Pro]etos
Corpo Tcnico
Pessoal
Administrativo
Clientes
e Parceiros
Gerente de
Pro]etos
Apiam e se
Comprometem
Corpo Tcnico
Pessoal
Administrativo
Clientes
e Parceiros
Corpo Tcnico Corpo Tcnico
Pessoal
Administrativo
Pessoal
Administrativo
Clientes
e Parceiros
Clientes
e Parceiros
Gerente de
Pro]etos
Gerente de
Pro]etos
Apiam e se
Comprometem
Pg. 21

Junto aos eventuais fornecedores e parceiros de mercado, avaliar e selecionar as solues
que melhor se enquadrem ao contexto da instituio, e negociar as melhores condies
para a adoo das escolhas a serem efetivadas;

Relacionamento do gerente de projetos com parceiros e fornecedores do mercado

No decorrer e ao trmino do projeto, dar conhecimento ao corpo executivo da empresa
quanto ao desenvolvimento das tarefas e atividades, no nvel de detalhamento,
frequncia e relevncia adequados aos escales gerenciais e estratgicos da organizao.

Relacionamento do gerente de projetos com o cliente estgios de execuo e finalizao do Projeto
Fornecedores
8olues do
Mercado
Gerente de
Pro]etos
Avalia e
8eleciona
8o Oferecidas
Por...
Fornecedores Fornecedores
8olues do
Mercado
8olues do
Mercado
Gerente de
Pro]etos
Gerente de
Pro]etos
Avalia e
8eleciona
8o Oferecidas
Por...
Cliente do
Pro]eto
Gerente de
Pro]etos
mplementa
e Participa
Cliente do
Pro]eto
Gerente de
Pro]etos
Gerente de
Pro]etos
mplementa
e Participa
Pg. 22

Desta forma, e tendo a viso completa do ciclo de conduo geral de um projeto, teramos a
seguinte configurao de relacionamentos entre os atores institucionais envolvidos em sua
iniciao, planejamento, desenvolvimento, controle e finalizao:

Viso integrada dos relacionamentos entre os atores institucionais envolvidos em um Projeto

Note o papel integrador do gerente de projetos, no somente realizando a troca de
informaes entre todos os envolvidos, mas sobretudo garantindo a realizao do empreendimento.

Cliente do
Pro]eto
Corpo Tcnico
Pessoal
Administrativo
Clientes
e Parceiros
Fornecedores
8olues do
Mercado
Gerente de
Pro]etos
Define e
Prioriza
Pro]etos
Apiam e se
Comprometem
Avalia e
8eleciona
mplementa
e Participa
8o Oferecidas
Por...
Cliente do
Pro]eto
Corpo Tcnico
Pessoal
Administrativo
Clientes
e Parceiros
Corpo Tcnico Corpo Tcnico
Pessoal
Administrativo
Pessoal
Administrativo
Clientes
e Parceiros
Clientes
e Parceiros
Fornecedores Fornecedores
8olues do
Mercado
8olues do
Mercado
Gerente de
Pro]etos
Gerente de
Pro]etos
Define e
Prioriza
Pro]etos
Apiam e se
Comprometem
Avalia e
8eleciona
mplementa
e Participa
8o Oferecidas
Por...
Pg. 23
5. A Proposta do PMI para o Gerenciamento de Projetos

O PMI (Project Management Institute) uma instituio fundada em 1969 com o objetivo
explcito de fomentar as melhores prticas em gerenciamento de projetos em todo o mundo, Este
instituto tido como um desenvolvedor de padres do American National Standards Institute
(ANSI), alm de ser a primeira organizao a ter o seu programa de certificao PMP (Project
Management Professional) reconhecido pela International Standards Organization (ISO).

O PMI conta com uma associao mundial de cerca de 90.000 membros de 125 pases
5
. As
sees ou captulos locais do PMI se renem periodicamente e permitem que os gerentes de projeto
troquem informaes e conheam novas ferramentas e tcnicas de gerenciamento de projetos ou
novas formas de utilizar as tcnicas existentes.

O PMI lder em prticas de gerenciamento de projetos, sendo a organizao e certificao
mais conhecida no setor. O PMI empenha-se em manter e promover padres e normas de conduta
tica neste campo e oferece outras publicaes, treinamentos, seminrios, reunies, grupos de
interesse especiais e faculdades para avanar na disciplina de gerenciamento de projetos.

O Guide to the PMBOK Guide (Guide to the Project Management Body of Knowledge)
estabelece uma estrutura, um arcabouo de conhecimentos que cobre todos os processos e as reas
de conhecimento relacionadas ao gerenciamento de projetos. O Guide to the PMBOK considera que
os projetos so compostos por 5 grupos de processos, e cada processo destes grupos est
relacionado a uma das 9 reas de conhecimento do gerenciamento de projetos. Este captulo tratar
de apresentar este framework proposto pelo PMI para a concepo, o planejamento, a execuo, o
controle e o encerramento dos projetos sob sua responsabilidade.

5.1. Os Grupos de Processos de um Projeto

Os projetos so compostos de processos. Um processo uma srie de aes que geram um
resultado. Os processos dos projetos so realizados por pessoas, esto inter-relacionados e
dependem uns dos outros. Os processos do gerenciamento de projetos normalmente se enquadram
em uma das duas categorias:

Processos orientado ao produto relacionam-se com a especificao e a criao do
produto do projeto. Os processos orientados ao produto so definidos pelo ciclo de
vida do projeto e variam de acordo com a rea de aplicao. Por exemplo, em projetos
de construo civil, h processos especficos da rea como, por exemplo, a instalao de
equipamentos, a terraplanagem, ou a desmobilizao da obra, entre outros;

Processos da gerncia de projetos relacionam-se com a descrio, a organizao e a
concluso do trabalho do projeto. Este processos so genricos, ou seja, aplicam-se a todo
e qualquer tipo de projeto.

Existe uma interao e uma sobreposio entre os processos da gerncia de projetos e os
processos orientados a produto, durante todo o projeto. Por exemplo, o escopo do projeto no pode

5
Dados de 2003.
Pg. 24
ser definido sem algum conhecimento bsico de como o produto deve ser criado.

Naturalmente, estaremos tratando dos processos de gerncia de projetos, uma vez que os
mesmos sero aplicados a quaisquer tipos de projetos. Os processos de gerncia de projetos podem
ser organizados em cinco grupos, cada um deles contendo um ou mais processos, conforme mostra
a ilustrao abaixo:

1> Processos de Iniciao: so os processos iniciais de um projeto, que tratam da
identificao da necessidade a ser atendida pelo mesmo e a consequente estruturao
do projeto em termos de um problema a ser resolvido por ele. Neste momento define-se
a misso e os objetivos do projeto;

2> Processos de Planejamento: responsveis por identificar e selecionar as melhores
estratgias para que um projeto seja abordado adequadamente. Nestes processos so
definidas as etapas e atividades especficas de um projeto bem como suas inter-
relaes e sua distribuio ao longo do tempo (os cronogramas), alm de serem
dimensionados os recursos necessariamente correspondentes, os custos, os produtos de
cada etapa bem como os demais parmetros que permitam uma execuo com um
mnimo de dificuldades e imprevistos;

3> Processos de Execuo: so os processos que coordenam a implementao do que foi
planejado, demandando grande parte do esforo e do oramento do projeto;

4> Processos de Controle: paralelamente aos processos de planejamento e execuo do
projeto, objetivam o acompanhamento e controle das tarefas previstas em relao ao
que est sendo executado efetivamente, de forma a permitir aes corretivas e
preventivas, almejando a eliminao ou minimizao dos impactos a serem causados
por anormalidades eventuais, muitas vezes no previstas;

5> Processos de Finalizao: tratam do encerramento do projeto, considerando o aceite
final dos produtos e servios gerados pelo projeto, a finalizao da documentao do
Processos
de Iniciao
Processos
de Iniciao
Processos de
Planejamento
Processos de
Planejamento
Processos
de Execuo
Processos
de Execuo
Processos
de Controle
Processos
de Controle
Processos de
Finalizao
Processos de
Finalizao
Ligaes entre os grupos de processos em cada fase
(as setas representam fluxos de informao) - Fonte: PMBOK (2000)
Processos
de Iniciao
Processos
de Iniciao
Processos de
Planejamento
Processos de
Planejamento
Processos
de Execuo
Processos
de Execuo
Processos
de Controle
Processos
de Controle
Processos de
Finalizao
Processos de
Finalizao
Ligaes entre os grupos de processos em cada fase
(as setas representam fluxos de informao) - Fonte: PMBOK (2000)
Pg. 25
projeto e a avaliao dos trabalhos realizados, bem como discusses sobre aspectos
positivos e negativos encontrados no decorrer do projeto (lies aprendidas).

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.

Alm disso, os grupos de processos da gerncia de projetos no so separados ou
descontnuos, nem acontecem uma nica vez durante todo o projeto; eles so formados por
atividades que se sobrepem, ocorrendo em intensidades variveis ao longo de cada fase do projeto.
A figura abaixo ilustra como os grupos de processos se sobrepem e variam dentro de uma fase:

A figura a seguir apresenta a relao entre as fases genricas de um Projeto (ou as sub-fases
de uma fase de projeto) e os nveis de atividade dos grupos de processos ao longo do mesmo:

Trmino da
Fase / Projeto
Tempo
Nvel de
Atividade
Processos de
Iniciao
Processos de
Planejamento
Processos
de Execuo
Processos
de Controle
Processos de
Finalizao
Sobreposio de grupos de processos em uma fase / projeto
Fonte: PMI, 2000
Incio da
Fase / Projeto
Trmino da
Fase / Projeto
Tempo
Nvel de
Atividade
Processos de
Iniciao
Processos de
Planejamento
Processos
de Execuo
Processos
de Controle
Processos de
Finalizao
Sobreposio de grupos de processos em uma fase / projeto
Fonte: PMI, 2000
Incio da
Fase / Projeto
Nvel de
Atividade
Processos de
Iniciao
Processos de
Planejamento
Processos
de Execuo
Processos
de Controle
Processos de
Finalizao
Relacionamento entre as fases genricas de um projeto e os grupos de processos
Fonte: Roberto L. C. Gattoni
Concepo Planejamento Implementao Encerramento
Nvel de
Atividade
Processos de
Iniciao
Processos de
Planejamento
Processos
de Execuo
Processos
de Controle
Processos de
Finalizao
Relacionamento entre as fases genricas de um projeto e os grupos de processos
Fonte: Roberto L. C. Gattoni
Concepo Planejamento Implementao Encerramento
Pg. 26
As interaes entre os grupos tambm atravessam as fases, de tal forma que o encerramento
de uma fase fornece uma entrada para o incio da prxima. A figura abaixo ilustra como esta
interao pode ocorrer:

5.2. reas de Conhecimento do Gerenciamento de Projetos

De acordo com o PMI (2000), h diversas reas de conhecimento ou de atuao gerencial na
gesto de projetos. Neste caso, cada uma das reas de conhecimento esto definidas em termos de
processos, e cada um de seus processos inserem-se em cada uma das fases (ou grupos de processos)
descrita acima, conforme apropriado. Vejamos quais so as reas de conhecimento gerencial de
cada projeto:

1> Gerncia de integrao: inclui os processos necessrios para a coordenao dos diversos
elementos de um projeto. Aplica-se ao desenvolvimento do Plano de Ao como
execuo e controle de alteraes do projeto;

2> Gerncia de escopo: considera os processos necessrios para assegurar que o projeto
inclui todo o trabalho necessrio e somente ele, de forma a permitir sua execuo e
concluso com sucesso. Engloba tanto a definio do escopo quanto de seu controle ao
longo da execuo do projeto;

3> Gerncia do tempo: incorpora os processos necessrios para a garantia de planejamento
e execuo do projeto dentro dos prazos previstos. Considera o levantamento das
atividades, o agendamento das mesmas ao longo do tempo e de seu controle;

4> Gerncia de custos: estabelece os processos necessrios para assegurar que o projeto seja
desenvolvido dentro dos oramentos estipulados originalmente. Considera o
planejamento de recursos, as suas respectivas estimativas de custos, a confeco do
oramento do projeto e o controle de seus custos;

Interao entre fases
Fonte: PMBOK (1996)
Processos
de Iniciao
Processos
de Iniciao
Processos de
Planejamento
Processos de
Planejamento
Processos
de Execuo
Processos
de Execuo
Processos
de Controle
Processos
de Controle
Processos de
Finalizao
Processos de
Finalizao
Fase de Design
Processos
de Iniciao
Processos
de Iniciao
Processos de
Planejamento
Processos de
Planejamento
Processos
de Execuo
Processos
de Execuo
Processos
de Controle
Processos
de Controle
Processos de
Finalizao
Processos de
Finalizao
Fase de Implementao
Fases
Subsequentes
Fases
Anteriores
Pg. 27
5> Gerncia da qualidade: inclui os processos necessrios para assegurar que os produtos e
servios do projeto atinjam os padres de qualidade segundo os quais o projeto foi
concebido. Envolve tanto o planejamento quanto a garantia e controle da qualidade;

6> Gerncia de recursos humanos: considera os processos necessrios para assegurar o
melhor emprego do pessoal envolvido no projeto. Engloba o planejamento
organizacional, a formao e o desenvolvimento da equipe do projeto;

7> Gerncia de comunicaes: incorpora os processos necessrios para assegurar o
adequado planejamento, gerao, armazenamento e disseminao de informaes
do projeto;

8> Gerncia de riscos: estabelece os processos relacionados com a identificao,
quantificao e anlise de riscos do projeto, bem como o estabelecimento das contra-
medidas a serem tomadas quando da ocorrncia de cada um dos fatores de risco
levantados;

9> Gerncia de suprimentos e contratao: envolve os processos necessrios para a
aquisio de bens e servios de fora da organizao, no que tange a parceiros e
fornecedores de insumos para o projeto. Considera o plano de compras (tanto de bens
como de servios), o levantamento de potenciais fornecedores, a licitao,
contratao e gesto e fechamento de contratos.

Pg. 28
5.3. Relao entre Grupos de Processos e reas de Conhecimento

Iniciao Planejamento Execuo Controle Encerramento
Escopo
5.1> Iniciao 5.2> Planejamento do Escopo
5.3> Detalhamento do Escopo
5.4> Verificao do
Escopo
5.5> Controle de
Mudanas do Escopo

Tempo
6.1> Definio das Atividades
6.2> Sequenciamento das
Atividades
6.3> Estimativa de Durao
das Atividades
6.4> Desenvolvimento do
Cronograma
6.5> Controle do
Cronograna

Custo
7.1> Planejamento dos
Recursos
7.2> Estimativa de Custos
7.3> Oramento de Custos
7.4> Controle de Custos
Integrao
4.1> Desenvolvimento do
Plano do Projeto
4.2> Execuo do Plano
do Projeto
4.3> Controle Integrado
de Mudanas

Comunicaes
10.1> Planejamento das
Comunicaes
10.2> Distribuio das
Informaes
10.3> Relato de
Desempenho
10.4> Encerramento
Administrativo
Suprimentos e
Contrataes
Aquisies
Solicitaes
12.3> Solicitaes
12.4> Seleo dos
Fornecedores
12.5> Administrao
dos Contratos
12.6> Encerramento
dos Contratos
Recursos
Humanos
9.1> Planejamento
Organizacional
9.2> Composio da Equipe
9.3> Desenvolvimento
da Equipe

Qualidade
8.1> Planejamento da
Qualidade
8.2> Garantia da
Qualidade
8.3> Controle da
Qualidade

Riscos
11.1> Planejamento da
Gerncia dos Riscos
11.2> Identificao dos Riscos
11.3> Qualificao dos Riscos
11.4> Quantificao dos
Riscos
Respostas aos Riscos
11.6> Controle e
Monitoramento dos
Riscos

OBS. O nmero ao lado de cada um dos processos a referncia seo correspondente no PMBOK 2000.

Pg. 29

Pg. 30
Segue uma breve descrio de cada um dos processos, segundo o PMBOK (2000):

Processos de Iniciao
Iniciao (5.1) obteno do comprometimento da organizao para o incio da prxima fase do
projeto;

Processos de Planejamento
Processos Essenciais Alguns dos processos de planejamento tm dependncias bem definidas, que
fazem com que sejam executados essencialmente na mesma ordem na maioria dos projetos. Por
exemplo, as atividades devem ser definidas antes do estabelecimento do cronograma e das
estimativas de custo. Estes processos essenciais de planejamento podem interagir vrias vezes
durante qualquer fase de um projeto. Eles incluem:
Planejamento do Escopo (5.2) desenvolvimento de uma declarao escrita do escopo, como
base para futuras decises no projeto;
Detalhamento do Escopo (5.3) subdiviso dos principais subprodutos do projeto em
componentes menores e mais gerenciveis;
Definio das Atividades (6.1) identificao das atividades especficas que devem ser realizadas
para produzir os diversos subprodutos do projeto;
Sequenciamento das Atividades (6.2) identificao e documentao das dependncias entre as
atividades do projeto;
Estimativa da Durao das Atividades (6.3) estimativa do nmero de perodos de trabalho
(prazos) que sero necessrios para completar as atividades individuais do projeto;
Desenvolvimento do Cronograma (6.4) criao do cronograma do projeto a partir da anlise da
seqncia das atividades, de suas duraes, e das necessidades de recursos a serem alocados em
cada uma delas;
Planejamento da Gerncia de Riscos (11.1) Deciso de como abordar e planejar a gerncia de
riscos no projeto;
Planejamento dos Recursos (7.1) determinao de quais e quantos recursos (pessoas,
equipamentos, materiais, etc.) devem ser utilizados para a realizao das atividades do projeto;
Estimativa dos Custos (7.2) desenvolvimento de uma aproximao (estimativa) dos custos dos
recursos que sero necessrios para completar as atividades previstas para o projeto;
Oramento dos Custos (7.3) alocao das estimativas dos custos globais aos pacotes individuais
de trabalho do projeto;
Desenvolvimento do Plano do Projeto (4.1) agregao dos resultados dos outros processos de
planejamento de forma a construir um documento coerente e consistente, integrando todo o
planejamento para o projeto;

Processos Facilitadores: As interaes entre os demais processos de planejamento so mais
dependentes da natureza do projeto. Por exemplo, em alguns projetos pode haver sido identificado
apenas um pequeno risco ou mesmo nenhum, at que a maioria do planejamento tenha sido
concluda e a equipe reconhea que as metas de custo e prazo so por demais ousadas, envolvendo
assim um risco considervel. Embora os processos facilitadores sejam realizados intermitentemente
Para os processos
de Planejamento
5.1 Iniciao
Escopo
Fonte: PMI, 2000
Para os processos
de Planejamento
5.1 Iniciao
Escopo
Fonte: PMI, 2000
Pg. 31
e medida que so necessrios durante o planejamento do projeto, eles no so opcionais. Eles
incluem:
Planejamento da Qualidade (8.1) identificao dos padres de qualidade relevantes para o
projeto e determinao de como satisfaz-los;
Planejamento Organizacional (9.1) identificao, documentao, e atribuio de papis,
responsabilidades e relaes hierrquicas no projeto.
Composio da Equipe (9.2) conseguir que os recursos humanos necessrios sejam designados
e alocados ao projeto;
Planejamento das Comunicaes (10.1) determinao das necessidades das partes envolvidas
quanto informao e comunicao: quem necessita de qual informao, quando necessita e
como a informao ser fornecida;
Identificao dos Riscos (11.2) determinao dos riscos provveis do projeto e documentao
das caractersticas de cada um;
Anlise Qualitativa dos Riscos (11.3) anlise dos riscos e das suas condies de forma priorizar
seus efeitos nos objetivos do projeto;
Anlise Quantitativa dos Riscos (11.4) mensurao da probabilidade e impacto dos riscos e
estimativa de suas implicaes nos objetivos do projeto;
Planejamento das Respostas aos Riscos (11.5) desenvolvimento de procedimentos e tcnicas
para aumentar as oportunidades e para reduzir as ameaas de riscos para os objetivos do projeto;
Planejamento das Aquisies (12.1) determinar o que contratar e quando contratar;
Planejamento das Solicitaes (12.2) documentao dos requisitos do produto/servio a ser
adquirido e as fontes possveis de fornecimento.

Processos Essenciais
5.2 Planejamento
do Escopo
Escopo
6.1 Definio das
Atividades
Tempo
6.2 Sequenciamento
das Atividades
Tempo
6.4 Desenvolvimento
do Cronograma
Tempo
5.3 Detalhamento
do Escopo
Escopo
Processos Facilitadores
10.1 Planejamento
das Comunicaes
Comunicao
11.2 Identificao
dos Riscos
Risco
11.3 Anlise Qualita-
tiva dos Riscos
Risco
11.4 Anlise Quanti-
tativa dos Riscos
Risco
11.5 Planejamento das
Risco
8.1 Planejamento da
Qualidade
Qualidade
9.1 Planejamento
Organizacional
RH
9.2 Composio da
Equipe
RH
12.1 Planejamento
das Aquisies
Aquisio
12.2 Planejamento
das Solicitaes
Aquisio
7.1 Planejamento
dos Recursos
Custo
6.3 Estimativa da Du-
rao das Atividades
Tempo
7.2 Estimativa dos
Custos
Custo
11.1 Planejamento
da Gerncia de Riscos
Risco
7.3 Oramento dos
Custos
Custo
4.1 Desenvolvimento
do Plano do Projeto
Integrao
Dos
Processos
de
Iniciao
Dos
Processos
de
Controle
Para os
Processos
de
Execuo
Fonte: PMI, 2000
Processos Essenciais
5.2 Planejamento
do Escopo
Escopo
5.2 Planejamento
do Escopo
Escopo
6.1 Definio das
Atividades
Tempo
6.1 Definio das
Atividades
Tempo
6.2 Sequenciamento
das Atividades
Tempo
6.2 Sequenciamento
das Atividades
Tempo
6.4 Desenvolvimento
do Cronograma
Tempo
6.4 Desenvolvimento
do Cronograma
Tempo
5.3 Detalhamento
do Escopo
Escopo
5.3 Detalhamento
do Escopo
Escopo
10.1 Planejamento
das Comunicaes
Comunicao
10.1 Planejamento
das Comunicaes
Comunicao
11.2 Identificao
dos Riscos
Risco
11.2 Identificao
dos Riscos
Risco
tiva dos Riscos
Risco
tiva dos Riscos
Risco
11.4 Anlise Quanti-
tativa dos Riscos
Risco
11.4 Anlise Quanti-
tativa dos Riscos
Risco
Risco
Risco
8.1 Planejamento da
Qualidade
Qualidade
8.1 Planejamento da
Qualidade
Qualidade
9.1 Planejamento
Organizacional
RH
9.1 Planejamento
Organizacional
RH
9.2 Composio da
Equipe
RH
9.2 Composio da
Equipe
RH
12.1 Planejamento
das Aquisies
Aquisio
12.1 Planejamento
das Aquisies
Aquisio
12.2 Planejamento
das Solicitaes
Aquisio
12.2 Planejamento
das Solicitaes
Aquisio
7.1 Planejamento
dos Recursos
Custo
7.1 Planejamento
dos Recursos
Custo
rao das Atividades
Tempo
rao das Atividades
Tempo
7.2 Estimativa dos
Custos
Custo
7.2 Estimativa dos
Custos
Custo
11.1 Planejamento
Risco
11.1 Planejamento
Risco
7.3 Oramento dos
Custos
Custo
7.3 Oramento dos
Custos
Custo
4.1 Desenvolvimento
do Plano do Projeto
Integrao
4.1 Desenvolvimento
do Plano do Projeto
Integrao
Dos
Processos
de
Iniciao
Dos
Processos
de
Controle
Para os
Processos
de
Execuo
Fonte: PMI, 2000
Pg. 32
Processos de Execuo
Execuo do Plano do Projeto(4.2) levar a cabo o plano do projeto atravs da realizao das
atividades nele includas;
Garantia da Qualidade (8.2) avaliao regular do desempenho geral do projeto com o objetivo
de prover confiana de que o projeto ir satisfazer os padres de qualidade estabelecidos.
Normalmente, realizado por pessoal externo equipe do projeto, como auditores da qualidade,
ou empresas especialmente contratadas para este objetivo;
Desenvolvimento da Equipe (9.3) desenvolvimento das habilidades das pessoas e da equipe,
enquanto grupo, para melhorar o desempenho do projeto;
Distribuio das Informaes (10.2) disponibilizao das informaes necessrias, e no
momento adequado, s partes envolvidas;
Solicitao de Propostas (12.3) obteno, conforme apropriado a cada caso (cotaes de preo,
cartas-convite, licitaes, concorrncias), as propostas de fornecimento dos produtos e/ou
servios pretendidos;
Seleo de Fornecedores (12.4) escolha, dentre os possveis fornecedores, aqueles que melhor
satisfaam s necessidades do projeto;
Administrao dos Contratos (12.5) gerncia dos relacionamentos com os fornecedores.

Processos de Controle
Controle Integrado de Mudanas (4.3) coordenao das mudanas ao longo de todo o projeto;
Verificao do Escopo (5.4) aceite formal dos resultados (escopo) do projeto;
Controle de Mudanas do Escopo (5.5) controle das mudanas no escopo do projeto;
Controle do Cronograma (6.5) controle das mudanas no cronograma do projeto;
Controle dos Custos (7.4) controle das mudanas no oramento do projeto;
Controle da Qualidade (8.3) monitorao dos resultados especficos do projeto para determinar
Processos de Execuo
Para os
Processos de
Controle
4.2 Execuo do
Plano do Projeto
Integrao
12.3 Solicitao de
Propostas
Aquisio
8.2 Garantia da
Qualidade
Qualidade
12.4 Seleo de
Fornecedores
Aquisio
9.3 Desenvolvimento
da Equipe
RH
10.2 Distribuio
das Informaes
Comunicao
12.5 Administrao
dos Contratos
Aquisio
Dos
Processos de
Planejamento
Dos
Processos de
Controle
Fonte: PMI, 2000
Processos de Execuo
Para os
Processos de
Controle
4.2 Execuo do
Plano do Projeto
Integrao
4.2 Execuo do
Plano do Projeto
Integrao
12.3 Solicitao de
Propostas
Aquisio
12.3 Solicitao de
Propostas
Aquisio
8.2 Garantia da
Qualidade
Qualidade
8.2 Garantia da
Qualidade
Qualidade
12.4 Seleo de
Fornecedores
Aquisio
12.4 Seleo de
Fornecedores
Aquisio
9.3 Desenvolvimento
da Equipe
RH
9.3 Desenvolvimento
da Equipe
RH
10.2 Distribuio
das Informaes
Comunicao
10.2 Distribuio
das Informaes
Comunicao
12.5 Administrao
dos Contratos
Aquisio
12.5 Administrao
dos Contratos
Aquisio
Dos
Processos de
Planejamento
Dos
Processos de
Controle
Fonte: PMI, 2000
Pg. 33
se eles atingem padres adequados de qualidade, e identificao de aes para eliminar as causas
de desempenhos insatisfatrios. Difere da garantia da qualidade porque realizado pelos prprios
integrantes da equipe do projeto, e no por pessoas ou instituies externas a ele;
Relato de Desempenho (10.3) coleta e divulgao de informaes de desempenho do projeto.
Isso inclui relatrios de status, medidas de progresso, e novas estimativas para o desenvolvimento
futuro do projeto;
Controle e Monitorao de Riscos (11.6) acompanhamento dos riscos identificados,
monitorando riscos residuais e identificando novos riscos, garantindo a execuo dos planos de
risco e avaliando sua efetividade na reduo dos riscos.

Processos de Encerramento
Encerramento dos Contratos (12.6) completar e liquidar os contratos, incluindo a resoluo de
quaisquer itens pendentes;
Encerramento Administrativo (10.4) gerao, reunio e disseminao de informaes para
formalizar o trmino da fase ou projeto, incluindo avaliaes do projeto e compilao das lies
aprendidas para uso em planejamentos de futuros projetos ou fases (gesto do conhecimento).

Dos
Processos de
Execuo
10.3 Relato de
Desempenho
Comunicao
7.4 Controle dos
Custos
Custo
5.5 Controle de Mu-
danas do Escopo
Escopo
8.3 Controle da
Qualidade
Qualidade
6.5 Controle do
Cronograma
Tempo
11.6 Controle e Moni-
toramento dos Riscos
Risco
Para os
Processos de
Planejamento
Para os
Processos de
Execuo
Para os
Processos de
Encerramento
4.3 Controle Integra
do de Mudanas
Integrao
5.4 Verificao do
Escopo
Escopo
Fonte: PMI, 2000
Dos
Processos de
Execuo
10.3 Relato de
Desempenho
Comunicao
10.3 Relato de
Desempenho
Comunicao
7.4 Controle dos
Custos
Custo
7.4 Controle dos
Custos
Custo
5.5 Controle de Mu-
danas do Escopo
Escopo
5.5 Controle de Mu-
danas do Escopo
Escopo
8.3 Controle da
Qualidade
Qualidade
8.3 Controle da
Qualidade
Qualidade
6.5 Controle do
Cronograma
Tempo
6.5 Controle do
Cronograma
Tempo
Risco
Risco
Para os
Processos de
Planejamento
Para os
Processos de
Execuo
Para os
Processos de
Encerramento
do de Mudanas
Integrao
do de Mudanas
Integrao
5.4 Verificao do
Escopo
Escopo
5.4 Verificao do
Escopo
Escopo
Fonte: PMI, 2000
Dos
Processos
de Controle
12.6 Encerramento
dos Contratos
Aquisio
10.4 Encerramento
Administrativo
Comunicao
Fonte: PMI, 2000
Dos
Processos
de Controle
12.6 Encerramento
dos Contratos
Aquisio
12.6 Encerramento
dos Contratos
Aquisio
10.4 Encerramento
Administrativo
Comunicao
10.4 Encerramento
Administrativo
Comunicao
Fonte: PMI, 2000
Pg. 34
6. O Relatrio Executivo

Uma vez que um projeto selecionado para desenvolvimento, parte-se para a sua
concepo, especificando-se de forma clara o escopo do que ser empreendido. O Relatrio
Executivo eaborado de forma a tornar os parmetros especficos do projeto mais claros e mais
profundamente compreendidos tanto pelos executivos da organizao quanto pela equipe
estabelecida para este fim
6
. Este documento discrimina o escopo que pretende ser considerado pelo
projeto, contemplando os seguintes itens:

1. Misso: declarao sucinta do que o projeto realizar;
2. Diagnstico: apresentao dos problemas e /ou oportunidades a serem vencidos /
alavancados;
3. Escopo: detalhamento dos produtos e aes que o projeto ir executar, bem como dos
que no ir implementar;
4. Restries: especificidades, limitantes e aspectos restritivos dos produtos a serem
gerados pelo projeto;
5. Premissas: condies pr-assumidas como verdadeiras a partir das quais o projeto ser
concebido, planejado e executado;
6. Benefcios: vantagens competitivas a serem trazidas pelo projeto, na viso do cliente ou
da organizao contratante;
7. Riscos: fatores que podero comprometer a viabilidade do projeto, ou acarretar danos,
dificuldades e problemas na sua execuo, bem como as contra-medidas a serem
adotadas para minimiz-los ou evit-los;
8. Macro-Fases: grandes etapas do projeto, bem como suas respectivas estimativas de prazo
e durao;
9. Justificativas para Contrataes e Aquisies: argumentos que justifiquem a necessidade
de contrataes especficas para o projeto, ou para aquisies necessrias e
imprescindveis para seu desenvolvimento;
10. Perfil da Equipe do Projeto: habilidades e skills necessrios para a conduo do projeto;
11. Oramento Preliminar: estimativas prvias relacionadas aos custos e investimentos para
a execuo do projeto;
12. Fatores Crticos de Sucesso: condies imprescindveis para o xito do projeto. Sem
elas, o projeto certamente falhar.

Vejamos, a seguir, um detalhamento de cada uma das sees que devem compor um
Relatrio Executivo.

6.1. Misso

Deve apresentar, de forma sucinta, o que o Projeto pretende atingir. Preferencialmente,
uma nica frase dever ser utilizada nesta seo, de forma a esclarecer o objetivo macro do projeto.
A declarao de misso de um projeto deve constar de um nico pargrafo, o mais sucinto possvel,
e, idealmente, deve possuir as caractersticas SMART (Specific, Mensurable, Achievable, Results-
Oriented e Time-Oriented). Vejamos como isso deve ser entendido:

6
Um Relatrio Executivo pode existir sob diversas terminologias como, por exemplo, uma Proposta de Negcio, uma
Proposta de Soluo, uma Minuta de Contrato, Project Charter, entre outros. Portanto, estamos adotando o termo
Relatrio Executivo de um Projeto para tornar o conceito mais geral.
Pg. 35

1> Ser especfica (Specific): no pode ser ambgua;
2> Ser mensurvel (Mensurable): as medidas devem ser quantitativas e qualitativas sempre
que possvel;
3> Ser atingvel (Achievable): dados os recursos, os prazos e a capacitao adequada, os
objetivos devem ser atingveis;
4> Estar baseada em resultados concretos (Results-Oriented): o verdadeiro teste de um
projeto efetivo se ele atinge os resultados esperados. A declarao de misso uma
medida clara para determinar se os resultados esperados foram, de fato, atingidos;
5> Estar orientada a um prazo bem definido (Time-Oriented): os perodos para a entrega
ou implantao do produto final do projeto deve estar bem clara na declarao de misso
do mesmo.

Naturalmente, deve-se enfatizar, na declarao de misso de um projeto, as necessidades de
negcio a serem atendidas. Neste ponto, deve-se tomar cuidado para no serem inseridas
funcionalidades especficas do projeto, nem tampouco detalhes de implementao do mesmo.

Vejamos um bom exemplo de declarao de misso de um projeto:

(...) Esta nao dever comprometer-se a atingir o objetivo de, antes do final desta dcada,
fazer com que um homem aterrisse na superfcie da Lua e seja trazido de volta Terra de forma
segura. Nenhum outro projeto espacial neste perodo ser mais impressionante para a humanidade,
ou mais importante para a explorao do espao no longo prazo, e nenhum ser to difcil ou to
caro para ser executado
Presidente John Fitzgerald Kennedy
Discurso no Congresso Nacional dos Estados Unidos
25 de Maio de 1961

Vejamos se nosso exemplo adequa-se a uma declarao de misso:

1> especfica? O Presidente pede Nao norte americana a comprometer-se
especificamente e sem ambigidade a fazer com que um homem aterrisse na superfcie
da Lua e retorne, so e salvo, Terra;
2> mensurvel? Ser muito fcil medir se os resultados foram alcanados ou no;
3> atingvel? A comunidade cientfica da poca acreditava que seria possvel enviar uma
misso tripulada Lua e retorn-la s e salva Terra, muito embora o Presidente JFK a
reconhecesse que este empreendimento seria muito difcil e caro;
4> Est baseada em resultados concretos? Os critrios para o sucesso eram claros: o
projeto iria ter sucesso se um homem aterrissasse na superfcie lunar e retornasse para a
Terra so e salvo. Ele falharia se uma espaonave tripulada americana no chegasse
Lua at o final da dcada, ou se ela no retornasse com sua tripulao de forma so e
salva Terra;
5> Est orientada a um prazo bem definido? Pela especificao de que os Estados
Unidos deveriam implementar uma misso lunar at o final da dcada, o Presidente
Kennedy estabeleceu um limite de prazo especfico e ofereceu aos engenheiros
aeroespaciais norte-americanos uma data limite at a qual os mesmos deveriam
concentrar seus esforos.

A viabilidade da viso do Presidente JFK foi mais tarde confirmada, muito embora ele
Pg. 36
mesmo no tenha vivido o suficiente para vivenci-la. Em 20 de julho de 1969, os americanos Neil
Armstrong e Edwin Buzz Aldrin, da misso espacial Apollo 11, deu humanidade os primeiros
passos sobre a Lua, retornando de forma segura Terra quatro dias depois.

6.2. Diagnstico

A seo Diagnstico trata, principalmente, dos necessidades, oportunidades ou problemas
a serem endereados pelo projeto. Nesta seo, devem ser considerados os fatos e situaes vividas
pela organizao referentes, especificamente, ao contexto que ser contemplado pelo projeto.
Idealmente, estatsticas, pesquisas, grficos e tabelas devem demonstrar a situao atual da empresa
quanto s deficincias e limitaes que justificariam a execuo do projeto em questo, projeto este
que buscar as solues que se dedicaro a minimizar tais elementos restritivos. Alm disso, deve
considerar, se possvel tambm atravs de tabelas e grficos, as oportunidades a serem alavancadas
a partir do desenvolvimento do projeto.

6.3. Escopo

A seo Escopo delimita a abrangncia dos resultados do Projeto, tanto em termos do que o
mesmo realizar quanto em relao ao que o projeto no implementar.

6.3.1. Objetivos (ou, O Qu o Projeto REALIZAR):

Discrimina a relao de aes que necessariamente sero implementadas no projeto.
Devem ser sucintas, pontuais e especficas. Devem ser redigidas com verbos de ao, como os
exemplos a seguir:

Implementar infra-estrutura tecnolgica que suporte as atividades de CRM, Workgroup
Computing e a Intranet corporativa, tanto no mbito da matriz como em todas as suas
filiais;
Desenvolver as funcionalidades X, Y e Z do sistema de gesto de logstica, atendendo aos
requisitos de fornecimento e engenharia de produtos conforme especificam os manuais
KKK e LLL;

Esta seo funciona como um contrato entre as partes envolvidas no projeto, ou seja, os
executivos patrocinadores e a equipe do projeto. Cada um de seus tpicos deve ter sido
rigorosamente cumprido ao final do projeto, sob pena de o considerarmos como no concludo,
ou parcialmente concludo, ou at mesmo com o status de fracassado ou de concludo com
restries. importante enfatizar que o lder de projetos avaliado em termos dos resultados que
oferece empresa. Os objetivos de um projeto so, necessariamente, a explicitao prtica destes
resultados. Podemos considerar, ainda, que os objetivos do projeto referem-se a um detalhamento
da Misso do mesmo.

6.3.2. O Qu o Projeto NO REALIZAR

Discrimina a relao de aes que NO sero implementadas pelo projeto. Tambm deve
ser sucintas, pontuais e especficas, e devem retirar toda e qualquer ambigidade que porventura
Pg. 37
tenha ficado subentendida na declarao dos Objetivos do Projeto.

Esta seo necessria e de extrema importncia, pois evita que se criem falsas expectativas
quanto aos resultados esperados do projeto. Vejamos alguns exemplos:

O Projeto no realizar a substituio dos equipamentos obsoletos, devendo tal ao ser
realizada pelas equipes de logstica do contratante;
O Projeto no prev a capacitao do pessoal a ser envolvido nas reas de Telemarketing,
Atendimento a Clientes e ao pessoal de Vendas, ficando esta responsabilidade a cargo do
contratante;
O Projeto no contemplar estudos para avaliao de tecnologias mais modernas para a
implementao da nova soluo, adotando a linha tecnolgica j utilizada e de pleno
conhecimento da empresa.

6.4. Restries

Refere-se a aspectos limitadores quanto s solues a serem desenvolvidas pelo projeto,
aspectos estes a serem respeitados durante o planejamento, a execuo e o controle do mesmo. As
restries geralmente so impostas pelo cliente, e podem limitar os custos do projeto, os prazos,
pessoal, tecnologia e outras questes que, se no forem respeitadas, o projeto no poder ser
executado. Do contrrio, o mesmo estar ferindo determinaes de seu contratante. Vejamos alguns
exemplos de declaraes de restries em um projeto:

A soluo a ser implementada dever oferecer acesso simultneo a, no mnimo, 1000
usurios para cada antena de telecomunicaes instalada;
Os equipamentos utilizados na soluo no podem ficar mais que 3 horas indisponveis
por ms;
O tempo de resposta da soluo deve ser de, no mximo, 1,5 segundos;
O custo da primeira Fase do projeto no dever ultrapassar R$100.000,00;
O prazo de implantao do projeto dever ser de, no mximo, 3 meses aps a aprovao
de seu oramento e proposta de trabalho.

Em alguns casos, as Restries podem ser discriminadas na prpria declarao de Objetivos,
o que parece ser um detalhamento de cada um dos Objetivos. Sendo assim, como exemplos da
declarao de Objetivos modificada, contendo aspectos qualitativos que os limitam, poderamos
verificar os seguintes casos:

Implementar infra-estrutura tecnolgica que suporte as atividades de CRM, Workgroup
Computing e a Intranet corporativa, tanto no mbito da matriz como em todas as suas
filiais com faturamento superior a R$300.000,00, at janeiro de 2001, e com um
investimento total mximo de R$450.000,00;
Desenvolver as funcionalidades X, Y e Z do sistema de gesto de logstica, atendendo aos
requisitos de fornecimento e engenharia de produtos conforme especificam os manuais
KKK e LLL, de forma a torn-lo compatvel e integrado com o sistema de ERP da
empresa, at maro de 2002, e com um investimento total mximo de R$250.000,00.

Pode surgir alguma confuso quanto ao que se considera uma Restrio e quanto ao que se
considera um item que o Projeto no realizar, este ltimo presente na seo Escopo. Devemos
Pg. 38
ressaltar que uma Restrio um conjunto de limitadores dos Objetivos de um Projeto, ou seja,
especifica, restringe ou limita, de forma bem clara, os Objetivos a serem produzidos por um projeto,
sendo elas definidas pelo cliente ou pelo contratante do projeto. O item O Qu o Projeto NO
REALIZAR, por sua vez, informa o que o Projeto NO far, ou seja, no realizar, de fato. Em
outras palavras, enquanto a primeira seo (Restries) particulariza os Objetivos a serem buscados
por um Projeto, o segundo tpico (O QU o Projeto NO Realizar) exclui literalmente elementos
que no sero sequer considerados no desenvolvimento do mesmo, retirando-os do escopo do
Projeto.

6.5. Premissas

Premissas so condies pr-assumidas como verdadeiras, ou suposies a partir das quais o
Projeto concebido e empreendido. As premissas geralmente so impostas pela equipe do projeto e,
caso no sejam respeitadas, aumentaro os riscos do projeto. Podemos considerar que as Premissas
so verdades em que se baseiam as expectativas, previses e estimativas relacionadas ao Projeto. As
Premissas funcionam como um alicerce sobre o qual o Projeto ser elaborado e conduzido. Vejamos
alguns exemplos:

O projeto considerar que, no momento de sua implantao, a utilizao mxima dos
equipamentos da organizao no ser maior que 55% de sua capacidade operacional til,
de forma a permitir a adequada acomodao da nova soluo;
O projeto considera que j existir fiao eltrica e instalaes hidrulicas pr-instaladas
nas fbricas e usinas do contratante, estando elas adequadas aos padres e normas
vigentes no mercado;
No caso de carncia de recursos para a continuidade do projeto, ficar priorizada a
soluo que atenda ao maior nmero de usurios da empresa contratante, ao invs da
soluo tecnicamente melhor paramentada;
Os fornecedores que no apresentarem um grupo significativo de outros clientes com
solues similares s que sero desenvolvidas no projeto estaro automaticamente
desqualificados como candidatos a parceiros tecnolgicos para a execuo do projeto.

As premissas ajudam a oferecer um terreno firme sobre o qual as solues do Projeto
sero desenvolvidas e, caso sejam violadas, podem alterar significativamente o curso das aes e
decises a serem tomadas, influenciando tambm o planejamento de atividades e os custos
associados a cada uma delas.

As Premissas diferem das Restries no seguinte sentido: as Restries apontam fatores
limitantes quanto aos resultados (Objetivos) a serem perseguidos ao longo do projeto, sendo
determinados pelo cliente ou contratante do Projeto. As Premissas, por sua vez, determinam
condies-chave a partir das quais o projeto ser concebido e planejado, sendo normalmente
definidas por parte da equipe do projeto, e com objetivos explcitos de reduo de riscos para o
Projeto. Desta forma, as Premissas definem pontos de partida para a prpria concepo e
desenvolvimento do Projeto de forma a torn-lo, de fato, exeqvel.

Pg. 39
6.6. Benefcios

Vantagens a serem obtidas, do ponto de vista do cliente, aps a implementao das solues
constantes do projeto. Refere-se a ganhos diretos (ou mesmo indiretos) relacionados s mudanas
originadas a partir da incorporao das novas solues provenientes do desenvolvimento do projeto.
Esta seo agrega valor s solues a serem desenvolvidas, e deve ser redigida considerando as
melhorias a serem alcanadas. Como exemplos de construes desta seo, teramos:

Otimizao do desempenho do sistema de controle de logstica, de forma a prepar-lo
para uma integrao com os sistemas de fornecimento internacionalmente utilizados,
como o AAA e o BBB;
Aperfeioamento dos processos de gesto de logstica e de controle de produo,
permitindo economia de custos no gerenciamento dos mesmos nos mdio e longo prazos;
Capacitao tecnolgica dos profissionais da empresa, tornando-os aptos a expandirem as
novas funcionalidades para toda a rede de fornecimento e de consumo, tanto da
organizao quanto em todas as suas empresas coligadas.

Os benefcios a serem incorporados por um projeto agregam valor e importncia iniciativa,
invariavelmente suportando novas iniciativas a serem futuramente consideradas com interesse.
Enfim, deve-se considerar a seo Benefcios como aquela que efetivamente vende um Projeto
aos seus clientes.

6.7. Riscos

Discrimina fatos e eventos que, caso ocorram, devem ser tratados com a mxima presteza,
sob pena de incorporar atrasos ou at mesmo a inviabilizao do projeto como um todo. A cada
risco, devem ser associadas aes a serem tomadas, de forma a mitigar ou anular seus efeitos. Por
exemplo, em um projeto de integrao do sistema de logstica central ao sistema de monitoramento
de transportes rodovirios, poderamos ter os seguintes riscos associados:

Greve dos caminhoneiros;
Migrao do sistema vigente nas empresas de transporte para padres proprietrios de
baixo custo;

Nestes casos, deveriam ser estabelecidas as seguintes aes de resposta respectivas, como:

Estudo a ser conduzido e levado ao corpo executivo da organizao para que se estudem
termos atraentes e proativos de negociao para melhoria da remunerao aos operadores
de frete;
Alocao de fora-tarefa para estudo de novos padres tecnolgicos emergentes de
mercado, especficos para o setor de transportes.

Um outro exemplo, num projeto de implementao de um sistema transacional baseado nas
tecnologias Web produzidas por uma empresa especfica poderia levantar, como um risco:

Aquisio da empresa fornecedora por grupos maiores, o que poderia forar a mudana
na linha de produtos principais.
Pg. 40

A isso, seguiria-se as seguintes aes para a mitigao do risco:

Estudo e avaliao de parceiros e tecnologias alternativas para a implementao da
soluo;
Estudo dos cenrios de fuses e aquisies futuras mais provveis.

Neste caso, tais aes poderiam permitir uma rpida adaptao a novos contextos
mercadolgicos.

6.8. Macro-Fases

Ainda sem um detalhamento maior das fases e atividades do Projeto, pode ser interessante a
discriminao das grandes etapas de um projeto (Ciclo de Vida). Mesmo considerando que o
planejamento minucioso das fases de um Projeto ainda no teve incio, uma expectativa acerca da
linha base de execuo de um projeto pode ser necessria. Vejamos um bom exemplo deste item,
considerando as macro-fases de um projeto de desenvolvimento e implantao de um novo sistema
de controle de transaes nas filiais de uma organizao comercial:

FASE 1: Estudo de viabilidade tcnico-financeira - Jan;
FASE 2: Planejamento detalhado da implementao - Jan-Fev;
FASE 3: Implementao da soluo - Mar-Ago;
FASE 4: Implantao e roll-out - Ago-Set;
FASE 5: Encerramento do Projeto - Set.

Talvez, se houvesse um detalhamento maior, poderamos chegar ao seguinte exemplo:

FASE 1: Estudo de viabilidade tcnico-financeira - Out/Nov;
FASE 2: Contratao de consultoria para elaborao da arquitetura da soluo - Out/Dez;
FASE 3: Detalhamento da arquitetura da soluo - Nov/Jan;
FASE 4: Planejamento detalhado da implementao - Jan/Mar;
FASE 5: Elaborao do primeiro prottipo - Mar;
FASE 6: Validao de requisitos de escopo - Mar;
FASE 7: Implementao da soluo - Abr/Jul;
FASE 8: Testes integrados e homologao da soluo - Jul/Ago;
FASE 9: Implantao em piloto - Ago;
FASE 10: Expanso para todas as filiais e unidades de negcio (Roll-out) - Set/Out;
FASE 11: Estabilizao da soluo no ambiente organizacional - Out/Nov;
FASE 12: Encerramento do Projeto - Nov;

interessante a insero das estimativas de prazos para a execuo de cada uma das fases
acima descritas. Normalmente, os clientes exigem conhec-los previamente, mesmo que seja em
termos de previses. Neste caso, sugere-se os prazos sejam estimados de forma a considerar as
diversas alternativas de execuo das solues oferecidas em cada uma das fases previstas para o
projeto. Mesmo que seja realizado um levantamento mais pormenorizado das aes a serem
tomadas para o desenvolvimento do projeto, deve-se deixar bem claro ao cliente que tratam-se de
estimativas ainda pouco profundas.

Pg. 41

6.9. Justificativas para Contrataes e Aquisies

No caso da possibilidade de incorporao de uma nova tecnologia atravs do projeto, pode
revelar-se imprescindvel a contratao de uma consultoria especializada no assunto em questo.
Alm disso, pode haver tambm a necessidade de se orarem treinamentos para a equipe do projeto,
ou mesmo para o pessoal que passar a operar as solues implementadas atravs do projeto. Nestes
casos, entre outros, devem ser levantados previamente todos os tipos de servios necessrios
execuo do projeto de forma a no surpreender a organizao no que tange preparao da mesma
para assimilao das novas solues.

Alm disso, caso se verifique necessria a aquisio de computadores, mobilirio, softwares
e outros suprimentos e equipamentos, importante a previso antecipada dos mesmos
principalmente para que se estime o esforo, o oramento e os prazos para a adequada absoro
destes recursos.

Sendo assim, esta seo deve contemplar as justificativas adequadas para as eventuais
aquisies de recursos, materiais e suprimentos necessrios para a execuo do projeto, bem como
apresentar os argumentos que devero levar s eventuais contrataes de servios. Naturalmente,
itens ordinrios a serem utilizados no projeto no devem ser necessariamente justificados nesta
seo, a no ser que o cliente assim o exija, e considerando que todos eles estaro inseridos na seo
seguinte, o Oramento Preliminar (Ex. material de escritrio, telefonia, deslocamento, estadia e
alimentao, etc.)
7
.

6.10. Perfil da Equipe de Projeto

Para que o Projeto seja conduzido, deve-se definir a estrutura organizacional da equipe de
projeto, ou seja, quem dever ficar encarregado de qu. Tendo em vista o planejamento da
equipe fixa a ser empregada para a conduo do projeto, podem ser recomendados perfis de
conhecimento desejveis, incluindo a as habilidades e skills necessrios sua composio. Caso
seja necessria a capacitao de alguns dos membros da equipe de projeto, devem ser justificados os
treinamentos necessrios, e isso normalmente feito na seo Justificativas para Contrataes e
Aquisies, conforme citado anteriormente. Como exemplo da definio do perfil de uma equipe
de projeto, vejamos a seguir:

1 profissional para gerenciar a equipe de Projeto, com boa capacidade de comunicao
oral e escrita, liderana, iniciativa e de esprito empreendedor e proativo; deve possuir
experincia comprovada mnima de 5 anos na conduo de equipes multidisciplinares;
deve possuir mdio a alto conhecimento nas tecnologias XXX, YYY e ZZZ;
1 profissional de nvel snior, com alta capacidade de trabalho em equipe e de
transferncia de conhecimentos, com experincia comprovada na tecnologia XXX por
mais que 5 anos, e com mdio conhecimento nas tecnologias YYY e ZZZ;

7
Em alguns casos, deve ficar claro que alguns custos no estaro cobertos pelo projeto como, por exemplo, custos com
deslocamento, estadia e alimentao de consultores externos. Na seo Justificativas para contratao e Aquisies
deve constar todas as condies financeiras a serem consideradas a este respeito, e a seo Oramento Preliminar
deve discriminar os tpicos correspondentes, quando for o caso.
Pg. 42
Investimentos Qtd. Valor Unitrio Valor Total
Hardware
Servidores Desenvolvimento 2 20.000,00 40.000,00
Servidores Homologao / Produo 2 35.000,00 70.000,00
Estaes de Trabalho 34 2.500,00 85.000,00
Impressoras 4 4.000,00 16.000,00
Equipamentos de Rede 7 1.500,00 10.500,00
Sub-total Hardware 221.500,00
Software
Windows 2000 36 1.000,00 36.000,00
Ferramentas de Desenvolvimento 4 3.200,00 12.800,00
Bancos de Dados 3 4.000,00 12.000,00
Backup 3 1.000,00 3.000,00
Anti-vrus 36 250,00 9.000,00
Sub-total Software 72.800,00
Servios
Treinamento 6 2.500,00 15.000,00
Consultoria 1 25.500,00 25.500,00
Sub-total Servios 40.500,00
TOTAL INVESTIMENTOS 334.800,00
Custos / Despesas (em 6 meses)
Qtd. Valor Unitrio Valor Total
Suprimentos
Papel 120 10,00 1.200,00
Toner para impressora 28 250,00 7.000,00
Material de escritrio 6 250,00 1.500,00
Sub-total Suprimentos 9.700,00
Servios
Contrato de manuteno 4 7.000,00 28.000,00
Sub-total Servios 28.000,00
TOTAL CUSTOS / DESPESAS (em 6 meses)
37.700,00
TOTAL GERAL (Investimentos + Custos/Despesas) 372.500,00
2 profissionais de nvel pleno, com boa capacidade de trabalho em equipe, com grande
nvel de conhecimentos e experincia comprovada mnima de 3 anos nas tecnologias
YYY e ZZZ;
1 profissional com experincia mnima de 3 anos em documentao de projetos.

6.11. Oramento Preliminar

Como um apoio para a tomada de decises, faz-se necessrio um oramento preliminar que
discrimine os investimentos necessrios para o desenvolvimento do projeto. Se for possvel, sugere-
se, ainda, que seja elaborado um plano de desembolso, discriminando os gastos ao longo do tempo,
e por categoria de investimento (Ex. Materiais, suprimentos, equipamentos, software, servios,
etc.). Contudo, o plano de desembolso poder ser desenvolvido posteriormente, quando da
elaborao do Plano de Execuo, como veremos adiante. Vejamos, logo abaixo, um exemplo
sucinto do que se pode oferecer em termos de oramento preliminar:

Exemplo de um Oramento Geral de um Projeto
Pg. 43

6.12. Fatores Crticos de Sucesso

Requisitos imprescindveis para a implementao do projeto, sem os quais o mesmo no
poder ser viabilizado. Podemos citar, como exemplo, num projeto de implementao de infra-
estrutura de segurana de informaes, os seguintes Fatores Crticos de Sucesso:

Aquisio de softwares de firewall que estejam cotados como efetivamente seguros, e
notoriamente avaliados a partir de organismos e instituies independentes;
Alocao em tempo integral de um profissional especializado em protocolos de
comunicao TCP/IP;
Contratao de empresa ou especialista de consultoria em segurana de informaes, para
oferecer mecanismos voltados configurao segura dos servidores da empresa.

Outros projetos que estejam previstos ou j sendo executados pela organizao podem ser
considerados como Fatores Crticos de Sucesso, pois o Projeto atual pode consider-los como seus
pr-requisitos. Sendo assim, cada um dos Projetos paralelos que impactem o desenvolvimento do
Projeto atual devem ser tratados como Fatores Crticos de Sucesso. Uma questo importante a ser
considerada neste item o comprometimento que a nova soluo dever demandar em relao s
diversas reas envolvidas, estimulando alteraes significativas em seus processos e rotinas
internos. Cada uma destas implicaes devem ser consideradas como Fatores Crticos de Sucesso.

ATENO!
Uma vez mais estamos chamando a ateno para os pontos a seguir: alguma confuso pode
ser feita em termos do que se referem as seguintes sees como, O QU o Projeto NO Far,
Restries, Premissas e Fatores Crticos de Sucesso. Recordemos suas definies bsicas:
O QU o Projeto NO Far: itens no cobertos pelo projeto;
Restries: limitantes em relao aos resultados a serem gerados por um projeto;
Premissas: condies assumidas pela equipe do projeto a partir das quais um projeto ser
concebido, planejado e executado;
FCS: condies imprescindveis para que ocorra o verdadeiro sucesso do projeto.

Como um exemplo, consideremos um projeto de realizao dos eventos de formatura.
Poderamos qualificar, da seguinte forma, elementos do projeto nos tpicos acima descritos:
O QU o Projeto NO Far: o projeto no realizar rifas, ou churrascos de
confraternizao, objetivando angariar fundos que o financiem;
Restries: o evento de colao de grau estar sendo dimensionado para cerca de 300
pessoas, incluindo os prprios formandos, professores, coordenadores e diretores de
curso, e no poder custar mais de R$20.000,00;
Premissas: a prioridade na execuo do projeto estar focada nas cerimnias de colao
de grau e celebraes religiosas, ficando a execuo de bailes ou festas de formatura com
prioridade menor. Outro exemplo de premissa de que o projeto somente poder ser
executado com o comprometimento de, pelo menos, metade dos formandos;
FCS: a contratao de servios de cerimonial essencial e imprescindvel para o sucesso
dos eventos a serem executados.

Num processo iterativo entre o lder de projeto e sua equipe, os gerentes das reas afins e os
Pg. 44
executivos envolvidos com a iniciativa, o Relatrio Executivo aprovado quando no h mais
nenhuma dvida ou ponderao por parte do corpo decisrio. Este relatrio passa a ser considerado
efetivamente como uma espcie de contrato firmado entre a equipe do projeto e os executivos que o
aprovaram.

Pg. 45
7. O Plano de Execuo

Uma vez que o Relatrio Executivo deixa claro para a equipe de projeto como para os
executivos da organizao contratante qual ser o escopo das solues a serem desenvolvidas e
implementadas, deve-se passar para o dimensionamento do projeto em termos de seu plano de
execuo, ou seja, o detalhamento de suas fases, atividades, produtos, prazos e recursos a serem
empregados no projeto, alm de definir como se dar a interao entre cada um de seus
participantes e envolvidos. Ressaltamos, porm, que esta tarefa no pequena, nem tampouco
trivial, mas a base para o real dimensionamento do projeto, em termos de custos, prazos, recursos
e produtos a serem disponibilizados. Vejamos quais so os elementos constituintes do Plano de
Execuo de um Projeto:

1. Cronograma;
2. Matriz de Responsabilidades;
3. Plano de Desembolso;
4. Produtos e Sub-Produtos;
5. Plano de Comunicao.

Em alguns casos, o Plano de Execuo pode ser parte integrante do Relatrio Executivo.

7.1. Cronograma

Constitui-se do estabelecimento e descrio das fases e atividades de execuo do projeto,
bem como sua distribuio no tempo. Devem ser consideradas as precedncias (refere-se ordem
em que tarefas devem ocorrer de forma a permitir que outras sejam executadas propriamente), as
prioridades (nveis de urgncia de tarefas em relao a outras de mesma precedncia) e a
possibilidade de paralelismo entre elas (refere-se s possibilidades de simultaneidade na execuo
de vrias tarefas). Tambm nos casos em que um grupo limitado de recursos seja necessrio para a
execuo de tarefas que, em tese, poderiam ser executadas em paralelo, algumas das tarefas devem
ser priorizadas em relao s demais.

Estimar prazos de atividades de forma a considerar folgas muito grandes pode ser danoso,
pois pode comprometer a viabilidade do projeto uma vez que o oramento pode crescer muito, e de
forma artificial. Alm disso, os prazos devem ser justificados dentro de uma realidade vivel.
Naturalmente, podem haver falhas nas estimativas iniciais, o que pode levar necessidade de
renegociaes junto aos clientes. Contudo, antes de se partir para a proposta de adiamentos ou
postergaes sempre necessrio verificar todas as alternativas que poderiam levar manuteno
dos prazos estabelecidos.

Quando houver a iminncia de um possvel atraso ou desembolso adicional em um projeto,
aps esgotadas todas as alternativas possveis que eventualmente possam contornar eventuais
impactos no projeto, tanto em termos de renegociao das funcionalidades esperadas, ou em termos
de reviso de prazos e custos, deve-se empregar a seguinte regra: informar tais possibilidades ao
executivo patrocinador o quanto antes possvel, de forma a no deix-lo sob presso, no ltimo
instante, para uma adequada tomada de decises que procure corrigir o rumo do projeto.

Como exemplo, verifiquemos o cronograma para um projeto hipottico de marketing
visando o lanamento de um novo produto no mercado:
Pg. 46

Exemplo do cronograma de um projeto de Marketing para o lanamento de um novo produto

S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4
Plano de Marketing - Lanamento de produto
Fase I - Pesquisa de mercado
1.1 - Contratao de empresa especializada
1.2 - Definio de objetivos da pesquisa
1.3 - Definio de respostas a serem obtidas
1.4 - Realizao da pesquisa de mercado
1.5 - Apresentao de resultados
Fase II - Preparao da veiculao do produto na mdia
2.1 - Definio de mdias a serem utilizadas
2.2 - Contratao de empresa de publicidade
2.3 - Oramentao de veiculao de peas publicitrias
2.4 - Aprovao de oramentos
2.5 - Elaborao de peas publicitrias
2.6 - Aprovao de peas publicitrias
Fase III - Preparao das equipes de vendas
3.1 - Elaborao de material de treinamento
3.2 - Elaborao de material de divulgao
3.3 - Anlise jurdica do material de divulgao
3.4 - Aprovao jurdica do material de divulgao
3.5 - Treinamento das equipes de vendas
3.6 - Distribuio do material de divulgao (kit do vendedor)
3.7 - Equipe de vendas preparada
Fase IV - Lanamento do produto
4.1 - Veiculao das peas publicitrias
4.2 - Realizao de vendas-piloto
4.3 - Apurao de resultados preliminares
4.4 - Anlise de aceitao e projeo de resultados futuros
4.5 - Apresentao de relatrio final
Ms 05 Ms 06 Ms 01 Ms 02 Ms 03 Ms 04
Pg. 47
Conforme pode ser observado a partir do exemplo acima:

A Fase I possui precedncia sobre as fases II e III, pois necessria que ela seja
concluda antes que as demais possam ser iniciadas;
A Fase II possui prioridade sobre a Fase III, apesar de que isso no necessariamente fica
explcito no grfico, a no ser pelo fato que a Fase II possui uma durao maior que a
Fase III, o que a torna parte do caminho crtico do projeto;
As Fases II e III podem ocorrer em paralelo, pois a execuo de uma delas no
necessariamente concorre contra a outra (a no ser em termos dos recursos e pessoas
envolvidas, o que pode gerar algum conflito);
A Fase IV somente poder iniciar-se aps as Fases II e III, sendo estas ltimas
necessariamente predecessoras da anterior.

As questes relativas a paralelismo, prioridades e precedncias podem e devem ser tambm
analisadas em termos das atividades de cada fase, bem como entre as macro-fases de um projeto. O
exemplo ilustra esta precedncia e mostra paralelismo entre algumas atividades, como pode ser
verificado visualmente no cronograma acima. Em outras palavras, a otimizao das etapas de um
projeto deve ser buscada a todo momento, de forma a ganhar-se produtividade e eficincia na gesto
do tempo.

Quanto s estimativas para durao de tarefas, poderamos analisar a seguinte sugesto. A
durao estimada (D
Estimada
) poder ser calculada a partir de uma mdia ponderada entre as
duraes mais provvel (D
Provvel
), a mais tarde (D
Tarde
) e a mais cedo (D
Cedo
), da seguinte
forma:

D
Estimada
= (D
Cedo
+ 4 x D
Provvel
+ D
Tarde
)
6

Para exemplificarmos o clculo, consideremos o seguinte caso:

D
Cedo
= 2 dias
D
Provvel
= 3 dias D
Estimada
= (2 + 4 x 3 + 5) = 3,17 dias
D
Tarde
= 5 dias 6

Devemos ressaltar que D
Cedo
poder ser igual ou muito prxima D
Provvel
, assim como
D
Tarde
tambm poder ser igual ou muito prxima D
Provvel
.

Para a estimao de cada uma das duraes consideradas, em qualquer situao no se deve
menosprezar a experincia daqueles que efetivamente realizaro cada uma das tarefas a serem
planejadas. Na verdade, os gerentes de projeto devem buscar o comprometimento das equipes e
participantes de cada fase e atividade justamente questionando aos futuros implementadores quanto
tempo eles consideram para que, de fato, realizem de fato o trabalho a ser feito. Neste processo, os
gerentes de projeto devem negociar os nveis de esforo a serem dispendidos, reduzir a
complexidade do produto final de forma a ganhar tempo, modularizar os resultados a serem
produzidos ao longo do tempo de forma a alcanar algo til e real em menor prazo, disponibilizar
mais e melhores recursos para a implementao de forma a acelerar o processo de desenvolvimento,
discutir as tcnicas ou as formas de implementao a serem empregadas de forma a eliminar
Pg. 48
trabalho no imprescindvel, entre outros fatores, objetivando adequar as estimativas apresentadas
pelos tcnicos e participantes realidade dos resultados do projeto, sobretudo no que tange ao ponto
de vista do cliente.

Algumas atividades podem possuir durao zero. Neste caso, considera-se tais atividades
como marcos, ou seja, como pontos a serem atingidos no tempo, e que sobre eles no se pode
precisar a durao especfica. Alm disso, os marcos podem indicar pontos de controle
(checkpoints) ao longo do projeto, sobre o qual devem ser tomadas aes especficas.

Como um exemplo de um marco temos, em algumas empresas, o prazo para a aprovao de
determinados oramentos, que pode estender-se por um perodo imprevisvel, seja de 2 semanas,
seja de 2 meses, devido aos trmites burocrticos internos. Neste caso, poderamos criar uma tarefa
de durao zero intitulada Aprovao do oramento XXX, e indicar que todas as demais que a
tm como precedente somente se iniciaro quando esta ltima tiver se encerrado. Uma outra
alternativa seria realizar, de fato, uma estimativa acerca desta atividade conforme a frmula
sugerida acima, e respeitando-se experincias similares vivenciadas anteriormente.

Para exemplificarmos ainda mais o emprego dos marcos, analisemos o cronograma
ilustrado acima:

A atividade 1.5, Apresentao de Resultados, como refere-se a uma reunio com o
cliente para demonstrao dos dados levantados e analisados na pesquisa realizada, est
discriminada como um marco, por dois motivos: 1> Refere-se a uma atividade cuja
durao se estender, muito provavelmente, durante uma manh ou, no mximo, em um
determinado dia, e data esta que dever ser confirmada com o cliente proximamente sua
execuo; 2> uma atividade sem a qual a Fase I no poder ser considerada encerrada,
e fato este que, enquanto no ocorrer, as Fases II e III no podero ser iniciadas;
A atividade 2.6, Aprovao de peas publicitrias, pode ser realizada em uma simples
reunio, como tambm poder levar semanas. A insero desta atividade como um marco
deixa claro que, somente aps sua execuo que poderemos considerar concluda a Fase
II;
A Atividade 3.7, Equipe de vendas preparada, refere-se a um marco de encerramento
da Fase III. Contudo, esta insero em forma de marco no necessria neste caso, pois a
prpria concluso das atividades 3.5 (Treinamento das equipes de vendas) e 3.6
(Distribuio do material de divulgao kit do vendedor) indicaro o trmino da Fase
III com sucesso;
A atividade 2.4, Aprovao de oramentos, mesmo inserida como um marco, no
impede que a atividade seguinte, 2.5 (Elaborao de peas publicitrias) tenha seu
incio realizado antes mesmo que ela tenha sido vencida. Isso nos leva a acreditar que o
planejador do projeto considerou que os riscos associados ao incio prematuro da
atividade 2.5 so aceitveis em relao no concluso da atividade 2.4 (talvez o que se
pretenda que alguns trabalhos a serem executados na atividade 2.5, trabalhos estes que
no tenham a necessidade de investimentos e desembolsos significativos, possam ser
iniciados antes mesmo da aprovao integral do oramento. Contudo, de maneira geral,
consideramos temerria a execuo de atividades de implementao sem a devida
aprovao de seus oramentos correspondentes, o que nos leva a considerar que este
exemplo meramente de emprego didtico);
A atividade 3.4, Anlise jurdica do material de divulgao, devido incerteza quanto
sua durao estimada, foi inserida como um marco. Alm disso, ela pr-requisito para a
Pg. 49
continuao do projeto, pois sem o aval do departamento jurdico, o material de
divulgao no poder ser distribudo, bem como o treinamento dos vendedores no
poder ser iniciado.

Existe um grande problema em relao utilizao de marcos em cronogramas. O fato de
que, como os marcos possuem durao zero, as datas de encerramento de fases bem como do
projeto em si ficam artificialmente reduzidas. Aos olhos do cliente, pode-se chegar falsas
expectativas quanto entrega de resultados do projeto. Para mitigar estes riscos, devemos adotar
pelo menos uma das seguintes alternativas:

1> Relembrar, constantemente, aos executivos, que o cronograma dever ser ajustado,
renegociado e reapresentado todas as vezes que um marco for alcanado, pois sua
durao real somente poder ser conhecida ao trmino de sua execuo. Esta alternativa
poder causar algum desgaste na relao entre o gerente de projetos e seus clientes, que
podem ter uma interpretao pouco clara do fato, esquecendo-se do correto significado
dos marcos em cronogramas;
2> Ao invs de se utilizar marcos para representar tais tarefas, estimar sua durao da
mesma maneira como so realizadas as demais atividades do projeto. Neste caso, a
experincia interna dos planejadores ser importante fator a ser considerado na sua
definio e, talvez, seja uma boa ocasio para definir-se folgas, desde que aceitveis.

7.2. Matriz de Responsabilidades

Para cada atividade de um projeto necessria a atribuio de responsabilidades para sua
execuo. Uma sugesto de matriz de responsabilidade para a Fase I do projeto utilizado como
exemplo na pgina anterior seria como a seguinte:

Pg. 50

Exemplo de uma matriz de responsabilidades

importante ressaltar os seguintes aspectos em uma matriz de responsabilidades:

Nenhuma atividade deve ficar sem um, e um nico, responsvel. No caso do responsvel
ser tambm um executor, melhor indic-lo como o responsvel, pois havendo outro
executor, ficariam dvidas sobre qual deles seria o responsvel de fato;
Deve haver um nico responsvel por cada atividade, mas podem ser alocados sub-
responsveis, que atuariam em substituio ao mesmo no caso de sua ausncia. Ainda
neste caso, dever haver um nico interlocutor responsvel para cada tarefa;
No se recomenda que uma empresa terceira ou uma pessoa externa organizao seja
responsvel por alguma atividade. Neste caso, a recomendao de que algum da
equipe de projeto seja o responsvel pela atividade, e a empresa ou o terceiro seja
indicado como executor;
Podem ser considerados casos em que algumas pessoas participam da confeco da
atividade, ou devem ser informadas de seu andamento, sem no entanto serem
responsveis diretos pela sua execuo ou mesmo executores propriamente ditos;
Ressalta-se que, sempre que possvel, deve ser considerada a participao do usurio da
soluo e/ou do cliente do projeto (representados nesta matriz, respectivamente, pelo
gerente do produto e pelo executivo patrocinador);
Em alguns casos, podem ficar vazias algumas das clulas da matriz, indicando que aquele
participante no desempenha nenhum papel na atividade correspondente, o que no
significa que o mesmo no tenha participao efetiva em outras fases e atividades;
E
x
e
c
u
t
i
v
o

P
a
t
r
o
c
i
n
a
d
o
r
G
e
r
e
n
t
e

d
e

P
r
o
d
u
t
o
G
e
r
e
n
t
e

d
e

M
a
r
k
e
t
i
n
g
A
n
a
l
i
s
t
a

d
e

M
a
r
k
e
t
i
n
g
C
o
n
s
u
l
t
o
r

J
u
r
d
i
c
o
E
m
p
r
e
s
a

d
e

P
e
s
q
u
i
s
a
.
.
.

.
.
.

.
.
.
.
.
.

.
.
.

.
.
.
.
.
.

.
.
.

.
.
.
Fase I - Pesquisa de mercado
1.1 - Contratao de empresa especializada .
.
.
.
.
.
.
.
.
1.3 - Definio de respostas a serem obtidas .
.
.
.
.
.
.
.
.
1.5 - Apresentao de resultados .
.
.
.
.
.
.
.
.
... ... ...
... ... ...
... ... ...
Legenda:
Aprovao final
responsvel
Realiza
Participa / Deve ser informado
Pg. 51
Em muitos casos, gerentes e executivos podem no estar representados do ponto de vista
dos detalhes de implementao, mas idealmente devem estar alocados na apresentao,
validao e aceite dos resultados finais;
Excepcionalmente, podem ser contratados consultores externos ou administradores que
sejam vistos como responsveis por tarefas e atividades. Nestes casos especficos, pode
ser que eles tenham sido trazidos organizao no apenas para executar tarefas, mas
para conduzirem as mesmas como se fossem parte da prpria organizao contratante.
Desta forma, no consideramos que a responsabilidade estaria sendo delegada a um
terceiro comum, mas a um terceiro com plenas funes internas organizao,
assumindo um papel muito parecido com o de um profissional da empresa (profissional
este que poderia ser considerado o responsvel pela execuo das atividades previstas
para o projeto). Em todo caso, continuamos a reforar que apenas indivduos da prpria
organizao sejam os responsveis pelas tarefas. No caso dos consultores e/ou
administradores externos organizao, o mximo que lhes pode caber a execuo das
mesmas, sendo contra-indicado estabelec-los como responsveis.

7.3. Plano de Desembolso

Todos os recursos a serem estimados para um Projeto devem ser estabelecidos previamente,
o que permitir o detalhamento do oramento e do plano de desembolso do projeto. Naturalmente,
grande parte destas estimativas podero sofrer (e certamente sofrero) alteraes significativas no
decorrer do desenvolvimento do projeto. Ainda assim, o levantamento dos recursos com seus custos
associados deve aproximar-se o mximo possvel da realidade presumida, pois aumentos no
oramento de um projeto so dificilmente bem vistos aos olhos de quaisquer clientes ou executivos
envolvidos. Mais uma vez vale a mxima de se tentar jamais surpreender o cliente do projeto,
tentando-se, ao menor sinal de aumentos nos custos previstos, buscar-se alternativas que os
contornem adequadamente. Somente ao esgotarem-se todas as possibilidades e alternativas, devem
ser levados novos planos de ao a serem negociados junto aos executivos patrocinadores e clientes
do projeto.

Em cada fase/atividade, devem ser estabelecidos os recursos de pessoal, equipamentos,
mobilirio, material, software, instalaes e servios a serem empregados nas mesmas. Tais
recursos podem ser integral, parcial, adicional ou mesmo esporadicamente envolvidos em cada uma
das fases do projeto. Tais estimativas devem ser feitas a partir de unidades mensurveis e de
entendimento efetivo por parte dos executivos patrocinadores, como a quantidade de homens/hora,
a quantidade de materiais ou seu consumo mdio como, por exemplo, a utilizao de telefone, papel
e cartuchos de impresso, entre outros.

Nesta seo, tambm devem ser consideradas as especificaes detalhadas para os tipos de
equipamentos, programas de computador, servios de treinamento e capacitao para a equipe,
viagens eventualmente necessrias (com as respectivas despesas de traslado, hospedagem,
deslocamento local e alimentao), caractersticas das instalaes fsicas onde se alocar a equipe
do projeto, custos de conexes a redes internas e externas (por exemplo, Internet), nmero de
aparelhos, linhas e ramais telefnicos, FAX, secretria, livros e publicaes necessrios para que se
atinja a qualificao adequada para o desenvolvimento do projeto, entre outros.

Vejamos um exemplo de Plano de Desembolso, conforme o Oramento Preliminar
desenvolvido no captulo anterior:
Pg. 52

Exemplo do Plano de Desembolso de um Projeto

Observar as totalizaes do plano de desembolso ao longo do projeto, tanto de maneira
geral, (coluna TOTAIS) quanto em relao a cada item em especfico, bem como a cada perodo
de desembolso considerado (mensal).

Este demonstrativo, tambm denominado cronograma fsico-financeiro, apresenta de forma
clara os elementos que realmente geram custos para o projeto, apontando os seus principais
gargalos, bem como apresentam os itens que trazem valor organizao sob a forma de
investimentos a serem conduzidos.

7.4. Produtos e Sub-Produtos

Cada uma das fases de um projeto deve apresentar, em sua concluso, produtos e sub-
produtos a serem entregues como resultados de sua execuo. Neste caso, o que caracteriza a
concluso de uma fase ou atividade justamente a disponibilizao dos produtos e sub-produtos
gerados atravs de sua execuo. Os produtos referem-se materializao dos objetivos e resultados
esperados pelo projeto. Os sub-produtos, por sua vez, tambm chamados entregas, so resultados
parciais ou intermedirios obtidos no decorrer do projeto, e significam a concluso de fases e
atividades internas especficas. Todos eles devem ser concebidos a priori, devendo tambm ser
Investimentos jan/2001 fev/2001 mar/2001 abr/2001 mai/2001 jun/2001 TOTAIS
Hardware
Servidores 40.000,00 70.000,00 110.000,00
Estaes de Trabalho 10.000,00 25.000,00 50.000,00 85.000,00
Impressoras 4.000,00 4.000,00 8.000,00 16.000,00
Equipamentos de Rede 1.500,00 3.000,00 6.000,00 10.500,00
Sub-total Hardware 55.500,00 0,00 102.000,00 0,00 64.000,00 0,00 221.500,00
Software
Windows 2000 6.000,00 10.000,00 20.000,00 36.000,00
Ferramentas de Desenvolvimento 12.800,00 12.800,00
Bancos de Dados 4.000,00 8.000,00 12.000,00
Backup 3.000,00 3.000,00
Anti-vrus 1.500,00 2.500,00 5.000,00 9.000,00
Sub-total Software 27.300,00 0,00 20.500,00 0,00 25.000,00 0,00 72.800,00
Servios
Treinamento 15.000,00 15.000,00
Consultoria 8.500,00 8.500,00 8.500,00 25.500,00
Sub-total Servios 15.000,00 0,00 8.500,00 8.500,00 8.500,00 0,00 40.500,00
TOTAL INVESTIMENTOS 97.800,00 0,00 131.000,00 8.500,00 97.500,00 0,00 334.800,00
Custos / Despesas (em 6 meses) jan/2001 fev/2001 mar/2001 abr/2001 mai/2001 jun/2001 TOTAIS
Suprimentos
Papel 100,00 100,00 100,00 300,00 300,00 300,00 1.200,00
Toner para impressora 500,00 500,00 1.000,00 1.000,00 2.000,00 2.000,00 7.000,00
Material de escritrio 250,00 250,00 250,00 250,00 250,00 250,00 1.500,00
Sub-total Suprimentos 850,00 850,00 1.350,00 1.550,00 2.550,00 2.550,00 9.700,00
Servios
Contrato de manuteno 14.000,00 14.000,00 28.000,00
Sub-total Servios 14.000,00 0,00 14.000,00 0,00 0,00 0,00 28.000,00
TOTAL CUSTOS / DESPESAS 14.850,00 850,00 15.350,00 1.550,00 2.550,00 2.550,00 37.700,00
TOTAL GERAL 112.650,00 850,00 146.350,00 10.050,00 100.050,00 2.550,00 372.500,00
Pg. 53
estabelecidos os seus parmetros de qualidade a serem atendidos conforme as expectativas dos
clientes do projeto.

Os produtos e sub-produtos so, na verdade, a principal moeda que os lderes de projeto
possuem para justificar os investimentos realizados nas iniciativas e empreendimentos sob sua
responsabilidade, pois representam a efetiva obteno dos resultados esperados pelos executivos e
clientes e para avalizar sua conduo em relao s expectativas estabelecidas pela organizao
quanto ao projeto.

Vejamos, ainda de acordo com a Fase I do projeto hipottico de marketing apresentado
anteriormente, uma provvel especificao de produtos e entregas para cada uma de suas atividades
correspondentes:

Fase I - Pesquisa de mercado Produtos / Entregas
1.1 - Contratao de empresa especializada
Contrato com empresa especializada em pesquisas de
mercado, com aprovao do consultor jurdico. Este
contrato dever prever, entre os aspectos legais normais, o
detalhamento do seguinte escopo:

Levantamento dos objetivos da pesquisa, em parceria
com o contratante;

Elaborao dos instrumentos de coleta de dados;

A efetiva realizao da pesquisa;

Anlise dos resultados da pesquisa em funo do
lanamento do novo produto e das necessidades da
empresa;

Apresentao dos resultados da pesquisa ao corpo
executivo da organizao.
Documento que discrimina quais sero os objetivos da
pesquisa de mercado a ser conduzida, em funo do
lanamento do novo produto
1.3 - Definio de respostas a serem obtidas
Documento que estabelece os instrumentos de coleta de
dados, seu contedo, a metodologia de aplicao dos
mesmos, a composio da amostragem a ser utilizada bem
como a discriminao de como os resultados podero ser
apurados a partir dos mtodos empregados na pesquisa;
Instrumentos de coleta de dados preenchidos;
Anlise de resultados realizada;
Concluses e recomendaes estabelecidas;
Apresentao executiva da pesquisa preparada e
agendada.
1.5 - Apresentao de resultados
Apresentao executiva dos resultados da pesquisa de
mercado realizada
Exemplo de relao de produtos e entregas da Fase I de um projeto hipottico

Observe o nvel de detalhamento de cada um dos produtos e entregas a serem gerados ao
longo da concluso de cada uma das fases e atividades respectivamente associadas, o que tambm
objetiva-se a dirimir quaisquer dvidas acerca dos resultados finais ou intermedirios a serem
produzidos pelo projeto.

Pg. 54

7.5. Plano de Comunicao

Para que todos os membros e participantes de um projeto troquem as informaes
necessrias para a adequada conduo de seus trabalhos, devem ser estabelecidos planos para a
comunicao bem como para o controle das alteraes eventualmente necessrias, alteraes estas
principalmente relacionadas aos prazos, custos e escopo do projeto.

O plano de comunicao deve contemplar, pelo menos, os seguintes itens:

Que tipos de informaes devero ser levantadas para acompanhamento e aes
corretivas?
Informaes financeiras, relativas ao desembolso promovido pelo projeto;
Informaes de cronograma, como atrasos, antecipaes, folgas, etc.;
Informaes relacionadas aos riscos do projeto;
Informaes relacionadas aos problemas e conflitos gerados ao longo do projeto;
Informaes relacionadas aos fornecedores de produtos e servios do projeto;
Informaes relativas ao cumprimento de etapas, atendimento de funcionalidades,
desempenho do projeto, lies aprendidas, entre outras;
Como e em que frequncia ser realizada a troca de informaes ao longo do projeto.
Exemplos:
e-Mails para troca de informaes operacionais;
Brainstormings para soluo de problemas;
Brainstormings para levantamento e anlise de lies aprendidas, principalmente aps
cada resoluo de problema, bem como ao trmino de cada uma das fases do projeto;
Relatrios semanais de posicionamento;
Checklists para acompanhamento de tarefas operacionais;
Reunies semanais de acompanhamento e controle (com ata);
Reunies quinzenais de posicionamento aos executivos patrocinadores (com ata).
Onde sero realizadas as reunies de acompanhamento e quando. Neste caso, mesmo
tendo sido estabelecida a frequncia de alguns tipos de reunio, alguns encontros podem
ser marcados com antecedncia prvia, uma vez que geralmente so conhecidos e
determinados os diversos pontos de controle (checkpoints) das principais fases do projeto,
previstos em cronograma;
Quem dever ser informado, e com qual antecedncia, para a participao nas reunies de
acompanhamento;
Quem ser o responsvel pela produo, guarda e recuperao das informaes e
documentos produzidos ao longo do projeto;
Como e em que local sero armazenadas as informaes pertinentes ao projeto (Ex.
repositrio de documentos, ou pastas e arquivos fsicos, ou pastas de documentos
eletrnicos);
Quais sero os modelos de formulrios a serem utilizados ao longo do projeto, como nos
seguintes casos:
Requisies de alterao de escopo;
Atas de reunio;
Checklists para acompanhamento de atividades e pendncias;
Relatrios de desempenho, em termos de custos, prazos e funcionalidades atendidas;
Relatrios de problemas.

Pg. 55
Outros aspectos especficos devem ser analisados e previstos nesta fase, de forma a prever
eficientes formas de troca de informaes ao longo de um projeto, no somente entre os
participantes diretos do projeto, mas em relao a toda a organizao ao que o mesmo se insere.

importante ressaltar que um plano de comunicaes efetivamente executado
necessariamente leva excelncia do controle do projeto, pois pode evitar desembolsos adicionais e
atrasos e perdas de funcionalidades j previstas em funo de decises tomadas sem a antecedncia
e o nvel de conhecimento global adequados.

Pg. 56
8. Negociao e Alocao de Recursos

Cada recurso a ser empregado em um projeto deve ser cuidadosamente planejado, de forma
que sua no utilizao ou desperdcio possa minar a credibilidade da equipe de projeto, bem como
do projeto em questo e de todos os outros que venham posteriormente a ser desenvolvidos pelo
mesmo pessoal. Alm disso, para que um Plano de Execuo tenha efetiva credibilidade, o mesmo
deve ser validado por todos os fornecedores de recursos para o projeto. Por exemplo, se um
determinado profissional requisitado para um conjunto de tarefas do projeto, o responsvel por ele
deve se comprometer a disponibiliz-lo nas datas e prazos estabelecidos previamente, sob pena de
inviabilizar o cronograma estabelecido. Essa regra vale tambm para os demais recursos
considerados necessrios para a execuo do projeto.

Em outras palavras, um Plano de Execuo somente poder ser considerado validado
quando todos os participantes de um projeto estiverem comprometidos com o que nele estiver
contido.

8.1. Negociando a Alocao de Profissionais

Quanto alocao de pessoas em fases especficas do projeto, deve haver uma previso
razovel das datas mais provveis do incio de seu envolvimento, com significativa antecedncia ao
momento da real necessidade, e de forma a se respeitar o atual envolvimento do profissional em
outros projetos ou atividades consecutivas. Da mesma forma, devem ser respeitados os perodos de
alocao de um profissional a um projeto de forma a devolv-lo a sua rea original ao trmino de
sua participao no mesmo.

A tarefa de negociao de recursos, sobretudo os que se referem participao de
profissionais nos projetos, apresenta-se como um grande paradoxo organizacional. Da mesma
maneira que certas reas da empresa demandam por novas solues tecnolgicas, mesmo
considerando que seus melhores colaboradores sejam envolvidos em perodo integral aos novos
projetos, seus gerentes funcionais podem relutar veementemente em ced-los. O argumento para
esse comportamento baseia-se no fato que os seus colaboradores mais eficientes no poderiam
abandonar suas atividades dirias em favor dos novos projetos, pois isso prejudicaria o desempenho
de seu setor funcional como um todo.

Este tipo de caso revela-se como grande potencial de conflitos a serem gerenciados pelos
responsveis por um projeto. Uma boa estratgia de negociao sugerida para possibilitar a
participao destes profissionais nos projetos seria o de considerar tal alocao como um
investimento interno efetivo, o que necessariamente deve vislumbrar retornos significativos para
ambas as partes. Devem-se apontar as melhorias e os benefcios que o projeto trar rea funcional
a ser temporariamente "desfalcada" de seus melhores profissionais em favor do projeto. O retorno a
ser oferecido deve visar, necessariamente, a ganhos de produtividade consistentes aps a concluso
do projeto, o que justificaria o envolvimento daquele profissional por um perodo determinado de
tempo, ainda que no integralmente dedicado ao mesmo.

Pg. 57

8.2. Negociando a Alocao de Recursos Fsicos

Quanto alocao de equipamentos e materiais diversos, deve-se preferencialmente tentar-
se a utilizao de recursos j existentes na organizao, economizando-se investimentos adicionais.
Alm disso, deve-se verificar o destino dos mesmos aps sua utilizao pela equipe do projeto. Por
exemplo, considere a aquisio de um equipamento de alto desempenho para a simulao do
ambiente operacional de produo, em um projeto que se presta construo de um prottipo para
uma nova soluo tecnolgica. Poderia se argumentar que, ao trmino do projeto, tal equipamento,
caro e sofisticado, ficaria sem utilidade, desperdiando o investimento realizado no mesmo. Neste
caso, deveria ser levantada a possibilidade do mesmo equipamento ser utilizado em outros projetos
em andamento, tentando-se a maximizao de seu emprego nos mesmos. Por exemplo, o
equipamento poderia ser empregado para os testes de outras solues em desenvolvimento, ou a ser
utilizado como contingncia s solues j existentes, no caso de falhas operacionais. Ainda, o
mesmo equipamento poderia ser utilizado como plataforma base para um ambiente de laboratrio
para novos projetos que estejam sendo vislumbrados. Na prtica, o que normalmente acontece que
muitos dos equipamentos e recursos definidos para a execuo de um projeto ganham uma
finalidade justamente baseada na nova soluo a ser implementada. Em outras palavras, os recursos
utilizados no projeto de maneira geral ficam vinculados configurao da prpria soluo a ser
desenvolvida.

Pode ser que a prpria empresa j possua um pool de recursos a serem especificamente
alocados a novos projetos, o que evitaria novas e contnuas aquisies. Como um projeto deve
possuir marcos bem definidos, tais recursos devem ser colocados disposio da empresa medida
que seu uso no seja mais necessrio, favorecendo o desenvolvimento de outros projetos.

Uma outra alternativa para a alocao de recursos temporrios em projetos pode ser o
aluguel de equipamentos por um perodo especfico, bem como a contratao eventual de servios
de terceiros para a execuo de tarefas bem definidas.

Pg. 58
9. Gerncia de Riscos

9.1. Definio de Risco

Risco a possibilidade de se sofrer uma perda. A perda poder ser de qualquer coisa,
desde a diminuio de qualidade de uma soluo at o aumento do custo de um projeto, o
atraso em prazos ou mesmo o fracasso geral do projeto.

Uma outra boa definio de risco a seguinte: um problema esperando para acontecer.

9.2. Caractersticas do Risco

Riscos so inerentes a qualquer projeto: o risco um ingrediente fundamental da
oportunidade e sendo intrnseco a qualquer projeto;

Os riscos no so intrinsecamente bons nem ruins;

O risco no deve ser visto como algo a ser temido, mas como algo a ser gerenciado:
equipes de sucesso gerenciam os riscos reconhecendo-os minimizando as incertezas
associadas aos mesmos, atravs de aes proativas para cada um dos riscos identificados.

9.3. Princpios de uma Gerncia de Riscos bem sucedida

Riscos envolvem pessoas, processos e tecnologia. Para um gerenciamento eficaz dos
riscos em um projeto devemos considerar os seguintes princpios:

Avaliar os riscos continuamente ao longo do ciclo de vida do projeto: mais do que
identificar os riscos no incio do projeto, uma boa gerncia de riscos requer a constante
avaliao dos mesmos ao longo da vida do projeto, devido ao fato que novos riscos so
revelados ao longo do projeto. Alm disso, os riscos j identificados podem se tornar
mais ou menos provveis, ou mais ou menos severos durante a evoluo do projeto;

Utilizar-se de tomada de decises baseada em riscos: todas as decises devem ser
tomadas no contexto dos seus riscos associados. As aes da equipe devem ser
priorizadas de forma relacionada aos riscos. Assim, os itens de risco mais elevado
devem ser gerenciados em primeiro lugar;

Estabelecer algum nvel de formalidade: um gerenciamento eficaz de riscos requer um
processo que seja compreendido e utilizado pela equipe. Isso no significa que o
processo deve ser uma metodologia estrita, mas deve ser empregada uma grande
parcela de disciplina em um processo estruturado. Se o processo de gerncia de risco
configurar-se como de grande dificuldade, a gerncia de risco no ocorrer de fato. Se o
processo no for estruturado, o mesmo no ser til, e eficaz;

Cobrir todas as pessoas e processos-chave: um gerenciamento de riscos eficaz considera
que a equipe procure por riscos em quase todos os lugares em um projeto. A equipe
Pg. 59
deve garantir que as pessoas-chave sejam efetivamente envolvidas, e em todos os
processos envolvidos com o projeto;

Buscar a identificao de riscos de forma positiva: para que a gerncia de riscos seja
efetiva, os membros da equipe devem estar desejosos de identificar os riscos sem o
medo da punio ou da crtica. A identificao dos riscos significa que poder haver
menos surpresas para uma equipe pois, quando um risco identificado, a equipe poder
preparar-se para ele e, espera-se, evitar que o mesmo ocorra ao longo do projeto.

9.4. Origens dos Riscos

Os riscos podem ser originados de muitas fontes, entre elas:

Da misso ou dos objetivos do projeto;
Dos tomadores de deciso, ou do gerenciamento organizacional;
Dos clientes ou dos usurios finais;
Do oramento, dos custos, do cronograma e das pessoas envolvidas no projeto;
Das caractersticas do projeto;
Do processo de desenvolvimento ou da cultura organizacional;
Do ambiente de operaes da organizao;
De uma nova tecnologia;
De aspectos legais, governamentais, econmicos, polticos, entre outros.

9.5. Impactos dos Riscos

Os riscos podem afetar um projeto de uma srie de maneiras:

Aumento dos custos e atrasos nos cronogramas;
Funcionalidade inadequada;
Projetos cancelados;
Mudanas sbitas de pessoal ou a desmoralizao da equipe;
Insatisfao do cliente;
Prejuzo imagem da companhia;
Performance ruim;
Problemas legais.

Pg. 60
9.6. Gesto Proativa de Riscos

A gerncia proativa de riscos significa que a equipe de projeto possui um processo visvel,
mensurvel e repetvel para o tratamento dos riscos. Este processo deve identificar, analisar e
enderear os riscos de forma proativa. Sendo assim, vejamos como seria uma comparao entre a
gesto proativa e reativa de riscos:

Gerncia Proativa de Riscos Gerncia Reativa de Riscos
Antecipar problemas vs Resolver problemas a medida que os
mesmos ocorram
Considerar a raiz dos problemas vs Considerar as consequncias dos problemas
Evitar e minimizar os riscos atravs da
mitigao
vs Reagir s consequncias
Preparar-se para as consequncias para
minimizar o impacto
vs Reagir a crises
Utilizar um processo estruturado vs Utilizar um processo ad hoc, ou aleatrio

9.7. Estratgias para o Gerenciamento de Riscos

Reduo do risco:
Tentativa de minimizar a probabilidade de que um risco ocorra, ou seja, de sua causa
(condio);
Ex. Construo de um armazm com materiais prova de fogo;
Tentativa de minimizar o impacto do risco, caso o mesmo venha a ocorrer
(consequncia);
Ex. Instalao de extintores de incndio automticos.

Transferncia do risco:
Repasse do risco para outra entidade;
Ex. 1> Contratao de um seguro contra incndio (o risco repassado para outra
empresa);
Ex. 2> Contratao de pessoal terceirizado para a gerncia da segurana contra
incndio;

Evitar o risco:
Eliminar o risco realizando algo menos arriscado;
Ex. 1> Construir algo menos sujeito a incndio do que um armazm;
Ex. 2> Adotar uma tecnologia j provada pelo mercado, ao invs de uma tecnologia de
ponta, ainda sujeita adeso pelo mercado.

Pg. 61
9.8. O Processo de Gerenciamento de Riscos

Passos do Processo de Gerenciamento de Riscos

Os passos relativos ao processo de gerenciamento de riscos so os seguintes:

1. Identificao dos Riscos
2. Anlise dos Riscos;
3. Elaborao de Planos de Tratamento dos Riscos;
4. Acompanhamento dos Riscos;
5. Controle dos Riscos.

Veremos, a seguir, como se estrutura cada um destes passos.

9.8.1. Identificao dos Riscos

Trazer os riscos superfcie de forma que os mesmos possam ser tratados sem que
impactem o projeto. Para efetivamente descobrir e reconhecer riscos potenciais:
Empregue uma abordagem colaborativa;
Examine os problemas potenciais de diversas fontes;
Examine os riscos de duas direes:
Causas potenciais e suas consequncias provveis;
Consequncias potenciais e suas causas provveis;
Ex. Identificao do fogo como um risco potencial a um armazm;
Elabore declaraes de risco: devem estabelecer de forma e clara e simples a condio
(causa) e a consequncia (efeito) de cada risco.
Ex. Lquidos inflamveis podem ser mantidos no armazm (causa ou condio), o que
pode provocar incndio no armazm (impacto / consequncia).

Anlise
Planejamento
Identificao
Acompanha-
mento
Controle
Declaraes
de Risco
Documento
de Avaliao
de Riscos
Top 10
Riscos
Retirados
O desenvolvimento contnuo deste processo gera um Documento de
Avaliao de Riscos Vivo, ou seja, em permanente mutao
Pg. 62
Como um exemplo um pouco mais elaborado para o estabelecimento de um armazm,
vejamos como poderemos elaborar diversas declaraes de riscos:

Exemplos de declaraes de risco para o estabelecimento de um armazm

A partir de agora em nosso exemplo estaremos nos detendo apenas no tratamento de riscos
vinculados ao caso de incndio, apenas para facilitar a discusso sobre o gerenciamento de riscos.

9.8.2. Anlise dos Riscos

Converter os dados de risco em informaes que a equipe pode utilizar para tomar
decises (Ex. Compreenso do que poderia causar fogo em um armazm e o quo
custoso seria o prejuzo causado pelo mesmo). Uma adequada anlise de riscos
compreende as seguintes etapas:
Avaliao da probabilidade do risco:
Utilize uma escala numrica para facilitar os clculos;
Represente uma escala numrica que seja padro para todo o projeto (Ex. Alto = 3 / Mdio
= 2 / Baixo = 1, ou , Alto = 75% / Mdio = 50% / Baixo = 25%);
Ex. Devido ao fato que o armazm possui itens inflamveis, a probabilidade de um
incndio alta
Avaliao do impacto do risco:
Tambm utilize uma escala numrica, de forma a facilitar os clculos;
Para impactos financeiros, preferencialmente utilize valores monetrios, pois eles
representam melhor tais impactos (Ex. Impacto do risco = R$500.000,00);
Se o impacto no financeiro, utilize uma escala numrica (Ex. 5, 4, 3, 2, 1);
No misture as escalas escolhidas;
Declaraes de riscos em relao ao estabelecimento de um armazm
Causa leva Consequncia
Vndalos podem gerar depredao e estragos diversos
Ladres podem roubar materiais e dinheiro
Intempries podem gerar inundaes
Intempries podem gerar desabamentos
Armazenamento / presena de material inflamvel pode acarretar incndio
Ms condies de armazenamento podem acarretar incndio
Mal gerenciamento pode trazer prejuzo financeiro
M superviso nos estoques podem trazer perda de produtos (prazo de validade)
M superviso nos estoques pode acarretar problemas junto a clientes
Servios de venda inadequados podem acarretar problemas junto a clientes
... ... ...
... ... ...
... ... ...
Especificamente em relao ao risco de incndio:
Causa leva Consequncia
Fumantes podem gerar incndio
Bales juninos / aeromodelos podem gerar incndio
Armazenamento / presena de material inflamvel pode acarretar incndio
Armazenamento de determinados produtos qumicos podem gerar incndio
Incidncia de raios podem acarretar incndio
Sabotadores e vndalos podem gerar incndio
Instalaes eltricas mal feitas podem gerar incndio
... ... ...
... ... ...
... ... ...
Pg. 63
Ex. Se o armazm se incendiar, ir custar R$500.000,00 reconstru-lo e repor todo o seu
contedo;
Clculo da exposio ao risco:
Exposio = Probabilidade X Impacto;
Ex. 75% X R$500.000,00 = R$375.000,00, ou , O risco de incndio no armazm possui
uma exposio de R$375.000,00;
Utilize-a para comparar as prioridades dos riscos;
Crie um ranking dos riscos e de seu gerenciamento do maior ao menor grau de exposio.

Prosseguindo com a anlise de riscos de incndio em nosso armazm, vejamos como
poderamos quantificar a probabilidade e o impacto, bem como calcular o grau de exposio de
cada uma das possibilidades:

Considerando que, quanto maior for o Grau de Exposio a um risco, mais o risco deve ser
considerado, devemos priorizar o tratamento de riscos em funo desta varivel:

Anlise do risco de incndio de um armazm:
# Descrio
Probabilidade
Ocorrncia
Impacto
Grau de Exposio
(% Risco X Impacto)
1 Incndio devido a fumantes 3 1 3
2 Incndio devido incidncia de bales juninos /
aeromodelos
1 2 2
3 Incndio devido a armazenamento / presena de
material inflamvel
3 3 9
4 Incndio devido a armazenamento inadequado de
determinados produtos qumicos
2 3 6
5 Incndio devido incidncia de raios 1 3 3
6 Incndio devido atuao de sabotadores e
vndalos
1 3 3
7 Incndio devido a instalaes eltricas mal feitas
2 3 6
8 ... ... ... ...
9 ... ... ... ...
10 ... ... ... ...
Priorizao do tratamento do risco de incndio (em funo do grau de exposio):
# Descrio
Probabilidade
Ocorrncia
Impacto
Grau de Exposio
(% Risco X Impacto)
1 Incndio devido a armazenamento / presena de
material inflamvel
3 3 9
2 Incndio devido a armazenamento inadequado de
determinados produtos qumicos
2 3 6
3 Incndio devido a instalaes eltricas mal feitas
2 3 6
4 Incndio devido a fumantes 3 1 3
5 Incndio devido atuao de sabotadores e
vndalos
1 3 3
6 Incndio devido incidncia de raios 1 3 3
7 Incndio devido incidncia de bales juninos /
aeromodelos
1 2 2
8 ... ... ... ...
9 ... ... ... ...
10 ... ... ... ...
OBS. Notar que a numerao dos riscos foi alterada em funo das respectivas priorizaes
Pg. 64

9.8.3. Elaborao de Planos de Tratamento dos Riscos

Converso das informaes em decises;
Priorizao de decises de planejamento baseadas na prioridade dos riscos;
Ex. Planejar como evitar o incndio em um armazm e o que fazer se isso ocorrer;
Considerar as cinco reas de atuao chave:
Pesquisa: voc conhece o bastante sobre o risco?
Aceitao: voc pode viver com as consequncias do risco?
Evitar: Voc pode evitar o risco?
Mitigao: voc pode reduzir a probabilidade ou o impacto do risco?
Priorizar os riscos de alto grau de exposio;
Considerar as condies de forma a tentar reduzir a probabilidade;
Enxergar as causas como opostas aos sintomas;
Considerar as consequncias de forma a minimizar o impacto;
Existem 2 tipos de mitigao
Mitigao da Causa: objetiva-se a reduzir a probabilidade de ocorrncia do risco;
Ex. 1> A companhia ir instituir uma poltica de no-fumantes para reduzir a probabilidade
de um incndio causado por cigarros;
Ex. 2> Realizarmos manutenes peridicas nos sistemas de fiao eltrica de forma a
procurar evitar a incidncia de curtos-circuitos bem como substituir material inadequado;
Mitigao da Consequncia: objetiva-se a reduzir o impacto do risco;
Ex. 1> Instalao de extintores de incndio, bem como esguichadores de gua (sprinkers)
acoplados a sensores de fumaa;
Ex. 2> Realizao de treinamento com a brigada de incndio, com testes e simulaes, de
forma a possibilitar capacitao interna para aes no caso de incndio;
Contingncia: voc pode reduzir o impacto atravs de uma reao planejada?
Priorizar os riscos de alto grau de exposio;
Planejar como reagir s consequncias;
Os planos de contingncia devem ser acionados tanto na iminncia do evento de risco quando
aps a ocorrncia, de fato, do mesmo;
Devem ser estabelecidas condies para determinar quando executar os planos de contingncia:
Dead-line ou data-limite: pontos no tempo, referentes a datas, geralmente a ltima data em
que um determinado evento deve ocorrer;
Ex. 1> Se a empresa contratada no confirmar sua presena at uma semana antes do
evento, ento deve-se partir para a contratao de uma empresa alternativa";
Ex. 2> Se o atleta XXX no se recuperar da contuso no joelho at 3 dias antes do
encerramento do prazo de inscrio no campeonato, convocaremos o atleta YYY para
compor a equipe;
Condio-limite: eventos ou fatos que podem ser medidos ou contados:
Ex. 1> A evidncia fsica de incndio autoriza qualquer pessoa da empresa a acionar o
alarme de emergncia e a acionar o corpo de bombeiros;
Ex. 2> Se o trfego de rede atingir 75% de carga, iniciaremos a instalao emergencial de
antenas extras para suportar as telecomunicaes na regio, evitando o congestionamento
iminente das linhas;
Ex. 3> Se o fluxo de carros na avenida principal chegar a 500 veculos por minuto,
convocaremos os policiais para o controle do trnsito, de forma a no prejudicar o andamento
da obra;

Dados os riscos de incndio considerados, como poderia ficar o plano de tratamento aos
riscos em termos de suas aes possveis? A planilha a seguir apresenta possibilidades:

Pg. 65

Plano de tratamento ao risco de incndio
# Descrio do Risco
Ao
#
rea de Atuao Descrio da Ao Data Limite (2)
Condio
Limite (3)
1 Incndio devido a presena de
material inflamvel
1 Pesquisa Informar-se a respeito da inflamabilidade dos materiais em estoque
2 Pesquisa
Informar-se a respeito da inflamabilidade das paredes, portas, mobilirio e demais
condies do imvel
3 Evitar No armazenar material inflamvel nos estoques
4 Evitar
No utilizar-se de material de construo e mobilirio inflamvel na construo do
armazm
5 Mitigao (Causa)
Substituir mobilirio inflamvel / materiais de construo por itens menos propensos a
incndio (1)
6 Mitigao (Causa) Solicitar revises peridicas das instalaes junto ao Corpo de Bombeiros
7 Mitigao (Causa) Treinamento dos funcionrios para adotarem cuidados no manuseio de material inflamvel
8
Mitigao
(Consequncia)
Acondicionar o material inflamvel em local especfico, protegido e isolado (4)
9
Mitigao
(Consequncia)
Instalao de extintores de incndio, sensores de incndio, sprinkers e demais
dispositivos de combate ao fogo
10
Mitigao
(Consequncia)
Treinamento da brigada de incndio interna, constituda pelos prprios funcionrios
11
Mitigao
(Consequncia)
Afixar quadros de aes prticas, bem como telefones de emergncia, em locais visveis e
estratgicos, de forma a permitir um rpido acionamento de providncias
12
Mitigao
(Consequncia)
Contratao de seguro contra incndio
13 Contingncia Acionamento do alarme geral contra incndios
Deteco do
incndio
14 Contingncia Acionamento da brigada de incndio
Deteco do
incndio
15 Contingncia Acionamento do corpo de bombeiros
Deteco do
incndio
16 Contingncia Acionamento da empresa seguradora
At 2 dias aps o
controle do
incndio
2 Incndio devido a armazenamento
inadequado de determinados
produtos qumicos
17 Pesquisa
Informar-se a respeito da inflamabilidade dos produtos qumicos armazenados no estoque
(pode ser implementado em conjunto com a ao 01)
18 Evitar No armazenar produtos qumicos potencialmente perigosos no estoque
19 Mitigao (Causa)
Acondicionar material qumico suspeito em local fisicamente seguro (pode ser
implementado de forma similar ao 5)
20 Mitigao (Causa)
Treinamento dos funcionrios para adotarem cuidados no manuseio de material
quimicamente perigoso (pode ser implementado conjuntamente com a ao 8)
Pg. 66

Plano de tratamento ao risco de incndio (cont.)
# Descrio do Risco
Ao
#
rea de Atuao Descrio da Ao Data Limite (2)
Condio
Limite (3)
3 Incndio devido a instalaes
eltricas mal feitas
21 Pesquisa
Informar-se a respeito das condies ideais e das condies atuas idas instalaes
eltricas do armazm
22 Mitigao (Causa) Realizar revises peridicas das instalaes eltricas do estabelecimento
23 Mitigao (Causa)
Utilizar-se de material eltrico no inflamvel e de baixa emisso de calor (esta ao j
poder estar sendo coberta pelas aes 4 e/ou 6)
24 Mitigao (Causa)
Realizar programa de educao dos funcionrios em relao utilizao de aparelhagem
eltrica (pode ser realizado conjuntamente com a ao 8)
4 Incndio devido a fumantes
25 Mitigao (Causa)
Proibir a prtica do fumo nas instalaes do armazm, o que inclui no permitir que
funcionrios fumantes faam uso das instalaes do armazm, ou mesmo sequer
contrat-los
26 Mitigao (Causa) Estabelecer local prprio para a prtica do tabagismo, isolado e fora de perigo
27 Mitigao (Causa)
Realizar campanhas de educao em relao prtica do tabagismo, incluindo
treinamento e afixao de cartazes (pode ser realizado conjuntamente com a ao 8)
5 Incndio devido atuao de
sabotadores e vndalos
28 Pesquisa
Informar-se a respeito da presena de indivduos suspeitos na regio do armazm, bem
como em relao proximidade do estabelecimento em relao a penitencirias, favelas,
etc.
29 Mitigao (Causa) Contratao de servios de segurana
30 Mitigao (Causa)
Estabelecer vnculos de relacionamento efetivos com o policiamento local, de forma a
solicitar agilidade no atendimento a eventuais suspeitas de presena de vndalos e
sabotadores
6 Incndio devido incidncia de
raios
31 Pesquisa
Informar-se a respeito da incidncia de chuvas e de descargas eltricas na regio do
estabelecimento
32 Mitigao (Causa)
Realizar manutenes preventivas e peridicas do sistema de aterramento e de controle
de descargas atmosfricas
7 Incndio devido incidncia de
bales juninos / aeromodelos
33 Pesquisa
Informar-se a respeito da ocorrncia de festas populares e de campos de aeromodelismo
prximos ao estabelecimento
34 Mitigao (Causa) Aumento da vigilncia em meses de festas juninas
35 Mitigao (Causa)
Aumento da vigilncia nas redondezas, em relao prtica de aeromodelismo e de
bales juninos
36 Mitigao (Causa)
Elaborao de campanhas educativas junto populao de forma a alert-las para os
riscos dos bales juninos, por exemplo
8 ... ... ... ... ... ...
9 ... ... ... ... ... ...
10 ... ... ... ... ... ...
OBS. (1) No caso do armazm j estar construdo
(2) Este campo tambm chamado dead-line , e utilizado apenas quando trata-se de uma ao de contingncia
(3) Este campo utilizado apenas quando trata-se de uma ao de contingncia
(4) Esta ao tambm poderia ser considerada como Mitigao (Causa), pois poderia pressupor uma maior disciplina no acesso ao material inflamvel, o que minimizaria as chances de
incndio por uma m administrao dos mesmos
Pg. 67
9.8.4. Acompanhamento dos Riscos

Monitoramento do status dos riscos e de quaisquer aes tomadas para mitig-los;
O acompanhamento de riscos deve ser tratado como um exerccio contnuo a ser
executado ao longo do ciclo de vida do projeto;
Os riscos devem ser monitorados em relao a quaisquer mudanas nas condies ou
consequncias;
Devem ser medidos os efeitos dos planos de mitigao;
As condies para acionamento da contingncia devem ser monitoradas
continuamente;

9.8.5. Controle dos Riscos

Mover o gerenciamento dos riscos para uma atividade diria do gerenciamento de
projetos, o que crucial para certificar-se de que esta atividade seja considerada de alta
importncia para o sucesso do projeto. Para efetivamente controlar os riscos, deve-se:
Adaptar as mudanas em termos das prioridades dos riscos;
Reagir s variaes do plano;
Responder aos eventos e condies para acionamento dos planos de contingncia aos
riscos;
Avaliar o processo de gerenciamento de riscos;
Retirar os riscos que tenham sido efetivamente mitigados.

9.9. O Documento de Avaliao de Riscos

Para obter o mximo de benefcios do gerenciamento de riscos, o documento de avaliao de
riscos deve ser utilizado para:
Priorizar o esforo;
Orientar as decises;
Ressaltar as dependncias;
Determinar cronogramas;
Gerenciar a orientao a todos os participantes e envolvidos no projeto.

O Documento de Avaliao de Riscos deve conter os seguintes elementos:
Declaraes de risco;
Clculos de probabilidades dos riscos;
Clculos da severidade dos riscos;
Clculos da exposio dos riscos;
Planos de mitigao;
Planos de contingncia e suas condies de acionamento especficas;
Associao da responsabilidade pelos riscos.

Deve ser criada uma lista com os Top-10 (os 10-Mais Prioritrios):
mais interessante e prtico limitar o nmero de riscos em 10 ou menos, naturalmente
considerando-se os de mais alta prioridade;
Esta lista deve ser revista regularmente;
Esta lista deve ser mantida atualizada de forma a mostrar as alteraes de prioridade.
Pg. 68
10. Instrumentos para Conduo e Desenvolvimento de Projetos

medida que cada projeto vem sendo desenvolvido de acordo com as fases e atividades
estabelecidas no Plano de Execuo, ou seja, medida que o projeto passa a ser executado de
fato, algumas ferramentas podem ser empregadas para apoiar seu efetivo gerenciamento. Podemos
diferenciar tais instrumentos entre dois tipos: os que apoiam o controle do projeto, e os que
promovem a gesto do conhecimento envolvido no desenvolvimento de projetos. Vejamos, pois,
algumas delas a seguir.

Instrumentos de Apoio ao Controle de
Projetos
Instrumentos de Apoio Gesto do
Conhecimento Presente nos Projetos
TO-DO Lists Prottipos
Listas de Pendncias (Checklists) Ambientes de Homologao
Bases de Acompanhamento de Atividades Projetos-Piloto
Reunies de Acompanhamento Laboratrios
Roteiros para Entrevistas / Reunies (Scripts) Benchmarking de Solues
Relatrios de Relacionamento com Fruns de Discusso / Conhecimento
Fornecedores Relatrios de Eventos
Bases Executivas para Acompanhamento de Transferncia de Conhecimento por Tradio
Projetos Reunies de Lies Aprendidas
Apresentaes Executivas

10.1. Instrumentos de Apoio ao Controle de Projetos

Controlar projetos, fases ou tarefas envolve um bom acompanhamento, com instrumentos
que permitam a monitorao daquilo que ficou estabelecido. A relao de instrumentos e
ferramentas a seguir oferece mecanismos para que este controle no se perca, e objetiva-se a
organizar as aes do gerente do projeto no sentido de focalizar o que realmente necessrio ser
feito, com as devidas prioridades para interveno.

10.1.1. TO-DO Lists

Periodicamente, cada integrante da equipe de um projeto deve estabelecer uma previso das
atividades que devero ser executadas, principalmente de acordo com o Plano de Execuo do
projeto. Idealmente, esta lista de coisas a fazer deve conter as prioridades para a execuo bem
como uma durao estimada, de forma a possibilitar suas eventuais estimativas de concluso.
Podem ser divididas por assunto, o que facilitar o entendimento do trabalho a ser efetivamente
concludo do trabalho j realizado. Em particular, as TO-DO Lists so individuais e especficas para
cada participante de um projeto, e cabe ao gerente do projeto cobrar de todos os envolvidos que
andem sempre com suas listas mo, evitando-se perder o foco do que realmente deve ser feito.

Os TO-DO lists so ferramentas que possibilitam o acompanhamento dos projetos no nvel
micro, ou seja, referente s atribuies detalhadas e ordinrias de cada participante da equipe em
particular. Estas tarefas podem variar desde um simples telefonema configurao de um
equipamento complexo. Algumas das tcnicas utilizadas para gerenciamento do tempo levam
construo de TO-DO Lists adequados para planejamento, acompanhamento e controle das
atividades pendendes individuais.

Pg. 69

Vejamos, a seguir, um pequeno exemplo de uma TO-DO List, de um coordenador envolvido
em um projeto de lanamento de um novo curso de ps-graduao lato sensu:

Exemplo: TO-DO List do coordenador de projeto para lanamento de um novo curso de ps-graduao lato sensu

Note que, no exemplo acima, algumas das atividades j foram concludas (), enquanto
outras ainda esto por ser feitas (). Alm disso, algumas das atividades esto sublinhadas e em
negrito, o que aponta seu carter de urgncia (prioridade) em relao s demais.

10.1.2. Listas de Pendncias (Checklists)

Para cada fase de um dado projeto so discriminadas tarefas e aes esperadas dos
participantes, e estas podem ficar registradas em listas de pendncias, ou checklists. Este
instrumento uma das principais ferramentas do gerente de projetos, e deve-se mant-la
constantemente atualizada, de forma se garantir o controle da conduo do projeto. Os Checklists
diferem-se das TO-DO Lists nos seguintes termos:

1> So elaboradas e mantidas pelo gerente de projetos;
2> Referem-se s pendncias relativas no a somente um dos indivduos do projeto, mas as
pendncias relacionadas a todos os envolvidos;
3> Detalham um pouco mais as complexidades inerentes s fases e atividades previstas no
Plano de Execuo, mas no chegam ao nvel de detalhamento das TO-DO Lists.

Assunto: Preparar calendrio
Convidar prof. Ricardo mdulo de telecomunicaes;
Documentar informaes de disponibilidade dos professores confirmados;
Verificar disponibilidade de uso laboratrio no dia 22/10 para prof. Srgio;
Enviar calendrio final para a secretaria de ps-graduao;

Assunto: Questes administrativas:
Averiguar datas de pagamento e honorrios por hora/aula;
Distribuir recomendaes da coordenao aos professores;
Acompanhar qualidade da impresso das apostilas para o mdulo de Estatstica;
Responder/Encaminhar ao e-Mail do aluno Apolnio, sobre trancamento;
Verificar possibilidade de uso do auditrio nas aulas do prof. de
Administrao Estratgica;

Assunto: Mdulo de Gerncia de Projetos
Revisar apostila;
Converter apostila para PDF;
Imprimir e deixar apostila no Xerox;
Solicitar lista com endereos de e-Mail dos alunos junto secretaria;
Enviar e-Mail com apostila PDF aos alunos;
Divulgar apostila no site da Escola.

Pg. 70
Esta relao de pendncias deve listar, alm das atividades e tarefas especficas, os
profissionais respectivamente responsveis pelas mesmas, as reas e/ou empresas alocadas para sua
execuo, as datas de incio de desenvolvimento, de previso de trmino e de trmino efetivo, bem
como eventuais informaes adicionais. As listas de pendncias devem estar ajustadas com o
Plano de Execuo do projeto, e as TO-DO Lists nada mais so que as tarefas individuais a serem
conduzidas por cada um dos envolvidos no projeto. O desafio fazer com que todas as atividades
das listas de pendncias se encaixem nos perodos previstos no Plano de Execuo de forma a
no impactar nos resultados de cada fase, o que consequentemente tambm no dever trazer riscos
s datas de implantao final do projeto como um todo.

As Listas de Pendncias e os TO-DO Lists so tambm conjuntamente denominados
microplanejamento do projeto.

Veremos, na pgina seguinte, um bom exemplo de checklist, em um projeto de implantao
de um novo sistema em uma empresa de tecnologia da informao, onde as atividades hachuradas
em cinza j foram concludas, as que esto em vermelho ou esto atrasadas, ou esto previstas para,
no mximo, o dia seguinte, e as atividades em azul esto previstas para finalizao em at 7 dias a
contar da data atual (considerar a data atual em 16/11/2002, para compreender a ilustrao).

10.1.3. Bases de Acompanhamento de Atividades

As bases de acompanhamento de atividades so pequenos sistemas de informaes onde
devem ser cadastradas as atividades dirias da equipe do projeto. Nesta base, permitido que se
faa o cadastramento do projeto bem como de suas fases e atividades associadas. Cada membro da
equipe de um Projeto deve, diariamente, entrar com informaes referentes s tarefas
desempenhadas no mesmo, discriminando a quantidade de horas dedicadas a cada uma das Fases e
Atividades previstas no Plano de Execuo do projeto no qual o mesmo desempenhou funes.

Este instrumento, se corretamente utilizado, oferece a apurao dos perodos efetivamente
trabalhados em cada uma das atividades previstas originalmente no Plano de Execuo. Desta
forma, possibilita uma apurao mais adequada do custeio relacionado ao emprego de homens/hora
nas diversas atividades do projeto. Um outro grande benefcio associado utilizao das bases de
acompanhamento de atividades pela equipe do projeto um acerto mais apurado das estimativas de
prazos e recursos para fases e atividades similares em projetos futuros.

Pode-se considerar que esta base funciona como um cronograma s avessas, pois refere-se
ao que foi, de fato, executado, e no ao que est previsto para ser desenvolvido, a posteriori.

Contudo, este tipo de ferramenta encontra grande resistncia para sua efetiva implementao
por parte dos profissionais envolvidos nos projetos, pois seu preenchimento, alm de tedioso e
frustrante, invariavelmente traz a conotao de controle excessivo por parte das chefias funcionais.
Portanto, devem ser considerados os aspectos culturais da organizao onde se deseja que esta
ferramenta seja implementada.

Na pgina seguinte, estaremos apresentando um modelo simplificado de uma base de
acompanhamento de atividades, implementado no como um sistema estruturado, mas como uma
planilha. Notar que as atividades hachuradas referem-se a perodos no trabalhados necessariamente
no projeto, mas a tarefas no previstas originalmente ou relativas a feriados, entre outras situaes.
Pg. 71

Exemplo de Checklist (ouLista de Pendncias) Considerar a data atual de 16/11/2002 para o entendimento da mesma.

Prior. Pendncia Responsvel Participantes Abertura
Trmino
Estimado
Status Observaes
1
Acerto das pendncias tcnicas inviabilizadoras do Roll-
out
Mrcia Afonso / Alberto 07/10/02 24/10/02

1 Homologao da nova soluo Mrcia Usurios piloto 07/10/02 27/10/02

1 Piloto da nova soluo Carlos
Mrcia / Afonso /
Alberto
28/10/02 07/11/02

1 Aprovao de oramento de implantao Sr. Jpiter
Carlos /
Gerentes
Funcionais
17/10/02 09/11/02

Aguardando confirmao de data agendada para a reunio
de reunio de fechamento e validao
1 Anlise do contrato com parceiro de Roll-out Pedro Depto jurdico ------- 11/11/02

Jurdico ainda no deu parecer final; pode demandar ao
gerencial para acelerar o processo
1 Elaborao do manual do instalador Mrcia Grfica Pioneira 27/10/02 18/11/02

Problemas com a grfica; questes de faturamento ainda
pendentes
2
Acerto das pendncias tcnicas menos crticas para o Roll-
out
Mrcia Afonso / Alberto 27/10/02 16/11/02

2 Elaborao de material para treinamento Luciana Grfica Pioneira 06/11/02 21/11/02

Depende de detalhes relacionados ao contrato com a Grfica
2 Homologao do manual do instalador Fabrcia
Suporte Tcnico /
Manuteno
06/11/02 24/11/02

3 Comunicao interna com filiais Carlos ------- 16/11/02 24/11/02

3 Fabricao / Distribuio dos kits de instalao Carlos
Empresa Mdia
Service /
Gerentes
regionais
21/11/02 01/12/02

3 Treinamento do pessoal de logstica Luciana
Gerentes
regionais /
multiplicadores
16/11/02 16/12/02

4
Montagem de QG central para acompanhamento do Roll-
out
Carlos
Gerentes
funcionais
21/11/02 26/11/02

4 Realizao do Roll-out Carlos
Parceiro de Roll-
out / Gerentes
regionais / QG /
Multiplicadores
26/11/02 25/01/03

Pg. 72

Exemplo de Base de Acompanhamento de Atividades (ou Cronograma s Avessas)

10.1.4. Reunies de Acompanhamento

Frequentemente os membros das equipes de cada projeto devem se reunir para avaliar o
andamento das atividades de cada um deles, sobretudo conforme previsto no Plano de
Comunicaes. Nestas reunies, o Plano de Execuo deve ser verificado em relao ao que est
sendo efetivamente conduzido, e principalmente em relao s pendncias relacionadas nos
checklists. No caso de ocorrerem atrasos, imprevistos, incidentes, ou alteraes de curso, gerando
Valor Hora: R$ 15,00
Incio Trmino Perodo Valor Descrio
1/nov Sex 09:00 10:30 01:30 22,50 Reunio de acertos de pendncias tcnicas
10:30 11:15 00:45 11,25 Elaborao e distribuio de ata da reunio
11:15 12:30 01:15 18,75 Contato com fornecedores para prospeco inicial de viabilidade tcnica
4/nov Seg 09:00 09:30 00:30 7,50 Elaborao de checklist geral do projeto
09:30 12:00 02:30 37,50 Elaborao da verso inicial das RFPs
14:30 16:00 01:30 22,50 Reuno com gerentes funcionais para apresentao do escopo definido
16:30 18:00 01:30 22,50 ajustes no Relatrio Executivo e no Plano de Execuo
5/nov Ter 09:00 10:00 01:00 15,00 Elaborao dos scripts para as entrevistas com os fornecedores
10:30 12:00 01:30 22,50 Entrevista com o fornecedor XXX
14:00 16:00 02:00 30,00 Entrevista com o fornecedor YYY
16:30 18:00 01:30 22,50 Prenchimento do relatrio de relacionamento com os fornecedores; Estudo dos
portflios de produtos dos fornecedores XXX e YYY; atualizao do script de
entrevistas
6/nov Qua 08:30 10:00 01:30 22,50 Entrevista com fornecedor ZZZ
10:15 11:00 00:45 11,25 Estudo do portflio de produtos do fornecedor ZZZ; preenchimento do relatrio de
relacionamento com fornecedores; atualizao do script de entrevistas
11:00 13:45 02:45 41,25 Acompanhamento do problema na linha de produo; brainstorming (War Room);
elaborao de plano de aes emergencial; apoio e suporte tcnico resoluo do
mesmo
14:30 18:30 04:00 60,00 Acompanhamento do problema na linha de produo; apoio e suporte tcnico
resoluo do mesmo; elaborao de relatrio do problema
7/nov Qui 07:30 14:30 07:00 105,00 Acompanhamento do problema na linha de produo; reunio de acompanhamento -
checkpoint; atualizao do relatrio do problema
16:00 17:30 01:30 22,50 Reunio de lies aprendidas; elaborao de relatrio de reunies aprendidas
8/nov Sex 08:30 10:00 01:30 22,50 Fechamento e distribuio do relatrio de problema
10:15 11:00 00:45 11,25 Atualizao dos cronogramas e listas de pendncias do projeto
14:30 16:00 01:30 22,50 Reunio de posicionamento do projeto com os membros da equipe
16:15 17:00 00:45 11,25 Atualizao dos cronogramas e listas de pendncias do projeto; acerto das
informaes e documentaes presentes na Base Executiva de Acompanhamento de
Projetos
11/nov Seg 08:30 10:00 01:30 22,50 Acompanhamento geral dos trabalhos executados pela equipe de projetos; reviso dos
TO-DO Lists individuais; visita s demais reas funcionais para acompanhamento de
tarefas
10:30 12:00 01:30 22,50 Reviso do Documento de Avaliao de Riscos
14:30 16:00 01:30 22,50 Reunio com os executivos patrocinadores para posicionamento do andamento do
projeto
16:30 18:00 01:30 22,50 Elaborao de ata de reunio; acerto na documentao do projeto e listas de
pendncias; bate-papo rpido com a equipe para posicionamento da reunio com a
diretoria
12/nov Ter 00:00 0,00
13/nov Qua 00:00 0,00
14/nov Qui 00:00 0,00
15/nov Sex 00:00 0,00 FERIADO
18/nov Seg 00:00 0,00
19/nov Ter 00:00 0,00
20/nov Qua 00:00 0,00
21/nov Qui 00:00 0,00
22/nov Sex 00:00 0,00
23/nov Seg 00:00 0,00
24/nov Ter 00:00 0,00
25/nov Qua 00:00 0,00
26/nov Qui 00:00 0,00
27/nov Sex 00:00 0,00
TOTAIS 43:30 652,50
Data
Pg. 73
ampliaes ou redues no escopo do projeto, o Plano de Execuo dever ser revisto, e todos os
fatos e eventos relacionados s eventuais mudanas devem ser devidamente documentados.

As Reunies de Acompanhamento devem envolver a verificao dos motivos que levaram
aos possveis atrasos, bem como levantar as alternativas de correo de rumo, alm do preparo da
argumentao que leve a novas negociaes referentes a prazos e custos a serem tratados junto ao
corpo diretivo da organizao. A freqncia destas reunies no deve ser muito baixa de forma a
possibilitar eventuais perdas de foco ou falta de informaes comuns a toda a equipe, nem
tampouco muito freqentes de forma a no tirar a produtividade do time. Caber ao gerente de
projetos definir os melhores momentos para a promoo das reunies de acompanhamento.

10.1.5. Roteiros para Entrevistas / Reunies (Scripts)

Ao agendar reunies ou entrevistas, tanto internas quanto com reas cliente ou com
fornecedores externos, seja presencialmente, seja via telefone ou vdeo-conferncia, muito
importante estabelecer a priori quais sero as questes a serem tratadas em cada evento. Os
roteiros, ou scripts, so instrumentos muito teis para dar eficcia a cada encontro, economizando
tempo e agregando real valor s decises a serem efetivamente tomadas pelos envolvidos
8
.
Idealmente, seu teor deve ser divulgado com alguma antecedncia em relao data de realizao
do evento, permitindo aos convidados que se prepararem adequadamente para o mesmo. Esta
ferramenta possui especial importncia sobretudo em reunies com grande nmero de participantes,
onde a objetividade um fator-chave.

A elaborao de roteiros pode ser uma tarefa participativa, e pode contar com profissionais
experientes no relacionamento entre as pessoas, reas, parceiros ou fornecedores envolvidos. Em
alguns casos, a elaborao dos roteiros pode ser elaborada em conjunto com profissionais mais
experientes, e que no necessariamente estejam alocados equipe de projeto. Isso pode garantir
objetividade na elucidao de pontos mais crticos e um maior entendimento dos desafios e
problemas a serem superados pelos participantes de cada evento.

10.1.6. Relatrios de Relacionamento com Fornecedores

Em projetos que contam com grande nmero de fornecedores, imperativo que se mantenha
um controle sobre o que tem sido comunicado e repassado a cada um deles, seja em reunies, seja
por telefone, FAX ou e-Mails, por exemplo. Em uma concorrncia, a lisura e imparcialidade do
processo depende de que todos os fornecedores obtenham o mesmo nvel de informao divulgada,
de forma a oferecerem propostas mais completas e adequadas aos objetivos e metas esperados.

Sendo assim, os relatrios de relacionamento com fornecedores podem apresentar
informaes genricas, com um pequeno relato das interaes com o fornecedor, ou com altos
nveis de detalhamento, em que so registradas as datas, horas e nomes das pessoas contactadas, o
instrumento utilizado (FAX, e-Mail, telefone, etc.), entre outras informaes relevantes. Seu
objetivo principal o de policiar o gerente de projetos no sentido de manter-se imparcial e no
contnuo esforo de fazer com que todos os fornecedores concorrentes tenham chances e
informaes iguais para sua participao nas concorrncias conduzidas ao longo do projeto.

8
No caso de reunies, o roteiro (ou script) previsto para sua conduo chamado pauta.
Pg. 74
Uma outra aplicao para este instrumento realizar o acompanhamento de chamados de
suporte ou de atendimento abertos junto aos fornecedores do projeto. Desta forma, caso se verifique
algum atraso em tarefas a serem executadas por terceiros bem como na resoluo de problemas
operacionais, o relato das interaes ao longo do tempo pode apontar os eventuais gargalos e falhas
no atendimento s solues solicitadas junto aos parceiros, o que pode estimular a convocao dos
mesmos para que aperfeioem seus processos de atendimento em favor do bom andamento do
projeto.

10.1.7. Bases Executivas para Acompanhamento de Projetos

Para que se realize um acompanhamento estratgico de cada um dos projetos da
organizao, deve ser criada uma rea comum, onde os executivos possam consultar e tomar
conhecimento dos estgios onde os projetos se encontrem. A Base de Acompanhamento de Projetos
um instrumento gerencial estratgico, oferecendo uma viso macro sobre o desenvolvimento dos
projetos da empresa.

Esta base de dados comum deve fornecer, idealmente, informaes referentes cada projeto
em particular, em nveis de detalhamento progressivos, contemplando os atributos do projeto em
geral. Entre outros elementos, poderamos sugerir que fossem colocados nesta base de informaes
os documentos principais do projeto (Relatrio Executivo, Plano de Execuo, Documento de
Avaliao de Riscos, checklists, Relatrios de Acompanhamento de Fornecedores, etc.), breves
resumos da situao do projeto por semana/ms, breve resumo de resultados j atingidos e dos que
esto por vir, breve resumo dos problemas enfrentados e das solues desenvolvidas, entre outros
aspectos e relatrios tcnicos necessrios, e que compem toda a documentao produzida ao longo
do ciclo de vida do projeto.

A partir desta base de informaes, possvel conhecer-se, a qualquer momento, qual a
situao corrente de cada projeto, bem como o histrico de aes executadas num nvel macro,
permitindo uma viso executiva relativa ao mesmo de forma sucinta e abrangente. Efetuando
pesquisas nestas bases podem ser verificados, por exemplo, quais so os projetos em atraso, ou
quais projetos de alta prioridade esto paralisados ou suspensos, aguardando recursos, ou mesmo
quantos e quais os projetos de uma determinada rea permanecem em demanda reprimida (ou
back-log), ou seja, ainda por serem iniciados. Indicadores coloridos podem ser utilizados para cada
um dos projetos inseridos nesta base como, por exemplo, vermelho (paralisado/suspenso), amarelo
(em atraso), verde (normal), azul (acima do desempenho planejado), preto (concludo), branco (no
iniciado / demanda reprimida), entre outros.

A anlise da situao global sobre a base de projetos permite uma constante monitorao das
direes e do desempenho dentro do qual a empresa se posiciona, suportando atividades e decises
de nvel estratgico com mais agilidade. Alm disso, como esta base agrega informaes de todos
os projetos da organizao, possvel que ela se oferea como fonte permanente de aprendizado
em relao aos projetos j realizados, balizando novos empreendimentos junto s experincias j
vivenciadas anteriormente.

Entretanto, para que esta ferramenta se mostre efetiva, importante que haja uma forte
disciplina na insero de contedo na mesma. Alm disso, fundamental que sejam implementados
mecanismos eficientes de recuperao de informaes e de conhecimentos nestas bases, sob pena de
se acumularem grandes estoques de conhecimento sem, no entanto, que se obtenha a liquidez
Pg. 75
necessria na recuperao das informaes necessrias. Existem diversas ferramentas de groupware
que permitem a implementao destas bases executivas para acompanhamento de projetos.

Contudo, deve-se atentar e buscar definies e implementaes robustas para a garantia da
segurana no acesso e na recuperao de informaes destas bases por parte dos seus usurios, pois
todo o expertise da organizao estar contido na mesma, e os segredos comerciais estabelecidos
em projetos estratgicos estaro ali armazenados.

10.2. Instrumentos de Apoio Gesto do Conhecimento Presente nos Projetos

Definir gesto do conhecimento parece ser algo simples, uma vez assumidas as distines
entre os conceitos de dado, informao e conhecimento. No entanto h uma grande diversidade de
conceitos referentes gesto do conhecimento, sobretudo devido ao fato de que a mesma ainda
muito recente. A gesto do conhecimento um processo interativo de criao do conhecimento
organizacional, sendo definida como a capacidade que uma empresa tem de criar conhecimento,
dissemin-lo na organizao e incorpor-lo a produtos, servios e sistemas
9
.

Sendo assim, as ferramentas a seguir se propem a maximizar os processos de gerao,
codificao e transferncia do conhecimento, tanto entre os participantes das equipes de cada
projeto quanto entre eles e todos os envolvidos direta e indiretamente com o mesmo. Seus
benefcios-chave so vinculados a estimular e fortalecer as estruturas formais e informais de
conhecimento, favorecendo a produtividade e as curvas de aprendizado em novos projetos.

10.2.1. Prottipos

Grandes projetos demandam que suas respectivas solues sejam implantadas
modularmente, de forma extensvel. Preferencialmente, devem haver testes que ajustem as
funcionalidades das solues implementadas e antecipem problemas potenciais. Um prottipo a
materializao de uma proposta de soluo, e no necessariamente precisa ser funcional, ou seja,
no precisa ser utilizvel, de fato. Um prottipo deve ser empregado no como uma soluo
acabada e pronta para ser implementada, mas para permitir que se faam questionamentos acerca da
proposta que est sendo, atravs dele, concretizada. Em outras palavras, prottipos no apresentam
as solues, mas apenas propostas, permitindo que eles prprios sejam desafiados em termos de sua
futura viabilidade funcional e operacional.

Prottipos so poderosos instrumentos de levantamento de informaes quanto ao
funcionamento e s expectativas de soluo mantidas pelas reas usurias e executivas envolvidas.
Podem ser descartados quando no tiverem mais necessidade, ou podem evoluir no decorrer do
projeto, apresentando novas alternativas para o desenvolvimento das solues buscadas pelo
mesmo.

So exemplos de prottipos os carros-conceito, automveis que no necessariamente se
tornam produtos fabricados em srie, mas para permitir que especialistas e leigos discutam sua
viabilidade, bem como seus conceitos-chave, ali materializados. Outros exemplos de prottipos so
maquetes de construes, programas de computador que realizam simulaes de uma obra

9
Conceito foi extrado de NONAKA e TAKEUCHI (1997, p. xii)
Pg. 76
concluda, e as chamadas bonecas, que so simulaes de uma soluo final, utilizadas apenas
para efeito de validar, junto aos seus clientes e usurios, os conceitos que procuram representar.

10.2.2. Ambientes de Homologao

Deve ser estruturado, sempre que possvel, um ambiente a ser empregado para os testes da nova
soluo, onde muitos dos erros e problemas que seriam encontrados apenas em um ambiente real de
produo podero ser verificados antecipadamente, e suas alternativas de correo estudadas e
prontamente implementadas. Um ambiente de homologao particularmente importante na
implantao de solues baseadas em tecnologias muito novas, cujos riscos de implementao
somente podem ser conhecidos aps extensivos testes em situaes muito prximas ao contexto real
em que sero ofertados na prtica. Em diversas situaes, a homologao de uma soluo tambm
chamada prova de conceito.

Neste caso, devem ser montados ambientes que reproduzam fielmente o ambiente real de
produo, para que as solues desenvolvidas sejam exaustivamente provadas anteriormente sua
implantao definitiva. Os erros, problemas e nuances verificados devem ser devidamente
registrados para consultas futuras, o que minimizaria a reincidncia dos mesmos, alm de otimizar
seu tratamento corretivo.

Um bom exemplo so os sistemas de automao bancria que, em grandes instituies, so
estruturados ambientes de homologao equivalentes a agncias de mentirinha, adequadas ao
estudo e reproduo do ambiente real das agncias fisicamente estabelecidas pela instituio
financeira. Outro exemplo de um ambiente de homologao so os chamados apartamentos
decorados, em que os provveis compradores de um imvel visitam o local, caminhando por ele,
de forma a descobrir por si mesmos as vantagens e desvantagens do que ser o produto final a ser
finalmente construdo. Nesta linha, poderamos citar as empresas de veculos que permitem que
seus clientes faam um test-drive nos modelos de veculos colocados venda, onde o cliente pode
experimentar um tipo de carro como se fosse seu prximo veculo
10
.

Outros exemplos para ambientes de homologao so algumas vacinas testadas em cobaias
no-humanas. Neste caso, os animaizinhos sero continuamente monitorados de forma a se
avaliarem os efeitos colaterais, a eficcia e a eficincia dos novos medicamentos. Caso algo errado
acontea, a cobaia pode ser sacrificada, ou mesmo ter seu sofrimento e reaes profundamente
estudados, permitindo-se contnuos aperfeioamentos na soluo desenvolvida (quando os testes
passam a ser realizados em seres humanos estaremos tratando de projetos-piloto, que veremos
adiante).

Algumas empresas de software oferecem cpias Beta, ou Alfa, de seus programas de
computador ao pblico especializado, de forma a solicitar sugestes, crticas ou consideraes em

10
importante observar que os ambientes de homologao dependem exclusivamente da natureza do projeto em
questo. No caso do test-drive, por exemplo, a montadora do veculo bem como a concessionria no estariam
realizando nenhum processo de homologao do seu produto, pois o mesmo j se encontraria disponvel para o
mercado. No entanto, um eventual comprador ou interessado no carro, em um projeto que visaria aquisio deste bem,
poderia utilizar-se do test-drive para cerificar-se, em um contexto similar ao ambiente real final (que o de seu uso
dirio), da qualidade e das funcionalidades oferecidas pelo veculo testado. Neste ltimo caso, ou seja, no projeto de
aquisio de um veculo conduzido por um interessado, o test-drive se revela como uma ferramenta de homologao. O
mesmo poderia ser dito dos apartamentos decorados, em que a construtora oferece a possibilidade do cliente homologar
o ambiente em seu projeto individual de adquirir um novo imvel.
Pg. 77
relao ao produto em fase final de construo. Neste caso, no se recomenda que o produto seja
utilizado em ambientes reais de produo pois, como trata-se de cpias de homologao, as mesmas
ainda no se encontra dentro de nveis adequados de estabilidade para implantao em ambientes
reais de produo de misso-crtica.

Deve-se prestar especial ateno quanto s diferenas entre o conceito de prottipo e de
ambiente de homologao. Um prottipo a materializao de uma proposta, ou seja, ainda est no
campo da idia, do conceito (ainda que j em um estgio bastante amadurecido de
desenvolvimento). Um ambiente de homologao, por sua vez, reproduz fielmente o ambiente real,
de produo, e possibilita que a soluo final j desenvolvida seja continuamente testada, corrigida,
avaliada e, enfim, aprovada para implantao definitiva.

10.2.3. Projetos-Piloto

Mesmo realizando testes em ambientes de homologao, o ambiente real, de produo,
sempre apresenta variveis (grande parte delas, intangveis) jamais passveis de antecipao e
simulao. Por exemplo, um determinado tipo de teste, o de stress, em que um grande nmero de
acessos simultneos deve ser simulado de forma a se permitir a anlise do comportamento da
soluo implementada, somente pode ser realizado em um ambiente real de produo.

Por causa disso, devem ser programadas implantaes iniciais em ambientes reais, e que
contemplem um universo crtico controlvel. Os ambientes nos quais os projetos-piloto so
implementados devem apresentar uma diversidade significativa de situaes de forma a se permitir
o acompanhamento do comportamento da nova soluo do ponto de vista de seu usurio final. Da
mesma forma que nos ambientes de homologao, aquilo que for percebido como de significativa
relevncia passa a ser adequadamente documentado para posterior reaproveitamento, ou seja, para
avaliao, anlise, e efetiva correo e ajustes.

importante apontar a principal diferena entre os ambientes de homologao e os de
projeto-piloto. Os ambientes de homologao so restritos a testes e validaes circunscritas ao
ambiente interno da organizao; os projetos-piloto j so solues disponibilizadas em ambientes
reais de produo. Neste ltimo caso, todo o cuidado deve ser tomado em relao conduo dos
testes em piloto, pois a j estaro envolvidos os clientes da empresa, a imagem da instituio, e
sobretudo, a credibilidade do projeto como um todo. Em outras palavras, os projetos-piloto somente
podem ser lanados quando j se possui grande certeza quanto aos resultados que sero atingidos,
no sendo permitidas situaes do tipo tentativa-e-erro.

Os projetos-piloto so indicados quando os investimentos finais so muito altos para um
Roll-out da soluo por completo, e os riscos associados podem se tornar muito elevados caso haja
alguma indisponibilidade ou falha nos novos servios e produtos a serem oferecidos.

So exemplos de projetos-piloto os testes de vacinas em cobaias humanas, a
disponibilizao de determinados produtos e servios em pequenas cidades, ou para grupos
reduzidos de clientes, entre outros.

10.2.4. Laboratrios

Idealmente, deve ser possvel a montagem de uma infra-estrutura a ser empregada para os
testes de uma nova soluo, sobretudo permitindo-se que este ambiente seja montado e desmontado
Pg. 78
quantas vezes necessrio. O objetivo principal da construo de um laboratrio a realizao de
experincias com novas tecnologias, testando e avaliando funcionalidades, restries, conceitos e
caractersticas de tecnologias ainda no dominadas pela organizao. No entanto, seus custos
podem ser proibitivos. Nestes casos, pode ser que um ambiente de laboratrio se pague conforme o
montante e a criticidade de um projeto, ou de forma a tornar possvel que suas instalaes possam
ser reutilizadas em projetos futuros.

Os laboratrios podem evoluir para ambientes de homologao, mas jamais para projetos-
piloto, pois estes ltimos so considerados ambientes de produo. Contudo, o que difere um
laboratrio de um ambiente de homologao a estabilidade deste ltimo, pois os laboratrios
permitem que se faam alteraes e mudanas a qualquer tempo, enquanto que os ambientes de
homologao so estveis, e evoluem conforme tambm evolui o ambiente de produo, junto dos
quais os ambientes de homologao devem se manter como cpias fiis.

10.2.5. Benchmarking de Solues

Muitas vezes, necessrio que a equipe do projeto veja com seus prprios olhos os
resultados alcanados em outras organizaes a respeito da utilizao de tecnologias, produtos e
servios especficos. Dessa forma, e sempre que for vivel, devem ser realizadas visitas tcnicas em
outras empresas, usurias de solues similares s que sero implantadas nos projetos em
desenvolvimento, para aprender in loco como as tecnologias e os esforos institucionais foram
associados para obteno de sucesso, naqueles casos. Quando no for possvel o agendamento de
visitas tcnicas, pode-se tentar entrevistas em que devem ser objetivamente abordados os pontos
mais crticos encontrados pelos terceiros na implementao das nuances encontradas em seus
projetos especficos.

Damos o nome de benchmarking de solues verificao, anlise e avaliao de conceitos
e solues em empresas ou setores que os implementaram com significativo sucesso. Este
aprendizado e as concluses a que se pode chegar pode se tornar at mesmo um fator crtico de
sucesso para o prprio projeto interno em andamento.

Em muitos dos casos, o aprendizado maior pode se basear no nos aspectos especficos da
tecnologia escolhida, mas em aspectos como os que esto vinculados gesto de sua implantao,
considerando fatores principalmente focados no lado cultural e humano das organizaes
envolvidas. Em outras palavras, detalhes normalmente no considerados do ponto de vista
estritamente tcnico podem se tornar itens determinantes para o sucesso de projetos como, por
exemplo, a integrao com sistemas e ambientes legados, ou a carncia de tcnicos e empresas
especializadas em suporte tcnico na mesma regio dos clientes da soluo do projeto, ou relativo a
aspectos culturais da organizao (como resistncias internas, disputas por poder, etc.), ou mesmo
devido ao fato que a empresa estudada baseia-se em uma estrutura organizacional fortemente
centralizada, enquanto que a empresa contratante do projeto interno mantm uma estrutura muito
distribuda geograficamente.

De particular importncia, os benchmarkings de soluo devem ser enfatizados quando da
avaliao de fornecedores em projetos. Nestes casos, a concorrncia entre fornecedores pode ser
decidida em algumas visitas a outros clientes dos mesmos, na busca de solues similares s que
sero desenvolvidas no projeto interno em questo.

Pg. 79
10.2.6. Fruns de Discusso/Conhecimento

Cada tema, tendncia ou assunto, seja de origem tcnica como de natureza organizacional,
tanto de foco e escopo internos como externos organizao, podem ser discutidos atravs deste
instrumento, que pode ser implementado tanto virtualmente quanto presencialmente. A
implementao virtual deste instrumento pode ser realizada atravs de listas de discusses, sendo
que, em muitos casos, as mesmas podem estar abertas a comunidades externas prpria
organizao. Presencialmente, importante estimular ciclos de palestras internos, de preferncia
trazendo palestrantes de outras reas da empresa ou de outras empresas, bem como oferecendo
eventos para outras reas da empresa, o que permite a livre troca de conhecimentos.

Assuntos mais tcnicos como, por exemplo, o Novidades em Telecomunicaes ou
Transaes Eletrnicas na Internet, ou mais especficos como Balanced Scorecard, Logstica
de Servios e Gerncia de Projetos, ou de escopo no tcnico como Mercado Financeiro,
Projeto de Vida ou Voluntariado podem ser debatidos atravs de ferramentas de groupware ou
de Intranet, ou mesmo em reunies e palestras programadas.

O objetivo, neste caso, criar um universo de interao virtual ou presencial, estimulando os
colaboradores a compartilharem seu conhecimento com os demais profissionais da empresa, nos
assuntos em que se sentirem motivados a contribuir.

Deve-se, contudo, tomar-se cuidado em sua implementao, pois a obrigatoriedade ou o
excesso de formalismo em sua participao pode destruir estas redes de conhecimento, minando sua
existncia. muito claro que os principais integrantes destas redes invisveis de pessoas, cujas
dimenses ultrapassam as fronteiras das organizaes, so pesquisadores e estudiosos voluntrios,
auto-estimulados por um aprendizado contnuo e constante, e fazem parte destas agremiaes
informais comumente chamadas comunidades de prtica. Se, por um lado, no se deve matar as
comunidades de prtica, um grande passo reconhecer sua existncia, e fomentar seu crescimento e
desenvolvimento sem, no entanto, sufoc-las.

10.2.7. Relatrios de Eventos

Aps cada visita, curso, congresso, seminrio ou outros eventos nos quais os colaboradores
de uma organizao possam tomar parte, devem ser elaborados documentos de resumo a serem
disponibilizados para toda a empresa, preferencialmente em uma base de conhecimentos comum, de
acesso liberado a todos os potencialmente interessados. Idealmente, devem ser oferecidas pequenas
palestras, onde este conhecimento possa ser socializado, e onde seja permitida grade interao por
parte dos demais colaboradores.

Tais documentos podem ser disponibilizados para toda a empresa, por exemplo, nos Fruns
de Discusso/Conhecimento, em bases de discusso virtuais, ou em ciclos de palestras e
treinamentos internos. Deve ser estimulada a participao de outros colaboradores no sentido de
oferecerem sugestes, comentrios e crticas s tecnologias e conceitos apresentados, bem como
apresentando novas fontes de informao sobre o mesmo assunto ou sobre tpicos relacionados,
desta forma enriquecendo o acervo de conhecimentos gerados aps cada evento.

Em particular, sugere-se que o tempo gasto para a produo destes documentos-resumo no
ultrapasse 20% da durao total do evento. Assim, caso um profissional tenha participado de um
treinamento cuja durao tenha sido de 40 horas, recomenda-se que o mesmo dedique um mximo
Pg. 80
de 8 horas para a produo de um documento ou palestra que o sumarize de forma adequada e
palatvel para o pblico-alvo.

10.2.8. Transferncia de Conhecimento por Tradio

Um dos aspectos mais crticos na elaborao de cada projeto o como faremos para
dominar a tecnologia a ser empregada de forma rpida e satisfatria?, principalmente quando
devem ser contratados servios e produtos de terceiros. A presena da equipe de projetos em
treinamentos e seminrios importante, sem dvida, mas leva tempo para que o conhecimento
baseado na prtica, ou seja, na experincia dos peritos, possa ser devidamente assimilada.

Nestes casos, e de forma ideal, deve ser estabelecido (preferencialmente em contrato) que
ocorram trabalhos conjuntos entre a equipe da empresa e os profissionais terceiros integrantes do
projeto. A equipe de projeto deve, presencialmente, acompanhar a instalao de ferramentas de
software, ou a operao dos equipamentos que sero utilizados, ou mesmo acompanharem os
trabalhos dos terceiros nas metodologias empregadas por eles de forma a propiciar a transferncia
de conhecimento por tradio
11
.

Por exemplo, em um determinado projeto, pode ser necessrio o desenvolvimento de
programas de computador que utilizem uma determinada linguagem e ferramentas at ento
desconhecidas por parte da empresa. Neste caso, programadores da empresa contratada para
desenvolver os aplicativos da soluo projetada poderiam deslocar-se para as dependncias da
organizao contratante, permitindo que a equipe do projeto possa presenciar, aprender e questionar
a construo dos novos programas nas novas ferramentas, o que poderia traduzir-se em um
aprendizado mais produtivo.

importante observar que este tipo de ferramenta no substitui o treinamento convencional,
mas amplia as possibilidades de fortalecimento do aprendizado, sobretudo considerando que a
prtica verdadeiramente ensina, tornando o conhecimento mais duradouro e perene.

10.2.9. Reunies de Lies Aprendidas

Ao concluir-se um projeto ou uma fase importante, ou mesmo aps a resoluo de algum
problema mais crtico, importante que se realizem reunies que tratem do assunto sob o ponto de
vista de se trocar informaes acerca das experincias vivenciadas. Estas reunies devem contar
com a imprescindvel presena de todos os envolvidos no evento ou fato. Devem ser ponderados os
resultados obtidos e avaliada a conduta estabelecida nas tarefas conduzidas para a realizao da
fase/projeto, ou para a resoluo do problema vencido. As irregularidades, os incidentes e falhas, os
inconvenientes e erros, bem como a qualidade do conhecimento adquirido, os nveis de motivao e
empenho investidos devem ser abertamente discutidos.

No cabe, nestas reunies (como em nenhuma outra), apontar culpados, mas sim os
empecilhos, falhas e virtudes encontrados no processo. Deve-se procurar sugestes para melhorias
futuras, levantar as perdas e os ganhos pessoais e corporativos, discutir fatores positivos e

11
Para maiores informaes sobre a transferncia de conhecimento por tradio, bem como para um excelente contedo
acerca de conceitos como conhecimento, competncia, percia e transferncia de conhecimento por informao, ver
SVEIBY (1997).
Pg. 81
negativos, tangveis e intangveis que ocorreram durante o desenvolvimento da fase/projeto/
problema.

O objetivo geral oferecer possveis mudanas de rumo, abrir perspectivas, disseminar e
compartilhar uma valiosa massa crtica de experincia apreendida de forma a otimizar seu emprego
em empreendimentos futuros, sobretudo no que tange aos fatores humanos e culturais que estiveram
estreitamente envolvidos nos processos vivenciados.

H alguns riscos, contudo, em relao adoo destas reunies, sobretudo no que toca aos
gerentes de projeto. Neste caso, reunies de lies aprendidas podem revelar-se como
oportunidades para que seus participantes apontem direta e publicamente os defeitos e falhas dos
demais colegas, o que pode abrir o precedente de que estes mesmos profissionais, bem como outros
tantos, enxerguem-se no direito constante de oferecer feedbacks no solicitados, estendendo suas
crticas a atitudes de gerentes funcionais e de projeto. Enfim, esta atividade deve ser encarada como
um exerccio de humildade e sabedoria para todos os seus participantes.

10.2.10. Apresentaes Executivas

Sempre que possvel, deve-se levar ao conhecimento da empresa, principalmente de seus
executivos principais e gerentes mdios, os resultados obtidos na concluso de um projeto ou de
suas fases mais importantes. Tal iniciativa demarca, em primeiro lugar, o atingimento formal das
metas estabelecidas no planejamento do projeto, apresentando os nveis de sucesso organizacional
eventualmente conquistados.

Em segundo lugar, oferece aos participantes da equipe do projeto a oportunidade de serem,
de fato, reconhecidos, de alcanarem mrito por seus esforos junto queles que efetivamente
patrocinam suas atividades e empreendimentos internos.

Em terceiro lugar, permite que a empresa valide a abordagem de desenvolvimento de
solues voltada para a gerncia de projetos, mesmo se esta j tiver ampla divulgao e
sedimentao interna, pois ratifica uma alternativa de infra-estrutura metodolgica que permita
gerenciar iniciativas, viabilizar empreendimentos e concretizar oportunidades reais de negcio.

Enfim, e no menos importante, estes eventos podem trazer, atravs da interao com os
executivos-chave, a visibilidade do que considerado de alto valor para os mais altos escales,
possibilitando o vislumbre de novas possibilidades, de novas abordagens para o desenvolvimento de
solues futuras, aprendendo e conhecendo quais sero os novos projetos que, certamente, valero a
pena ser desenvolvidos brevemente.

Isso tudo o que os executivos, ou os clientes, podero nos dizer, enquanto estivermos
apresentando os resultados de nossos projetos a eles.

Bastar estarmos dispostos a escut-los.

Pg. 82
11. Avaliao e Escolha de Fornecedores

Para a viabilizao de solues, em no raras vezes devem ser contratados servios
especializados de fornecedores externos, sejam estes como consultores que apoiem a
implementao do projeto, sejam estes como os prprios implementadores do todo ou de partes
especficas do projeto. Existem tambm os fornecedores de suprimentos necessrios execuo de
projetos.

Para que os fornecedores sejam adequadamente consultados, suas propostas devidamente
avaliadas e, enfim, que os mais adequados organizao e ao projeto sejam devidamente
escolhidos, sugerimos o seguinte roteiro:

1. Estabelecimento de Critrios de Avaliao;
2. Solicitao de Propostas;
3. Realizao da Avaliao;
4. Elaborao do Relatrio de Recomendao;
5. Contratao dos Parceiros Escolhidos.

Naturalmente, aps a contratao dos fornecedores para a realizao do todo ou de parte do
projeto, existe o gerenciamento da atuao dos mesmos, como a administrao de contratos (tanto
em termos de sua execuo quanto em termos de seu encerramento), a alocao de recursos e
materiais contratados e adquiridos e a desmobilizao dos mesmos ao trmino de uma fase ou do
projeto como um todo. Entretanto, neste captulo iremos nos dedicar aos cinco passos apresentados
acima.

Vejamos, com maior detalhe, cada um dos tpicos deste roteiro.

11.1. Estabelecimento de Critrios de Avaliao

Em primeiro lugar, devem ser levantados os itens e aspectos a serem procurados nos
fornecedores a serem contactados. Estas definies esto distribudas em 3 tipos: pr-requisitos,
reas de avaliao e categorias e quesitos de pontuao.

11.1.1. Definio de Pr-Requisitos

Devem ser verificados pr-requisitos a serem obrigatoriamente atendidos pelo fornecedor
candidato. Tais pr-requisitos so condio imprescindvel para que um fornecedor seja qualificado
como participante potencial do processo de avaliao. Por exemplo, poderamos ter como pr-
requisito um fornecedor que seja certificado ISO 9002 na sua rea de atuao, ou que sua
soluo para um sistema CRM inclua o tratamento de CTIs (Centrais Telefnicas Inteligentes), ou
ainda que o fornecedor oferea alternativa de integrao com os atuais sistemas de Call Center e
Help Desk j implantados na organizao.

Em alguns projetos, pode ser que alguns dos pr-requisitos faam meno explcita a uma
determinada linha de produtos, ou mesmo que considerem nveis de servio especficos a serem
oferecidos como, por exemplo, a disponibilizao de um suporte tcnico telefnico 24 x 7, nos
primeiros 6 meses aps a implementao do projeto.
Pg. 83
A no observncia de um Pr-requisito implica em desclassificao imediata da empresa
candidata a fornecedora do projeto.

Para ilustrarmos nossas idias quanto ao desenvolvimento desta seo, consideremos o
seguinte exemplo: uma organizao necessita adquirir um veculo, e para isso gostaria de conduzir
um processo de avaliao idneo e imparcial junto s principais concessionrias s quais possui
acesso. A seguir, apresentamos uma relao de pr-requisitos que os fornecedores devem atender,
em termos da soluo demandada:

11.1.2. reas de Avaliao

Para que se avaliem solues oriundas de diversos fornecedores, suas propostas devem ser
analisadas segundo critrios de avaliao bem definidos. Idealmente, tais critrios devem cobrir,
pelo menos, quatro grandes reas de avaliao, quais sejam, reas tcnica, financeira, comercial e
mercadolgica.

rea Tcnica: refere-se ao atendimento da empresa aos critrios tcnicos demandados
pela soluo. Deve fazer referncia tanto s funcionalidades da nova soluo no que
tange demanda do negcio quanto s tecnologias subjacentes que a suportem. Pode
referenciar-se metodologia utilizada para o desenvolvimento da soluo,
modularidade dos produtos a serem disponibilizados, qualidade da documentao
oferecida, aos nveis de segurana e auditoria implementados, s caractersticas de
compatibilidade, portabilidade, disponibilidade e acessibilidade com outros sistemas,
reas e produtos da empresa contratante, entre outros aspectos tcnicos especficos;

rea Financeira: refere-se ao quanto custar a nova soluo. Neste caso, a avaliao
financeira no deve contemplar apenas o valor absoluto da nova soluo mas, idealmente,
deve apresentar o custo por funcionalidade atendida. Uma boa alternativa para o
nivelamento das propostas a avaliao do custo de um pacote bsico composto por
um conjunto determinado de atributos e, para tpicos adicionais, a discriminao de seus
valores respectivos em separado. Esta rea de avaliao deve considerar todos os aspectos
financeiros da soluo a ser contratada como, por exemplo, as condies e opes de
financiamento, as taxas de juros envolvidas, custos indiretos, depreciao, taxa de retorno
do investimento, entre outros;

rea Comercial: refere-se ao comportamento dos fornecedores no que tange ao
atendimento s necessidades e solicitaes das solues do projeto. Nesta rea, devem ser
verificados os servios bsicos e agregados relacionados soluo contratada ou aos
fornecedores das mesmas. Devem ser verificados aspectos como a estrutura de suporte de
pr-venda e de ps-venda, garantias, redes de assistncia tcnica, qualidade das
informaes apresentadas ao longo do processo de avaliao, experincias anteriores de
sucesso e de fracasso da empresa candidata, seja internamente organizao contratante,
seja em outras organizaes, presteza, agilidade, flexibilidade e iniciativa na apresentao
Aquisio de veculo - Pr-Requisitos
1 Deve ser um veculo novo
2 Deve ter 4 portas
3 Deve ser movido a gasolina
4 Deve ser produzido no Brasil
Pg. 84
e disponibilizao de propostas, produtos e resultados, potencial de implantao da nova
soluo nos termos e requerimentos do projeto, entre outros aspectos. Por exemplo, se um
determinado fornecedor no retorna com agilidade as ligaes telefnicas que lhes so
dirigidas, no retorna rapidamente solicitaes de esclarecimentos e dvidas quanto s
solues as quais representa, no entrega suas propostas tcnico-financeiras conforme os
prazos previamente estipulados, ou apresenta propostas com informaes truncadas,
pouco claras, pouco elucidativas e de forma a no considerar a importncia devida do
projeto assim como o mesmo considerado pela organizao contratante, entre outros
fatores, isso tudo o tornaria pouco apto a ser considerado como um forte candidato
oferta da soluo demandada. Uma boa forma de avaliao do fornecedor neste aspecto
verificar, junto a outros de seus clientes, seu comportamento ao longo de projetos
similares nos quais os mesmos tenham tido participao efetiva (benchmarking);

rea Mercadolgica: neste tipo de avaliao, os fornecedores devem ser verificados
quanto ao seu posicionamento em relao aos parceiros, concorrentes e aos nichos de
mercado em que atuam. Questes como aderncia a padres de mercado e a tecnologias-
chave especficas, qualidade das parcerias estabelecidas, observncia s tendncias tidas
como mais significativas, fatias de mercado ocupadas por seus produtos e servios, curva
de crescimento na adoo de suas solues por parte de parcelas e segmentos
relacionados com o negcio da organizao contratante, situao financeira da
organizao (anlise de balanos), capacidade de atendimento em larga-escala (quando
for o caso), presena no territrio nacional, presena no mercado internacional, entre
outros itens, so importantes indicadores de que o fornecedor avaliado estar bem ou mal
posicionado mercadologicamente para o atendimento da soluo oferecida para a
organizao contratante. Em outras palavras, podemos considerar que a avaliao
mercadolgica refere-se ao atendimento do fornecedor quanto a uma viso macro de seus
mercados e clientes, enquanto que a avaliao comercial posiciona-se em aspectos
particulares, ou seja, voltada s especificidades dos clientes num mbito individual.

11.1.3. Categorias, Quesitos de Pontuao, Nveis de Conformidade e Pesos

Para realizar uma avaliao idnea e isenta, devem ser preparados formulrios de avaliao,
que geraro as planilhas e grficos onde os resultados sero demonstrados. Sugere-se, para isso, a
criao de categorias de avaliao para cada rea de avaliao (tcnica / financeira / comercial /
mercadolgica), com um posterior desdobramento das mesmas em quesitos a serem devidamente
pontuados. Cada um dos quesitos de pontuao deve conter, internamente, nveis de conformidade,
que discriminaro a aceitao, a no aceitao ou a aceitao parcial do quesito, em relao ao seu
atendimento s necessidades apresentadas. Ainda, podem ser atribudos pesos cada uma das
categorias de avaliao, de forma a ponderar-se ndices mais elevados onde for dada maior
relevncia quanto aos respectivos quesitos de avaliao das solues candidatas.

muito importante que todos os elementos escolhidos para a realizao de uma avaliao
possam ser, de alguma maneira, avaliados em uma escala coerente (quesitos de pontuao).
Naturalmente, um excesso de itens de pontuao pode trazer dificuldades para a seleo do melhor
fornecedor, alm de que os mesmos podem no se revelar significativos para os objetivos a que se
prestem.
Pg. 85

Pr-Requisitos, reas de Avaliao, as Categorias, Pesos e Quesitos de Pontuao de uma Soluo de Fornecedor

Em nosso exemplo de aquisio de um veculo, vejamos como podem ser elencadas as
categorias em termos de cada uma das reas de avaliao propostas:

Uma vez estabelecidas as categorias de avaliao, cabe-nos elaborar o que ser, de fato
avaliado em cada uma das categorias (quesitos de pontuao), como cada um dos quesitos dever
ser valorado (nveis de conformidade) e, enfim, atribuir-se graus de importncia (ou pesos) a cada
uma das categorias de avaliao (em alguns casos, podem ser atribudos pesos tambm aos quesitos
de avaliao).

Vejamos como ficaria nosso instrumento de avaliao, para o exemplo hipottico de
avaliao de veculos de diversas empresas:
Aquisio de Veculo - Categorias de Avaliao
rea de Avaliao Categoria
Tcnica Desempenho
Segurana
Conforto
Design
Opcionais
Financeira Condies de financiamento
Custos por opcional
Taxas e outros custos
Comercial Atendimento pr-venda
Servios oferecidos
Mercadolgica Posicionamento da empresa no mercado
Posicionamento da montadora no mercado
Posicionamento do veculo no mercado
Tcnica Tcnica
Financeira Financeira
Comercial Comercial
Mercadolgica Mercadolgica
reas de
Avaliao
Pr-Requisitos
Pr-Requisitos
Avaliao
da
Soluo
Avaliao
da
Soluo
Pesos
5
3
4
2
5
3
Nveis de
Conformidade
Categoria 01
Quesito 1.1
Quesito 1.2
Quesito 1.3
Categoria 02
Quesito 2.1
Quesito 2.2
Categoria 03
Quesito 3.1
Quesito 3.2
Categoria 06
Quesito 6.1
Quesito 6.2
Categoria 04
Quesito 4.1
Quesito 4.2
Quesito 4.3
Categoria 05
Quesito 5.1
Quesito 5.2
Categorias
e Quesitos
Instrumento de Avaliao
Tcnica Tcnica
Comercial Comercial
reas de
Avaliao
Tcnica Tcnica
Comercial Comercial
reas de
Avaliao
Pr-Requisitos
Pr-Requisitos
Pr-Requisitos
Pr-Requisitos
Avaliao
da
Soluo
Avaliao
da
Soluo
Pesos
5
3
4
2
5
3
Pesos
5
3
4
2
5
3
Nveis de
Conformidade
Nveis de
Conformidade
Categoria 01
Quesito 1.1
Quesito 1.2
Quesito 1.3
Categoria 02
Quesito 2.1
Quesito 2.2
Categoria 03
Quesito 3.1
Quesito 3.2
Categoria 06
Quesito 6.1
Quesito 6.2
Categoria 04
Quesito 4.1
Quesito 4.2
Quesito 4.3
Categoria 05
Quesito 5.1
Quesito 5.2
Categorias
e Quesitos
Categoria 01
Quesito 1.1
Quesito 1.2
Quesito 1.3
Categoria 02
Quesito 2.1
Quesito 2.2
Categoria 03
Quesito 3.1
Quesito 3.2
Categoria 06
Quesito 6.1
Quesito 6.2
Categoria 04
Quesito 4.1
Quesito 4.2
Quesito 4.3
Categoria 05
Quesito 5.1
Quesito 5.2
Categoria 04
Quesito 4.1
Quesito 4.2
Quesito 4.3
Categoria 05
Quesito 5.1
Quesito 5.2
Categorias
e Quesitos
Instrumento de Avaliao Instrumento de Avaliao
Pg. 86

Exemplo de instrumento de avaliao, contendo categorias de avaliao que atendem s 4 reas (tcnica, financeira,
comercial e mercadolgica), seus respectivos quesitos, nveis de conformidade e pesos

11.2. Solicitao de Propostas

11.2.1. Elaborao das Solicitaes de Propostas (RFP Request for Proposal)

Como sero solicitadas as propostas junto aos fornecedores de forma a tomar-se contato com
suas respectivas solues? Em primeiro lugar, deve ser solicitada uma proposta tcnico-financeira a
Aquisio de Veculo - Instrumento de Avaliao
Empresa: _______________________ Modelo do Veculo: _________________________ Montadora: ___________________ Data: ___ / ___ / ______
0 pontos 3 pontos 7 pontos
Tcnica Desempenho Potncia do motor (cv) At 60 cv De 60,01 a 100 cv Acima de 100 cv
Cilindradas At 1000 cc De 1001 a 1600 cc Acima de 1600 cc
Acelerao 0-100 Km/h Acima de 12 seg De 9,1 a 12 seg At 9 seg
Retomada 40-100 km/h Acima de 10 seg De 7,1 a 10 seg At 7 seg
Consumo por litro At 7 Km De 7,1 a 10 Km Acima de 10 Km
Segurana Barras de proteo lateral No disponvel Instalado
Cinto de segurana reforados No disponvel Instalado
Vidros reforados No disponvel Instalado
Conforto Bancos anatmicos No Sim
Encosto de brao No Sim
Encosto de cabea traseiro No Sim
Direo hidrulica No Sim
Ar condicionado No Sim
Rdio / CD Player No Sim
Design Estilo do carro Popular Esportivo Executivo
Painel Padro Algum atrativo Sofisticado
Estofamento Padro Algum atrativo Couro
Pra-choques da cor do carro No Sim
Opcionais Air-bag motorista No Sim
Air-bag passageiro No Sim
Rodas de liga-leve No Sim
Faris de neblina No Sim
Teto solar No Sim
Financeira Condies de Valor vista Acima de R$30.000 De R$20.000,01 a R$30.000 At R$20.000,00
financiamento Desconto vista At 3% De 3 a 5% Acima de 5%
Opes de financiamento Sem opes Apenas Concessionria Banco + Concessionria
Formas de pagamento Mx 24 meses De 24 a 36 meses De 36 a 48 meses
Taxas anuais de juros Acima de 18% a.a. De 12 a 18% a.a. At 12% a.a.
Custos por Air-bag motorista Acima de R$1.200,00 de R$750,01 a R$1.200,00 At R$750,00
opcional Air-bag passageiro Acima de R$1.200,00 de R$750,01 a R$1.200,00 At R$750,00
Rodas de liga-leve Acima de R$800,00 de R$600,01 a R$800,00 At R$600,00
Faris de neblina Acima de R$350,00 de R$200,01 a R$350,00 At R$200,00
Taxas e outros Custo Seguro Acima de R$850,00 de R$500,01 a R$850,00 At R$500,00
Custos por Custo IPVA Acima de R$850,00 de R$500,01 a R$850,00 At R$500,00
Custo mdio manuteno anual Acima de R$500,00 de R$300,01 a R$500,00 At R$300,00
Custo mdio manuteno 5 anos Acima de R$3.500,00 de R$2.500,01 a R$3.500,00 At R$2.500,00
Depreciao mdia anual Acima de 10% de 7,01 a 10% At 7%
Comercial Atendimento em Atendimento do vendedor Insuficiente Normal Excelente
pr-venda Atendimento da concessionria Insuficiente Normal Excelente
Completude da proposta Insuficiente Normal Excelente
Transparncia Insuficiente Normal Excelente
Servios oferecidos Garantia 1 ano 2 anos
Revises gratuitas 1 2 3
Proximidade de alguma concessionria Distante Prximo Muito prximo
Carro reserva durante revises No Sim
Mercadolgica Posicionamento da Qualidade das parcerias Insuficiente Normal Excelente
empresa no Presena na mesma cidade Fraca Mdia Forte
mercado Presena no mesmo Estado Fraca Mdia Forte
Presena no pas Fraca Mdia Forte
Situao financeira Fraca Mdia Forte
Segmentos de mercado atendidos Pessoa Fsica Pessoa Jurdica Pessoa Fsica e Jurdica
Crescimento mdio anual At 10% de 10,01 a 20% Acima de 20%
Posicionamento da Disponibilidade de peas de reposio Insuficiente Normal Excelente
montadora no Segmentos de mercado atendidos Domstico Domstico / Utilitrios / Txis Todos anteriores + frotistas
mercado Situao financeira Fraca Mdia Forte
Crescimento mdio anual At 15% de 15,01 a 28% Acima de 28%
Posicionamento do Rede de oficinas no formais Fraca Mdia Grande
veculo no mercado Possibilidade de descontinuidade do modelo Alta Mdia Baixa
Compatibilidade com outros modelos Nenhuma Alguma Alta
OBS. As categorias, quesitos e nveis de conformidade deste quadro no objetivam-se necessariamente a atributos verdadeiros, mas sim a elementos meramente didticos.
rea de
Avaliao
Categoria Quesito de Pontuao
Nveis de Conformidade
Peso
5
5
2
4
2
3
3
1
5
1
3
3
3
Pg. 87
cada um dos fornecedores que se deseja contactar. O documento gerado a partir desta etapa
denomina-se RFP (Request for Proposal ou Solicitao de Proposta Tcnico-Financeira, ou
Requisio Formal de Proposta). Ele deve ser claro e conciso, devendo discriminar de forma no
ambgua o que est sendo requerido, quais tpicos, caractersticas e documentos que devero ser
apresentados, qual ser o formato em que as respostas s solicitaes devero ser oferecidas e
quanto custar a soluo final, este ltimo item geralmente devendo ser desdobrado o mximo
possvel, de forma a permitir comparaes entre itens de mesma natureza nas diversas propostas
oferecidas. A data de entrega das propostas deve ser informada neste documento, e deve ser
considerado um perodo realista para a elaborao das propostas por parte dos fornecedores, de
forma a atender os nveis de detalhamento demandados pela equipe do projeto.

natural que ocorra significativa interao entre a organizao e os seus fornecedores
concorrentes, aps a entrega do documento de RFP, pois muitas dvidas podero surgir quanto ao
entendimento do mesmo. Nestes casos, todo e qualquer documento, FAX ou e-Mail enviado a
qualquer um deles tambm dever ser enviado a todos os demais, simultaneamente e, sempre que
possvel, com a formalizao da confirmao de recebimento. Este procedimento tem por finalidade
garantir-se a lisura e a imparcialidade na conduo do processo de avaliao e seleo de
fornecedores.

Uma recomendao importante quanto solicitao de propostas: recomenda-se que se
solicite aos fornecedores candidatos o COMO eles pretendem implementar cada uma das
funcionalidades demandadas. Muitas RFPs, de forma pouco produtiva, perguntam aos fornecedores
apenas SE atendem ou no a determinados requisitos. Por exemplo, ao invs de se solicitar aos
fornecedores candidatos respostas questo utiliza o padro de mercado X para o
desenvolvimento da soluo?, uma abordagem melhor seria quais os padres de mercado sero
utilizados para a implementao da soluo?. Neste tipo de abordagem, o fornecedor deve detalhar
suas respostas de forma a deixar clara sua forma de implementao, ficando a avaliao destes
mritos a cargo da equipe do projeto.

11.2.2. O Recebimento das Propostas Tcnico-Financeiras

Aps o envio das RFPs, a equipe do projeto deve aguardar a entrega da primeira verso das
propostas tcnico-financeiras. Esta primeira verso geralmente no contempla totalmente o que foi
solicitado pelas RFPs, no que se refere aos nveis de clareza e detalhamento demandados pela
equipe do projeto. Muitos itens podem ter que ser melhor explorados, alm de que o formato das
propostas entregues podem no seguir ao que foi estipulado pela RFP, o que pode vir a dificultar o
estudo e a anlise das propostas de cada um dos fornecedores potenciais.

Alm disso, costume que ocorra o seguinte fato: alguns fornecedores, visualizando
possibilidades de oferta de novas funcionalidades s suas solues, acrescentam novas
caractersticas s mesmas, ampliando assim as opes solicitadas atravs da RFP. Pode ainda
ocorrer que, na apresentao de propostas, algumas funcionalidades normais dos produtos
oferecidos apresentem-se como novidade para os avaliadores das solues candidatas. Dependendo
das condies tcnicas e financeiras envolvidas, pode ser interessante solicitar a todos os
fornecedores as novas funcionalidades vislumbradas, agregando-as em RFPs complementares.
Nestas ltimas, novos detalhamentos devem ser ento solicitados, desta vez voltados s novas
caractersticas de soluo a serem contempladas. O objetivo, nesta etapa especfica, o de nivelar as
propostas de todos os fornecedores, evitando-se o problema serem avaliadas solues que ofeream
caractersticas distintas.
Pg. 88

Nesta etapa intensifica-se a interao entre a organizao contratante e os diversos
fornecedores candidatos, de forma a serem solicitadas novas verses das propostas para que se
faam os devidos esclarecimentos e detalhamentos necessrios, seja quanto ao que foi solicitado
pela RFP original, seja quanto ao que pedem as RFPs complementares.

ATENO! A etapa de Estabelecimento de Critrios de Avaliao no necessariamente
precisa anteceder a etapa de Solicitao de Propostas. Em alguns casos, as propostas so
solicitadas anteriormente ao estabelecimento de critrios de avaliao. Em qualquer caso, contudo,
recomenda-se que no se passe para a etapa de Realizao da Avaliao sem antes estarem bem
definidos todos os critrios de avaliao a serem empregados.

11.3. Realizao da Avaliao

Uma vez que todas as propostas niveladas tenham sido entregues, inicia-se o processo de
avaliao das mesmas. Naturalmente, devem ser analisados apenas os fornecedores que estejam em
total acordo com os Pr-Requisitos previamente estabelecidos. O no atendimento aos mesmos
implica em desclassificao imediata dos fornecedores em respectivo desacordo. Aps esta primeira
filtragem, efetivamente realizada a avaliao de cada uma das propostas entregues, pontuando os
quesitos j definidos em termos dos nveis de conformidade estabelecidos previamente. Vejamos,
logo a seguir, algumas recomendaes para a avaliao dos diversos quesitos, conforme sua rea de
avaliao correspondente.

11.3.1. Avaliao Tcnica

Para a pontuao das categorias e quesitos tcnicos, o mtodo mais direto atravs da
anlise das prprias propostas, que funcionam como uma espcie de contrato de prestao de
servios. Alm disso, pode ser que sejam verificados outros instrumentos, como apresentaes dos
fornecedores, sites da Internet que se referem aos produtos ou a componentes da soluo oferecida,
literatura especializada, entrevistas com especialistas, entre outras fontes. No entanto, importante
ressaltar que somente o que estiver explicitado numa proposta de soluo de um fornecedor que
poder ser considerado para efeito de pontuao, pois este o nico instrumento formal que
oficialmente os compromete a realizar o que est sendo solicitado.

Alguma exceo pode ser feita no que tange, por exemplo, a tecnologias de apoio s
solues demandadas. Por exemplo, supondo que esteja sendo avaliada uma soluo de ERP
(Enterprise Resource Planning ou ferramenta de gesto integrada), e tambm estejam sendo
avaliados os sistemas operacionais a serem disponibilizados nos servidores (por exemplo, Microsoft
Windows 2000, NOVELL Netware ou HP-UX). Neste caso, a avaliao das funcionalidades da
categoria sistemas operacionais de servidor poderiam ser melhor verificadas em relatrios
produzidos por entidades ou publicaes especializadas, ou mesmo atravs de entrevistas com
especialistas muitas vezes existentes na prpria organizao contratante (neste ltimo caso, deve-se
tomar cuidado para no se deixar levar pelos argumentos apaixonados dos xiitas tecnolgicos,
que defendem vertentes tecnolgicas como uma religio, fechando os olhos para outras alternativas
igualmente viveis).

Pg. 89

11.3.2. Avaliao Financeira

Para a pontuao dos quesitos das caractersticas financeiras, sempre que possvel devem ser
produzidos valores baseados em cada mdulo da soluo a ser entregue, de forma a permitir
comparaes de itens que sejam similares entre os diversos fornecedores. Desta forma, pode-se
perceber quais seriam os mdulos mais caros, e destas informaes poderiam sugerir abordagens
mais eficientes nas negociaes de preos finais. Alm disso, devem ser apresentados resumos que
contemplem os valores totais a serem investidos pela organizao contratante, preferencialmente em
planos de desembolso mensais. importante observar que alguns fornecedores apresentam seus
custos baseados em homens/hora, enquanto que outras apresentam seu preos em termos de valores
finais. Deve-se tomar muito cuidado com as solues baseadas em horas, pois podem estourar os
oramentos no mdio prazo. Por outro lado, as propostas entregues em termos de valores
fechados podem embutir o risco do estouro dos cronogramas por parte dos fornecedores, o que
encareceria a soluo.

Podem ser avaliadas condies de pagamento, formas de parcelamento e/ou financiamento,
possibilidade de contratao de mdulos parciais, ao longo do tempo, entre outras condies
financeiras especficas.

11.3.3. Avaliao Comercial

Na avaliao dos aspectos comerciais, deve-se tentar, o mximo possvel, contactar outros
clientes das solues entregues, de forma a obter deles depoimentos verdadeiros referentes ao
processo de implementao das solues por parte dos fornecedores avaliados. Estas entrevistas
podem ser realizadas nas prprias instalaes dos clientes bem como via telefone ou vdeo-
conferncia, por exemplo. Deve-se, no entanto, considerar o contexto organizacional em que os
clientes verificados se encontrem, pois estes podem ser ou estar estruturados de forma
completamente distinta de como se organiza a empresa contratante.

Uma outra fonte de informaes importante em relao avaliao de categorias da rea
comercial pode ser os depoimentos de colaboradores que tenham tido experincias (felizes e
infelizes) em outras organizaes, onde os fornecedores candidatos tenham prestado seus servios.
Porm, devem ser verificadas questes ticas e baseadas em opinies pessoais tanto neste caso
quando por ocasio da realizao das visitas e entrevistas com demais clientes dos fornecedores
potenciais. Nestes casos, muitos dos critrios de avaliao podem ser percebidos subjetivamente, ou
seja, baseados unicamente nas vises especficas de outros colaboradores e clientes, e no
necessariamente baseados em fatos efetivamente verdadeiros.

A avaliao comercial, num aspecto mais objetivo, tambm deve considerar a rede de
suporte formal estabelecido pelos fornecedores, ou se existe um centro de atendimento a clientes via
telefone, FAX, ou e-Mail. Pode ser verificada a presena de sites para oferta de servios e
documentao de apoio, entre outros aspectos, conforme os itens j apontados na sub-seo reas
de Avaliao.

11.3.4. Avaliao Mercadolgica

A avaliao mercadolgica refere-se, exclusivamente, a anlise do fornecedor e/ou de suas
solues sob um ponto de vista macro. Neste caso, organismos independentes e publicaes
Pg. 90
especializadas poderiam oferecer importantes dados relativos ao market-share da empresa/soluo
nos mercados regionais, nacionais ou internacionais, bem como as taxas de crescimento de
ocupao destes espaos. Sendo possvel, deve-se utilizar o setor financeiro para uma avaliao das
empresas fornecedoras sob o ponto de vista contbil/econmico, divulgado atravs de seus balanos
periodicamente publicados.

Assim que os instrumentos de avaliao estejam devidamente preenchidos, o registro das
avaliaes ser efetivamente produzido. Tais resultados devem ser devidamente tabulados e, dentro
dos critrios definidos anteriormente, devem ser indicados os fornecedores que tenham vencido o
processo. Aps isso, deve ser produzido um relatrio executivo de recomendao da soluo, para
apreciao do corpo decisrio da organizao contratante.

11.4. O Relatrio de Recomendao

A partir dos resultados oferecidos pela avaliao deve-se produzir um relatrio dirigido aos
nveis executivos da organizao. Este relatrio deve compr-se, basicamente, de duas partes. A
primeira, a recomendao propriamente dita, deve ser concisa, sumarizando a escolha realizada,
com um breve resumo das pontuaes obtidas em termos macro, os custos totais e ponderaes
mais gerais sobre cada uma das solues apresentadas, nos aspectos tcnicos, financeiros,
comerciais e mercadolgicos. Como trata-se de um documento executivo, no pode ser muito
extenso, contendo um nmero adequado de pginas para leitura especificamente por parte dos
tomadores de deciso da organizao contratante, mas tambm no pode ser extremamente sucinto,
pois isso pode levar perda de credibilidade em relao consistncia das escolhas e
recomendaes oferecidas.

Para facilitar o entendimento do investimento a ser realizado no projeto, idealmente
recomendvel a elaborao de um plano de desembolso mensal, discriminando gastos com pessoal,
obras, software, equipamentos, materiais, suprimentos, servios, taxas e impostos. Desta forma,
possvel realizar o planejamento financeiro dos investimentos necessrios, alm de permitir a
visualizao do oramento final ao longo do tempo.

A segunda parte do Relatrio de Recomendao refere-se aos seus anexos. Nesta parte, cabe
toda a documentao produzida pela equipe do projeto, como as atas de reunio, os desdobramentos
da avaliao, enfim, todos os detalhes que fizeram parte do processo como um todo. Na verdade,
dificilmente algum ir ler todas as suas pginas, mas as mesmas prestam-se como referncias ao
que est sumarizado na primeira parte do Relatrio de Recomendao, suportando-o e dando-lhe
subsdios para um entendimento mais pormenorizado do processo.

Duas consideraes devem ainda ser feitas em relao ao Relatrio de Recomendao. A
primeira quanto organizao da primeira parte. Executivos preferem conhecer os dados macro
em primeiro lugar, para depois irem questionando seus detalhes. Isso significa que, a recomendao
das solues vencedoras devem vir o quanto antes possvel neste relatrio, seguidas pelos seus
custos e prazos totais (estes tpicos preferencialmente apresentados de forma sumarizada na
primeira pgina do documento), e deixando outras consideraes e informaes para as pginas
posteriores. Alm disso, os executivos podem demandar que determinadas informaes sejam
acrescentadas ou informadas em formatos diferentes, o que leva a equipe do projeto a um perodo
Pg. 91
intenso de modificaes no formato final do Relatrio de Recomendao, o que pode levar a vrias
interaes num breve perodo de tempo, gerando novas e frequentes verses deste documento.

A segunda considerao ocorre quando existe o chamado empate tcnico, ou seja, quando
duas ou mais empresas fornecedores apresentam solues igualmente eficientes e a custos muito
competitivos entre si. Alm disso, podem ainda ocorrer discrepncias quanto s funcionalidades
oferecidas por cada fornecedor em potencial, tornando a recomendao final mais complexa, pois
estaria-se considerando situaes distintas, ou seja, no niveladas.

Por exemplo, considere o caso em que um dos fornecedores oferea uma soluo mais
enxuta e, consequentemente, menos dispendiosa, enquanto que um outro pode apresentar uma
soluo mais robusta e, por sua vez, mais cara. Ou ainda, uma empresa fornece a soluo de
forma a implement-la nas instalaes da empresa contratante, enquanto que outra oferece o servio
que atende soluo, porm implementando-o internamente. Nestes casos, podem ser realizados
cenrios ou simulaes, prevendo evolues possveis com cada uma delas e seus impactos
tcnicos, financeiros e operacionais envolvidos (como prazos, recursos, capacitao tcnica, infra-
estrutura administrativa, entre outros aspectos).

A deciso final neste caso (e como sempre ser em todos os outros) dever recair para o
corpo decisrio da organizao, que certamente levaro em alta conta as opinies e
posicionamentos da equipe do Projeto. De qualquer maneira, a equipe do Projeto dever sempre
recomendar uma nica soluo, mesmo que os executivos e clientes optem por outras alternativas
ou linhas de ao.

11.5. Contratao dos Parceiros Escolhidos

Uma vez escolhido o fornecedor, pode ser que a soluo oferecida por este ltimo demande
muito mais recursos do que o originalmente previsto no incio do projeto (ou do processo de
avaliao). Esta concluso parcialmente justificvel, pois as previses iniciais para os custos,
prazos e recursos podem ter sido subestimadas principalmente diante da complexidade incorporada
a partir dos estudos mais detalhados realizados no decorrer do processo de avaliao de
fornecedores e de solues. Neste caso, o projeto corre o risco de ser suspenso, ou colocado em uma
situao de inviabilidade, o que interromperia seu processo de implementao, muitas vezes por
longos e indefinidos perodos. Por isso que se torna importante uma boa estimativa inicial de
parmetros e recursos para o projeto no momento de seu planejamento inicial, o que aumentaria sua
chances de ser aprovado neste estgio de desenvolvimento. Um outro aspecto importante a ser
verificado quanto a esta possibilidade que projetos anteriormente desenvolvidos tm muito a
acrescentar em termos da experincia vivida por suas equipes respectivas, oferecendo uma grande
massa crtica que poderia ser utilizada para evitarem-se novos erros na previso dos recursos de
projetos em curso. Sendo assim, sempre muito saudvel o envolvimento de profissionais mais
experientes na estimao de prazos e custos logo no incio de projetos, apoiando na inferncia de
duraes e valores de forma a minimizar desvios muito significativos.

Caso o projeto seja aprovado aps o exame do corpo diretivo sobre o Relatrio de
Recomendao, pode ser que os diretores da organizao contratante desejem negociar com os
fornecedores condies especficas de pagamento ou na oferta de produtos e servios.

Pg. 92
importante ressaltar que, a no ser quando for delegado ao lder de projetos, que o mesmo
resista tentao de entrar em negociaes diretas com os fornecedores candidatos quanto aos seus
valores financeiros finais. Normalmente, os nveis de autoridade dos gerentes de projeto so
limitados no que se refere negociaes com fornecedores externos. Some-se a isso o fato de que a
utilizao de tcnicas mais agressivas de negociao de forma a trazer condies efetivamente mais
vantajosas para a organizao contratante , normalmente, um privilgio de altos executivos.

Tcnicas de negociao podem ser melhor utilizadas pelo pessoal de outras reas da empresa
como, por exemplo, os gerentes das reas usurias, ou pelo pessoal dos setores de compras, ou
mesmo, como j citado, pelos prprios executivos principais da empresa. Em geral, um lder de
projetos tambm no possui autonomia para oferecer contra-propostas aos fornecedores potenciais.
Um lder de projetos pouco experiente em tcnicas de negociao pode minar o relacionamento
da empresa com os provveis fornecedores, inviabilizando dilogos futuros ou at mesmo ferindo a
imagem da organizao perante o mercado. alm de que poderiam haver srias dvidas quanto
aquisio de condies realmente vantajosas para a organizao contratante, intermediadas por este
profissional.

Aps todos os acertos finais, os fornecedores devem ser contactados pelo pessoal especfico
da organizao para a aquisio e contratao dos produtos e servios correspondentes, encerrando-
se, assim, o ciclo de contratao dos parceiros de negcio especficos.

Deve-se ressaltar, contudo, que a gerncia dos contratos, dos recursos e profissionais de
terceiros, do nvel de qualidade dos produtos e resultados disponibilizados pelos fornecedores,
responsabilidade inerente aos gerentes de projetos, mesmo que ele prprio tenha delegado tais
atribuies a outros setores e profissionais da organizao.

Pg. 93
12. Consideraes Finais (mas no menos importantes)

12.1. Envolvimento do Pessoal Interno da Organizao

Para que um Projeto possa ser desenvolvido de forma consistente e adequada s reais
necessidades de uma empresa, deve ser fortemente considerado o apoio dos principais executivos da
organizao, bem como o envolvimento dos diversos setores da empresa, que certamente
contribuiro com depoimentos e posicionamentos alavancadores de oportunidades. Apoio este que
no dever ficar restrito ao fornecimento de recursos e liberao de verbas para que estas iniciativas
sejam levadas a cabo pelas equipes de projeto. fundamental que as resistncias culturais sejam,
pouco a pouco, vencidas, principalmente atravs de posturas pr-ativas, na abertura para debates e
discusses que favoream o questionamento quanto s alternativas de solues por serem adotadas.

Uma organizao no so seus Projetos, nem seus Processos internos, nem tampouco toda a
Tecnologia da Informao que venha a possuir. So as Pessoas que ali trabalham, objetivando a
excelncia naquilo que dispem para a comunidade, para os clientes da instituio, para seus
acionistas e, naturalmente, para si prprias. Os Processos so a estruturao do know-how da
organizao, a forma como ela pensa que deve trabalhar, objetivando sua total eficincia e eficcia
em seus fluxos de produo e de prestao de servios. A Tecnologia da Informao um poderoso
instrumento que torna muitas das tarefas desempenhadas por seus colaboradores menos onerosas e
complexas. E os Projetos so apenas uma maneira estruturada e inteligente de se preparar a
incorporao destas melhorias. Portanto, de nada adiantariam projetos altamente sofisticados, bem
elaborados e bem conduzidos se no for conseguido significativo respaldo interno por parte de
todos os nveis organizacionais envolvidos. E de nada adiantaria todo esse pessoal envolvido se no
houvesse algum, um gerente, um lder de projetos, tentando fazer com que todos caminhem em
uma mesma direo.

12.2. Quando dizer NO

comum, no mbito corporativo, que se deseje a incorporao de melhorias atravs de
projetos com um mnimo de esforo, atravs do menor dispndio possvel de dinheiro e recursos, da
forma mais eficaz, eficiente e produtiva possvel, e em prazos cada vez menos dilatados.
Idealmente, o que todos desejamos que possa ser feito. E um dos papis da alta e mdia
gerncias exercer um determinado nvel de presso por resultados, preferencialmente de forma a
atender aos parmetros acima citados. Do contrrio, as solues demandadas seriam as mais caras
possveis, implementadas em prazos astronomicamente estendidos, e de forma a demandar todos os
recursos disponveis e no disponveis da organizao. Ns, profissionais, por vrias vezes,
alimentamos nossos prprios sonhos de soluo, algo que se revela como inatingvel, porm,
ideal, perfeito. E uma importante atribuio das gerncias no permitirem que nossos devaneios
nos dominem por completo, privando-nos de uma realidade fatal que a de que h um negcio por
aqui a ser tocado.

No entanto, h limites para o que factvel, o que vivel num sentido prtico. Excesso de
presso pode ser prejudicial, pode levar a solues fracas, escolhas errneas e, o que pior, a
considerar alternativas que ningum de fato acredita que podero satisfazer s necessidades
apontadas. E de responsabilidade dos lderes de projeto, amparados por suas equipes, determinar
que, nos momentos adequados, determinadas exigncias no podero ser atendidas pelos Projetos
que lhes cabem. Amparando sua postura, tais equipes devem oferecer a argumentao convincente,
Pg. 94
os caminhos alternativos a serem pesquisados e as novas possveis propostas de soluo para os
problemas com os quais se vem desafiados. Sobretudo, devem estar atentos a novas perspectivas
de soluo, a todo o tempo, e perspectivas estas muitas vezes originrias de situaes e pessoas
improvveis. Uma abordagem comum para se dizer no a algo solicitado que no encontra
viabilidade para sua execuo a prpria devoluo da pergunta, apresentando-se outras iniciativas
em curso que poderiam ser paralisadas ou suspensas em favor do novo empreendimento. Esta
deciso deve ficar a cargo das aladas com poder de transferncia de prioridades de uma frente para
a outra, e assim assumir-se as responsabilidades devidas pelos eventuais atrasos nos projetos
preteridos.

A negativa imposio de uma soluo tida como invivel resultado de um extremo senso
tico e de profissionalismo. A transparncia, a capacidade de assumir a verdade, mesmo que ela no
seja a constatao mais agradvel a ser verificada no momento, a firmeza nos posicionamentos e a
transparncia dos argumentos levam uma empresa a no investir tempo e dinheiro em tentativas
fatalmente suscetveis ao fracasso.

H uma frase que, de forma simplria, poderia traduzir situaes como estas: prefervel
ficar vermelho uma nica vez dizendo NO, do que amarelo todos os dias, at o final do
Projeto, dizendo SIM, e no acreditando, de fato, que ns realmente faremos isso...

12.3. Voc um Lder de Projetos?

Voc se v na situao de assumir projetos caros e complexos? Voc se enquadra nas
caractersticas definidas como ideais para a liderana de uma iniciativa corporativa baseada em uma
grande e intrincada soluo de misso-crtica? Voc se considera um excelente negociador,
planejador, motivador e gestor de pessoas, solucionador de conflitos, condutor de reunies? No,
no e no?

Acredite: ningum perfeito. Todos temos caractersticas de personalidade, formao,
crenas, valores, princpios e posicionamentos pessoais que, dificilmente, nos abandonaro quando
assumirmos funes de alta responsabilidade. Ainda, muitas das exigncias demandadas para
estes profissionais podem ser desenvolvidas, aperfeioadas, melhoradas e otimizadas. Pode-se
desenvolver, por exemplo, empatia, diplomacia, bom-senso empresarial, adquirir importantes
conhecimentos do mercado, de tecnologia, do negcio especfico, entre outros aspectos.

No entanto, a questo aqui ainda mais simples: voc REALMENTE QUER se tornar um
lder de projetos?

A histria est repleta de exemplos de lderes, de grandes empreendedores, inventores,
aventureiros, descobridores, pesquisadores, pioneiros, artistas, sonhadores. Nenhum deles era
perfeito. Todos eles possuam diversos e inominveis defeitos, e defeitos estes que, na maior parte
das vezes, eles nem se esmeraram em minimizar. Alguns, mesmo brilhantes no que os tornaram
conhecidos, jamais dominaram a totalidade do universo de conhecimentos que seria mandatrio que
possussem para atingirem o real estgio de gnios. Vrios deles cometeram erros abissais,
fracassaram tragicamente em muitas de suas tentativas. E ainda assim foram realizadores
excepcionais, brilhantes, geniais.

Pg. 95
Mas... o que ento lhes tornava to diferenciados? O que lhes trazia tanto sucesso, tantas
realizaes? Era o fato de que, por sorte, estavam em um lugar certo, na hora exata e, por acaso,
executavam algo que, deste jeito, s podia dar certo mesmo...?

Ou era o fato de que j estavam predestinados a estas realizaes, a se tornarem fenomenais,
desde o incio dos tempos? Ou, ainda, era porque j possuam as respostas certas na cabea antes
que algum pudesse sequer imaginar as perguntas? Talvez, quem sabe?

Contudo, certamente todos eles sabiam do poder que possuam para erguer-se todas as vezes
que falhassem. Todas as vezes. At porque eles no deixavam de falhar.

Eles aprendiam a continuar acreditando em si mesmos.

Mas... por que que ns sempre nos referimos a eles como... Eles? Por que eles no
poderamos ser... Ns? Sim, claro! Pois olhe s para Ns. Veja no que Ns nos transformamos. Ns
construmos nossas famlias, criamos nossos filhos, confortamos nossas vivas, vencemos nossos
medos. Ns, todos os dias, conquistamos amigos, pessoas, desejos e vitrias, vencemos desafios.
Ns construmos pontes, poemas, pases e verdades. Ns libertamos injustias, preconceitos, limites,
amores satisfeitos.

Ns construmos o mundo...

Enfim, todos Ns, estes seres brilhantes, ao conduzirmos maravilhosamente nossos
prprios Projetos, tornando-nos to bem sucedidos, devemos guardar, pelo menos, uma
caracterstica mpar e comum em nossos coraes.

Ns, simples e profundamente, devemos acreditar que SIM, que tudo o que quisermos pode
ser feito.

Depende de Ns.

Pg. 96
13. Referncias Bibliogrficas

. CARNEGIE, Dale. Como fazer amigos e influenciar pessoas. 51. Edio. So Paulo:
Companhia Editora Nacional, 2003.

. COVEY, Stephen. Os 7 Hbitos das Pessoas Altamente Eficazes. So Paulo: Best Seller, 2000.

. DAVENPORT, Thomas H. Ecologia da Informao. So Paulo: Futura, 1998.

. DAVENPORT, T. PRUSAK, L. Conhecimento Empresarial. Rio de Janeiro: Campus, 1999.

. GATTONI, Roberto L. C. Gesto do conhecimento organizacional na conduo de projetos
corporativos em tecnologia da informao um caso prtico. Belo Horizonte: Escola de
Cincia da Informao da UFMG, 2000. 150p. (Dissertao, Mestrado em Informao
Gerencial e Tecnolgica).

. GATTONI, Roberto L. C.; FERREIRA, Marta Arajo Tavares. A gesto do conhecimento na
conduta de projetos corporativos em tecnologia da informao um estudo de caso. In:
Simpsio de Gesto da Inovao Tecnolgica, 21, 2000, So Paulo, SP. Anais do XXI
Simpsio de Gesto da Inovao Tecnolgica. So Paulo: Ncleo de Poltica e Gesto
Tecnolgica da Universidade de So Paulo: PGT/USP, 2000, pp. 97 (resumo) texto integral
em CD-ROM.

. GATTONI, Roberto L. C. A atuao do gerente de projetos na era do conhecimento. In:
ISKM/DM International Symposium on Knowledge Management/Document Management,
4, 2001, Curitiba, PR. Anais do 4o. International Symposium on Knowledge Management/
Document Management. Curitiba: Pontifcia Universidade Catlica do Paran PUC/PR/
Centro Internacional de Tecnologia de Software CITS, Curitiba, Brasil, 2001, pp. 253-274.

. GATTONI, Roberto L. C. A Gesto do Conhecimento Aplicada Prtica da Gerncia de
Projetos. In: Congresso Ibero-Americano de Gerncia de Projetos, 4, 2003, Rio de Janeiro
(no prelo).

. GATTONI, Roberto L. C.; FERREIRA, Marta Arajo Tavares. A gesto do conhecimento na
conduta de projetos corporativos em tecnologia da informao um estudo de caso. In:
TERRA, Jos Cludio; KRUGLIANSKAS, Isak. Gesto do conhecimento em pequenas e
mdias empresas: lies extradas de casos reais. Rio de Janeiro: Campus, 2003, pp. 319-342.

. HELDMAN, Kim. Gerncia de Projetos: guia para o exame oficial do PMI. 2. Edio. Rio de
Janeiro: Campus, 2003.

. KERZNER, Harold. Gesto de Projetos: as melhores prticas. Porto Alegre: Bookman, 2002.

. MARTINS, Jos Carlos Cordeiro. Gesto de Projetos de Desenvolvimento de Software. Rio de
Janeiro: Brasport, 2002.

. MAXIMIANO, Antnio Csar Amaru. Administrao de Projetos: como transformar idias em
resultados. So Paulo: Atlas, 2002.
Pg. 97

. MENEZES, Lus Csar de Moura. Gesto de Projetos. 2. Edio. So Paulo: Atlas, 2003.

. MEREDITH, Jack R.; MANTEL JR., Samuel J. Project Management: a managerial approach.
New York: John Wiley and Sons, 1995.

. MICROSOFT CORPORATION. Microsoft Solutions Framework. United States: Microsoft
Press, 1993-1996.

. NETO, Fernando Henrique da Silveira. O Gerente de Informtica (Alm do C.P.D.). Rio de
Janeiro: COP Editora, 1989. p.29-39.

. NONAKA, Ikujiro; TAKEUCHI, Hirotaka. Criao de conhecimento na empresa: como as
empresas japonesas geram a dinmica da inovao. Rio de Janeiro: Editora Campus, 1997.

. PETERS, Thomas J. Fazer primeiro, pensar depois. HSM Management, So Paulo, v.1, n.3,
p.14-18, jul./ago. 1997.

. PRADO, Darci. Gerncia de projetos em tecnologia da informao. Srie Gerncia de Projetos,
v. 5. Belo Horizonte: Editora DG, 1999.

. PROJECT MANAGEMENT INSTITUTE. A Guide to The Project Management Body of
Knowledge. 2000 Edition. Charlotte, NC, USA: Automated Graphic Systems, 2000.

. STAIR, Ralph M. Princpios de Sistemas de Informao: uma abordagem gerencial Segunda
Edio. Rio de Janeiro: LTC Livros Tcnicos e Cientficos Editora, 1998.

. STEWART, Thomas. Capital intelectual: a nova vantagem competitiva das empresas. Rio de
Janeiro: Campus, 1998.

. SVEIBY, K. E. A Nova Riqueza das Organizaes. Rio de Janeiro: Campus, 1997.

. VARGAS, Ricardo Viana. Gerenciamento de Projetos: estabelecendo diferenciais competitivos.
Rio de Janeiro: Brasport, 2000.

. VERMA, Vijay K. Human Resource Skills for the Project Manager. Charlotte, NC, USA:
Automated Graphic Systems, 1996.

. WIDEMAN, R. Max. Project and Program Risk Management: A Guide to Managing Project
Risks and Opportunities. Charlotte, NC, USA: Automated Graphic Systems, 1992.

Apostila Gerencia Projetos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Apostila Gerencia Projetos

Transféré par

Droits d'auteur :

Formats disponibles

Gerncia de Projetos

* Verso 1.19r *

Vous aimerez peut-être aussi