Gerenciamento de projetos: conceitos-chave

Gerência de Projetos Mauro Rezende Filho
Gerência de Projetos
Para cursos de Administração, Ciências Contábeis, Economia e

Engenharia de Produção
Mauro Rezende Filho, M.Sc.

OBRAS DO AUTOR
Livros
 Gestão por Projetos Aplicando o Método PERT/CPM e o Software MS-Project

 Engenharia Financeira – Fundamentos para Avaliação e Seleção de Projetos de Investimentos
e Tomada de Decisão
 Sistema CUP de Apropriação de Custos
 Pesquisa Operacional – Volume I - Programação Linear – Otimização em Apoio à Tomada de
Decisão
 Pesquisa Operacional – Volume II – Métodos Quantitativos para a Otimização de Sistemas
Produtivos
 Pesquisa Operacional – Volume III - Fundamentos de Teoria dos Estoques, Teoria dos Jogos,
Teoria das Filas e Simulação com Arena
 Fundamentos de Economia
 Administração da Produção e Materiais
Apostilas
 Probabilidade e Estatística Utilizando e Excel

 Manual do MS-Project 2003
 Gestão Estratégica
 Gestão na Pequena e Média Empresa
 Matemática Básica
 Matemática Avançada
 Matemática Financeira
 Fundamentos de Álgebra Linear
 Gestão de Materiais
 Engenharia de Manutenção
 Contabilidade para Engenheiros
 Contabilidade de Custos I
 Contabilidade de Custos II
 Raciocínio Lógico e Algoritmos
 Administração da Produção
 Organização, Sistemas e Métodos
 Economia para Engenheiros
Artigos
 Balanced Scorecard: Instrumento de Desdobramento de Estratégia e Alavancagem de

Resultados
 Empreendedorismo e Tecnologia da Informação nas MPMEs
 Avaliando o Risco nas decisões de Orçamento Empresarial: Uma Aplicação Prática do Método
de Monte Carlo
 Estratégia Empresarial: Um Diferencial Competitivo
 CUP – Sistema de Custos por Pontos: Uma aplicação para Pequena e Média Empresa
 Um Modelo Alternativo para Avaliação de Investimento em Navios em Condição de Incerteza
 Um Modelo de Opções Reais para Avaliação de Investimento em Navios Petroleiros
 Operational System Analysis on Iron Ore Exportation in Rio de Janeiro
 Optimization of the production program of an Agricultural Business Industry: applying the
linear programming model
 Avaliação de Empresas sob Incerteza: uma Aplicação Prática do Método de Monte Carlo como
Auxílio ao Processo Decisório
 A Real Options Approach to Ship Investment Appraisal
Conceitos-Chave 3
Sumário
1 Introdução ................................................................................................................................. 1
2 Conceitos-Chave ...................................................................................................................... 3
2.1 Conceito de Projeto ......................................................................................................... 3
2.2 Gerenciamento de Projetos ............................................................................................ 4
2.3 Operações X Projetos ..................................................................................................... 4
2.4 Exemplos de Projetos ..................................................................................................... 5
2.5 Exemplos de Não-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 ................................................................... 10
3 Fases de um Projeto e seu Ciclo de Vida .............................................................................. 13
3.1 Subdivindo os Projetos ................................................................................................. 13
3.2 Fases Genéricas do Ciclo de Vida de um Projeto ........................................................ 14
3.3 Comportamento Genérico de um Projeto ao Longo do Ciclo de Vida .......................... 15
3.4 Importância Relativa dos Objetivos do Projeto quanto ao Ciclo de Vida .................... 18
4. Estratégias para Desenvolvimento de Novos Produtos ........................................................ 22
4.1 Desenvolvimento de novos produtos e estratégias de ciclo de vida ............................ 22
5 O Gerente de Projetos ............................................................................................................ 29
6. A Proposta do PMI para o Gerenciamento de Projetos ........................................................ 31
6.1 Os Grupos de Processos de um Projeto ...................................................................... 31
6.2 Áreas de Conhecimento do Gerenciamento de Projetos.............................................. 34
6.3 Relação entre Grupos de Processos e Áreas de Conhecimento ................................. 35
7. O Relatório Executivo ............................................................................................................ 43
7.1 Missão ........................................................................................................................... 43
7.2 Diagnóstico .................................................................................................................... 45
7.3 Escopo .......................................................................................................................... 45
7.3.1 Objetivos (ou, O Quê o Projeto REALIZARÁ):.................................................. 45
7.3.2 O Quê o Projeto NÃO REALIZARÁ .................................................................. 46
7.4 Restrições .................................................................................................................... 46
7.5 Premissas ..................................................................................................................... 47
7.6 Benefícios ..................................................................................................................... 48
7.7 Riscos ........................................................................................................................... 49
7.8 Macro-Fases ................................................................................................................ 49
7.9 Justificativas para Contratações e Aquisições ............................................................. 50
7.10 Perfil da Equipe de Projeto .......................................................................................... 51
7.11 Orçamento Preliminar .................................................................................................. 51
7.12 Fatores Críticos de Sucesso ........................................................................................ 52
8. O Plano de Execução ............................................................................................................ 55
8.1 Cronograma ................................................................................................................. 55
8.2 Matriz de Responsabilidades ....................................................................................... 59
.
8.3 Plano de Desembolso .................................................................................................. 61
8.4 Produtos e Sub-Produtos ............................................................................................. 62
8.5 Plano de Comunicação ................................................................................................ 64
9. Negociação e Alocação de Recursos.................................................................................... 67
9.1 Negociando a Alocação de Profissionais ..................................................................... 67
9.2 Negociando a Alocação de Recursos Físicos ............................................................. 68
10. Gerência de Riscos ............................................................................................................ 69
10.1 Definição de Risco ....................................................................................................... 69
10.2 Características do Risco .............................................................................................. 69
10.3 Princípios de uma Gerência de Riscos bem sucedida ................................................ 69
10.4 Origens dos Riscos ...................................................................................................... 70
10.5 Impactos dos Riscos .................................................................................................... 70
10.6 Gestão Pró-ativa de Riscos ......................................................................................... 71
10.7 Estratégias para o Gerenciamento de Riscos ............................................................. 71
10.8 O Processo de Gerenciamento de Riscos .................................................................... 71
10.8.1 Identificação dos Riscos .................................................................................. 72
10.8.2 Análise dos Riscos ........................................................................................... 73
10.8.3 Elaboração de Planos de Tratamento dos Riscos ........................................... 75
10.8.4 Acompanhamento dos Riscos ......................................................................... 77
10.8.5 Controle dos Riscos ......................................................................................... 77
10.9 O Documento de Avaliação de Riscos .......................................................................... 78
11. Instrumentos para Condução e Desenvolvimento de Projetos ........................................... 79
11.1 Instrumentos de Apoio ao Controle de Projetos .......................................................... 79
11.1.1 TO-DO Lists .................................................................................................... 79
11.1.2 Listas de Pendências (Checklists) .................................................................. 80
11.1.3 Bases de Acompanhamento de Atividades .................................................... 81
11.1.4 Reuniões de Acompanhamento ...................................................................... 82
11.1.5 Roteiros para Entrevistas/Reuniões (Scripts) ................................................. 83
11.1.6 Relatórios de Relacionamento com Fornecedores ......................................... 83
11.1.7 Bases Executivas para Acompanhamento de Projetos .................................. 84
11.2 Instrumentos de Apoio à Gestão do Conhecimento Presente nos Projetos ............... 85
11.2.1 Protótipos ........................................................................................................ 85
11.2.2 Ambientes de Homologação ........................................................................... 86
11.2.3 Projetos-Piloto ................................................................................................. 87
11.2.4 Laboratórios .................................................................................................... 88
11.2.5 Benchmarking de Soluções ............................................................................ 88
11.2.6 Fóruns de Discussão/Conhecimento .............................................................. 89
11.2.7 Relatórios de Eventos ..................................................................................... 90
11.2.8 Transferência de Conhecimento por Tradição................................................ 90
11.2.9 Reuniões de Lições Aprendidas ..................................................................... 91
11.2.10 Apresentações Executivas .............................................................................. 92
12. Avaliação e Escolha de Fornecedores ................................................................................ 93
12.1 Estabelecimento de Critérios de Avaliação ................................................................. 93
12.1.1 Definição de Pré-Requisitos............................................................................ 93
12.1.2 Áreas de Avaliação ......................................................................................... 94
12.1.3 Categorias, Quesitos de Pontuação, Níveis de Conformidade e Pesos ........ 96
12.2 Solicitação de Propostas ............................................................................................... 98
12.2.1 Elaboração das Solicitações de Propostas .................................................... 98
Conceitos-Chave 5
11.2.2 O Recebimento das Propostas Técnico-Financeiras .................................... 99

12.3 Realização da Avaliação ............................................................................................ 100
12.3.1 Avaliação Técnica ......................................................................................... 101
12.3.2 Avaliação Financeira ..................................................................................... 101
12.3.3 Avaliação Comercial ..................................................................................... 102
12.3.4 Avaliação Mercadológica .............................................................................. 102
12.4 O Relatório de Recomendação .................................................................................. 103
12.5 Contratação dos Parceiros Escolhidos ...................................................................... 104
13. ELEMENTOS PARA ANÁLISE DE PROJETOS ............................................................... 107
13.1 Indicadores de avaliação ........................................................................................... 109
13.1.1 Relação benefício-custo (RBC) .................................................................... 110
13.1.2 Valor atual dos fluxos líquidos (VA) .............................................................. 111
13.1.3 Payback simples (PBS) e econômico (PBE) ................................................ 112
13.1.4 Taxa interna de retorno (TIR)........................................................................ 113
13.1.5 Custo total atualizado .................................................................................... 115
13.2 Uso dos indicadores na avaliação de projetos .......................................................... 116
13.3 Análise em condições de risco ................................................................................... 117
13.4 Conceito de Probabilidade Subjetivas ....................................................................... 117
13.5 Critérios para Decisões sob Incerteza ....................................................................... 118
13.6 Sistemas de Financiamento ....................................................................................... 118
13.6.1 Método francês ou Tabela Price ................................................................... 119
13.6.2 Sistema de Amortização Constante – SAC ................................................. 121
13.6.3 Sistema Americano ....................................................................................... 122
13.7 Empréstimo com carência .......................................................................................... 125
13.8 Amortização com "parcelas intermediárias"............................................................... 128
13.9 Empréstimos com cláusula de reajustamento ........................................................... 128
14. Considerações Finais ........................................................................................................ 131
14.1 Envolvimento do Pessoal Interno da Organização .................................................... 131
14.2 Quando dizer NÃO ..................................................................................................... 131
14.3 Você é um Líder de Projetos? .................................................................................... 132
15. Referências Bibliográficas ................................................................................................. 135
Anexo I - Ferramenta PERT/CPM ........................................................................................... 137
.
Introdução 1
1 Introdução
Considere a execução dos eventos de Reveillon na praia de Copacabana – Rio de Janeiro,
que reúne, a cada ano, cerca de 2 milhões de pessoas à zero hora de 31 de dezembro:
 Gerência do tráfego urbano: como tratar os desvios de tráfego, a inversão de mãos,

a interrupção das vias de acesso e da avenida litorânea, como divulgar e
sinalizar as alterações de tráfego com a antecedência necessária, em todos as
vias de acesso à região...;
 Gerência da segurança/policiamento: como distribuir o efetivo policial ao longo das
redondezas, ao longo da praia, como garantir a coordenação de esforços entre os
diversos destacamentos militares disponibilizados, como realizar a efetiva contenção
de eventuais arrastões e tumultos diversos...;
 Gerência do atendimento médico imediato/hospitalar: como instalar tendas para
atendimento em termos de primeiros socorros, realizar a contratação de médicos e
enfermeiros adequados, realizar a remoção dos casos mais graves para os hospitais
mais próximos (principalmente em relação aos “corredores de fuga”, a serem
negociados junto à gerencia do tráfego urbano)...;
 Gerência do lixo: como distribuir recipientes para o depósito de lixo a longo do evento,
como realizar a retirada dos mesmos, como realizar, de forma rápida e eficiente,
a limpeza da região horas depois à ocorrência do evento...;
 Gerência de informações / divulgação / sinalização: considerar a adequada
disseminação de informações aos turistas, aos moradores e donos de restaurantes e
hotéis da região, como repassar informações acerca de restrições relacionadas ao
tráfego aéreo, marítimo e urbano...;
 Gerência dos shows musicais / fogos de artifício: quem contratar, como contratar,
como distribuir os diversos palcos ao longo da praia, qual será a melhor composição
de artistas, bem como a ordem em que os mesmos farão suas apresentações, como
realizar a instalar todo o equipamento de luz e som...
Em cada uma das questões 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 possíveis, e prever o contingenciamento efetivo
para cada um deles?
 Gerenciar as comunicações entre todos os participantes e envolvidos direta e
indiretamente?
 Cuidar da aquisição de produtos e contratação de serviços de terceiros?
 Obter alta qualidade nos produtos adquiridos e nos serviços contratados?
 Garantir que o projeto seja realizado estritamente dentro do prazo e do orçamento
previstos?
 Integrar o projeto como um todo, em todos os seus aspectos e parâmetros?
Numa visão integrada do projeto acima e de todas as questões levantadas, como fazer para:
.
2 Gerência de Projetos
 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 execução 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 realização do evento significa cuidar de todos os detalhes citados

acima, bem como todos os detalhes que ainda não são conhecidos anteriormente ao projeto,
agir de forma pró-ativa para que todas as ações sejam executadas de forma integrada e
coesa e, enfim...
REALIZAR O PROJETO!!!
Conceitos-Chave 3
2 Conceitos-Chave
2.1 Conceito de Projeto

Para abordarmos o tema de gerência de projetos devemos, em primeiro lugar, definir o
conceito de projeto:
“Um projeto é um esforço temporário empreendido para criar um produto ou

serviço único. Temporário significa que todo projeto tem um início e um término
bem definidos. Único significa que o produto ou serviço distingue-se
substancialmente de todos os produtos e serviços existentes” (PMI, 2000, p. 4).
Outras definições de projeto vêm a seguir:
“Projeto é um empreendimento não repetitivo, caracterizado por uma sequência

clara e lógica de eventos, com início, meio e fim, que se destina a atingir um
objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros pré-
definidos de tempo, custo, recursos envolvidos e qualidade.”
“Projeto é uma combinação de recursos organizacionais colocados juntos para

criarem ou desenvolverem algo que não existia previamente, de modo a prover
um aperfeiçoamento da capacidade de performance no planejamento e na
realização de estratégias organizacionais”
De forma mais simplificada, “projetos são esforços temporários levados a efeito para gerar um
produto ou serviço único”.
Características principais dos projetos:
 Temporariedade e individualidade do produto ou serviço a ser desenvolvido pelo

projeto.
Outras características relevantes:
 Empreendimento não repetitivo;
.
 Envolve uma sequência clara e lógica de eventos em seu planejamento, mas seu
desenvolvimento pode se tornar caótico, uma vez que as variáveis envolvidas
não são totalmente conhecidas a priori;
 Objetivos claros e bem definidos; Conduzido por pessoas;
 Utiliza recursos;
 Possui parâmetros 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;
 Restrições: limitadores vinculados aos fatores tempo, capital e/ou recursos;
 Multidisciplinaridade: requer integração e coordenação entre pessoas e áreas
diversas; Complexidade: principalmente no que tange aos aspectos de divergência de
objetivos e da mudança tecnológica constante.
2.2 Gerenciamento de Projetos

Aplicação do conhecimento e habilidades utilizando ferramentas e técnicas de planejamento e
controle de atividades conforme os requisitos de um projeto.
2.3 Operações X Projetos

As operações são trabalhos contínuos e repetitivos.
Suas semelhanças com os projetos são as seguintes:
 As operações podem ser executadas por pessoas (os projetos tem que ser
executados por pessoas);
 As operações também necessitam ser planejadas, executadas e controladas;
 As operações também objetivam-se à obtenção de resultados bem definidos;
 As operações também possuem limitações e restrições em seus recursos alocados.
Suas diferenças em relação aos projetos são as seguintes:
 As operações são repetitivas, enquanto os projetos são únicos;

 As operações são de execução previsível ou bem definida, enquanto os projetos
possuem condução com propensão ao caos, pois as variáveis e complexidades
envolvidas nos mesmos não são necessariamente conhecidas por completo a priori;
 As operações podem não ser executadas por pessoas, podendo ser conduzidas por
computadores ou por máquinas;
 As operações normalmente possuem um procedimento associado que documenta
seu funcionamento, condições de erro, situações de contorno; cada projeto, por sua
vez, possui documentação que se propõe a planejar sua execução, contudo, a
Conceitos-Chave 5
mesma estará sempre sujeita a modificações, acertos e adequações, dada a

natureza de complexidade e de alguma imprevisibilidade que envolve um projeto;
 As operações envolvem pouco ou quase nenhum trabalho de criação, sujeição a
riscos ou gerência de conflitos, pois se referem a tarefas bem definidas e
conhecidas. Em certos casos, as eventuais exceções ou conflitos que possam atingir
as operações costumam ser bem conhecidas e bem documentadas, passando a
constituírem-se parte de si próprias; já os projetos são típicos ambientes que
envolvem conflitos e riscos, e continuamente exige-se a adoção de mecanismos e
soluções desenvolvidas a partir de grande dose de criatividade por parte de seus
participantes.
2.4 Exemplos de Projetos

 Implantação de uma nova solução de software em uma organização;
 Construção de uma casa;
 Estudo de um acidente aéreo com vítimas;
 Elaboração de uma tese de doutorado;
 Realização de uma viagem a um local;
 Desenvolvimento de um novo sistema de informações;
 Realização de um concurso de videokê;
 Desenvolvimento e implantação de um novo curso de graduação.
2.5 Exemplos de Não-Projetos

 Manutenção rotineira de equipamentos;
 Preenchimento de um formulário;
 Atendimento a clientes via telemarketing;
 Realização de vendas de passagens de ônibus em um terminal rodoviário;
 Configuração de um vídeo-cassete para gravar um determinado programa.
2.6 Sucesso e Fracasso em Projetos

Poderíamos começar 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 idéia do que se constitui o sucesso de um projeto.
Alguns autores consideram, por exemplo, que existem 4 dimensões para que um projeto
atinja o seu pleno êxito:
1. A eficiência do projeto: consiste em realizar o projeto de forma a atender ao seu

orçamento 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 orçado originalmente, será que
isso não 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 não utilizados no projeto);
2. Impacto/satisfação do cliente do projeto: esta dimensão é muito complexa, pois

não somente envolve a natural conformidade às especificações técnicas e
operacionais dos produtos gerados pelo projeto, mas também inclui fatores
relacionados à fidelidade e à disposição do uso (ou da reaquisição) dos produtos
gerados pelo projeto: atendimento às necessidades apontadas pelo cliente, efetivo
uso da solução por parte do cliente, resolução de um problema considerado
principal pelo cliente e o constante desafio da própria satisfação do cliente
em relação às soluções oferecidas pelo projeto. Naturalmente, pode existir
grande parcela de subjetividade na própria avaliação de satisfação por parte do
cliente, pois podem existir representantes da organização cliente que considerem
positivos e satisfatórios os resultados de um projeto, assim como há a
possibilidade de que outros indivíduos considerem que o projeto tenha sido um
empreendimento de resultados absolutamente insatisfatórios (some-se a isso
que estas avaliações podem variar ao longo do tempo...);
3. Sucesso direto/sucesso no negócio do cliente: esta característica pode ser

medida, primariamente, em termos do nível 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
produção alavancadas a partir do projeto, ou na redução de tempo dos ciclos
produtivos, ou na redução ou otimização dos passos de processamento, ou na
melhoria da qualidade, entre outros fatores relacionados aos processos
organizacionais do cliente do projeto;
4. Futuro potencial: esta dimensão, mas difícil 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 serviços em função da implementação do projeto ou, em um
projeto interno, na possibilidade de desenvolvimento de novas tecnologias,
habilidades e/ou competências a partir da execução do projeto.
Em uma outra abordagem, mais analítica, poderíamos caracterizar o sucesso de um projeto

em termos da natureza das variáveis a serem consideradas em sua mensuração, tais como:
Sucesso Técnico: quando ocorre aderência do projeto a quesitos mensuráveis. Como
exemplos, vejamos as seguintes situações:
 Um projeto que se concluiu dentro ou antes do prazo previsto. Neste caso, estamos
considerando que a antecipação do prazo de entrega do projeto foi benéfico para a
organização contratante do mesmo;
Conceitos-Chave 7
O fator de antecipação dos resultados de um projeto pode se revelar, em alguns

casos, um estorvo. Por exemplo, suponha que um determinado fabricante de peças se
proponha a entregar, em seis meses, um volume total de 10.000 itens para uma organização
contratante, esta última em processo de implantação de uma fábrica, cujo prazo de término
da construção de seus galpões de estocagem é compatível com as datas combinadas de
entrega dos itens. A antecipação na entrega dos itens na fábrica, ainda em construção,
poderia causar transtornos severos em termos da estocagem dos mesmos, uma vez que a
fábrica ainda não teria condições de abrigá-los adequadamente.
 Envolver um orçamento menor ou igual ao previsto. Neste caso, se considera que a

economia gerada pela redução do desembolso no projeto não venha a incorrer em
perdas de capital para o contratante do projeto;
Este é um outro exemplo em que a redução do que foi planejado originalmente pode trazer
resultados perversos para o contratante de um projeto. Por exemplo, suponha que um
projeto foi orçado em R$ 10 milhões a serem executados em um período de um ano. Desta
forma, a contratante provisionou, em termos de seus orçamentos anuais, esta quantia para o
investimento no empreendimento. Contudo, suponha que o desembolso total do projeto
tenha somado R$ 8 milhões ao longo dos mesmos 12 meses de execução. Neste caso, a
diferença de R$ 2 milhões não 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 não poderia ter
trazido al um prejuízo ao contratante ao invés de benefícios?
 Demandar menos recursos do que o previsto originalmente;

 Os produtos gerados possuírem qualidade ou performance igual ou superior ao
previsto originalmente.
Sucesso Organizacional: quando ocorre aderência do projeto a quesitos não mensuráveis,

mas igualmente importantes do ponto de vista do contexto envolvido. Vejamos os
seguintes exemplos:
 Um projeto que ocorre com um mínimo de alterações de escopo;

 Um projeto que é aceito sem restrições pelo contratante ou cliente;
 Um projeto que é desenvolvido e implantado sem que tenha ocorrido
paralização, interrupção ou prejuízo das atividades normais da organização
contratante;
 Um projeto que não tenha agredido a cultura da organização contratante.
Finalmente, se agregarmos todas as questões levantadas acima no intuito de chegarmos a

uma definição única de sucesso em um projeto, poderíamos chegar aos seguintes termos:
2.7 Fatores de Sucesso e Fracasso em Projetos

Em uma pesquisa realizada pelo Standish Group, em projetos de tecnologia da informação,
chegou-se aos seguintes números em relação ao sucesso e fracasso dos mesmos:
.
16,2% dos projetos de software iniciados são completados no prazo definido, dentro do
orçamento planejado e com todas as funcionalidades como originalmente definido;
52,7% dos projetos iniciados são completados e tornados operacionais, mas excedem o
orçamento, e/ou o prazo estimado e/ou oferecem menos funcionalidades e produtos
em relação ao que foi originalmente especificado;
31,3% dos projetos são 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 usuário 15,9%
Apoio dos executivos sêniores 13,9%
Definição clara de requisitos 13,0%
Planejamento adequado 9,6%
Expectativas realistas 8,2%
Proximidade dos marcos do projeto 7,7%
Competência da equipe 7,2%
Propriedade 5,3%
Clareza da visão e dos objetivos 2,9%
Trabalho duro, com a equipe focada 2,4%
Outros fatores 13,9%
Os participantes da pesquisa foram também questionados a respeito das causas que levam
um projeto a ser concluído, porém com distorções no orçamento e/ou no prazo e/ou nas
funcionalidades esperadas:
Fatores dos projetos Concluídos com Restrições % de Respostas

Falta de informações dos usuários 12,8%
Especificações e requisições incompletas 12,3%
Alterações nas especificações e requerimentos 11,8%
Falta de apoio dos executivos 7,5%
Restrições da tecnologia 7,0%
Falta de recursos 6,4%
Expectativas não realistas 5,9%
Estimativas de prazos não realistas 4,3%
Tecnologia muito nova 3,7%
Outros fatores 23,0%
As opiniões 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 usuário 12,4%
Falta de recursos 10,6%
Expectativas não realistas 9,9%
Falta de apoios dos executivos 9,3%
Conceitos-Chave 9
Alterações nas especificações e requerimentos 8,7%

Falta de planejamento 8,1%
“Não 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 diferenciação entre objetivo e funcionalidade: a funcionalidade deve

existir para apoiar o atingimento de um objetivo particular ou para resolver um
problema técnico específico. Frequentemente, a funcionalidade é criada sem a
compreensão do objetivo a que serve. Como um exemplo, um projeto tem por objetivo
a criação de um novo modelo de automóvel que seja barato, bonito e econômico.
Neste caso, supondo que os engenheiros insistam em tentar produzir um motor
altamente eficiente mas que se utilize de uma tecnologia de difícil implementação em
larga escala, se poderia chegar a um caso típico de funcionalidade atendida e ainda
assim o objetivo não ter sido alcançado;
 Falta de sintonia entre negócio e tecnologia: quando os objetivos de negócio e

os objetivos de tecnologia da organização não estão alinhados, os objetivos da
tecnologia podem não suportar as necessidades de negócio demandadas. Como um
exemplo, suponhamos que os objetivos de negócio de uma organização seja o de
explorar as necessidades de cidades do interior do país com cerca de 100.000
habitantes. Neste caso, considere que uma decisão estratégica seria dotar os
vendedores de ferramentas que lhes dêem agilidade para prospectar e contatar
rapidamente os clientes potenciais nas micro-regiões de foco, bem como dar
eficiência aos processos de coleta e atendimento de pedidos. Desta forma, um
fator de sucesso seria o alinhamento dos objetivos de negócio com os de tecnologia,
esta última devendo esmerar-se em desenvolver canais eletrônicos para a troca de
informações entre a central e os vendedores móveis (Internet, PDAs, notebooks,
celular, construção de aplicativos específicos, sistemas de logística mais eficientes,
etc.) para que os resultados sejam alcançados de acordo com os interesses da
organização;
 Falta de uma linguagem e um processo comuns: neste caso, resulta-se em muita

confusão e expectativas não realistas. Como um exemplo de fator para o insucesso
de um projeto, teríamos o seguinte caso: considere uma fábrica em que os setores de
relacionamento com fornecedores (compras) estivessem desenvolvendo novos
sistemas para a automação da logística de recebimento de insumos. Neste caso, se o
pessoal das usinas, do controle de estoques de materiais, de tecnologia da
informação, e outros setores, não estiverem bem coordenados e envolvidos em
relação a uma visão integrada quanto ao processo como um todo, o fracasso será
praticamente certo (às vezes, as demais áreas somente tomam conhecimento do
projeto às vésperas da sua implantação!!!). Além disso, a utilização de termos
distintos para significar as mesmas coisas pode dificultar ainda mais a eficácia do
novo projeto. Por exemplo, a “data de entrada” da mercadoria é a data de entrega do
produto na fábrica, ou a data em que o mesmo entra nos estoques da empresa, ou a
.
data em que a mesma é tornada disponível para a linha de produção? Ou os códigos

de fornecedores estão realmente integrados em todos os sistemas da empresa, cada
um deles significando um, e exatamente um único fornecedor? Ou a causa da não
aceitação de um material está relacionada à sua incompatibilidade no processo
produtivo, ou às eventuais divergências quanto à entrega da mercadoria na chegada
da mesma à empresa? Todas estas discrepâncias podem trazer sérios problemas à
organização, pois desconectam o novo projeto em relação a todos os seus
envolvidos e participantes necessários;
 Falhas na comunicação entre as equipes de projeto, e falhas na atuação

como um único time: estimular as pessoas a irem além de seu esforço pessoal e
torná-las capazes de trabalhar efetivamente como uma equipe coesa e única é
crítico para o sucesso de um projeto;
 Processos organizacionais internos inflexíveis: ambientes resistentes às
mudanças a serem proporcionadas pelo projeto podem inviabilizá-lo por completo.
Neste caso, se deve verificar com cuidado os redutos de poder nas organizações, e
implementar políticas que facilitem e ampliem a flexibilidade dos diversos setores
envolvidos na implantação dos novos projetos.
2.8 Trade-Offs do Gerenciamento de Projetos

Há uma tendência ao considerar um projeto apenas em termos das especificações de seus
resultados, ou seja, da qualidade de seus resultados. Contudo, devem ser considerados
também os custos necessários para se atingir tais resultados, bem como o adequado
dimensionamento de prazos para seu desenvolvimento. Alguns autores também consideram
as expectativas do cliente como uma quarta dimensão do gerenciamento dos projetos. No
entanto, podemos considerar que este último fator é uma parte inerente das combinações das
outras 3 dimensões de um projeto.
O gráfico abaixo apresenta os objetivos principais do gerenciamento de projetos, com os

objetivos especificados do projeto nos eixos. A função resultante varia de projeto para projeto,
e a principal tarefa do gerente de projetos é lidar com estes trade-offs.
Conceitos-Chave 11
Relacionamento entre os objetivos de um projeto: custo, prazo e qualidade

(ou performance, no original em inglês).
Fonte: MEREDITH e MANTEL (1995, p. 4)
A obrigação principal de um gerente de projetos é de manter o melhor equilíbrio entre este trio
de restrições, além de atender (ou, se possível, exceder) as expectativas dos stakeholders do
projeto.
Stakeholders são todos aqueles que serão afetados pelos resultados de um projeto, seja
direta, seja indiretamente, sejam eles internos como externos à organização. A figura a seguir
apresenta todos os tipos stakeholders que podem participar isoladamente ou em conjunto em
um projeto comum.
.
1
Fases de um Projeto e seu Ciclo de Vida 13
3 Fases de um Projeto e seu Ciclo de Vida
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
finalização de produtos, trabalhos ou resultados, que devem ser tangíveis e de fácil
identificação. A conclusão de uma fase é geralmente marcada pela revisão dos principais
subprodutos e pela avaliação do desempenho do projeto tendo em vista:
A. Determinar se o projeto deve continuar na sua próxima fase;

B. Detectar e corrigir eventuais erros a um custo aceitável.
O ciclo de vida do projeto serve para definir o início e o fim de um projeto. A definição do ciclo
de vida do projeto também determina os procedimentos de transição para o ambiente de
operação que serão incluídos ao final do projeto, distinguindo-os dos que não serão. Desta
forma, o ciclo de vida do projeto pode ser usado para ligar o projeto aos processos
operacionais contínuos da organização executora.
Os subprodutos oriundos de uma fase normalmente são aprovados antes do início da próxima
fase. Entretanto, quando os riscos são considerados aceitáveis, a fase subsequente pode
iniciar antes da aprovação dos subprodutos da fase precedente.
As descrições do ciclo de vida de projeto podem ser genéricas ou detalhadas. Descrições

muito detalhadas podem conter uma série de formulários, diagramas e checklists para prover
estrutura e consistência. Esta abordagem detalhadas são freqüentemente chamadas de
metodologias de gerência de projeto.
Os programas são grupos de projetos administrados com as mesmas técnicas, 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 gestão própria,
coordenados por comitês 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 responsável pelo programa inteiro.
Por exemplo, uma empresa de arquitetura contratada para projetar um novo prédio de
escritórios poderá estar inicialmente envolvida com um subprojeto relacionado às definições
do contratante (ao qual chamaremos, neste exemplo, “Subprojeto de Análise de
Viabilidade”). Quando esta empresa estiver fornecendo suporte à construção, estará
também envolvida no “Subprojeto de Construção”. O Subprojeto de Análise de Viabilidade
poderia ser dividido em diversas fases, entre elas, a fase de “Elaboração do Design
Arquitetônico”. Esta fase, por sua vez, poderá possuir sua própria configuração de sub-fases
.
como, por exemplo, as sub-fases “Especificação Conceitual”, “Definição dos Planos de

Trabalho”, “Desenho das Pranchas”, “Construção de Maquetes”, “Apresentação ao
cliente”, “Revisão Final” e, enfim, “Entrega e Encerramento”.
O diagrama a seguir ilustra o exemplo de subdivisão de um projeto em sub-projetos, fases e

sub-fases:
Projeto Nova Casa
Subprojeto: Subprojeto: Subprojeto:

Análise de Viabilidade Construção Outros (....)
Fase: Elaboração do Fase: Estudo de Outras Fases (...)

Design Arquitetônico Viabilidade Financeira
Sub-fase: Especificação
Conceitual
Sub-fase: Definição de
Planos de Trabalho
Sub-fase: Desenho das

Pranchas
Sub-fase: .....
3.2 Fases Genéricas do Ciclo de Vida de um Projeto

Genericamente, podemos considerar as seguintes fases de um ciclo de vida de um projeto:
 Concepção: os objetivos técnicos do projeto devem ser especificados a um nível que

permita o planejamento detalhado do estágio seguinte, de Planejamento. Deve haver
o comprometimento dos recursos necessários para o projeto tanto por parte do apoio
dos executivos sêniores quanto por parte dos gerentes funcionais; a prioridade do
projeto, em relação às prioridades de outros projetos da organização, 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 condução 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 alocação dos recursos sob sua responsabilidade
para a execução de tarefas previstas para o projeto;
 Implementação: 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: conclusão dos trabalhos do pessoal envolvido, com a entrega dos

produtos e serviços finais do projeto, a finalização dos documentos abertos durante o
projeto, o encerramento dos contratos firmados junto aos parceiros e fornecedores e o
aceite final do cliente do projeto.
No PMBOK encontram-se diversos exemplos de ciclos de vida de projetos, como projetos de

construção civil, desenvolvimento de software, da indústria farmacêutica e do estabelecimento
de uma infra-estrutura de defesa militar.
3.3 Comportamento Genérico de um Projeto ao Longo do Ciclo

de Vida
A maioria das descrições do ciclo de vida de projeto apresentam algumas características em
comum:
 O custo e a quantidade de pessoas integrantes da equipe são baixos no início

do projeto, sofre incrementos no decorrer do mesmo e se reduzem drasticamente
quando seu término é vislumbrado;
Como pode ser verificado no gráfico acima, quando os recursos e custos são
alocados a um projeto bem como quando os mesmos são desalocados, um aspecto
crítico é a qualidade da gerência sobre os mesmos. Rapidamente um projeto
ganha recursos ao longo do tempo e também rapidamente o projeto os perde. Além
disso, quando os custos e recursos encontram uma estabilidade em termos de
alocação, o gerente de projetos deve preparar-se para “perdê-los”, não esperando
utilizar-se dos mesmos por tempo indeterminado.
.
 A probabilidade de terminar um projeto com sucesso é baixa no início e o risco e a

incerteza são altos. Normalmente a probabilidade de sucesso vai aumentando à
medida que o projeto caminha em direção ao seu término;
Como o gráfico acima demonstra, em determinado momento do projeto, a curva de

probabilidade de sucesso cresce muito rápido. Neste momento, os níveis de
aprendizado da equipe de projeto ampliam-se fortemente, capacitando-os para o
cumprimento final do mesmo. Além disso, se observarmos o grau de aumento de
probabilidade de sucesso no mesmo período, fortalece-se a argumentação para
que o comprometimento das áreas e executivos envolvidos sejam mantidos em
alta.
 A capacidade das partes envolvidas de influenciar as características finais do

produto do projeto e o seu custo final, é alta no início e vai se reduzindo
com o andamento do projeto. Isto acontece, principalmente, porque o custo de
mudanças e correção de erros geralmente aumenta à medida que o projeto se
desenvolve.
Uma vez que as alterações no início do projeto são menos complexas e, em

consequência, menos dispendiosas, deve-se intensificar o entendimento das
expectativas dos usuários ou clientes do projeto. Ferramentas como protótipos ou
simulações podem ser empregados para que o mesmo nível de entendimento seja
obtido entre todas as partes envolvidas.
 A oportunidade e o risco envolvidos geralmente mantêm-se relativamente altos no

início do projeto, ao passo que as quantidades arriscadas são menores no início e
aumentam à medida que um projeto evolui. Isso significa que o período de maior
impacto do risco ocorre quando ambas estas variáveis chegam ao seu ponto de
encontro.
O gráfico a seguir apresenta uma relação entre o estado de finalização do projeto ao longo do
tempo. Note como no início 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:
O gráfico a seguir apresenta a distribuição do esforço em projetos ao longo de seu ciclo de

vida:
.
Observe como o esforço dispendido nas fases iniciais é mínimo (quando o conceito do projeto
está sendo desenvolvido), bem como no término, quando há os processos de avaliação
e conclusão do projeto. Ressaltamos que se for utilizado mais esforço nas fases iniciais
do projeto suas chances de sucesso crescem significativamente.
É essencial para o gerente de projetos compreender as características da curva do ciclo de

vida do projeto sob sua responsabilidade. As distinções entre os diversos ciclos de vida
assumem um papel crítico no desenvolvimento de orçamentos e cronogramas para o projeto.
3.4 Importância Relativa dos Objetivos do Projeto quanto ao

Ciclo de Vida
A sabedoria convencional, de forma errônea, aponta os objetivos dos projetos em função de
seus estágios da seguinte forma:
 No início 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 execução, o custo
tomaria precedência em relação às demais variáveis, devido ao fato que o
projeto toma corpo, cresce e opera em picos de atividade, demandando, para isso,
dispêndio 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 crença apontada acima não é considerada verdadeira.

A tabela a seguir aponta a importância relativa entre os objetivos de um projeto em cada uma
das fases do ciclo de vida genérico considerado:
Estágio do Ciclo de Vida Custo Prazo Qualidade

Concepção 1 1 1
Planejamento 3 1 2
Implementação 3 1 1
Encerramento 3 2 1
OBS. 1 = mais importante
Importância relativa dos objetivos de um projeto durante os diferentes estágios
de seu ciclo de vida genérico
Fonte: MEREDITH e MANTEL (1995, p. 101)
Como pode ser verificado, no estágio de Concepção não há uma diferença

significativa entre cada um dos três 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 três objetivos. Se condições específicas devem ser assumidas, cada um dos três
objetivos deve ser considerado vulnerável. Contudo, caso algum objetivo assuma uma
importância maior nesta fase, o candidato natural é o objetivo Qualidade, uma vez que o
cliente pode desejar alcançar níveis 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 execução, produzidos neste estágio. Em função
dos prazos assumidos, estabelecem-se compromissos em relação à apresentação de
versões, ou módulos, dos produtos a serem gerados ao longo do projeto (Qualidade),
de forma que novas versões vão sempre acrescentando novas funcionalidades às já
existentes. Isso se justifica de forma a “quebrar” as expectativas dos clientes do projeto,
oferecendo-lhes resultados intermediários ao longo do tempo de execução do mesmo.
Na fase de Implementação, tanto o Prazo quanto a Qualidade são 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
façam restrições às especificações técnicas dos produtos finais (o que pode prejudicar a
Qualidade). Cada uma destas decisões pode não se justificar em grande parte dos casos,
devido à restrições de ordem contratual, ética ou de política da companhia.
Quanto à Qualidade, à medida que o projeto evolui passa a existir uma grande
quantidade de interfaces entre os componentes da solução, aumentando enormemente a
complexidade dos resultados esperados. Neste caso, como há uma grande preocupação
com a devida integração dos diversos componentes da solução projetada, o objetivo
Qualidade é considerado tão significativo quanto o Prazo. O controle do projeto nesta fase
é exercido, principalmente, sobre estes dois objetivos, o que não significa que o fator
Custo não mereça a atenção 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
.
esforço para executar o que for necessário para concluir as especificações dos
produtos a serem gerados pelo projeto (Qualidade), objetivando-se completar o projeto
mesmo que com algum atraso tolerável. Neste caso, exceções podem ser verificadas em
projetos com datas-limite muito rígidas. Até mesmo alguns desvios nos Custos, desde
que não muito altos, são tolerados, desde que favoreçam a conclusão do projeto
dentro da Qualidade aceitável, e dentro de Prazos finais não muito postergados.
Problemas técnicos são relativamente raros nesta fase, uma vez que a maioria dos mesmos
muito provavelmente já teriam sido resolvidos nas fases anteriores.
1
.
4. Estratégias para Desenvolvimento de Novos

Produtos
A economia mundial vem sofrendo uma série de mudanças ao longo das últimas
décadas. A globalização, a crescente complexidade das atividades, a utilização do
conhecimento e da informação como novos produtos, e as novas demandas do mercado vêm
forçando as empresas cada vez mais a assumirem um posicionamento dinâmico e flexível
perante seus clientes, parceiros, concorrentes e até mesmo dentro de suas próprias
organizações.
Hoje, qualquer empresa pode gerenciar atividades repetitivas e recorrentes, com base em
padrões históricos ou métodos consagrados. Porém o desafio desta nova era, para quem não
quer ser apenas mais uma empresa no mercado, está em gerenciar atividades nunca
tentadas no passado e que podem jamais vir a se repetir no futuro.
Nota-se também que sua procura e aplicações mais fortes e freqüentes se dão em atividades
de Engenharia, em especial para o desenvolvimento de novos produtos. A Engenharia, por
essência, é baseada em projetos e o engenheiro freqüente apresenta como características
pessoais uma visão macro e um raciocínio sistêmico sobre os projetos. A “espiral de projeto”,
os conceitos de QFD (Quality Function Deployment), a Engenharia Simultânea e a
interatividade dos sistemas existentes em um projeto de Engenharia fazem com que o
engenheiro esteja sempre atento e ciente de que qualquer alteração em um dos parâmetros
pode impactar fortemente o resultado final.
Estas características se encaixam perfeitamente ao perfil que o Gerente de Projetos deve

possuir. Em outras palavras, a Gestão de Projetos e a Engenharia possuem naturalmente
uma forte relação entre si, principalmente devido às atividades de integração inerentes às
mesmas.
4.1 Desenvolvimento de novos produtos e estratégias de ciclo

de vida
Um dos resultados mais concretos de um planejamento estratégico é a composição de um
portfólio de projetos para se por em prática as intenções da alta gerência. Os projetos serão
os motores da mudança que viabilizarão a concretização da estratégia. Eles gerarão novos
produtos e serviços, construirão novas fábricas, melhorarão a infraestrutura, desenvolverão
novos processos, etc. Sendo assim, fica claro que todas as mudanças significativas a serem
implementadas em uma organização, e oriundas de uma estratégia, geralmente assumem a
forma de algum tipo de projeto.
Estudos recentes estimam que cerca de 80% dos novos produtos falham. Apenas cerca de
40 % se mantêm no mercado passados 5 anos. Porquê?
Estratégias para Desenvolvimento de Novos Produtos 23
 Sobre-estimação da dimensão do mercado,

 Problemas com o design do produto,
 O produto foi incorretamente posicionado, apreçado ou comunicado,
 O produto pode ter sido introduzido apesar dos resultados das pesquisas e de um
marketing pobre.
 Custos de desenvolvimento do produto, ou
 Ações da concorrência
O sucesso dos novos produtos depende fortemente de:
 Produto com valor superior único (elevada qualidade, características, etc);

 Conceito de produto bem definido (um segmento de mercado bem definido,
exigências do produto, e benefícios).
Para desenvolver novos produtos de sucesso a empresa deve:
 Compreender os consumidores, mercados e concorrentes;

 Desenvolver produtos que forneçam valor superior aos clientes.
A figura a seguir apresenta um fluxo com as principais etapas a serem seguidas no

desenvolvimento de novos produtos:
Etapa 1: Geração de idéias

A geração de idéias é a pesquisa sistemática de idéias para novos produtos quer
internamente (empregados), quer externamente:
.
Etapa 2: Seleção de idéias

Muitas empresas têm sistemas para ponderar e selecionar as idéias. Estes sistemas estimam:
 A dimensão do mercado
 O preço do produto
 Tempo e custos de desenvolvimento
 Custos de produção
 Taxa de retorno
Depois a idéia é avaliada perante um conjunto de critérios gerais da empresa (objetivos,

metas, recursos, etc).
Etapa 3: Desenvolvimento e teste do conceito

Idéia de produto: idéia de um possível produto que a empresa pensa poder vir a desenvolver
e comercializar.
Imagem de produto: é o modo como os consumidores percebem um produto atual ou

potencial.
Conceito de produto: Versão detalhada da idéia em termos perceptíveis para o consumidor

Desenvolvimento do conceito
A Daimler Chrysler está prestes a
comercializar a versão experimental
do seu novo carro elétrico (NECAR
4). Este carro polui muito pouco, é
altamente eficiente em termos de
combustível (75% mais que os
carros normais a gasolina) e tem
vantagens ambientais sobre os
carros normais. Baseado no
Mercedes classe A, o carro acelera
rapidamente, alcança a velocidade
de 90 km/h e têm uma autonomia
para 450 km, o que lhe dá uma
vantagem sobre os carros elétricos a
bateria.
Conceito 1: Um sub-compacto com preço médio, desenhado como um segundo carro de

família para circular na cidade e visitar os amigos.
Conceito 2: Um compacto desportivo com preço médio dirigido a gente jovem.
Conceito 3: Um sub-compacto “verde”, pouco caro para apelar a pessoas ambientalmente

conscientes que querem um transporte prático e pouco poluente.
Teste do conceito
Um sub-compacto eléctrico, eficiente, divertido de conduzir, para 4 pessoas. Este motor
moderno é movido a hidrogênio líquido, fornecendo uma solução de transporte prática, fiável
e praticamente sem poluição. Atinge uma velocidade de 90 km/h e contrariamente aos carros
elétricos, nunca precisa de ser recarregado. O seu preço com equipamento completo é de
20.000 €.
Questões para o teste do NECAR 4:
 Compreende o conceito de um carro elétrico movido a combustível?

 Acredita nas capacidades do carro?
 Quais as principais vantagens deste carro comparativamente aos tradicionais?
 Quais as principais vantagens deste carro comparativamente aos elétricos?
 Que melhorias nas características do carro sugeriria?
 Para que fins preferiria um carro como este comparativamente ao carro convencional?
 Qual seria o preço razoável para este carro?
 Quem estaria envolvido na decisão de comprar um carro destes? Quem o conduziria?
 Irá comprar este carro? (Claro que sim, talvez, não sei, provavelmente não, nunca)
.
Etapa 4: Estratégia de marketing

A estratégia de marketing em geral apresenta-se sub-dividida em:
Parte I Descreve tudo:

 Mercado alvo
 Posicionamento previsto
 Objetivos de vendas e lucros
 Quota de mercado
Parte II Descreve o primeiro ano:

 Preço previsto
 Distribuição
 Orçamento de marketing
Parte III Descreve o longo prazo:

 Objetivos de vendas e lucros
 Estratégia de marketing
 Mix
Etapa 5. Análise de negócio

Como fase preliminar ao processo de avaliação e análise de projetos é necessário o computo
de estimativas dos desembolsos e receitas (chamados de “custos” e “benefícios” nesse
contexto) que deverão ocorrer ao longo da vida útil do projeto, uma tarefa que pode ser
relativamente complexa em muitos casos. É através dessas estimativas que é gerado o
cronograma financeiro do projeto com o respectivo fluxo de caixa, que é o insumo principal
necessário ao processo de análise.
Etapa 6. Desenvolvimento do produto

Após todas as etapas anteriores terem sido aprovadas, tem-se efetivamente o
desenvolvimento do produto, com especificação de todos os processos, materiais, meios de
fabricação, etc.
Etapa 7. Teste de Marketing

Teste de marketing é a etapa em que o produto e o programa de marketing são introduzidos
em condições mais reais. O seguintes elementos deverão ser testados:
 Preço de venda
 Marca
 Embalagem
 Posicionamento no mercado
 Distribuição
 Meios de comunicação
Etapa 8. Comercialização
A comercialização é a introdução do novo produto no mercado. As seguintes perguntas
deverão ser respondidas.
.
O Gerente de Projetos 29
5 O Gerente de Projetos
Responsável por planejar, conduzir, controlar e finalizar um projeto, um gerente de projetos
deve possuir habilidades específicas para um bom gerenciamento de projetos. As seguintes
habilidades gerenciais-chave aplicam-se não somente para um gerente de projetos, mas para
os diversos indivíduos participantes nos mesmos, quais sejam:
1. Comunicação: troca de informações com eficiência e eficácia, e tanto nas funções

de emissor quanto de receptor, de forma clara, não ambígua e completa, e sob as
diversas dimensões de comunicações disponíveis (escrita e oral, interna/externa ao
projeto/organização/inter-organização, formal/informal, vertical/horizontal, entre outras).
De todas as habilidades necessárias a um gerente de projetos, esta é sem dúvida a mais
importante de todas, principalmente devido ao fato que um gerente de projetos investe
cerca de 90% de seu tempo em atividades de comunicação, através de reuniões de
status, de equipe, e.mail, comunicações verbais e outras atividades. As comunicações
escrita e oral são o alicerce de todo projeto bem sucedido;
2. Liderança: através do estabelecimento de direções voltadas para objetivos, metas

ou visões comuns, do alinhamento dos demais participantes em função da visão
comum estabelecida, da motivação e inspiração a ser energizada nos membros das
equipes de projeto de forma a suplantar os eventuais obstáculos de ordem política,
burocrática e de recursos por vir;
3. Negociação: a capacidade de negociar com outros de forma a chegar a acordos

benéficos aos objetivos do projeto, e no que tange aos aspectos de escopo, custo,
cronograma, mudanças, termos e condições contratuais, atribuições e responsabilidades,
alocação de recursos, por exemplo. No caso de conflitos, técnicas de negociação podem
ser utilizadas para saná-los e, no caso de dúvidas, tais conflitos devem ser sempre
resolvidos preferencialmente a favor do cliente;
4. Resolução de problemas: refere-se a uma combinação de definição de problemas e

tomada de decisões. No primeiro caso, a definição de um problema requer a distinção
entre causas e sintomas, e os problemas podem ser de ordem interna ou externa,
técnicos, gerenciais ou inter-pessoais, entre outros. A tomada de decisões inclui a análise
do problema para identificar as soluções viáveis, e posteriormente fazer uma
escolha dentre elas. Uma vez feita a escolha, as decisões devem ser implementadas. Há
que se observar, neste caso, que uma decisão certa pode não ser a melhor decisão
técnica, dadas as restrições de prazos, por exemplo;
5. Influência na organização: refere-se à habilidade de efetivamente realizar coisas. Para

isso, é necessário o conhecimento das estruturas formais e informais da
organização como as esferas culturais, de poder e da política interna da organização.
Também deve levar em consideração as relações entre clientes, parceiros, fornecedores
e concorrentes, como os fluxos de informação estão estruturados internamente, e suas
interfaces com as entidades externas à organização.
.
6. Outras habilidades pessoais e inter-pessoais: honestidade, integridade, lealdade,

auto-motivação, pró-atividade, auto-confiança, estabilidade emocional, maturidade,
tolerância, flexibilidade, entre outras não menos importantes.
Uma proposta de trabalho voltada para a gerência de projetos deve considerar que, de uma
maneira geral, o líder de projetos conduza as seguintes atividades:
 Junto ao cliente, contratante do projeto, estabelecer as principais iniciativas a serem

desenvolvidas em termos das soluções a serem desenvolvidas, e dar início ao
seu planejamento e execução, considerando parâmetros bem definidos de custos,
prazos, recursos e níveis de qualidade a serem atendidos;
 Junto ao pessoal técnico e administrativo, tático e operacional da instituição, bem
como junto aos parceiros e clientes, envolver os principais atores institucionais
ligados às soluções demandadas, obtendo deles participação e comprometimento
para o desenvolvimento das mesmas;
 Junto aos eventuais fornecedores e parceiros de mercado, avaliar e selecionar as
soluções que melhor se enquadrem ao contexto da instituição, e negociar as
melhores condições para a adoção das escolhas a serem efetivadas;
 No decorrer e ao término do projeto, dar conhecimento ao corpo executivo da
empresa quanto ao desenvolvimento das tarefas e atividades, no nível de
detalhamento, frequência e relevância adequados aos escalões gerenciais e
estratégicos da organização.
Visão integrada dos relacionamentos entre os atores institucionais envolvidos em um Projeto

A Proposta do PMI para o Gerenciamento de Projetos 31
6. A Proposta do PMI para o Gerenciamento de

Projetos
O PMI (Project Management Institute) é uma instituição fundada em 1969 com o
objetivo explícito de fomentar as melhores práticas em gerenciamento de projetos em todo o
mundo, Este instituto é tido como um desenvolvedor de padrões do American National
Standards Institute (ANSI), além de ser a primeira organização a ter o seu programa
de certificação PMP (Project Management Professional) reconhecido pela International
Standards Organization (ISO).
O PMI conta com uma associação mundial de cerca de 90.000 membros de 125
países. As seções ou capítulos locais do PMI se reúnem periodicamente e permitem que os
gerentes de projeto troquem informações e conheçam novas ferramentas e técnicas de
gerenciamento de projetos ou novas formas de utilizar as técnicas existentes.
O PMI é líder em práticas de gerenciamento de projetos, sendo a organização e

certificaçãomais conhecida no setor. O PMI empenha-se em manter e promover padrões e
normas de conduta ética neste campo e oferece outras publicações, treinamentos,
seminários, reuniões, grupos de interesse especiais e faculdades para avançar na disciplina
de gerenciamento de projetos.
O Guide to the PMBOK Guide (Guide to the Project Management Body of Knowledge)
estabelece uma estrutura, um arcabouço 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 são 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 capítulo tratará de apresentar este framework proposto pelo
PMI para a concepção, o planejamento, a execução, o controle e o encerramento dos projetos
sob sua responsabilidade.
6.1 Os Grupos de Processos de um Projeto

Os projetos são compostos de processos. Um processo é “uma série de ações que geram um
resultado”. Os processos dos projetos são realizados por pessoas, estão 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 especificação e a criação

do produto do projeto. Os processos orientados ao produto são definidos pelo
ciclo de vida do projeto e variam de acordo com a área de aplicação. Por exemplo,
em projetos de construção civil, há processos específicos da área como, por exemplo,
a instalação de equipamentos, a terraplanagem, ou a desmobilização da obra, entre
outros;
.
 Processos da gerência de projetos relacionam-se com a descrição, a

organização e a conclusão do trabalho do projeto. Este processos são genéricos, ou
seja, aplicam-se a todo e qualquer tipo de projeto.
Existe uma interação e uma sobreposição entre os processos da gerência de projetos

e os processos orientados a produto, durante todo o projeto. Por exemplo, o escopo do
projeto não pode ser definido sem algum conhecimento básico de como o produto deve ser
criado.
Naturalmente, estaremos tratando dos processos de gerência de projetos, uma vez

que os mesmos serão aplicados a quaisquer tipos de projetos. Os processos de gerência de
projetos podem ser organizados em cinco grupos, cada um deles contendo um ou mais
processos, conforme mostra a ilustração abaixo:
Ligações entre os grupos de processos em cada fase

(as setas representam fluxos de informação) - Fonte: PMBOK (2000)
1. Processos de Iniciação: são os processos iniciais de um projeto, que tratam

da identificação da necessidade a ser atendida pelo mesmo e a consequente
estruturação do projeto em termos de um problema a ser resolvido por ele. Neste
momento define-se a missão e os objetivos do projeto;
2> Processos de Planejamento: responsáveis por identificar e selecionar as

melhores estratégias para que um projeto seja abordado adequadamente. Nestes
processos são definidas as etapas e atividades específicas de um projeto bem
como suas inter-relações e sua distribuição ao longo do tempo (os cronogramas),
além de serem dimensionados os recursos necessariamente correspondentes, os
custos, os produtos de cada etapa bem como os demais parâmetros que permitam
uma execução com um mínimo de dificuldades e imprevistos;
3> Processos de Execução: são os processos que coordenam a implementação do que

foi planejado, demandando grande parte do esforço e do orçamento do projeto;
4> Processos de Controle: paralelamente aos processos de planejamento e

execução do projeto, objetivam o acompanhamento e controle das tarefas previstas em
relação ao que está sendo executado efetivamente, de forma a permitir ações
corretivas e preventivas, almejando a eliminação ou minimização dos impactos a serem
causados por anormalidades eventuais, muitas vezes não previstas;
5> Processos de Finalização: tratam do encerramento do projeto, considerando o aceite

final dos produtos e serviços gerados pelo projeto, a finalização da documentação do
projeto e a avaliação dos trabalhos realizados, bem como discussões sobre
aspectos positivos e negativos encontrados no decorrer do projeto (lições aprendidas).
Os grupos de processos se ligam pelos resultados que produzem – o resultado ou saída de

um grupo torna-se entrada para outro. Entre grupos de processos centrais, as ligações são
iterativas - o planejamento alimenta a execução, no início, com um plano do projeto
documentado, fornecendo, a seguir, atualizações ao plano, na medida em que o projeto
progride.
Além disso, os grupos de processos da gerência de projetos não são separados ou

descontínuos, nem acontecem uma única vez durante todo o projeto; eles são
formados por atividades que se sobrepõem, ocorrendo em intensidades variáveis ao longo de
cada fase do projeto. A figura abaixo ilustra como os grupos de processos se sobrepõem e
variam dentro de uma fase:
Sobreposição de grupos de processos em uma fase / projeto

Fonte: PMI, 2000
A figura a seguir apresenta a relação entre as fases genéricas de um Projeto (ou as sub-fases
de uma fase de projeto) e os níveis de atividade dos grupos de processos ao longo do
mesmo:
.
Relacionamento entre as fases genéricas de um projeto e os grupos de processos
As interações entre os grupos também atravessam as fases, de tal forma que o encerramento
de uma fase fornece uma entrada para o início da próxima. A figura abaixo ilustra
como esta interação pode ocorrer:
Interação entre fases

Fonte: PMBOK (1996)
6.2 Áreas de Conhecimento do Gerenciamento de Projetos

De acordo com o PMI (2000), há diversas áreas de conhecimento ou de atuação gerencial na
gestão de projetos. Neste caso, cada uma das áreas de conhecimento estão 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 são as áreas
de conhecimento gerencial de cada projeto:
1. Gerência de integração: inclui os processos necessários para a coordenação dos diversos

elementos de um projeto. Aplica-se ao desenvolvimento do Plano de Ação como à
execução e controle de alterações do projeto;
2. Gerência de escopo: considera os processos necessários para assegurar que o

projeto inclui todo o trabalho necessário e somente ele, de forma a permitir sua
execução e conclusão com sucesso. Engloba tanto a definição do escopo quanto de seu
controle ao longo da execução do projeto;
3. Gerência do tempo: incorpora os processos necessários para a garantia de planejamento

e execução do projeto dentro dos prazos previstos. Considera o levantamento das
atividades, o agendamento das mesmas ao longo do tempo e de seu controle;
4. 4> Gerência de custos: estabelece os processos necessários para assegurar que o

projeto seja desenvolvido dentro dos orçamentos estipulados originalmente. Considera
o planejamento de recursos, as suas respectivas estimativas de custos, a confecção do
orçamento do projeto e o controle de seus custos;
5. Gerência da qualidade: inclui os processos necessários para assegurar que os produtos e

serviços do projeto atinjam os padrões de qualidade segundo os quais o projeto
foi concebido. Envolve tanto o planejamento quanto a garantia e controle da qualidade;
6. Gerência de recursos humanos: considera os processos necessários para assegurar

o melhor emprego do pessoal envolvido no projeto. Engloba o planejamento
organizacional, a formação e o desenvolvimento da equipe do projeto;
7. Gerência de comunicações: incorpora os processos necessários para assegurar o

adequado planejamento, geração, armazenamento e disseminação de informações do
projeto;
8. Gerência de riscos: estabelece os processos relacionados com a identificação,
quantificação e análise de riscos do projeto, bem como o estabelecimento das contra-
medidas a serem tomadas quando da ocorrência de cada um dos fatores de risco
levantados;
9. 9> Gerência de suprimentos e contratação: envolve os processos necessários para

a aquisição de bens e serviços de fora da organização, no que tange a parceiros
e fornecedores de insumos para o projeto. Considera o plano de compras (tanto de bens
como de serviços), o levantamento de potenciais fornecedores, a licitação,
contratação e gestão e fechamento de contratos.
6.3 Relação entre Grupos de Processos e Áreas de

Conhecimento
.
.
Segue uma breve descrição de cada um dos processos, segundo o PMBOK (2000):
Processos de Iniciação
Iniciação (5.1) – obtenção do comprometimento da organização para o início da próxima fase
do projeto;
Processos de Planejamento
Processos Essenciais – Alguns dos processos de planejamento têm dependências 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 várias vezes durante qualquer fase de um projeto. Eles
incluem:
 Planejamento do Escopo (5.2) – desenvolvimento de uma declaração escrita do

escopo, como base para futuras decisões no projeto;
 Detalhamento do Escopo (5.3) – subdivisão dos principais subprodutos do
projeto em componentes menores e mais gerenciáveis;
 Definição das Atividades (6.1) – identificação das atividades específicas que devem
ser realizadas para produzir os diversos subprodutos do projeto;
 Sequenciamento das Atividades (6.2) – identificação e documentação das
dependências entre as atividades do projeto;
 Estimativa da Duração das Atividades (6.3) – estimativa do número de
períodos de trabalho
 (prazos) que serão necessários para completar as atividades individuais do projeto;
Desenvolvimento do Cronograma (6.4) – criação do cronograma do projeto a partir da
análise da seqüência das atividades, de suas durações, e das necessidades de
recursos a serem alocados em cada uma delas;
 Planejamento da Gerência de Riscos (11.1) – Decisão de como abordar e planejar a
gerência de riscos no projeto;
 Planejamento dos Recursos (7.1) – determinação de quais e quantos recursos
(pessoas, equipamentos, materiais, etc.) devem ser utilizados para a realização das
atividades do projeto; Estimativa dos Custos (7.2) – desenvolvimento de uma
aproximação (estimativa) dos custos dos recursos que serão necessários para
completar as atividades previstas para o projeto;
 Orçamento dos Custos (7.3) – alocação das estimativas dos custos globais aos
pacotes individuais de trabalho do projeto;
 Desenvolvimento do Plano do Projeto (4.1) – agregação 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 interações entre os demais processos de planejamento são 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
concluída e a equipe reconheça que as metas de custo e prazo são por demais ousadas,
envolvendo assim um risco considerável. Embora os processos facilitadores sejam realizados
intermitentemente e à medida que são necessários durante o planejamento do projeto,
eles não são opcionais. Eles incluem:
 Planejamento da Qualidade (8.1) – identificação dos padrões de qualidade

relevantes para o projeto e determinação de como satisfazê-los;
 Planejamento Organizacional (9.1) – identificação, documentação, e atribuição
de papéis, responsabilidades e relações hierárquicas no projeto.
 Composição da Equipe (9.2) – conseguir que os recursos humanos necessários
sejam designados e alocados ao projeto;
 Planejamento das Comunicações (10.1) – determinação das necessidades das
partes envolvidas quanto à informação e comunicação: quem necessita de qual
informação, quando necessita e como a informação será fornecida;
 Identificação dos Riscos (11.2) – determinação dos riscos prováveis do projeto e
documentação das características de cada um;
 Análise Qualitativa dos Riscos (11.3) – análise dos riscos e das suas condições de
forma priorizar seus efeitos nos objetivos do projeto;
 Análise Quantitativa dos Riscos (11.4) – mensuração da probabilidade e
impacto dos riscos e estimativa de suas implicações nos objetivos do projeto;
 Planejamento das Respostas aos Riscos (11.5) – desenvolvimento de
procedimentos e técnicas para aumentar as oportunidades e para reduzir as
.
ameaças de riscos para os objetivos do projeto; Planejamento das Aquisições (12.1) –

determinar “o que” contratar e “quando” contratar; Planejamento das Solicitações
(12.2) – documentação dos requisitos do produto/serviço a ser adquirido e as
fontes possíveis de fornecimento.
Processos de Execução
 Execução do Plano do Projeto(4.2) – levar a cabo o plano do projeto através da
realização das atividades nele incluídas;
 Garantia da Qualidade (8.2) – avaliação regular do desempenho geral do projeto com
o objetivo de prover confiança de que o projeto irá satisfazer os padrões 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;
 Distribuição das Informações (10.2) – disponibilização das informações
necessárias, e no momento adequado, às partes envolvidas;
 Solicitação de Propostas (12.3) – obtenção, conforme apropriado a cada caso
(cotações de preço, cartas-convite, licitações, concorrências), as propostas de
fornecimento dos produtos e/ou serviços pretendidos;
 Seleção de Fornecedores (12.4) – escolha, dentre os possíveis fornecedores, aqueles
que melhor satisfaçam às necessidades do projeto;
 Administração dos Contratos (12.5) – gerência dos relacionamentos com os
fornecedores.
Processos de Controle
 Controle Integrado de Mudanças (4.3) – coordenação das mudanças ao longo de todo
o projeto; Verificação do Escopo (5.4) – aceite formal dos resultados (escopo) do
projeto;
 Controle de Mudanças do Escopo (5.5) – controle das mudanças no escopo do
projeto; Controle do Cronograma (6.5) – controle das mudanças no cronograma do
projeto; Controle dos Custos (7.4) – controle das mudanças no orçamento do projeto;
 Controle da Qualidade (8.3) – monitoração dos resultados específicos do projeto para
determinar
 se eles atingem padrões adequados de qualidade, e identificação de ações para
eliminar as causas de desempenhos insatisfatórios. Difere da garantia da qualidade
porque é realizado pelos próprios integrantes da equipe do projeto, e não por pessoas
ou instituições externas a ele;
 Relato de Desempenho (10.3) – coleta e divulgação de informações de desempenho
do projeto. Isso inclui relatórios de status, medidas de progresso, e novas estimativas
para o desenvolvimento futuro do projeto;
 Controle e Monitoração de Riscos (11.6) – acompanhamento dos riscos
identificados, monitorando riscos residuais e identificando novos riscos, garantindo a
execução dos planos de risco e avaliando sua efetividade na redução dos riscos.
Processos de Encerramento
 Encerramento dos Contratos (12.6) – completar e liquidar os contratos, incluindo a
resolução de quaisquer itens pendentes;
 Encerramento Administrativo (10.4) – geração, reunião e disseminação de
informações para formalizar o término da fase ou projeto, incluindo avaliações do
projeto e compilação das lições aprendidas para uso em planejamentos de futuros
projetos ou fases (gestão do conhecimento).
.
O Relatório Executivo 43
7. O Relatório Executivo
Uma vez que um projeto é selecionado para desenvolvimento, parte-se para a sua
concepção, especificando-se de forma clara o escopo do que será empreendido. O
Relatório Executivo é elaborado de forma a tornar os parâmetros específicos do projeto mais
claros e mais profundamente compreendidos tanto pelos executivos da organização
quanto pela equipe estabelecida para este fim. Este documento discrimina o escopo que
pretende ser considerado pelo projeto, contemplando os seguintes itens:
1. Missão: declaração sucinta do que o projeto realizará;

2. Diagnóstico: apresentação dos problemas e/ou oportunidades a serem vencidos
/alavancados;
3. Escopo: detalhamento dos produtos e ações que o projeto irá executar, bem como dos
que não irá implementar;
4. Restrições: especificidades, limitantes e aspectos restritivos dos produtos a serem
gerados pelo projeto;
5. Premissas: condições pré-assumidas como verdadeiras a partir das quais o projeto será
concebido, planejado e executado;
6. Benefícios: vantagens competitivas a serem trazidas pelo projeto, na visão do cliente ou
da organização contratante;
7. Riscos: fatores que poderão comprometer a viabilidade do projeto, ou acarretar danos,
dificuldades e problemas na sua execução, 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 duração;
9. Justificativas para Contratações e Aquisições: argumentos que justifiquem a
necessidade de contratações específicas para o projeto, ou para aquisições
necessárias e imprescindíveis para seu desenvolvimento;
10. Perfil da Equipe do Projeto: habilidades necessárias para a condução do projeto;
11. Orçamento Preliminar: estimativas prévias relacionadas aos custos e investimentos
para a execução do projeto;
12. Fatores Críticos de Sucesso: condições imprescindíveis para o êxito do projeto.
Sem elas, o projeto certamente falhará.
Vejamos, a seguir, um detalhamento de cada uma das seções que devem compor um
Relatório Executivo.
7.1 Missão
Deve apresentar, de forma sucinta, o que o Projeto pretende atingir. Preferencialmente, uma
única frase deverá ser utilizada nesta seção, de forma a esclarecer o objetivo macro do
projeto. A declaração de missão de um projeto deve constar de um único parágrafo, o mais
sucinto possível, e, idealmente, deve possuir as características SMART (Specific, Mensurable,
Achievable, Results- Oriented e Time-Oriented). Vejamos como isso deve ser entendido:
.
1. Ser específica (Specific): não pode ser ambígua;

2. Ser mensurável (Mensurable): as medidas devem ser quantitativas e qualitativas
sempre que possível;
3. Ser atingível (Achievable): dados os recursos, os prazos e a capacitação adequada,
os objetivos devem ser atingíveis;
4. Estar baseada em resultados concretos (Results-Oriented): o verdadeiro teste de um
projeto efetivo é se ele atinge os resultados esperados. A declaração de missão é
uma medida clara para determinar se os resultados esperados foram, de fato, atingidos;
5. Estar orientada a um prazo bem definido (Time-Oriented): os períodos para a entrega
ou implantação do produto final do projeto deve estar bem clara na declaração de
missão do mesmo.
Naturalmente, deve-se enfatizar, na declaração de missão de um projeto, as necessidades de

negócio a serem atendidas. Neste ponto, deve-se tomar cuidado para não serem inseridas
funcionalidades específicas do projeto, nem tampouco detalhes de implementação do mesmo.
Vejamos um bom exemplo de declaração de missão de um projeto:
“(...) Esta nação deverá comprometer-se a atingir o objetivo de, antes do final desta
década, fazer com que um homem aterrisse na superfície da Lua e seja trazido de volta
à Terra de forma segura. Nenhum outro projeto espacial neste período será mais
impressionante para a humanidade, ou mais importante para a exploração do espaço no
longo prazo, e nenhum será tão difícil ou tão caro para ser executado”
Presidente John Fitzgerald Kennedy

Discurso no Congresso Nacional dos Estados Unidos
25 de Maio de 1961
Vejamos se nosso exemplo se adequa a uma declaração de missão:
1. É específica? O Presidente pede à Nação norte americana a se comprometer

especificamente e sem ambigüidade a fazer com que um homem aterrisse na superfície
da Lua e retorne, são e salvo, à Terra;
2. É mensurável? Será muito fácil medir se os resultados foram alcançados ou não;
3. É atingível? A comunidade científica da época acreditava que seria possível enviar uma
missão tripulada à Lua e retorná-la sã e salva à Terra, muito embora o Presidente JFK a
reconhecesse que este empreendimento seria muito difícil e caro;
4. Está baseada em resultados concretos? Os critérios para o sucesso eram claros: o
projeto iria ter sucesso se um homem aterrissasse na superfície lunar e retornasse para
a Terra são e salvo. Ele falharia se uma espaçonave tripulada americana não
chegasse à Lua até o final da década, ou se ela não retornasse com sua tripulação de
forma são e salva à Terra;
5. Está orientada a um prazo bem definido? Pela especificação de que os Estados Unidos
deveriam implementar uma missão lunar “até o final da década”, o Presidente
Kennedy estabeleceu um limite de prazo específico e ofereceu aos engenheiros
aeroespaciais norte-americanos uma data limite até a qual os mesmos

deveriam concentrar seus esforços.
A viabilidade da visão do Presidente JFK foi mais tarde confirmada, muito embora ele
mesmo não tenha vivido o suficiente para vivenciá-la. Em 20 de julho de 1969, os americanos
Neil Armstrong e Edwin “Buzz” Aldrin, da missão espacial Apollo 11, deu à humanidade os
primeiros passos sobre a Lua, retornando de forma segura à Terra quatro dias depois.
7.2 Diagnóstico
A seção Diagnóstico trata, principalmente, dos necessidades, oportunidades ou problemas a
serem endereçados pelo projeto. Nesta seção, devem ser considerados os fatos e situações
vividas pela organização referentes, especificamente, ao contexto que será contemplado
pelo projeto. Idealmente, estatísticas, pesquisas, gráficos e tabelas devem demonstrar a
situação atual da empresa quanto às deficiências e limitações que justificariam a execução do
projeto em questão, projeto este que buscará as soluções que se dedicarão a minimizar tais
elementos restritivos. Além disso, deve considerar, se possível também através de tabelas e
gráficos, as oportunidades a serem alavancadas a partir do desenvolvimento do projeto.
7.3 Escopo
A seção Escopo delimita a abrangência dos resultados do Projeto, tanto em termos do que o
mesmo realizará quanto em relação ao que o projeto não implementará.
7.3.1 Objetivos (ou, O Quê o Projeto REALIZARÁ):

Discrimina a relação de ações que necessariamente serão implementadas no projeto.
Devem ser sucintas, pontuais e específicas. Devem ser redigidas com verbos de ação,
como os exemplos a seguir:
 Implementar infra-estrutura tecnológica 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 gestão de logística,
atendendo aos requisitos de fornecimento e engenharia de produtos conforme
especificam os manuais KKK e LLL;
Esta seção funciona como um contrato entre as “partes” envolvidas no projeto, ou seja, os
executivos patrocinadores e a equipe do projeto. Cada um de seus tópicos deve ter sido
rigorosamente cumprido ao final do projeto, sob pena de o considerarmos como “não
concluído”, ou “parcialmente concluído”, ou até mesmo com o status de “fracassado” ou de
“concluído com restrições”. É importante enfatizar que o líder de projetos é avaliado em
.
termos dos resultados que oferece à empresa. Os objetivos de um projeto são,

necessariamente, a explicitação prática destes resultados. Podemos considerar, ainda, que os
objetivos do projeto referem-se a um detalhamento da Missão do mesmo.
7.3.2 O Quê o Projeto NÃO REALIZARÁ

Discrimina a relação de ações que NÃO serão implementadas pelo projeto. Também deve ser
sucintas, pontuais e específicas, e devem retirar toda e qualquer ambigüidade que
porventura tenha ficado subentendida na declaração dos Objetivos do Projeto.
Esta seção é necessária e de extrema importância, pois evita que se criem falsas
expectativas quanto aos resultados esperados do projeto. Vejamos alguns exemplos:
 O Projeto não realizará a substituição dos equipamentos obsoletos, devendo tal ação
ser realizada pelas equipes de logística do contratante;
 O Projeto não prevê a capacitação 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 não contemplará estudos para avaliação de tecnologias mais modernas
para a implementação da nova solução, adotando a linha tecnológica já utilizada
e de pleno conhecimento da empresa.
7.4 Restrições
Refere-se a aspectos limitadores quanto às soluções a serem desenvolvidas pelo
projeto, aspectos estes a serem respeitados durante o planejamento, a execução e o controle
do mesmo. As restrições geralmente são impostas pelo cliente, e podem limitar os custos
do projeto, os prazos, pessoal, tecnologia e outras questões que, se não forem
respeitadas, o projeto não poderá ser executado. Do contrário, o mesmo estará ferindo
determinações de seu contratante. Vejamos alguns exemplos de declarações de restrições
em um projeto:
 A solução a ser implementada deverá oferecer acesso simultâneo a, no mínimo,

1000 usuários para cada antena de telecomunicações instalada;
 Os equipamentos utilizados na solução não podem ficar mais que 3 horas
indisponíveis por mês;
 O tempo de resposta da solução deve ser de, no máximo, 1,5 segundos;
 O custo da primeira Fase do projeto não deverá ultrapassar R$ 100.000,00;
 O prazo de implantação do projeto deverá ser de, no máximo, 3 meses após a
aprovação de seu orçamento e proposta de trabalho.
Em alguns casos, as Restrições podem ser discriminadas na própria declaração de Objetivos,

o que parece ser um detalhamento de cada um dos Objetivos. Sendo assim, como
exemplos da declaração de Objetivos modificada, contendo aspectos qualitativos que os

limitam, poderíamos verificar os seguintes casos:
 Implementar infra-estrutura tecnológica 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 máximo de R$ 450.000,00;
 Desenvolver as funcionalidades X, Y e Z do sistema de gestão de logística,
atendendo aos requisitos de fornecimento e engenharia de produtos conforme
especificam os manuais KKK e LLL, de forma a torná-lo compatível e integrado
com o sistema de ERP da empresa, até março de 2002, e com um investimento
total máximo de R$ 250.000,00.
Pode surgir alguma confusão quanto ao que se considera uma Restrição e quanto ao que se
considera um item que o “Projeto não realizará”, este último presente na seção Escopo.
Devemos ressaltar que uma Restrição é 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 NÃO REALIZARÁ, por sua vez, informa o que o Projeto NÃO
fará, ou seja, não realizará, de fato. Em outras palavras, enquanto a primeira seção
(Restrições) particulariza os Objetivos a serem buscados por um Projeto, o segundo tópico (O
QUÊ o Projeto NÃO Realizará) exclui literalmente elementos que não serão sequer
considerados no desenvolvimento do mesmo, retirando-os do escopo do Projeto.
7.5 Premissas
Premissas são condições pré-assumidas como verdadeiras, ou suposições a partir das quais
o Projeto é concebido e empreendido. As premissas geralmente são impostas pela equipe do
projeto e, caso não sejam respeitadas, aumentarão os riscos do projeto. Podemos considerar
que as Premissas são verdades em que se baseiam as expectativas, previsões 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 implantação, a utilização

máxima dos equipamentos da organização não será maior que 55% de sua
capacidade operacional útil, de forma a permitir a adequada acomodação da nova
solução;
 O projeto considera que já existirá fiação elétrica e instalações hidráulicas pré-
instaladas nas fábricas e usinas do contratante, estando elas adequadas aos
padrões e normas vigentes no mercado;
 No caso de carência de recursos para a continuidade do projeto, ficará
priorizada a solução que atenda ao maior número de usuários da empresa
contratante, ao invés da solução tecnicamente melhor paramentada;
 Os fornecedores que não apresentarem um grupo significativo de outros
clientes com soluções similares às que serão desenvolvidas no projeto estarão
.
automaticamente desqualificados como candidatos a parceiros tecnológicos para a

execução do projeto.
As premissas ajudam a oferecer um “terreno firme” sobre o qual as soluções do

Projeto serão desenvolvidas e, caso sejam violadas, podem alterar significativamente o curso
das ações e decisões a serem tomadas, influenciando também o planejamento de
atividades e os custos associados a cada uma delas.
As Premissas diferem das Restrições no seguinte sentido: as Restrições 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 condições-chave a partir das quais o projeto será concebido e
planejado, sendo normalmente definidas por parte da equipe do projeto, e com objetivos
explícitos de redução de riscos para o Projeto. Desta forma, as Premissas definem
pontos de partida para a própria concepção e desenvolvimento do Projeto de forma a
torná-lo, de fato, exeqüível.
7.6 Benefícios
Vantagens a serem obtidas, do ponto de vista do cliente, após a implementação das soluções
constantes do projeto. Refere-se a ganhos diretos (ou mesmo indiretos) relacionados às
mudanças originadas a partir da incorporação das novas soluções provenientes do
desenvolvimento do projeto. Esta seção agrega valor às soluções a serem desenvolvidas,
e deve ser redigida considerando as melhorias a serem alcançadas.
Como exemplos de construções desta seção, teríamos:
 Otimização do desempenho do sistema de controle de logística, de forma a

prepará-lo para uma integração com os sistemas de fornecimento internacionalmente
utilizados, como o AAA e o BBB;
 Aperfeiçoamento dos processos de gestão de logística e de controle de
produção, permitindo economia de custos no gerenciamento dos mesmos nos médio
e longo prazos; Capacitação tecnológica dos profissionais da empresa, tornando-os
aptos a expandirem as novas funcionalidades para toda a rede de fornecimento
e de consumo, tanto da organização quanto em todas as suas empresas coligadas.
Os benefícios a serem incorporados por um projeto agregam valor e importância à iniciativa,

invariavelmente suportando novas iniciativas a serem futuramente consideradas com
interesse. Enfim, deve-se considerar a seção Benefícios como aquela que efetivamente
“vende” um Projeto aos seus clientes.
7.7 Riscos
Discrimina fatos e eventos que, caso ocorram, devem ser tratados com a máxima presteza,
sob pena de incorporar atrasos ou até mesmo a inviabilização do projeto como um todo. A
cada risco, devem ser associadas ações a serem tomadas, de forma a mitigar ou anular seus
efeitos. Por exemplo, em um projeto de “integração do sistema de logística central ao sistema
de monitoramento de transportes rodoviários”, poderíamos ter os seguintes riscos associados:
 Greve dos caminhoneiros;

 Migração do sistema vigente nas empresas de transporte para padrões proprietários
de baixo custo;
Nestes casos, deveriam ser estabelecidas as seguintes ações de resposta respectivas, como:
 Estudo a ser conduzido e levado ao corpo executivo da organização para que se

estudem termos atraentes e proativos de negociação para melhoria da remuneração
aos operadores de frete;
 Alocação de força-tarefa para estudo de novos padrões tecnológicos emergentes
de mercado, específicos para o setor de transportes.
Um outro exemplo, num projeto de “implementação de um sistema transacional baseado nas

tecnologias Web produzidas por uma empresa específica” poderia levantar, como um risco:
 Aquisição da empresa fornecedora por grupos maiores, o que poderia forçar a

mudança na linha de produtos principais.
A isso, se seguiria as seguintes ações para a mitigação do risco:
 Estudo e avaliação de parceiros e tecnologias alternativas para a implementação

da solução;
 Estudo dos cenários de fusões e aquisições futuras mais prováveis.
Neste caso, tais ações poderiam permitir uma rápida adaptação a novos contextos
mercadológicos.
7.8 Macro-Fases
Ainda sem um detalhamento maior das fases e atividades do Projeto, pode ser interessante a
discriminação das grandes etapas de um projeto (Ciclo de Vida). Mesmo considerando
que o planejamento minucioso das fases de um Projeto ainda não teve início, uma
expectativa acerca da linha base de execução de um projeto pode ser necessária. Vejamos
um bom exemplo deste item, considerando as macro-fases de um projeto de desenvolvimento
e implantação de um novo sistema de controle de transações nas filiais de uma organização
comercial:
.
FASE 1: Estudo de viabilidade técnico-financeira - Jan;

FASE 2: Planejamento detalhado da implementação - Jan-Fev;
FASE 3: Implementação da solução - Mar-Ago;
FASE 4: Implantação e roll-out - Ago-Set;
FASE 5: Encerramento do Projeto - Set.
Talvez, se houvesse um detalhamento maior, poderíamos chegar ao seguinte exemplo:
FASE 1: Estudo de viabilidade técnico-financeira - Out/Nov;

FASE 2: Contratação de consultoria para elaboração da arquitetura da solução - Out/Dez;
FASE 3: Detalhamento da arquitetura da solução - Nov/Jan;
FASE 4: Planejamento detalhado da implementação - Jan/Mar;
FASE 5: Elaboração do primeiro protótipo - Mar;
FASE 6: Validação de requisitos de escopo - Mar;
FASE 7: Implementação da solução - Abr/Jul;
FASE 8: Testes integrados e homologação da solução - Jul/Ago;
FASE 9: Implantação em piloto - Ago;
FASE 10: Expansão para todas as filiais e unidades de negócio (Roll-out) - Set/Out;
FASE 11: Estabilização da solução no ambiente organizacional - Out/Nov;
FASE 12: Encerramento do Projeto - Nov;
É interessante a inserção das estimativas de prazos para a execução de cada uma das fases
acima descritas. Normalmente, os clientes exigem conhecê-los previamente, mesmo
que seja em termos de previsões. Neste caso, sugere-se os prazos sejam estimados
de forma a considerar as diversas alternativas de execução das soluções oferecidas em
cada uma das fases previstas para o projeto. Mesmo que seja realizado um levantamento
mais pormenorizado das ações a serem tomadas para o desenvolvimento do projeto,
deve-se deixar bem claro ao cliente que tratam-se de estimativas ainda pouco profundas.
7.9 Justificativas para Contratações e Aquisições

No caso da possibilidade de incorporação de uma nova tecnologia através do projeto, pode
revelar-se imprescindível a contratação de uma consultoria especializada no assunto em
questão. Além disso, pode haver também a necessidade de se orçarem treinamentos para a
equipe do projeto, ou mesmo para o pessoal que passará a operar as soluções
implementadas através do projeto. Nestes casos, entre outros, devem ser levantados
previamente todos os tipos de serviços necessários à execução do projeto de forma a
não surpreender a organização no que tange à preparação da mesma para assimilação das
novas soluções.
Além disso, caso se verifique necessária a aquisição de computadores, mobiliário, softwares e

outros suprimentos e equipamentos, é importante a previsão antecipada dos mesmos
principalmente para que se estime o esforço, o orçamento e os prazos para a
adequada absorção destes recursos.
Sendo assim, esta seção deve contemplar as justificativas adequadas para as

eventuais aquisições de recursos, materiais e suprimentos necessários para a execução do
projeto, bem como apresentar os argumentos que deverão levar às eventuais contratações
de serviços. Naturalmente, itens ordinários a serem utilizados no projeto não devem ser
necessariamente justificados nesta seção, a não ser que o cliente assim o exija, e
considerando que todos eles estarão inseridos na seção seguinte, o “Orçamento Preliminar”
(Ex. material de escritório, telefonia, deslocamento, estadia e alimentação, etc.)7.
7.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 condução do projeto, podem ser
recomendados perfis de conhecimento desejáveis, incluindo aí as habilidades e skills
necessários à sua composição. Caso seja necessária a capacitação de alguns dos membros
da equipe de projeto, devem ser justificados os treinamentos necessários, e isso é
normalmente feito na seção “Justificativas para Contratações e Aquisições”, conforme citado
anteriormente. Como exemplo da definição do perfil de uma equipe de projeto, vejamos a
seguir:
 1 profissional para gerenciar a equipe de Projeto, com boa capacidade de

comunicação oral e escrita, liderança, iniciativa e de espírito empreendedor e
proativo; deve possuir experiência comprovada mínima de 5 anos na condução
de equipes multidisciplinares; deve possuir médio a alto conhecimento nas
tecnologias XXX, YYY e ZZZ;
 1 profissional de nível sênior, com alta capacidade de trabalho em equipe e
de transferência de conhecimentos, com experiência comprovada na tecnologia
XXX por mais que 5 anos, e com médio conhecimento nas tecnologias YYY e ZZZ;
 2 profissionais de nível pleno, com boa capacidade de trabalho em equipe, com
grande nível de conhecimentos e experiência comprovada mínima de 3 anos
nas tecnologias YYY e ZZZ;
 1 profissional com experiência mínima de 3 anos em documentação de projetos.
7.11 Orçamento Preliminar

Como um apoio para a tomada de decisões, faz-se necessário um orçamento preliminar que
discrimine os investimentos necessários para o desenvolvimento do projeto. Se for possível,
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, serviços, etc.).
Contudo, o plano de desembolso poderá ser desenvolvido posteriormente, quando da

elaboração do Plano de Execução, como veremos adiante. Vejamos, logo abaixo, um
exemplo sucinto do que se pode oferecer em termos de orçamento preliminar:
.
Investim entos Qtde Valor Unitário Valor Total

Hardw are
Servidores Desenvolvimento 2 20.000,00 40.000,00
Servidores Homologação/Produção 2 35.000,00 70.000,00
Estações de Trabalho 34 2.500,00 85.000,00
Impressoras 4 4.000,00 16.000,00
Equipamento de Rede 7 1.500,00 10.500,00
Sub-total Hadw are 221.500,00
Softw are
Window s 36 1.000,00 36.000,00
Ferramentas de Desenvolvimento 4 3.200,00 12.800,00
Banco de Dados 3 4.000,00 12.000,00
Backup 3 1.000,00 3.000,00
Ainti-vírus 36 250,00 9.000,00
Sub-total Softw are 72.800,00
Serviços
Treinamento 6 2.500,00 15.000,00
Consultoria 1 25.500,00 25.500,00
Sub-total Serviços 40.500,00
TOTAL DE INVESTIMENTOS 334.800,00
Custos/Despesas (em 6 m eses) Qtde Valor Unitário Valor Total

Suprimentos
Papel 120 10,00 1.200,00
Toner para impressora 28 250,00 7.000,00
Material de escritório 6 250,00 1.500,00
Sub-total Suprimentos 9.700,00
Serviços
Contrato de manutenção 4 7.000,00 28.000,00
Sub-total Serviços 28.000,00
TOTAL DE CUSTOS/DESPESAS (em 6 m eses) 37.700,00
TOTAL GERAL (investim ento + Custos/Despesas) 372.500,00
Exemplo de um Orçamento Geral de um Projeto
7.12 Fatores Críticos de Sucesso

Requisitos imprescindíveis para a implementação do projeto, sem os quais o mesmo
não poderá ser viabilizado. Podemos citar, como exemplo, num projeto de
“implementação de infra-estrutura de segurança de informações”, os seguintes Fatores
Críticos de Sucesso:
 Aquisição de softwares de firewall que estejam cotados como efetivamente seguros,

e notoriamente avaliados a partir de organismos e instituições independentes;
 Alocação em tempo integral de um profissional especializado em protocolos de
comunicação TCP/IP;
 Contratação de empresa ou especialista de consultoria em segurança de

informações, para oferecer mecanismos voltados à configuração segura dos
servidores da empresa.
Outros projetos que estejam previstos ou já sendo executados pela organização podem ser
considerados como Fatores Críticos 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 Críticos de Sucesso.
Uma questão importante a ser considerada neste item é o comprometimento que a nova
solução deverá demandar em relação às diversas áreas envolvidas, estimulando alterações
significativas em seus processos e rotinas internos. Cada uma destas implicações devem
ser consideradas como Fatores Críticos de Sucesso.
ATENÇÃO!
Uma vez mais estamos chamando a atenção para os pontos a seguir: alguma confusão pode
ser feita em termos do que se referem as seguintes seções como, “O QUE o Projeto NÃO
Fará”, “Restrições”, “Premissas” e “Fatores Críticos de Sucesso”. Recordemos suas
definições básicas:
 O QUE o Projeto NÃO Fará: itens não cobertos pelo projeto;

 Restrições: limitantes em relação aos resultados a serem gerados por um projeto;
Premissas: condições assumidas pela equipe do projeto a partir das quais um projeto
será concebido, planejado e executado;
 FCS: condições imprescindíveis para que ocorra o verdadeiro sucesso do projeto.
Como um exemplo, consideremos um projeto de realização dos eventos de formatura.

Poderíamos qualificar, da seguinte forma, elementos do projeto nos tópicos acima descritos:
 O QUE o Projeto NÃO Fará: o projeto não realizará rifas, ou churrascos de

confraternização, objetivando angariar fundos que o financiem;
 Restrições: o evento de colação de grau estará sendo dimensionado para
cerca de 300 pessoas, incluindo os próprios formandos, professores,
coordenadores e diretores de curso, e não poderá custar mais de R$20.000,00;
 Premissas: a prioridade na execução do projeto estará focada nas cerimônias de
colação de grau e celebrações religiosas, ficando a execução 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 contratação de serviços de cerimonial é essencial e imprescindível para o
sucesso dos eventos a serem executados.
Num processo iterativo entre o líder de projeto e sua equipe, os gerentes das áreas afins e os
executivos envolvidos com a iniciativa, o Relatório Executivo é aprovado quando não
há mais nenhuma dúvida ou ponderação por parte do corpo decisório. Este relatório passa a
ser considerado efetivamente como uma espécie de contrato firmado entre a equipe do
projeto e os executivos que o aprovaram.
.
O Plano de Execução 55
8. O Plano de Execução
Uma vez que o Relatório Executivo deixa claro para a equipe de projeto como para os
executivos da organização contratante qual será o escopo das soluções a serem
desenvolvidas e implementadas, deve-se passar para o dimensionamento do projeto em
termos de seu plano de execução, ou seja, o detalhamento de suas fases, atividades,
produtos, prazos e recursos a serem empregados no projeto, além de definir como se dará
a interação entre cada um de seus participantes e envolvidos.
Ressaltamos, porém, que esta tarefa não é 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 são os elementos constituintes do Plano de
Execução de um Projeto:
1. Cronograma;
2. Matriz de Responsabilidades;
3. Plano de Desembolso;
4. Produtos e Sub-Produtos;
5. Plano de Comunicação.
Em alguns casos, o Plano de Execução pode ser parte integrante do Relatório Executivo.
8.1 Cronograma
Constitui-se do estabelecimento e descrição das fases e atividades de execução do projeto,
bem como sua distribuição no tempo. Devem ser consideradas as precedências (refere-se à
ordem em que tarefas devem ocorrer de forma a permitir que outras sejam executadas
propriamente), as prioridades (níveis de urgência de tarefas em relação a outras de mesma
precedência) e a possibilidade de paralelismo entre elas (refere-se às possibilidades de
simultaneidade na execução de várias tarefas).
Também nos casos em que um grupo limitado de recursos seja necessário para a execução
de tarefas que, em tese, poderiam ser executadas em paralelo, algumas das tarefas devem
ser priorizadas em relação à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 orçamento pode crescer
muito, e de forma “artificial”. Além disso, os prazos devem ser justificados dentro de uma
realidade viável. Naturalmente, podem haver falhas nas estimativas iniciais, o que pode levar
à necessidade de renegociações junto aos clientes.
Contudo, antes de se partir para a proposta de adiamentos ou postergações é sempre

necessário verificar todas as alternativas que poderiam levar à manutenção dos prazos
estabelecidos.
.
Quando houver a iminência de um possível atraso ou desembolso adicional em um projeto,

após esgotadas todas as alternativas possíveis que eventualmente possam contornar
eventuais impactos no projeto, tanto em termos de renegociação das funcionalidades
esperadas, ou em termos de revisão de prazos e custos, deve-se empregar a seguinte
regra: informar tais possibilidades ao executivo patrocinador o quanto antes possível, de
forma a não deixá-lo sob pressão, no último instante, para uma adequada tomada de
decisões que procure corrigir o rumo do projeto.
Como exemplo, verifiquemos o cronograma para um projeto hipotético de marketing

visando o lançamento de um novo produto no mercado:
Conforme pode ser observado a partir do exemplo acima:
 A Fase I possui precedência sobre as fases II e III, pois é necessária que ela
seja concluída antes que as demais possam ser iniciadas;
 A Fase II possui prioridade sobre a Fase III, apesar de que isso não necessariamente
fica explícito no gráfico, a não ser pelo fato que a Fase II possui uma duração maior
que a Fase III, o que a torna parte do caminho crítico do projeto;
 As Fases II e III podem ocorrer em paralelo, pois a execução de uma delas não
necessariamente concorre contra a outra (a não ser em termos dos recursos e
pessoas envolvidas, o que pode gerar algum conflito);
 A Fase IV somente poderá iniciar-se após as Fases II e III, sendo estas

últimas necessariamente predecessoras da anterior.
As questões relativas a paralelismo, prioridades e precedências podem e devem ser também

analisadas em termos das atividades de cada fase, bem como entre as macro-fases de um
projeto. O exemplo ilustra esta precedência e mostra paralelismo entre algumas atividades,
como pode ser verificado visualmente no cronograma acima. Em outras palavras, a
otimização das etapas de um projeto deve ser buscada a todo momento, de forma a ganhar-
se produtividade e eficiência na gestão do tempo.
Quanto às estimativas para duração de tarefas, poderíamos analisar a seguinte sugestão. A

duração estimada (DEstimada) poderá ser calculada a partir de uma média ponderada
entre as durações “mais provável” (DProvável), a “mais tarde” (DTarde) e a “mais cedo” (DCedo),
da seguinte forma:
(D Cedo  4 x D Provável  D Tarde )

D Estimada 
6
Para exemplificarmos o cálculo, consideremos o seguinte caso:
DCedo = 2 dias
(2  4 x 3  5)
DProvável = 3 dias D Estimada   3,17
6
DTarde = 5 dias
Devemos ressaltar que DCedo poderá ser igual ou muito próxima à DProvável, assim
como DTarde também poderá ser igual ou muito próxima à DProvável.
Para a estimação de cada uma das durações consideradas, em qualquer situação não se
deve menosprezar a experiência daqueles que efetivamente realizarão 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 níveis de esforço 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 alcançar algo útil e real em
menor prazo, disponibilizar mais e melhores recursos para a implementação de forma a
acelerar o processo de desenvolvimento, discutir as técnicas ou as formas de implementação
a serem empregadas de forma a eliminar trabalho não imprescindível, entre outros
fatores, objetivando adequar as estimativas apresentadas pelos técnicos e participantes à
realidade dos resultados do projeto, sobretudo no que tange ao ponto de vista do cliente.
.
Algumas atividades podem possuir duração zero. Neste caso, considera-se tais atividades
como marcos, ou seja, como pontos a serem atingidos no tempo, e que sobre eles
não se pode precisar a duração específica. Além disso, os marcos podem indicar pontos
de controle (“checkpoints”) ao longo do projeto, sobre o qual devem ser tomadas ações
específicas.
Como um exemplo de um marco temos, em algumas empresas, o prazo para a aprovação de

determinados orçamentos, que pode estender-se por um período imprevisível, seja de 2
semanas, seja de 2 meses, devido aos trâmites burocráticos internos. Neste caso,
poderíamos criar uma tarefa de duração zero intitulada “Aprovação do orçamento XXX”, e
indicar que todas as demais que a têm como precedente somente se iniciarão quando
esta última tiver se encerrado. Uma outra alternativa seria realizar, de fato, uma
estimativa acerca desta atividade conforme a fórmula sugerida acima, e respeitando-se
experiências similares vivenciadas anteriormente.
Para exemplificarmos ainda mais o emprego dos “marcos”, analisemos o cronograma

ilustrado acima:
 A atividade 1.5, “Apresentação de Resultados”, como refere-se a uma reunião

com o cliente para demonstração dos dados levantados e analisados na pesquisa
realizada, está discriminada como um marco, por dois motivos: 1> Refere-se a
uma atividade cuja duração se estenderá, muito provavelmente, durante uma manhã
ou, no máximo, em um determinado dia, e data esta que deverá ser confirmada com o
cliente proximamente à sua execução; 2> É uma atividade sem a qual a Fase I não
poderá ser considerada encerrada, e fato este que, enquanto não ocorrer, as Fases II
e III não poderão ser iniciadas;
 A atividade 2.6, “Aprovação de peças publicitárias”, pode ser realizada em uma

simples reunião, como também poderá levar semanas. A inserção desta atividade
como um marco deixa claro que, somente após sua execução é que poderemos
considerar concluída a Fase II;
 A Atividade 3.7, “Equipe de vendas preparada”, refere-se a um marco de

encerramento da Fase III. Contudo, esta inserção em forma de marco não é
necessária neste caso, pois a própria conclusão das atividades 3.5 (“Treinamento
das equipes de vendas”) e 3.6 (“Distribuição do material de divulgação – kit do
vendedor)” indicarão o término da Fase III com sucesso;
 A atividade 2.4, “Aprovação de orçamentos”, mesmo inserida como um marco,

não impede que a atividade seguinte, 2.5 (“Elaboração de peças publicitárias”)
tenha seu início realizado antes mesmo que ela tenha sido vencida. Isso nos leva a
acreditar que o planejador do projeto considerou que os riscos associados ao
início prematuro da atividade 2.5 são aceitáveis em relação à não conclusão da
atividade 2.4 (talvez o que se pretenda é que alguns trabalhos a serem executados na
atividade 2.5, trabalhos estes que não tenham a necessidade de investimentos e
desembolsos significativos, possam ser iniciados antes mesmo da aprovação
integral do orçamento. Contudo, de maneira geral, consideramos temerária a
execução de atividades de implementação sem a devida aprovação de seus

orçamentos correspondentes, o que nos leva a considerar que este exemplo é
meramente de emprego didático);
 A atividade 3.4, “Análise jurídica do material de divulgação”, devido à incerteza quanto

à sua duração estimada, foi inserida como um marco. Além disso, ela é pré-requisito
para a continuação do projeto, pois sem o aval do departamento jurídico, o
material de divulgação não poderá ser distribuído, bem como o treinamento dos
vendedores não poderá ser iniciado.
Existe um grande problema em relação à utilização de marcos em cronogramas. O fato de

que, como os marcos possuem duração 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 alcançado,
pois sua duração real somente poderá ser conhecida ao término de sua execução.
Esta alternativa poderá causar algum desgaste na relação entre o gerente de projetos
e seus clientes, que podem ter uma interpretação pouco clara do fato, “esquecendo-
se” do correto significado dos marcos em cronogramas;
2. Ao invés de se utilizar marcos para representar tais tarefas, estimar sua

duração da mesma maneira como são realizadas as demais atividades do
projeto. Neste caso, a experiência interna dos planejadores será importante fator
a ser considerado na sua definição e, talvez, seja uma boa ocasião para definir-se
“folgas”, desde que aceitáveis.
8.2 Matriz de Responsabilidades

Para cada atividade de um projeto é necessária a atribuição de responsabilidades para sua
execução. Uma sugestão de matriz de responsabilidade para a Fase I do projeto
utilizado como exemplo na página anterior seria como a seguinte:
.
Executivo Patrocinador
Empresa de Pesquisa
Analista de Marketing
Gerente de Marketing
Gerente de Produto
Consultor Jurídico
…………
…………
…………
Plano de Marketing - Lançamento de produto
Fase I - Pesquisa de mercado
… … …
! ! ! ! !
!
1.1 - Contratação de empresa especializada  F
… … …
!
1.2 - Definição de objetivos da pesquisa 1
… … …
! !
1.3 - Definição de respostas a serem obtidas F 1
1.4 - Realização da pesquisa de mercado F 1 … … …
… … …
!
1.5 - Apresentação de resultados  F
… … … …
… … … …
Legenda:
 Aprovação Final
F É Responsável
0 Realiza
!
Participa/Deve ser Informado
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, responsável. No caso do

responsável ser também um executor, é melhor indicá-lo como o responsável,
pois havendo outro executor, ficariam dúvidas sobre qual deles seria o responsável
de fato;
 Deve haver um único responsável por cada atividade, mas podem ser alocados
sub-responsáveis, que atuariam em substituição ao mesmo no caso de sua
ausência. Ainda neste caso, deverá haver um único interlocutor responsável para
cada tarefa;
 Não se recomenda que uma empresa terceira ou uma pessoa externa à organização
seja responsável por alguma atividade. Neste caso, a recomendação é de que
alguém da equipe de projeto seja o responsável pela atividade, e a empresa
ou o terceiro seja indicado como executor;
 Podem ser considerados casos em que algumas pessoas participam da
confecção da atividade, ou devem ser informadas de seu andamento, sem
no entanto serem responsáveis diretos pela sua execução ou mesmo executores
propriamente ditos;
 Ressalta-se que, sempre que possível, deve ser considerada a participação do
usuário da solução 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 células da matriz, indicando que
aquele participante não desempenha nenhum papel na atividade correspondente,
o que não significa que o mesmo não tenha participação efetiva em outras fases e
atividades;
 Em muitos casos, gerentes e executivos podem não estar representados do ponto de
vista dos detalhes de implementação, mas idealmente devem estar “alocados” na
apresentação, validação e aceite dos resultados finais;
 Excepcionalmente, podem ser contratados consultores externos ou administradores
que sejam vistos como responsáveis por tarefas e atividades. Nestes casos
específicos, pode ser que eles tenham sido trazidos à organização não apenas
para executar tarefas, mas para conduzirem as mesmas como se fossem parte
da própria organização contratante. Desta forma, não consideramos que a
responsabilidade estaria sendo delegada a um terceiro comum, mas a um
terceiro com plenas funções internas à organização, assumindo um papel muito
parecido com o de um profissional da empresa (profissional este que poderia ser
considerado o responsável pela execução das atividades previstas para o
projeto). Em todo caso, continuamos a reforçar que apenas indivíduos da própria
organização sejam os responsáveis pelas tarefas. No caso dos consultores e/ou
administradores externos à organização, o máximo que lhes pode caber é a execução
das mesmas, sendo contra-indicado estabelecê-los como responsáveis.
8.3 Plano de Desembolso

Todos os recursos a serem estimados para um Projeto devem ser estabelecidos previamente,
o que permitirá o detalhamento do orçamento e do plano de desembolso do projeto.
Naturalmente, grande parte destas estimativas poderão sofrer (e certamente sofrerão)
alterações significativas no decorrer do desenvolvimento do projeto. Ainda assim, o
levantamento dos recursos com seus custos associados deve aproximar-se o máximo
possível da realidade presumida, pois aumentos no orçamento de um projeto são
dificilmente bem vistos aos olhos de quaisquer clientes ou executivos envolvidos.
Mais uma vez vale a máxima 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 ação a serem negociados junto aos
executivos patrocinadores e clientes do projeto.
Em cada fase/atividade, devem ser estabelecidos os recursos de pessoal, equipamentos,

mobiliário, material, software, instalações e serviços 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 mensuráveis e de entendimento efetivo por parte dos executivos patrocinadores,
como a quantidade de homens/hora, a quantidade de materiais ou seu consumo médio como,
por exemplo, a utilização de telefone, papel e cartuchos de impressão, entre outros.
Nesta seção, também devem ser consideradas as especificações detalhadas para os tipos de
equipamentos, programas de computador, serviços de treinamento e capacitação para
a equipe, viagens eventualmente necessárias (com as respectivas despesas de
.
traslado, hospedagem, deslocamento local e alimentação), características das instalações

físicas onde se alocará a equipe do projeto, custos de conexões a redes internas e
externas (por exemplo, à Internet), número de aparelhos, linhas e ramais telefônicos, FAX,
secretária, livros e publicações necessários para que se atinja a qualificação adequada para o
desenvolvimento do projeto, entre outros.
Vejamos um exemplo de Plano de Desembolso, conforme o Orçamento Preliminar

desenvolvido no capítulo anterior:
Investim entos jan-05 fev-05 m ar-05 abr-05 m ai-05 jun-05 total
Servidores 40.000,00 70.000,00 110.000,00
Estações 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 de hardw are 55.500,00 0,00 102.000,00 0,00 64.000,00 0,00 221.500,00
Window s 6.000,00 10.000,00 20.000,00 36.000,00
Ferramentas de desenvolvimento 12.800,00 12.800,00
Banco de dados 4.000,00 8.000,00 12.000,00
Backup 3.000,00 3.000,00
Anti vírus 1.500,00 2.500,00 5.000,00 9.000,00
Sub-total de softw are 27.300,00 0,00 20.500,00 0,00 25.000,00 0,00 72.800,00
Treinamento 15.000,00 15.000,00
Consultoria 0,00 8.500,00 8.500,00 8.500,00 25.500,00
Sub-total de serviços 15.000,00 0,00 8.500,00 8.500,00 8.500,00 0,00 40.500,00
Total de Investim entos 97.800,00 0,00 131.000,00 8.500,00 97.500,00 0,00 334.800,00
Custos/Despesas jan-05 fev-05 m ar-05 abr-05 m ai-05 jun-05 total

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 escritório 250,00 250,00 250,00 250,00 250,00 250,00 1.500,00
Sub-total de suprim entos 850,00 850,00 1.350,00 1.550,00 2.550,00 2.550,00 9.700,00
Manutenção 14.000,00 14.000,00 28.000,00
Sub-total de serviços 14.000,00 0,00 14.000,00 0,00 0,00 0,00 28.000,00
Total de 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
Observar as totalizações do plano de desembolso ao longo do projeto, tanto de

maneira geral, (coluna “TOTAIS”) quanto em relação a cada item em específico, bem como a
cada período de desembolso considerado (mensal).
Este demonstrativo, também denominado cronograma físico-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 à organização
sob a forma de investimentos a serem conduzidos.
8.4 Produtos e Sub-Produtos

Cada uma das fases de um projeto deve apresentar, em sua conclusão, produtos e
sub-produtos a serem entregues como resultados de sua execução. Neste caso, o que
caracteriza a conclusão de uma fase ou atividade é justamente a disponibilização dos
produtos e sub-produtos gerados através de sua execução. Os produtos referem-se à
materialização dos objetivos e resultados esperados pelo projeto. Os sub-produtos, por sua
vez, também chamados entregas, são resultados parciais ou intermediários obtidos no
decorrer do projeto, e significam a conclusão de fases e atividades internas
específicas. Todos eles devem ser concebidos a priori, devendo também ser
estabelecidos os seus parâmetros de qualidade a serem atendidos conforme as
expectativas dos clientes do projeto.
Os produtos e sub-produtos são, na verdade, a principal moeda que os líderes de

projeto possuem para justificar os investimentos realizados nas iniciativas e
empreendimentos sob sua responsabilidade, pois representam a efetiva obtenção dos
resultados esperados pelos executivos e clientes e para avalizar sua condução em
relação às expectativas estabelecidas pela organização quanto ao projeto.
Vejamos, ainda de acordo com a Fase I do projeto hipotético de marketing apresentado

anteriormente, uma provável especificação de produtos e entregas para cada uma de suas
atividades correspondentes:
Plano de Marketing - Lançamento de produto

Fase I - Pesquisa de mercado Produtos / Entregas
1.1 - Contratação de empresa especializada  Contrato com empresa especializada em pesquisas de
mercado, com aprovação do consultor jurídico. Este
contrato deverá prever, entre os aspectos legais
normais, o detalhamento do seguinte escopo:
- Levantamento dos objetivos da pesquisa, em
parceria com o contratante;
- Elaboração dos instrumentos de coleta de dados;
A efetiva realização da pesquisa;
- Análise dos resultados da pesquisa em função do
lançamento do novo produto e das necessidades
da empresa;
- Apresentação dos resultados da pesquisa ao
corpo executivo da organização.
1.2 - Definição de objetivos da pesquisa  Documento que discrimina quais serão os objetivos da
pesquisa de mercado a ser conduzida, em função do
lançamento do novo produto.
1.3 - Definição de respostas a serem obtidas  Documento que estabelece os instrumentos de coleta
de dados, seu conteúdo, a metodologia de aplicação
dos mesmos, a composição da amostragem a ser
utilizada bem como a discriminação de como os
resultados poderão ser apurados a partir dos métodos
empregados na pesquisa;
1.4 - Realização da pesquisa de mercado  Instrumentos de coleta de dados preenchidos; Análise
de resultados realizada;
 Conclusões e recomendações estabelecidas;
Apresentação executiva da pesquisa preparada e
agendada.
1.5 - Apresentação de resultados  Apresentação executiva dos resultados da pesquisa de
mercado realizada.
Exemplo de relação de produtos e entregas da Fase I de um projeto hipotético
Observe o nível de detalhamento de cada um dos produtos e entregas a serem gerados ao

longo da conclusão de cada uma das fases e atividades respectivamente associadas, o que
.
também objetiva-se a dirimir quaisquer dúvidas acerca dos resultados finais ou

intermediários a serem produzidos pelo projeto.
8.5 Plano de Comunicação

Para que todos os membros e participantes de um projeto troquem as informações
necessárias para a adequada condução de seus trabalhos, devem ser estabelecidos
planos para a comunicação bem como para o controle das alterações eventualmente
necessárias, alterações estas principalmente relacionadas aos prazos, custos e escopo do
projeto.
O plano de comunicação deve contemplar, pelo menos, os seguintes itens:
 Que tipos de informações deverão ser levantadas para acompanhamento e ações

corretivas?
 Informações financeiras, relativas ao desembolso promovido pelo projeto;
 Informações de cronograma, como atrasos, antecipações, folgas, etc.;
Informações relacionadas aos riscos do projeto;
 Informações relacionadas aos problemas e conflitos gerados ao longo do projeto;
Informações relacionadas aos fornecedores de produtos e serviços do projeto;
 Informações relativas ao cumprimento de etapas, atendimento de
funcionalidades, desempenho do projeto, lições aprendidas, entre outras;
 Como e em que frequência será realizada a troca de informações ao longo do

projeto. Exemplos:
 e-Mails para troca de informações operacionais;
 Brainstormings para solução de problemas;
 Brainstormings para levantamento e análise de lições aprendidas, principalmente
após cada resolução de problema, bem como ao término de cada uma das fases
do projeto; Relatórios semanais de posicionamento;
 Checklists para acompanhamento de tarefas operacionais; Reuniões semanais de
acompanhamento e controle (com ata);
 Reuniões quinzenais de posicionamento aos executivos patrocinadores (com ata).
 Onde serão realizadas as reuniões de acompanhamento e quando. Neste caso,

mesmo tendo sido estabelecida a frequência de alguns tipos de reunião, alguns
encontros podem ser marcados com antecedência prévia, uma vez que
geralmente são conhecidos e determinados os diversos pontos de controle
(checkpoints) das principais fases do projeto, previstos em cronograma;
 Quem deverá ser informado, e com qual antecedência, para a participação nas
reuniões de acompanhamento;
 Quem será o responsável pela produção, guarda e recuperação das

informações e documentos produzidos ao longo do projeto;
 Como e em que local serão armazenadas as informações pertinentes ao

projeto (Ex. repositório de documentos, ou pastas e arquivos físicos, ou pastas
de documentos eletrônicos);
 Quais serão os modelos de formulários a serem utilizados ao longo do projeto, como

nos seguintes casos:
 Requisições de alteração de escopo;
 Atas de reunião;
 Checklists para acompanhamento de atividades e pendências;
 Relatórios de desempenho, em termos de custos, prazos e funcionalidades
atendidas;
 Relatórios de problemas.
Outros aspectos específicos devem ser analisados e previstos nesta fase, de forma a prever
eficientes formas de troca de informações ao longo de um projeto, não somente entre
os participantes diretos do projeto, mas em relação a toda a organização ao que o mesmo se
insere.
É importante ressaltar que um plano de comunicações efetivamente executado

necessariamente leva à excelência do controle do projeto, pois pode evitar desembolsos
adicionais e atrasos e perdas de funcionalidades já previstas em função de decisões tomadas
sem a antecedência e o nível de conhecimento global adequados.
.
1
Negociação e Alocação de Recursos 67
9. Negociação e Alocação de Recursos

Cada recurso a ser empregado em um projeto deve ser cuidadosamente planejado, de forma
que sua não utilização ou desperdício possa minar a credibilidade da equipe de projeto, bem
como do projeto em questão e de todos os outros que venham posteriormente a ser
desenvolvidos pelo mesmo pessoal. Além disso, para que um Plano de Execução 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 responsável por ele deve se comprometer a disponibilizá-lo
nas datas e prazos estabelecidos previamente, sob pena de inviabilizar o cronograma
estabelecido. Essa regra vale também para os demais recursos considerados necessários
para a execução do projeto.
Em outras palavras, um Plano de Execução somente poderá ser considerado validado

quando todos os participantes de um projeto estiverem comprometidos com o que nele
estiver contido.
9.1 Negociando a Alocação de Profissionais

Quanto à alocação de pessoas em fases específicas do projeto, deve haver uma
previsão razoável das datas mais prováveis do início de seu envolvimento, com significativa
antecedência 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 períodos de alocação de um profissional a um projeto de forma a
“devolvê-lo” a sua área original ao término de sua participação no mesmo.
A tarefa de negociação de recursos, sobretudo os que se referem à participação de

profissionais nos projetos, apresenta-se como um grande paradoxo organizacional. Da
mesma maneira que certas áreas da empresa demandam por novas soluções
tecnológicas, mesmo considerando que seus melhores colaboradores sejam envolvidos
em período 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 não poderiam abandonar suas atividades diárias 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
responsáveis por um projeto. Uma boa estratégia de negociação sugerida para
possibilitar a participação destes profissionais nos projetos seria o de considerar tal
alocação como um investimento interno efetivo, o que necessariamente deve
vislumbrar retornos significativos para ambas as partes.
.
Devem-se apontar as melhorias e os benefícios 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 após a
conclusão do projeto, o que justificaria o envolvimento daquele profissional por um período
determinado de tempo, ainda que não integralmente dedicado ao mesmo.
9.2 Negociando a Alocação de Recursos Físicos

Quanto à alocação de equipamentos e materiais diversos, deve-se preferencialmente tentar-
se a utilização de recursos já existentes na organização, economizando-se investimentos
adicionais. Além disso, deve-se verificar o destino dos mesmos após sua utilização pela
equipe do projeto. Por exemplo, considere a aquisição de um equipamento de alto
desempenho para a simulação do ambiente operacional de produção, em um projeto que
se presta à construção de um protótipo para uma nova solução tecnológica.
Poderia se argumentar que, ao término do projeto, tal equipamento, caro e sofisticado, ficaria
sem utilidade, “desperdiçando” 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 maximização de seu emprego nos mesmos.
Por exemplo, o equipamento poderia ser empregado para os testes de outras soluções em
desenvolvimento, ou a ser utilizado como contingência às soluções já existentes, no caso
de falhas operacionais. Ainda, o mesmo equipamento poderia ser utilizado como plataforma
base para um ambiente de laboratório para novos projetos que estejam sendo vislumbrados.
Na prática, o que normalmente acontece é que muitos dos equipamentos e recursos

definidos para a execução de um projeto ganham uma finalidade justamente baseada na
nova solução a ser implementada. Em outras palavras, os recursos utilizados no projeto de
maneira geral ficam vinculados à configuração da própria solução a ser desenvolvida.
Pode ser que a própria empresa já possua um pool de recursos a serem

especificamente alocados a novos projetos, o que evitaria novas e contínuas
aquisições. Como um projeto deve possuir marcos bem definidos, tais recursos devem ser
colocados à disposição da empresa à medida que seu uso não seja mais necessário,
favorecendo o desenvolvimento de outros projetos.
Uma outra alternativa para a alocação de recursos temporários em projetos pode ser
o aluguel de equipamentos por um período específico, bem como a contratação eventual de
serviços de terceiros para a execução de tarefas bem definidas.
Gerência de Riscos 69
10. Gerência de Riscos
10.1 Definição de Risco

 Risco é a possibilidade de se sofrer uma perda. A perda poderá ser de
qualquer coisa, desde a diminuição de qualidade de uma solução até o aumento do
custo de um projeto, o atraso em prazos ou mesmo o fracasso geral do projeto.
 Uma outra boa definição de risco é a seguinte: um problema esperando para

acontecer.
10.2 Características do Risco

 Riscos são inerentes a qualquer projeto: o risco é um ingrediente fundamental
da oportunidade e sendo intrínseco a qualquer projeto;
 Os riscos não são intrinsecamente bons nem ruins;
 O risco não 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, através de ações pró-ativas
para cada um dos riscos identificados.
Princípios de uma Gerência de Riscos bem sucedida

Riscos envolvem pessoas, processos e tecnologia. Para um gerenciamento eficaz dos
riscos em um projeto devemos considerar os seguintes princípios:
 Avaliar os riscos continuamente ao longo do ciclo de vida do projeto: mais do

que identificar os riscos no início do projeto, uma boa gerência de riscos requer a
constante avaliação dos mesmos ao longo da vida do projeto, devido ao fato que
novos riscos são revelados ao longo do projeto. Além disso, os riscos já identificados
podem se tornar mais ou menos prováveis, ou mais ou menos severos durante a
evolução do projeto;
 Utilizar-se de tomada de decisões baseada em riscos: todas as decisões

devem ser tomadas no contexto dos seus riscos associados. As ações da
equipe devem ser priorizadas de forma relacionada aos riscos. Assim, os itens
de risco mais elevado devem ser gerenciados em primeiro lugar;
.
70 Gerência de Projetos .
 Estabelecer algum nível de formalidade: um gerenciamento eficaz de riscos requer

um processo que seja compreendido e utilizado pela equipe. Isso não 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
gerência de risco configurar-se como de grande dificuldade, a gerência de risco não
ocorrerá de fato. Se o processo não for estruturado, o mesmo não 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 deve garantir que as pessoas-chave sejam efetivamente
envolvidas, e em todos os processos envolvidos com o projeto;
 Buscar a identificação de riscos de forma positiva: para que a gerência de riscos seja
efetiva, os membros da equipe devem estar desejosos de identificar os riscos
sem o medo da punição ou da crítica. A identificação 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.
10.4 Origens dos Riscos

Os riscos podem ser originados de muitas fontes, entre elas:
 Da missão ou dos objetivos do projeto;

 Dos tomadores de decisão, ou do gerenciamento organizacional; Dos clientes ou dos
usuários finais;
 Do orçamento, dos custos, do cronograma e das pessoas envolvidas no projeto; Das
características do projeto;
 Do processo de desenvolvimento ou da cultura organizacional; Do ambiente de
operações da organização;
 De uma nova tecnologia;
 De aspectos legais, governamentais, econômicos, políticos, entre outros.
10.5 Impactos dos Riscos

Os riscos podem afetar um projeto de uma série de maneiras:
 Aumento dos custos e atrasos nos cronogramas;

 Funcionalidade inadequada;
 Projetos cancelados;
 Mudanças súbitas de pessoal ou a desmoralização da equipe;
 Insatisfação do cliente;
 Prejuízo à imagem da companhia; Performance ruim;
 Problemas legais.
10.6 Gestão Pró-ativa de Riscos

A gerência pró-ativa de riscos significa que a equipe de projeto possui um processo visível,
mensurável e repetível para o tratamento dos riscos. Este processo deve identificar,
analisar e endereçar os riscos de forma pró-ativa. Sendo assim, vejamos como seria uma
comparação entre a gestão pró-ativa e reativa de riscos:
Gerência Proativa de Riscos Gerência Reativa de Riscos

Antecipar problemas vs Resolver problemas a medida que os mesmos ocorram
Considerar a raiz dos problemas vs Considerar as consequências dos problemas
Evitar e minimizar os riscos através da mitigação vs Reagir às consequências
Preparar-se para as consequências para vs Reagir a crises
minimizar o impacto
Utilizar um processo estruturado vs Utilizar um processo ad hoc, ou aleatório
10.7 Estratégias para o Gerenciamento de Riscos

 Redução do risco:
 Tentativa de minimizar a probabilidade de que um risco ocorra, ou seja, de
sua causa (condição);
- Ex. Construção de um armazém com materiais à prova de fogo;
- Tentativa de minimizar o impacto do risco, caso o mesmo
venha a ocorrer (consequência);
- Ex. Instalação de extintores de incêndio automáticos.
 Transferência do risco:
 Repasse do risco para outra entidade;
- Ex. Contratação de um seguro contra incêndio (o risco é
repassado para outra empresa);
- Ex. Contratação de pessoal terceirizado para a gerência da
segurança contra incêndio;
 Evitar o risco:
 Eliminar o risco realizando algo menos arriscado;
- Ex. Construir algo menos sujeito a incêndio do que um armazém;
- Ex. Adotar uma tecnologia já provada pelo mercado, ao invés de uma
tecnologia de ponta, ainda sujeita à adesão pelo mercado.
10.8 O Processo de Gerenciamento de Riscos
.
Os passos relativos ao processo de gerenciamento de riscos são os seguintes:
1. Identificação dos Riscos

2. Análise dos Riscos;
3. Elaboração de Planos de Tratamento dos Riscos;
4. Acompanhamento dos Riscos;
5. Controle dos Riscos.
Veremos, a seguir, como se estrutura cada um destes passos.
10.8.1 Identificação dos Riscos

 Trazer os riscos à superfície 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 direções:
- Causas potenciais e suas consequências prováveis;
- Consequências potenciais e suas causas prováveis;
Ex. “Identificação do fogo como um risco potencial a um armazém”;
 Elabore declarações de risco: devem estabelecer de forma e clara e simples a
condição (causa) e a consequência (efeito) de cada risco.
Ex. “Líquidos inflamáveis podem ser mantidos no armazém (causa ou
condição), o que pode provocar incêndio no armazém (impacto /
consequência)”.
Como um exemplo um pouco mais elaborado para o estabelecimento de um

armazém, vejamos como poderemos elaborar diversas declarações de riscos:
Declarações de riscos em relação ao estabelecimento de um armazém

Causa Leva à Conseqüência
Vândalos podem gerar depredação e estragos diversos
Ladrões podem roubar Materiais e dinheiro
Interpéries podem gerar Inundações
Interpéries podem gerar Desabamento
Armazenamento / presença de material inflamável pode acarretar Incêndio
Más condições de armazenamento pode acarretar Incêndio
Mal gerenciamento podem trazer prejuízo financeiro
Má supervisão nos estoques podem trazer perda de produtos (prazo de validade)
Má supervisão nos estoques pode acarretar problemas junto a clientes
Serviços de venda inadequado pode acarretar problemas junto a clientes
... ... ... ... ... ... ... ... ... ... ... ...
Especificamente em relação ao risco de incêndio:

Causa Leva à Conseqüência
Fumantes podem gerar Incêndio
Balões juninos/aeromodelos podem gerar Incêndio
Armazenamento / presença de material inflamável pode acarretar Incêndio
Armazenamento de determinados produtos químicos podem gerar Incêndio
Incidência de raios pode acarretar Incêndio
Sabotadores e vândalos podem gerar Incêndio
Instalações elétricas mal feitas podem gerar Incêndio
... ... ... ... ... ... ... ... ... ... ... ...
A partir de agora em nosso exemplo estaremos nos detendo apenas no tratamento de riscos
vinculados ao caso de incêndio, apenas para facilitar a discussão sobre o gerenciamento de
riscos.
10.8.2 Análise dos Riscos

Converter os dados de risco em informações que a equipe pode utilizar para tomar
decisões (Ex. “Compreensão do que poderia causar fogo em um armazém e o quão
custoso seria o prejuízo causado pelo mesmo”). Uma adequada análise de riscos
compreende as seguintes etapas:
 Avaliação da probabilidade do risco:

 Utilize uma escala numérica para facilitar os cálculos;
 Represente uma escala numérica que seja padrão para todo o projeto (Ex. Alto
= 3 / Médio = 2 / Baixo = 1, ou , Alto = 75% / Médio = 50% / Baixo = 25%);
 Ex. “Devido ao fato que o armazém possui itens inflamáveis, a
probabilidade de um incêndio é alta”
 Avaliação do impacto do risco:

 Também utilize uma escala numérica, de forma a facilitar os cálculos;
 Para impactos financeiros, preferencialmente utilize valores monetários, pois
eles representam melhor tais impactos (Ex. “Impacto do risco = R$
500.000,00”);
.
 Se o impacto é não financeiro, utilize uma escala numérica (Ex. 5, 4, 3, 2, 1);

Não misture as escalas escolhidas;
 Ex. “Se o armazém se incendiar, irá custar R$ 500.000,00 para reconstruí-lo e
repor todo o seu conteúdo”;
 Cálculo da exposição ao risco:

 Exposição = Probabilidade X Impacto;
 Ex. “75% X R$ 500.000,00 = R$ 375.000,00”, ou seja, “O risco de incêndio no
armazém possui uma exposição 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
exposição.
Prosseguindo com a análise de riscos de incêndio em nosso armazém, vejamos como

poderíamos quantificar a probabilidade e o impacto, bem como calcular o grau de
exposição de cada uma das possibilidades:
Análise do risco de incêndio de um armazém

Probabilidade Grau de Exposição (%
# Descrição Impacto
de Ocorrência Risco x Impacto)
1 Incêndio devido à fumantes 3 1 3
Incêndio devido à incidência de balões juninos /
2 1 2 2
aeromodelos
Incêndio devido a armazenamento inadequado
3 3 3 9
de material inflamável
4 2 3 6
de produtos químicos
5 Incêndio devido à incidência de raios 1 3 3
6 Incêndio devido à sabotadores e vândalos 1 3 3
7 Incêndio devido à instalações mal feitas 2 3 6
8 ... ... ... ...
9 ... ... ... ...
Considerando que, quanto maior for o Grau de Exposição a um risco, mais o risco deve ser
considerado, devemos priorizar o tratamento de riscos em função desta variável:
Priorização do tratamento do risco de incêndio (em função do grau de exposição

Probabilidade Grau de Exposição (%
# Descrição Impacto
de Ocorrência Risco x Impacto)
1 3 3 9
de material inflamável
2 2 3 6
de produtos químicos
3 Incêndio devido à instalações mal feitas 2 3 6
4 Incêndio devido à fumantes 3 1 3
5 Incêndio devido à sabotadores e vândalos 1 3 3
6 Incêndio devido à incidência de raios 1 3 3
Incêndio devido à incidência de balões juninos /
7 1 2 2
aeromodelos
8 ... ... ... ...
9 ... ... ... ...
OBS. Notar que a numeração dos riscos foi alterada em função das respectivas priorizações
10.8.3 Elaboração de Planos de Tratamento dos Riscos

 Conversão das informações em decisões;
 Priorização de decisões de planejamento baseadas na prioridade dos riscos;
 Ex. “Planejar como evitar o incêndio em um armazém e o que fazer se isso
ocorrer”;
 Considerar as cinco áreas de atuação chave:
- Pesquisa: você conhece o bastante sobre o risco?
- Aceitação: você pode viver com as consequências do risco? Evitar: Você
pode evitar o risco?
- Mitigação: você pode reduzir a probabilidade ou o impacto do risco?
 Priorizar os riscos de alto grau de exposição;
 Considerar as condições de forma a tentar reduzir a probabilidade;
Enxergar as causas como opostas aos sintomas;
 Considerar as consequências de forma a minimizar o impacto; Existem
2 tipos de mitigação
 Mitigação da Causa: objetiva-se a reduzir a probabilidade de ocorrência
do risco;
 Ex. 1> “A companhia irá instituir uma política de não-fumantes para
reduzir a probabilidade de um incêndio causado por cigarros”;
 Ex. 2> “Realizarmos manutenções periódicas nos sistemas de
fiação elétrica de forma a procurar evitar a incidência de curtos-
circuitos bem como substituir material inadequado”; Mitigação da
Consequência: objetiva-se a reduzir o impacto do risco;
 Ex. 1> “Instalação de extintores de incêndio, bem como esguichadores
de água (sprinkers)
 acoplados a sensores de fumaça”;
 Ex. 2> “Realização de treinamento com a brigada de incêndio, com
testes e simulações, de forma a possibilitar capacitação interna para
ações no caso de incêndio”;
 Contingência: você pode reduzir o impacto através de uma reação planejada?
- Priorizar os riscos de alto grau de exposição; Planejar como reagir às
consequências;
- Os planos de contingência devem ser acionados tanto na iminência do
evento de risco quando após a ocorrência, de fato, do mesmo;
- Devem ser estabelecidas condições para determinar quando executar os
planos de contingência:
 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 não confirmar sua presença até
uma semana antes do evento, então deve-se partir para a
contratação de uma empresa alternativa";
Ex. 2. “Se o atleta XXX não se recuperar da contusão no joelho até 3
dias antes do encerramento do prazo de inscrição no campeonato,
convocaremos o atleta YYY para compor a equipe”;
 Condição-limite: eventos ou fatos que podem ser medidos ou contados:
.
Ex. 1. “A evidência física de incêndio autoriza qualquer pessoa da

empresa a acionar o alarme de emergência e a acionar o corpo de
bombeiros”;
Ex. 2. “Se o tráfego de rede atingir 75% de carga, iniciaremos a
instalação emergencial de antenas extras para suportar as
telecomunicações na região, evitando o congestionamento iminente
das linhas”;
Ex. 3. “Se o fluxo de carros na avenida principal chegar a 500
veículos por minuto, convocaremos os policiais para o controle do
trânsito, de forma a não prejudicar o andamento da obra”;
Dados os riscos de incêndio considerados, como poderia ficar o plano de tratamento

aos riscos em termos de suas ações possíveis? A planilha a seguir apresenta possibilidades:
Plano de tratamento ao risco de incêndio

# Descrição Ação Área de Descrição da Ação Data Condição
do Risco # Atuação Limite Limite (3)
(2)
1 Incêndio devido 1 Pesquisa Informar-se a respeito da inflamabilidade dos
a presença de materiais de estoque
material 2 Pesquisa Informar-se a respeito da inflamabilidade das
inflamável paredes, portas, mobiliário e demais
condições do imóvel
3 Evitar Não armazenar material inflamável nos
estoques
4 Evitar Não utilizar-se de material de construção e
mobiliário inflamável na construção do
armazém
5 Mitigação Substituir mobiliário inflamável / materiais de
(Causa) construção por itens menos propensos a
incêndios (1)
6 Mitigação Solicitar revisões periódicas das instalações
(Causa) junto ao Corpo de Bombeiros
7 Mitigação T reinamento dos funcionários para adotarem
(Causa) cuidados no manuseio de material inflamável
8 Mitigação Acondicionar o material inflamável em local
(Consequência) específico, protegido e isolado (4)
9 Mitigação Instalação de extintores de incêndio,
(Consequência) sensores de incêndio, sprinkers e demais
dispositivos de combate ao fogo
10 Mitigação T reinamento da brigada de incêndio interna,
(Consequência) constituída pelos próprios funcionários
11 Mitigação Afixar quadros de ações práticas, bem como
(Consequência) telefones de emergência, em locais visíveis e
estratégicos, de forma a permitir um rápido
acionamento de providências
12 Mitigação Contratação de seguro contra incêndio
(Consequência)
13 Contingência Acionamento do alarme geral contra Detecção do
incêndios incêndio
14 Contingência Acionamento da brigada de incêndio e Detecção do
bombeiros incêndio
15 Contingência Acionamento da empresa seguradora Até 2 dias
após o
controle do
incêndio
2 Incêndio devido 16 Pesquisa Informar-se a respeito da inflamabilidade dos
a produtos químicos armazenados no estoque
armazenamento (pode ser implementado em conjunto com a
inadequado de ação 1)
determinados 17 Evitar Não armazenar produtos químicos

produtos potencialmente perigosos no estoque
químicos 18 Mitigação Acondicionar material químico suspeito em
(Causa) local fisicamente seguro (pode ser
implementado de forma similar a ação 5
19 Mitigação T reinamento dos funcionários para adotarem
(Causa) cuidados no manuseio de material
quimicamente perigoso (pode ser
implementado conjuntamente com a ação 8)
3 Incêndio devido 20 Pesquisar Informar-se a respeito das condições ideais e
a instalações das condições elétricas do armazém
elétricas mal
feitas
21 Mitigação Realizar revisões periódicas das instalações
(Causa) elétricas do estabelecimento
22 Mitigação Utilizar-se de material elétrico não inflamável
(Causa) e de baixa emissão de calor (esta ação já
poderá estar sendo coberta pelas ações 4
e/ou 6)
23 ... ... ... ... .... .... ....
Legenda:
1. No caso do armazém já estar construído.
2. Este campo é também chamado dead-line, e é utilizado apenas quando se trata de uma ação de
contingência.
3. Este campo é utilizado apenas quando trata-se de uma ação de contingência.
4. Esta ação também poderia ser considerada como Mitigação (Causa), pois poderia pressupor uma
maior disciplina no acesso ao material inflamável, o que minimizaria as chances de incêndio por
uma má administração dos mesmos.
10.8.4 Acompanhamento dos Riscos

 Monitoramento do status dos riscos e de quaisquer ações tomadas para mitigá-los:
 O acompanhamento de riscos deve ser tratado como um exercício contínuo
a ser executado ao longo do ciclo de vida do projeto;
 Os riscos devem ser monitorados em relação a quaisquer mudanças nas
condições ou consequências;
 Devem ser medidos os efeitos dos planos de mitigação;
 As condições para acionamento da contingência devem ser monitoradas
continuamente;
10.8.5 Controle dos Riscos

 Mover o gerenciamento dos riscos para uma atividade diária do gerenciamento de
projetos, o que é crucial para certificar-se de que esta atividade seja considerada de
alta importância para o sucesso do projeto. Para efetivamente controlar os riscos,
deve-se:
 Adaptar as mudanças em termos das prioridades dos riscos; Reagir às
variações do plano;
.
 Responder aos eventos e condições para acionamento dos planos de

contingência aos riscos;
 Avaliar o processo de gerenciamento de riscos;
 Retirar os riscos que tenham sido efetivamente mitigados.
10.9 O Documento de Avaliação de Riscos

Para obter o máximo de benefícios do gerenciamento de riscos, o documento de avaliação de
riscos deve ser utilizado para:
 Priorizar o esforço;
 Orientar as decisões;
 Ressaltar as dependências;
 Determinar cronogramas;
 Gerenciar a orientação a todos os participantes e envolvidos no projeto.
O Documento de Avaliação de Riscos deve conter os seguintes elementos:
 Declarações de risco;
 Cálculos de probabilidades dos riscos; Cálculos da severidade dos riscos; Cálculos da
exposição dos riscos; Planos de mitigação;
 Planos de contingência e suas condições de acionamento específicas; Associação da
responsabilidade pelos riscos.
Deve ser criada uma lista com os Top-10 (os 10-Mais Prioritários):
 É mais interessante e prático limitar o número 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 alterações de prioridade.
Instrumentos para Condução e Desenvolvimento de Projetos 79
11. Instrumentos para Condução e Desenvolvimento

de Projetos
À medida que cada projeto vem sendo desenvolvido de acordo com as fases e
atividades estabelecidas no “Plano de Execução”, 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 gestão do conhecimento envolvido no
desenvolvimento de projetos. Vejamos, pois, algumas delas a seguir.
Instrumentos de Apoio ao Controle de Instrumentos de Apoio à Gestão do

Projetos Conhecimento Presente nos Projetos
 TO-DO Lists  Protótipos
 Lista de Pendências (checklist)  Ambientes de Homologação
 Base de Acompanhamento de Atividades  Projetos-Piloto
 Reuniões de Acompanhamento  Laboratórios
 Roteiros para Entrevistas / Reuniões (scripts)  Benchmarking de Soluções
 Relatórios de Relacionamento com Fornecedores  Fóruns de Discusão / Conhecimento
 Bases Executivas para Acompanhamento de  Relatórios de Eventos
Projetos
 Transferência de Conhecimento por Tradição
 Reuniões de Lições Aprendidas
 Apresentações Executivas
11.1 Instrumentos de Apoio ao Controle de Projetos

Controlar projetos, fases ou tarefas envolve um bom acompanhamento, com instrumentos
que permitam a monitoração daquilo que ficou estabelecido. A relação de
instrumentos e ferramentas a seguir oferece mecanismos para que este controle não se
perca, e objetiva-se a organizar as ações do gerente do projeto no sentido de focalizar o que
é realmente necessário ser feito, com as devidas prioridades para intervenção.
11.1.1 TO-DO Lists

Periodicamente, cada integrante da equipe de um projeto deve estabelecer uma previsão das
atividades que deverão ser executadas, principalmente de acordo com o “Plano de Execução”
do projeto. Idealmente, esta lista de coisas “a fazer” deve conter as prioridades para a
execução bem como uma duração estimada, de forma a possibilitar suas eventuais
estimativas de conclusão.
Podem ser divididas por assunto, o que facilitará o entendimento do trabalho a ser
efetivamente concluído do trabalho já realizado. Em particular, as TO-DO Lists são individuais
e específicas para cada participante de um projeto, e cabe ao gerente do projeto cobrar de
.
todos os envolvidos que “andem sempre com suas listas à mão”, evitando-se perder o foco
do que realmente deve ser feito.
Os TO-DO lists são ferramentas que possibilitam o acompanhamento dos projetos no nível
micro, ou seja, referente às atribuições detalhadas e ordinárias de cada participante da equipe
em particular. Estas tarefas podem variar desde um simples telefonema à configuração
de um equipamento complexo. Algumas das técnicas utilizadas para gerenciamento do
tempo levam à construção de TO-DO Lists adequados para planejamento,
acompanhamento e controle das atividades pendendes individuais.
Vejamos, a seguir, um pequeno exemplo de uma TO-DO List, de um coordenador envolvido

em um projeto de lançamento de um novo curso de pós-graduação lato sensus:
Assunto: Preparar calendário

 Convidar prof. Ricardo – módulo de telecomunicações;
 Documentar informações de disponibilidade dos professores confirmados;

 Verificar disponibilidade de uso laboratório no dia 22/10 para prof. Sérgio;
 Enviar calendário final para a secretaria de pós-graduação; 
Assunto: Questões administrativas:

 Averiguar datas de pagamento e honorários por hora/aula; 
 Distribuir recomendações da coordenação aos professores;
 Acompanhar qualidade da impressão das apostilas para o módulo de Estatística;
 Responder/Encaminhar ao e-Mail do aluno Apolônio, sobre trancamento; 
 Verificar possibilidade de uso do auditório nas aulas do prof. de
Administração Estratégica; 
Assunto: Módulo de Gerência de Projetos

 Revisar apostila;
 Converter apostila para PDF;
 Imprimir e deixar apostila no Xerox;
 Solicitar lista com endereços de e-Mail dos alunos junto à secretaria; 
 Enviar e-Mail com apostila PDF aos alunos;
 Divulgar apostila no site da Escola.
Exemplo: TO-DO List do coordenador de projeto para lançamento de um novo curso de pós-graduação
lato sensu
Note que, no exemplo acima, algumas das atividades já foram concluídas (  ), enquanto
outras ainda estão por ser feitas. Além disso, algumas das atividades estão sublinhadas e em
negrito, o que aponta seu caráter de urgência (prioridade) em relação às demais.
11.1.2 Listas de Pendências (Checklists)

Para cada fase de um dado projeto são discriminadas tarefas e ações esperadas dos
participantes, e estas podem ficar registradas em listas de pendências, 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 condução do projeto. Os Checklists diferem-se das TO-DO Lists nos seguintes termos:
1. São elaboradas e mantidas pelo gerente de projetos;

2. Referem-se às pendências relativas não a somente um dos indivíduos do projeto, mas
as pendências relacionadas a todos os envolvidos;
3. Detalham um pouco mais as complexidades inerentes às fases e atividades previstas
no Plano de Execução, mas não chegam ao nível de detalhamento das TO-DO Lists.
Esta relação de pendências deve listar, além das atividades e tarefas específicas, os
profissionais respectivamente responsáveis pelas mesmas, as áreas e/ou empresas alocadas
para sua execução, as datas de início de desenvolvimento, de previsão de término e de
término efetivo, bem como eventuais informações adicionais.
As listas de pendências devem estar ajustadas com o “Plano de Execução” do projeto, e

as TO-DO Lists nada mais são 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
pendências se “encaixem” nos períodos previstos no “Plano de Execução” de forma a não
impactar nos resultados de cada fase, o que consequentemente também não deverá trazer
riscos às datas de implantação final do projeto como um todo. As Listas de Pendências e
os TO-DO Lists são também conjuntamente denominados “microplanejamento” do projeto.
11.1.3 Bases de Acompanhamento de Atividades

As bases de acompanhamento de atividades são pequenos sistemas de informações
onde devem ser cadastradas as atividades diárias da equipe do projeto. Nesta base, é
permitido que se faça o cadastramento do projeto bem como de suas fases e atividades
associadas. Cada membro da equipe de um Projeto deve, diariamente, entrar com
informações referentes às tarefas desempenhadas no mesmo, discriminando a quantidade
de horas dedicadas a cada uma das Fases e Atividades previstas no “Plano de Execução” do
projeto no qual o mesmo desempenhou funções.
Este instrumento, se corretamente utilizado, oferece a apuração dos períodos efetivamente

trabalhados em cada uma das atividades previstas originalmente no Plano de
Execução. Desta forma, possibilita uma apuração mais adequada do custeio relacionado ao
emprego de homens/hora nas diversas atividades do projeto. Um outro grande benefício
associado à utilização 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 não ao que está previsto para ser desenvolvido, a posteriori.
Contudo, este tipo de ferramenta encontra grande resistência para sua efetiva implementação
por parte dos profissionais envolvidos nos projetos, pois seu preenchimento, além de
tedioso e frustrante, invariavelmente traz a conotação de controle excessivo por parte das
.
chefias funcionais. Portanto, devem ser considerados os aspectos culturais da

organização onde se deseja que esta ferramenta seja implementada.
A seguir, apresentamos um modelo simplificado de uma base de acompanhamento de

atividades, implementado não como um sistema estruturado, mas como uma planilha. Notar
que as atividades hachuradas referem-se a períodos não trabalhados necessariamente no
projeto, mas a tarefas não previstas originalmente ou relativas a feriados, entre outras
situações.
11.1.4 Reuniões 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 Comunicações. Nestas reuniões, o Plano de Execução deve ser
verificado em relação ao que está sendo efetivamente conduzido, e principalmente em
relação às pendências relacionadas nos checklists. No caso de ocorrerem atrasos,
imprevistos, incidentes, ou alterações de curso, gerando ampliações ou reduções no escopo
do projeto, o Plano de Execução deverá ser revisto, e todos os fatos e eventos relacionados
às eventuais mudanças devem ser devidamente documentados.
As Reuniões de Acompanhamento devem envolver a verificação dos motivos que levaram

aos possíveis atrasos, bem como levantar as alternativas de correção de rumo, além do
preparo da argumentação que leve a novas negociações referentes a prazos e custos a

serem tratados junto ao corpo diretivo da organização. A freqüência destas reuniões não deve
ser muito baixa de forma a possibilitar eventuais perdas de foco ou falta de informações
comuns a toda a equipe, nem tampouco muito freqüentes de forma a não tirar a
produtividade do time. Caberá ao gerente de projetos definir os melhores momentos para
a promoção das reuniões de acompanhamento.
11.1.5 Roteiros para Entrevistas/Reuniões (Scripts)

Ao agendar reuniões ou entrevistas, tanto internas quanto com áreas cliente ou com
fornecedores externos, seja presencialmente, seja via telefone ou vídeo-conferência, é
muito importante estabelecer a priori quais serão as questões a serem tratadas em
cada evento. Os roteiros, ou scripts, são instrumentos muito úteis para dar eficácia a cada
encontro, economizando tempo e agregando real valor às decisões a serem efetivamente
tomadas pelos envolvidos. Idealmente, seu teor deve ser divulgado com alguma antecedência
em relação à data de realização do evento, permitindo aos convidados que se prepararem
adequadamente para o mesmo. Esta ferramenta possui especial importância sobretudo em
reuniões com grande número de participantes, onde a objetividade é um fator-chave.
A elaboração 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 elaboração dos roteiros pode ser elaborada em conjunto
com profissionais mais experientes, e que não necessariamente estejam alocados à
equipe de projeto. Isso pode garantir objetividade na elucidação de pontos mais críticos
e um maior entendimento dos desafios e problemas a serem superados pelos participantes
de cada evento.
11.1.6 Relatórios de Relacionamento com Fornecedores

Em projetos que contam com grande número de fornecedores, é imperativo que se mantenha
um controle sobre o que tem sido comunicado e repassado a cada um deles, seja em
reuniões, seja por telefone, FAX ou e-Mails, por exemplo. Em uma concorrência, a
lisura e imparcialidade do processo depende de que todos os fornecedores obtenham o
mesmo nível de informação divulgada, de forma a oferecerem propostas mais completas e
adequadas aos objetivos e metas esperados.
Sendo assim, os relatórios de relacionamento com interações com o fornecedor, ou com

altos níveis de detalhamento, em que são registradas as datas, horas e nomes das pessoas
contatadas, o instrumento utilizado (FAX, e-Mail, telefone, etc.), entre outras informações
relevantes. Seu objetivo principal é o de “policiar” o gerente de projetos no sentido de
manter-se imparcial e no contínuo esforço de fazer com que todos os fornecedores
concorrentes tenham chances e informações iguais para sua participação nas
concorrências conduzidas ao longo do projeto.
.
Uma outra aplicação 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
resolução de problemas operacionais, o relato das interações ao longo do tempo pode
apontar os eventuais gargalos e falhas no atendimento às soluções solicitadas junto aos
parceiros, o que pode estimular a convocação dos mesmos para que aperfeiçoem seus
processos de atendimento em favor do bom andamento do projeto.
11.1.7 Bases Executivas para Acompanhamento de Projetos

Para que se realize um acompanhamento estratégico de cada um dos projetos da
organização, deve ser criada uma área comum, onde os executivos possam consultar
e tomar conhecimento dos estágios onde os projetos se encontrem. A Base de
Acompanhamento de Projetos é um instrumento gerencial estratégico, oferecendo uma visão
macro sobre o desenvolvimento dos projetos da empresa.
Esta base de dados comum deve fornecer, idealmente, informações referentes à cada projeto
em particular, em níveis de detalhamento progressivos, contemplando os atributos do
projeto em geral. Entre outros elementos, poderíamos sugerir que fossem colocados nesta
base de informações os documentos principais do projeto (Relatório Executivo, Plano de
Execução, Documento deAvaliação de Riscos, checklists, Relatórios de Acompanhamento
de Fornecedores, etc.), breves resumos da situação do projeto por semana/mês, breve
resumo de resultados já atingidos e dos que estão por vir, breve resumo dos problemas
enfrentados e das soluções desenvolvidas, entre outros aspectos e relatórios técnicos
necessários, e que compõem toda a documentação produzida ao longo do ciclo de vida do
projeto.
A partir desta base de informações, é possível conhecer-se, a qualquer momento, qual é a

situação corrente de cada projeto, bem como o histórico de ações executadas num
nível macro, permitindo uma visão executiva relativa ao mesmo de forma sucinta e
abrangente. Efetuando pesquisas nestas bases podem ser verificados, por exemplo,
quais são os projetos em atraso, ou quais projetos de alta prioridade estão 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 (concluído), branco
(não iniciado / demanda reprimida), entre outros.
A análise da situação global sobre a base de projetos permite uma constante monitoração das
direções e do desempenho dentro do qual a empresa se posiciona, suportando atividades e
decisões de nível estratégico com mais agilidade. Além disso, como esta base agrega
informações de todos os projetos da organização, é possível que ela se ofereça como fonte
permanente de “aprendizado” em relação aos projetos já realizados, balizando novos
empreendimentos junto às experiências já vivenciadas anteriormente.
Entretanto, para que esta ferramenta se mostre efetiva, é importante que haja uma
forte disciplina na inserção de conteúdo na mesma. Além disso, é fundamental que sejam
implementados mecanismos eficientes de recuperação de informações e de conhecimentos
nestas bases, sob pena de se acumularem grandes estoques de conhecimento sem, no
entanto, que se obtenha a “liquidez”
necessária na recuperação das informações necessárias. Existem diversas ferramentas de
groupware que permitem a implementação destas bases executivas para acompanhamento
de projetos.
Contudo, deve-se atentar e buscar definições e implementações robustas para a garantia da

segurança no acesso e na recuperação de informações destas bases por parte dos seus
usuários, pois todo o expertise da organização estará contido na mesma, e os segredos
comerciais estabelecidos em projetos estratégicos estarão ali armazenados.
11.2 Instrumentos de Apoio à Gestão do Conhecimento

Presente nos Projetos
Definir gestão do conhecimento parece ser algo simples, uma vez assumidas as distinções
entre os conceitos de dado, informação e conhecimento. No entanto há uma grande
diversidade de conceitos referentes à gestão do conhecimento, sobretudo devido ao fato de
que a mesma ainda é muito recente. A gestão do conhecimento é um processo
interativo de criação do conhecimento organizacional, sendo definida como “a capacidade
que uma empresa tem de criar conhecimento, disseminá-lo na organização e incorporá-lo a
produtos, serviços e sistemas”.
Sendo assim, as ferramentas a seguir se propõem a maximizar os processos de

geração, codificação e transferência 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 benefícios-chave são vinculados a estimular e fortalecer as
estruturas formais e informais de conhecimento, favorecendo a produtividade e as curvas
de aprendizado em novos projetos.
11.2.1 Protótipos
Grandes projetos demandam que suas respectivas soluções sejam implantadas
modularmente, de forma extensível. Preferencialmente, devem haver testes que ajustem
as funcionalidades das soluções implementadas e antecipem problemas potenciais. Um
protótipo é a materialização de uma proposta de solução, e não necessariamente precisa ser
funcional, ou seja, não precisa ser utilizável, de fato. Um protótipo deve ser empregado
não como uma solução acabada e pronta para ser implementada, mas para permitir que se
façam questionamentos acerca da proposta que está sendo, através dele, concretizada. Em
outras palavras, protótipos não apresentam as soluções, mas apenas propostas, permitindo
que eles próprios sejam desafiados em termos de sua futura viabilidade funcional e
operacional.
.
Protótipos são poderosos instrumentos de levantamento de informações quanto ao

funcionamento e às expectativas de solução mantidas pelas áreas usuárias e executivas
envolvidas. Podem ser descartados quando não tiverem mais necessidade, ou podem
evoluir no decorrer do projeto, apresentando novas alternativas para o desenvolvimento
das soluções buscadas pelo mesmo.
São exemplos de protótipos os carros-conceito, automóveis que não necessariamente

se tornam produtos fabricados em série, mas para permitir que especialistas e leigos
discutam sua viabilidade, bem como seus conceitos-chave, ali materializados. Outros
exemplos de protótipos são maquetes de construções, programas de computador que
realizam simulações de uma obra concluída, e as chamadas “bonecas”, que são
simulações de uma solução final, utilizadas apenas para efeito de validar, junto aos seus
clientes e usuários, os conceitos que procuram representar.
11.2.2 Ambientes de Homologação

Deve ser estruturado, sempre que possível, um ambiente a ser empregado para os
testes da nova solução, onde muitos dos erros e problemas que seriam encontrados apenas
em um ambiente real de produção poderão ser verificados antecipadamente, e suas
alternativas de correção estudadas e prontamente implementadas. Um ambiente de
homologação é particularmente importante na implantação de soluções baseadas em
tecnologias muito novas, cujos riscos de implementação somente podem ser conhecidos
após extensivos testes em situações muito próximas ao contexto real em que serão ofertados
na prática. Em diversas situações, a homologação de uma solução também é chamada
“prova de conceito”.
Neste caso, devem ser montados ambientes que reproduzam fielmente o ambiente real
de produção, para que as soluções desenvolvidas sejam exaustivamente provadas
anteriormente à sua implantação definitiva. Os erros, problemas e nuances
verificados devem ser devidamente registrados para consultas futuras, o que minimizaria
a reincidência dos mesmos, além de otimizar seu tratamento corretivo.
Um bom exemplo são os sistemas de automação bancária que, em grandes instituições, são
estruturados ambientes de homologação equivalentes a “agências de mentirinha”,
adequadas ao estudo e reprodução do ambiente real das agências fisicamente
estabelecidas pela instituição financeira. Outro exemplo de um ambiente de
homologação são os chamados “apartamentos decorados”, em que os prováveis
compradores de um imóvel 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
construído. Nesta linha, poderíamos citar as empresas de veículos que permitem que
seus clientes façam um test-drive nos modelos de veículos colocados à venda, onde o cliente
pode experimentar um tipo de carro como se fosse seu próximo veículo.
Outros exemplos para ambientes de homologação são algumas vacinas testadas em cobaias
não-humanas. Neste caso, os animaizinhos serão continuamente monitorados de forma
a se avaliarem os efeitos colaterais, a eficácia e a eficiência dos novos medicamentos. Caso
algo errado aconteça, a cobaia pode ser sacrificada, ou mesmo ter seu sofrimento e
reações profundamente estudados, permitindo-se contínuos aperfeiçoamentos na solução
desenvolvida (quando os testes passam a ser realizados em seres humanos estaremos
tratando de projetos-piloto, que veremos adiante).
Algumas empresas de software oferecem cópias Beta, ou Alfa, de seus programas de

computador ao público especializado, de forma a solicitar sugestões, críticas ou
considerações em relação ao produto em fase final de construção. Neste caso, não se
recomenda que o produto seja utilizado em ambientes reais de produção pois, como trata-se
de cópias de homologação, as mesmas ainda não se encontra dentro de níveis adequados de
estabilidade para implantação em ambientes reais de produção de missão-crítica.
Deve-se prestar especial atenção quanto às diferenças entre o conceito de protótipo e

de ambiente de homologação. Um protótipo é a materialização de uma proposta, ou seja,
ainda está no campo da idéia, do conceito (ainda que já em um estágio bastante
amadurecido de desenvolvimento). Um ambiente de homologação, por sua vez, reproduz
fielmente o ambiente real, de produção, e possibilita que a solução final já desenvolvida seja
continuamente testada, corrigida, avaliada e, enfim, aprovada para implantação definitiva.
11.2.3 Projetos-Piloto
Mesmo realizando testes em ambientes de homologação, o ambiente real, de
produção, sempre apresenta variáveis (grande parte delas, intangíveis) jamais passíveis
de antecipação e simulação. Por exemplo, um determinado tipo de teste, o de stress, em
que um grande número de acessos simultâneos deve ser simulado de forma a se
permitir a análise do comportamento da solução implementada, somente pode ser
realizado em um ambiente real de produção.
Por causa disso, devem ser programadas implantações iniciais em ambientes reais, e
que contemplem um universo crítico controlável. Os ambientes nos quais os projetos-
piloto são implementados devem apresentar uma diversidade significativa de situações de
forma a se permitir o acompanhamento do comportamento da nova solução do ponto de vista
de seu usuário final. Da mesma forma que nos ambientes de homologação, aquilo que for
percebido como de significativa relevância passa a ser adequadamente documentado para
posterior reaproveitamento, ou seja, para avaliação, análise, e efetiva correção e ajustes.
É importante apontar a principal diferença entre os ambientes de homologação e os

de projeto-piloto. Os ambientes de homologação são restritos a testes e validações
circunscritas ao ambiente interno da organização; os projetos-piloto já são soluções
disponibilizadas em ambientes reais de produção. Neste último caso, todo o cuidado deve ser
tomado em relação à condução dos testes em piloto, pois aí já estarão envolvidos os
clientes da empresa, a imagem da instituição, e sobretudo, a credibilidade do projeto como
um todo. Em outras palavras, os projetos-piloto somente podem ser lançados quando já se
possui grande certeza quanto aos resultados que serão atingidos, não sendo permitidas
situações do tipo “tentativa-e-erro”.
.
Os projetos-piloto são indicados quando os investimentos finais são muito altos para
um Roll-out da solução por completo, e os riscos associados podem se tornar muito elevados
caso haja alguma indisponibilidade ou falha nos novos serviços e produtos a serem
oferecidos.
São exemplos de projetos-piloto os testes de vacinas em cobaias humanas, a

disponibilização de determinados produtos e serviços em pequenas cidades, ou para
grupos reduzidos de clientes, entre outros.
11.2.4 Laboratórios
Idealmente, deve ser possível a montagem de uma infra-estrutura a ser empregada para os
testes de uma nova solução, sobretudo permitindo-se que este ambiente seja montado e
desmontado quantas vezes necessário. O objetivo principal da construção de um laboratório
é a realização de experiências com novas tecnologias, testando e avaliando
funcionalidades, restrições, conceitos e características de tecnologias ainda não
dominadas pela organização. No entanto, seus custos podem ser proibitivos. Nestes
casos, pode ser que um ambiente de laboratório se pague conforme o montante e a
criticidade de um projeto, ou de forma a tornar possível que suas instalações possam ser
reutilizadas em projetos futuros.
Os laboratórios podem evoluir para ambientes de homologação, mas jamais para projetos-
piloto, pois estes últimos são considerados ambientes de produção. Contudo, o que
difere um laboratório de um ambiente de homologação é a estabilidade deste último,
pois os laboratórios permitem que se façam alterações e mudanças a qualquer tempo,
enquanto que os ambientes de homologação são estáveis, e evoluem conforme também
evolui o ambiente de produção, junto dos quais os ambientes de homologação devem se
manter como cópias fiéis.
11.2.5 Benchmarking de Soluções

Muitas vezes, é necessário que a equipe do projeto “veja com seus próprios olhos”
os resultados alcançados em outras organizações a respeito da utilização de
tecnologias, produtos e serviços específicos. Dessa forma, e sempre que for viável, devem
ser realizadas visitas técnicas em outras empresas, usuárias de soluções similares às
que serão implantadas nos projetos em desenvolvimento, para aprender in loco como
as tecnologias e os esforços institucionais foram associados para obtenção de sucesso,
naqueles casos.
Quando não for possível o agendamento de visitas técnicas, pode-se tentar entrevistas em
que devem ser objetivamente abordados os pontos mais críticos encontrados pelos
terceiros na implementação das nuances encontradas em seus projetos específicos.
Damos o nome de benchmarking de soluções à verificação, análise e avaliação de conceitos

e soluções em empresas ou setores que os implementaram com significativo sucesso.
Este aprendizado e as conclusões a que se pode chegar pode se tornar até mesmo um
fator crítico de sucesso para o próprio projeto interno em andamento.
Em muitos dos casos, o aprendizado maior pode se basear não nos aspectos específicos da
tecnologia escolhida, mas em aspectos como os que estão vinculados à gestão de sua
implantação, considerando fatores principalmente focados no lado cultural e
humano das organizações envolvidas.
Em outras palavras, detalhes normalmente não considerados do ponto de vista

estritamente técnico podem se tornar itens determinantes para o sucesso de projetos
como, por exemplo, a integração com sistemas e ambientes legados, ou a carência de
técnicos e empresas especializadas em suporte técnico na mesma região dos clientes da
solução do projeto, ou relativo a aspectos culturais da organização (como resistências
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 mantém uma estrutura muito distribuída
geograficamente.
De particular importância, os benchmarkings de solução devem ser enfatizados quando da

avaliação de fornecedores em projetos. Nestes casos, a concorrência entre
fornecedores pode ser decidida em algumas visitas a outros clientes dos mesmos, na busca
de soluções similares às que serão desenvolvidas no projeto interno em questão.
11.2.6 Fóruns de Discussão/Conhecimento

Cada tema, tendência ou assunto, seja de origem técnica como de natureza organizacional,
tanto de foco e escopo internos como externos à organização, podem ser discutidos através
deste instrumento, que pode ser implementado tanto virtualmente quanto presencialmente.
A implementação virtual deste instrumento pode ser realizada através de listas de
discussões, sendo que, em muitos casos, as mesmas podem estar abertas a
comunidades externas à própria organização.
Presencialmente, é importante estimular ciclos de palestras internos, de preferência

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 técnicos como, por exemplo, o “Novidades em Telecomunicações” ou

“Transações Eletrônicas na Internet”, ou mais específicos como “Balanced Scorecard”,
“Logística de Serviços” e “Gerência de Projetos”, ou de escopo não técnico como
“Mercado Financeiro”, “Projeto de Vida” ou “Voluntariado” podem ser debatidos através de
ferramentas de groupware ou de Intranet, ou mesmo em reuniões e palestras programadas.
.
O objetivo, neste caso, é criar um universo de interação 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 implementação, pois a obrigatoriedade ou

o excesso de formalismo em sua participação pode destruir estas redes de conhecimento,
minando sua existência. É muito claro que os principais integrantes destas redes
invisíveis de pessoas, cujas dimensões ultrapassam as fronteiras das organizações, são
pesquisadores e estudiosos voluntários, auto-estimulados por um aprendizado contínuo e
constante, e fazem parte destas agremiações informais comumente chamadas
“comunidades de prática”. Se, por um lado, não se deve “matar” as comunidades de prática, é
um grande passo reconhecer sua existência, e fomentar seu crescimento e desenvolvimento
sem, no entanto, “sufocá-las”.
11.2.7 Relatórios de Eventos

Após cada visita, curso, congresso, seminário ou outros eventos nos quais os colaboradores
de uma organização 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 interação por parte dos demais colaboradores.
Tais documentos podem ser disponibilizados para toda a empresa, por exemplo, nos Fóruns
de Discussão/Conhecimento, em bases de discussão virtuais, ou em ciclos de
palestras e treinamentos internos. Deve ser estimulada a participação de outros
colaboradores no sentido de oferecerem sugestões, comentários e críticas às
tecnologias e conceitos apresentados, bem como apresentando novas fontes de
informação sobre o mesmo assunto ou sobre tópicos relacionados, desta forma
enriquecendo o acervo de conhecimentos gerados após cada evento.
Em particular, sugere-se que o tempo gasto para a produção destes documentos-resumo não
ultrapasse 20% da duração total do evento. Assim, caso um profissional tenha participado de
um treinamento cuja duração tenha sido de 40 horas, recomenda-se que o mesmo dedique
um máximo de 8 horas para a produção de um documento ou palestra que o
sumarize de forma adequada e palatável para o público-alvo.
11.2.8 Transferência de Conhecimento por Tradição

Um dos aspectos mais críticos na elaboração de cada projeto é o “como faremos
para dominar a tecnologia a ser empregada de forma rápida e satisfatória?”,
principalmente quando devem ser contratados serviços e produtos de terceiros. A
presença da equipe de projetos em treinamentos e seminários é importante, sem
dúvida, mas leva tempo para que o conhecimento baseado na prática, ou seja, na
experiência 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
instalação de ferramentas de software, ou a operação dos equipamentos que serão
utilizados, ou mesmo acompanharem os trabalhos dos terceiros nas metodologias
empregadas por eles de forma a propiciar a transferência de conhecimento por tradição.
Por exemplo, em um determinado projeto, pode ser necessário o desenvolvimento de

programas de computador que utilizem uma determinada linguagem e ferramentas até
então desconhecidas por parte da empresa. Neste caso, programadores da empresa
contratada para desenvolver os aplicativos da solução projetada poderiam deslocar-se
para as dependências da organização contratante, permitindo que a equipe do projeto
possa presenciar, aprender e questionar a construção dos novos programas nas novas
ferramentas, o que poderia traduzir-se em um aprendizado mais produtivo.
É importante observar que este tipo de ferramenta não substitui o treinamento convencional,
mas amplia as possibilidades de fortalecimento do aprendizado, sobretudo considerando
que a prática verdadeiramente ensina, tornando o conhecimento mais duradouro e perene.
11.2.9 Reuniões de Lições Aprendidas

Ao concluir-se um projeto ou uma fase importante, ou mesmo após a resolução de algum
problema mais crítico, é importante que se realizem reuniões que tratem do assunto sob o
ponto de vista de se trocar informações acerca das experiências vivenciadas. Estas
reuniões devem contar com a imprescindível presença de todos os envolvidos no evento ou
fato.
Devem ser ponderados os resultados obtidos e avaliada a conduta estabelecida nas

tarefas conduzidas para a realização da fase/projeto, ou para a resolução do problema
vencido. As irregularidades, os incidentes e falhas, os inconvenientes e erros, bem como a
qualidade do conhecimento adquirido, os níveis de motivação e empenho investidos devem
ser abertamente discutidos.
Não cabe, nestas reuniões (como em nenhuma outra), apontar culpados, mas sim os
empecilhos, falhas e virtudes encontrados no processo. Deve-se procurar sugestões para
melhorias futuras, levantar as perdas e os ganhos pessoais e corporativos, discutir
fatores positivos e negativos, tangíveis e intangíveis que ocorreram durante o
desenvolvimento da fase/projeto/
problema.
O objetivo geral é oferecer possíveis mudanças de rumo, abrir perspectivas, disseminar

e compartilhar uma valiosa massa crítica de experiência 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 relação à adoção destas reuniões, sobretudo no que toca aos
gerentes de projeto. Neste caso, reuniões de lições 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 não
solicitados, estendendo suas críticas a atitudes de gerentes funcionais e de projeto. Enfim,
esta atividade deve ser encarada como um exercício de humildade e sabedoria para todos os
seus participantes.
11.2.10 Apresentações Executivas

Sempre que possível, deve-se levar ao conhecimento da empresa, principalmente de
seus executivos principais e gerentes médios, os resultados obtidos na conclusão 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
níveis de sucesso organizacional eventualmente conquistados.
Em segundo lugar, oferece aos participantes da equipe do projeto a oportunidade de serem,

de fato, reconhecidos, de alcançarem mérito por seus esforços junto àqueles que
efetivamente patrocinam suas atividades e empreendimentos internos.
Em terceiro lugar, permite que a empresa valide a abordagem de desenvolvimento de
soluções voltada para a gerência de projetos, mesmo se esta já tiver ampla
divulgação e sedimentação interna, pois ratifica uma alternativa de infra-estrutura
metodológica que permita gerenciar iniciativas, viabilizar empreendimentos e concretizar
oportunidades reais de negócio.
Enfim, e não menos importante, estes eventos podem trazer, através da interação com
os executivos-chave, a visibilidade do que é considerado de “alto valor” para os mais altos
escalões, possibilitando o vislumbre de novas possibilidades, de novas abordagens para o
desenvolvimento de soluções futuras, aprendendo e conhecendo quais serão os novos
projetos que, certamente, valerão a pena ser desenvolvidos brevemente.
Isso tudo é o que os executivos, ou os clientes, poderão nos dizer, enquanto

estivermos “apresentando” os resultados de nossos projetos a eles.
Bastará estarmos dispostos a escutá-los.

Avaliação e Escolha de Fornecedores 93
12. Avaliação e Escolha de Fornecedores

Para a viabilização de soluções, em não raras vezes devem ser contratados serviços
especializados de fornecedores externos, sejam estes como consultores que
apoiem a implementação do projeto, sejam estes como os próprios implementadores
do todo ou de partes específicas do projeto. Existem também os fornecedores de
suprimentos necessários à execução de projetos.
Para que os fornecedores sejam adequadamente consultados, suas propostas

devidamente avaliadas e, enfim, que os mais adequados à organização e ao projeto
sejam devidamente escolhidos, sugerimos o seguinte roteiro:
1. Estabelecimento de Critérios de Avaliação;

2. Solicitação de Propostas;
3. Realização da Avaliação;
4. Elaboração do Relatório de Recomendação;
5. Contratação dos Parceiros Escolhidos.
Naturalmente, após a contratação dos fornecedores para a realização do todo ou de parte do

projeto, existe o gerenciamento da atuação dos mesmos, como a administração de contratos
(tanto em termos de sua execução quanto em termos de seu encerramento), a
alocação de recursos e materiais contratados e adquiridos e a desmobilização dos mesmos
ao término de uma fase ou do projeto como um todo. Entretanto, neste capítulo iremos nos
dedicar aos cinco passos apresentados acima.
Vejamos, com maior detalhe, cada um dos tópicos deste roteiro.
12.1 Estabelecimento de Critérios de Avaliação

Em primeiro lugar, devem ser levantados os itens e aspectos a serem procurados nos
fornecedores a serem contatados. Estas definições estão distribuídas em 3 tipos:
1. pré-requisitos, áreas de avaliação;

2. categorias;
3. quesitos de pontuação.
12.1.1 Definição de Pré-Requisitos

Devem ser verificados pré-requisitos a serem obrigatoriamente atendidos pelo
fornecedor candidato. Tais pré-requisitos são condição imprescindível para que um
fornecedor seja qualificado como participante potencial do processo de avaliação. Por
exemplo, poderíamos ter como pré-requisito “um fornecedor que seja certificado ISO
.
9002 na sua área de atuação”, ou que “sua solução para um sistema CRM inclua o
tratamento de CTIs (Centrais Telefônicas Inteligentes)”, ou ainda que o fornecedor “ofereça
alternativa de integração com os atuais sistemas de Call Center e Help Desk já implantados
na organização”.
Em alguns projetos, pode ser que alguns dos pré-requisitos façam menção explícita a uma
determinada linha de produtos, ou mesmo que considerem níveis de serviço específicos a
serem oferecidos como, por exemplo, a “disponibilização de um suporte técnico telefônico
24 x 7, nos primeiros 6 meses após a implementação do projeto”. A não observância de um
Pré-requisito implica em desclassificação imediata da empresa candidata a fornecedora
do projeto.
Para ilustrarmos nossas idéias quanto ao desenvolvimento desta seção, consideremos

o seguinte exemplo: uma organização necessita adquirir um veículo, e para isso gostaria de
conduzir um processo de avaliação idôneo e imparcial junto às principais
concessionárias às quais possui acesso. A seguir, apresentamos uma relação de pré-
requisitos que os fornecedores devem atender, em termos da solução demandada:
Aquisição de veículo – Pré-Requisitos

1 Deve ser um veículo novo
2 Deve ter 4 portas
3 Deve ser movido a gasolina
4 Deve ser produzido no Brasil
12.1.2 Áreas de Avaliação

Para que se avaliem soluções oriundas de diversos fornecedores, suas propostas devem ser
analisadas segundo critérios de avaliação bem definidos. Idealmente, tais critérios
devem cobrir, pelo menos, quatro grandes áreas de avaliação, quais sejam, áreas técnica,
financeira, comercial e mercadológica.
 Área Técnica: refere-se ao atendimento da empresa aos critérios técnicos

demandados pela solução. Deve fazer referência tanto às funcionalidades da nova
solução no que tange à demanda do negócio quanto às tecnologias subjacentes
que a suportem. Pode referenciar-se à metodologia utilizada para o desenvolvimento
da solução, à modularidade dos produtos a serem disponibilizados, à qualidade
da documentação oferecida, aos níveis de segurança e auditoria implementados,
às características de compatibilidade, portabilidade, disponibilidade e
acessibilidade com outros sistemas, áreas e produtos da empresa contratante, entre
outros aspectos técnicos específicos;
 Área Financeira: refere-se ao “quanto custará” a nova solução. Neste caso, a

avaliação financeira não deve contemplar apenas o valor absoluto da nova solução
mas, idealmente, deve apresentar o custo por funcionalidade atendida. Uma boa
alternativa para o nivelamento das propostas é a avaliação do custo de um “pacote
básico” composto por um conjunto determinado de atributos e, para tópicos
adicionais, a discriminação de seus valores respectivos em separado. Esta área de

avaliação deve considerar todos os aspectos financeiros da solução a ser
contratada como, por exemplo, as condições e opções de financiamento, as taxas
de juros envolvidas, custos indiretos, depreciação, taxa de retorno do investimento,
entre outros;
 Área Comercial: refere-se ao “comportamento” dos fornecedores no que tange

ao atendimento às necessidades e solicitações das soluções do projeto. Nesta área,
devem ser verificados os serviços básicos e agregados relacionados à solução
contratada ou aos fornecedores das mesmas. Devem ser verificados aspectos como
a estrutura de suporte de pré-venda e de pós-venda, garantias, redes de assistência
técnica, qualidade das informações apresentadas ao longo do processo de
avaliação, experiências anteriores de sucesso e de fracasso da empresa candidata,
seja internamente à organização contratante, seja em outras organizações, presteza,
agilidade, flexibilidade e iniciativa na apresentação e disponibilização de propostas,
produtos e resultados, potencial de implantação da nova solução nos termos e
requerimentos do projeto, entre outros aspectos.
Por exemplo, se um determinado fornecedor não retorna com agilidade as ligações

telefônicas que lhes são dirigidas, não retorna rapidamente solicitações de
esclarecimentos e dúvidas quanto às soluções as quais representa, não entrega
suas propostas técnico-financeiras conforme os prazos previamente estipulados, ou
apresenta propostas com informações truncadas, pouco claras, pouco
elucidativas e de forma a não considerar a importância devida do projeto assim
como o mesmo é considerado pela organização contratante, entre outros
fatores, isso tudo o tornaria pouco apto a ser considerado como um forte
candidato à oferta da solução demandada. Uma boa forma de avaliação do
fornecedor neste aspecto é verificar, junto a outros de seus clientes, seu
comportamento ao longo de projetos similares nos quais os mesmos tenham tido
participação efetiva (benchmarking);
 Área Mercadológica: neste tipo de avaliação, os fornecedores devem ser

verificados quanto ao seu posicionamento em relação aos parceiros, concorrentes
e aos nichos de mercado em que atuam. Questões como aderência a padrões de
mercado e a tecnologias-chave específicas, qualidade das parcerias estabelecidas,
observância às tendências tidas como mais significativas, fatias de mercado
ocupadas por seus produtos e serviços, curva de crescimento na adoção de suas
soluções por parte de parcelas e segmentos relacionados com o negócio da
organização contratante, situação financeira da organização (análise de balanços),
capacidade de atendimento em larga-escala (quando for o caso), presença no
território nacional, presença no mercado internacional, entre outros itens, são
importantes indicadores de que o fornecedor avaliado estará bem ou mal posicionado
mercadologicamente para o atendimento da solução oferecida para a organização
contratante. Em outras palavras, podemos considerar que a avaliação mercadológica
se refere ao atendimento do fornecedor quanto a uma visão macro de seus mercados
e clientes, enquanto que a avaliação comercial posiciona-se em aspectos
particulares, ou seja, voltada às especificidades dos clientes num âmbito individual.
.
12.1.3 Categorias, Quesitos de Pontuação, Níveis de

Conformidade e Pesos
Para realizar uma avaliação idônea e isenta, devem ser preparados formulários de avaliação,
que gerarão as planilhas e gráficos onde os resultados serão demonstrados. Sugere-se, para
isso, a criação de categorias de avaliação para cada área de avaliação (técnica /
financeira/comercial / mercadológica), com um posterior desdobramento das mesmas em
quesitos a serem devidamente pontuados.
Cada um dos quesitos de pontuação deve conter, internamente, níveis de conformidade, que
discriminarão a aceitação, a não aceitação ou a aceitação parcial do quesito, em relação ao
seu atendimento às necessidades apresentadas. Ainda, podem ser atribuídos pesos à cada
uma das categorias de avaliação, de forma a ponderar-se índices mais elevados onde for
dada maior relevância quanto aos respectivos quesitos de avaliação das soluções
candidatas.
É muito importante que todos os elementos escolhidos para a realização de uma avaliação
possam ser, de alguma maneira, avaliados em uma escala coerente (quesitos de
pontuação). Naturalmente, um excesso de itens de pontuação pode trazer dificuldades para a
seleção do melhor fornecedor, além de que os mesmos podem não se revelar significativos
para os objetivos a que se prestem.
Pré-Requisitos, Áreas de Avaliação, as Categorias, Pesos e Quesitos de Pontuação

de uma Solução de Fornecedor
Em nosso exemplo de aquisição de um veículo, vejamos como podem ser elencadas

as categorias em termos de cada uma das áreas de avaliação propostas:
Aquisição de Veículo – Categoria de Avaliação

Área de Avaliação Categoria
Técnica Desempenho
Segurança
Conforto
Design
Opcionais
Financeira Condições de financiamento
Custos por opcional
Taxas e outros custos
Comercial Atendimento pré-vendas
Serviços oferecidos
Mercadológica Posicionamento da empresa no mercado
Posicionamento da montadora no mercado
Posicionamento do veículo no mercado
Uma vez estabelecidas as categorias de avaliação, cabe-nos elaborar o que será, de

fato avaliado em cada uma das categorias (quesitos de pontuação), como cada um dos
quesitos deverá ser valorado (níveis de conformidade) e, enfim, atribuir-se graus de
importância (ou pesos) a cada uma das categorias de avaliação (em alguns casos, podem ser
atribuídos pesos também aos quesitos de avaliação).
Vejamos como ficaria nosso instrumento de avaliação, para o exemplo hipotético de

avaliação de veículos de diversas empresas:
.
12.2 Solicitação de Propostas
12.2.1 Elaboração das Solicitações de Propostas

(RFP – Request for Proposal)
Como serão solicitadas as propostas junto aos fornecedores de forma a tomar-se contato com
suas respectivas soluções? Em primeiro lugar, deve ser solicitada uma proposta técnico-
financeira a cada um dos fornecedores que se deseja contactar. O documento gerado
a partir desta etapa denomina-se RFP (Request for Proposal – ou Solicitação de
Proposta Técnico-Financeira, ou Requisição Formal de Proposta).
Ele deve ser claro e conciso, devendo discriminar de forma não ambígua o que está sendo
requerido, quais tópicos, características e documentos que deverão ser apresentados,
qual será o formato em que as respostas às solicitações deverão ser oferecidas e
quanto custará a solução final, este último item geralmente devendo ser desdobrado o
máximo possível, de forma a permitir comparações 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 período realista para a elaboração das propostas por parte dos
fornecedores, de forma a atender os níveis de detalhamento demandados pela equipe do
projeto.
É natural que ocorra significativa interação entre a organização e os seus

fornecedores concorrentes, após a entrega do documento de RFP, pois muitas dúvidas
poderão surgir quanto ao entendimento do mesmo. Nestes casos, todo e qualquer
documento, FAX ou e-Mail enviado a qualquer um deles também deverá ser enviado a
todos os demais, simultaneamente e, sempre que possível, com a formalização da
confirmação de recebimento. Este procedimento tem por finalidade garantir-se a lisura e a
imparcialidade na condução do processo de avaliação e seleção de fornecedores.
Uma recomendação importante quanto à solicitação 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 não a determinados requisitos.
Por exemplo, ao invés de se solicitar aos fornecedores candidatos respostas à

questão “utiliza o padrão de mercado X para o desenvolvimento da solução?”, uma
abordagem melhor seria “quais os padrões de mercado serão utilizados para a
implementação da solução?”. Neste tipo de abordagem, o fornecedor deve detalhar suas
respostas de forma a deixar clara sua forma de implementação, ficando a avaliação
destes méritos a cargo da equipe do projeto.
11.2.2 O Recebimento das Propostas Técnico-Financeiras

Após o envio das RFPs, a equipe do projeto deve aguardar a entrega da primeira versão das
propostas técnico-financeiras. Esta primeira versão geralmente não contempla totalmente o
que foi solicitado pelas RFPs, no que se refere aos níveis de clareza e detalhamento
demandados pela equipe do projeto. Muitos itens podem ter que ser melhor explorados, além
de que o formato das propostas entregues podem não seguir ao que foi estipulado pela RFP,
.
o que pode vir a dificultar o estudo e a análise das propostas de cada um dos fornecedores
potenciais.
Além disso, é costume que ocorra o seguinte fato: alguns fornecedores, visualizando
possibilidades de oferta de novas funcionalidades às suas soluções, acrescentam
novas características às mesmas, ampliando assim as opções solicitadas através da
RFP. Pode ainda ocorrer que, na apresentação de propostas, algumas
funcionalidades normais dos produtos oferecidos apresentem-se como novidade para os
avaliadores das soluções candidatas.
Dependendo das condições técnicas 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 então
solicitados, desta vez voltados às novas características de solução a serem contempladas.
O objetivo, nesta etapa específica, é o de nivelar as propostas de todos os fornecedores,
evitando-se o problema serem avaliadas soluções que ofereçam características distintas.
Nesta etapa intensifica-se a interação entre a organização contratante e os

diversos fornecedores candidatos, de forma a serem solicitadas novas versões das
propostas para que se façam os devidos esclarecimentos e detalhamentos necessários,
seja quanto ao que foi solicitado pela RFP original, seja quanto ao que pedem as RFPs
complementares.
ATENÇÃO! A etapa de “Estabelecimento de Critérios de Avaliação” não necessariamente

precisa anteceder a etapa de “Solicitação de Propostas”. Em alguns casos, as
propostas são solicitadas anteriormente ao estabelecimento de critérios de avaliação. Em
qualquer caso, contudo, recomenda-se que não se passe para a etapa de “Realização da
Avaliação” sem antes estarem bem definidos todos os critérios de avaliação a serem
empregados.
12.3 Realização da Avaliação

Uma vez que todas as propostas niveladas tenham sido entregues, inicia-se o processo
de avaliação das mesmas. Naturalmente, devem ser analisados apenas os fornecedores que
estejam em total acordo com os Pré-Requisitos previamente estabelecidos. O não
atendimento aos mesmos implica em desclassificação imediata dos fornecedores em
respectivo desacordo.
Após esta primeira filtragem, é efetivamente realizada a avaliação de cada uma das propostas
entregues, pontuando os quesitos já definidos em termos dos níveis de conformidade
estabelecidos previamente. Vejamos, logo a seguir, algumas recomendações para a
avaliação dos diversos quesitos, conforme sua área de avaliação correspondente.
11.3.1 Avaliação Técnica

Para a pontuação das categorias e quesitos técnicos, o método mais direto é através
da análise das próprias propostas, que funcionam como uma espécie de contrato de
prestação de serviços. Além disso, pode ser que sejam verificados outros instrumentos, como
apresentações dos fornecedores, sites da Internet que se referem aos produtos ou a
componentes da solução oferecida, literatura especializada, entrevistas com especialistas,
entre outras fontes. No entanto, é importante ressaltar que somente o que estiver explicitado
numa proposta de solução de um fornecedor é que poderá ser considerado para efeito de
pontuação, pois este é o único instrumento formal que oficialmente os compromete a
realizar o que está sendo solicitado.
Alguma exceção pode ser feita no que tange, por exemplo, a tecnologias de apoio às
soluções demandadas. Por exemplo, supondo que esteja sendo avaliada uma solução
de ERP (Enterprise Resource Planning – ou ferramenta de gestão integrada), e
também estejam sendo avaliados os sistemas operacionais a serem disponibilizados nos
servidores (por exemplo, Microsoft Windows 2000, NOVELL Netware ou HP-UX).
Neste caso, a avaliação das funcionalidades da categoria “sistemas operacionais de

servidor” poderiam ser melhor verificadas em relatórios produzidos por entidades ou
publicações especializadas, ou mesmo através de entrevistas com especialistas muitas
vezes existentes na própria organização contratante (neste último caso, deve-se tomar
cuidado para não se deixar levar pelos argumentos apaixonados dos “xiitas
tecnológicos”, que defendem vertentes tecnológicas como uma religião, fechando os olhos
para outras alternativas igualmente viáveis).
12.3.2 Avaliação Financeira

Para a pontuação dos quesitos das características financeiras, sempre que possível devem
ser produzidos valores baseados em cada “módulo” da solução a ser entregue, de
forma a permitir comparações de itens que sejam similares entre os diversos
fornecedores. Desta forma, pode-se perceber quais seriam os módulos mais caros, e
destas informações poderiam sugerir abordagens mais eficientes nas negociações de preços
finais. Além disso, devem ser apresentados resumos que contemplem os valores totais a
serem investidos pela organização contratante, preferencialmente em planos de desembolso
mensais.
É importante observar que alguns fornecedores apresentam seus custos baseados em

homens/hora, enquanto que outras apresentam seu preços em termos de valores finais.
Deve-se tomar muito cuidado com as soluções baseadas em horas, pois podem estourar os
orçamentos no médio 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 solução.
.
Podem ser avaliadas condições de pagamento, formas de parcelamento e/ou financiamento,

possibilidade de contratação de módulos parciais, ao longo do tempo, entre outras
condições financeiras específicas.
12.3.3 Avaliação Comercial

Na avaliação dos aspectos comerciais, deve-se tentar, o máximo possível, contactar outros
clientes das soluções entregues, de forma a obter deles depoimentos verdadeiros
referentes ao processo de implementação das soluções por parte dos fornecedores
avaliados.
Estas entrevistas podem ser realizadas nas próprias instalações dos clientes bem como
via telefone ou vídeo- conferência, 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 informações importante em relação à avaliação de categorias da

área comercial pode ser os depoimentos de colaboradores que tenham tido
experiências (felizes e infelizes) em outras organizações, onde os fornecedores candidatos
tenham prestado seus serviços. Porém, devem ser verificadas questões éticas e
baseadas em opiniões pessoais tanto neste caso quando por ocasião da realização
das visitas e entrevistas com demais clientes dos fornecedores potenciais.
Nestes casos, muitos dos critérios de avaliação podem ser percebidos subjetivamente, ou
seja, baseados unicamente nas visões específicas de outros colaboradores e clientes,
e não necessariamente baseados em fatos efetivamente verdadeiros.
A avaliação comercial, num aspecto mais objetivo, também 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 presença de sites para
oferta de serviços e documentação de apoio, entre outros aspectos, conforme os itens já
apontados na sub-seção “Áreas de Avaliação”.
12.3.4 Avaliação Mercadológica

A avaliação mercadológica refere-se, exclusivamente, a análise do fornecedor e/ou de suas
soluções sob um ponto de vista macro. Neste caso, organismos independentes e
publicações especializadas poderiam oferecer importantes dados relativos ao market-share
da empresa/solução nos mercados regionais, nacionais ou internacionais, bem como as
taxas de crescimento de ocupação destes espaços. Sendo possível, deve-se utilizar o setor
financeiro para uma avaliação das empresas fornecedoras sob o ponto de vista
contábil/econômico, divulgado através de seus balanços periodicamente publicados.
Assim que os instrumentos de avaliação estejam devidamente preenchidos, o registro

das avaliações será efetivamente produzido. Tais resultados devem ser devidamente
tabulados e, dentro dos critérios definidos anteriormente, devem ser indicados os
fornecedores que tenham vencido o processo. Após isso, deve ser produzido um relatório
executivo de recomendação da solução, para apreciação do corpo decisório da organização
contratante.
12.4 O Relatório de Recomendação

A partir dos resultados oferecidos pela avaliação deve-se produzir um relatório dirigido aos
níveis executivos da organização. Este relatório deve compôr-se, basicamente, de duas
partes. A primeira, a recomendação propriamente dita, deve ser concisa, sumarizando a
escolha realizada, com um breve resumo das pontuações obtidas em termos macro, os
custos totais e ponderações mais gerais sobre cada uma das soluções
apresentadas, nos aspectos técnicos, financeiros, comerciais e mercadológicos.
Como trata-se de um documento executivo, não pode ser muito extenso, contendo um
número adequado de páginas para leitura especificamente por parte dos tomadores de
decisão da organização contratante, mas também não pode ser extremamente sucinto, pois
isso pode levar à perda de credibilidade em relação à consistência das
escolhas e recomendações oferecidas.
Para facilitar o entendimento do investimento a ser realizado no projeto, idealmente é

recomendável a elaboração de um plano de desembolso mensal, discriminando gastos com
pessoal, obras, software, equipamentos, materiais, suprimentos, serviços, taxas e impostos.
Desta forma, é possível realizar o planejamento financeiro dos investimentos necessários,
além de permitir a visualização do orçamento final ao longo do tempo.
A segunda parte do Relatório de Recomendação refere-se aos seus anexos. Nesta parte,
cabe toda a documentação produzida pela equipe do projeto, como as atas de reunião, os
desdobramentos da avaliação, enfim, todos os detalhes que fizeram parte do processo como
um todo. Na verdade, dificilmente alguém irá ler todas as suas páginas, mas as mesmas
prestam-se como referências ao que está sumarizado na primeira parte do Relatório de
Recomendação, suportando-o e dando-lhe subsídios para um entendimento mais
pormenorizado do processo.
Duas considerações devem ainda ser feitas em relação ao Relatório de Recomendação.

A primeira é quanto à organização da primeira parte. Executivos preferem conhecer os dados
macro em primeiro lugar, para depois irem questionando seus detalhes. Isso significa que, a
recomendação das soluções vencedoras devem vir o quanto antes possível neste
relatório, seguidas pelos seus custos e prazos totais (estes tópicos preferencialmente
apresentados de forma sumarizada na primeira página do documento), e deixando
outras considerações e informações para as páginas posteriores.
Além disso, os executivos podem demandar que determinadas informações sejam

acrescentadas ou informadas em formatos diferentes, o que leva a equipe do projeto a um
.
período intenso de modificações no formato final do Relatório de Recomendação, o que pode

levar a várias interações num breve período de tempo, gerando novas e freqüentes versões
deste documento.
A segunda consideração ocorre quando existe o chamado “empate técnico”, ou seja, quando
duas ou mais empresas fornecedores apresentam soluções igualmente eficientes e a
custos muito competitivos entre si. Além disso, podem ainda ocorrer discrepâncias
quanto às funcionalidades oferecidas por cada fornecedor em potencial, tornando a
recomendação final mais complexa, pois se estaria considerando situações distintas, ou seja,
não niveladas.
Por exemplo, considere o caso em que um dos fornecedores ofereça uma solução
mais “enxuta” e, consequentemente, menos dispendiosa, enquanto que um outro pode
apresentar uma solução mais “robusta” e, por sua vez, mais cara. Ou ainda, uma
empresa fornece a solução de forma a implementá-la nas instalações da empresa
contratante, enquanto que outra oferece o serviço que atende à solução, porém
implementando-o internamente. Nestes casos, podem ser realizados cenários ou
simulações, prevendo evoluções possíveis com cada uma delas e seus impactos
técnicos, financeiros e operacionais envolvidos (como prazos, recursos, capacitação técnica,
infra-estrutura administrativa, entre outros aspectos).
A decisão final neste caso (e como sempre será em todos os outros) deverá recair para
o corpo decisório da organização, que certamente levarão em alta conta as
opiniões e posicionamentos da equipe do Projeto. De qualquer maneira, a equipe do
Projeto deverá sempre recomendar uma única solução, mesmo que os executivos e clientes
optem por outras alternativas ou linhas de ação.
12.5 Contratação dos Parceiros Escolhidos

Uma vez escolhido o fornecedor, pode ser que a solução oferecida por este último demande
muito mais recursos do que o originalmente previsto no início do projeto (ou do
processo de avaliação). Esta conclusão é parcialmente justificável, pois as previsões
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 avaliação de fornecedores e de soluções.
Neste caso, o projeto corre o risco de ser suspenso, ou colocado em uma situação de
inviabilidade, o que interromperia seu processo de implementação, muitas vezes por
longos e indefinidos períodos. Por isso é que se torna importante uma boa estimativa
inicial de parâmetros e recursos para o projeto no momento de seu planejamento inicial, o
que aumentaria sua chances de ser aprovado neste estágio de desenvolvimento.
Um outro aspecto importante a ser verificado quanto a esta possibilidade é que

projetos anteriormente desenvolvidos têm muito a acrescentar em termos da experiência
vivida por suas equipes respectivas, oferecendo uma grande massa crítica que poderia ser
utilizada para evitarem-se novos erros na previsão dos recursos de projetos em curso.
Sendo assim, é sempre muito saudável o envolvimento de profissionais mais

experientes na estimação de prazos e custos logo no início de projetos, apoiando na
inferência de durações e valores de forma a minimizar desvios muito significativos.
Caso o projeto seja aprovado após o exame do corpo diretivo sobre o Relatório de
Recomendação, pode ser que os diretores da organização contratante desejem
negociar com os fornecedores condições específicas de pagamento ou na oferta de produtos
e serviços.
É importante ressaltar que, a não ser quando for delegado ao líder de projetos, que o mesmo
resista à tentação de entrar em negociações diretas com os fornecedores candidatos quanto
aos seus valores financeiros finais. Normalmente, os níveis de autoridade dos gerentes
de projeto são limitados no que se refere à negociações com fornecedores externos. Some-
se a isso o fato de que a utilização de técnicas mais agressivas de negociação de forma a
trazer condições efetivamente mais vantajosas para a organização contratante é,
normalmente, um privilégio de altos executivos.
Técnicas de negociação podem ser melhor utilizadas pelo pessoal de outras áreas da
empresa como, por exemplo, os gerentes das áreas usuárias, ou pelo pessoal dos
setores de compras, ou mesmo, como já citado, pelos próprios executivos principais da
empresa. Em geral, um líder de projetos também não possui autonomia para oferecer
contra-propostas aos fornecedores potenciais.
Um líder de projetos pouco experiente em técnicas de negociação pode “minar” o

relacionamento da empresa com os prováveis fornecedores, inviabilizando diálogos futuros ou
até mesmo ferindo a imagem da organização perante o mercado. além de que poderiam
haver sérias dúvidas quanto à aquisição de condições realmente vantajosas para a
organização contratante, intermediadas por este profissional.
Após todos os acertos finais, os fornecedores devem ser contatados pelo pessoal específico
da organização para a aquisição e contratação dos produtos e serviços correspondentes,
encerrando- se, assim, o ciclo de contratação dos parceiros de negócio específicos.
Deve-se ressaltar, contudo, que a gerência dos contratos, dos recursos e profissionais
de terceiros, do nível de qualidade dos produtos e resultados disponibilizados pelos
fornecedores, é responsabilidade inerente aos gerentes de projetos, mesmo que ele
próprio tenha delegado tais atribuições a outros setores e profissionais da organização.
.
1
Elementos para Análise de Projetos 107
13. ELEMENTOS PARA ANÁLISE DE PROJETOS

Apresentamos agora noções básicas sobre a análise de projetos de investimento. A
apresentação enfatiza a análise em condições de ausência de incerteza a respeito da
composição dos fluxos de caixa dos projetos. Ao final, apresentamos uma breve discussão
sobre a incorporação de incerteza na análise de investimentos e programas de computador
que podem implementar os procedimentos sugeridos.
O quadro apresentado a seguir introduz alguns conceitos fundamentais utilizados ao longo do

capítulo.
A análise de projetos é o conjunto de procedimentos utilizados para

avaliação e comparação de projetos alternativos fundamentados em
princípios econômicos básicos.
Um projeto nesse contexto seria representado pelos benefícios e

custos associados, por exemplo, a compra de um equipamento, a
instalação de uma indústria, etc.
Como fase preliminar ao processo de avaliação e análise de projetos é necessário o computo

de estimativas dos desembolsos e receitas (chamados de “custos” e “benefícios” nesse
contexto) que deverão ocorrer ao longo da vida útil do projeto, uma tarefa que pode ser
relativamente complexa em muitos casos. É através dessas estimativas que é gerado o
cronograma financeiro do projeto com o respectivo fluxo de caixa, que é o insumo principal
necessário ao processo de análise.
O fluxo de caixa de um projeto, representado pela seqüência F i, é a

diferença entre os benefícios (receitas em geral), representada por
Bi, e os custos (desembolsos em geral, representado por Ci, onde i =
0, 1, 2, ..., n, que identifica cada período do projeto, ou seja:
Fi = Bi – Ci, i = 0, 1, 2, ...., n
A nível ilustrativo, vejamos agora os exemplos a seguir:
Máquina para Prestação de Serviços

Suponha que se deseja avaliar um projeto de investimento em um equipamento A, que se
destinará à prestação de serviços por um período de 10 anos. O custo do equipamento no
início do período o é de 1.000 UM, e se espera que a receita líquida anual (valor dos serviços
menos o custo operacional desembolsado) recebida ao final de cada período (ou início do
.
período subseqüente) pela prestação de serviços será de 100 UM. Ao final do décimo ano o
equipamento será vendido como sucata pelo valor de 200 UM. Apresente uma tabela
contendo o fluxo de caixa deste projeto.
Período Fluxo
i Bi Ci Fi
0 0 1.000 -1.000
1 100 0 100
2 100 0 100
3 100 0 100
4 100 0 100
5 100 0 100
6 100 0 100
7 100 0 100
8 100 0 100
9 100 0 100
10 300 0 300
Investimento em um Título
Suponha que se deseje avaliar a aplicação de 1.000 UM em um título no período zero, que
promete o pagamento de 1.600 UM ao final do quinto ano de aplicação. Apresente o fluxo de
caixa.
Período Fluxo
i Bi Ci Fi
0 0 1.000 -1.000
1 0 0 0
2 0 0 0
3 0 0 0
4 0 0 0
5 1.600 0 1.600
Os últimos dois exemplos apresentam uma situação comum no contexto da análise de

projetos de investimento. Nos dois projetos o investidor dispõe de 1.000 UM para aplicação no
período 0. No primeiro projeto o retorno do investimento se fará através da receita líquida
anual propiciada pela prestação de serviços utilizando uma máquina adquirida com os 1.000
UM. No segundo projeto, o retorno se dará no 5 ano pelo pagamento de um valor
estabelecido no título adquirido. A análise de investimentos oferece uma metodologia prática
para que o investidor possa selecionar qual desses 2 projetos seria o mais vantajoso para a
aplicação de seus recursos (no caso 1.000 UM).
A análise de projetos de investimento considera a elaboração de indicadores associados ao

desempenho econômico do projeto calculados a partir de seu fluxo de benefícios e custos
medidos em unidades monetárias. A idéia é a de que esses indicadores possam expressar,
diretamente em seu valor numérico, o valor econômico do projeto, simplificando, dessa forma,
uma possível situação complexa de análise. Uma vez calculados os indicadores de cada
projeto disponível o investidor poderia, por exemplo, ordená-los de uma forma tal que os
projetos mais atrativos poderiam ser selecionados facilmente.
• A análise em condições determinísticas é a estratégia mais

comumente utilizada para a avaliação de projetos e pressupõe
conhecimento exato do projeto, o que é uma simplificação do
problema real.
• A análise em condições de risco é mais realista e possibilita a
incorporação do conhecimento incerto a respeito das variáveis que
irão compor o fluxo de caixa do projeto com o auxílio de
distribuições de probabilidades.
A ordenação resultante da utilização isolada de um indicador pode ser questionada em

algumas situações quanto a sua validade no que diz respeito à consistência com os princípios
da racionalidade econômica. De uma certa forma, cada um dos indicadores usualmente
utilizados está relacionado a uma dimensão do projeto, a qual pode não ser facilmente
percebida pelo simples exame do fluxo de caixa desse projeto.
• Um indicador de desempenho de um projeto é um índice calculado

a partir do fluxo de caixa que tenta medir uma determinada
dimensão da qualidade do investimento.
• Indicadores usualmente utilizados: relação benefício-custo, valor
atual do fluxos líquidos do projeto (VPL), payback simples (prazo
de recuperação do capital), payback econômico, custo total
atualizado e taxa interna de retorno.
13.1 Indicadores de avaliação

Os principais indicadores de avaliação de projetos de são examinados nas próximas seções.
Para análise das qualidades e limitações associadas a cada indicador, utilizaremos os
projetos de investimento identificados com as letras A a F apresentados no quadro introduzido
a seguir. Os benefícios (Bi) e custos (Ci) associados ao fluxo de caixa de cada projeto são
listados para cada período i.
Período i Projetos
A B C D E F
Bi Ci Bi Ci Bi Ci Bi Ci Bi Ci Bi Ci
0 0 10 0 1000 0 100 0 100 0 100 0 100
1 5 3 500 300 110 0 55 0 120 0 0 0
2 10 3 1000 300 0 0 60,5 0 0 0 134 0
3 10 3 1000 300 0 0 0 0 0 0 0 0
.
Os valores dos indicadores associados a cada um dos projetos, que consideram em alguns
casos duas taxas de juros diferentes a título de custo de oportunidade para os recursos
utilizados, são apresentados no próximo quadro:
Projetos
Indicador Juros
A B C D E F
Benefício-custo (RBC) 10% 1,16 1,16 1,00 1,00 1,091 1,107
Benefício-custo (RBC) 12% 1,14 1,14 0,98 0,97 1,071 1,068
Valor Atual (VA) 10% 2,86 286,25 0,00 0,00 9,090 1-,743
Valor Atual (VA) 12% 2,35 234,85 -1,79 -2,66 7,142 6,823
Payback Econômico 10% 3,00 3,00 1,00 2,00 1,000 2,000
Payback Econômico 12% 3,00 3,00 - - 1,000 2,000
Payback Simples - 3,00 3,00 1,00 2,00 1,000 2,000
Taxa Interna de Retorno (TIR) - 23,08 23,08 10,00 10,00 20,00 15,76
13.1.1 Relação benefício-custo (RBC)

A relação benefício-custo (RBC) de um projeto é definida por:
n
Bi
∑(1 + j) i
i=0
RBC = n
Ci
∑(1 + j) i
i=0
Onde Bi é o benefício do projeto em unidades monetárias no ano i, Ci é o custo do projeto em

unidades monetárias no ano i e j é a taxa de juros correspondente ao custo de oportunidade
do capital.
O indicador RBC é muito utilizado e de interpretação relativamente fácil em comparação a

outros indicadores, entretanto, apresenta diversas limitações, dentre as quais se destaca a
insensibilidade à escala e à duração projeto. Ademais, a obtenção desse indicador depende
da fixação “a priori'' de um custo de oportunidade para ser utilizado como taxa de desconto
dos fluxos, o que em geral, pode se realizar com algum grau de arbitrariedade.
Comparando-se os projetos A e B na tabela apresentada ao fim da última seção, verifica-se

que ambos tem uma RBC de 1,16, obtida à 10%. Isso indicaria que seriam equivalentes aos
olhos do investidor; entretanto, se esses projetos fossem mutuamente exclusivos existiriam
muitos investidores que poderiam preferir o projeto B ao projeto A. Na realidade, o projeto B é
o próprio projeto A no qual os benefícios e custos foram multiplicados por um fator de escala
de valor 100, o que mostra a insensibilidade do indicador RBC à escala do projeto.
Comparando-se, agora, os projetos C e D pode-se verificar a insensibilidade do indicador

RBC à duração do projeto. Possuindo a mesma RBC (10%) de valor 1,00, os projetos C e D
deveriam ser equivalentes. Isso pode não ser verdadeiro para muitos investidores, os quais
podem preferir o projeto C como o melhor, por recuperar mais rapidamente o capital e os
rendimentos.
A dependência da RBC à escolha da taxa de desconto é evidenciada na comparação dos

projetos E e F. À taxa de 10% o projeto F, com RBC de valor 1,107, seria mais atrativo que o
projeto E, que apresenta sua RBC de valor 1,091. Se a taxa de desconto considerada fosse a
de 12%, a situação se inverteria ficando o projeto E, agora com uma RBC de valor 1,071, em
posição mais favorável que a do projeto F que apresentaria uma RBC de valor 1,068.
A rejeição de projetos pela RBC pode ser realizada comparando-se o valor do indicador
obtido ao custo de oportunidade do capital com a unidade. O projeto seria descartado por
esse critério caso se verifique a condição:
RBC < 1
13.1.2 Valor atual dos fluxos líquidos (VA)

O valor atual dos fluxos líquido de um projeto (VA) é obtido por:
n
Bi - Ci
VA = ∑(1 + j) i
1=1
Onde Bi é o fluxo de benefícios do projeto em unidades monetárias, C i é o fluxo de custo do

projeto em unidades monetárias e j é a taxa de juros correspondente ao custo de
oportunidade do capital.
O indicador VA é, do ponto de vista teórico, em condições estritamente deterministas, o mais

consistente dos indicadores disponíveis. Contudo, tem também deficiências e limitações e,
sobretudo, é de difícil interpretação.
O VA não apresenta insensibilidade à escala do projeto, como acontece com a RBC, o que
pode ser verificado no quadro que descreve os projetos A a F previamente apresentado,
comparando-se as VAs dos projetos A e B.
Com respeito à duração do projeto e à sensibilidade à taxa de desconto, o VA apresenta as

mesmas limitações observadas para a RBC. Comparando-se os projetos C e D pode-se
verificar que o VA de ambos tem o valor 0,0 à taxa de 10%, sugerindo sua equivalência. Em
tópico anterior discutiu-se que essa equivalência entre os projetos C e D pode não ser aceita
por alguns investidores.
O aspecto da dependência à escolha da taxa de desconto pode ser avaliado na comparação

dos projetos E e F. À taxa de 10% o projeto F, com o VA de valor 10,74, seria preferível ao
projeto E, que apresenta um VA de valor 9,09. À taxa de 12%, essa situação irá se inverter.
Nesse caso, o projeto E registrará uma VA de valor 7,14 e o projeto F uma VA de valor 6,82.
.
O descarte de projetos através do VA pode se processar comparando-se o valor do indicador

obtido no projeto, ao custo de oportunidade do capital, com o valor zero, sendo rejeitado o
projeto caso se verifique:
VA > 0
É interessante salientar que o VA e a RBC são afetados diferentemente pela alteração na

taxa de desconto. Se considerarmos, por exemplo, um projeto G e H descritos no próximo
quadro:
Projetos
Período i G H
Bi Ci Bi Ci
0 0 10.065 0 15.100
1-10 1.500 0 2.200 0
Os projetos G e H apresentam os seguintes indicadores:
Indicador Juros Projetos

G H
Benefício-custo (RBC) 6% 1,10 1,07
Valor Atual (VA) 6% 975,13 1.092,19
Benefício-custo (RBC) 7% 1,05 1,02
Valor Atual (VA) 7% 470,37 351,88
Pode-se verificar nesse quadro que à taxa de desconto de 7% o projeto G seria preferido ao
projeto H, tanto pelo critério do VA como pelo critério da RBC que seriam, respectivamente
470,37 e 351,88, e, 1,05 e 1,02. À taxa de desconto de 6% o projeto H seria mais atrativo que
o projeto G pelo critério do VA. Pelo critério da RBC o resultado seria o oposto, com o projeto
G sendo mais atrativo que o projeto H.
13.1.3 Payback simples (PBS) e econômico (PBE)

O payback simples não leva em consideração o valor do dinheiro no tempo, sendo seu cálculo
determinado por:
k k -1
PBS = K, tal que ∑ Fi ≥0 e ∑F < 0 i
i- 1 i=0
O payback econômico (PBE) considera a dimensão do dinheiro no tempo, sendo o seu

cálculo:
k k -1
Fi Fi
PBE = K, tal que ∑(1 + j) i ≥0 e ∑(1 + j) i <0
i- 1 i=0 i
Caso estas condições não sejam satisfeitas, diz-se que o projeto em questão não tem
payback simples ou econômico, respectivamente.
O “payback” ou prazo para recuperação do capital é um indicador voltado à medida do tempo

necessário para que um projeto recupere o capital investido. É aplicável, sem restrições, a
projetos convencionais de investimento que apresentem um fluxo de caixa com as seguintes
características:
F0 < 0 e Fi > 0, i =1, 2, 3, ....., n
onde Fi é o fluxo de caixa no ano i definido por Bi - Ci, os fluxos de benefícios e de custos dos
projetos.
Em projetos onde ocorrem múltiplas mudanças de sinal no fluxo de caixa líquido, a obtenção
do PB deve ser realizada com cautela, assim como sua interpretação, para que os resultados
sejam consistentes.
Mesmo sendo um indicador com muitas limitações o “payback” pode ser útil como indicador
auxiliar no processo de análise. Essa utilidade é demonstrada ao se comparar os projetos C e
D descritos previamente. Enquanto os indicadores RBC e VA apresentam os dois projetos
como equivalentes à taxa de desconto de 10% o PBE apresenta um valor de 1 para o projeto
E e um valor de 2 para o projeto F. Isso significa que o capital investido no projeto E retornará
em um período e, no projeto F, em dois períodos, o que pode ser uma vantagem para o
primeiro projeto para alguns investidores.
Para descarte de projetos o indicador PB também pode ser utilizado. Um projeto seria
descartado por esse indicador quando não for possível recuperar o capital dentro da vida útil
do projeto.
É necessário salientar que PB é um indicador de características intrinsecamente auxiliares,

voltado à medida da dimensão tempo de um projeto.
13.1.4 Taxa interna de retorno (TIR)

A taxa interna de retorno é definida por:
n
Bi - Ci
TIR = j, tal que ∑(1 + j) i =0
1=1
.
Onde Bi é o fluxo de benefícios do projeto em unidades monetárias, C i é o fluxo de custo do

projeto em unidades monetárias e j é a taxa de desconto.
Dentre todos os indicadores mais utilizados a TIR é aquele que, ao primeiro exame, aparenta
apresentar as menores limitações. Isso se deve, possivelmente, a independência de
informações exógenas ao projeto para a sua obtenção. Em particular, não depende da
definição “a priori'' de um custo de oportunidade do capital para sua elaboração, como ocorre
nos casos dos outros indicadores considerados.
Todavia, essa vantagem é apenas aparente, pois a TIR somente será um indicador
consistente, em uma situação em que um investidor que dispuser de um capital para
aplicação de valor K, tendo como alternativas de investimento projetos mutuamente
exclusivos, não puder aplicar o valor residual de seu capital inicial após o investimento no
projeto escolhido, o que é uma situação bem pouco realista. Em alguns casos, os resultados
da aplicação do critério TIR são absolutamente incoerentes, como ocorre no projeto I, que
apresenta o seguinte fluxo de caixa líquido, definido para os períodos 0 e 1:
F0 = 100 e F1 > -90
A TIR desse projeto que é -10%, tornaria, à primeira vista, inviável sua seleção quando
comparado a qualquer projeto com TIR positiva. Entretanto, basta uma rápida inspeção no
fluxo de caixa para se perceber que o projeto é altamente viável (corresponde a uma situação
na qual toma-se 100 unidades monetárias no período 0 para pagamento de apenas 90
unidades monetárias no período 1).
A análise dos projetos E e F apresentados previamente permite constatar outras limitações da

TIR quando comparado ao VA por exemplo. Pelo critério da TIR o projeto E (TIR = 20,00%)
seria preferido ao projeto F (TIR = 15,76%) ; contudo, se o custo de oportunidade considerado
for de 10,0 %, o critério do VA apresentaria o projeto F como preferido ao projeto E.
Uma justificativa para a escolha do projeto F resulta da análise do fluxo de caixa dos projetos.
O investimento nos dois projetos é idêntico e igual a 100 unidades monetárias. O projeto E
apresenta seu benefício de 120 unidades monetárias no período 1 e o projeto F apresenta
seu benefício de 134 unidades monetárias no período 2. É fácil verificar que à taxa de 10%
(custo de oportunidade do capital considerado) o valor do benefício recebido no projeto E de
120 unidades monetárias, no período 1, representaria um valor de 132 unidades no período 2,
valor inferior ao obtido pelo projeto F no período 2.
Uma outra dificuldade na utilização da TIR como indicador está associada à possibilidade de
ocorrência de múltiplas TIR para um mesmo fluxo de caixa. Ou seja, para alguns fluxos de
caixa existirá mais de uma TIR que atenda à definição desse indicador.
O descarte de projetos através da TIR pode ser realizado comparando-se seu valor com o do
custo de oportunidade do capital. Caso o valor da TIR (positivo) de um projeto seja inferior ao
valor do custo de oportunidade do capital, então esse projeto será descartado.
Pelo algebrismo do cálculo da taxa de retorno, podem-se obter múltiplas taxas, bastando,
para isso, haver mais de uma inversão de sinal dos fluxos de caixa, ao longo dos anos. Isso
poderá ocorrer quando, após o investimento inicial, haja necessidade de expansão, ou
melhorias substituições de equipamentos ao longo da vida do projeto. Quando se utiliza
simulação (Monte Carlo) de fluxos de caixa, o fenômeno antes descrito também poderá
ocorrer, pelas flutuações dos valores aleatórios.
Um projeto que apresente comportamento bem previsível, no entanto, com investimentos no

início de sua vida e receitas líquidas positivas ao longo de sua duração, não apresentará
problemas na aplicação do método da TIR.
Suponha um projeto que possua o seguinte fluxo de caixa:
Ano Fluxo de Caixa

0 -1.600
1 10.000
2 -10.000
Existem duas inversões de sinal no fluxo de caixa. Verifica-se o seguinte comportamento para
o VPL, variando-se a taxa de desconto:
Múltiplas TIR
1.000
500
0
0%
25%
50%
75%
150%
225%
300%
375%
450%
VPL(i)
500
1.000
1.500
2.000
Taxa de Desconto
Nesse caso, portanto, existem duas taxas internas de retorno: 25% e 400% ao ano.
Dependendo do valor inicial tentativo, alimentado na função financeira do Excel TIR, encontra-
se uma ou outra. Se for 10%, encontra-se TIR = 25%. Se for 410%, encontra-se TIR = 400%.
Os valores da TIR podem ser calculados manualmente, também.
13.1.5 Custo total atualizado

O custo total atualizado (CTA) ou valor presente do projeto é definido por:
.
n
Ci
CTA = ∑(1 + j) i
1=1
Onde Ci são os custos do projeto no ano i e j é custo de oportunidade do capital.
O CTA pode ser um indicador útil para medir a escala do projeto, ou seja, a ordem de
grandeza dos recursos envolvidos no investimento global necessário para a implementação
do projeto. Assim como o PBS e PBE, o CTA é um indicador de características auxiliares que
permite ao investidor detectar indícios de possíveis restrições orçamentárias que o impediriam
de selecionar o projeto.
13.2 Uso dos indicadores na avaliação de projetos

Nos tópicos anteriores foram discutidos os principais indicadores disponíveis para o processo
de avaliação de projetos. Todos eles, alguns mais outros menos, são imperfeitos sob algum
aspecto. Sob condições estritamente deterministas, contudo, o indicador VA é o mais
consistente com os princípios da racionalidade econômica.
Quando utilizados para a rejeição, os indicadores produzem resultados equivalentes nos

projetos de investimento do “tipo convencional”. Nos casos de ocorrência de mais de uma
mudança de sinal na série de fluxos de caixa do projeto, verificou-se que a aplicabilidade da
TIR, do PBS e do PBE, deve ser considerada com cautela.
A relativa equivalência desses indicadores em seu uso para o descarte de projetos não é
mantida quando utilizados para a comparação e ordenação múltipla. Alguns indicadores não
consideram aspectos do projeto considerados por outro indicador.
As limitações que estão associadas aos indicadores não os invalida como auxiliares muito
úteis no processo de avaliação de projetos. Através deles, o investidor pode conhecer muitos
aspectos associados projetos disponíveis para a análise que a simples inspeção dos fluxos
líquidos não revelaria.
Esse conhecimento desses muitos aspectos associados aos projetos (duração do projeto,
escala do investimento, tempo de retorno, valor relativo do retorno, valor presente dos
resultados líquidos), propiciado pelos indicadores, pode contribuir no processo de tomada de
decisões na medida que favorece ou, pelo menos, modifica a formação de expectativas do
investidor quanto ao perfil temporal do seu consumo futuro. Isso possibilitará que o processo
de ordenação e seleção de projetos por parte do investidor possa ser agilizado.
Mesmo considerando que a pressuposição de condições deterministas (implícita ou

explicitamente) é utilizada de forma bastante generalizada pelos analistas de projetos, pode-
se questionar a validade dos resultados desse processo de análise. A maior parte das
situações associadas à análise de projetos tem natureza preditiva, ou seja, muitos dos valores
das variáveis que determinam a quantificação do fluxo de caixa do projeto não podem ser
conhecidos com exatidão “a priori”, o que indica serem variáveis aleatórias os indicadores
resultantes do processo de análise de projetos.
13.3 Análise em condições de risco

Na discussão que apresentamos até o momento, assumimos que conhecemos com certeza
os valores que definirão os benefícios e custos associados ao fluxo de caixa dos projetos de
investimentos. Esse procedimento de análise, que chamamos de determinístico, ainda que
bastante útil para avaliações de projetos em condições práticas, é, de fato, uma simplificação.
Em geral, muitas das informações (preços, rendimentos, quantidades, etc.) necessárias para
composição do fluxo de caixa de muitos projetos não são conhecidas com certeza no
momento da análise. A análise em condições deterministas frequentemente superestima o
desempenho econômico do projeto de investimento, o que pode ser algo indesejável em
muitas situações. Esses problemas são de alguma forma minimizados num procedimento
chamado “análise em condições de risco''.
Por exemplo, vamos analisar os investimentos A e B da seguir. O investimento A dá um

retorno de R$ 1.000 com probabilidade de ocorrência de 100%. O investimento B, por outro
lado, oferece o mesmo retorno médio de R$ 1.000, mas há 30% de probabilidade de que o
retorno seja só de $ 800 e também 30% de probabilidade de que seja R$ 1.200. Na verdade,
enquanto o investimento A garante o retorno de R$ 1.000 com 100% de probabilidade, no
investimento B esta probabilidade é só de 40%.
Investimento Retorno Retorno

A 1.000 100%
800 30%
B 1.000 40%
1.200 30%
Resumindo, o risco é a probabilidade de haver variações nos resultados previstos, não

importando se essas variações são para mais ou para menos. É lógico que o administrador se
preocupa muito mais com a probabilidade das variações que podem lhe trazer prejuízo ou
frustrar um determinado empreendimento.
13.4 Conceito de Probabilidade Subjetivas
O problema mais difícil, numa análise de risco, é justamente a estimativa das probabilidades.
O processo de decisão não oferece condições para o cálculo de probabilidades, como, por
exemplo, um jogo de dados ou de baralhos. Em certos casos, mesmo análises estatísticas de
dados históricos não são possíveis, já que muitas vezes o administrador se vê face a um
problema inteiramente novo.
O que se pode fazer, nesse caso, de forma a aplicar as técnicas que serão apresentadas
neste capítulo, é lançar mão do conceito de probabilidade subjetiva.
.
A probabilidade é uma medida de incerteza. Assim, mesmo que o problema seja novo para o
administrador, ele sempre terá informações a respeito (sem informação alguma o problema
fica realmente difícil!), que lhe dão uma certa sensibilidade acerca da incerteza dos fatores
envolvidos. Com um pouco de esforço de imaginação, ele pode quantificar o grau de certeza
(ou incerteza) que tem sobre cada fator. Com isso, estará definindo, em termos numéricos, a
probabilidade de ocorrência do fator, que ele acha razoável.
O processo de atribuição de probabilidades subjetivas pode ser assim detalhado:
 Analisar o problema de forma a identificar os fatores que mais contribuem para a

incerteza do resultado final.
 Para cada fator importante, estimar os valores mais prováveis de ocorrerem.
 Atribuir probabilidades a estes valores, como graus de certeza de ocorrência.
 Procurar conferir os resultados atribuídos com outras pessoas que conhecem o
problema, de forma a tentar obter um consenso sobre os graus de certeza.
Existem alguns métodos quantitativos para análise de risco ou de incerteza que são utilizados
pelos administradores no processo de preparação de uma decisão. Os principais são:
 Exigir um período de retorno de capital menor para projetos de investimento mais

arriscados. Assim, quanto maior o risco associado ao investimento, mais rapidamente
o dinheiro aplicado no projeto deve retornar aos aplicadores.
 Aplicação de determinados critérios de decisão sob condições de incerteza, para a
escolha da alternativa que forneça o maior retorno ou a menor perda esperada.
 Aplicação do método de simulação de Monte Carlo, utilizando probabilidades
estimadas a partir de análise estatística ou atribuídas por um processo subjetivo.
 Utilização de uma taxa de desconto acrescida de valor correspondente ao risco do
investimento, de forma que, quanto maior o risco do projeto.
13.5 Critérios para Decisões sob Incerteza
Em alguns casos, a atribuição de probabilidades subjetivas a eventos que condicionam os

resultados de um problema é uma tarefa difícil ou mesmo impraticável. Nessas situações,
tendo sido determinados os resultados possíveis, associados aos diversos eventos que
poderão ocorrer, o administrador se vê diante de um problema de escolha de alternativa que
poderá dar bons resultados se ocorrer um evento favorável, mas que poderá, caso contrário,
resultar em um fracasso.
13.6 Sistemas de Financiamento

Quando os empréstimos são tomados à longo prazo, os juros passam a ser considerados em
sua forma composta. As prestações compõem-se de amortização do principal mais juros
incidentes sobre o saldo devedor no início de cada período.
A seguir, serão descritos alguns sistemas ou métodos de amortização de empréstimos mais

usuais:
 Sistema Francês ou Tabela Price: as prestações são constantes;

 Sistema de Amortização Constante (SAC) : as amortizações são constantes;
 Sistema Americano ou Sinking fund: os juros são constantes.
A mecânica para elaboração de uma tabela de amortização é bastante simples, e encontra-se

ilustrada a seguir.
O saldo devedor no início do primeiro período é o valor do empréstimo. Os juros devidos de

cada período são iguais ao produto da taxa de juros pelo saldo devedor no início daquele
período, sempre.
A amortização em cada período vai depender do sistema ou método acordado entre a

instituição que concede o financiamento (banco ou fabricante do equipamento) e a empresa
tomadora do empréstimo ou pessoa física (mutuário).
13.6.1 Método francês ou Tabela Price

É o mais empregado no Brasil. Consiste em um sistema de amortização utilizando
pagamentos em parcelas constantes ao longo de todo o prazo de re-pagamento do
empréstimo. Para cálculo das prestações, que são constantes, usa-se a expressão da série
anual uniforme:
P i (1 + i)n
A=
i(1 + i)n 1
A amortização será dada pela diferença entre juros e pagamento:
Ax = A – J x
Jx = Sx-1 . i
Onde:
Ax é a amortização do principal no ano x
Jx são os juros no ano x
Sx é o saldo devedor ao final do ano x - 1
Para x = 1, So é o saldo devedor no início do primeiro ano, isto é, é o valor financiado (P).
Com isso, sabe-se o valor total constante de cada prestação, o qual, por sua vez, é resultado
da adição dos juros à amortização, em cada período. Subtraindo-se da prestação ou anuidade
A os juros, é obtido o valor da amortização). Esse valor é então subtraído ao saldo devedor do
ano anterior, e o saldo resultante é inserido como devedor deste ano. Os juros são sempre
.
calculados sobre esse saldo devedor, e, ao final do período de financiamento, esse devedor
será zerado, ou seja, liquidado.
Exemplo
Vamos supor um empréstimo de R$ 5.000,00 pelo prazo de 10 anos, a juros de 10% ao ano.
A amortização será pela Tabela Price, ou Sistema Francês. Montar a tabela, calcular os juros
e pagamentos anuais.
Por meio da fórmula obtém-se: A = 813,73.
Sabendo que P = 5.000,00 os juros no ano 1 (J1) são 5.000,00 .10% = R$ 500,00.
Assim, a amortização a1 é (813,73- 500,00) = R$ 313,73.
O saldo devedor no final do ano 1 reduz-se a S1 = So- a1 =(5.000,00- 313,73) = R$ 4.686,27.
Prosseguindo para os próximos anos da mesma forma, teremos a seguinte tabela que foi
montada no Excel:
P ARC E L A P AG T O JU RO S AM O RT IZ AÇ ÃO AC U M U L AD O S AL D O
0 5.000,00
1 813,73 500,00 313,73 313,73 4.686,27
2 813,73 468,63 345,10 658,83 4.341,17
3 813,73 434,12 379,61 1.038,45 3.961,55
4 813,73 396,16 417,57 1.456,02 3.543,98
5 813,73 354,40 459,33 1.915,35 3.084,65
6 813,73 308,46 505,27 2.420,62 2.579,38
7 813,73 257,94 555,79 2.976,41 2.023,59
8 813,73 202,36 611,37 3.587,78 1.412,22
9 813,73 141,22 672,51 4.260,29 739,75
10 813,73 73,98 739,75 5.000,04 0,00
T O T AIS 8.137,30 3.137,30 5.000,00
O gráfico a seguir mostra a variação do pagamento, juros e amortização durante o prazo de

financiamento.
TABELA PRICE
900,00
800,00
700,00
600,00
500,00
400,00
300,00
200,00
100,00
0,00
1 2 3 4 5 6 7 8 9 10
PAGAMENTO JUROS AMORTIZAÇÃO

13.6.2 Sistema de Amortização Constante – SAC

Como o próprio nome diz, o SAC consiste em um sistema de pagamentos onde a amortização
do empréstimo será constante durante todo o período contratual.
Pelo fato da amortização ser constante, a série de pagamento não é uniforme. Ou seja,
primeiro calcula-se o valor da amortização em função do número de parcelas do
financiamento, depois o cálculo dos juros devidos será sobre o saldo devedor na data da
amortização. Calculados os juros temos então o valor do pagamento a ser realizado.
Exemplo
Vamos então imaginar que o sistema de amortização do exemplo anterior que era pela Tabela
Price passe a ser realizado pelo SAC. Montar a tabela e o gráfico.
Sabemos que P = 5.000,00 os juros no ano 1 (J1) são 5.000,00 .10% = R$ 500,00.
A amortização anual como é constante é calculada dividindo-se o valor do empréstimo pelo

prazo de pagamento, ou seja, dividindo-se R$ 5.000,00 por 10 (anos), obtendo-se então R$
500,00.
No primeiro ano como o saldo devedor é de R$ 5.000,00, os juros serão calculados

multiplicado-se a taxa por este saldo  5.000,00 . 0,10 = R$ 500,00, e portanto o pagamento
será a soma da amortização com os juros
Portanto com a amortização de R$ 500,00, o saldo devedor para o segundo ano será
calculado como  R$ 5.000,00 – R$ 500,00 = R$ 4.500,00.
No segundo ano como o saldo devedor é de R$ 4.500,00, os juros serão calculados

multiplicado-se a taxa por este saldo  4.500,00 . 0,10 = R$ 450,00, e assim por diante. A
tabela a seguir montada no Excel apresenta todo o fluxo durante o contrato:
0 5.000,00
1 1.000,00 500,00 500,00 500,00 4.500,00
2 950,00 450,00 500,00 1.000,00 4.000,00
3 900,00 400,00 500,00 1.500,00 3.500,00
4 850,00 350,00 500,00 2.000,00 3.000,00
5 800,00 300,00 500,00 2.500,00 2.500,00
6 750,00 250,00 500,00 3.000,00 2.000,00
7 700,00 200,00 500,00 3.500,00 1.500,00
8 650,00 150,00 500,00 4.000,00 1.000,00
9 600,00 100,00 500,00 4.500,00 500,00
10 550,00 50,00 500,00 5.000,00 0,00
T O T AIS 7.750,00 2.750,00 5.000,00
O gráfico do sistema SAC apresentado a seguir mostra um comportamento entre as variáveis

bem diferentes do da Tabela Price.
.
SISTEMA SAC
1.200,00
1.000,00
800,00
600,00
400,00
200,00
0,00
1 2 3 4 5 6 7 8 9 10
13.6.3 Sistema Americano

Neste sistema, em cada período, o tomador somente paga os juros do saldo devedor, não
havendo nenhum pagamento à título de amortização. Portanto, o saldo devedor não se
alterará durante o prazo contratual, pois como os juros são pagos e não incorporados ao
saldo devedor. O Principal será pago então no final do prazo contratual acordado entre as
partes.
Note que como os juros são pagos e não incorporados ao saldo devedor, é como se o
empréstimo fosse concedido no regime de juros simples.
Exemplo
Vamos então imaginar que o sistema de amortização do mesmo exemplo que era pela Tabela
Price passe a ser realizado pelo Sistema Americano. Montar a tabela e o gráfico.
A parcela de juros então será 5.000,00 .10% = R$ 500,00. A tabela a seguir mostra então o
fluxo deste sistema de pagamentos:
0 5.000,00
1 500,00 500,00 0,00 0,00 5.000,00
2 500,00 500,00 0,00 0,00 5.000,00
3 500,00 500,00 0,00 0,00 5.000,00
4 500,00 500,00 0,00 0,00 5.000,00
5 500,00 500,00 0,00 0,00 5.000,00
6 500,00 500,00 0,00 0,00 5.000,00
7 500,00 500,00 0,00 0,00 5.000,00
8 500,00 500,00 0,00 0,00 5.000,00
9 500,00 500,00 0,00 0,00 5.000,00
10 5.500,00 500,00 5.000,00 5.000,00 0,00
T O T AIS 10.000,00 5.000,00 5.000,00
SISTEMA AMERICANO
6.000,00
5.000,00
4.000,00
3.000,00
2.000,00
1.000,00
0,00
1 2 3 4 5 6 7 8 9 10
Em relação ao Sistema Francês (Tabela Price), o método americano requer menores

desembolsos periódicos, ao longo do prazo do financiamento. Em compensação, a empresa
tomadora do empréstimo deve-se preparar para o desembolso total da amortização, ao cabo
do prazo de financiamento. Uma maneira de preparar-se para esse desembolso, é constituir
um fundo de reserva para amortização (sinking .fund).
O sinking fund consiste, então, de depósitos periódicos e iguais em uma instituição financeira
que remunere o capital a uma taxa isf de juros. O objetivo é alcançar, com a capitalização
composta, um valor futuro ou montante que seja próximo ao valor da amortização única que
será devida ao final do prazo do financiamento.
O diagrama de fluxo de caixa e a fórmula correspondente ao cálculo dessa prestação estão
na Seção 2.5.2 -Pagamentos Múltiplos: Série Uniforme- e o valor de tal prestação dependerá
da taxa de juros que remunerará o capital empregado no sinking .fund.
Por exemplo, se a taxa de remuneração do capital do sinking fund for igual à taxa de juros do
empréstimo, pode-se verificar que a quantia total (juros + parcela do sinking fund) será a
mesma da prestação calculada pela Tabela Price (A).
Naturalmente, se as parcelas do sinking fund forem aplicadas a uma taxa de remuneração

maior que a taxa de juros do empréstimo, passa a ser mais interessante para o tomador do
empréstimo, usar o Sistema americano. Se a remuneração do sinking fund for inferior à taxa
do empréstimo, o sistema francês de amortização será mais vantajoso que o americano, para
o tomador do empréstimo.
Exemplo
Agora, para verificar o que está anteriormente descrito, vamos montar uma planilha em Excel
em que a taxa de juros para o empréstimo pelo Sistema Francês (Tabela Price) é de 10% a.a.
Vamos utilizar os mesmos dados dos exemplos anteriores.
Vamos então comparar os resultados no Sistema americano, calculado a 10% a.a. mais o
sinking fund capitalizado a uma taxa isf = 7,5%, 10% e 12,5% a.a.. Somamos a parcela de
juros do Sistema Americano com a parcela a constituir o sinking fund para cada uma das três
taxas de juros.
.
Para calcular a parcela do sinking fund, é necessário apenas encontrar a série uniforme
equivalente ao empréstimo descontada à taxa de juros desejada. Assim, utilizando-se da
fórmula da Tabela Price, encontra-se A, ou parcela do sinking.fund (SF):
P = 5.000 i= 7,5% n = 10  então A = R$ 353,43 = SF

P = 5.000 i= 10,% n = 10  então A = R$ 313,73 = SF
P = 5.000 i= 12,5% n = 10  então A = R$ 278,11 = SF
Para executar a comparação, montamos a tabela a seguir:
i 7,50% 10% 12,50%

Tabela Price
Prestação (cte) R$ 813,73 R$ 813,73 R$ 813,73
Sistema Americano
Parcela Juros: cte R$ 500,00 R$ 500,00 R$ 500,00
Parcela Sink ing fund R$ 353,43 R$ 313,73 R$ 278,11
Total (J+SF ) R$ 853,43 R$ 813,73 R$ 778,11
Opção Price Indiferente Americano
Ou seja, se a prestação da Tabela Price for maior do que a do Sistema Americano, isto é, se
não existir uma taxa de juros com retorno pelo menos igual ao financiamento, opta-se pelo
Sistema Francês. No entanto, se a taxa de juros do sinking fund for maior do que a taxa do
financiamento, opta-se pelo sistema americano.
Na Figura a seguir, aparecem as prestações da Tabela Price e do Sistema Americano para

diversas taxas de remuneração do sinking fund.
Com paração Price x Am ericano
R$ 1.050,00
R$ 1.000,00
R$ 950,00
R$ 900,00
R$ 850,00
Valor
R$ 800,00
R$ 750,00
R$ 700,00
R$ 650,00
R$ 600,00
0%
2%
4%
6%
8%
10%
12%
14%
16%
18%
20%
Taxa de juros SF (i sf )
Prestação - Tabela Price Sistema Americano + Sinking Fund

13.7 Empréstimo com carência
A empresa que deseja investir em determinado projeto, por exemplo, fábrica nova, necessita
de capital. Muitas vezes, a instituição financeira (Banco Comercial ou Banco de
Desenvolvimento) concederá um empréstimo que não cobre o valor integral do investimento,
o que exigirá que a empresa entre com uma parte do investimento usando capital próprio.
(usualmente os bancos financiam 80% a 90% do investimento)
Nos anos iniciais de implementação do projeto, a empresa estará realizando os investimentos,

os quais serão parcialmente financiados, e ela terá que aportar o restante do capital para
realização de obras e aquisição de máquinas e equipamentos.
Nos anos iniciais, é muito conveniente, do ponto de vista do empreendedor ter um período de
carência, para amortização da dívida, durante a qual apenas os juros obtidos pela incidência
da taxa de juros sobre o saldo devedor são devidos. Às vezes, também, os juros são
capitalizados, sendo acrescentados ao saldo devedor, durante o período de carência. Tudo
depende do acerto entre as partes, o que será objeto do contrato de financiamento. Quando
se atinge o final do prazo de carência, o pagamento poderá ser calculado por meio do
Sistema Francês, do Americano, ou de amortização constante ou de algum outro acertado
entre as partes.
Alguns tipos de carência:
Caso 1:
Durante o prazo de carência, apenas os juros sobre o principal são devidos;
Caso 2:
Durante o prazo de carência, não há pagamento nenhum, nem de juros sobre o saldo
devedor, nem de amortização do principal. Dessa forma, os juros são somados ao saldo
devedor, resultando um saldo devedor maior.
Exemplo
Vamos admitir um financiamento de 60% do valor total de um investimento, no valor de R$ 10

milhões no prazo total de 10 anos, com dois anos de carência, a juros de 10% ao ano. Fazer
a projeção do financiamento utilizando o método francês (Tabela Price) para os casos 1 e 2,
anterior mente citados.
Resolução:
Caso 1: Pagamento de juros durante o período de carência
Tem-se o pagamento de juros sobre o principal de 10 milhões nos primeiros dois anos. Isso
acarreta um pagamento de R$ 10.000.000,00 . 0,10 = R$ 1.000.000,00 nos dois primeiros
anos.
Como se escolheu utilizar o Sistema Price para o plano de financiamento, é necessário

calcular a série uniforme para os 10 milhões, agora dividida em apenas oito anos.(10 anos – 2
.
de carência = 8 anos de amortização) Utilizando-se a fórmula Price, encontra-se A= R$

1.874,44. Os juros para o ano 3 serão iguais aos dos anos 1 e 2: R$1 milhão. Subtraindo-se
este valor da anuidade, encontra-se R$ 874.440,00 que corresponde ao pagamento da
amortização do ano 3.
Prosseguindo-se com a mesma linha de raciocínio para os outros anos, calcula-se tabela a
seguir:
Juros D ura nte a C a rê nc ia

T a b e la Pric e - va lo re s e m R $ m il
(A ) (B ) (C ) (D ) (E) (F )
Pa rc e la Pa g a m e n to J u ro s A m o rtiz a ç ã o A c u m u la d o S a ld o
1 R$ 1 .0 0 0 ,0 0 R$ 1 .0 0 0 ,0 0 R$ 0 ,0 0 R$ 0 ,0 0 R$ 1 0 .0 0 0 ,0 0
2 R$ 1 .0 0 0 ,0 0 R$ 1 .0 0 0 ,0 0 R$ 0 ,0 0 R$ 0 ,0 0 R$ 1 0 .0 0 0 ,0 0
3 R$ 1 .8 7 4 ,4 4 R$ 1 .0 0 0 ,0 0 R$ 8 7 4 ,4 4 R$ 8 7 4 ,4 4 R$ 9 .1 2 5 ,5 6
4 R$ 1 .8 7 4 ,4 4 R$ 9 1 2 ,5 6 R$ 9 6 1 ,8 8 R$ 1 .8 3 6 ,3 2 R$ 8 .1 6 3 ,6 8
5 R$ 1 .8 7 4 ,4 4 R$ 8 1 6 ,3 7 R$ 1 .0 5 8 ,0 7 R$ 2 .8 9 4 ,4 0 R$ 7 .1 0 5 ,6 0
6 R$ 1 .8 7 4 ,4 4 R$ 7 1 0 ,5 6 R$ 1 .1 6 3 ,8 8 R$ 4 .0 5 8 ,2 8 R$ 5 .9 4 1 ,7 2
7 R$ 1 .8 7 4 ,4 4 R$ 5 9 4 ,1 7 R$ 1 .2 8 0 ,2 7 R$ 5 .3 3 8 ,5 4 R$ 4 .6 6 1 ,4 6
8 R$ 1 .8 7 4 ,4 4 R$ 4 6 6 ,1 5 R$ 1 .4 0 8 ,2 9 R$ 6 .7 4 6 ,8 4 R$ 3 .2 5 3 ,1 6
9 R$ 1 .8 7 4 ,4 4 R$ 3 2 5 ,3 2 R$ 1 .5 4 9 ,1 2 R$ 8 .2 9 5 ,9 6 R$ 1 .7 0 4 ,0 4
10 R$ 1 .8 7 4 ,4 4 R$ 1 7 0 ,4 0 R$ 1 .7 0 4 ,0 4 R$ 1 0 .0 0 0 ,0 0 R$ 0 ,0 0
To ta is R$ 1 6 .9 9 5 ,5 2 R$ 6 .9 9 5 ,5 2 R$ 1 0 .0 0 0 ,0 0
A representação dos pagamentos, amortização e juros ao longo do tempo apresenta-se na

figura a seguir:
Carência com Pagamento de Juros
R$ 2.000,00
R$ 1.800,00
R$ 1.600,00
R$ 1.400,00
R$ 1.200,00
Valor
R$ 1.000,00
R$ 800,00
R$ 600,00
R$ 400,00
R$ 200,00
R$ 0,00
1 2 3 4 5 6 7 8 9 10
Período
Pagamento Juros Amortização
Caso 2: Ausência de pagamentos durante o prazo de carência

Nesse caso, os juros vão sendo incorporados ao principal até o final do prazo de carência.
Para determinar esse novo principal, precisa-se calcular o valor futuro dos R$ 10 milhões a
n
uma taxa de 10% a.a. Utilizando-se a fórmula F = P(1 + i) , encontra-se F = R$ 12,1 milhões.
Desse ponto em diante, a resolução é exatamente a mesma do caso anterior. Encontra-se a

série anual uniforme equivalente ao principal, ou seja, o valor anual para um valor presente de
R$ 12,1 milhões com taxa de 10% a.a. em um período de 10 anos. Essa parcela corresponde
a A=R$ 2,268 milhões. Os juros serão cobrados sobre o saldo devedor, e o restante da
parcela corresponderá à amortização do principal. Procedendo assim para todos os períodos,
monta-se a tabela a seguir:
S e m p a g a m e nto d ura nte a c a rê nc ia

T a b e la Pric e - va lo re s e m R $ m il
(A ) (B ) (C ) (D ) (E) (F )
Pa rc e la Pa g a m e n to J u ro s A m o rtiz a ç ã o A c u m u la d o S a ld o
1 R$ 0 ,0 0 R$ 0 ,0 0 R$ 0 ,0 0 R$ 0 ,0 0 R$ 1 1 .0 0 0 ,0 0
2 R$ 0 ,0 0 R$ 0 ,0 0 R$ 0 ,0 0 R$ 0 ,0 0 R$ 1 2 .1 0 0 ,0 0
3 R$ 2 .2 6 8 ,0 7 R$ 1 .2 1 0 ,0 0 R$ 1 .0 5 8 ,0 7 R$ 1 .0 5 8 ,0 7 R$ 1 1 .0 4 1 ,9 3
4 R$ 2 .2 6 8 ,0 7 R$ 1 .1 0 4 ,1 9 R$ 1 .1 6 3 ,8 8 R$ 2 .2 2 1 ,9 5 R$ 9 .8 7 8 ,0 5
5 R$ 2 .2 6 8 ,0 7 R$ 9 8 7 ,8 0 R$ 1 .2 8 0 ,2 7 R$ 3 .5 0 2 ,2 2 R$ 8 .5 9 7 ,7 8
6 R$ 2 .2 6 8 ,0 7 R$ 8 5 9 ,7 8 R$ 1 .4 0 8 ,2 9 R$ 4 .9 1 0 ,5 1 R$ 7 .1 8 9 ,4 9
7 R$ 2 .2 6 8 ,0 7 R$ 7 1 8 ,9 5 R$ 1 .5 4 9 ,1 2 R$ 6 .4 5 9 ,6 4 R$ 5 .6 4 0 ,3 6
8 R$ 2 .2 6 8 ,0 7 R$ 5 6 4 ,0 4 R$ 1 .7 0 4 ,0 4 R$ 8 .1 6 3 ,6 8 R$ 3 .9 3 6 ,3 2
9 R$ 2 .2 6 8 ,0 7 R$ 3 9 3 ,6 3 R$ 1 .8 7 4 ,4 4 R$ 1 0 .0 3 8 ,1 2 R$ 2 .0 6 1 ,8 8
10 R$ 2 .2 6 8 ,0 7 R$ 2 0 6 ,1 9 R$ 2 .0 6 1 ,8 8 R$ 1 2 .1 0 0 ,0 0 R$ 0 ,0 0
To ta is R$ 1 8 .1 4 4 ,5 8 R$ 6 .0 4 4 ,5 8 R$ 1 2 .1 0 0 ,0 0
Um gráfico então poderá ser traçado para uma melhor visualização:
Carência sem Pagamento de Juros
R$ 2.500,00
R$ 2.000,00
R$ 1.500,00
Valor
R$ 1.000,00
R$ 500,00
R$ 0,00
1 2 3 4 5 6 7 8 9 10
Período
Pagamento Juros Amortização
Verifica-se, no caso 2, um patamar de pagamento superior ao do caso 1, justificado pela

ausência de pagamento de juros nos dois primeiros anos. O desafogo para o devedor
.
representado pela ausência de pagamento de juros nos primeiros anos, transforma-se e

pagamentos maiores, posteriormente.
Existem alguns termos utilizados, em Matemática Financeira e Análises de Investimentos,

geralmente em inglês. A seguir, serão dados alguns desses termos e seus significados:
 Grace Period - Período ou Prazo de Carência

 Loan - Empréstimo
 Debt- Exigibilidade ou capital de terceiros
 Equity - Capital Próprio
 Net Worth - Patrimônio Líquido (Capital próprio + Reservas + Lucro acumulado)
Interest Rate - Taxa de Juros
 Minimum Attractive Rate (Hurdle Rate) - Taxa Mínima de Atratividade
 Yield, Eaming Power - Taxa de Retorno
 Liabilities (passivo) - Debt + Net Worth (capital de terceiros + patrimônio líquido)
Discount Rate - Taxa de Desconto
13.8 Amortização com "parcelas intermediárias"

Não é incomum, para venda de imóveis, por exemplo, que a empresa vendedora ofereça ao
comprador a possibilidade de saldar a dívida com um programa flexível de pagamentos, tais
como, por exemplo:
 30% de entrada;
 4 intermediárias semestrais de 5% cada ( 5%x4=20%) ;
 10% na entrega das chaves;
 Saldo (40%) financiado em 15 anos à taxa de juros de 10% ao ano;
 Prazo total: 2 anos (4 x 6 meses) + 15 anos = 17 anos.
Seja mantendo-se o programa de pagamentos anterior, seja com antecipação de pagamentos

intermediários devidos, seja ainda com amortização parcial ou total do empréstimo, em dado
momento do prazo total de amortização (15 anos, em nosso exemplo), as amortizações serão
sempre abatidas do saldo devedor, e os juros incidirão sobre o saldo devedor restante, de
acordo com o sistema de amortização contratado.
Da mesma forma, se uma amortização devida no futuro for antecipada, então a empresa
vendedora poderá oferecer um desconto (o valor presente descontará a amortização a uma
dada taxa de desconto, por exemplo, igual à do financiamento).
13.9 Empréstimos com cláusula de reajustamento

Alguns contratos de empréstimos poderão ter cláusulas de reajustamento do saldo devedor,
para compensar perda de poder aquisitivo da moeda. Para isso são usados índices de
preços.
Remontando à seção 2.7, será ampliada a equação da incidência da inflação na taxa de juros
da seguinte forma:
F = P (1+  ) + P . i .(1+  )
A primeira parcela desta equação é o reajuste do principal, e a segunda parcela o

reajustamento dos juros.
Assim, reajustando-se valores tanto de principal como de juros, podemos calcular as novas
parcelas de pagamentos. O exemplo dado a seguir ilustra bem a situação.
Exemplo
Adimita-se que um empréstimo de R$ 200.000,00 foi tomado à taxa de juros de 8% a.a. pelo
prazo de cinco anos, devendo ser resgatado ao final deste período. Usar a Tabela Price para
calcular os cinco pagamentos anuais. Depois, utilizar a variação monetária a ano, por meio do
reajuste pela estimativa de inflação na tabela a seguir:
Ano Inflação
1 20,00%
2 18,00%
3 17,00%
4 17,00%
5 16,50%
A primeira parte do exercício já é conhecida. Inicialmente, calcula-se a parcela da série anual

uniforme equivalente ao valor presente considerando-se a taxa de juros de 8% ao ano, para
n= 5 anos. Resolvendo-se as equações, monta-se a tabela:
Ta b e la Pric e se m C orre ç ã o M one tá ria

(A ) (B ) (C ) (D ) (E) (F)
Pa rc e la Pa g a m e nto J uros A m ortiz a ç ã o A c um ula d o Sa ld o
0 R$ - R$ - R$ - R$ - R$ 200.000,00
1 R$ 50.091,29 R$ 16.000,00 R$ 34.091,29 R$ 34.091,29 R$ 165.908,71
2 R$ 50.091,29 R$ 13.272,70 R$ 36.818,59 R$ 70.909,89 R$ 129.090,11
3 R$ 50.091,29 R$ 10.327,21 R$ 39.764,08 R$ 110.673,97 R$ 89.326,03
4 R$ 50.091,29 R$ 7.146,08 R$ 42.945,21 R$ 153.619,18 R$ 46.380,82
5 R$ 50.091,29 R$ 3.710,47 R$ 46.380,82 R$ 200.000,00 R$ 0,00
Total R$ 250.456,45 R$ 50.456,45 R$ 200.000,00
No fim do primeiro ano, o devedor deverá pagar R$ 50.091,29. No entanto, como houve
inflação de 20%, os valores deverão ser reajustados. O devedor pagará a quantia (1 + θ 1).A
= R$ 60.109,55. Esse reajuste incidirá de forma igual sobre juros e amortização.
Dessa forma, a amortização passa a ser a 1' = 1,2 .a1 = 1,2 .(34.091,29) = RS 40.909,55.
.
Os juros também se alteram: j1' = 1,2 . j1 = 1,2 .16.000 = R$ 19.200,00. Total = 40.909,55 +
19.200,00 = R$ 60.109,55.
Imediatamente antes do pagamento da primeira parcela da dívida, o valor reajustado do saldo

devedor (acrescido de juros) é de:
C 1' = C1. (1 + Ө1) .(1 + i) = R$ 200.000,00. (1,2) .(1,08) = R$ 259.200,00

Após o pagamento, o saldo devedor será C 1' - A 1' = R$ 199.090,55. Esse valor é exatamente
igual ao reajuste do saldo devedor inicial, ou seja, R$ 165.908,71 .(1 + 0,20) = R$ 199.090,55.
Verifica-se, então, na linha relativa ao ano 1, que todos os valores foram devidamente
reajustados pelo índice da inflação deste ano, isto é, foram multiplicados por (1 + θ 1). Como
índices inflacionários incidem como juros compostos sobre saldos devedores, a inflação do
período 2 terá seu efeito da seguinte forma:
C '2 = C1 .(1 + i) .(1 + Ө1) .(1 + Ө2) = C2 (1 + Ө1) .(1 + Ө2)

J '2 = C 1' .i. (1 + Ө2) = C1 .(1 + Ө1) .i. (1 + Ө2) = J2. (1 + Ө1) .(1 + Ө2)
a '2 = C '2 - J '2 = (C2 - J2 .(1 + Ө1) .(1 + Ө2) = a2 .(1 + Ө1) .(1 + Ө2)
Ou seja, a cada período devem ser tomados o valor de prestação, a amortização do período e
amortização total acumulada, juros e saldo devedor calculados sem reajuste E atualizá-los
pela inflação composta (1 + Ө1) .(1 + Ө2) ...(1 + Өn)
o quadro completo só poderá ser calculado por etapas, pois só após saber o índice de
inflação relativo ao ano, conseguir-se-á calcular o reajuste causado pela inflação. A tabela a
seguir mostra a tabela reajustada:
Ta b e la Pric e c om C orre ç ã o M one tá ria

(A ) (B ) (C ) (D ) (E) (F)
Pa rc e la Pa g a m e nto J uros A m ortiz a ç ã o A c um ula d o Sa ld o
0 R$ - R$ - R$ - R$ - R$ 200.000,00
1 R$ 60.109,55 R$ 19.200,00 R$ 40.909,55 R$ 40.909,55 R$ 199.090,45
2 R$ 70.929,27 R$ 18.794,14 R$ 52.135,13 R$ 100.408,40 R$ 182.791,60
3 R$ 82.987,24 R$ 17.109,29 R$ 65.877,95 R$ 183.355,77 R$ 147.988,23
4 R$ 97.095,07 R$ 13.851,70 R$ 83.243,38 R$ 297.769,63 R$ 89.902,85
5 R$ 113.115,76 R$ 8.378,95 R$ 104.736,82 R$ 451.638,44 R$ 0,00
Total R$ 424.236,90 R$ 77.334,08 R$ 346.902,82
Note-se que as parcelas de amortização desinflacionadas são iguais, ou seja, o que a tabela
mostra é realmente uma Tabela Price "aquecida" pela inflação.
Considerações Finais 131
14. Considerações Finais
14.1 Envolvimento do Pessoal Interno da Organização

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 organização, bem como o envolvimento dos diversos setores da
empresa, que certamente contribuirão com depoimentos e posicionamentos alavancadores
de oportunidades.
Apoio este que não deverá ficar restrito ao fornecimento de recursos e liberação de verbas
para que estas iniciativas sejam levadas a cabo pelas equipes de projeto. É fundamental que
as resistências culturais sejam, pouco a pouco, vencidas, principalmente através de posturas
pró-ativas, na abertura para debates e discussões que favoreçam o questionamento quanto
às alternativas de soluções por serem adotadas.
Uma organização não são seus Projetos, nem seus Processos internos, nem tampouco toda a
Tecnologia da Informação que venha a possuir. São as Pessoas que ali trabalham,
objetivando a excelência naquilo que dispõem para a comunidade, para os clientes da
instituição, para seus acionistas e, naturalmente, para si próprias.
Os Processos são a estruturação do know-how da organização, a forma como ela pensa

que deve trabalhar, objetivando sua total eficiência e eficácia em seus fluxos de produção e
de prestação de serviços. A Tecnologia da Informação é um poderoso instrumento que torna
muitas das tarefas desempenhadas por seus colaboradores menos onerosas e complexas.
E os Projetos são apenas uma maneira estruturada e inteligente de se preparar a

incorporação destas melhorias. Portanto, de nada adiantariam projetos altamente sofisticados,
bem elaborados e bem conduzidos se não for conseguido significativo respaldo interno
por parte de todos os níveis organizacionais envolvidos. E de nada adiantaria todo esse
pessoal envolvido se não houvesse alguém, um gerente, um líder de projetos, tentando
fazer com que todos caminhem em uma mesma direção.
14.2 Quando dizer NÃO

É comum, no âmbito corporativo, que se deseje a incorporação de melhorias através
de projetos com um mínimo de esforço, através do menor dispêndio possível de dinheiro e
recursos, da forma mais eficaz, eficiente e produtiva possível, e em prazos cada vez
menos dilatados. Idealmente, é o que todos desejamos que possa ser feito.
E é um dos papéis da alta e média gerências exercer um determinado nível de

pressão por resultados, preferencialmente de forma a atender aos parâmetros acima
.
citados. Do contrário, as soluções demandadas seriam as mais caras possíveis,

implementadas em prazos astronomicamente estendidos, e de forma a demandar todos os
recursos disponíveis e não disponíveis da organização. Nós, profissionais, por várias
vezes, alimentamos nossos próprios “sonhos” de solução, algo que se revela como
inatingível, porém, ideal, perfeito. E é uma importante atribuição das gerências não
permitirem que nossos “devaneios” nos dominem por completo, privando-nos de uma
realidade fatal que é a de que “há um negócio por aqui a ser tocado”.
No entanto, há limites para o que é factível, o que é viável num sentido prático. Excesso de
pressão pode ser prejudicial, pode levar a soluções fracas, escolhas errôneas e, o
que é pior, a considerar alternativas que ninguém de fato acredita que poderão
satisfazer às necessidades apontadas.
E é de responsabilidade dos líderes de projeto, amparados por suas equipes, determinar que,
nos momentos adequados, determinadas exigências não poderão ser atendidas pelos
Projetos que lhes cabem. Amparando sua postura, tais equipes devem oferecer a
argumentação convincente, os caminhos alternativos a serem pesquisados e as novas
possíveis propostas de solução para os problemas com os quais se vêem desafiados.
Sobretudo, devem estar atentos a novas perspectivas de solução, a todo o tempo, e
perspectivas estas muitas vezes originárias de situações e pessoas “improváveis”.
Uma abordagem comum para se dizer não a algo solicitado que não encontra
viabilidade para sua execução é a própria devolução da pergunta, apresentando-se outras
iniciativas em curso que poderiam ser paralisadas ou suspensas em favor do novo
empreendimento. Esta decisão deve ficar a cargo das alçadas com poder de transferência de
prioridades de uma frente para a outra, e assim assumir-se as responsabilidades devidas
pelos eventuais atrasos nos projetos preteridos.
A negativa à imposição de uma solução tida como inviável é resultado de um extremo senso
ético e de profissionalismo. A transparência, a capacidade de assumir a verdade, mesmo que
ela não seja a constatação mais agradável a ser verificada no momento, a firmeza nos
posicionamentos e a transparência dos argumentos levam uma empresa a não investir
tempo e dinheiro em tentativas fatalmente suscetíveis ao fracasso.
Há uma frase que, de forma simplória, poderia traduzir situações como estas: é preferível
ficar “vermelho” uma única vez dizendo NÃO, do que “amarelo” todos os dias, até o
final do Projeto, dizendo SIM, e não acreditando, de fato, que nós realmente faremos isso...
14.3 Você é um Líder de Projetos?

Você se vê na situação de assumir projetos caros e complexos? Você se enquadra
nas características definidas como ideais para a liderança de uma iniciativa corporativa
baseada em uma grande e intrincada solução de missão-crítica? Você se considera um
excelente negociador, planejador, motivador e gestor de pessoas, solucionador de conflitos,
condutor de reuniões? Não, não e não?
Considerações Finais 133
Acredite: ninguém é perfeito. Todos temos características de personalidade, formação,

crenças, valores, princípios e posicionamentos pessoais que, dificilmente, nos abandonarão
quando assumirmos funções de alta responsabilidade.
Ainda, muitas das “exigências” demandadas para estes profissionais podem ser
desenvolvidas, aperfeiçoadas, melhoradas e otimizadas. Pode-se desenvolver, por exemplo,
empatia, diplomacia, bom-senso empresarial, adquirir importantesconhecimentos do mercado,
de tecnologia, do negócio específico, entre outros aspectos.
No entanto, a questão aqui é ainda mais simples: você REALMENTE QUER se tornar um
líder de projetos?
A história está repleta de exemplos de líderes, de grandes empreendedores, inventores,

aventureiros, descobridores, pesquisadores, pioneiros, artistas, sonhadores. Nenhum
deles era perfeito. Todos eles possuíam diversos e inomináveis 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 mandatório que possuíssem para atingirem o real
estágio de gênios. Vários deles cometeram erros abissais, fracassaram tragicamente
em muitas de suas tentativas. E ainda assim foram realizadores excepcionais,
brilhantes, geniais.
Mas o que então lhes tornava tão diferenciados? O que lhes trazia tanto sucesso,
tantas realizações? 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 realizações, a se tornarem

fenomenais, desde o início dos tempos? Ou, ainda, era porque já possuíam as respostas
certas na cabeça antes que alguém pudesse sequer imaginar as perguntas? Talvez, quem
sabe?
Contudo, certamente todos eles sabiam do poder que possuíam para erguer-se todas as
vezes que falhassem. Todas as vezes. Até porque eles não deixavam de falhar.
Eles aprendiam a continuar acreditando em si mesmos.
Mas por que é que nós sempre nos referimos a eles como... Eles? Por que eles não
poderíamos ser... Nós? Sim, claro! Pois olhe só para Nós. Veja no que Nós nos
transformamos. Nós construímos nossas famílias, criamos nossos filhos, confortamos nossas
viúvas, vencemos nossos medos. Nós, todos os dias, conquistamos amigos, pessoas,
desejos e vitórias, vencemos desafios. Nós construímos pontes, poemas, países e
verdades. Nós libertamos injustiças, preconceitos, limites, amores satisfeitos.
Nós construímos o mundo...
.
Enfim, todos Nós, estes seres “brilhantes”, ao conduzirmos “maravilhosamente” nossos

próprios Projetos, tornando-nos tão bem sucedidos, devemos guardar, pelo
menos, uma característica ímpar e comum em nossos corações.
Nós, simples e profundamente, devemos acreditar que SIM, que tudo o que quisermos pode
ser feito.
Depende de Nós.
Referências Bibliográficas 135
15. Referências Bibliográficas
AZEVEDO FILHO, A.J.B.V. 1988a. Análise Econômica de Projetos: ``Software" para

Situações Deterministas e de Risco Envolvendo Simulação. Piracicaba, 127p. (Mestrado-
ESALQ/USP).
AZEVEDO FILHO, A.J.B.V. 1988b. ALEAXPRJ -- Sistema para Análise Economica de

Projetos em Condição de Risco. Manual do Usuário. Piracicaba, USP/PCP/CIAGRI--- Centro
de Informática na Agricultura, 43p.
AZEVEDO FILHO, A.J.B.V. 1988c. DETERPRJ -- Sistema para Análise Economica de

Projetos em Condições Deterministas. Manual do Usuário. Piracicaba, USP/PCP/CIAGRI---
Centro de Informática na Agricultura, 89p.
CARNEGIE, Dale. Como fazer amigos e influenciar pessoas. 51 . Edição. São

Paulo: Companhia Editora Nacional, 2003.
COVEY, Stephen. Os 7 Hábitos das Pessoas Altamente Eficazes. São Paulo: Best Seller,
2000.
DAVENPORT, Thomas H. Ecologia da Informação. São Paulo: Futura, 1998.
DAVENPORT, T. PRUSAK, L. Conhecimento Empresarial. Rio de Janeiro: Campus, 1999.
HELDMAN, Kim. Gerência de Projetos: guia para o exame oficial do PMI. 2 . Edição. Rio de
Janeiro: Campus, 2003.
HERTZ, O. B. 1964. Risk Analysis in Capital Investment. Harvard Business Review, 42(1):95-
106, Jan-Feb.
KERZNER, Harold. Gestão de Projetos: as melhores práticas. Porto Alegre: Bookman, 2002.
MARTINS, José Carlos Cordeiro. Gestão de Projetos de Desenvolvimento de Software. Rio

de Janeiro: Brasport, 2002.
MAXIMIANO, Antônio César Amaru. Administração de Projetos: como transformar idéias em

resultados. São Paulo: Atlas, 2002.
MENEZES, Luís César de Moura. Gestão de Projetos. 2 . Edição. São 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 Informática (Além do C.P.D.).

Rio de Janeiro: COP Editora, 1989. p.29-39.
NONAKA, Ikujiro; TAKEUCHI, Hirotaka. Criação de conhecimento na empresa: como as

empresas japonesas geram a dinâmica da inovação. Rio de Janeiro: Editora Campus, 1997.
PETERS, Thomas J. “Fazer primeiro, pensar depois”. HSM Management, São Paulo, v.1,
n.3, p.14-18, jul./ago. 1997.
PRADO, Darci. Gerência de projetos em tecnologia da informação. Série Gerência 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.
REZENDE FILHO, MAURO. Gestão por Projetos Aplicando o Método PERT/CPM e o Software MS-
Project. Rio de Janeiro: Fábrica do Livro, 2005.
STAIR, Ralph M. Princípios de Sistemas de Informação: uma abordagem gerencial –

SegundaEdição. Rio de Janeiro: LTC – Livros Técnicos e Científicos Editora, 1998.
STEWART, Thomas. Capital intelectual: a nova vantagem competitiva das empresas.

Rio de Janeiro: Campus, 1998.
SVEIBY, K. E. A Nova Riqueza das Organizações. 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.
Anexo I: Ferramenta PERT/CPM 137
Anexo I - Ferramenta PERT/CPM

A ferramenta PERT / CPM, pode ser aplicada em tudo que se possa imaginar que tenha uma
origem e um término previamente fixado. Desde a fabricação de um alfinete até a elaboração
de um projeto para colocar um satélite em órbita.
O significado desta sigla é:
PERT - Program Evaluation & Review Technique

Avaliação de Programas e Técnicas de Revisão
CPM – Critical Path Method

Método do Caminho Crítico
Atualmente estes métodos apesar de serem distintos se confundem, entretanto, é

interessante saber a características de cada um:
• O PERT trabalha com três estimativas de tempo:

- Tempo otimista – condições favoráveis.
- Tempo mais provável – tempo mais próximo da realidade.
- Tempo pessimista – condições desfavoráveis.
Por este motivo o PERT possui características probabilísticas e variáveis aleatórias.

Portanto para calcular o tempo de cada atividade é necessário usar a formula abaixo.
• O CPM possui características determinísticas e variáveis reais.
Para a montagem de uma rede PERT/CPM inicialmente necessitamos caracterizar as

atividades e os eventos do projeto, sendo que normalmente as atividades são representadas
por setas e os eventos por círculos
• Atividade: representa uma parcela do trabalho total necessário para a execução de

um projeto. Consome tempo e recursos (humanos, financeiros, tecnológicos e
materiais).
.
• Evento: é a caracterização no tempo da origem ou do término de uma atividade, não

consome tempo e nem recursos.
Regras básicas para montagem da rede

Algumas regras são utilizadas para a montagem de uma rede PERT/CPM, com o objetivo de
padronizar e uniformizar as informações, de modo que qualquer profissional em qualquer
parte do mundo não tenha dificuldades em entender o cronograma do projeto.
Atividade fantasma: não consome tempo e nem recursos, mas só deve ser utilizada quando
for realmente necessária.
Casos que deve ser utilizada:

Evitar que entre dois eventos sucessivos exista mais do que uma atividade.
Demonstrar a independência de uma atividade.
Atividades condicionantes: são aquelas que condicionam a realização das atividades que
lhes sucedem.
Atividades paralelas: são duas ou mais atividades ocorridas entre dois eventos sucessivos.
Atividades simultâneas: são duas ou mais atividades que partem de um único evento e se
direcionam para eventos diferentes.
Roteiro Básico para aplicar a técnica

A seguir apresentamos a idéia de um roteiro para a montagem da rede utilizando a técnica
PERT/CPM, que entretanto não deve ser considerada como única, uma vez que, como
projetos são únicos, cada um deverá ter seu caso específico.
1. Levantar todas as atividades necessárias para a realização do projeto.

2. Elaborar o Quadro de Prioridades – QP, o qual consiste em demonstrar a
interdependência das atividades, ou seja, ordem de relacionamento (atividades que
antecedem sucedem umas a outras).
3. Com base no QP, montar o Diagrama ou a Rede, que é a representação gráfica do

projeto.
Passos necessários para montar a rede:

- Por meio do QP verificar quais atividades partem do evento inicial;
- Ignorar as atividades antecessoras e montar a rede observando o destino de
cada atividade, segundo o QP na ordem seqüencial em que são empregadas
(de cima para baixo);
.
- Numerar os eventos, no início o número 1 e ao final o maior número de

acordo com o projeto;
- Verificar se a Rede foi montada corretamente, “perguntando” ao QP de cima
para baixo, qual a origem de cada atividade e observar a sua concordância
com a Rede.
4. Calcular as datas mais cedo e mais tarde

# Data mais cedo – é o momento no qual é possível ter concluídas todas as
atividades que condicionam um evento.
2
(4)
4
3
C = Data mais cedo
Dcant = Data mais cedo anterior
Dativ = Duração da atividade
(t >) = Maior tempo
C = Dcant + Dativ (t >)
Cálculo do cedo:
a) Ao evento inicial atribuir o valor 0 (zero), caso não seja determinado;
b) Empregar a fórmula de cálculo do cedo - C = Dcant + Dativ (t >) , para cada
evento (a partir do evento inicial).
c) Se em determinado evento chegar mais do que uma atividade (evento 9),
escolher aquela de (maior tempo).
5. Calcular o Tempo Disponível - TD

O TD deve ser calculado com o objetivo de verificar a disponibilidade de tempo de
cada atividade para poder fazer os ajustes necessários de forma a não atrasar o
prazo fixado para o término do projeto.
6. Calcular as Folgas das Atividades

As folgas são estabelecidas com o objetivo de verificar a diferença entre as possíveis
datas de início (cedo inicial e tarde inicial) e suas possíveis datas de término (cedo
final e tarde final).
5 1
(3) (14) 8
A
1 2
10
- Primeira data de início ..................... 3

- Última data de término .................... 18
- Primeira data de término ................. 13
- Última data de início ....................... 8
Cálculo das Folgas:

⇨ FL (Folga Livre) é o atraso máximo que uma atividade pode ter sem comprometer a
data mais cedo do seu evento final.
FL = (Dcf - Dci) – D
⇨ FT (Folga Total) é o Tempo Disponível menos a duração da atividade.
FT = TD – D ou FT = (Dtf - Dci) – D
⇨ FD (Folga Dependente) é o prazo que se disponível entre o tarde do evento final e o

tarde do evento inicial para realizar uma atividade.
FD = (Dtf - Dti) – D
⇨ FI (Folga Independente) é o prazo disponível entre o cedo final e o tarde inicial para
realizar uma atividade (eventualmente dá um número negativo).
FI = (Dcf - Dti) - D
Exemplo do cálculo das folgas e do tempo disponível:
5 1
(3) (14) 8
A
1 2
10
.
7. Determinação do Caminho Crítico

O Caminho Crítico é formado pelas atividades mais relevantes do projeto para fins
de controle, pois elas não podem sofrer qualquer tipo de atraso, e se isto
acontecer irá refletir diretamente no prazo fixado para o término do projeto.
O Caminho Crítico é constituído pelas atividades (interligadas) de menor folga ou de

folga nula, entre o evento inicial e o evento final, o qual, inclusive, podem passar
pelas atividades fantasmas.
Métodos para estabelecer o Caminho Crítico:
1º Pelas diferenças constantes entre os cedos e os tardes (encontrada no último

evento).
Regras Básicas:
a. não são críticas as atividades cuja diferença entre cedos e tardes não
seja igual àquela encontrada no último evento;
b. poderão ser críticas aquelas atividades cuja diferença no evento inicial e
final entre cedos e tardes seja igual à encontrada no último evento;
b) são, realmente, atividades críticas aquelas que obedecem à condição
anterior e que a data mais tarde de seu evento final, menos a sua própria
duração, é exatamente igual à data mais tarde de seu evento inicial, ou
seja:
Tarde Posterior – Duração da Atividade = Tarde Anterior
Determinação do Caminho Crítico (exemplo):
2º Pelas Folgas da Atividades, onde as folgas (livrem total, dependente e

independente) devem ser iguais a 0 (zero).
Exemplo
A seguir o plano de atividades de um projeto de instalação de uma pequena unidade de um
Call Center, para o qual desejamos determinar o caminho crítico através da montagem de
uma rede PERT/CPM.
Código Atividades descrição Atividades Duração

Precedentes (dias)
A Esc olha d o sistem a d e inform aç ão 3
B Determ inaç ão d as p rop ostas d os 2
fornec ed ores
C Ob tenç ão d as p rop ostas d os A,B 6
fornec ed ores
D Seleç ão d o fornec ed or C 1
E Reform ulaç ão d as instalaç ões B 15
F Enc om end a d o sistem a D 1
G Transform aç ão d as instalaç ões p ara E, F 15
as ad eq uar aos novos eq uip am entos
H Instalaç ão d o sistem a E, F 3
O quadro doI projeto nosento
Treinam informa
d os todas
op eradas atividades, quais são
ores G, Has precedentes,
5 ou seja,
quem deve J iniciar somente
Ensaio Final quanto a atividade anterior estiver H encerrada,15bem como a
duração de cada uma.
Para determinarmos o caminho crítico, em um primeiro momento montamos simplesmente a

rede, com a preocupação de fixação de tempos, como também de separar o que é atividade
do que é evento, numerando-os. Usualmente utiliza-se para eventos caracteres numéricos (1,
2, 3, ...) e para atividades caracteres alfabéticos (A, B, C, ...).
.
E 6 9
2 15
B
2 H 11
1 A 3
J
3 15
C 4 D 5 F 7 G 8 I 10
3 6 1 1 15 5
O próximo passo será calcular a data mais cedo de acordo com a seguinte fórmula:
C = Dcant + Dativ (t >)

Evento Evento Data mais cedo + duração Data mais
procedente cedo
1 - - 0
2 1 0+2 2
2 2+0
3 3
1 3+0
4 3 3+6 9
5 5 9+1 10
6 2 2+15 17
5 10+1
7 17
6 17+0
9 7 17+3 20
7 17+15
8 32
9 20+0
10 8 32+5 37
11 10 37+15 52
O próximo passo será calcular a data mais cedo de acordo com a seguinte fórmula:
Evento Evento procedente Data mais tarde - Data mais

duração tarde
11 - - 52
10 11 52-15 37
8 10 37-5 32
9 8 32-0 32
8 32-15
7 17
9 32-3
6 7 17-0 17
5 7 17-1 16
4 5 16-1 15
3 4 15-6 9
6 17-15
2 2
3 9-0
2 2-2
1 0
3 9-3
Agora calcularemos as folgas.
Evento Data mais tarde - Folga

data mais cedo
1 0-0 0
2 2-2 0
3 9-3 6
4 15-9 6
5 16-10 6
6 17-17 0
7 17-17 0
8 32-32 0
9 32-20 12
10 37-37 0
11 52-52 0
.
Exercício: Projeto de Reforma de Escritório

Segundo as atividades abaixo relacionadas. Crie um projeto de Reforma de Escritório.
ATIVIDADES DURAÇÃO
Início do Projeto 0 dias
Planejamento 10 dias
Escrever proposta 3 dias
Contratar arquiteto 2 dias
Localizar nova instalação 1 semanas
Apresentar a proposta 2 dias
Aprovação pela corporação 0 dias
Negociar novo aluguel 4 dias
Finalizar plantas 2 semanas
Selecionar subcontratados 1,5 semanas
Contratar empresa de mudanças 3 dias
Submeter plantas 1,5 semanas
Permissão recebida 0 dias
Remodelagem 10 dias
Demolição do espaço existente 3 dias
Estruturar paredes interiores 4 dias
Instalação elétrica 6,5 dias
Instalação de linhas telefônicas e de dados 3 dias
Terminar paredes 2 semanas
Instalar portas e hardware 3 dias
Pintura 4 dias
Instalar carpetes no espaço do escritório 3 dias
Instalar vinil: sala do servidor 3 dias
Acabamento e fixação final 1 semanas
Testar sistemas 2 dias
Retocagem 3 dias
Limpeza final 2 dias
Remodelação completada 0 dias
Mudança 2 dias
Espaço do escritório 2 dias
Desconectar computadores/equip. 2 dias
Desmontar móveis 2 dias
Mudar móveis/equip./caixas 4horas
Montar móveis 2 dias
Reconectar computadores/equip. 2 dias
Espaço do escritório completado 0 dias
Sala do servidor 2 dias
Desconectar servidor 2 dias
Mover servidor 4horas
Reconectar servidor 2 dias
Testar servidor 1 dias
Sala do servidor completada 0 dias
Reinauguração do Escritório 0 dias

Gerenciamento de projetos: conceitos-chave

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gerenciamento de projetos: conceitos-chave

Enviado por

Direitos autorais:

Formatos disponíveis

Gerência de Projetos Mauro Rezende Filho

Para cursos de Administração, Ciências Contábeis, Economia e

Mauro Rezende Filho, M.Sc.

 Gestão por Projetos Aplicando o Método PERT/CPM e o Software MS-Project

 Probabilidade e Estatística Utilizando e Excel

 Balanced Scorecard: Instrumento de Desdobramento de Estratégia e Alavancagem de

11.2.2 O Recebimento das Propostas Técnico-Financeiras .................................... 99

 Gerência do tráfego urbano: como tratar os desvios de tráfego, a inversão de mãos,

Em cada uma das questões acima, como fazer para:

 Definir, com clareza e objetividade, o escopo do que se pretende?

 Definir o escopo geral do projeto?

Gerenciar um projeto de realização do evento significa cuidar de todos os detalhes citados

2.1 Conceito de Projeto

“Um projeto é um esforço temporário empreendido para criar um produto ou

Outras definições de projeto vêm a seguir:

“Projeto é um empreendimento não repetitivo, caracterizado por uma sequência

“Projeto é uma combinação de recursos organizacionais colocados juntos para

Características principais dos projetos:

 Temporariedade e individualidade do produto ou serviço a ser desenvolvido pelo

Outras características relevantes:

 Empreendimento não repetitivo;

2.2 Gerenciamento de Projetos

2.3 Operações X Projetos

Suas semelhanças com os projetos são as seguintes:

Suas diferenças em relação aos projetos são as seguintes:

 As operações são repetitivas, enquanto os projetos são únicos;

mesma estará sempre sujeita a modificações, acertos e adequações, dada a

2.4 Exemplos de Projetos

2.5 Exemplos de Não-Projetos

2.6 Sucesso e Fracasso em Projetos

1. A eficiência do projeto: consiste em realizar o projeto de forma a atender ao seu

Perda de produtos gerados e insumos estocados para consumo no projeto, ou perda

2. Impacto/satisfação do cliente do projeto: esta dimensão é muito complexa, pois

3. Sucesso direto/sucesso no negócio do cliente: esta característica pode ser

Em uma outra abordagem, mais analítica, poderíamos caracterizar o sucesso de um projeto

O fator de antecipação dos resultados de um projeto pode se revelar, em alguns

 Envolver um orçamento menor ou igual ao previsto. Neste caso, se considera que a

 Demandar menos recursos do que o previsto originalmente;

Sucesso Organizacional: quando ocorre aderência do projeto a quesitos não mensuráveis,

 Um projeto que ocorre com um mínimo de alterações de escopo;

Finalmente, se agregarmos todas as questões levantadas acima no intuito de chegarmos a

2.7 Fatores de Sucesso e Fracasso em Projetos

Fatores dos projetos de Sucesso % de Respostas

Fatores dos projetos Concluídos com Restrições % de Respostas

Fatores dos projetos Cancelados % de Respostas

Alterações nas especificações e requerimentos 8,7%

 Falta de diferenciação entre objetivo e funcionalidade: a funcionalidade deve

 Falta de sintonia entre negócio e tecnologia: quando os objetivos de negócio e

 Falta de uma linguagem e um processo comuns: neste caso, resulta-se em muita

data em que a mesma é tornada disponível para a linha de produção? Ou os códigos

 Falhas na comunicação entre as equipes de projeto, e falhas na atuação

2.8 Trade-Offs do Gerenciamento de Projetos

O gráfico abaixo apresenta os objetivos principais do gerenciamento de projetos, com os

Relacionamento entre os objetivos de um projeto: custo, prazo e qualidade

3 Fases de um Projeto e seu Ciclo de Vida

3.1 Subdivindo os Projetos

A. Determinar se o projeto deve continuar na sua próxima fase;

As descrições do ciclo de vida de projeto podem ser genéricas ou detalhadas. Descrições

Os programas são grupos de projetos administrados com as mesmas técnicas, de modo

como, por exemplo, as sub-fases “Especificação Conceitual”, “Definição dos Planos de

O diagrama a seguir ilustra o exemplo de subdivisão de um projeto em sub-projetos, fases e

Projeto Nova Casa